OpenStack DefCore Committee—The Grown-Ups Are in the House
Anyone who has worked with OpenStack components for even a short time knows the drill. OpenStack Swift does not quite fully communicate with Keystone; nobody knows what do about Horizon; and Nova Networking, Quantum, Neutron—whatever it is called—does not really get along with anything. Have you been frustrated by the lack of standardization in the OpenStack code and the glaring holes in and between many of the components?
As OpenStack enters its fifth year, the OpenStack Foundation and its many contributors, big and small, are finally addressing growing concerns regarding sprawling code and inconsistent compatibility among the platform’s components. The DefCore Committee is coming to the rescue.
The OpenStack DefCore Committee was originally formed by a Board Resolution during the November 2013 Hong Kong Summit. Chaired by Josh McKenty and Rob Hirschfeld, two major luminaries in the community, and filled with many OpenStack Foundation board members, the committee’s mandate from the very beginning was to bring some much needed adult supervision to the management of an increasingly unwieldy code base by defining what clearly should be branded OpenStack for commercial purposes and what is outside the scope of the project.
One of the most important functions of the committee is to develop the framework for what can be labeled as OpenStack without creating requirements so restrictive that they stifle innovation and creativity. Rob Hirschfeld wrote eloquently on the need to maintain balance. He uses the analogy of eating the proverbial elephant—best consumed in very small chunks, while deliberately putting off taking on any of the hard bits until they are ready. While the analogy is apt, it does not seem overly appetizing.
The official DefCore charter is to define what is “core” to the project. At the very least, as stated on the committee’s wiki page,
DefCore sets base requirements by defining 1) capabilities, 2) code and 3) must-pass tests for all OpenStack products. This definition uses community resources and involvement to drive interoperability by creating the minimum standards for products labeled "OpenStack."
Already the definition has moved away from a core/not core mind-set toward a realization that OpenStack is more of a patchwork onion than an in or out proposition. Clearly there is much work to be done as OpenStack matures into a stable platform that can be embraced by both the enterprise and research communities.
If this has sparked an interest in helping with the important work of standardizing the OpenStack components, as with any of the OpenStack projects, anybody is encouraged to engage in the process. In the end, that is the real power of an open source community. Anyone with some time and interest is more than welcome to contribute to the project’s success.
