Are open source projects growing faster (in terms of the number of users and developers) relative to closed source ones? Are there any metrics measuring this?

  • 1
    Open source software design is usually more stable than proprietary software. Mar 12, 2017 at 2:51

2 Answers 2


This totally depends on the dynamic of user base (both users and contributors) as the project evolves. Also it depends on dynamic of bazaar, technology, sponsorship, rivals, etc. So consider this case:

Let's consider two projects (one close and one open source) but both have same financial support and management (hence same dynamics regarding outer environment for growth). In this particular case, the open source project generally have faster growth.

So the notion of growth in a project is multi-factored and being closed or open source is just one. However if you fix all other factors (aka control the dynamics of project evolution) we can say being open source helps growing faster.

Let's start with counter-hypothesis, The fact that growth of software project depends whether on open or closed source has been noted in [1]:

This paper investigates the hypothesis that open-source software grows more quickly, but does not find evidence to support this. The project growth is similar for all the projects in the analysis, indicating that other factors may limit growth. The hypothesis that creativity is more prevalent in open-source software is also examined, and evidence to support this hypothesis is found using the metric of functions added over time. The concept of open-source projects succeeding because of their simplicity is not supported by the analysis, nor is the hypothesis of open-source projects being more modular. However, the belief that defects are found and fixed more rapidly in open-source projects is supported by an analysis of the functions modified. The paper finds support for two of the five common beliefs and concludes that, when implementing or switching to the open-source development model, practitioners should ensure that an appropriate metrics collection strategy is in place to verify the perceived benefits.

which basically indicates that how rapidly a project evolves is multi-factored and being just open source isn't enough. However it should be noted the reference [1] doesn't isolate the factors and just based its empirical study on general case i.e. whether open source projects, in general, have faster growth or not. However the question OP asks is about the impact of openness in growth which is not the case in the above paper. For example in [2], with investigating the case of APACHE and compare it with some other selected commercial projects, the above hypothesis has confirmed, with a caution:

Although we picked several commercial projects that are reasonably close to APACHE, none is a perfect match, and the reader should not infer that the variation between these commercial projects and APACHE is due entirely to differences between commercial and OSS development processes.

This paper has provided some factors such as the core developer are not larger than 10-15 and write 80% of the code. or:

This observation stems both from the "many eyeballs implies shallow bugs" observation cited earlier [15], and the way that fixes are distributed. In the "free" world of OSS, patches can be made available to all customers nearly as soon as they are made. In commercial developments, by contrast, patches are generally bundled into new releases, and made available according to some redetermined schedule.

This is one of the key reasons for possible quicker evolution of F/OSS projects. The model used in [1] regarding growth can be challenged by empirical evolution models presented in [3]. From [1]:

The majority of the open-source and closed-source projects analyzed have a similar growth rate with respect to the increase of the total lines of code, the total complexity, and the total number of functions when analyzed using a linear approximation. A linear model was chosen based on an analysis of several different models [10] and provides a reasonable approximation of the growth for project comparisons.

In [3] it's been shown how the model for evolution of software should be modified for F/OSS project usually in favor of faster growth at least for significant portion of the F/OSS group:

The most interesting fact is that while in the mean the growth rate is linear or decreasing over time according to the laws of software evolution, a significant percentage of projects is able to sustain super-linear growth. There is a positive relationship between the size of a project, the number of participants, and the inequality in the distribution of work within the development team with the presence of super-linear growth patterns.


The choice of license for software project (and hence open or closed) has real impact on software development [4]. However we're more curious about whether being open sorced foster rapid growth in comparison to closed source or not. While I tried to reflect different aspects of the question it should be noted that there are significant body of evidence (based on my point of view and my search through academic papers in this regard) which shows positive correlation of F/OSS development model with growth in comparison to closed source development. However how rapid a software project develops is a multi-factored and complicated problem and clearly there is great opportunity regarding researching this topic to come with new/better models explaining software evolution.


[1] Paulson, James W., Giancarlo Succi, and Armin Eberlein. "An empirical study of open-source and closed-source software products." IEEE Transactions on Software Engineering 30, no. 4 (2004): 246-256.

[2] Mockus, Audris, Roy T. Fielding, and James Herbsleb. "A case study of open source software development: the Apache server." In Software Engineering, 2000. Proceedings of the 2000 International Conference on, pp. 263-272. IEEE, 2000.

[3] Koch, Stefan. "Software evolution in open source projects—a large‐scale investigation." Journal of Software Maintenance and Evolution: Research and Practice 19, no. 6 (2007): 361-382.

[4] Stewart, Katherine J., Anthony P. Ammeter, and Likoebe M. Maruping. "Impacts of license choice and organizational sponsorship on user interest and development activity in open source software projects." Information Systems Research 17, no. 2 (2006): 126-144.

[5] Scacchi, Walt. "Understanding open source software evolution." Software Evolution and Feedback: Theory and Practice 9 (2006): 181-205.

p.s. In my answer I frequently use evolution for project development which can be investigate further on references such as [5].

*p.s. The Bazaar is used referring to paradigm elaborated in "the cathedral and the bazaar".*

*p.s. I provide more emprical/academic resources based on @Zimm i48 comment

  • That's an interesting consideration but it would benefit from being based on evidence or actual examples.
    – Zimm i48
    Apr 10, 2017 at 11:38
  • Wow! The answer looks now very good! Thanks for taking my comment into account.
    – Zimm i48
    Apr 12, 2017 at 10:25
  • 1
    @Zimmi48, you're absolutely welcome. I get inspiration from your request to really take a look to the topic (through academic resources) and it was pretty fun. Although, this is an interesting topic worth more research...
    – SddS
    Apr 12, 2017 at 15:53
  • 1
    It appears [1] is defining growth as how much the lines of source code increase, but that could be more of a measure of how bloated the program is. By "growth" I mean the increase in userbase size and number of developers.
    – Geremia
    Jan 10, 2018 at 16:44

Metrics are difficult here. Many closed projects are unclear, popular or not. Many open projects are clear but not just the popular ones.

So lets look at survival. Money can motivate people to advance a project they would normally never touch. But if a company does not like to put more money into a project the project dies rather quickly. An open project can be overtaken by other people.

As an example lets look at java projects. It is effectively impossible to write a good project without using open source projects. i.e. here open source is overwhelmingly popular. e.g. * Maven, Ant, Gradle to build * many apache, google libs * jboss, spring ... I have never seen a popular java project (closed or open) without open source tools.

So my opinion is that it is unclear what makes them grow faster, open or closed. But the survival is better for popular open source software.

  • 1
    I don't think that this question should receive opinion-based answers. It would be better if, at least, part of your answer could be evidence-based (e.g. what evidence makes you say that it is impossible to write a good Java project without using open source projects? )
    – Zimm i48
    Mar 10, 2017 at 10:00
  • @Zimmi48 Let's reverse that. Show me a single good closed project without an open source tool or lib. So no Ant, Maven or gradle. My insight in many companies is that there is (in Java) no real project. But I stay corrected.
    – openCage
    Mar 10, 2017 at 10:26
  • 2
    I didn't say you were wrong. Actually, I would bet that you are right. It's just that you are claiming something as a fact without bringing evidence to demonstrate it. At least, if you had supported that claim with your personal experience in many companies (in the text of your answer), that would have meant something (even if of course, this is much harder to verify).
    – Zimm i48
    Mar 10, 2017 at 10:30
  • Concerning survival: You may also want to consider the opposite dynamic: An open source project that does what it is supposed to do, and does it well, will be left as it is. In a commercial project, in contrast, the need may be seen to make changes (objectively, not necessarily improvements) for the sake of change, to have a new version that generates new revenue. Apr 12, 2017 at 7:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.