Skip to content

The Open Source Checklist

About

It's easy to overlook important tasks when releasing and maintaining an open source project. This checklist helps ensure your project follows best practices for health, development, and security.

Use this checklist as a discussion starter for your team and a foundation for continuous improvement.

Archiving and Deprecating a Project

  • Should use the platform's "Archival" function. This way, it becomes read-only, including the issues board, and is flagged as inactive.
  • Should state in the README that the project is no longer maintained.
  • Should be archived if there are no maintainers.

Documentation

  • Must ensure the project includes standard Community Health Files (CHANGELOG, CONTRIBUTING, CODE_OF_CONDUCT, etc.).
    See the README.md Template Files section for a complete list.

  • Should include usage documentation and architecture descriptions relevant to the project.

  • Must ensure the project's license doesn't conflict with third-party licenses.
  • License declarations must follow the REUSE licensing specification, ensuring all materials have clear copyright information.

Naming and Trademarks Check

  • Should ensure that the project name does not conflict with an existing project or infringe on trademarks.
  • Conduct a general search engine check for the proposed project name.
  • Perform a Trademark Search.

Note: It might be perfectly acceptable to use a name reminiscent of an existing trademark - if the existing trademark is used for other services/areas and is not recognized as a well-known trademark.

People & Maintenance

  • Must ensure maintainers have education or experience with open source. For example, reading guides at https://opensource.guide.
  • Must ensure maintainers have a plan for handling merge/pull requests (code reviews, etc.).
  • Must ensure maintainers have a plan for community engagement (responding to issues, reviewing pull requests).
  • Must ensure someone is responsible for security issues.

  • Must include a Maintainer section in every project README (team, individual, or role).

  • Should establish a release plan with clear announcement and promotion strategies.

  • Should use a CODEOWNERS file for granular maintenance descriptions (complementing the README's general Maintainer section).

Project Quality

  • Must verify that the project has undergone a code review.
  • Should discuss and establish the project's testing goals and ambitions.
  • Should make it easy to use the project - documentation, examples, pre-built releases, etc.

Release and Versioning

Security

This part of the checklist is based on the Open Source Security Foundation (OpenSSF) guide for more secure open source development, version: 2023-06-14, (and companion post).

General

  • Must use two-factor authentication (2FA) or multifactor authentication (MFA) to make it harder for account takeovers.
  • Must limit merge and push rights to specific branches.
  • Must have enabled branch protection.

  • Must have a practice of signed commits.

  • Should have a basic knowledge of committers and maintainers, and must do a periodic review of those.

  • Should have automated testing and test coverage practices, including tests for negative cases, to detect bugs and secure the project.

Contribution

  • Should have a practice of code reviews.
  • Should have good readability and scope requirements to ensure new PRs are not obfuscated, and use of opaque binaries is minimized.

Dependencies and Vulnerabilities Detection

  • Must use SCA-tools in the CI pipeline to detect vulnerabilities and license incompatibilities.
  • Must use linter tools in the CI pipeline to detect vulnerabilities and bad development practices.
  • Must use secret scanning tools to detect secrets (passwords, logs, tokens).
  • Must use automated tooling to monitor dependency updates for critical vulnerabilities.

  • Must have maintenance to quickly handle updating vulnerabilities.

  • Should use SAST-tools in the CI pipeline to detect potential vulnerabilities and bad software practices.

  • Should evaluate the health of every new direct project dependency that is added to the project.
  • Should prefer using package managers (at the system, language, and container level) for automatic and consistent dependency updates.

Publishing

  • Must produce an SBOM (Software Bill of Materials) for the project so that end-users and systems can verify vulnerabilities and license incompatibilities.

  • Must limit software publishing rights of artifacts.

  • Should sign any project releases.

  • Should make it easy for end-users to upgrade to new releases. Use semantic versioning, support stable APIs, and flag deprecation early.

Policy

  • Must have a security policy in place - it should contain information about where to report non-disclosure vulnerabilities and the process regarding the report.

Secure software practices and tooling from OpenSSF and OWASP:

Tooling

Guides

Workflows

Specifications and Standards to Follow

The following will help your Open Source Project to be collaborative, reusable, accessible, and up-to-date.