Helping your project survive the loss of core contributors
Work is not divided evenly across open source projects. A small number of contributors do the majority of the work. Sometimes these people have a formal designation as a core contributor and sometimes they don’t. In either case, they’re clearly load-bearing. But people’s interest in — or capacity to contribute to — a project can vary over time. Even the most committed contributor will need to take a step back sometimes.
So how can you help your project survive when a core member of the team steps away? Research by Olivier Nourry and colleagues offers some insight.
- Grow the community. It seems obvious, but more contributors means a lower risk that the project dies. The larger the community — in particular, the larger the team of core contributors — the less the project depends on any one person.
- Be older. Admittedly, there’s not much you can do about this. Still, the longer a project has been around, the more likely it is to survive the loss of a core contributor. My suspicion is that this is related to the previous point: a project that’s been around longer has had more opportunity to grow the community. But there’s also a higher likelihood that someone relies on it, which means they’re more likely to step up if the project is in danger of collapse. This is less likely to be the case for a new project that might be interesting, but isn’t relied upon yet.
- Be active. “Activity begets activity” is a core idea behind the Flywheel Theory of Community Engagement. It’s not enough to have a lot of people sitting around, they need to be doing something. Nourry et al found that a higher number of commits at the time a core member left the project corresponds to a higher likelihood of survival.
Nourry et al also found that a smaller number of files correlated to survival rate. I didn’t include this in the list above because I’m not entirely sure what to make of it. There’s something to be said for simpler projects being easier to pick up on, but that may or may not be what’s happening here.
Building on what’s in the paper, I have a few extra tidbits.
- Provide mentoring. Help contributors gain new skills and responsibilities and give them a ladder to climb. Not everyone will climb to the top, but the more rungs that people advance, the more resilient your community will be.
- Plan for departures. Everyone is going to leave the project one way or another. Have a plan in advance for how to handle it. The mentoring you do will be a big part of that.
- Foster a culture of documentation. Research by Lin et al found that contributors who primarily focus on documentation stick around for less time than those who primarily focus on code. Unless you want to constantly churn through docs contributors, make documentation everyone’s job. When people do work primarily on documentation, make sure they are recognized and given an incentive to stick around.
- Encourage maintenance. The same work by Lin et al found that contributors who mostly modify files stick around longer that those who mostly create files. Once a project is beyond the initial phases, the bulk of the work is maintenance. Recognize and reward the maintainers.
- Be important. The more people who depend on your project, the more likely someone is to step up when needed. Sadly, this happens far less than it should.
No matter what you do, the odds aren’t particularly great. Nourry et al found that nearly 90% of projects lose their core developers at least once, and only 27% of projects that do are able to survive. Despite the long odds, you can take steps to give your project its best chance.