How to Grow Your Open Source Project 10x and Revenues 5x

IT Leaders Summit
Location: F 150
Average rating: *....
(1.67, 3 ratings)

By studying a selection – believed to be more or less complete – of the most popular open source projects and correlating their size with governance model, we have revealed a strong, and to some possibly surprising result:

  • There are 9 projects (Linux, KDE, Apache, Eclipse, Perl+CPAN, Mozilla+Addons, Gnome, Drupal and GNU) that stand out as significantly larger – roughly 10 times – than any others.
  • All of these projects, categorized as “XtraLarge”, are developed as collaborative community projects governed by non-profit foundations. No single vendor project has so far been even close to reaching their magnitude.
  • There appears to be a glass ceiling limiting the growth of the Large single-vendor projects (MySQL, Qt, OpenOffice, Mono, JBoss).
  • While the unfathomable magnitude and velocity of the Linux project is well studied and commonly known, and the preference of collaborative foundation governed projects has started to become a generally accepted fact, it was surprising to find as many as 9 projects that all clearly stand out from the rest. A 9 to 0 is statistically a very strong result in favor of the foundation governance model.
  • The other factor strengthening this result is the clear gap between the “XtraLarge” group and the other projects. This gives further confidence in the validity of the result. Even if the underlying data was deemed to be of poor quality, it is clear it does not have errors that could explain a difference of this magnitude.
  • Another common trait all 9 “XtraLarge” projects share is the software architecture being either modular (Linux, Eclipse, Perl+CPAN, Mozilla+Addons, Drupal) or formed as a collection of software (KDE, Apache, Perl+CPAN, Gnome and GNU)

The Oracle controlled OpenJDK may prove to become an exception to the rule, since IBM has now announced that it will contribute to OpenJDK development and abandon Apache Harmony, and previously Red Hat is already a contributor. If successful, it is an impressive achievement of Sun and Oracle, yet the route taken there is perhaps not applicable to the general open source project: Java grew to its current level of importance as a proprietary product, and IBM’s abandonment of Apache Harmony seems to have been the result of some kind of non-public negotiations with Oracle. This “brute force” strategy is simply not available to most open source projects aspiring to reach the “XtraLarge” category.

By comparing the relative investment of Red Hat and Novell into the development of Linux, it was shown that both the largest and second largest Linux vendor clearly benefit from sharing development cost by collaborative development. Red Hat is the biggest Linux developer by providing 12% of the development effort, but having then in proportion a much larger, 62% market share. This indicates that the leverage Red Hat gets from the collaborative development of Linux is roughly Leverage = 5×. For Novell, the levarage is almost as significant, with 7.6% of development effort, 29% market share, yielding a roughly 4x leverage factor.

It was further observed that if Linux had been developed as a single vendor effort by Red Hat alone, we can see that the engineering effort would probably be about 10 times smaller than the total effort by the whole Linux community is today. This seems to be in harmony with the previous observation that the largest single vendor projects are roughly 10 times smaller than the “XtraLarge” foundation governed projects.

From these results it follows as an obvious recommendation that vendors participating in open source development and business, should look into participating in collaborative community developed projects – where the standard and familiar governance form is a non-profit foundation. If a vendor is currently in control of an open source project, it should explore the option of transferring the project to an existing foundation, or alternatively creating its own foundation for it. Since the original vendor is always the strongest candidate to become the leading vendor also in a collaboratively developed project, the vendor could, as a rule of thumb, expect this strategy – if properly executed – to result in a 10x growth in the project and product, but also 10x larger addressable market, of which the vendor can expect to capture 50% or more as its own market share.

Photo of Henrik Ingo

Henrik Ingo


Henrik is a Solution Architect at MongoDB. Prior to MongoDB he worked at MySQL, Sun and MariaDB as a MySQL and MySQL Cluster expert and at Nokia as Senior Performance Architect. He is and has been active in many open source projects and is the author of “Open Life: The Philosophy of Open Source” ( a book on open source community ethics and business models.