In the wake of last week’s well attended OpenStack Summit, there has been much discussion of the state of the project. As is typical, this ranges from heated criticism of the project’s community, governance or technology to grandiose claims regarding its trajectory and marketplace traction. And as is typical, the truth lies somewhere in between.
Critics of the project suggesting that it has real organizational issues and engineering shortcomings to address are correct. As are proponents arguing that the project’s momentum is accelerating, both via additions to its community and by the lack thereof from competitive projects and products. The former is, in all probability, the more important of the two developments. Engineering quality is important, but as we tell all of our clients, it has become overvalued in many technology industry contexts. With the right resources, quality of implementation is – usually – a solvable problem. The lack of a community, and attendant interest, is much less tractable. More often than not, the largest community wins.
In the case of OpenStack, however, this can be considered a positive for the project only as long as there is one OpenStack community. It is unclear that this will remain the case moving forward.
Historically, some of the most important and highest profile platform technologies – Linux being the most obvious example – have been reciprocally licensed. In practical terms, this requires vendors distributing the codebase to make any modifications to it available under precisely the same terms as the original code. OpenStack, like Cloud Foundry, Hadoop and other younger projects, is permissively licensed. Unlike reciprocally licensed assets, then, distributors of OpenStack technologies are not required to make any of their bugfixes, feature upgrades or otherwise available under the same terms, or indeed available at all.
Though not required by the license, the overwhelming majority of code is contributed back to the project, because there is little commercial incentive to heavily differentiate from OpenStack. There are, however, commercial incentives to differentiate in certain areas. Which could, over the longer term, lead to fragmentation within the OpenStack community.
To combat this, the OpenStack Foundation and its Board of Directors must make two difficult decisions regarding compatibility.
First, it needs to answer a currently existential question regarding OpenStack: specifically, what is it, exactly? What constitutes an OpenStack instance? One interpretation is that an OpenStack instance is one that has implemented Nova and Swift, the compute and object storage components within OpenStack. What of vendors or customers who have found Swift wanting, and turned to Ceph or RiakCS, then, as an alternative? Are they not OpenStack? Further, how might the definition of what constitutes an OpenStack project evolve over time? Over what timeframe, for example, might customers have to implement Quantum (networking), Keystone (identity), Heat (orchestration) to be considered ‘OpenStack?’
Answering this question will involve difficult decisions for the OpenStack project, because opinions on the answer are likely to vary depending on the nature of existing implementations and the larger strategies they reflect. Because much of OpenStack’s value to customers – and the marketing that underpins it – lies in its avoidance of lock-in, however, answering this question is essential. A customer that cannot move with relative ease from one OpenStack cloud to another because the underlying storage substrates differ is, open source or no, effectively locked in.
The OpenStack Foundation could decline to take an aggressive position on this question, leaving it to the market to determine a solution. This would be a mistake, because as we’ve seen previously in questions of compatibility (e.g. Java), trademark is the most effective weapon to keeping vendors in line. OpenStack implementations that are denied the right to call themselves OpenStack as a result of a breach of interoperability guidelines are effectively dead products, and vendors know it. Given that the Foundation controls the trademark guidelines, then, it is the only institution with the power to address the question of what is OpenStack and what is not.
Assuming that the question of what foundational components are required versus optional in an OpenStack implementation can be answered to the market’s satisfaction, the second cause for concern lies in compatibility between the differing implementations of those foundational components. The nature of implementations, for instance, may introduce unintended, accidental incompatibilities. Consider that shipped distributions are likely to be based on older versions of the components than those hosted, which are frequently within a week or two of trunk. How then can a customer seeking to migrate workloads to and from public and private infrastructure be sure that they will run seamlessly in each environment?
This type of interoperability is by definition more complex, but it is not without historical precedent. As discussed previously in the context of Cloud Foundry, one approach the Foundation may wish to consider is Sun’s TCK (Technology Compatibility Kit) – should a given vendor’s implementation fail to pass a standard set of test harnesses, it would be denied the right to use the trademark. Indeed, this seems to be the direction that Cloud Foundry itself is following in an attempt to forestall questions of implementation compatibility.
Ultimately, the pride on display at the OpenStack Summit last week was well justified. The project has come a long way since its founding, when several of its now members declined to participate after examining the underlying technologies. But its future, as with any open source project, depends heavily on its community, which in turn is dependent on the Foundation keeping that community from fragmenting. The good news for OpenStack advocates is that there are indications the board understands the importance of these questions, and is working to address them. How effective they are at doing so is likely to be the single most important factor in determining the project’s future.
Disclosure: Multiple vendors involved in the OpenStack project, including Cisco, Cloudscaling, Dell, HP, IBM, Red Hat and are RedMonk customers. VMware, which is both a participant in the OpenStack community and a competitor to it, is a customer.
