OpenStack: Commercial, open source aren't exclusive
Can a commercial vendor lead a project as openly as a foundation?
OpenStack is, by anyone's assessment, a very successful open source project. With 1197 participants (at least 250 of them code contributors) from 92 companies and more participation announced all of the time, OpenStack has grown far faster than even it's founders' expectations.
OpenStack has the attributes that make open source developers happy: copyrights are kept by the contributors, the project is under the Apache Software License (ASL) 2.0, and the project is governed by a board with eight out of twelve elected seats. As the project celebrates its one-year anniversary this week at OSCON, it has become the very definition of what a good open source project should be.
And it's all run by a for-profit corporation: OpenStack, LLC, a wholly-owned subsidiary of Rackspace Hosting.
Historically, the open source community has been wary of projects that have been corporate-led, and that same history has often validated those fears. Sun Microsystems's acquisition by Oracle and the ongoing problems that have ensued for some of the open source projects that Sun once led (OpenOffice.org, Hudson, MySQL, and Java) have justified the notion that when a for-profit corporate entity has control of an open source project has control over a free or open source software project, you're just asking for trouble. Better, many argue, to contribute code and governance responsibilities to a non-profit foundation, where ultimately the code and other project works will be protected from being dominated by any one vendor.
OpenStack's success and the behavior of its Rackspace parent definitely belie this notion, and raises an interesting question: can a single vendor successfully start and then lead an open source project? As far as OpenStack is concerned, all signs seem to be pointing to yes.
I spoke with Jonathan Bryce, founder of The Rackspace Cloud and member of the OpenStack Project Policy Board (PPB), at OSCON this week, and right from the starting gate asked him the question that had been murmuring around the conference floor: why wasn't OpenStack moving towards a non-profit foundation governance model?
Bryce has a fair bit of skepticism about the purity of the foundation model. His immediate answer was that "most foundations are vendor-driven," what with corporate members holding board positions and providing resources and time to such organizations. Because of this corporate influence, "foundations are no guarantee there will be a meritocracy" within a project, Bryce said.
Bryce's point has some traction, particularly when looking at 501(c)(6) non-profit foundations, which is US tax code for trade organizations that are primarily looking out for the benefit of their corporate members. The Linux Foundation and the Eclipse Foundation are examples of 501(c)(6) foundations. But all foundations are not created equally. 501(c)(3) non-profits are more geared towards the public good. The Apache Software Foundation and Free Software Foundation fall into the 501(c)(3) category. Both organization types include corporate members, but it's a little harder to argue that corporate interests might dominate the direction of 501(c)(3)-type foundation.
For OpenStack, there doesn't seem to be any big incentive on the part of its members or Rackspace to shift to a foundation, mostly because of the reasons outlined above.
"We don't own the copyright," Bryce explained, "[contributors] decide who owns the code." With all contributions licensed under ASL 2.0, there's not a huge potential for Rackspace to hijack the OpenStack project.
"There are natural limitations in place," Bryce argued. "It would be very difficult to take [OpenStack] in a direction the community wants to go."
The governance model of OpenStack bears this out as well. The projects within OpenStack are all self-governed, with the PPB only handling meta-issues like the release process and software integration. The PPB also manages bug tracking and organizing the regular design summits for the broader OpenStack project. Code contributions and direction, Bryce emphasized, are only managed by the project communities themselves.
As for the PPB itself, only four of the twelve board positions are appointed by Rackspace (and currently only two of those seats are held by Rackspace employees), with the other eight positions elected by the community at large.
It should be noted that this current arrangement was itself the source of a little controversy this Spring, when Rackspace was accused of unilaterally altering the parameters of the PPB by departing Rackspace employee Rick Clark. Clark argued in March that even though he believed that changes in OpenStack governance model were positive, the closed way in which they were enacted did little to show the community that at the end of the day, it was Rackspace asserting direct control over the OpenStack in the way they saw fit.
Bryce countered in an April interview with GigaOM:
"Regarding the board changes, Bryce said, Clark's post wasn't entirely accurate because the changes actually were decided through a variety of public, private and hybrid forums, as opposed to unilaterally and behind closed doors. There are reasons a company wouldn't want certain governance issues discussed in the open, he said, without elaborating on what those might be. And whatever the process, Bryce added, the result was a more open voting process and inclusive board..."
Bryce acknowledged that the bad acting on the part of Oracle has certainly raised legitimate concerns about corporate leadership of open source projects. But he is confident that Rackspace will not, indeed cannot, become such a player. To date, the explosive community growth of the OpenStack projects supports that belief. When OpenStack was first launched a year ago, Bryce believed that it would be 12-18 months before outside corporations joined the project. Instead, it happened in five months, and those corporations are making significant contributions. Bryce cited Japanese telecom giant NTT for their efforts in IPv6 and live migration, as an example.
The numbers are also growing in the developer count, too. At launch, there were 20 coders on the project, and nine months later, there were 250 and growing.
"Our long-term goal is something that will be a lot bigger than Rackspace," Bryce said.
Moving to a foundation model, as appealing as that might be for some community members, would also be logistically very difficult to implement. Recall that while contributors grant OpenStack a perpetual copyright license to use their code, that's not copyright ownership. So, to move to a foundation that would presumably own the copyrights for all OpenStack code, all of the individual contributors would have to give up their copyright ownership.
Bryce clearly is not impressed with the idea that a foundation is ultimately the best goal for every open source project, and he includes OpenStack in that group of exceptions. And there is very little in the history of OpenStack to date that would suggest that Rackspace is being anything less than open. The Spring 2011 governance change may or may not have been a unilateral fix, but even if it was, even critics of the move agree it was a change for the better.
There is nothing that says that a corporation can't effectively run an open source project and run it openly. In fact, instead of constantly suspecting the motives of all corporate participation, perhaps we should examine each one on a case-by-case basis. Commercial interest and participation should be something that should be encouraged in open source, because otherwise it sets up the idea that somehow corporations and open source can never really work. (An idea that Microsoft, for example, is still pushing.)
The demonstration that open source can be compatible with and even flourish in a for-profit business is a very big deal. If OpenStack can succeed without a foundation, and there's no reason to think it can't, then it could be a model to other corporate-led projects to follow and real proof that commercial and open source interests aren't mutually exclusive.