If you work in tech, you may be familiar with The Bus Factor.
We had a running joke at one of my previous jobs that whenever a bunch of developers crowded into an old elevator in Lower Manhattan, that we were really playing with fire and that our “Bus Factor” was really high. But what does the Bus Factor really mean?
What is the Bus Factor
Somewhat morbidly, the Bus Factor is usually stated to mean: what is the probability that the tech project you’re working on will fail if someone on the team is run over by a bus? This stems from individuals who are the “gatekeepers,” so to speak of all the intellectual knowledge either of a system or a technology. These people are tasked with keeping the lights on and whenever they go on vacation, they are usually interrupted because the rest of the team doesn’t know how to do the work themselves.
This situation can happen for a number of reasons:
- The employee intentionally withholds their knowledge out of fear of job security
- The team doesn’t have a way to disperse knowledge so that everyone has a working understanding if not an expert understanding of how to achieve something.
I once discussed the Bus Factor at a conference called Open Source & Feelings, except I used the analogy a little bit differently.
In an open source project, very rarely is a maintainer hit by a bus, but they do have a tendency to just walk away from a project.
When I brought up the bus factor at Open Source & Feelings, I wanted to highlight the fact that emotional labor as an open source maintainer was high. I found that I and other people I had talked to felt an overwhelming responsibility to shepherd projects through the end of days. This led to thoughts of apathy, depression, and resentment.
That’s why whenever I presented on how to maintain your open source community I instead framed “Bus Factor” like this:
Your personal Bus Factor is the amount of bull shit you’re willing to put up with your community before you pack your bags and hop on a bus out of town.
Open source maintainers and contributors often start these projects because they want to help others. Unfortunately, these altruistic ideals can also come back to bite us in the ass.
Our patrons can sometimes seem insensitive to our time and emotions.
Companies profit off of our hard work by using our tools in their for-profit software at multi-million companies without any recognition of our involvement.
Sometimes we are the worst critics to ourselves, always wishing we could do more, and we pile the guilt on ourselves until the responsibility becomes unbearable.
As a culture, open source maintainers, contributors, and users need to come together to respect the art and finds ways of rewarding those who dedicate their time and energy to the development of the tools we love. We also need to be able to recognize burn out in ourselves and others to save us from losing some wonderful people who have built our community.
Have you ever worked on an open source project only to find yourself faced with a situation that made you want to quit?
