Open Source Lifecycle

Back in September, Michael Kolling raised a good point about the open source software lifecycle—over time open source systems accumulate features to the point of becoming unusable. He points out:

So, what we really need is for a system developing towards the Happy User Peak, and then somebody pulling the hand brake and saying – “That’s it, folks, from now on we are only maintaining compatibility, keep the system running, oiling the cogs, but no new features. Anyone who adds a feature will be shot.”

In practice, this rarely happens. Why is that?

I have a couple of quick thoughts on this:

First, time after time we find new, simpler systems will be created in response to over-engineered messes. Consider Spring versus J2EE, or Ruby on Rails and Django compared to almost everything that came before them. In my experience, the market with auto-correct even if an individual project will not.

Secondly, over in Apache, we have a related problem. We have several projects which have reached the end of their lifecycle. In some cases, newer technology has been developed to replace the older generation. In other cases, the software is stable and still widely in use, but there really isn’t much to do with the code other than the occasional bug fix.

Apache projects live and die based on a community of volunteers, so when the action dies down, so too does the community of developers maintaining the project. This leads to several problems, the chief of which is oversight. Apache creates a set of natural checks and balances by requiring diversity in projects, minimal numbers of participants and votes, and a hierarchy of responsibility to ensure that no one individual can abuse the software commons the foundation stewards. When an active project transitions into “maintenance only” mode, those checks and balances start to weaken and our promises of quality and oversight are compromised. It can be difficult to know when a project goes from a handful of active maintainers to one or none, because maintainers generally don’t announce they’re no longer watching the project.

There’s another set of problems from the user’s perspective. How does one determine the lifecycle state of a given project? Will anyone answer my emails? Who will accept my patches? Will there ever be another release? Can I still get involved or should I fork this code?

We at Apache need to have a clearer process for sunsetting a project and a clearer, more consistent set of answers to these user questions. It’s not a difficult thing, just something we have to come to concensus on and enact. But with the break-up of Jakarta and the slowing down of several other projects, we need to have an answer.

Update: fixing unicode issue.