Bus Factor
Noun · Hacker Culture
Definitions
The minimum number of team members who would have to be hit by a bus (or otherwise suddenly unavailable) before a project stalls due to lack of knowledge. A bus factor of 1 means a single departure could kill the project.
In plain English: How many people would have to leave before no one knows how to maintain the project. If the answer is 'one,' you have a serious problem.
Example: "Our bus factor on the billing system is literally one. If Dave quits, we're done."
More diplomatically called the 'lottery factor' (what if someone wins the lottery and quits?) or 'truck factor.' Improving bus factor requires active knowledge sharing: pair programming, documentation, code reviews, and rotating on-call responsibilities.
Example: 'Our bus factor on the billing system is 1. We're starting mandatory pair programming on that codebase this sprint.'
Source: mitigation strategies
Origin Story
How many team members can get hit by a bus before the project dies?
The **bus factor** is the minimum number of team members who would need to be incapacitated (the euphemistic scenario: "hit by a bus") before a project stalls due to lack of knowledge or ability. A bus factor of 1 means a single person's departure would be catastrophic.
The concept emerged from open-source project management discussions in the late 1990s and early 2000s. It formalized a fear that many projects share: critical knowledge locked in one person's head. The Linux kernel, for example, has a relatively high bus factor because many developers understand its internals, while many corporate projects have a bus factor of 1 because a single "10x developer" hoarded all the context.
More diplomatic alternatives exist: the **lottery factor** (how many people can win the lottery and quit?) or the **truck factor**. Academic researchers at the University of Passau published tools to calculate the truck factor of GitHub repositories by analyzing commit patterns and code ownership. The results are often sobering.
Coined by: Open-source community
Context: Open-source project management discussions, late 1990s
Fun fact: A 2015 study analyzing 133 popular GitHub projects found that most had a truck factor of 1 or 2, including major frameworks used by millions. The Python standard library had one of the highest truck factors, while many smaller projects literally depended on a single contributor.