I systematically look at the actual number of developers involved in the production of one hundred mature OSS products. What I found is more consistent with the lone developer (or cave) model of production rather than a community model (with a few glaring exceptions, of course). …
… My contention is only that communities do things other than produce the actual product- e.g. provide feature suggestions, try products out as lead users, answer questions etc. …
To be more specific the top 100 most active projects (based on Sourceforge’s activity percentile) in the mature class were chosen for this study. …
Finding 1: The vast majority of mature OSS programs are developed by a small number of individuals. …
Moreover, as shown in Table 2, only 29% of all projects had more than 5 developers while 51% of projects had 1 project administrator. Only 19 out of 100 projects had more than 10 developers. On the other extreme, 22% of projects had only one developer associated with them. …
Finding 2: Very few OSS products generate a lot of discussion. Most products do not generate too much discussion. …
Finding 3: Products with more developers tend to be viewed and downloaded more often. …
Finding 4: The number of developers working on a OSS program was unrelated to the release date.
It could be argued that older projects may have more developers associated with them. However, we found no relationship between the release date and the number of developers associated with a program. …
Even though the discussion here may seem like an example of extreme free- riding, the reader needs to know that all free-riding is not necessarily “bad”. For instance, consider public radio stations in the United States. Even the most successful stations have about a 10% contribution rate or a 90% free-ridership rate. But, they are still able to meet their goals! Similarly, the literature on lurking in e-mail lists has suggested that if everyone in a community contributes it may actually be counter-productive.
Similarly, a recent survey of participants in open-source projects conducted by the Boston Consulting Group and MIT provides more insight. The top five motivations of open-source participants were
1. To take part in an intellectually stimulating project.
2. To improve their skill.
3. To take the opportunity to work with open-source code.
4. Non-work functionality.
5. Work-related functionality.