Put this on the list of things you need to know: bus factor. It’s how you make boring ideas like succession planning more interesting and accessible to open-source developers, enough so that they actually bother doing something about it. To put it bluntly, the bus factor is the number of people who would need to be struck and killed by a bus before the open-source project would become incapacitated.
Your bus factor measures the robustness and resiliency of your organization. If your community consists of 20 developers, and your bus factor is 19, that means it would still be a viable project with only one remaining developer. If you lose one developer and your project’s inviable, whether it’s a benevolent dictator or simply the only person who knows about security auditing and secure code, then your bus factor is 1. It’s critical to consider this outside any hierarchy of project leadership, but rather extend it to every indispensable contributor. Maybe it’s your docs lead, or your website maintainer, or your build-system expert.
What makes this really interesting is that this doesn’t just relate to things like obtaining access for and maintaining project infrastructure. It’s also, perhaps most importantly, about the code itself. How easy is it for a developer in one area to become familiar enough with other areas to maintain them? Therefore, the bus factor is a very concrete, internal consequence of your barrier to entry — specifically areas like technical documentation, maintainability and readability of code (minimal technical debt), and project infrastructure.
What’s your bus factor?
No Comments