22aae01d55
From an upstream perspective, I see us as being in the business of providing open collaboration playing fields in order to build projects to reach the OpenStack Mission. We collectively provide resources (infra, horizontal teams, events...) in order to enable that open collaboration. An important characteristic of these open collaboration grounds is that they need to be a level playing field, where no specific organization is being given an unfair advantage. I expect the teams that we bless as "official" project teams to operate in that fair manner. Otherwise we end up blessing what is essentially a trojan horse for a given organization, open-washing their project in the process. Such a project can totally exist as an unofficial project (and even be developed on OpenStack infrastructure) but I don't think it should be given free space in our Design Summits or benefit from "OpenStack community" branding. So if, in a given project team, developers from one specific organization benefit from access to specific knowledge or hardware (think exclusive access to proprietary hardware or software that the open source code primarily interfaces with), then this project team should be rejected under the "open community" rule. This requirement (like all requirements in this document) is meant to be interpreted by humans on a case-by-case basis. In particular, there is a grey area around drivers for proprietary solutions that requires human judgment here. As a rule of thumb, if the open implementation was unusable open core bait to lure people into using the one and only proprietary driver, it would be a problem. If the open implementation was fully functional and nothing prevented adding additional proprietary drivers to the code base, there would be no problem. Change-Id: I0cd689afb8ddb7a269b9ce378e4c6647652f6977
3.8 KiB
Requirements for new OpenStack Projects applications
Teams in OpenStack can be created as-needed and grow organically. By becoming an official OpenStack Project, they place themselves under the authority of the OpenStack Technical Committee. In return, their contributors get to vote in the Technical Committee election.
When considering new projects for addition, the TC will check that:
- The project aligns with the OpenStack Mission: The project must have a clear and defined scope. It should help further the OpenStack mission, by providing a cloud infrastructure service, or directly building on an existing OpenStack infrastructure service.
- The project follows the OpenStack way ("the 4 opens"):
- Open Source:
- The proposed project uses an open source license (preferably the Apache v2.0 license, since it is necessary if the project wants to be used in an OpenStack trademark program)
- Project must have no library dependencies which effectively restrict how the project may be distributed or deployed
- Open Community:
- The leadership is chosen by the contributors to the project
- The project has regular public meetings on IRC and those meetings are logged and published (moving to official OpenStack meeting channels once the project's application is accepted, if they're not held there already)
- The project shall provide a level and open collaboration playing field for all contributors. The project shall not benefit a single vendor, or a single vendors product offerings; nor advantage contributors from a single vendor organization due to access to source code, hardware, resources or other proprietary technology available only to those contributors.
- Open Development:
- The project uses public code reviews on the OpenStack infrastructure
- The project has core reviewers and adopts a test-driven gate in the OpenStack infrastructure for changes
- The project provides liaisons that serve as contacts for the work of cross-project teams in OpenStack
- Where it makes sense, the project cooperates with existing projects rather than gratuitously competing or reinventing the wheel
- Where appropriate, the project adopts technology and patterns used by existing OpenStack projects
- Open Design:
- The project direction is discussed at the Design Summit and/or on public forums
- The project uses the openstack-dev ML to discuss issues
- Open Source:
- The project ensures basic interoperability with the rest of OpenStack: User-facing API services should support Keystone for discovery and authentication.
- The project should have an active team of one or more contributors
- The project meets any policies that the TC requires all projects to
meet. For instance, the
project-testing-interface
In order to do an evaluation against this criteria, the TC expects the project to be set up and have some history to evaluate. A few months of operating and following these project requirements is a rough guideline for how long to wait before applying to be approved by the TC.
Once a project has joined OpenStack, it may create additional source code repositories as needed at the discretion of its Project Team Lead (PTL) without prior approval from the TC as long as the additional source code repositories fall within the scope of the approved project mission statement.
Official project teams are expected to participate in all elections held after the team is accepted as official, regardless of how recently the team leadership may have been established.