BreakPoint Drop

Glossary

Open source adoption glossary

30+ terms every developer, maintainer, and engineering manager should know. The vocabulary behind the abandonment crisis and the adoption network.

adopt-me full page →

A GitHub topic (and WordPress convention) that signals a project is looking for a new maintainer. See the adopt-me concept page. See the related page.

ADOPTME

A machine-readable signal in the CPAN permissions file. The pseudo-user ADOPTME in the permissions list means the project is officially up for adoption. See the related page.

archived full page →

A formal end-of-life state. On GitHub, an archived repo is read-only: no commits, no issues, no PRs. See the project lifecycle concept page. See the related page.

BDFL

Benevolent Dictator For Life. A single person who has the final say on a project's direction. Python was the canonical BDFL project under Guido van Rossum until 2018. See the governance blog post. See the related page.

break point

The 30-day window between when a project is dropped on BreakPoint and when a new maintainer typically files their first PR. Median break point: 23 days. See the related page.

bus factor full page →

The minimum number of contributors whose sudden departure would cause a project to stall. Bus factor 1 = one person away from dead. The 2024 Harvard / Linux Foundation study found a median bus factor of 1 for the top 100 OSS packages. See the bus factor concept page. See the related page.

charter maintainer

The maintainer who originally started a project. Often the person who drops it on BreakPoint. May or may not still be involved after the handoff.

contributor

Anyone who has submitted a PR, filed an issue, or otherwise engaged with a project. Distinct from a maintainer (who has commit access and decision-making authority). See the contribute blog post. See the related page.

co-maintainer

A maintainer who shares commit access and decision-making authority with the lead maintainer. A project with 2+ co-maintainers is healthier than a bus-factor-1 solo project. CPAN's HANDOFF model is the gold standard for co-maintainer handoff.

deprecated full page →

An official signal that a package is no longer recommended for new use. Different ecosystems have different mechanisms: npm deprecate command, PyPI development_status = 7 (Inactive), Packagist 'abandoned' flag, RubyGems 'is_outdated' warning. See the responsible abandonment guide. See the related page.

ecosystem

A language-specific community with its own package registry, conventions, and tools. The Python ecosystem (PyPI + pip + setuptools + PyPI classifiers) is distinct from the JavaScript ecosystem (npm + package.json + npm deprecate) even though both share the adopt-me GitHub convention.

fork full page →

A copy of a repository. Distinct from adoption: a fork starts from zero (new URL, no stars, no existing users), while adoption preserves the original URL. The first option for adoption is the original repo; forking is the fallback. See the related page.

governance full page →

The decision-making structure of a project. The four common models: BDFL (one person, final say), foundation (non-profit owns the project), vendor-led (a company owns the project), community-led (no single owner). See the governance blog post. See the related page.

HANDOFF full page →

A maintainer has decided to step down and is looking for a specific successor. The CPAN pseudo-user HANDOFF in the permissions file is a machine-readable signal. See the project lifecycle concept page. See the related page.

incubation

A project moves to a foundation (Linux Foundation, Apache, CNCF) and gains the foundation's legal infrastructure, governance, and funding. The Kubernetes Ingress NGINX retirement (Nov 2025) showed what a graceful foundation-managed handoff looks like.

looking-for-maintainer full page →

A shields.io badge that signals a project is looking for a new maintainer. The equivalent of the adopt-me topic for the README. See the maintainer handoff guide. See the related page.

maintainer full page →

A contributor with commit access and decision-making authority. Distinct from a contributor (who only files issues and submits PRs). A project with 2+ maintainers is healthier than a bus-factor-1 project.

maintainer handoff

The process of transferring maintainership of a project from one person to another. The 5-step playbook is in the maintainer handoff guide. See also: adoption. See the related page.

NEEDHELP

The project still has a maintainer, but they need co-maintainers. The project is not at immediate risk of abandonment; the maintainer is just asking for help. See the project lifecycle concept page. See the related page.

next steps

The list of what should be worked on first by the next maintainer. The single most useful document in a handoff. See the document blog post. See the related page.

open adoption

A maintainer publishes a 'looking for new maintainer' notice and accepts applications. Distinct from chosen successor (where the maintainer picks a specific person). See the maintainer handoff guide. See the related page.

open source full page →

Per the OSI definition: a license that allows anyone to read, modify, and redistribute the code for any purpose, including commercial use. Distinct from source-available licenses (BSL, SSPL, Elastic). See the open source vs source available blog post. See the related page.

orphan

A package whose maintainer is unreachable. PEP 541 (Python) and the GitHub successor setting (for deceased maintainers) are the formal mechanisms for handling orphans.

pull request (PR)

A proposed change to a repository. The standard mechanism for contributing code to an open source project. See the contribute blog post and the handle pull requests blog post. See the related page.

release

A versioned snapshot of a project. The cut-a-release process is documented in the release notes blog post. A regular release cadence is one of the signals of a healthy project. See the related page.

renovate-bot

An automated dependency update tool. Renovate, Dependabot, and similar tools create PRs that update dependencies. These PRs are typically auto-mergeable but can flood the maintainer's queue.

selected successor

A specific person the maintainer has chosen to take over the project. The opposite of open adoption. See the maintainer handoff guide. See the related page.

supply chain risk

The risk that a critical dependency your product depends on becomes unmaintained, compromised, or deprecated. The 2026 Reptile.haus analysis puts the bus-factor-1 annual loss rate at 36%. The XZ Utils backdoor (CVE-2024-3094) proved the attack vector. See the supply chain report. See the related page.

supply chain attack

A compromise of a software dependency that propagates to all projects that depend on it. The XZ Utils backdoor (CVE-2024-3094) was a supply chain attack on a near-universal Linux dependency. See the supply chain report. See the related page.

truck factor

The European alternative to bus factor. Same concept: the minimum number of people whose loss would cause a project to stall.

Related reading

Companion

FAQ

20+ Q/A pairs grouped by topic.

Concepts

The concept library

The canonical explainers behind the vocabulary.