117 lines
5.4 KiB
ReStructuredText
117 lines
5.4 KiB
ReStructuredText
==================
|
|
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 :doc:`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
|
|
<https://www.openstack.org/legal/community-code-of-conduct/>`__.
|
|
|
|
One OpenStack
|
|
-------------
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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, we encourage you to either participate
|
|
in improving them within our community governance rules, or seek a different
|
|
community that is better aligned with your ideals or opinions.
|
|
|