Call me a bore, but Open Source Governance models would be my “Specialist Subject” on a quiz show. It’s not that I have studied Open Source Governance, it’s more that I have lived it. A s a member of the Board of Directors of Eclipse I worked extensively with both Skip McGaughey who originally set up Eclipse as an entity inside IBM, and with Mike Milinkovich who took it over as an independent entity, and I know the pain that the originating organization has to go through to let go of its baby, and the pain that an independent director goes through to finally wrest the baby from its parent’s grasp, and the benefits to the originating organization and to the community at large when it all happens. I also know that Rackspace has gone through none of that pain in setting up OpenStack, it has got the OpenStack governance model spectacularly wrong, and as a result the whole initiative is in peril.
The OpenStack Governance Document bears an uncanny resemblance to George Orwell’s Animal Farm. You may remember that various animals got together to throw out the humans with the slogan “All Animals are Equal”, but that over time the slogan migrated to “All Animals Are Equal, but some are More Equal than Others” as the Pigs gained control and became indistinguishable from the humans they threw out. OpenStack was created with a similar sentiment: let’s throw out Eucalyptus and create a community programme where all contributors are equal. What has emerged in the governance model is “All Contributors are Equal, but Rackspace is more equal than others”. All the key positions, and a majority on the decision-making bodies are reserved for Rackspace. Rackspace, like the Pigs in Animal Farm, has subverted the revolution.
You can see this mindset clearest by comparing the language of the Rackspace governance model to those of Eclipse.
- Eclipse:
- There is no reference to IBM or to any other vendor in any of the half dozen founding documents of Eclipse.
- Line 1 of Section 1.1 of Article 1 of the Bylaws says “The Eclipse technology is a vendor-neutral, open development platform “
- OpenStack:
- Rackspace is mentioned 12 times in the OpenStack Governance Document. No other vendor is mentioned.
- First Key Principle says “The community will be involved in the design process. The community will have representation throughout the governance structure. ” So if the Community has “Representation”, who has Control. The answer is Rackspace, who in truly Orwellian double-speak are not part of the Community.
You can see how much control-freakery is embodied in this document by counting the number of Rackspace appointees on the OpenStack Architecture Board. Not only are the Chair and the Chief Architect appointed directly by Rackspace, but 3 additional members are appointed directly by Rackspace, meaning that the 4 independently-elected Community members (even if they could agree) could never form a majority.
It should be fairly obvious that in a collaborative program of this nature, where you wish competitors to collaborate on issues of a common interest, it is incredibly stupid to bias the governance model to one competitor over any other. It simply isn’t safe for competitors to collaborate under these circumstances. These were the issues we went through at Eclipse in ensuring it was safe for IBM and HP and Oracle to sit around the table together for the benefit of the industry. That’s why you end up with vendor-neutral governance.
However, there are two other reasons why the OpenStack governance model is incredibly stupid.
1) There is actually no need to gain control explicitly. You control by contribution. Since Rackspace contributes most it will gain most control. In fact, in Eclipse we went through a whole raft of measures to ensure that IBM didn’t get the control it deserved for the level of contribution it was making. This sounds perverse, but Eclipse structures are set up to preferentially over-represent smaller contributors. Committers (i.e. active developers) are given only one vote per company in determining community representation. This means that even if IBM has 200 developers, their community representation is the same as one individual working from home on his own account. What’s more, once a company reaches a certain threshold of contribution (around 7 developers and some project leadership roles) it gets exactly the same level of corporate input to the governance process as IBM who may have those 200 developers and run a dozen projects. Despite these rules, IBM was able to exert enough control in the detailed project substructure inside Eclipse to enure its objectives were met.
2) Rackspace doesn’t actually need control to satisfy its business objectives. IBM, certainly at the time it set up Eclipse, didn’t make money out of tools. Their role was and still is to sell platforms, notably WebSphere. All IBM actually needs is for something like Eclipse to exist and to exert enough control to ensure it meets the needs of WebSphere. The same is true of Rackspace. It will never sell and make money out of OpenStack. All it needs is to make sure the project is successful and retain enough control over the project to ensure its own needs are met. If someone else wants to take the project in additional areas that should be fine. Over time there need be proportionally very few Rackspace developers left on the project.
So our suggestion to OpenStack is to take their Governance model, rip it up and start again. And this time make sure that not only the Pigs write it, but all the animals get a look in too.
I couldn’t agree more! I was at the launch for Openstack at OSCON this year and it 100% looked like a Rackspace initiative. They mentioned NASA once or twice but never had a logo of Peer1, Softlayer, etc or any other company that’s participating.
Your animal farm line could have been stated any better.
Hi Mike,
Let’s get this out of the way: I am a contractor for Rackspace. My opinion here is my own, and in no way should my opinion by construed as representing Rackspace the company’s point of view.
As a contributor to OpenStack projects, I actually do agree with much of what you said here about the governance model (though I think you could have been more constructive about the way you said it…).
It is true that Rackspace has structured things this way, and from what the governance rules look like, it seems that Rackspace is indeed attempting to have their cake and it eat too; in other words, to benefit from the models of open source collaboration and yet not comply with the maxim of “your level of contribution dictates your ability to direct/influence the project” that underpins most open source projects. So, I agree with you on that.
However, let me point out two things that may not be evident if the only view of OpenStack you have is looking at the wiki page on the Governance Board 🙂
1) The contributors to OpenStack are indeed varied, and it is indeed *their contributions* that have dictated the direction of OpenStack subprojects.
Ewan Mellor from Citrix/Xen has contributed large patches for getting Xen working properly. Likewise, Chiradeep Vittal from Cloud.com has contributed patched to get Microsoft Hyper-V support into the OpenStack Nova project. A team from NASA contributes patches to OpenStack Nova on a daily basis. Why? Because they deploy a version of it in production for their clients and need fixes and features done. Do Rackspace employees and contractors contribute code? Yep. There are 5 or 6 of us who do regularly. The priority of stuff we work on is set by folks on “the inside” who need certain features or fixes most urgently.
So, regardless of the governance board or architecture board or whatever, I think that if you showed up on IRC or the mailing lists or checked out the project on Launchpad, I think you’d find that OpenStack is pretty similar to many open source projects in that the direction of the projects are determined by the contributions made. 🙂
2) It’s still *really* early, Mike! 🙂 OpenStack is a work in progress. Will mistakes be made early on like this? Yep. Will mistakes be corrected? Yep.
So, your post is appreciated and I’m sure a number of people are already digesting this inside Rackspace. Give them a few weeks to see if any changes will be announced.
Cheers!
jay
Hello.
I am FOSS freelancer who is interested in Openstack.
While i agree with some of your points, i would like to state that while license is making it free, i am not worried.
Free/Open Source Software is world of ‘benevolent dictators’. If you think that dictator of the project is somehow wrong, you just FORK the software. If you do not want to serve users and manage the development process, why don’t you let the benevolent dictator do it?
I can understand that Rackspace wants to make sure the project will not fail. You can always branch it as “FreeStack”, if you think you can better serve users and/or developers.
I’m glad this post has generated some feedback, and yes to an extent I was “shooting from the hip”, but I stand by what I said and the manner in which I said it. The tone came from frustration, given this initiative could be of immense benefit to the industry, because it offers a real opportunity to drive interoperability at this layer.
Jay, I hear what you are saying about the diversity of contribution that is emerging, but that means the Governance document makes even less sense. I smell an internal disconnect between the Rackspace development team and the legal department and/or senior management about the process of Open Source. The Governance Model does matter because potential contributor/consumer companies also have legal departments and senior management, and investors to whom they owe a duty of care, and for this thing to fly everyone has to be on board. The story of the CPL to EPL transition at Eclipse is illuminating. It was a huge diversion and wasted a huge amount of effort, but it had to be done. It was all down to one line regarding patent rights which IBM Legal had “slipped into” the original CPL. Mike Rank and the legal team at HP drove the process, but they were acting in everyone’s interest.
David, whilst I agree you can fork the codebase, the problem is that once you fork you have to maintain not just the new codebase but the existing, which can become a major committment depending on the maturity of the codebase you are adopting. And then there is the problem of API. OpenStack is all about interoperability. If the codebases are divergent, real API-compatibility is very hard to maintain, and if you fork and want to maintain compatibility and still control your own destiny you need a collaborative API standard. A key reason why I believe in OpenStack is that I don’t believe API standards can now happen here, and the right way to do this is through a ubiquitously adopted implementation of the core function.
Nice write up. Rackspace is in the process of creating an independent foundation to manage the overall project and transitioning the governance model: http://wiki.openstack.org/Governance. Hopefully, the transition will go smoothly. It looks like the new governance model will address the issues that you raised here.
Hi Tom,
Thanks for updating me on this. I had a brief interaction with Jim Curry at the time of the original post, and I think he was amenable to what I said, and I’m glad that the organization has been able to take steps to address it. As things emerge I will hopefully be able to post additional commetary – and not so hostile this time. Actually it wasn’t hostility just disappointment.
Mike