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