In 2016, four researchers computed the truck factor — the bus factor under its other name — of 133 popular GitHub projects and found that 65% of them ran on two developers or fewer [R2][R3]. Thirty-four percent ran on exactly one [R4]. Then they did the thing almost nobody does with a metric: they emailed the developers the algorithm had named and asked whether it had got it right. Eighty-four percent agreed, or partially agreed, that it had found the right people [R7]. Only 39% thought losing those people would actually put the project in trouble [R8].
Both numbers come from the same survey, in the same paper, about the same projects. That gap is the whole story. The bus factor is a good instrument for finding where knowledge has pooled. It's a much weaker instrument for telling you how much trouble you're in.
The bus factor — also called the truck factor — is the number of developers a project would have to lose before it is in serious trouble [R1]. In the standard algorithm it means one specific thing: the number of top authors you must remove before the remaining authors cover less than 50% of the project's files [R10].
Key takeaways
The definition is older than the paper and deliberately blunt: the truck factor is "the number of people on your team that have to be hit by a truck (or quit) before the project is in serious trouble" [R1]. Everything interesting is in how you turn that into arithmetic.
Avelino, Passos, Hora and Valente did it on a corpus of 133 popular GitHub projects holding more than 373,000 files, 41 million lines of code and over 2 million commits [R2]. Their headline result: 87 systems, 65% of the corpus, had a truck factor of two or fewer [R3]. Forty-five systems (34%) sat at exactly 1, including mbostock/d3 and less/less.js; forty-two (31%) sat at exactly 2, including clojure/clojure, jashkenas/backbone and elasticsearch/elasticsearch [R4]. The quartiles were 1, 2 and 4 [R5]. At the other end, torvalds/linux measured 57, android/platform_frameworks_base 19, git/git 12 and rails/rails 9 [R6].
The distribution is trivia. The mechanism is what you'd be adopting if you ran this on your own repositories, and it works in three moves.
First, score authorship per file. Each developer gets a degree of authorship for each file from a linear model: DOA = 3.293 + 1.098 × FA + 0.164 × DL − 0.321 × ln(1 + AC), where FA is first authorship, DL is the number of changes that developer made to the file, and AC is the number everyone else made [R9]. Writing the file first counts heavily. Coming back to it counts a little. Other people touching it erodes your claim, but logarithmically, so the twentieth external change hurts far less than the second.
Second, decide who counts as an author at all. A developer is an author of a file only if their normalised degree of authorship is above 0.75 and their absolute score is at least 3.293 [R11]. That threshold isn't a round number picked for elegance: the authors report 0.75 aligned results with manual inspection better than 0.50 did [R11].
Third, remove people until the system breaks. The algorithm rests on an explicit coverage assumption: "a system will face serious delays or will be likely discontinued if its current set of authors covers less than 50% of the current set of files in the system" [R10]. So it greedily removes whichever remaining author owns the most files, recomputes coverage, and repeats. The number of removals it takes to push coverage under 50% is the truck factor [R10].
Read that assumption again, because it does all the work. The number isn't a measurement of how badly you'd suffer. It's a measurement of how few removals it takes before authored files stop covering half the repository. Whether that constitutes "serious trouble" is an assertion the algorithm makes on your behalf — the same failure mode as any other engineering metric that claims to predict delivery.
The 2016 authors validated their estimates by asking the developers, which is why this paper is worth more than the number it produced.
They contacted 114 systems and got answers covering 67, a 59% response rate [R7]. On identification the algorithm did well: developers of 49 systems, 84% of valid answers, agreed or partially agreed that the named truck-factor authors were in fact the main authors of their system [R7].
Then came the second question. Would the project be in trouble if it lost those people? Developers of 24 systems (39%) agreed, 6 (10%) partially agreed, developers of 27 systems (43%) disagreed, and 5 (8%) were unclear [R8]. More respondents rejected the consequence than accepted it outright.
The free-text answers are more useful than the percentages — and both of the ones below were counted as agreement [R8]. An SFTtech/openage developer: "If both of us left, the project would be kind of unmaintained." A bitcoin/bitcoin developer, answering the same question: "If Wladimir or Pieter left, it would be a serious loss, but not fatal I think." The second is hedged nearly to the point of contradicting itself, and it still sits in the same bucket as the first. Both developers are probably right about their own project; the bucket is doing a lot of flattening.
One reply from kivy/kivy names the structural flaw directly: "Yes and no, historically yes, currently no, a team has been picking up the activity, your analysis seems to be biased on capital (existing files) rather than activity (current commits)." The algorithm weighs who wrote the code that exists, not who's showing up on Tuesday. A clojure/clojure developer supplies the other half: "if the code is old enough, even the original author will have to approach it with essentially fresh eyes." Ownership decays without anyone leaving, which is the same decay behind rewrite, refactor or replace decisions on legacy systems.
So the output is a shortlist of names carrying 84% credibility [R7] and a risk verdict carrying roughly coin-flip credibility [R8]. Treat it accordingly. The names are the finding. The alarm is a hypothesis you still have to test by talking to the people on the list.
Three years later, largely the same group went looking for the events themselves rather than the risk score.
The 2019 study by Avelino, Constantinou, Valente and Serebrenik analysed 1,932 popular GitHub projects, arrived at by taking the 500 most-starred non-fork repositories in each of six languages, then discarding 677 with lost migration history, 338 with under two years of activity and 53 that weren't software units [R13]. That's a much larger sample than the 2016 study's 133 projects, and it reports a different concentration profile: 57% of the 1,932 projects had a truck factor of exactly 1 and 25% exactly 2, the highest measured being 26, for edx/edx-platform [R18]. Keep the two apart when you quote them. The 34%-at-one figure belongs to the 133-project 2016 corpus [R4]; the 57%-at-one figure belongs to the 1,932-project 2019 corpus [R18].
The definitions are stricter than the folklore. A developer counted as having abandoned a project if their last commit occurred at least one year before the most recent repository commit; the authors tested 3 months, 0.5, 1, 1.5 and 2 years and chose one year because it produced the highest harmonic mean of precision and improvement, at 66% [R16]. A project counted as Active while at least one truck-factor developer remained active, and Inactive once all of them had abandoned it. It counted as having survived only if it moved from Inactive back to Active with respect to its most recent detachment, with the truck factor recomputed yearly from repository creation [R17].
The result: 315 of the 1,932 projects (16%) lost their entire truck-factor developer set [R14]. Of those 315, 128 (41%) survived by attracting at least one new truck-factor developer who took over maintenance [R15]. In 86% of the recoveries, exactly one new person did it [R20]. Sixty-six percent of all detachments happened in projects whose truck factor was exactly one, and 88% of affected projects went through only a single detachment event across their entire history [R19].
Two caveats keep the 41% honest. Recovery isn't passive: of 33 surveyed developers who took over after the original truck-factor developers left, 77% were fully or partially aware of the project's discontinuation risk before making the contributions that revived it [R21]. Somebody knew, and stepped in. And the cheerful number shrinks when the sample grows. A 2024 replication covered 36,464 GitHub projects — a different, far larger corpus than the 1,932 projects above. In that sample, 89.65% had lost their entire core team at least once [R22]. Seventy percent of those losses happened inside the project's first three years [R23]. Only 27.07% ever attracted a replacement core developer [R24], materially below the 41% recovery rate measured on the 2019 sample [R15].
Losing your only expert is a serious event with a recovery rate somewhere between one in four and two in five, depending on which sample you trust [R15][R24]. It is not the extinction event that "bus factor of one" implies.
Here's the finding most bus-factor advice leaves out, and it doesn't come from GitHub at all.
Bird, Nagappan, Murphy, Gall and Devanbu examined ownership and failures across Windows Vista and Windows 7, built by more than 2,000 developers, and concluded that "high levels of ownership, specifically operationalized as high values of Ownership and Major, and low values of Minor, are associated with less defects" [R25]. Their terms are precise: a Minor Contributor has changed a component but holds under 5% of its changes, a Major Contributor holds 5% or more, and Ownership is the share held by the single highest contributor [R26]. More concentration, fewer defects.
Their recommendations follow from that, and they aren't what a naive bus-factor reading would produce: review changes by minor contributors with more scrutiny, preferably by a major contributor; have would-be minor contributors communicate the desired change to a developer experienced with that component rather than making it themselves; and give QA priority to components with low ownership [R28]. That is advice to reinforce concentration in the short run, not to dissolve it.
One nuance rescues this from sounding like a defence of hoarding. When a component has a minor contributor, that developer is a major contributor to a component connected by a dependency roughly half the time [R27]. Most low-ownership edits come from neighbours reaching across a boundary, not from strangers.
I'm not going to resolve the tension, because the evidence doesn't. Bird et al. bound their own result: "Microsoft employs strong ownership practices and our results are much more likely to hold in other industrial settings where similar policies are in place" [R29]. Concentration is a position, not a defect. It buys quality now and costs continuity later, and the truck factor measures only the second half of that trade. If you spread ownership across a component to move a number, expect to pay for it somewhere, decide in advance where, and know what you'll monitor in production to catch it if you're wrong.
Run two bus-factor tools over the same repository, get two answers, and neither is necessarily broken. The trouble starts in the complexity class.
Computing the bus factor accurately is NP-Hard under established formalisations, and the widely adopted degree-based heuristic — removing people in decreasing order of how many tasks they touch — can yield severely inflated estimates [R43]. That heuristic is the intuitive one. It's also the one most likely to hand you a scarier number than the truth.
The empirical work agrees. Rigby, Zhu, Donadelli and Mockus modelled knowledge loss the way finance models portfolio risk, running Monte Carlo simulations of disaster loss scenarios, and stated plainly that "simplistic estimates of the 'truck factor' exaggerate the potential for loss" [R30]. Their framing measures how much source code actually ends up orphaned, and how likely that is. It found projects susceptible to losses more than three times the expected loss, with historical simulations showing susceptibility to over five times [R31]. Exaggerated headline, real tail. Both things.
Tool-level error is easy to demonstrate. Evaluated against engineers' own estimates on 13 real JetBrains projects, a multimodal algorithm adding code-review and meeting data reached a mean absolute error of 5.46 against 5.80 for the version-control-only baseline, with an F1 of 0.48 for identifying key engineers on the eight of those projects that supplied key-engineer lists [R41]. In two of those thirteen projects, the version-control-only baseline named as a key developer someone whose last commit was more than 18 months old [R42]. Identity resolution adds its own noise. The 2019 study resolved aliases through a GitHub API mapping from commit e-mail to account rather than name matching. It still found a median of 11% aliases per project [R46] — roughly one in nine apparent contributors in a raw git log is a duplicate.
The "Bus Factor In Practice" authors, who built one of these tools, are the soberest voices in the corpus: "The tool should never be perceived as an ultimate arbiter on the bus factor (or any other health metric) of a project. It should be used as an additional source of information on the project that allows condensing scattered information about the code ownership into a small description with an inevitable loss of context" [R40].
One more limit, and it's structural: apart from the Windows study [R25] and the JetBrains work [R41], essentially all of this measurement is on public GitHub repositories. Whether the same patterns hold inside a closed-source codebase with a payroll behind it is not something these samples can tell you. Your codebase is in none of them.
Stop trying to produce one integer for the organisation. Measure knowledge concentration where it actually costs you: coverage on the files that matter.
The coverage assumption is already sitting inside the algorithm [R10], so use it directly instead of the number it exports. Pick the systems where an outage costs you money or credibility. For each, list the files that carry that behaviour, and ask how many people hold a real authorship claim on them. That gives you a per-system answer, which is the granularity practitioners want anyway. Asked where bus factor should be computed, 269 surveyed engineers split 40% team-level, 39% project-level and 16% module-level. Of those same 269, 61% wanted the names of key engineers and the identity of critical low-bus-factor modules reported alongside the number itself [R39].
Then name successors. Rigby et al. adapted coordination-requirements matrices to recommend the correct successor for a departing developer 34% to 48% of the time, and found that having designated successors reduced expected loss by as much as 15% [R32]. Half-right recommendations plus a 15% reduction isn't magic, but it's a concrete instrument, and unlike a headline integer it produces an action: for each critical component there is a named second person, and you can check whether that person's degree of authorship is non-zero.
For the intervention itself, the developers surveyed in 2016 already said what works. Asked which practices most attenuate the loss of top-ranked authors, they named documentation most often at 36 answers, then an active community (15), automatic tests (10), code legibility (10), code comments (7), founding or paid developers (5) and popularity (5) [R12]. Documentation and tests, by a distance.
Two cautions. The names list is management information, not a team-wide broadcast: the "Bus Factor In Practice" authors record real social costs, including too much attention landing on the implicated modules, a named key engineer feeling irreplaceable in a way that damages their relationship with employer and teammates, and unnamed engineers feeling underestimated about their role [R40]. And most engineers have never seen any of this done — 51% of the 269 surveyed knew what the bus factor is, but only 19% had worked on a project where it was communicated to them [R35], even though 63% had spent time in the past year on a project they felt carried a high risk of the bus factor reaching zero [R36].
If you've inherited a system and don't yet know which files matter, the static-review pass comes before any of this — start with a code audit checklist.
Once you have the list, the remediation is unglamorous and almost entirely mechanical. Write the tests that pin behaviour only one person can currently explain. Document the two subsystems nobody else has opened. Instrument the paths whose failure modes live in one head. That's knowledge extraction: well-specified, delegable work that never wins a sprint. It is also exactly the shape of work that ships predictably in small batches.
Be precise about what an outside engineer does and doesn't fix here: a subscription engineer does not reduce your key-person risk by existing. It only moves if someone is pointed at the extraction work your own team keeps deferring, which is the shape of work Dev On Demand is built for. A single stream is $3,495/mo and a dual stream $6,795/mo, running on a 3-day task cycle with daily async updates and a task-by-task approval gate, with 1 dedicated AI-augmented engineer assigned the same business day and a 5-day first ship. If you want evidence before commitment, Proof of Quality is one real task you judge before subscribing. There's a 5-day replacement guarantee, and you can cancel any time — no lock-in, no notice period required.
Whether or not you buy anything, here's the move that costs nothing this week. Take the two systems you'd least like to lose and ask the people who own them a single question: what would you have to write down before you could take a month off? Then have them write it down. That document, not the integer, is the measurement.
A low bus factor means the algorithm found that removing one or two top authors drops authored coverage below 50% of the project's files [R10]. It does not confirm a crisis. When the 2016 authors asked developers of the 133 projects whether losing the named people would put the project in trouble, 39% agreed, 10% partially agreed, 43% disagreed and 8% were unclear [R8].
It is a serious event, not an automatic extinction event. In the 2019 study of 1,932 GitHub projects, 16% lost their entire truck-factor developer set, and 41% of those attracted at least one new truck-factor developer who took over maintenance [R14][R15]. A separate 2024 replication across 36,464 projects found a lower recovery rate of 27.07% [R24]. Recovery is also not passive: of 33 surveyed developers who took over after the original truck-factor developers left, 77% already knew the project was at risk of discontinuation [R21].
Computing the bus factor accurately is NP-Hard under established formalisations, and the widely used degree-based heuristic can yield severely inflated estimates [R43]. Data quality compounds it: the 2019 study still found a median of 11% aliases per project after resolving identities through the GitHub API [R46], and on 13 real JetBrains projects a multimodal algorithm reached a mean absolute error of 5.46 against 5.80 for the version-control-only baseline [R41].
No, and the evidence pulls in two directions. Studying Windows Vista and Windows 7, built by more than 2,000 developers, Bird et al. concluded that high levels of ownership "are associated with less defects" [R25], and recommended reviewing minor-contributor changes more closely and giving QA priority to low-ownership components [R28]. They also bound the result to organisations with strong ownership practices like Microsoft's [R29]. Concentration buys quality now and costs continuity later; the truck factor only measures the second half.
Asked which practices most attenuate the loss of top-ranked authors, the developers surveyed in 2016 named documentation most often at 36 answers, then an active community (15), automatic tests (10), code legibility (10), code comments (7), founding or paid developers (5) and popularity (5) [R12]. Naming successors also helps: Rigby et al. recommended the correct successor 34% to 48% of the time and found designated successors reduced expected loss by as much as 15% [R32].
