long-term release schedule?

Peter Hansen peter at engcorp.com
Thu Jun 12 14:41:22 CEST 2003

Ray Smith wrote:
> "Tim Peters" <tim_one at email.msn.com> wrote in message
> > Python 3.0 in particular would require finding a way
> > to fund at least Guido's time on it, and there's no obvious way (at this
> > time) to do that.
> I'm looking at introducing Python into a corporate environment and the
> above statement seems at least a little worrying (the first time I thought
> about it).

Why would it be worrying in a corporate environment?  Are you
worried that the donated time of the developers will stop
being provided freely to your company?

> Thinking again it seems obvious that any Open Source or Proprietary
> software can be discontinued.  

"Discontinued" has little meaning in this world.  "Development
stopped" might have a little more meaning, except that the source
code is freely available to you to pick up and carry on with any
enhancements you wish to make, if you no longer want to rely on 
others to make those enhancements, unpaid, for your company.

I think in most corporate environments the concern should be on
the stability of the product, and with that in mind, consider the
PBF's (Python Business Forum) focus on Python version 2.2 and 
making sure it is a long-supported and stable release.  Again,
free, without your company paying a dime for it (although it
could become a member of the PBF to help support the effort).

> The core Python language seems very stable, if bug fixes where the
> only changes to Python in the next 5-10 years would Python still 
> gain in popularity as fast as it is now?

How fast is it gaining popularity now?

(Note: I use Python in a corporate environment, and I don't 
really understand your concern.  Commercial software is much less
dependable than Python has proven to be, both from the point of
view of the product itself and from the point of view of the 
community backing it.  Worst case: we grab the source for 2.2
(or whatever version we want to maintain ourselves) and carry on
with our own product line, with less concern than we'd have 
with a commercial product we couldn't get source to.)


More information about the Python-list mailing list