Summary:

The latest OpenStack code release, dubbed Cactus, is now available and generally capable of running within enterprise data centers, but underlying the project’s progress are concerns over its true commitment to the open source ethos.

horse race

Open-source cloud computing project OpenStack unveiled the code for its “Cactus” release Friday, and while it’s full of enterprise-grade features, it should also help keep the Rackspace-led project from getting bogged down in concerns over whether Rackspace is forcing through its desires in what’s supposed to be a community process.

OpenStack members have been questioning Rackspace’s commitment to the traditional open source ethos because of its seemingly unilateral project leadership, but as long as the pace of innovation remains fast enough to make it worth sacrificing a bit of control in return for a better product, Rackspace should be able to walk the line between keeping control of the project and still maintaining its open source cachet. Cactus came just two and a half months after OpenStack’s “Bexar” release, which is a month faster than the time frame between “Austin,” OpenStack’s first code release, and Bexar.

However, if release cycles start dragging on, or if Rackspace clearly oversteps its bounds, there could be trouble in what has been largely a cloud success story thus far.

Concerns over the open-source nature of OpenStack emerged early in the year when Rackspace bought OpenStack governing member and NASA-cloud builder Anso Labs. This gave the hosting company a majority of seats on the project’s governance board. Rackspace Cloud President Lew Moorman adamantly denied any such motive behind the acquisition (in fact, it turned out to be a precursor to Rackspace’s Cloud Builders program). The company later rearranged the governance board makeup and voting process, and one of the components of that reorganization was to give a greater voice to the other big-name IT companies involved in OpenStack, including Cisco, Dell, Intel and Citrix. Any one of those companies arguably has enough influence to keep even project leader Rackspace in check.

However, the issue reared its ugly head again in late March when OpenStack Chief Architect Rick Clark left Rackspace (to take a job at Cisco, interestingly) and called out some of Rackspace’s decisions in a blog post. Among other things, Clark questioned Rackspace’s decisions to make the governing board changes without the approval of the current board, as well as its insistence on keeping OpenStack within Rackspace’s ultimate control instead of releasing to a foundation such as the Apache Software Foundation. Such a move, Clark wrote, would prove that Rackspace “understands that it doesn’t actually own the project, and it protects the project from management changes and changes of priorities at any one company.”

I asked OpenStack Policy Board Chairman Jonathan Bryce about these concerns earlier in the week. 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, which directly addressed the concerns raised around the time of the Anso Labs acquisition.

Further, Bryce explained that he sees the current OpenStack model as being an “extreme open method” for licensing code vs what would happen within a foundation. In essence, everyone who contributed code to OpenStack owns the copyright to that code and licenses for use in the OpenStack software, but Rackspace alone doesn’t have the power to move the code into a foundation. Moving OpenStack to a foundation would inevitably strip contributors owners of the copyright. Granted, many of those contributors might agree to giving up their copyright if the option were proposed, but Bryce said that will require buy-in from all contributors whose code has been included into the releases thus far. Rackspace might be the driving force behind OpenStack and ultimately control its purse strings, but it doesn’t own the code outright. For Cactus alone, Bryce said, the code-review team looked at about 5,000 submissions and included code from more than 100 developers.

Bryce also suggests that individuals concerned with openness within OpenStack analyze the evolution of the project. He noted that the project has grown organically from being a Rackspace-only venture to one with NASA as a co-leader to, now, a project with large numbers of individual developers and dozens of corporate partners. If Rackspace has a high level of control over OpenStack, it’s because it has put the majority of the resources into it since the beginning, Bryce said. However, the power structure is distributed with every new member. And the community is “growing and thriving more than any open source [project] I’ve seen in my life,” he added.

As I mentioned above, I think most people involved with and covering OpenStack will overlook any shortcomings in the project’s adherence to true open source principles as long as the new features keep coming fast and furiously. The reason is that there’s a weighing of interests involved: foundations are certainly are open, but too much openness without a strong leader can result in infighting and very long release cycles. For example, more than a year passed between the 0.20 and 0.21 releases of the Apache Hadoop Distributed File System.

Right now, however, the OpenStack code is advancing fast enough that it might outweigh members’ desires for a foundation-like experience. In a shorter release cycle than usual, Bryce said the Cactus release incorporates about 40 new features across the Compute and Object Storage components, including support for all major hypervisors, live-migration capabilities for KVM virtual machines and “multi-cluster region support,” which lets users set up failover nodes and geographically distributed availability zones. With Cactus, in fact, OpenStack release is pretty much ready for primetime, but Bryce cautioned that “if you want to run something that is tens of thousands of machines … I would say there still are some other things that need to get into the code base.” Those capabilities are priorities for the next release, he added.

At that point, OpenStack will finally be ready to start delivering on its promise as an alternative cloud computing platform that can compete with proprietary options such as Amazon Web Services and Microsoft Windows Azure. For many OpenStack members, the possibility of chipping away at Amazon’s cloud dominance is what makes all the whole process, faults included, worthwhile.

Image courtesy of Peter Evans.

Comments have been disabled for this post