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


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.



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 file, using the following Markdown:

[![FINOS - Active](](

This will appear as follows:

and when clicked will navigate to this page.


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

The Foundation mandates the user of Semantic Versioning ("semver") throughout a project's lifecycle.

For those ecosystems that support more complex version number representations (e.g. Python), the Foundation strongly recommends restricting version numbers to semver format wherever possible.

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.

Projects and Working Groups

Software and other work products of FINOS programs' respective projects are expected to have met the criteria above when a specific build or release is moved to formal Active status. In general builds and releases (including the overall "bundle" of artifacts associated with a particular release such as documentation, support and maintenance plans, testing criteria and results, etc.) that do not meet all of these criteria should remain a "release candidate" until such time as these criteria are asserted by the PMC as having been met. Affiliated projects within programs that release software together, as a singular release and/or single product, are further expected to build appropriate documentation and other material required to understand how different project output should work together.