Much has been written about the importance of foundations versus single vendor controlled open source projects. Yet, there’s been too little focus on the gradual shift that often occurs between these two ends of the open source project spectrum. The OpenStack project is being asked to accelerate its transition into a foundation-led project, maybe a little too soon.
Rackspace struggles with control versus influence
The OpenStack open source project that aims to deliver “a massively scalable cloud operating system”. OpenStack was launched with great fanfare 8 months ago, with claims of over 50 organizations, including Rackspace, NASA, Dell, Cisco and Canonical, participating in the project.
However, Rick Clark, a Rackspace lead on the OpenStack project, raised some eyebrows when he announced his departure from Rackspace to join Cisco. Clark has many good things to say about Rackspace and the OpenStack project itself, but felt that the Cisco opportunity was too good to pass up. However, he goes on to explain a degree of frustration with the way the OpenStack is being managed.
Clark states his view “that Rackspace is trying to control OpenStack rather than influence it.” Clark provides some examples of Rackspace making decisions that impact the OpenStack project behind closed doors. And while Clark doesn’t necessarily disagree with the end result of these Rackspace decisions, his concern centers on the fact that Rackspace has the ability to make these decisions without community input in the first place. While Rackspace is doing right by the OpenStack project today, Clark asks, “What happens if Rackspace is under new management, say Oracle, for example?”
Clark’s proposes that Rackspace put the OpenStack project under the control of an open source foundation. Rackspace would lose control over the project, but would more than likely retain its influence considering the amount of code and ongoing investment Rackspace would bring to the community.
The notion of influence versus control has been previously discussed by Simon Phipps, ex-chief open source officer at Sun. Simon writes:
In my experience, attempting to retain control of a project you’re starting or hosting leads to mistrust, contention and a rules-based focus that diminishes your reputation. Relaxing control will lead to the community innovating and growing in ways you’ve not anticipated, as well as enhancing your reputation. As I’ve frequently said (although less frequently been heeded): trade control for influence, because in a meshed society control gets marginalized while influence delivers success.
It’s interesting to note that Simon admits that his advice isn’t always easy for vendors to follow. Even Sun, during Simon’s time as chief open source officer, frequently opted for control over influence. This was especially true in the early stages of an open source project led by Sun.
Transferring control to a foundation, when the time is right
Like many, I’m a supporter of open source foundations. However, one must consider where the project is in its lifecycle before arguing that its prospects would be brighter within a foundation than elsewhere.
In some cases, the success of an open source project is un-related to whether a single vendor or a multitude of vendors control the project. Projects such as MySQL and Spring fall into this category.
In other cases, a foundation is the right place for an open source project, but when the project control is handed over to a foundation is an important question. For instance, control of Drupal was not handed over to the Drupal Foundation until five years after its founding. As another example, control of WordPress didn’t move to a foundation for nearly seven years after the project began.
The pressure for Rackspace to cede control over OpenStack to a foundation appears to be premature. Dell’s Rob Hirschfeld, an OpenStack community member, writes
While companies like Dell (my employer), NTT, Citrix, Cisco (Rick’s employer), and Microsoft are clearly investing in OpenStack, none have yet achieved NASA or Rackspace’s level of technical commitment.
The challenge for Rackspace is to expand the OpenStack market and ecosystem so that partners are motivated to jump in more and more quickly. If my experiences inside Dell are indicative of the broader community, Rackspace’s leadership makes it much easier for partners to increase their own commitment. Like teaching my daughter to ride her bike, she needed to know that I was running next to her before she would pedal hard enough to balance by herself.
Few open source projects succeed in attracting third party vendor contributions if the project doesn’t appear to be evolving at a rapid enough pace. Third party vendors want to know that they’re contributing to a project that will eventually, if not already, become the leading project in the particular product category. Who controls the community is an important, but second order question for third party vendors considering contributions.
Rackspace should be afforded the time to grow the feature/function competitiveness of OpenStack and the quantity of third party contributions before being prematurely forced down the path towards a foundation.