Creating Pathways That Invest in New Maintainers

Open Source Practices: The Mountain of Engagement

8 min readNov 22, 2021

Sometimes, you need to step away from your current focus to invest in the future. I’ve been on parental leave most of this year (thank you Canada & Mozilla!), and I’ve been struck with the similarities to mentoring new leaders. Last week, this tweet was trending in the ‘open source’ topic:

“Every open source project is looking for more maintainers but if someone asks them what’s the path/criteria to become a maintainer, they don’t have an answer” @rakyll on twitter

I scrolled past in my sleep-deprived, new-parent state, but the tweet lingered with me the next day. There’s a lot of great work on creating inclusive and welcoming communities in open source. But I think one of the most effective ways to approach community building is through the lens of pathways to leadership. A path that invests in new maintainers is the backbone of creating a welcoming, diverse, and sustainable open source community.

Creating a path or criteria to become a maintainer is not always the same as investing in new maintainers. I’m on parental leave right now so that I can invest in the next generation. Taking time to nurture skills and train new leaders is not easy, but it is one way to value and support open source maintainers. It might mean stepping back for a season, but it could be hugely beneficial to the future of your community and project.

“Ultimately, leadership is not about glorious crowning acts [..] It is about laying the groundwork for others' success, and then standing back and letting them shine.” — Chris Hadfield

The work I’m sharing here was originally taught as part of Mozilla Open Leaders. Parts were developed by my excellent colleagues Chad Sansing and Zannah Marsh, with frameworks like the Mountain of Engagement and Personas and Pathways, and builds on ideas like the marketing funnel and commitment curve.

One of the hardest lessons I learned as a student leader happened when I brushed off the need to recruit freshmen. A sustainable community needs two things: (1) newcomers to the community, and (2) a way to level up within the community. In a campus setting, if you don’t get freshmen joining your club, 4 years later no one will be ready to keep the community going. Using the Mountain of Engagement framework, a sustainable community could look something like this:

A sustainable community needs two things: (1) newcomers to the community, and (2) a way to level up within the community

In this post, I’m going to break down each step up the mountain and share some ways open source projects can level up their community and invest in new maintainers and leaders. This mountain is using the 6 steps from the personas and pathways exercise:

6 steps in a community pathway to leadership from Mozilla’s personas and pathways exercise

Discovery — How they first hear about the project.
First Contact — How they first engage with the project, their initial interaction.
Participation — How they first participate or contribute.
Sustained Participation — How their contribution or involvement can continue.
Networked Participation — How they may invite and onboard others, networking within the community.
Leadership — How they may take on some additional responsibility on the project, or begin to lead.

Many of the practices associated with the earlier steps (1–3) are about setting the groundwork to enable collaboration. Once that’s in place, it might be time to start identifying and investing in future maintainers and leaders.

Discovery

How they first hear about the project.

Publish your code publicly and with an open source license

Make your work accessible online by creating a public repository on a code hosting platform like GitHub or GitLab. Use an open source license to aid discoverability and to enable outside contribution at later steps.

Promote your project (social media, conference, more)

Promotion goes a long way in helping others discover your project. Think of the kind of community you want to build — ideally one that represents the diversity of your users. Where would these potential contributors hear about this work? What affinity groups or communities of practice should know about this project? This could mean communicating your work on social media, speaking at conferences, or writing on mailing lists.

First Contact

How they first engage with the project, their initial interaction.

Have a clear vision

After hearing about a project, people generally won’t reach out unless they understand the work and find it exciting. Spend a bit of time clarifying WHAT you’re working towards or the vision of your project. There are several different exercises you can use to hone your message. I’m partial to the Open Canvas. These are great to do as a group!

Open communication channels

The next barrier people often face is figuring out how to contact you. Do you have an open communication channel someone can join? Sending a personal email or DM is often more intimidating than joining a chat channel, forum, or mailing list.

Write a README

A README is the welcome mat of your project! It’s often the first thing people see when they come to your repository. This is a great place to include your project vision, links to communication channels, and anything else newcomer to your project might want to know.

Participation

How they first participate or contribute.

Personally invite people to contribute

Personal invitations are one of the most effective ways to get contributors. Asking someone to volunteer their time can make them up to four times more likely to volunteer. Be intentional about who you invite — aim to have your contributors reflect the diversity of users of your product.

Be responsive

When someone reaches out, a fast response time to their message indicates an active and engaged community and makes them much more likely to go on and contribute. A good rule of thumb is to aim to follow up within 24 hours.

Write Contributing Guidelines & choose a Code of Conduct

There are 2 additional documents you should include in your repository to establish an inclusive environment and help people understand HOW they can participate. (1) Contributing Guidelines show the different ways, standards and practices used for participating in the project. (2) A Code of Conduct establishes the community norms and responsibilities, along with reporting information. I also recommend having current leadership go through code of conduct enforcement training.

Use public issues and pull requests

Public issues and pull requests add transparency around how the work is done. This makes it easier for others to jump in and understand what work has been done before. Adding the label good first issue to starter issues for newcomers is a nice way to show people how they can get started right away.

Sustained Participation

How their contribution or involvement can continue.

Recognize the work done by the community

It’s easy to forget to say “thank you”, but it’s one of the most effective ways to show contributors that their work is essential to the project. You can also acknowledge them as a contributor and consider larger awards programs or appreciation events, but don’t forget the basics!

Connecting work to the overall project mission

To keep motivation up, it’s important to connect work done by contributors to the overall project mission. Help contributors understand WHY fixing typos or answering support questions is important.

Match contributor skills and interests to tasks

Make it a point to listen to your contributors needs and interests to make sure they want to do the work they’re being asked to do. This is most effective as 1:1 check-ins but can be done more broadly, like with a survey. Meeting needs that come up is a great way invest in the community and future maintainers. This is a good point to start identifying potential maintainers to invest in.

Networked Participation

How they may invite and onboard others, networking within the community.

When I’m looking to scale an existing community, I like to optimize for this step in the pathway. Having contributors that are actively inviting and onboarding others is the best way to grow exponentially.

Formalize mentorship

Asking someone to become a mentor in your project is a quick way to put them in a networked participation role. This could mean implementing mentored issues, or participating in programs like GSoC or Outreachy.

Offer training and professional development

Training and professional development are great ways for contributors to feel like they’re learning and growing in this community. This could look like mentoring potential maintainers through hands-on leadership work, like onboarding others.

Run hackathons and socials (easy-to-invite-others events)

To improve networking overall, events like hackathons or socials make it easier for community members to invite their friends and introduce them the project.

Leadership

How they may take on some additional responsibility on the project, or begin to lead.

Set clear expectations for leadership roles

It’s important to set clear expectations for any leadership roles in your community. At minimum, clarify roles like ‘maintainer’, but you will probably need to choose a governance structure. A governance structure that includes the community when making decisions about the project can help create a positive experience for contributors.

Personally invite people to leadership roles

Some community members, even if you’ve been mentoring them, might be waiting for a personal invitation before taking on or running for a leadership position.

Provide an equitable value exchange

As much as possible, aim to provide an equitable value exchange for the leaders and maintainers in your open source project. A nice place to start is Mozilla’s Inclusive Leadership Cycle which includes onboarding, review, recognition, and renewal as part of the leadership cycle.

Pathway Summary

Summary of open source practices to help level up community on a pathway to leadership.

I know I’m not the only thinking of this problem — do you have any practices that help level up your open source community? What pain points do you run into when finding new maintainers? Please share your thoughts, I’d love to keep iterating on this work!

Raising up new leaders is (hopefully!) less consuming than raising an infant. To those of you doing the hard work mentoring and supporting the next generation of open source maintainers, know that I am with you in spirit, cheering you on ✨