Bus factor, boss factor, and the economics of disappearing maintainers

We've jokingly referred to the problem of disappearing maintainers as "bus factor" for about as far back as I can remember. In short, the idea is that it's bad for a project to have only one maintainer, because if they are (morbidly) hit by a bus, no one will keep working on the project.

The core idea behind the “bus factor” concept is important—more maintainers is basically always a good thing. But I'm beginning to think we need a better term, because "bus factor" makes it sound like random bad luck is the primary reason why people leave open source projects. But random bad luck is actually rare. Instead, the leading reason people leave open source projects is economics—and particularly, changes in their employment situation. 

So I’m suggesting that we use language that helps us focus less on random chance, and more on the important causes that actually drive turnover. In short, boss factor.

Bosses are great!

The change in terminology from bus factor to boss factor isn't a critique of bosses! Tens of thousands of bosses have let hundreds of thousands of developers use and contribute to open source, and that support has been a key driver in open source’s transition from curiosity to critical infrastructure. 

… except when they're not.

But the thing with bosses (and companies generally) is that sometimes they change their minds. Even when those changes are for completely good and fair reasons, those changes have implications for their employees—and now, for open source. To see how that plays out, a recent paper used a dataset and survey of maintainers who dropped from 300+ contributions over 18 months to < 5 contributions in the following six-month period to evaluate why people stop contributing to open source.

In the words of the authors, their survey shows that "the most common reasons for complete disengagement relate to transitions in employment, such as graduating from academia, changing employers, and changing roles." (Note: no buses, and no random chance.) 

After doing the initial survey, the authors did a further deep dive on the GitHub data. This analysis confirmed the survey results, showing that "job transitions" (measured by looking at public employment information) are the strongest predictor that a contributor will stop contributing.

This should not be terribly surprising. When companies depend on open source, they often give people time to work on it. But when business needs change, technologies are swapped out, or people simply decide to find new jobs, open source contributions often lose out. That’s the basic fact that “bus factor” obscures.

Number of contributors may be less important than number of employers

Once you start focusing on bosses rather than buses, you start seeing other things. For example, it is highly unlikely that an entire team of engineers will all step in front of a bus at the same time. It is, however, common for an entire team of engineers to work for the same company—and get reassigned away from an open source project at the same time!

This also shows up in the data. In another recent paper, CMU researchers found, to their surprise, that commercial support may make a project somewhat less likely to be maintained over the long term. This may seem counterintuitive—company support is something we all typically think of as good for a project, and indeed even the researchers say that "commercial involvement was expected to have a positive effect on sustainability." After all, a project with a company's support often has multiple people working on it—so the traditional bus factor is > 1.

But when we think of this in terms of boss factor, the unintuitive research result suddenly makes more sense. If a project relies on a single company (in other words, often a single boss) for support, then many of the same dynamics as bus factor come into play. A single executive decision can end the project. While I can’t prove it, I suspect that this single point of failure explains the dynamic observed by the CMU paper: corporate support is great, right up until it isn’t.

What this tells us

If we focus on corporate support, deliberate choice, and bosses, rather than random chance and buses, what lessons can we take away?

Perhaps more than anything else, my personal takeaway is to always remember that maintainer turnover is not something that “just happens”—it’s the result of human choices and human causes. Which means we can impact it!

Unfortunately, it also suggests that efforts to do deep, sophisticated modeling of project health based on GitHub data is always going to have an inherent limitation. We can’t predict what bosses will do from that data, and that means there’s always going to be some surprises—unless we’re talking to the maintainers directly!

Finally, focusing on who makes corporate decisions is a good reminder that, for open source projects, multi-company support that makes a project more independent is always going to be better for avoiding boss factor than single company support. 

Thankfully, the number of maintainers getting hit by actual buses continues to stay low. But if we look deeper at the choices organizations are making around the open source projects they support—especially when they the only organization supporting a project—we may find more room for new ideas that will make open source work better—for everyone.