OpenStack: balancing control and community

“the trends appear to be moving away from control and back toward community and collaborative development, which is why The 451 Group has advised that established vendors that rely on controlling open source development projects need to evaluate how they might be able to transition to more collaborative development practices and permissive licensing”
The 451 Group: Control and Community, November 2010

Shifting from control to community is not easy. Recent weeks have provided a number of examples of how the demand for collaborative development from the community can outpace corporate strategy.

A prime example would be the reaction to Google’s decision to withhold the code for Honeycomb until it deems it to be ready for wider distribution.

While Eric Raymond had cautioned against over-reacting to this news, Stephen Walli meanwhile also provided a timely reminder of retaining too much control can be damaging, specifically how it played a part in the decline of the Symbian Foundation.

If that wasn’t enough, Rick Clark also published his concerns about the OpenStack project and whether Rackspace has overstepped the mark in trying to control the project rather than influence it.

OpenStack is a benchmark in the shift away from control seen in the past few years, since the project was itself born out of a desire to shift the balance towards community-led development.

As we wrote in Control and Community:

“NASA… was formerly using Eucalyptus’ open source cloud platform, but in July created the alternative OpenStack project with Rackspace following a disagreement with Eucalyptus. The exact nature of that disagreement is itself a matter of dispute, but it is clear that it was related to the copyright attribution agreement used by Eucalyptus for external contributions to ensure that it was in a position to continue its open core licensing approach. It is no coincidence that the OpenStack project involves distributed copyright ownership and a non-copyleft license, designed to ensure that the core software will remain open source while providing all participants with equal opportunities to create closed source derivatives and complementary products and services.”

Quite how equal the opportunities for participants are was drawn into question by Rackspace’s recent acquisition of Anso Labs and the launch of its Cloud Builders business providing support and services for OpenStack deployments.

While this was unsettling for some it should not have been a surprise as Rackspace had made no secret of its desire to explore commercial support and services revenue opportunities, although it had stated that it has no desire to sell closed source variants.

As we wrote in July 2010:

“The vendor says it does not plan any commercial licensing or products from OpenStack. Its main focus is making cloud computing easier to consume and repeat, although it is anticipating that users will deploy the software on-premises to create their own on-ramp to the Rackspace cloud and is considering providing commercial support for on-premises implementations.”

Even so, the acquisition of Anso gave cause for concern. As Glyn Moody noted:

“Anso Labs held one of the four seats on the OpenStack governance board and three of the nine seats on the project oversight committee. The purchase of Anso by Rackspace means that Rackspace now dominate OpenStack’s governance, three to one, and project oversight, eight to one; the “one” in both cases being Citrix.”

And it is the governance of the project, rather than product or licensing plans, that have raised concern. Specifically, as Rick Clark explains:

“Basically, Rackspace made governance changes without talking to the development community or the sitting governance board. This is extremely problematic for the health of the project… The sad thing here, is that the governing body would have probably approved it with only minor changes. The changes are for the most part good, but the process shows a serious flaw in Rackspace’s thinking.”

As noted above, OpenStack was specifically designed to be more open than the alternative and the organisations behind it specifically chose distributed copyright ownership and a non-copyleft license, as well as a promise of openness in order to shift the balance away from vendor control towards community.

In the context of the wider shift away from control it is interesting to note that these steps are not considered enough and that the call has gone out for even less vendor influence and the creation of a non-profit foundation.

While it is tempting to suggest that Rackspace was not open enough in creating the OpenStack project, another viewpoint might suggest that the result of any level of openness is the demand from the community for more.

It is too easy to assume that in the balancing act between control and community the demand for control is exclusive to the vendor. The vendor is in a privileged position, and must recognise this and act accordingly.

However, we must also recognise that the community is often also seeking control, albeit with the aim of sharing that control between collaborating participants.

The balance between control and community is not simply a matter of balancing between the vendor and developers/users, but between all participants in any collaborative initiative.