62ff3381c5
The current phrasing states "Truly open source software is not feature or performance limited and is not crippled." Crippled in that context means it is not disabled or limited in any manner by the fact the software is open source. As a non-native English speaker, the first impression on looking up that adjective on the internet is that it is an English word used to describe people with disabilities, sometimes in a pejorative manner. Its translation to the Portuguese word 'aleijado' which does not seem respectful, translating back to 'crippled', 'lame' or 'gammy'. As it led me to confusion, it may lead others too, specially in a community where almost every country in this planet is represented. This patch suggests the removal of that part of the sentence, leaving "Truly open source software is not feature or performance limited." which still has the same meaning that is clear and thus does not need to be emphasized by that adjective. Change-Id: I29b6cea609ae9db9c9ff678c28744de4570486ca
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.
|
|
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.
|