Volunteers can’t be blockers

As your project grows, you add processes. This, of course, requires humans to make the processes go. In open source projects, contributors often come and go without warning. This makes it difficult to depend on a particular individual for a critical task. You never know when they might silently disappear. This is not a knock against volunteers. They are the lifeblood of open source communities and they have every right to step back when they need (or just want) to.

If your project has people who are paid to work in the community, then they should be the load-bearing contributors. Paid contributors will still have periods of unavailability and may leave with short — or no — notice, but you can generally expect them to be around more often and more predictably. Again, this is not a value judgment, it’s a matter of capacity planning.

“Ben,” I hear you say, “no individual should be a single point of failure, whether they’re paid or volunteer.” You are correct, dear reader. That’s the ideal state, but it’s not the reality for many projects. It’s best to have a group of people who are able to handle a critical task. Even then, there should be one person who is the default assignee so that you don’t end up with everyone assuming someone else will do it.

Relying on an all-volunteer group can be hazardous, too. The Flywheel Theory of Community Engagement tells us that there will be times when everyone in the group independently disappears. The larger the group, the lower the risk, but there’s still a chance that no one will be around to push the button when you need them to. In an all-volunteer project, of course, you have no choice.

None of this is to say that volunteer contributors can’t have important roles in the project. They should. The best approach is to figure out which processes are truly critical and accept that the non-critical ones may get missed from time to time. If you have paid contributors, they should be responsible for the critical processes.

There is one possible exception: maintainers, whether paid or volunteer, have committed to a certain level of presence in the project. Ideally, this expectation is explicit, but it always exists implicitly. Keeping maintainer status (again, this should be explicit) depends on regular activity in the project. If you must rely on volunteers for critical processes, it should be the volunteers who have made a commitment to be there and shown a history of meeting that commitment.

This post’s featured photo by Ron Hollis/USFWS on Flickr.