OpenStack has a set of guiding principles that are used to inform and shape decisions. These principles are not aspirational. Rather, they form the bedrock upon which the OpenStack community and software are built.
First and foremost, OpenStack follows The Four Opens. All four of them are essential, and most of the principles described in this document derive from them. In their personal interactions, our community members are also bound by the rules described in the OpenStack Community Code of Conduct.
OpenStack is one community with one common mission, producing one framework of collaborating components. Our organization into separate source code repositories and teams allows contributors to focus on their areas of interest and expertise, but does not make OpenStack a loose collection of disconnected projects.
While the software that OpenStack produces has well defined and documented APIs, the primary output of OpenStack is software, not API definitions. We expect people who say they run “OpenStack” to run the software produced by and in the community, rather than alternative implementations of the API.
OpenStack is ultimately built to be deployed and used. We need to factor the needs of our existing and anticipated users (operators but also application developers) when making decisions.
Change happens in OpenStack because anyone in the community can identify an issue and volunteer to do the necessary work. Contribution is the mechanism of change and how trust is built between community members. Though elected leadership exists, that leadership is not solely responsible for change. The entire OpenStack community is empowered to identify problems and, where possible, assemble the teams to resolve them.
The voice of the contributor community is essential, and forms the basis of our democracy. A person with a thousand patches in an OpenStack release should not have a voice a thousand times as strong (and writing patches is not the only way to contribute). Efforts to limit the electorate to those who make quantifiable contributions, no matter the form, are intended only to prevent gaming of the system, not as a value judgement on relative worth of the various different forms of community contributions.
While we strive to build community consensus around decisions, all decisions are finally made or delegated by people who have been democratically elected.
OpenStack leaders hold their positions only in order to serve the people they lead. The TC only exists to serve the technical community. PTLs exist to serve the contributors to and users of their projects.
It is important for the long-term health of OpenStack that its democratically elected leaders change over time to remain representative of the body of contributors. OpenStack does not have and does not want any sort of dictator, benevolent or otherwise. Leaders (and other community members) in OpenStack are encouraged to participate in mentoring activities (external or internal to the OpenStack community) to help cultivate the next generation of contributors and leaders. No one should consider their role as permanent. Leaders, specifically, should consider stepping down from their role when they can’t fully focus on it anymore, and always ensure a good transition path with their successors.
OpenStack is a geographically distributed community, with members from different cultures whose first language may not be English. Both of those characteristics can make communication more difficult and lead to misunderstandings, but we encourage everyone to consciously work to overcome that challenge through careful and constructive writing and by looking for positive interpretations of unclear messages. Communicating clearly improves our ability to collaborate to solve technical challenges more effectively.
OpenStack leaders are expected to put the needs of OpenStack first in their decision making, before the needs of any individual project team. They are also expected to put the needs of their project team before the needs of the organization they work for, if any. They can of course represent the needs of their project team or their company, but in case of conflicts of interest, they should be ready to put those needs aside and make the best call for OpenStack as a whole.
From the beginning, OpenStack has striven to support businesses who build products on or with OpenStack, and help them be successful. However, OpenStack should not empower one business over another, or else our community would not truly be a place where everyone can collaborate. While the needs of the constituent businesses are essential, they must be balanced with each other lest OpenStack decisions unwittingly be made by unelected people behind closed doors.
No one is outside of the rules. We derive considerable value from the empowerment that everyone in the community enjoys from equal application of our key values, principles, and common processes. If parts of OpenStack exist outside of the rules, everyone suffers. While it can be tempting to circumvent process for expedience, doing so is not scalable from a community perspective. It leads to the subversion of democracy and an abdication of our principles of Open Design and Open Community. Large code changes designed outside of community processes, and decisions made outside of OpenStack governance are generally rejected because they, by definition, did not include the community.
The leadership of OpenStack should not need to find itself in a position of enforcing the rules because participation in the OpenStack community is a choice made by its participants in the first place. If you disagree with the principles or processes we follow, you may of course seek a different community that is better aligned with your ideals or opinions. However, if you are committed to the mission of OpenStack and our Four Open ideals, we encourage you to contribute to OpenStack and participate in improving the OpenStack processes and the documenting of our principles from within our community according to our rules of governance.