Add The Four Opens

The project's stance on the Four Opens is currently in the wiki, which
isn't a great place for such an important piece of information. We
should make it a bit more official.

Change-Id: I96ccb0ef823aca95b1fd0e7c2e1be3207ad52d00
This commit is contained in:
Monty Taylor 2015-12-11 09:34:58 -05:00
parent 8a2d1e9997
commit a95e825e58
3 changed files with 59 additions and 1 deletions

View File

@ -17,3 +17,4 @@ Reference documents which need to be revised over time.
tags/index
Template for new tags <tag-template>
Requirements for previously-used incubation/integration process <incubation-integration-requirements>
opens

57
reference/opens.rst Normal file
View File

@ -0,0 +1,57 @@
==============
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 six months the
development community holds a design summit to gather requirements and write
specifications for the upcoming release. The design summits, which are **open
to the public**, include users, developers, and upstream projects. We gather
requirements and produce an approved roadmap used to guide development for the
next six months.
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.
We follow those principles:
* **The community controls the design process.** You can help make this
software meet your needs.
* **The technical governance of the project is a community meritocracy** with
contributors electing technical leads and members of the Technical Committee.
* **This will always be truly free software.** We will never purposefully
limit the functionality or scalability of the software to try and sell you
an "enterprise" version
* **All project meetings are held in public IRC channels and recorded.**
* **Additional technical communication is through public mailing lists and is
archived.**

View File

@ -35,7 +35,7 @@ provides to a running server instance. In order to test the interfaces that a
user of an OpenStack cloud should be able to expect (for instance, does
config-drive show up, does the instance have the IP that neutron says it has)
we have to be able to have tests in the gate. Since OpenStack follows
`The Four Opens <https://wiki.openstack.org/wiki/Open>`_
`The Four Opens`_
that means that our tests must be Open Source. Alternate versions of the tests
that might test the same interfaces but use Close Source Operating Systems are
not possible to be validated since we can't run those Operating Systems in the