Open Clouds: Beyond Open Code

Open source is a key ingredient in open clouds. But openness in a cloud requires more than just code that's under an open source license. In this post, we examine three open characteristics that are closely related to open source but don't automatically flow from it.

Historically, there's probably been too much attention paid to the details of open source licenses as opposed to the communities associated with bringing the code into being and using it. Certainly, licenses are important for defending against legal threats and in determining how an open source project can be combined with other projects. But without a viable, independent community, it's hard for an open cloud to realize the collaborative potential of open source. Delivering maximum innovation means having the right structures and organization in place to fully leverage the open source development model.

There's no single approach to fostering communities. The best approach in any given case to engaging with and governing a community will depend on the nature of the project. Who is contributing? What are the project's goals? What business or licensing constraints are there? These and many other factors will affect governance structure, as well as copyright, trademark and licensing decisions.

Red Hat has a long history of engaging with, fostering and contributing to many different types of communities. It brings this experience to the wide variety of upstream cloud projects, both those in which it plays a significant management role and those in which its involvement is primarily limited to contributing code.

It's also important for an open cloud to be based on open standards, or protocols and formats that are moving toward standardization. This is not a statement about needing to have “official” standards blessed by standards organizations. It's reasonable to expect that those will come about over time with various degrees of success and acceptance. But the history of technology standardization is one of trailing innovation, not leading it.

More important, especially in the near term, are approaches to interoperability that aren't under the control of individual vendors and that aren't tied to specific platforms. This frees protocols and formats from the constraints and limitations that come from being tied to a single vendor's business approach and product roadmap—even if those protocols or formats are nominally standards. The office document format disputes of last decade provide an illustrative example.

An important side effect of this approach is that it allows the API specification to evolve beyond implementation constraints. This creates the opportunity for communities and organizations to develop variants that meet their individual technical and commercial requirements. Perhaps one community values a feature-rich implementation, while another wants something that is simple—but lightning fast. If an API is forced to be in lockstep with one specific implementation of that API, only one set of tradeoffs are possible. Even if those tradeoffs are made out in the open as part of a process in which all stakeholders have a say, a singular result has to be arrived at. (Or, worse, the implementation ends up catering to so many parties that it ultimately doesn't satisfy anyone.)

If the specification and implementation are independent, on the other hand, there's a lot more flexibility to tailor code to the needs of different constituencies. It also enables and even encourages competing implementations, helping to push forward innovation. A good example of separating specification and implementation is the AMQP messaging protocol, an open standard for high-performance messaging that was initially driven by end users in the financial industry. It has since become the de facto standard in that industry and is implemented in commercially supported products from Red Hat (Red Hat Enterprise MRG Messaging) and others.

Open clouds also have to give you the freedom to use IP. Permission to use intellectual property, like copyrights and patents, must be granted in ways that make the technology open and accessible to the user. So-called “de facto standards,” which are often “standards” only insofar as they are promoted by a large vendor, can fail this test.

An open cloud has to be open across multiple dimensions. It has to be open source and—as we've discussed here—it needs to be associated with a viable and independent community; it has to offer the freedom to use IP; and it must be based on open standards.

In our final post of this open cloud-focused series, we'll take a deeper look at the three remaining essential characteristics of an open cloud: deployable on the infrastructure of your choice, an open API that's pluggable and extensible and enables portability across heterogeneous clouds.