governance/reference/principles.rst

Guiding Principles

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 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.

One OpenStack

OpenStack is one community with one common mission, producing one framework of collaborating components. Our organization is split into separate source code repositories and teams allowing contributors to focus on their areas of interest and expertise, but does not make OpenStack a loose collection of disconnected projects.

OpenStack Primarily Produces Software

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 Built for our Users

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.

Contribution Is Our Currency

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.

We Value Constructive Peer Review

Peer review is a fundamental part of our culture. Reviewing submissions of code and documentation helps us find mistakes and become better programmers or writers. Peer review helps us build trust among team members and gives us an opportunity to teach each other about different parts of our software, CI system, and processes. Without the goodwill of contributors and reviewers, we would have no community.

We want review comments to be constructive so that the review process fulfills its purpose. We do not want reviews to be used to block contributions based on minor issues, often called "nits". The focus should always be on incremental improvement of the system as a whole, rather than ensuring each individual change is perfect.

We encourage reviewers who find minor aspects of a change they feel need to be changed, to engage the author in discussion versus downvoting, and collaborate on how best to move the change forward. Often this may result in a follow-up change, or revising the change under review.

One Contributor, One Vote

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.

Representative Democracy

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 Exist to Serve Their Community

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 and users of their projects.

Changes in Leadership are Good

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.

We value clear, friendly, and open communication

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 First, Project Team Second, Company Third

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.

Empowering Businesses, on a Level Playing Field

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.

We all should Always Follow the OpenStack Way

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.

Participation is Voluntary

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.