The Bus Factor: Give Every Critical Task a Second Person

By Sergey Nosov

20 October 2026

On 29 June 1994, Michael McLay of the National Institute of Standards and Technology posted to the Python mailing list under the subject “If Guido was hit by a bus?” McLay had just come from a meeting in which “the major objection to using Python was its dependence on Guido. They wanted to know if Python would survive if Guido disappeared.”

Python faced a version of that question twenty-four years later, and not because of a bus. On 12 July 2018, tired after a hard fight over one proposal, Guido van Rossum stepped down as its leader. The community would have to manage without him one day anyway, he wrote: “there’s still that bus lurking around the corner.”

Many teams have a Guido for something: the one person who can deploy, the one a customer calls, the one who knows why a setting has its value. The fix is a second person for every critical task, and the test is that the second person has done the task without help. This article covers how low the bus factor runs in real projects, where it hides beyond the code, five practices that raise it, and that test.

What the Bus Factor Counts

The bus factor is the smallest number of people who would have to leave, suddenly, before a project stalls. It also goes by the truck factor and, more kindly, the lottery factor. CHAOSS, a Linux Foundation project that defines health metrics for open source, renamed its version Contributor Absence Factor in June 2024. Announcing the change, it called the old image “a pretty morbid thought” that “was off-putting for a lot of people.”

The kinder names fit the facts better. Most people do not leave by bus. They change jobs, take a long vacation, or get promoted.

In 2022, researchers at JetBrains and Bilkent University surveyed 269 engineers about the bus factor and a related problem they called “code red.” Their definition of code red reads: “A crucial part of a project depends on too few people and the project stalls when they are sick or go on vacation.” Within the past year, 63 percent of the engineers had worked on at least one project where they felt the bus factor was at high risk of reaching zero.

How Low It Runs

In 2016, Guilherme Avelino, Leonardo Passos, Andre Hora, and Marco Tulio Valente estimated the truck factor of 133 popular open-source projects on GitHub. The projects came from the most-starred repositories in six languages, and the authors caution that their findings “cannot be directly generalized,” especially to closed-source systems.

Their method reads the commit history and credits each file to the developers with a high degree of authorship. That score rises if you created the file and with each change you made to it, and it falls as others change the file. Then the method removes the developer credited with the most files, one at a time, until fewer than half the files have an author left. The number removed is the estimate. The authors published the tool that computes it.

By that estimate, 45 projects (34 percent) had a truck factor of 1, and another 42 (31 percent) had 2. The method put about two in three projects one or two departures away from serious trouble. At the other end, the Linux kernel without its drivers came out at 57, Git at 12, and Rails at 9. The number also depends on what you count: Homebrew came out at 250 with its thousands of installation recipes, and at 2 without them.

The researchers then asked the developers. About half agreed, at least in part, that losing the named people would put their project in trouble. Most who disagreed said others could take over. Two projects had already survived the loss of their main author. In one, Homebrew Cask, the respondent named two things that helped, in the authors’ words: “comprehensive documentation” and “developers ready to transmit the rules and requirements to newcomers.”

A 2019 follow-up by Avelino and three colleagues looked at what happens when the people do leave, counting a developer as gone after a year without a commit. Of 1,932 popular GitHub projects, 315 (16 percent) lost every developer behind their truck factor. Only 128 of those projects (41 percent) survived; in each, new core developers took over. Asked in a survey what had helped, they named friendly and active maintainers most often.

A First Count from Your Repository

For a rough first look at your own code, count each author’s commits to one folder in the last year, most commits first. Run this from the repository root, in Bash or Zsh:

git shortlog -sn --no-merges \
  --since="12 months ago" \
  HEAD -- src/billing/

Keep HEAD: it selects the history behind the current commit. Without a revision, git shortlog reads standard input, not the repository, whenever that input is a pipe or a file rather than a terminal, or there is no current branch. Tested with Git 2.55, it then waits for the input to end. If no log arrives, it prints nothing and exits with status 0, as it does for a folder nobody touched or a misspelled one. An empty list proves nothing.

A shallow clone can make the list short or empty, with no warning. GitHub’s checkout action fetches “only a single commit” by default, so set fetch-depth: 0 in its with: settings before counting.

If commits stand in for contributions, the list gives you the CHAOSS metric: the smallest number of contributors responsible for half of all contributions. Count down from the top until you reach half the commits. If the counts read 41, 9, 6, and 4, the first person made 41 of the 60 commits, so the folder’s number is 1.

The list counts names, not people, and commits, not knowledge. Someone who commits under two names, such as a full name and a handle, counts as two people unless a .mailmap file joins them. Two people who share a name count as one. The 2022 study gives the example of a team “led by a senior engineer, who hardly writes code, but participates in discussions and performs code reviews.” A count of commits can miss that engineer, although “they may have the most knowledge about the project.”

Respondents in the same study warned that a named key engineer “may feel irreplaceable,” while those not named “may feel underestimated.” Read the list as a map of folders, not a ranking of people.

Where a Bus Factor of One Hides

The 2016 study notes that “Python no longer has a truck factor of one.” Yet in 2018, one role still rested on one person: the final say on proposals to change the language. Van Rossum’s message named it: “I would like to remove myself entirely from the decision process.” Since 2019, a five-person steering council has held that role.

No count of commits shows a role like that. One developer in the 2016 survey put it plainly: the truck factor “is mostly concerned with institutional memory getting lost.” No automatic system, the developer added, can account for that loss unless all project communication is public. Look in four places beyond the code:

Your future self counts too. A Clojure developer in the same survey said that “if the code is old enough, even the original author will have to approach it with essentially fresh eyes.”

How to Raise It

Five practices raise the number. Two spread the knowledge, and three spread the doing.

Spread the Knowledge

Write it down where the work lives. Put it in the README, the wiki, the ticket, or the troubleshooting guide that the alert links to: wherever the next person will look first. If you work on another organization’s system, as a contractor or consultant, write in its wiki and tracker, so the knowledge stays when you leave. Write down the steps, never the secrets: say which vault holds the credential and who can grant access to it.

The 2016 study asked developers what helps a project survive the loss of its main authors. Documentation came first, with thirty-six answers, more than twice the fifteen for an active community.

Review to learn, not only to approve. In 2013, Alberto Bacchelli and Christian Bird studied code review at Microsoft. One manager there listed, among her reasons to review, grooming “backup developers” for areas where knowledge is “too concentrated on one or two expert developers.” A senior developer named one thing reviews should bring over time: “a distribution of knowledge.” By that developer’s measure, a review that leaves you still knowing nothing about the area “was not as good code review as it could have been.”

Every review you read closely makes you a second person who knows the change. My article on the anatomy of a good code review covers the rest of what a review is for.

Spread the Doing

Pair on the hard part, once. An hour of walking someone through it moves more than a page can. Spend that hour while the expert is still there. From one of the 2022 interviews, the authors report that a departed engineer “usually provides answers with a high level of abstraction, while low-level abstraction is required.” Another interviewee said it took up to six person-months to get a project back on track. In two of the interviews, subsystems had to be rewritten from scratch.

Rotate the duty: releases, demos, on-call. Whoever does it second finds the gaps in the guide. Google’s SRE book makes the case for practice: “The hero jack-of-all-trades on-call engineer does work, but the practiced on-call engineer armed with a playbook works much better.” The book adds that Google SRE backs its playbooks with exercises such as the Wheel of Misfortune, a disaster role-play.

Two named people with access, never a shared password. Least privilege still holds; it just should not mean one person. NIST SP 800-53, the US government’s catalog of security and privacy controls, lists shared accounts among those an organization may wish to prohibit “due to increased risk.” For high-impact systems, the baseline in SP 800-53B adds enhancement IA-2(5). Where shared accounts are used, it requires “users to be individually authenticated before granting access to the shared accounts or resources.”

Control AC-2 also asks for a process to change a shared account’s credentials whenever someone leaves the group. With named accounts, a departure means disabling one account instead, though any shared secret the person knew still needs changing. My article on NIST SP 800-53 for developers covers the catalog.

Open source shows what a missing permission costs. In the 2019 survey, five of the new core developers named a lack of access to the main repository as a barrier. They needed it because the maintainers were absent or the project had been abandoned. If someone outside your team grants a permission you depend on, ask them to grant it to a second person before anyone needs it.

The Test: Someone Else Has Done It

My article on availability by the numbers ends by asking whether the way back is written down. The next question is who else can follow it. Three rules of thumb answer it.

A guide is done when someone else has followed it. The author can miss a step that feels obvious. In a 2001 study, Pamela Hinds, Michael Patterson, and Jeffrey Pfeffer had experts and beginners give instructions for a circuit-wiring task. The experts “used more abstract and advanced statements and fewer concrete statements.” Novices taught by beginners did better on that task and “reported fewer problems with the instructions.” Novices taught by experts did better on a different task in the same domain.

So keep the expert’s why, and have someone new to the task check the steps. For a risky procedure, such as a restore, run that check as a rehearsal. A guide stays done only while people keep following it; that is what rotating the duty is for.

Aim for two, not everyone. Every critical thing needs a second person who can do it. Nobody needs to know everything. A task that needs two people at once, such as a two-person approval, needs three people who can do it. Where a bus factor of one is acceptable, make that a decision, not an accident.

Thank the hero, then pair them. When one person answers every hard question, the fix is not less of that person. It is a second person beside them. Python spread the final say among five people and kept its hero. Van Rossum said he would stay “for a while as an ordinary core dev” and would still be available to mentor people, “possibly more available.” He sat on the first steering council.

A bus factor of one is not anyone’s fault. It is the team’s to-do.

The Two-Week Question

In the 2022 survey, only 19 percent of the engineers had ever worked on a project whose bus factor was communicated to them. So ask yourself, about each piece of work you do: if you were away for two weeks, starting tomorrow, what on your project would wait for you? Then ask whether anyone else could do it today. If the answer is nobody and the work cannot wait, that is a critical task with a bus factor of one.

The bus factor entry in my Software Development Principles series says the number “is best assessed qualitatively through honest team discussion,” which is what the two-week question is for. When a team asks it together, name the work, such as “the release steps,” not the colleague who holds it. If you are a project’s only engineer, the second person may sit on another team or work for the client; name the role.

Then pick one thing only you know how to do, and a second person with time to learn it. Write it down where the work lives, or walk that person through it once. A week later, check whether they have done it without help.

Checklist

Further Reading