Presenting "How to grow open source project 10x" at OSCON
2 weeks from now I'm giving a talk How to Grow Your Open Source Project 10x and Revenues 5x at OSCON (in Portland, Oregon). It is based on the article with the same title I published last year. The talk is scheduled to end a one day sub-track called IT Leaders Summit. I'm glad it is categorized as a business talk rather than community talk - things I write usually are problematic in that I typically cover both business and community and see them mostly as harmonious topics, whereas most other people see them as opposites.
I know many of those who have commented or retweeted on this article will be in Portland, so I hope you show up and give interesting comments during the talk!
Btw, I will also attend Community Leadership Summit the weekend preceding OSCON. It's a great unconference and I look forward to networking with all the community leaders there.
In preparation for the OSCON talk I did a little review and refresh of the underlying article, but there are only minor changes:
I learned that "The PHP Group" was never formally incorporated in any jurisdiction so I have moved it to the "Just a project" column. PHP does however have quite well defined membership and decision making process, making it work like most of the incorporated non-profits.
I made an effort to estimate the true size of OpenJDK developer community, but have so far failed to get even a round number that would be usable. The motivation for this is that I'm suspecting OpenJDK could be the first vendor-led project to break into XtraLarge magnitude so I'd like to know some numbers for it. The problem with OpenJDK is that the public Mercurial version control system only shows 50+ committers per month (OHLOH.net). Since we are talking Java here, I know for a fact there must be hundreds of developers at Oracle alone working on mundane bug fixing - but apparently all of this work is done in-house and not in public, so it is impossible to measure it without insider knowledge.
If you have knowledge of how many engineers work on Java (at Oracle, but also at IBM, Apple or Red Hat), I'm interested to know. For know, OpenJDK was left in the unknown column.
I also looked at 2 new projects: OpenStack and Chromium. This was triggered by openstack.org claiming to have 1171 contributors from 82 companies, and an lwn.net article citing 700+ all time committers for Chromium. Both numbers indicated these vendor led projects would be deserving a spot in the XtraLarge category.
It turns out however that the number of active Chromium developers (as reported by OHLOH) per month is steadily growing but still only at 300. (For the past year it is already 600.) While this makes Chromium larger than any of the other "Large" projects in the study, it is still not quite up to the level of the "XtraLarge" project, but if it keeps its momentum it may grow there in a year or two.
It is still unclear to me what the 1171 OpenStack contributors are contributing, but both OHLOH and personal friends confirm that OpenStack doesn't have that many code committers. OHLOH lists various OpenStack components as having maybe 100+ code committers over past 12 months and about 50+ per month. For a project still in its first year, that is already an impressive number!
The OpenStack governance model turns out to be rather interesting in the context of my study. When it was announced by Rackspace and NASA a year ago it was initially incorporated as a Rackspace owned subsidiary OpenStack LLC. The explanation was given that a for-profit entity was faster to incorporate than a non-profit one (which is certainly true) and that the intent was to make OpenStack a true community project. 12 months later OpenStack has indeed developed governance processes comparable to Apache, Eclipse and the other foundation projects, but technically OpenStack LLC (to the best of my knowledge) remains a Rackspace owned subsidiary.
If it was included into the essay, it would therefore have to remain in the vendor-led category. Assuming that OpenStack keeps growing with the current momentum, it will then be interesting to watch and learn what ingredients have made it grow past the "glass ceiling" that seems to have kept the classic vendor led projects like MySQL, Qt and JBoss from reaching their true potential. From a current observation of OpenStack we can list
- Lack of copyright assignment to a signle dominating vendor. Everyone is on equal footing and can - if they choose - combine OpenStack software with their own proprietary components without the need to pay another project participant a license fee.
- Open development process both in terms of code, mailing lists and bi-annual design conferences.
- Open governance process. While Rackspace has the right to appoint a few seats on the Policy Board, it does not control a majority of votes.
- Equal rules for usage of the OpenStack trademark. Also the openstack.org website is not a portal for Rackspace advertising.
The above setting seems to have been enough for other OpenStack stakeholders to join the project in masses.
The success of OpenStack building a developer community is particularly interesting when juxtaposed against the "incumbent" open source cloud solution Eucalyptus, that follows a more traditional vendor-led model with copyright assignment and tight control of trademarks and web properties of the product. The initiators of OpenStack made no secret of the fact that they started the project partially due to dissatisfaction with the Eucalyptus model, and timing wise it happened at a time when Eucalyptus was busy advocating its model. The rapid growth of a diverse developer community around OpenStack can almost fully be counted as a missed opportunity for Eucalyptus - wasted engineering resources at minimum, but also loss of mindshare. As a culmination of the shift in mindshare, Ubuntu Linux, early on the primary channel for Eucalyptus has now switched to supporting OpenStack as its primary cloud solution.
While it is great to witness a company that is able to create an efficient and not dysfunctional open source community around itself, I cannot help that a small part of me remains worried about how OpenStack LLC ended up. Those who participate in OpenStack seem to be rather happy with how the project operates, and indeed, to its form it is identical to how other non-profit projects operate. But as long as there remains a single owner of OpenStack LLC, technically, legally, they still have the ultimate say. Sun being acquired by Oracle taught us that even companies considered friendly to open source can change to hostile over night. Even if OpenStack today works great, how would the community handle it if one day a similar unwanted change of control in Rackspace was to happen?
My perspective perhaps differs from most others here. Some years ago I was personally involved in a situation where developers of a project had voted for an action to be taken, properly following the written governance rules of the project they were working on. But the CEO and Chairman of the company in control of the project simply refused to execute the decision (they would have needed to sign legal agreements on behalf of the company). The developers then had little choice but to accept the reality that the vendor in charge had the legal power to veto the governance rules of their project. From the looks of it, it doesn't seem Rackspace would ever have the motive to do something like that (even if one assumes a more hostile ownership or leadership at the company), I'm just pointing out that such things do sometimes happen, and personally I always prefer legal certainty and simplicity over "we don't think it will ever happen". (I'm pedantic, I'm an engineer.)
Since both of these projects fell short of reaching the XtraLarge category I haven't included them in the updated study at all. But I will be keeping an eye on them. They both have great momentum and may very well reach the XtraLarge level in a year or two. If so, they first of all constitute a counter-trend to the classic model of running successful open source projects via neutral and non-profit foundations. If they succeed they then also can serve as examples of vendor led projects that succeeded in creating communities comparable in size to Linux and the other foundation governed projects, examples from which others can learn to follow in their footsteps.
Even if the original message of my article was to emphasize that vendors retaining control of their projects categorically fail to reach their true potential, if a Rackspace or Google or even Oracle can demonstrate that they can bring together a thousand developers actively working on open source software - I will surely be the first to appreciate such an achievement!