When open source community programming doesn't work

Comment has been circulating in certain web-driven circles relating to the size of some open source projects. Allow me to elaborate…

The subject in discussion is centred on projects that (allegedly) suffer from too small a number of community members; the upshot of which may be to create some sort of elitist group of core developers (or a single developer even) that hold all (or a disproportionate amount at least) of the knowledge and power behind a project.

Jenkins and Google’s V8 engine have been singled out as potentially falling into this category.

But (even if the team is rather small) is this a problem necessarily?

The contention is that when “issues” arise, they will sometimes necessitate the attention of a very small pool of brains — as opposed to being able to benefit from widespread community care and attention.

Looking at Jenkins more closely, it’s hard to tell if these suggestions hold water. The project itself has created an open source continuous integration server built with Java, it currently provides over 300 plugins to support building and testing virtually any project.

While it’s true that Jenkins’ website contributors number only three individuals, the group’s recent user conference listed attendees from all the countries shown on the below map. But that’s not the same as developer numbers of course.

Jenkins users.png

There is of course no optimum size for an open source project, nor should there be. But I hope these notes provide an interesting diversion and talking point.