| 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 forge with Bamboo currently, or an external CI platform) |
|
|
|---|
| Binaries | | The project binaries must be synced to the OW2 platform, at least once per release |
|
|
|---|
| Documentation | | A user and a developer documentation must be available |
| | The documentation must be synced to the OW2 forge, at least once per release |
|
|
|---|
| Quality assessment | | Transversal maturity assessment by filling in and maintaining on a regular basis the Open-source Maturity Model form |
| | Source code static analysis with a tool such as SonarQube | | | IP and license analysis with a tool such as FOSSology |
| | Source code originality analysis with a tool such as Antepedia Reporter |
| | Activiy metrics eg via OpenHub |
|
|
|---|
