DRAFT -  DRAFT -  DRAFT -  DRAFT -  DRAFT -  DRAFT - 

In the 1990s, OpenGL was developed as a portable open graphics library standard. The goal was to provide a cross-platform library that could enable developers to produce 3D graphics at real time speeds (30-120 frames per second). There were several major challenges to meeting this goal. In order to be considered an open standard, control needed to shift from Silicon Graphics (SGI), who originally developed OpenGL, to an independent Architecture Review Board (ARB) who would be responsible for approving specification changes, marking new releases, and ensuring conformance testing. Additionally, the graphics library itself would need to be designed in a manner that would allow the establishment of a stable and portable platform for developers. Finally, the library would need to garner the support of graphics hardware vendors as they would be providing the hardware acceleration needed to meet the goal of performing at real-time speeds.

Gaining vendor support is challenging because vendors are often in direct competition with one another. They differentiate themselves by creating innovative new features and by providing niche functionality to their users. Thus, OpenGL was faced with two competing requirements. On the one hand, it needed to abstract away vendor differences in order to provide a stable cross-platform environment to developers. On the other hand, in order to garner vendor support, it needed a method by which vendors could differentiate themselves and provide innovative new features and niche functionality to their users.

The OpenGL extension mechanism was developed to solve these problems. The extension mechanism achieved balance between the two requirements by maintaining the core specification under the direction of the Architecture Review Board while allowing vendors to define extensions to the core OpenGL specification. The core specification remained uncluttered and presented a unified view of common functionality. Because extensions were detectable at run time, developers could write portable applications that could adapt to the hardware on which they were running. This method of allowing for an extensible API has proven to be a very successful strategy. More than 500 extensions have been defined in OpenGL's lifetime and many vendors, including NVidia, ATI, Apple, IBM, and Intel, have participated in the process by developing their own custom extensions. Additionally, many key innovations (such as vertex and fragment shaders) have been developed via the extension process and are now part of the core OpenGL API.

OpenStack, while very different from OpenGL, shares many similar goals and faces many of the same challenges. OpenStack APIs are designed to be open API standards. An important goal is to provide developers with a ubiquitous, stable, any-scale cloud development platform that abstracts away many of the differences between hosting providers and their underlying infrastructure (hypervisors, load balancers, etc.). A Policy Review Board, similar to OpenGL's Architecture Review Board, is responsible for directing development of these APIs in a manner that ensures these goals are met. As with OpenGL, OpenStack requires support from vendors (and cloud providers) in order to be successful. As a result, OpenStack APIs also aim to provide vendors with a platform which allows them to differentiate themselves by providing innovative new features and niche functionality to their users. Because of these similarities, the OpenStack extension mechanism described in this document is modeled after the OpenGL extension mechanism. The methods by which extensions are defined vary drastically, of course, since the nature of the APIs is very different (C versus ReST); however, the manner in which extensions are documented, the way in which vendors are attributed, and the promotion path that an extension follows, all borrow heavily from OpenGL.