Skip to content
Rabin Poudyal
Page 6-1
6-1 Models

6.15Bus factor

Software and engineering

The number of people who would have to disappear before a project stalls; for a surprising share of the software the world runs on, that number is one.

Folk usage, from the old question of what happens if someone is hit by a bus; no single coiner is known. An early software example is Michael McLay's post "If Guido was hit by a bus?" to the Python mailing list on 29 June 1994. Also called the truck factor.

  1. 1Read

    McLay had just come from a meeting where, he wrote, the major objection to using Python was its dependence on Guido van Rossum, its creator; managers "weigh risk heavily" and wanted to know whether Python would survive if he disappeared. The bus factor puts a number on that worry: the smallest number of people whose loss would leave a project unable to carry on. In a 2016 study Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente estimated it for 133 popular projects on GitHub and found that 65 percent had a truck factor of two or less. The prediction is that a project with a bus factor of one lasts exactly as long as that person's health, time, money and interest.

    It drifts down on its own. Work flows to whoever knows the most, because they are fastest, so they learn more and the gap widens; writing things down always loses to shipping. In open source the cost lands on one or two people while the benefit is spread across users who pay nothing, which is the tragedy of the commons in miniature. The bus is a figure of speech. The usual causes are burnout, a new job or a slow loss of interest, and a worn-out sole maintainer is also a security risk: when they hand over control, everyone downstream inherits their judgement of the person they hand it to.

    The number is crude. Counting who wrote the code misses reviewers, operators and whoever knows why things are the way they are, and a high count can hide a single person who understands the one part that matters. Raising it costs something: two people who both know a system move more slowly than one, and adding people late to a struggling project has its own trap, Brooks's law. Not everything needs a high bus factor either. A small library you could replace in an afternoon can live with one; the question is how much depends on it and how hard it would be to replace.

  2. 2Note

    Example

    In February 2015 ProPublica's Julia Angwin reported that GnuPG (GNU Privacy Guard), widely used free software for encrypting email, relied on one man. Werner Koch had written it in 1997 and kept it going largely alone, earning about 25,000 dollars a year since 2001. In early 2013 he had been close to giving up and taking an ordinary job, and changed his mind after the Snowden revelations. After the article, donations took him past his goal of 137,000 dollars, the Linux Foundation's Core Infrastructure Initiative gave a one-time grant of 60,000 dollars, and Facebook and Stripe each pledged 50,000 dollars a year.

  3. 3Apply

    Where it applies

    For every service you run, write down who could fix it at 3 am if the usual person were on holiday, and pair or rotate until the answer is at least two names. For dependencies, look at the commit history: if one person has made nearly every commit for two years, that is a question about funding and security, not only about availability. The same goes for an AI system: the prompt chain, evaluation set or fine-tuning recipe that only one engineer understands is a bus factor of one.

  4. 4Think

    Think about it

    Which system you depend on would stop moving if one particular person left next month, and does that person know how much you rely on them?

  5. 5Log

    Applied it to something real? Log it.

  6. 6Check
    Test yourselfWhat is a project's bus factor, and why is a bus factor of one a security risk as well as an availability risk?

    The smallest number of people whose loss would stall the project. With one, the project depends on that person's health and time, and whoever they hand control to inherits everyone's trust, as the xz backdoor showed.

  7. 7Go

    Related models

    • Single point of failurepage 6-77

      A part whose failure alone stops the whole system; the dangerous ones are those nobody drew on the diagram, such as the login service, the DNS provider or the tool you would use to fix things.

    • Redundancy and slackpage 6-69

      Spare parts and spare capacity look like waste until the day they are the only thing between a fault and a failure.

    • Tragedy of the commonspage 6-107

      When many people share a resource nobody owns, each gains the whole benefit of using more and bears only a share of the damage, so the resource is overused.

    • Brooks's lawpage 6-14

      Adding people to a late software project makes it later: the new hands cost training and communication before they add output.

  8. 8See

    Seen in an incident

    • The xz/liblzma backdoorpage 9-7

      An attacker spent over two years becoming a maintainer of a compression library, then shipped a backdoor aimed at SSH (Secure Shell) logins on Linux servers. One engineer noticed logins were half a second slow.

    • Heartbleedpage 9-10

      A missing bounds check in OpenSSL's TLS (Transport Layer Security) heartbeat let anyone ask a server for up to 64 kilobytes of its memory, again and again, with nothing abnormal in the logs.

  9. 9Source

    Sources and further reading