First, it’s important to realize that DTP’s low closing rate is hardly unique. Rather, it’s the rule on Eclipse projects and has been validated by Eclipse Foundation studies via data mining on Eclipse code check-ins. We must seek another explanation for this situation. In the rest of this section I’ll propose a model for contributions to open source and identify a key factor that I claim limits wider contributions.

There are many levels on which you can work on an open source project. As a developer, there’s a standard division between contributors who don’t have write-access to the source code and committers who do. Typically, you start out as a contributor and are granted committers status after gaining the trust of existing committers. As a committer, there are various levels of responsibility and rights concerning project control and direction. Ideally open source projects operate as a meritocracy: the more you do, the more you can do. In practice, a committer needs to build credibility within the community and political considerations are in play.

Even if an open source project was operating as a pure meritocracy, some group has to judge the merits of the contributions. In theory, judgment is passed by the widest possible community surrounding a given project. In reality, however, the governance is similar to that of elected officials who need to maintain a certain level of credibility with their constituents, but are otherwise empowered to make the actual decisions. That is, the existing committers on a project make the decisions – though usually not in a strict consensus model that open source might imply: command-and-control is prevalent – and retain the ability to continue doing so as long as they maintain a certain level of credibility with the overall project community. This structure leads to various levels of control within an open source project. It turns out that control is the key factor that determines whether a developer is willing to join a project and to what extent effort is supplied once having joined. Here we can identify a number of levels:

1. Closed source: involvement is determined by employment only
2. Participation: open source, contributions allowed directed by key committers
3. Sand-boxed: open source, control granted for limited components, overall direction retained by the key committers
4. Collaboration: open source, component and overall project direction determined in joint effort by all committers.

Given a set of key committers who originate a project, the level of control that they exercise is weaker as the level increases. That is, in levels 1–3, the key committers are firmly in charge of the project’s overall direction and cede control only in isolated cases at level 3. In level 4, the key committers no longer try to control the overall direction of the project, rather, a true collaboration with any interested parties is obtained. As an example, DTP falls squarely in level 2.

Why does it matter? Isn’t it natural enough to assume level 2? My claim here – and as key points in this document – is that levels 2 and 3 prove that we are only just beginning to understand the potential of open source, and that the real value of open source comes from level 4 maturity. Specifically, I claim the following:

1. The major reason why Eclipse projects in general, and DTP in particular, have a hard time recruiting additional core committers is because companies (and individuals) are far less likely to make such resource allocations without gaining an acceptable level of control in return.
2. A truly and deeply engaged open source community has the potential to provide a large return on investment for all involved, only if the governance is at level 4. Otherwise, the incentives for such deep involvement are not sufficient to sustain it (especially over the long run).
3. Innovation based on interaction with lead users is minimal at level 3, and only really viable at level 4.
4. Few organizations today (particularly those from “traditional” software backgrounds) understand these levels and a huge advantage will accrue to the first ones that do.

Summary
It’s not hard to understand why developers don’t join a project, even if they initially express serious interest in doing so. This is because the attitude of most open source projects today is that “we’ll give you the privilege of working for us.” Few individuals are willing to contribute their free time to such an endeavor, and companies interested in open source participation (rightfully) expect some level of control in exchange for their resource allocations.

References

• Cusumano, Michael A. The Business of Software: What Every Manager, Programmer, and Entrepreneur Must Know to Thrive and Survive in Good Times and Bad. Free Press. 2004.
• Singh, Param Vir; Fan, Ming; and Tan, Yon. “An Empirical Investigation of Code Contribution, Communication, Participation and Release Strategy in Open Source Software Development: A Conditional Hazard Model Approach.” http://opensource.mit.edu/home.html. 2007.
• Weber, Steven. The Success of Open Source. Harvard University Press. 2004.