Mature Transition Criteria

The content of this page is under active discussion by the TC.
It only reflects the current state of our thoughts and has not been voted or officially supported/endorsed by the TC.

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.

Minimal dashboard's content

  • Compulsory
    • Project Name
    • Project description
    • 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 (not compulsory)
    • 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)
  • Proposed
    • Community informations (list size, traffic, #committers, ...)


The project must show that it is in activity:

  • Exchanges (question + answer) on the mailing lists
    • Community support
    • The number of commits on the last 6 months
  • Last commits
  • The number of mail / month (on the last 6 months).
  • ...