The bus factor is an important thing to keep track of for both commercial and open source software development. If your bus factor is low (below two), you'll be in trouble if that developer leaves or cannot contribute any longer.
It gets worse. Not only is your bus factor probably too low for critical parts of your project, but it's in the nature of software that a small group of people make the largest impact1. In general, human performance follows a power law2, so your first few contributors are the most important.
Losing them is painful.
The Walk Score
A colleague and I were discussing the bus factor and how we could improve it. We recently improved it on several key projects from 1 to about 1.5, which we obviously wanted to increase.
I noticed, however, that I was significantly more concerned about projects that were a lot harder to work on, and less concerned about projects that were easier to work on. In fact, one of our older systems has a bus factor of 3 or 4, but is so difficult to start working on that it is as big as a business risk as an easy project with a bus factor of 1.5 is.
There is another element to the bus factor that is important to consider which I call The Walk Score.
How nice is your software neighborhood?
Imagine your software as a neighborhood. Is it a friendly, welcoming place? Or is it full of dark alleys and crimes against software development?
The higher your walk score, the more enjoyable it is to "walk around" your code. The higher your walk score, the easier it is for your colleagues to work on the project and the less dire your low bus factor becomes.
This is as important, if not more important than your bus factor. You can get away with a low bus factor if your walk score is high.
This should include maps (tutorials, examples, and overviews), be easy to get to (getting, compiling and deploying the code), and be a nice place to hang around (well written and with good tests).
After all, don't you want to live in a nice neighborhood?
Goeminne, Mathieu, and Tom Mens. "Evidence for the pareto principle in open source software activity." Magiel Bruntink et Kostas Kontogiannis, éditeurs: CSMR 2011 Workshop on Software Quality and Maintainability (SQM). Vol. 701. 2011. ↩
AGUINIS, HERMAN. "The best and the rest: Revisiting the norm of normality of individual performance." Personnel Psychology 65.1 (2012): 79-119. ↩