What is the bus factor?
Updated
The bus factor is the smallest number of people who would have to suddenly leave a project — be 'hit by a bus' — before the remaining team could no longer keep it running. A bus factor of one means a single person holds knowledge or code that no one else can readily replace, the classic key-person risk.
It is a resilience measure, not a judgment of anyone's work. A solo founder or a small team is legitimately concentrated; the point of measuring it is to make that concentration visible so it can be managed — through documentation, pairing, and spreading ownership — before a departure becomes an outage or a stalled acquisition.
How the bus factor is measured
The intuitive definition — how many people can leave before the project stops — is hard to compute directly, so practitioners approximate it from where the work actually comes from. The most common proxy is authorship concentration: attribute each line or commit to its author, then find the fewest authors whose combined share crosses a threshold (often 50% of the codebase). If one author wrote more than half the code, the bus factor is one.
Because authorship is measured from version-control identity, it captures who committed the code, not headcount. A single person may commit under several identities, and automated agents commit under their own names — so authorship concentration should be read as a signal about where knowledge sits, not as a literal staff count. It is a starting point for a conversation, not a verdict.
| Measure | What it captures |
|---|---|
| Bus factor | Fewest people whose loss would stall the project |
| Top-contributor share | Percent of the codebase written by the single largest author |
| Effective contributors | Inverse Herfindahl index (1/HHI) — the diversity-adjusted count |
| Gini coefficient | How unevenly contribution is distributed across authors |
Why technical due diligence asks about it first
In an acquisition or investment, one of the earliest questions a technical reviewer asks is: if two key people left, what would stop? A codebase that only its original author understands is a liability that no amount of feature completeness offsets — the value walks out the door with the person. High concentration also slows onboarding, concentrates outage risk, and makes the estimate of remaining work unreliable.
The remedy is rarely to hire more people quickly; it is to reduce the dependence deliberately: write down the tacit decisions, pair on the load-bearing modules, add tests that encode intent, and rotate ownership so a second person can operate each critical system. Measuring the bus factor turns 'we should document things' into a specific, trackable target.
Frequently asked questions
What does a bus factor of one mean?
It means a single person holds knowledge or wrote code that no one else can readily take over. If that person left, the project would stall until someone reconstructed what they knew. It is the highest form of key-person risk — common and legitimate for solo builders, but worth managing as a team grows.
How do you calculate the bus factor from a codebase?
Attribute each added line or commit to its author, rank authors by share, and count the fewest authors whose combined share passes a threshold such as 50%. That count approximates the bus factor. It reflects authorship identity in version control, so treat it as a knowledge-concentration signal rather than a literal headcount.
Is a high bus factor concentration bad?
Not inherently. A solo founder or small team is naturally concentrated, and that is a fact about the stage, not a defect. Concentration becomes a risk when it is invisible and unmanaged — when a single departure would cause an outage or block a deal — so the goal is to surface it and spread ownership over time.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.