Checklist for measuring the health of an open source project

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

(In healthier projects, no single group or organization should commit more than 55% of merged code.)

Domain of contributor email address Percentage of total commits from that
domain in past 12 months
1. (ex. redhat.com)
2.
3.
4.
5.

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
12 months ago

Number of contributors submitting issues

Number of contributors submitting issues 12
months ago

Maintainer responsiveness

(In healthier projects, the number on the right should be larger.)

Average time to address issue when first raised
(in days)

Average time to address issue when first raised
12 months ago (in days)

Average time to close issue or merge pull
request (in days)

Average time to close issue or merge pull
request 12 months ago (in days)