A good open source community should have a good developer and user support infrastructure. It should have things such as:

• releases that are recent enough to be useful
• up to date and helpful documentation
• a good web site
• a helpful and active mailing list
• automated tests
• well maintained change notes
• well managed issue tracker
• well managed version control system

and so on. These are very important. Most open source communities probably feel they can do a lot better in some of the areas above.

All that is necessary and important, but it isn't enough.

A living, functional open source community should also have vision. It should support an atmosphere of ideas. Not just small ideas, but also some bigger ideas, that affect the very core of the project and everyone that uses it.

A community shouldn't only be in maintenance mode with improvements taking place in the periphery, or only in matters where consensus can easily be reached. A community should also be able to innovate in areas where consensus is difficult, because sometimes that is necessary in order to move forward.

Innovation is much easier in a smaller, younger community. In a larger, more mature community it is easy to forget about innovation because there is so much more focus on maintenance and stability. In such a community, innovations will need to be more incremental in order to safeguard stability. Incremental improvements can add up, however - evolution can be very innovative. A living, functional community can aim improvements in directions where they do add up.

A innovative community should have the following qualities:

• creative energy. There should be people who come up with ideas, preferably based on experience. There should be people who are not satisfied with the status quo and are willing to do something about it. These ideas shouldn't be just be in the periphery but also about core aspects of the project.
• supportive atmosphere: Creative energy should be channeled positively, not dispersed. A community should have an atmosphere where new ideas can be discussed and not just always be rejected or worse, ignored. Discussions should aim to refine ideas or offer alternative approaches.
• process: The community should have clear mechanisms in place that can help lead a discussion to a conclusion that can be accepted by the community.
• leadership: A process is important but not sufficient. In order to make the process work, the community should have people who are able to lead the process to conclusions.
• implementers: people who actually go and implement the idea. Without them, it all stays with a discussion and the community is ultimately inert.

A living open source community shouldn't discourage fundamental innovations because the support infrastructure isn't right yet. It will never be perfect - this is another way in which perfection can be the enemy of the good. The community should support improvements to the support infrastructure and allow innovation at the same time. A great quality of open source communities is that people can work in parallel.

It is often possible to do both at the same time: innovate and as a side effect also improve the support infrastructure of the project, such as documentation. The community should have a culture where innovations go hand in hand with improvements to the support infrastructure that this innovation touches, such as documentation.

To conclude: in open source communities, a healthy balance between stability and innovation needs to be maintained. We should not lose sight of one by focusing too much on the other.

P.S. I just realized that it is possible to interpret this post as an argument against Python's PEP 3003, the "Python Language Moratorium". It wasn't intended as such; I'm very much in favor of this moratorium. The Python development community is a mature community where innovation on the language level has certainly not been lacking. The moratorium on language changes helps in the important area of stability, and also helps refocus innovation on areas that do need improvement more, such as the interpreter, libraries and the packaging infrastructure.