Leong: "OpenStack has drawn a large vendor community, which makes source code contributions, but many exclusively contribute vendor-specific code, such as drivers for their own hardware and resist the creation of interoperability inducing common frameworks that would facilitate switching between vendors. Vendor interests also heavily affect the determination of what features to add and how to implement them, since every vendor wants each feature to work best with its own products."
OpenStack: Bryce says contributions from a growing cadre of member organizations make the project stronger. The alternative would be to have an open source project backed by a single company or a small number of companies controlling it, which Bryce says would not be ideal. Companies are using the OpenStack code to create products and services, so they have an interest in encouraging the source code to be strong, he argues. "We want something that will be around for the long term that will have long-term support, not a product from a single company," he says. Plus, new additions to the OpenStack code that are contributed by member companies are optional for OpenStack to install. The newest Folsom release, for example, adds block storage and virtual networking features, but the code still works without implementing those.
Leong: "Since the vendors involved want to drive business through the OpenStack ecosystem, there is considerable incentive for proprietary lock-in. There is no significant difference in lock-in for customers adopting OpenStack than for those customers adopting proprietary CMPs. In fact, as OpenStack is not a widely-adopted standard, the number of solution providers is highly limited (whether in hardware, software, or services), restricting overall customer choice far more than adopting VMware's vCloud. Nor are there multiple implementations of an OpenStack CMP. On a practical level, the AWS API has the broadest ecosystem, including multiple CMPs (both open source and proprietary) offering compatible implementations."
OpenStack: While there may be many companies using OpenStack and creating their own products and services based on the code, Bryce says each company has a lowest common denominator of using the same base-level code, which will inherently allow for interoperability compared to if vendors had each created their own cloud management platform. The OpenStack Foundation hopes to control fragmentation by creating rules to ensure that products and services that use the OpenStack brand name include specific components to encourage interoperability. One of the recent goals of the code development within OpenStack has been around improving ease of use, and Collier says he expects a healthy debate about how much focus there should be on management and upgradeability within the code at the upcoming OpenStack foundation.
Leong: "The overall project difficulties are causing many vendors to re-evaluate their OpenStack-related strategies. Vendors, as well as OpenStack customers, often say very different things in public about OpenStack than they do in private. The dissonance between public and private statements stems from customers' desire to associate themselves with a project hyped as the future of the cloud. However, their reservations about the project's ability to produce a stable product within a commercially meaningful time frame run very deep and consequently, many vendors are unwilling to fully commit significant engineering resources to the project at present."
Sign up for Computerworld eNewsletters.