Look Both Ways

It's a pretty violent metaphor, this notion of what happens to your open source software project if one or more of its members might get hit by a bus. Or a truck. Or whatever motor vehicle of doom happens to be barreling down the road of fate. At first thought, one might simply want to urge people to look both ways when crossing the street.

But the bus factor is a real concern for many open source projects, because too often a lot of the work finds itself in the hands of just a few people, who in turn become very critical to the project's success.

Before you dismiss the idea of the bus factor, you should be aware that there are many far more realistic scenarios that can invoke this situation. Euphemistically (and much less more violently), the term "lottery factor" can be used as a substitute. Someone winning the lottery and running off to Bora Bora isn't very realistic either, but getting a new job, starting school, building a new relationship… there are countless real-life situations that can cause a person to leave or reduce their presence within an open source project.

Is There a Problem?

The first thing you need to determine is if you have a bus factor problem. Anecdotally, your project may be small enough for you to look around and imagine "what would happen if so-and-so left?" If you think the project could survive or even be okay without that person, then they won't count against your bus factor. What you are looking for is the number of people who do have critical roles in your project—to the point where the project might have to make adjustments for the departure of one, but the project would be seriously hurt by the departure of all.

The good news is, the more people you find, the better off your bus factor becomes. If there are five people who maintain critical roles in your project, your project has a bus factor of 5. That means all five of those folks would have to leave at the same time to kill or seriously wound your project's progress.

But, if there is just one or two such people, who seem to be doing a lion's share of effort in your community, then your bus factor is lower, and you have a potential disaster on your hands.

One quick way to mathematically determine your community bus factor is to examine how many project files a given contributor has worked with over a set period of time (6-12 months works for me). If a person has worked with over 50% of project files, that person should be classified as a critical contributor.

Raising Your Bus Factor

The simplest was to alliviate this problem is to spread the work around. But getting to that goal can take many paths.

You first need to examine why a person has ended up in that position to begin with. Are they really the only one who knows how to solve certain problems, or did everyone else just see their talent and hand work off to them? Motivations are key here, because sometimes people want to be the Important Person and sharing might not be in their personal interests, even though it will always be in the greater interest of the project.

If the person is a critical contributor, the community needs to have a frank discussion with the person to determine how best to share what they know and get more work delegated around the community. Also look for other methodologies, like agile development, that tend to disseminate workloads as a matter of course.

Avoid egos as much as possible. Think about the greater good as you build concensus and work to raise your bus factor and avoid the roads of fate.

Image by Max Pixel under CC0 Public Domain license.