Virtually all Foundation-hosted projects are expected to strive towards, and ultimately attain, released status. This indicates to potential consumers that the project has reached a level of functional and non-functional maturity such that it is suitable for production use.
In order for a project to become released, it must be reviewed by the Foundation and formally approved. Approval is performed by the Engineering Steering Committee (ESCo), representing the Foundation.
Any project team may initiate this approval process at any time, which involves:
- Preparing an information packet demonstrating that they've met the requirements for activation (see below for details)
- Submitting the packet to the ESCo mailing list, and requesting an activation vote.
When a request for activation vote is first received, the ESCo Secretary will schedule the vote on the project team's behalf. Activation votes are typically conducted in-person during one of the ESCo's weekly meetings, using the ESCo's voting rules. A member of the project team is encouraged to attend this meeting, in order to answer any last minute questions from the ESCo prior to the vote, and to capture any feedback the ESCo provides.
Requirements for Activation
In addition to continuing to meet all of the contribution requirements, activation has the following additional requirements, and the information packet provided to ESCo when requesting activation must include references proving that each of these requirements has been met. The best format for these references are links (URLs) to the source systems themselves (GitHub, Travis CI, SonarQube, etc.) - the more evidence you're able to provide in support of each criteria, the more smoothly the activation vote will proceed.
The appropriate license text should be included in each source file's header. See the Apache guidelines for specifics.
The project should have active contribution from two or more committers.
|Documentation||The project must have a README.md.||Yes|
|Documentation||The README.md must include a description of the software, including a feature overview.||Yes|
|Documentation||The README.md must include installation & configuration instructions (how to run it locally, how to obtain, deploy and configure binaries, etc.).||Yes|
|Documentation||The README.md must include a description of how to use the software.|
|Documentation||The README.md must include links to other systems (further documentation, continuous integration & validation tools, artifact repository, change log / history, etc.) - where possible this should be in the form of badges (e.g. from shields.io).||Yes|
|Documentation||The README.md must include a Foundation status badge (initially the Incubating badge, but must be swapped with the Active badge once activation is approved).||Yes|
|Documentation||The README.md must include a roadmap.||Yes|
|Documentation||The README.md must include copyright & license information.||Yes|
No (high) security vulnerabilities are discovered by versioneye.com.
No issues rated "high impact" are discovered by scan.coverity.com.
|Security||Identify any cryptographic functions and key lengths used within the software and get in touch with firstname.lastname@example.org in order to request compliance with U.S. Export policy.||Yes|
All OWASP Top 10 warnings are (manually) verified.
SonarQube.com Security Gates are respected (TBD).
No (medium) security vulnerabilities are discovered by versioneye.com.
|Security||No issues rated "medium impact" are discovered by scan.coverity.com.||No|
|Examples||If the software is a library or SDK, example code that demonstrates the use of the library or SDK.||Yes|
Redistributed binaries (i.e. via an artifact repository or package manager) should be listed.
Proof of adoption (e.g. in the form of download statistics, citing known deployments, etc.) must be provided.