A healthy open source project demonstrates open practices, uses open infrastructure, and cultivates an open culture with the goal of becoming more sustainable. Use this checklist to assess the health of an open source project. The more checks you see when you are finished, the healthier the project is likely to be.
Infrastructure
Basic infrastructure*
- Code repositories and issue trackers are present and easily accessible
- Development and testing tools are present and easily accessible
- Project website is present and easily accessible
- Mailing list servers are present and easily accessible
- Documentation platform is present and easily accessible
- Video conferencing platform is present and easily accessible
- Community forum is present and easily accessible
- Synchronous chat tools are present and easily accessible
- Community event calendar is present and easily accessible
* Infrastructure is "easily accessible" if users and contributors do not require special permission or specific institutional affiliation to engage with it.
Project website
- Website has a unique domain name
- Website features other publicly visible sites or subdomains
- Website contains clear description of project and its purpose
- Website features consistent stylistic and navigational elements
- Website features software binaries download link
- Website features multiple download formats
- Website content and copyright notices are current
- Website contains a GDPR policy and other relevant privacy policies
- Website explains project's governance model
- Website does not include references to outdated, unused, or legacy tooling
Governance
Project license
- Project code is licensed
- Project license is an OSI-approved open source license
- Project does not require a contributor licensing statement or agreement
- Project does not feature code with per-file licensing
- Project code does not contain obvious inherent license incompatibilities
- Code includes notice of licensing intent
- Code includes copy of license text
Project leads
- Project has clearly identified lead maintainers
- Project has identified means of contacting lead maintainers
Governance model and processes
- Project has documented decision-making processes
- Project makes and records decisions publicly
- Project has documented processes for leadership transitions
- Project has identified various roles contributors can occupy
Release management
Release frequency
- Project has issued a release in the past 12 months
- Project releases software at consistent intervals
Release conventions
- Project releases are adequately documented
- Project uses consistent release versioning scheme
Release tooling
- Project has implemented a quality assurance process
- Project uses automated continuous integration and development tooling
Release availability
- Project releases are available from consistent download location
- Project releases software in multiple formats
Onboarding
Onboarding guides
- Project home page features quickstart guide for new users
- Project home page features quickstart guide new contributors
Onboarding practices
- Project features communication channels exclusively for new users and contributors
- Project clearly identifies opportunities for contributions of different types (code, documentation,
design, etc.)
Documentation
Documentation content and style
- Documentation appears complete
- Documentation is stylistically consistent
- Project features documentation specifically aimed at new users
- Project has thoroughly documented installation processes
- Project has thoroughly documented process of compiling source code
- Project documentation includes use case examples
Documentation practices
- Project has a dedicated team of documentation maintainers
- Project creates and maintains documentation via automated processes
Outreach
Project messaging
- Website features a project description of less than 100 words
- Project description is consistent across platforms
Outreach channels
- Project has a dedicated community outreach specialist or team
- Project provides development updates (including release announcements) consistently across all channels
- Project has a blog
- Project is active on at least one social media platform
- Project offers support via synchronous chat platform
Outreach frequency
- Project updates its blog at least once per month
- Project updates its social media at least twice per week
- Project responds to social media inquiries within 12 hours
Outreach events
- Project has a dedicated event-planning team
- Project hosts weekly or monthly community calls
- Project hosts annual conference or workshop event
- Project supports community user groups or local meetups
Contributions
Active contributors are the foundation of any open source project, so assessing a healthy project's contributor base requires more rigorous analysis. Use the tools below to get started.
Contributor affiliation
| Domain of contributor email address | Percentage of total commits from that domain in past 12 months |
| 1. (ex. redhat.com) | |
| 2. | |
| 3. | |
| 4. | |
| 5. |
(In healthier projects, no single group or organization should commit more than 55% of merged code.)
Contributor engagement
(In healthier projects, the number on the left should be larger.)
|
Number of contributors making pull requests
|
Number of contributors making pull requests |
|
Number of contributors submitting issues
|
Number of contributors submitting issues 12 |
Maintainer responsiveness
(In healthier projects, the number on the right should be larger.)
|
Average time to address issue when first raised |
Average time to address issue when first raised 12 months ago (in days) |
|
Average time to close issue or merge pull |
Average time to close issue or merge pull request 12 months ago (in days) |
