Finding and Nurturing Your Project's Future Maintainers

Handing over administrative access to your open source repository is a significant step. You need someone who is trustworthy, understands your project's vision, and will stick around. One proven path is to promote active contributors into maintainers. We spoke with Carol Willing (Python Steering Council member and Project Jupyter core contributor), Brandon Roberts (NgRx maintainer and Analog creator), and Paulus Schoutsen (Home Assistant founder) about how they identify, train, and work with co-maintainers.

Headshot photograph of Carol Willing Headshot photograph of Brandon Roberts Headshot photograph of Paulus Schoutsen

Spotting Potential Maintainers

Each maintainer has their own strategy for finding the right people. For Willing, Project Jupyter uses a cronjob to identify active contributors and then reaches out to ask if they're interested in a more formal role. Those who say yes receive informal coaching on reviewing pull requests and maintainer duties.

Roberts found his path to maintainership by simply jumping in and consistently solving problems. He now looks for that same level of initiative, plus how contributors interact with others. "When I notice someone who is helping out with issues and actively investing time into a project, I invite them behind the curtain," he says.

Schoutsen's approach has evolved as Home Assistant grew. While he once favored early and generous merge access, his focus now is on community building. The project uses chat platforms to observe contributors in action. "It gives you a chance to see not just the quality of their contributions but how they deal with people who have different opinions," he explains.

Addressing Impostor Syndrome

When a promising contributor hesitates, the key is often re-framing the role. Roberts points out that if you're asking them, they're already doing the work. Becoming a maintainer formalizes what they do but gives them more influence over the project's direction.

Willing takes a conversational approach to uncover specific concerns. For technical worries, she reminds contributors that no one on a large project understands the whole codebase, and mistakes can be reverted. For time commitment worries, she reframes maintainership as a long-term commitment rather than more hours. Jupyter's "Red Team" and "Blue Team" system gives maintainers permission to step back when life gets busy without abandoning the project.

Schoutsen notes that scale helps: with around 100 Home Assistant maintainers, there's less pressure on any one person. He also suggests inviting people to the GitHub organization without commit access as a low-stakes first step.

Structured Onboarding

New maintainers need more than just technical skills. Roberts compares onboarding to "a bit like onboarding someone to a new job," complete with private chat channels, internal documentation, and administrative tasks like calendar invites.

Home Assistant leans heavily on documentation and automation. "We use a lot of automation, like linters and formatters, which takes much of the pressure off manual reviews," Schoutsen says. "No one wants to reject a pull request someone spent hours on because they missed a comma."

Jupyter uses a "Team Compass" template that covers project history, direction, and each maintainer's current activity status. It helps everyone stay aligned across the project's various groups.

Managing Disagreements

Disputes are handled best when kept technical and depersonalized. Willing emphasizes understanding another person's perspective and building win-win outcomes. She also suggests that not all decisions are permanent: "Sometimes a decision is a one-way door, but a lot of times you say 'Let's move ahead this way, and then reevaluate in 30 days.'"

For Home Assistant, the first step is moving rule discussions out of pull requests and into more visible spaces like Discord. Documenting the "why" behind past decisions often settles debates before they escalate. "Going through a process slows things down, which is actually good," Schoutsen says. "It gives people a chance to cool off."

When Removal Is Necessary

Sometimes things go wrong. Schoutsen describes one incident where a talented front-end contributor had a short temper with users. "We tried to calm him down, but we eventually had to let him go. I think this was the only time we had a maintainer break our Code of Conduct."

Willing has faced similar situations as a last resort. When someone repeatedly crosses lines, the pattern of behavior becomes clear over time. "You can't jeopardize the sustainability of the project for one person who is not acting professionally or in the project's best interest," she says, noting that sometimes a break is all someone needs.

Delegating Beyond Your Comfort Zone

Letting go of control is difficult but necessary. Roberts encourages fellow maintainers to share their ideas and let others execute them. Schoutsen no longer writes much code and instead coordinates small project teams around specific goals, drawing on others' expertise. Willing suggests that tasks you've been putting off are great learning opportunities — delegate the legwork while you supervise. "Don't hold someone to a higher standard than you hold yourself to," she adds.