As a popular open source system, Python enjoys a large and active development community that responds to issues and develops enhancements with a speed that many commercial software developers might find remarkable. Python developers coordinate work online with a source-control system. Changes are developed per a formal protocol, which includes writing a PEP (Python Enhancement Proposal) or other document, and extensions to Python’s regression testing system. In fact, modifying Python today is roughly as involved as changing commercial software—a far cry from Python’s early days, when an email to its creator would suffice, but a good thing given its large user base today.
The PSF (Python Software Foundation), a formal nonprofit group, organizes conferences and deals with intellectual property issues. Numerous Python conferences are held around the world; O’Reilly’s OSCON and the PSF’s PyCon are the largest. The former of these addresses multiple open source projects, and the latter is a Python-only event that has experienced strong growth in recent years. PyCon 2012 and 2013 reached 2,500 attendees each; in fact, PyCon 2013 had to cap its limit at this level after a surprise sell-out in 2012 (and managed to grab wide attention on both technical and nontechnical grounds that I won’t chronicle here). Earlier years often saw attendance double—from 586 attendees in 2007 to over 1,000 in 2008, for example—indicative of Python’s growth in general, and impressive to those who remember early conferences whose attendees could largely be served around a single restaurant table.
Having said that, it’s important to note that while Python enjoys a vigorous development community, this comes with inherent tradeoffs. Open source software can also appear chaotic and even resemble anarchy at times, and may not always be as smoothly implemented as the prior paragraphs might imply. Some changes may still manage to defy official protocols, and as in all human endeavors, mistakes still happen despite the process controls (Python 3.2.0, for instance, came with a broken console input function on Windows).
Moreover, open source projects exchange commercial interests for the personal preferences of a current set of developers, which may or may not be the same as yours—you are not held hostage by a company, but you are at the mercy of those with spare time to change the system. The net effect is that open source software evolution is often driven by the few, but imposed on the many.
In practice, though, these tradeoffs impact those on the “bleeding” edge of new releases much more than those using established versions of the system, including prior releases in both Python 3.X and 2.X. If you kept using classic classes in Python 2.X, for example, you were largely immune to the explosion of class functionality and change in new-style classes that occurred in the early-to-mid 2000s. Though these become mandatory in 3.X (along with much more), many 2.X users today still happily skirt the issue.