Active

Overview

Projects that have been approved for activation transition to the Active state, a formal recognition that the software is now suitable for production use.

Objectives

The first priority of a newly Active project is to deploy a v1.0.0 or higher production-grade version.  The Foundation expects this to occur soon after activation, ideally within one month.

Once a v1.0.0 is released, the objectives of the Active lifecycle state primarily involve the project team developing and executing on an ongoing roadmap of features and bug fixes, informed by feedback from the project's user base.

Requirements

Badge

Foundation-hosted projects are expected to provide a clear indication to visitors that they are Active.  To this end, the Foundation provides a badge that should be displayed at the top of the project's root-level README.md file, using the following Markdown:

This will appear as follows:

and when clicked will navigate to this page.

Releases

An Active project can use any version number it wishes, although it is expected that virtually all releases from a released project will be ≥ v1.0.0.  Ecosystem-specific suffixes may also be used for pre-releases (e.g. "-SNAPSHOT" in the Java ecosystem, or "-alpha", "-beta", etc. in the .NET ecosystem).

All Active project starting from v1.0.0 upward must adhere to the version numbering rules defined by semantic versioning, specifically:

  • Increment MAJOR version when an incompatible change is made
  • Increment MINOR version when new functionality is added in a backwards-compatible manner
  • Increment PATCH version when bugs are fixed in a backwards-compatible manner

Notes for Evaluators

If you're evaluating Foundation-hosted open source projects and see the released badge shown above, here are some of the things you should expect should you choose to download and use the software. 

  • The software is functional, though perhaps minimally viable.
  • The software has high quality - it has met or exceeded all of the Foundation's security and compliance requirements, and has been well tested.
  • The installation & upgrade experiences should be relatively smooth - binaries will be available at a minimum, and more advanced deployment options (installers, containers, VM images, automated upgrade scripts etc.) may also be available.
  • The project is well documented.
  • The project is supported by an engaged project team.  While there may not be a formal SLA (depending on the availability of commercial support for the project), bugs and enhancement requests will be triaged and addressed by the team.
  • Backwards compatibility is a priority, and semantic versioning is used to clearly communicate breaking changes.

For a full list of guidelines an Active project is expected to fulfill see the Activation checklist.