Just like many companies have different advancement tracks for their employees (for example, a management track and an engineering track), similar concepts exist in free software projects. One of the roles of a maintainer is to help contributors develop into the roles which best suit them. I’d like to explain what this means to me in my role as a maintainer of several projects, though I should mention upfront that I’m just some guy and, while I can explain what has and hasn’t worked for me, I can’t claim to have all of the answers. People are hard.
There are lots of different tasks which need doing on a project. A few which come up fairly often include:
- End-user support
- Graphic design
- Marketing
- Release planning
- Reviewing code
- Translations
- Triaging tickets
- Writing code
- Writing documentation
Within these tasks there’s room still for more specialization - different modules have different maintainers, each contributor’s skills may be applicable to different parts of the codebase, some people may like blogging about the project where others like representing the project at conferences, and so on. To me, one of my most important jobs is to figure out these relationships between tasks and people.
There are several factors that go into this. Keeping an eye on code reviews, social channels, etc, gives you a good pulse on what people are good at now. Talking with them directly and discussing possible future work is a good way to understand what they want to work on. I also often consider what they could be good at but don’t have exposure to yet, and encourage them to take on more of these tasks. The most common case where I try to get people to branch out is code review - once they’ve contributed to a module they’re put on the shortlist for reviewers for future changes to nearby code. Don’t be afraid to take risks - a few bugs is a small price to pay for an experienced contributor.
This also touches on another key part of this work - fostering collaboration. For example, if someone is taking on a cross-cutting task, I’ll give them the names of experts on all of the affected modules so they can ask questions and seek buy-in on their approach. Many developers aren’t interested in end-user support, so getting people who are interested in this to bubble up technical issues when they’re found is helpful as well.
The final step is to gradually work your way out of the machine. Just like you onboard someone with feature development or code review, you can onboard people with maintainer tasks. If someone asks you to connect them to experts on some part of the code, defer to a senior contributor - who has likely asked you the same question at some point. Ask a contributor to go over the shortlog and prepare a draft for the next release notes. Pull a trusted contributor aside and ask them what they think needs to be improved in the project - then ask them to make those improvements, and equip them with any tools they need to accomplish it.
One role I tend to reserve for myself is conflict prevention and moderation. I keep a light watch on collaboration channels and periodically sync with major contributors, keeping a pulse for the flow of information through the project. When arguments start brewing or things start getting emotional, I try to notice early and smooth things over before they get heated. At an impasse, I’ll make a final judgement call on a feature, design decision, or whatever else. By making the decision, I aim to make it neither party’s fault that someone didn’t get their way. Instead, I point any blame at myself, and rely on the mutual trust between myself and the contributors to see the decision through amicably. When this works correctly, it can help preserve a good relationship between each party.
If you’re lucky, the end result is a project which can grow arbitrarily large, with contributors bringing a variety of skills to support each other at every level and enjoy the work they’re doing. The bus factor is low and everyone maintains a healthy and productive relationship with the project - yourself included.