One Human, Five Systems: Mapping the Single Points of Failure Hiding in Your Maintainer Roster

The Org Chart Nobody Wrote

Every open-source project has an org chart, even if it exists only in the collective head of the team. The trouble is that the informal version — the one that reflects who actually knows what — rarely matches the contributor graph on GitHub. A project can list forty contributors and still be one bad commute away from losing its database migration process, its hosting credentials, and its only person who can decode the billing dashboard.

This is concentration risk, and in open-source infrastructure it behaves differently than in a company. A startup loses an employee and hires a replacement. An open-source project loses a maintainer and inherits a mystery. The commit history tells you what changed. It almost never tells you why, and it never tells you which of the eleven things that person silently carried will fall first.

Knowledge Redundancy Is Not Code Redundancy

The open-source ethos treats replication as the default defense. Fork the repo, mirror the docs, spin up a staging environment. Code is cheap to copy. What is brutally expensive to copy is the decision context: why the connection pool is sized at 47, why the staging cluster points at a particular US-East region, why the renewal invoice routes through a personal email address.

Consider the pattern repeated across countless mid-sized infrastructure projects. One person is the de facto maintainer of the storage layer, but they are also the only one who understands the Terraform that provisions it, the only one who answers user reports in the support channel, and — because someone has to — the only one managing the donation account that pays for the CI runners. Four roles, one human. No policy change, no refactor, no amount of automated testing addresses that exposure.

The Bus Factor Audit

We propose a simple exercise, runnable in an afternoon, that any project can perform on itself. We call it a bus factor audit, and it has three passes.

Pass one: inventory the systems. List everything the project operates, not just what it ships. Include the CI configuration, the artifact repository, the domain registrar, the cloud accounts, the support channels, and any financial or legal plumbing. Most teams discover two or three systems they forgot they owned.

Pass two: map the humans. For each system, name every person who could independently operate it tomorrow without asking questions. Be honest. "Everyone can edit the docs repo" is not the same as "two people know how the docs deploy." A system with fewer than two qualified humans is a red flag; a system with zero is an outage waiting for a calendar date.

Pass three: map the decisions. Some knowledge isn't tied to a system but to a history — why a license was chosen, why a breaking API change was accepted, why a major sponsor's requirements shaped the roadmap. These decisions live in heads, mailing list archives, and the occasional DM. If only one person can explain a decision, the project cannot legitimately revisit or defend it later.

The output is a spreadsheet, unglamorous but clarifying. We have yet to see a project run this exercise and come away without at least one uncomfortable row.

What to Do With the Findings

An audit without remediation is just anxiety in tabular form. The fixes, ranked roughly by effort:

• Record, don't lecture. Screen-capture walkthroughs of operational tasks — rotating a credential, restoring a backup, reconciling the budget. Imperfect video beats perfect memory.
• Break the credential monopoly. Shared access through an organization account or a hardware-key policy removes the scenario where the domain registration expires because one person changed jobs.
• Rotate the support desk. Even a two-person rotation, switching monthly, converts a hero into a process.
• Write the decision log. A single DECISIONS.md file, appended whenever something non-obvious is settled, is the cheapest institutional memory available.

None of this requires a foundation grant or a governance overhaul. It requires the existing team to spend a meeting admitting what everyone already suspects.

The Scarcest Resource

Open-source projects compete for funding, for contributors, for mindshare. But the audit makes plain that the genuinely scarce resource is redundant knowledge — a second person who has seen the weird failure mode, a third person who knows where the money comes from. Code forges make repositories abundant. They do nothing to duplicate understanding.

Run the audit before you need it. The best time to discover your single point of failure is while that point of failure is still around to answer questions.