Market Readiness Level Rating, Best Practices Verification: ProActive Workflows & Scheduling


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.

Project Communication

Willingness and ability of the project to communicate, to be easy to deal with.

COM-1CommunicationThe project maintains a website, there is a project URL.Status:  Yes  
COM-2CommunicationThe project website provides a high-level, non-technical introduction of what the software does (what problem does it solve?).Status:  Yes  
COM-3CommunicationThe project's website provides an easy-to-find link to the source code of its latest release.  Status:  Yes  
COM-4CommunicationThe 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-5CommunicationThe project's dashboard on the OW2 web site is completed and up to date.Status:  Yes  

Project Community

Status of the community and mechanisms that support third party contributions.

CTY-1CommunityThe project has at least two unassociated active code committers.Status:  Yes  
CTY-2CommunityThe 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-3CommunityThe project is open to third-party contributions.Status:  Yes  
CTY-4CommunityThe 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-5CommunityThe project maintains a list of easy contributions suitable for new contributors.Status:  No  

Project Documentation

Documentation facilitating usage of the project and contribution to it.

DOC-1DocumentationThe project maintains web pages with ready-to-use human-readable documentation in English.Status:  Yes  
DOC-2DocumentationThe project provides user documentation.Status:  Yes  
DOC-3DocumentationThe 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-4DocumentationThe project provides documentation for developers including coding guidelines, style, patterns, etc.Status:  Yes  
DOC-5DocumentationThe project provides documentation on the contribution workflow (e.g., are pull requests used?).Status:  Yes  

Development Infrastructure

Provisioning of development resources and facilitation of bug reports and commits contribution.

INF-1InfrastructureThe 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 URLStatus:  Yes  
INF-2InfrastructureThe 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-3InfrastructureThe project uses a publicly accessible issue tracker for tracking individual issues.Status:  Yes  
INF-4InfrastructureThe project has a version-controlled source repository that is publicly readable.Status:  Yes  
INF-5InfrastructureThe 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  

Project Management

Organization of the project and management of its activities.

MGT-1ManagementThe project decision making process and the main roles in this process are explicitly defined and publicly documented.Status:  No  
MGT-2ManagementThe project release management process is defined and publicly documented (or the project has named a release team).Status:  Yes  
MGT-3ManagementThe project roadmap process is defined and publicly documented.Status:  No  
MGT-4ManagementThe project facilitates community support (i.e. provides resources where users and committers can talk to each other).Status:  Yes  
MGT-5ManagementThe way in which contributors can be granted more rights is explicitly defined and publicly documented.Status:  No  

Project License

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-1LicensesThe project produces software exclusively under license(s) approved by the Open Source Initiative (OSI).Status:  Yes  
LIC-2LicensesThe project's license(s) can verified by the use of dedicated license analysis tools.Status:  Yes  
LIC-3LicensesThe project's license is clearly stated on the project web site.Status:  Yes  
LIC-4LicensesThe project has a process to vet the copyright ownership of every code contributions integrated into the software.Status:  No  
LIC-5LicensesLibraries and components that are mandatory dependencies of the project's code are available as open source software. Status:  Yes  

Development Process

Development practices that help improve code quality.

DEV-1Dev. ProcessThe 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-2Dev. ProcessThe project maintains at least one stable version of the software, different from the development version.Status:  Yes  
DEV-3Dev. ProcessThe project quality control process is defined and publicly documented.Status:  Yes  
DEV-4Dev. ProcessThe project's source repository includes interim versions to enable collaborative review between releases, development for public releases happens publicly.Status:  Yes  
DEV-5Dev. ProcessThe project can provide evidence of the use of agile methodology or any well-documented software development methodology.Status:  Yes  

Testing Process

Implemention, quality and maintenance of the testing process.

TST-1Test ProcessThe 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-2Test ProcessThe project uses at least one automated FLOSS test framework.Status:  Yes  
TST-3Test ProcessThe project can provide evidence that its tests cover at least 50% of its lines of code.Status:  Yes  
TST-4Test ProcessThe 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-5Test ProcessThe project  can provide evidence that it tests the quality of its tests.Status:  Yes  

Release Management

Enablement and maintenance of the integrity of the product and its releases.

REL-1Release MgtThe project results have a unique version identifier for each release intended to be used by users.Status:  Yes  
REL-2Release MgtThe Semantic Versioning (SemVer) format is used for releases.Status:  No  
REL-3Release MgtThe project provides for each realeasea public way to inspect the full list of changes integrated since the previous release.Status:  Yes  
REL-4Release MgtThe 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-5Release MgtThe 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-1SecurityThe project has defined and documented a process for confidentially reporting vulnerabilities.Status:  No  
SEC-2SecurityThe project provides security support and updates for the last stable release for at least one year.Status:  Yes  
SEC-3SecurityThe project uses standard identifiers (e.g. CVE, CPE) to track security vulnerabilities.Status:  Yes  
SEC-4SecurityThe project can provide evidence that it applies secure development best practices.Status:  Yes  
SEC-5SecurityThe project has conducted a security audit in the last three years.Status:  Yes