Defending the Python lanuage...

Tim Peters tim.one at home.com
Wed Jan 30 18:15:38 EST 2002


[Rony]
> ...
> - What happens with the thousands of lines of code we wrote for our
> standard librarys and wich we are using for every project. And THIS is
> a very important question i think, because you're talking money here
> (sorry for the open source guys here <wink> ). If, as a company, you
> have to trow away a couple of thousand hours of investment because
> your development team wants to change you need a serious reason for
> this.

If your development team wants to change, that *is* a serious reason.
Technology evolves quickly, and they're down in the pits wrestling with it.
If they feel their tools are getting out of date, they'll be eager to move
on, and you can enjoy the "cost savings" of holding on to dead weight until
it drags you to the bottom of the ocean <0.9 wink>.

> And this goes even further than that, another point is how good
> will it be supported ? Here i don't mean only the language it self but
> allso his librarys. Take Python as an example. The language itself is
> going trough a *normal* growing cycle and is very well supported, but
> imaging that with version Python 3000 (:)the "community" has decided
> that the Tkinter library won't be supported any more.. I can assure
> you that this would be a very expensive decission for us, our whole
> GUI library is based on that now.

If you can throw money at it, *because* it's open source you're certain to
find competent people to maintain it for hire as long as you like.  There
are no legal impediments -- nothing on Earth can interfere with you doing
whatever you want with the code.  Heck, if Tkinter is such a great boon to
business, you could take over maintenance for the world and turn it into a
profit center.  All assuming that Tk will get abandoned by at least tens of
thousands of current users.  It may!  And it probably will if something much
better comes along -- in which case a decision to stick with then-obsolete
technology would likely be technical suicide, not fiscal prudence.

> And isn't this a risk with many open source projects ?

In my repeated experience, less so than with closed-source products.  I've
even got thousands of dollars worth of personal software sitting at home,
purchased from companies that have since gone out of business, taking the
source code with them.  I can't get upgrades, new features, fixes, support,
ports to modern platforms, nothing -- it's dead.  When's the last time you
*bought* a piece of software that came with a guarantee it would always be
supported?  Open source *is* like that, to the extent that free support is
relatively easy to get for as long as people like it enough to work on it,
and even after that support for hire remains a possibility forever.  Would
that it were so for my copy of, e.g., Macsyma.

> - What will be the investment for training of our development team and
> how much time will it take

6 or 5, give or take <wink>.

> - Do we have a 'small ' project we can use as a testcase

That's a good question, but you'll have to answer that in-house (telepathy
isn't a Usenet strength).

> and what do we have to do if we where wrong ?!!

Learn from it and move on?

Software bascially sucks, and you've got to come to terms with that.  The
reality is that no software you write is going to have a useful lifetime
spanning even a decade without continual rewriting.  *Especially* when
software is successful, customers quickly demand new things it was never
intended to do, and sometimes fundamentally different technology is required
to make that possible.  So, if you want to stick to the same codebase for
many years, your best plan is to write software that nobody wants <0.7
wink>.

even-microsoft's-notepad-supports-unicode-now-ly y'rs  - tim





More information about the Python-list mailing list