Open source maintenance playbook

An open source maintenance playbook for any project you publish for others to use, in any language. It covers a library, a command-line tool or a whole app on a public code host. Each rule says what to do, why it matters and how to check it.

The chapters follow the life of a project. First come the licence and the copyright notice in every file. Then come how people contribute, who holds the keys, and how decisions are made. Next are releases that people can verify, private vulnerability reports, CVE numbers and advisories. That chapter also covers open source stewards under the EU Cyber Resilience Act. After that come the checks on the project's own supply chain, issue triage, funding, and how to stop a project cleanly.

Start with Choose an OSI-approved licence before the first release. Code without a licence is not open source, whatever the README says. Then read Keep at least two people who can publish before you need a fix out while you are away.

Some topics have their home elsewhere. Using other people's open source is in Lock and audit dependencies, Review every new package and List the licences of the code and every dependency. Version numbers, deprecation and support periods for libraries are in the engineering playbook's Libraries and SDKs. Publishing without stored tokens is in Publish your packages without stored tokens.

Chapters

1. Licences and copyright

   Pick one OSI-approved licence, ship its text, name it by SPDX identifier in every file and in the package, and keep other people's notices intact.

   • Required 1
   • Recommended 3
   • Avoid 2

2. Contributions

   Tell people how to contribute and behave, record their right to give you the code, and review outside changes to build files and test data.

   • Recommended 5

3. Maintainers and governance

   Keep two people who can publish, write down who decides and who holds each key, vet people before granting rights and retire unused rights.

   • Required 1
   • Recommended 5

4. Releases

   Build each release from its tag in CI, attach signed provenance, publish only the files from that tag, and let a second maintainer approve it.

   • Required 1
   • Recommended 3

5. Vulnerabilities and advisories

   Take reports and fix in private, get a CVE and publish advisories tools can read. Know the duties of open source stewards under the Cyber Resilience Act.

   • Required 2
   • Recommended 6

6. Project supply chain

   Score the repository with the OpenSSF Scorecard every week, keep binaries out of git, test the oldest dependency versions you allow and earn a badge.

   • Recommended 3
   • Optional 1

7. Issues and triage

   Ask for the facts a bug report needs, answer within a set time and label each issue by type and status. Never close issues just for being old.

   • Recommended 3
   • Optional 1
   • Avoid 1

8. Funding and the end of a project

   Say who pays for the project and what they get. When you stop, hand it over or archive it with a notice, and never delete versions people use.

   • Recommended 2
   • Avoid 1

All 41 rules on one page

This is a lot to check. An Expert can check it for you.

Related playbooks

• Supply chain and setup

  In the Adversarial testing playbook. Your project is someone else's dependency. Publish without stored tokens, keep secrets from fork builds and ship a bill of materials.

• Libraries and SDKs

  In the Engineering playbook. Users upgrade only when version numbers keep their promise. Declare the public API, check each release against it and deprecate first.

• Product and sector laws

  In the Compliance and governance playbook. Companies that ship your code face the Cyber Resilience Act. Know what they must report, and when advisories are due.

• Due diligence

  In the Codebase takeover playbook. Buyers and new teams read your licences and history. See what a due diligence review checks before it reaches you.