Page tree
Skip to end of metadata
Go to start of metadata


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.

Initiating Activation

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:

  1. Preparing an information packet demonstrating that they've met the requirements for activation (see below for details)
  2. Submitting the packet to the ESCo mailing list, and requesting an activation vote.

Approval Process

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.

Project Team

The project should have active contribution from two or more committers.

DocumentationThe project must have a
DocumentationThe must include a description of the software, including a feature overview.Yes
DocumentationThe must include installation & configuration instructions (how to run it locally, how to obtain, deploy and configure binaries, etc.).Yes
DocumentationThe must include a description of how to use the software.


DocumentationThe 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
DocumentationThe must include a Foundation status badge (initially the Incubating badge, but must be swapped with the Active badge once activation is approved).Yes
DocumentationThe must include a roadmap.Yes
DocumentationThe must include copyright & license information.Yes

No (high) security vulnerabilities are discovered by



No issues rated "high impact" are discovered by

SecurityIdentify any cryptographic functions and key lengths used within the software and get in touch with in order to request compliance with U.S. Export policy.Yes

All OWASP Top 10 warnings are (manually) verified.

Security Security Gates are respected (TBD).


No (medium) security vulnerabilities are discovered by


SecurityNo issues rated "medium impact" are discovered by
ExamplesIf 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.

  • No labels