Open Source Project Best Practices
Identifying the best practices of an open source project is the first step in evaluating its market readiness. This step is based on a list of 50 check points from the framework used by the OW2 Technology Council to evaluate project maturity.
Willingness and ability of the project to communicate, to be easy to deal with.
COM-1 | Communication | The project maintains a website, there is a project URL. | | Status: Yes |
COM-2 | Communication | The project website provides a high-level, non-technical introduction of what the software does (what problem does it solve?). | | Status: Yes |
COM-3 | Communication | The project's website provides an easy-to-find link to the source code of its latest release. | | Status: Yes |
COM-4 | Communication | The project can provide evidence of at least one event participation or press release in the last 12 months, plus recent social network activity. | | Status: Yes |
COM-5 | Communication | The project's dashboard on the OW2 web site is completed and up to date. | | Status: Yes |
Status of the community and mechanisms that support third party contributions.
CTY-1 | Community | The project has at least two unassociated active code committers. | | Status: Yes |
CTY-2 | Community | The project can provide evidence of active discussions around the project on one or several public communication channel(s) over the last three months. | | Status: Yes |
CTY-3 | Community | The project is open to third-party contributions. | | Status: Yes |
CTY-4 | Community | The project recognizes as contributions not only source code, but also documentation, constructive bug reports, constructive discussions, marketing and generally anything that adds value to the project. | | Status: Yes |
CTY-5 | Community | The project maintains a list of easy contributions suitable for new contributors. | | Status: No |
Documentation facilitating usage of the project and contribution to it.
DOC-1 | Documentation | The project maintains web pages with ready-to-use human-readable documentation in English. | | Status: Yes |
DOC-2 | Documentation | The project provides user documentation. | | Status: Yes |
DOC-3 | Documentation | The project provides reference documentation that describes the external interface (both input and output) of the software produced by the project, if any. | | Status: Yes |
DOC-4 | Documentation | The project provides documentation for developers including coding guidelines, style, patterns, etc. | | Status: Yes |
DOC-5 | Documentation | The project provides documentation on the contribution workflow (e.g., are pull requests used?). | | Status: Yes |
Provisioning of development resources and facilitation of bug reports and commits contribution.
INF-1 | Infrastructure | The project provides communication mechanisms to interact with the user community (mailing-list, chat, forum) that are searchable, allow messages and topics to be addressed by URL | | Status: Yes |
INF-2 | Infrastructure | The project uses a state-of-the-art collaborative development environment that tracks what changes were made, who made the changes, and when the changes were made. | | Status: Yes |
INF-3 | Infrastructure | The project uses a publicly accessible issue tracker for tracking individual issues. | | Status: Yes |
INF-4 | Infrastructure | The project has a version-controlled source repository that is publicly readable. | | Status: Yes |
INF-5 | Infrastructure | The project provides a continuous integration (CI) system that can automatically rebuild the software from source code, if the software produced by the project requires building for use. | | Status: Yes |
Organization of the project and management of its activities.
MGT-1 | Management | The project decision making process and the main roles in this process are explicitly defined and publicly documented. | | Status: No |
MGT-2 | Management | The project release management process is defined and publicly documented (or the project has named a release team). | | Status: Yes |
MGT-3 | Management | The project roadmap process is defined and publicly documented. | | Status: Yes |
MGT-4 | Management | The project facilitates community support (i.e. provides resources where users and committers can talk to each other). | | Status: Yes |
MGT-5 | Management | The way in which contributors can be granted more rights is explicitly defined and publicly documented. | | Status: Yes |
Open source licenses and copyright handling by the project.
DISCLAIMER: The text in this section does not constitute legal advice. The information contained on this page does not constitute legal advice and is presented without any representation or warranty whatsoever, including as to accuracy or completeness. This page should not be used as a substitute for competent legal advice from a licensed lawyer. Readers should not act on information contained on this page without seeking legal counsel.
LIC-1 | Licenses | The project produces software exclusively under license(s) approved by the Open Source Initiative (OSI). | | Status: Yes |
LIC-2 | Licenses | The project's license(s) can verified by the use of dedicated license analysis tools. | | Status: Yes |
LIC-3 | Licenses | The project's license is clearly stated on the project web site. | | Status: Yes |
LIC-4 | Licenses | The project has a process to vet the copyright ownership of every code contributions integrated into the software. | | Status: Yes |
LIC-5 | Licenses | Libraries and components that are mandatory dependencies of the project's code are available as open source software. | | Status: Yes |
Development practices that help improve code quality.
DEV-1 | Dev. Process | The project process for users to submit bug reports, feature requests and improvement ideas is documented and supported by a tool (e.g. an issue tracker or a mailing list). | | Status: Yes |
DEV-2 | Dev. Process | The project maintains at least one stable version of the software, different from the development version. | | Status: Yes |
DEV-3 | Dev. Process | The project quality control process is defined and publicly documented. | | Status: No |
DEV-4 | Dev. Process | The project's source repository includes interim versions to enable collaborative review between releases, development for public releases happens publicly. | | Status: Yes |
DEV-5 | Dev. Process | The project can provide evidence of the use of agile methodology or any well-documented software development methodology. | | Status: Yes |
Implemention, quality and maintenance of the testing process.
TST-1 | Test Process | The project applies at least one FLOSS static code analysis tool to any proposed major production release of the software before its release. | | Status: Yes |
TST-2 | Test Process | The project uses at least one automated FLOSS test framework. | | Status: Yes |
TST-3 | Test Process | The project can provide evidence that its tests cover at least 50% of its lines of code. | | Status: No |
TST-4 | Test Process | The project can provide evidence that it provides tests for different testing levels (Unit testing, Integration testing, System testing, Functional and non-functional testing, etc.).. | | Status: Yes |
TST-5 | Test Process | The project can provide evidence that it tests the quality of its tests. | | Status: Yes |
Enablement and maintenance of the integrity of the product and its releases.
REL-1 | Release Mgt | The project results have a unique version identifier for each release intended to be used by users. | | Status: Yes |
REL-2 | Release Mgt | The Semantic Versioning (SemVer) format is used for releases. | | Status: Yes |
REL-3 | Release Mgt | The project provides for each realeasea public way to inspect the full list of changes integrated since the previous release. | | Status: Yes |
REL-4 | Release Mgt | The project's releases consist of both source code and executable binary if applicable, and they are distributed using standard and open archive formats. | | Status: Yes |
REL-5 | Release Mgt | The project provides, in each release, release notes that are in a human-readable format and a summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. | | Status: Yes |
Security and Vulnerability Management
Attention to security vulnerabilities, mechanisms and resources to deal with them.
SEC-1 | Security | The project has defined and documented a process for confidentially reporting vulnerabilities. | | Status: Yes |
SEC-2 | Security | The project provides security support and updates for the last stable release for at least one year. | | Status: Yes |
SEC-3 | Security | The project uses standard identifiers (e.g. CVE, CPE) to track security vulnerabilities. | | Status: Yes |
SEC-4 | Security | The project can provide evidence that it applies secure development best practices. | | Status: Yes |
SEC-5 | Security | The project has conducted a security audit in the last three years. | | Status: Yes |