The Bus Factor

A project has a bus factor of n if it would survive losing any n−1 of its contributors but die when n are gone simultaneously. A bus factor of one is the dangerous case: a single person knows something nobody else can recover. Their absence breaks the project.

The term has no canonical origin. The earliest plausible attribution is to Michael McLay in a 1994 Python mailing list discussion; the related phrase "truck factor" appeared independently in the same era. Both spread through open-source communities in the late 1990s. The earliest published academic study is Cosentino, Izquierdo & Cabot (2015), who measured bus factors across thousands of GitHub repositories and found that roughly 65% of major open-source projects have a bus factor of two or less.

A blunt measure, but blunt enough to act on.

At a glance

Roughly 65% of major open-source projects sit at bus factor 1 or 2.

How it is measured

There is no single accepted formula. Three common approximations:

Commit-share threshold. List contributors by lines-of-code or commits over the last N months. Bus factor = smallest number whose removal would leave less than some fraction (often 50%) of the project's recent activity covered.
File-ownership coverage. For each file, identify primary authors. Bus factor = minimum number of authors whose removal leaves more than some fraction of files unauthored.
Knowledge-mapping interviews. Walk the team through the system. For each subsystem, list the people who could fix a production fire in it. Bus factor = the smallest set whose loss would orphan a critical subsystem. This is the most accurate and the least scalable.

In practice, the file-ownership variant is what tools like git-bus-factor and the Adam Tornhill-style "code maat" analytics produce. They are useful as conversation starters, not as final numbers.

Why bus-factor-one is so common

Three forces concentrate knowledge:

Specialisation discounts. It is faster, this week, for the person who already knows the subsystem to fix the next bug in it. The faster path teaches no one else. Compounded over years, one person becomes the only person.
Documentation as overhead. Writing down what you know is unpaid work in most organisations. The person who could most usefully document is the busiest person, because they are the one nobody else can substitute for. The asymmetry is self-reinforcing.
Hero culture. Systems that reward firefighters punish documenters. The same incentive that produces the irreplaceable expert produces a single point of failure.

The pattern is not malice. It is local-optimisation pressure. Every individual decision is rational; the aggregate is fragile.

Mitigations that actually work

Not all "spread knowledge" advice is equal. The mitigations that survive contact with real teams:

Rotating on-call. Once an engineer has had to debug a subsystem at 3 a.m. on call, they own it for life. On-call rotation forces incidental learning of systems people would otherwise avoid.
Pair programming with rotating pairs. Specifically rotating; static pairs just produce two-headed monsters with the same bus factor.
Mandatory code review by someone other than the author's regular reviewer. Code review is reading time. Reading is knowledge transfer. Forced rotation prevents the review graph from collapsing to a tree.
"Stranger in the codebase" exercises. Periodically, give an engineer who has not touched a subsystem a small feature in it, with the original owner explicitly forbidden to do the work. Painful, slow, irreplaceable.
Decision logs and architecture-decision records (ADRs). Documentation works if it captures why, not what. Future-you and future-them want to know what trade-off was made and what the alternative was.

What does not work: requiring exhaustive documentation by fiat. Documentation that is only read once a year by the original author bit-rots into noise.

Beyond software

The bus factor concept generalises everywhere knowledge concentrates.

Lab equipment. Old mass spectrometers, electron microscopes, and bespoke synthesisers often have a single person who can keep them running. The retirement or death of that operator can mothball an instrument worth millions for years.
Languages. The death of the last fluent speaker of concept color language-style minor languages is a civilisational bus factor of one. Each extinction event is also a loss of concept distributed cognition encoded in vocabulary.
Institutional knowledge. Many state archives, religious lineages, and craft traditions have bus factors so low that the death of one elder ends a continuous transmission of centuries. The concept svalbard seed vault is a deliberate civilisational answer to this — backup against bus-factor-one extinction events.
Lineage holders. Tantric and Vedantic traditions have explicit lineage charts; succession is the institutional mechanism for raising the bus factor of the transmission. See overview vedanta.

Why this has to do with other realms

The bus factor is a special case of concept power laws applied to knowledge distribution. In most organisations the contribution distribution is Zipfian (see concept zipf law): a few people do a lot of the work. The bus factor is the operational consequence of that distribution combined with mortality.

It also touches concept compounding: the cost of low bus factor compounds. Every week the single expert continues to be the only expert, the cost of their absence grows because the system they alone understand has grown too.

In open source it explains why "permissive licence + healthy community" is a more durable design than "permissive licence + brilliant single maintainer." Permissive licences solve legal forking; only community solves cognitive forking.

An open question

Is there a measurable bus factor for modern AI systems? A trained transformer's weights are technically a perfect record of one frozen state of knowledge, but the training pipeline, the data curation choices, and the evaluation infrastructure that produced them often live in single heads. If the team that trained GPT-4 or person karpathy's nanoGPT lineage disappeared, how many years would it take to reproduce the result from public artefacts alone?

Key sources

Cosentino, Izquierdo & Cabot (2015), "Assessing the bus factor of Git repositories" — first large-scale academic study.
Avelino, Constantinou, Valente, Serebrenik (2019), "On the abandonment and survival of open source projects" — successor study.
The original Wiki page (c2.com) entry on "TruckNumber" preserves some of the early 1990s discussion.

Abhishek's take

I see this on the floor when a single planner understands why a QR tag, a fit note, and a replenishment rule sit together. The tools I wrote reduce the risk only when the decision trail is visible, not when the code is clever. If one buyer cannot explain a 100-day lead-time bet to another buyer in five minutes, the bus factor is still one.

Abhishek