Mature Transition Criteria

Here is the output of the discussion between Jacques, Florent and myself (Guillaume) about the required criteria to successfully move a project from incubator to mature.

Acceptance Criteria

First of all, we decided to remove all business related criteria: we're the technology council, not the board, let these business aspects to other guys and focus on technical and community aspects.

Technical Criteria

Source Code + Documentation + Binaries

  • The source code of the project must be available on the OW2 infrastructure.
    • Either the OW2 forge is used as the main development point
    • Or the project maintainers must publish on a regular basis their code on OW2
      • This have to be an automatic script
      • Regular basis meaning "Once per release"
  • The same rule applies for documentation and binaries


  • The project code-base must build.
    • Build means here compile + tests OK
  • A continuous integration mechanism must be used to ensure the build is a success.
  • The way to build the system has to be documented on the web site
    • Like a cookbook explaining required environment and software + step by step build process
Projects could use the OW2 in-house Continuous Integration System ( or provides a link on their own CI system elsewhere.

Project's Usage

The projects must show that it is used within the OW2 universe or outside.

Possible Control Points:

  • Code sharing with maven repository
  • Gives references of client system (using the project)
  • Gives references of business users
  • ...


Quality is an important factor of maturity acceptance and has not to be neglected.

Source Repository Management

The project must have means of separating active development from versioning and bug-fixing in the source repository.
It should be documented on the web site.

Active development goes into a trunk and branches are used for stabilization.

Code Conventions

A mature project must follow a code convention guideline.
It should be documented on the web site.
This guideline should be enforced by using tools like checkstyle.

It's not the aim of OW2 to provides a strict code guideline, but the consortium may define a set of convention that could be used by default by projects.


SQuAT (Software Quality Assurance Tool) is an OW2 initiative/platform? (Verify) or set of tools dedicated to software quality.

Using the SQuAT tools, it will be easier to ensure of the quality of a project (IP/Licence management, code style, ...).

But as it's currently not open to everyone, we can't have it as a mandatory point.

SQuAT 'compliance' will be re-incorporated into a later revision of this document.

Possible Control Points

  • Checkstyle report
  • Code coverage
  • Tests/Code ratio ?
  • At least 1 development branch (the trunk)
  • At least 1 tags in the VCS for proper release management
  • ...

Community Criteria


The project must have more than 1 active committer.


The project's dashboard must be up to date.

Question: What is the minimal dashboard's content for a mature project ?
  • Compulsory
    • Project Name
    • Project description -> compulsory
    • Short project description
    • Status: Mature/Incubator/Archive
    • Function: (in the list of predefined functions)obvious
    • License
    • Forge Link
    • Mailing List link
    • Repository type (SVN, CVS, etc)
    • Repository Link
    • Project Home Page Link
  • Recommended
    • Logo Image
    • License Link
    • Project DataSheet link (the link must be to a PDF file)
    • Professional support link
    • Case study -> I think it should be compulsory (at least to show who is using it)
    • Standard implemented
  • Future
    • Fossology report -> will be compulsory in the future for mature projects when implemented
    • Code quality reports(Sonar? Code coverage? other?)
    • project roadmap (link)


The project must show that it is in activity:

  • Exchanges (question + answer) on the mailing lists
    • Community support
  • Last commits
  • ...