33c93087e7
The value and meaning of the word "meritocracy" has been a source of much debate in many communities, open source and otherwise. For many people it is considered exclusionary and something of a hallmark for not being in tune with its negative connotations. Rather than presenting our defenses against those negative connotations and being more explicit about the local definition of a subjective term, we can remove it in favor of something that is more direct. The intent, in the past, has been that "meritocracy" is supposed to be indicative of a community where the people who get on and do things and get stuff done are the ones that become become leaders. The problem with this is "meritocracy" is defined by those who are already in positions of leadership and thus implicitly excludes those who may be leading or attempting to lead (or "do") in styles that are different from existing leaders or who come from backgrounds different from the norm. These styles may have just as much "merit" as any other. The change here simply states what is the case: one of the ways we achieve openness is by technical governors being elected from members of the community, rather than being imposed from elsewhere. Also in this change "technical leads" is adjusted to "team leads" to reflect the current expansion of "PTL". Change-Id: Ifdadaad9e616c0ee3ce59f3c1da323ed458c0bc7
54 lines
2.0 KiB
ReStructuredText
54 lines
2.0 KiB
ReStructuredText
==============
|
|
The Four Opens
|
|
==============
|
|
|
|
Open Source
|
|
-----------
|
|
|
|
We do **not** produce "open core" software.
|
|
|
|
We are committed to creating truly open source software that is usable and
|
|
scalable. Truly open source software is not feature or performance limited and
|
|
is not crippled. There will be no "Enterprise Edition".
|
|
|
|
We use the Apache License, 2.0.
|
|
|
|
* `OSI <http://www.opensource.org/licenses/alphabetical>`_ approved
|
|
* `GPLv3 <http://www.gnu.org/licenses/license-list.html#apache2>`_ compatible
|
|
* `DFSG <http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines>`_ compatible
|
|
|
|
Open Design
|
|
-----------
|
|
|
|
**We are committed to an open design process.** Every development
|
|
cycle the OpenStack community holds face-to-face events to gather
|
|
requirements and write specifications for the upcoming release. Those
|
|
events, which are **open to anyone**, include users, developers, and
|
|
upstream projects. We gather requirements, define priorities and flesh
|
|
out technical design to guide development for the next development cycle.
|
|
|
|
The community controls the design process. You can help make this software
|
|
meet your needs.
|
|
|
|
Open Development
|
|
----------------
|
|
|
|
We maintain a publicly available source code repository through the entire
|
|
development process. We do public code reviews. We have public roadmaps. This
|
|
makes participation simpler, allows users to follow the development process and
|
|
participate in QA at an early stage.
|
|
|
|
Open Community
|
|
--------------
|
|
|
|
One of our core goals is to maintain a healthy, vibrant developer and user
|
|
community. Most decisions are made using a `lazy consensus
|
|
<http://www.apache.org/foundation/glossary.html#LazyConsensus>`_ model. All
|
|
processes are documented, open and transparent.
|
|
|
|
The technical governance of the project is provided by the community itself,
|
|
with contributors electing team leads and members of the Technical Committee.
|
|
|
|
All project meetings are held in public IRC channels and recorded. Additional
|
|
technical communication is through public mailing lists and is archived.
|