←back to Articles

Introducing the Open Cloud Principles (OCP)

This content is 15 years old and may not reflect reality today nor the author’s current opinion. Please keep its age in mind as you read it.

In light of the rapidly increasing (and at times questionable) use of the term “Open Cloud” I hereby propose the following (draft) set of principles, inspired by the Open Source Initiative (OSI) with their Open Source Definition (OSD).

I would be interested to hear any feedback people have with a view to reaching a community consensus for what constitutes “Open Cloud” (in the same way that we have had clear guidelines for what constitutes “Open Source” for many years). You can do so in reply to this post, on the document’s talk page or by being bold and editing directly – if I don’t hear from you I’ll assume you’re satisfied.

Examples of uses today include:

For the latest version of the document please refer to http://www.opencloudinitiative.org/principles

Open Cloud Principles (OCP)

Overview
In order to stem the abuse of the term “Open Cloud” the community is forming a set of principles which should be met by any entity that wishes to use it, similar in spirit to the OSI‘s Open Source Definition for free software licenses.
Principles

  • No Barriers to Entry: There must be no obstacles in the path of an entity that make it difficult to enter. For example, membership fees, disproportionate capital expenditure relative to operational expenditure or dependencies on non-compliant products.
  • Rationale: Open Cloud offerings should be available to the maximum number and diversity of persons and groups. Competition must not be restricted.
  • No Barriers to Exit: There must be no obstacles in the path of an entity that make it difficult to leave. For example, a user must be able to obtain their data in a utile machine-readable form on a self-service basis.
  • Rationale: Obstacles that prevent entites from abandoning one offering for another reduce competition, which must not be restricted. If the barriers of exit are significant; a firm may be forced to continue competing in a market, as the costs of leaving may be higher than those incurred if they continue competing in the market.
  • No Discrimination: There must be no discrimination, including against any person or group of persons or specific field of endeavor. For example, it may not restrict the program from being used in certain countries, select certain people, by a commercial endeavour, or from being used for genetic research.
  • Rationale: All users should be allowed to participate without arbitrary screening.
  • Note: Some countries, including the United States, have export restrictions for certain types of products. An OCP-conformant product may warn users of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself.
  • Interoperability: Where an appropriate standard exists for a given function it must be used rather than a proprietary alternative. Standards themselves must be clean and minimalist so as to be easily implemented and consumed. For example, if there is a suitable existing standard for single sign on than it must be used by default, although including support for alternative interfaces is permissible.
  • Rationale: Standards foster interoperability and competition giving rise to a fairer marketplace. The absence of standards and to a lesser extent, complex standards, have the opposite effect.
  • Licensing Freedom: Any material that is conveyed to users must be done so under a free license; approved by the Open Source Initiative (OSI) based on their Open Source Definition (OSD) in the case of software and Creative Commons licenses (except NonCommercial and/or NoDerivatives versions) for everything else.
  • Rationale: Free licenses impose no significant legal restriction relative to people’s freedom to use, redistribute, and produce modified versions of and works derived from the content.
  • Technological Neutrality: No provision of any license or agreement may be predicated on any individual technology or style of interface. For example, it may not require that network clients run a certain operating system or be written in a certain programming language.
  • Rationale: Such restrictions limit the utility of the solution and freedom of the user by preventing them from using their preferred solution.
  • Transparency: All related processes should be transparent and subject to public scrutiny from inception. Feedback from stakeholders should be solicited and incorporated with a view to reaching a community consensus. Conflicts of interest must be disclosed and should be further mitigated.
  • Rationale: Transparency implies openness, communication, and accountability and prevents unfairly advantaging or disadvantaging certain parties.

Acknowledgements

See also