Mature level


Mature level graduation procedure

The procedure to obtain the mature level is as follows:

  • The project leader fills-in the form below and submits it
  • The form is then reviewed by the TC Chairman and the OW2 CTO
  • Once approved by them, they pass the evaluation to the whole TC: one week is then given for the other TC members to review the submission and to express their views. If there is no opposition from the TC, the project becomes a mature project.

Mature level criteria

This section describes the criteria to be met by a project in incubation stage to reach the mature level. These criteria have been defined and accepted by the Technology Council (a history of the main changes is available in the last section).

Technical criteria

Source code
  • The project must have means of separating active development from versioning and bug-fixing in the source repository. It must be documented on the web site.
  • The source code of the project must be available on the OW2 infrastructure. Either the OW2 forge is used as the main source code repository, or the source code is synced from external repositories to the OW2 forge, automatically and on regular basis (at least once per release).
  • For each release, the project must publish an archive file containing the source code corresponding to the release.
  • The project must follow a code convention guideline, which has to be documented on the web site. This guideline should be enforced by using tools such as Checkstyle.
Continuous integration
  • The way to build the project has to be documented on the web site (required environment and step by step process to be followed)
  • The project code base must compile successfully on the target platforms.
  • The project must contain automated test suites executing successfully
  • A continuous integration platform must be set up either within the OW2 infrastructure with GitLab or an external CI platform.
Binaries
  • The project binaries of the recent releases must be available on the OW2 platform
  • The project binaries must be synced to the OW2 forge, at least once per release
Documentation
  • A user and a developer documentation must be available
  • Project page need to include a link to the documentation
Quality assessment

A mature project has to publish reports covering the following aspects:

  • Transversal maturity assessment by filling in the Open-source Maturity Model form (please ask the OW2 CTO for an instance of it for your project)
  • Source code static analysis with a tool such as SonarQube (see documentation for how to configure your project to publish results on OW2 SonarQube server)
  • IP and license analysis with a tool such as FOSSology or ScanCode

Community criteria

Activeness

The project must show that it is active by giving the following information:

  • Existence of discussions around the project on one or several communication channel(s) such as mailing-lists or IRC channels
  • Existence of recent source code commits
  • Existence of the availability of technical support (not necessarily commercial)
Usage

The project must expose metrics showing that it is in use by an audience. Possible control points may be:

  • Maven repository download statistics
  • Availability of public case studies
  • References to business users
Committers

The project must have at least two code committers.

Dashboard

The project's dashboard on the OW2 projects web site must be up to date with the information below.

Compulsory data
  • SPDX license(s) reference
  • Forge link
  • Mailing-list(s) information
  • Case study(ies)
  • Quality assessment reports covering static analysis, IP/License analysis, originality analysis
  • Implemented standards
  • An Open-source Maturity Model (OMM) form – example: ASM OMM – must be filled-in with up to date information and maintained on a regular basis
Recommended
  • Datasheet
  • Professional support information
  • Project roadmap
  • Community metrics

Document history

  • The TC has defined and accepted a first list of criteria in March 2011
  • The requirement for an archive containing the source of each release was adopted in February 2013