7

Growing Contributors to Maintainers

When I talk about open source projects, a huge point of emphasis for me is sustainability. It’s also a point that is quite challenging to wrap your head around; after all, it’s really hard to think about the future with so much going on in the present. Open source projects often model the same pattern that start-up companies have, and for a start-up, thinking about the long term before the short term is hard because, without some degree of revenue and success, there is no long term. Open source projects tend to not be so heavily dependent on the short term, but at the same time, they can’t ignore it. A good project, just like a good company, focuses the appropriate attention on both and considers both in decision-making.

A piece of the sustainability puzzle is bringing more people into the project in various roles. The natural pool of these individuals is people already invested in the project; within a community of end users, contributors will naturally emerge that help drive new ideas and fixes into a project. This chapter will talk about how to grow those contributors so that they become the maintainers of the future.

We’ll cover the following topics in this chapter:

• The importance of growing contributors into maintainers
• Finding contributors and being a mentor
• When is a contributor ready to become a maintainer?

Growing contributors into maintainers is a piece of the larger conversation we will get into in Chapter 9, Handling Growth, but with this chapter, I want to take a deep look at this topic, as it tends to be one of the most dominant struggles for project maintainers. Part of this is likely due to some of the social dynamics we talked about in the last chapter, but also it comes down to having an intentional focus on identifying talent within your community and helping find a place for them in the project.

Before we get into identifying potential maintainers, let’s first chat about why this is so important.

The importance of growing contributors into maintainers

When someone is a new maintainer and sees their personal involvement in a project increase, they are often ignorant to the larger needs a project might have as it grows. It’s easy for them to say, “this is an easy bug fix; I can do it” or “I can spend a weekend writing documentation,” which is appealing when they are so heavily emotionally invested in the project. But what happens when that one bug becomes five, or a weekend that needs to be invested in writing documentation also has to compete with spending time with friends and family or being able to rest and recharge? Having more maintainers lessens that load and helps all maintainers focus on where their energy is best spent.

Let’s look more specifically at some of the main reasons why growing contributors into maintainers is so important to a project, starting with the need to alleviate the stress on current maintainers.

Alleviating the stress on the current maintainers

Coming out of the COVID-19 pandemic, one of the greatest challenges is maintainer burnout. Maintainer burnout has in some sense always been a problem in open source, but like many things, has been exacerbated by sudden cultural and lifestyle changes. It also hit hard with the Apache Log4j vulnerability that was big toward the end of 2021, just like the OpenSSL Heartbleed vulnerability many years before was critical for maintainers whose projects did not have good security practices.

With open source software being so ubiquitously used, the pressure on maintainers is at an all-time high. One article in Business Insider (https://www.businessinsider.com/open-source-developers-burnout-low-pay-internet-2022-3) talks about how some maintainers have gotten to the point where they are sabotaging their own projects. This sabotaging is not because of a lack of love for the project but because of the pressure put on them by end users and other downstream constituents, treating maintainers as though they are a full software development shop and not somebody maintaining all the aspects of a project in between different activities.

I’ve worked on a few projects that had great potential but suffered from this. Each one had maintainers with interesting code and a valuable use case, but they struggled to get others involved in the project. These maintainers had the stereotypical “if you build it, they will come” philosophy, but it never panned out. Here’s what tended to happen instead:

• The maintainer would switch jobs, and during that switch, the maintainer had to spend considerable time getting up to speed on their new job. Otherwise, that job switch involved new technological areas of expertise for the maintainer, whereas before, the previous project aligned well with the “scratch-your-own itch” motivation, but in the new role, it became something less aligned and useful for them.
• Health problems, with themselves or loved ones, took away their time and attention. Some maintainers see the work in open source as something of an outlet for them to escape the present challenges they might have, but the reality is that they don’t have the energy they need to continue driving the project at the same pace as before.
• The allure of running a project becomes less and less strong as it doesn’t grow how the maintainer or creator thought it would. One maintainer I worked with particularly struggled with two projects they started and ultimately ended up shutting down; in each case, they did a fair amount of outreach, but couldn’t ever get broader interest.

All of this adds to stress on the maintainer. Having contributors grow into maintainers can help offset the stress and keep maintainers engaged and excited.

But it’s not all about continuity planning; new maintainers bring new ideas and perspectives as well. Let’s look more at that now.

Bringing new ideas and energy into a project

We talked about the “benevolent dictators” model of governance back in Chapter 5, Governance and Hosting Models. One challenge we illustrated with that model is the fact that the hub of decision-making comes back to one person, and depending on the style of leadership, that can end up either helping drive consensus or stifling other opinions. Either way, it’s hard on a maintainer to be in that role; imagine being that person and every single project decision having to come through you. It’s overwhelming, for sure.

When you bring in new maintainers, you bring in new ideas and energy. In my current role at the Linux Foundation, I work on a team with a group of skilled program managers and directors, each with different levels of experience in stakeholder management, open source project guidance, and general organizational skills. One of the things I like the most is bringing in a new member to the team, as each person comes with different skills and experiences. Some of our team members are Project Management Professional (PMP)-certified. Others come from the non-profit sector. Some might have event or marketing experience. Even a few of us have extensive open source project backgrounds. Most of us have a combination of these skills, and our outcomes as a team give us two key things:

• We learn new ways of doing things from one another. Someone with more events experience can share tips for helping a project prepare for an event, while someone with deeper open source experience might have insights on the governance setup for a complex project.
• We strengthen each other, both from an experience perspective, as in the previous point, and from a mental and emotional support standpoint. Working with open source communities is very rewarding, but it also can be stressful due to various personalities and priorities. Chapter 8, Dealing with Conflict, and Chapter 9, Handling Growth, will dig deeper into these topics.

When you, as a maintainer, get comfortable with new maintainers coming into your project, you no longer have to be the fulcrum of everything in the project. Let’s look at how bringing in new maintainers enables current maintainers to step back from the project.

Enabling current maintainers to step back

Coming back to the point raised earlier in this section, the “Benevolent Dictators” model of governance back in Chapter 5, Governance and Hosting Models, puts the single maintainer in the position of the sole person allowing the project to “sink or swim.” However, I’ve seen this happen in projects with several maintainers as well, especially if that group of maintainers has been the maintainers since day one.

This becomes a big problem in projects with a perceived high barrier to entry to be a contributor, let alone a maintainer. Media and entertainment space projects I’ve worked with have struggled with this, as specific domain backgrounds in visual rendering and color science were often requirements, in addition to deep C/C++ experience. Because of this barrier, they immediately had the challenge of getting new contributors to the project – which, in turn, created the problem of too much work on the maintainers and lots of stress overall on the project.

What I have started to see as a trend in the case I just illustrated is new contributors emerging that do meet the requirements, from two general categories:

• Existing organizations add additional resources, though usually, this is pretty minimal (maybe an additional full-time engineer equivalent)
• New organizations grow in value or independent developers do, who have experience and are often known in the industry already

For a maintainer to step back, they must feel comfortable doing so. In industries such as the media and entertainment, there is a small community of people who tend to move from company to company rather than floating between multiple industries. I will note that long-term, the pattern of “tapping the same well again and again” is not sustainable. Still, as a starting point, it creates the right culture of bringing in new maintainers and transitioning leadership, which can often be hard for the initial leaders of a project.

Another part of enabling maintainers to step back is thinking about how to best optimize the time of a maintainer. As open source projects I’ve worked with start to hit maturity, one of the best ways to help scale growth is building out documentation, training, and certification resources that enable mass education on the project itself. Building these out is a lot of work, and something we’ll discuss in more detail in future chapters, but it also requires someone with deep project knowledge to direct and lead for it to be successful. If the maintainers spend tons of time doing singular enablement, meaning responding to forum posts and bug reports, they are caught in a never-ending cycle. Having new maintainers who can lead those activities effectively lets those other maintainers take on “higher-level activities” such as this, which helps the project grow and scale.

Stepping back as a maintainer can result in shifting roles and responsibilities, letting the maintainer focus on specific areas with their available time, but it can also be a path for succession, meaning a maintainer leaves a project entirely. As a maintainer, there is no requirement to be part of a project for life, just as in our careers; we aren’t wedded to a single employer or job for life. We might even want to retire someday; Guido van Rossum, the founder of Python, has been able to step away from the project and retire, with Python continuing to grow and evolve as a key programming language. Having this foresight as a project leader helps you set a course for how to get there while ensuring the community and its work can continue.

Hopefully, this has given you enough perspective on why this is such an important focus for a project. Let’s now jump into our next topic of how to find contributors with the potential to grow and mentor them to success.

Finding contributors and being a mentor

Identifying who among the current contributors will be a great future maintainer is the hardest part of getting new maintainers. In the early days of a project, or for a less experienced maintainer, everyone showing up looks like a possible maintainer. That’s not only overly optimistic but can also deter people from becoming a contributor. Remember that often contributors and end users come to a project with the “scratch-your-own item” mentality and doing work in a project for a maintainer likely isn’t that itch.

At the same time, as we will learn more about in Chapter 11, Open Source and the Talent Ecosystem, contributors may also have the motivation to gain development experience or even be part of the project leadership in time to open up their future employment opportunities. As a maintainer, know that you don’t have the responsibility of career development for a contributor looking to become a maintainer, but if interests align, then it could be a good opportunity for the project and you as a maintainer

Let’s start on the journey of identifying future maintainers by looking at what qualities you should look for.

Qualities of a future maintainer

Early in open source, when it was viewed as more “counter-culture,” we had the idea that open source leaders resisted the concept of leadership. Leading an open source project is much harder than leading a team of employees. For one, contributors can bail out at a much lower threshold than an employee can, as there is rarely any economic impact on the contributor. Secondly, these contributors don’t come with any vetting process ahead of time; they see your project, like it, use it, and contribute to it as it fits their needs. This requires a maintainer to look at both the technical and soft skills of the individual to see how they could evolve into being a maintainer.

Let’s break down the skills into two categories – technical skills and soft skills. Here are some of the typical ones I see:

Technical skills	Soft skills
Knows the code base well	Organized
Understands the technology	Good communicator and writer
Can debug issues	Problem solver
Good software development skills	Curious thinker

Table 7.1 – Technical skills versus soft skills

Being a maintainer is one part technical management and another part people management, which requires soft skills. The technical side is usually fairly trivial to evaluate; look at the code contributions made and you can quickly see whether the person is a good software developer or not. However, for the soft skills side, there isn’t one place to look and evaluate; you’ll want to review a number of different places:

• Do they post in mailing lists/chat channels/forums? What is their tone like? Is it respectful and humble, or arrogant and confrontational?
• Do they answer questions from others or help debug issues and problems people are having? Are those interactions patient and understanding, or frustrating and demoralizing?
• When this person is involved in a conflict, how do they respond? Do they engage directly and point fingers? Do they run the other way? Do they try to understand others’ points (a topic that we will dig more into in Chapter 8, Dealing with Conflict).
• Is the person a regular in the project, or does their participation ebb and flow? If they are needed for something, can you count on them to come through?
• What are the long-term career goals of this person? Are they someone who jumps from thing to thing, or sticks with jobs and works for a longer period?

Knowing what qualities a good future maintainer has is a good indicator of which contributors could be future maintainers, but know that many of the preceding questions can’t fully be answered upfront. As you build a relationship with the person, you learn more about their style, personality, work ethic, technical skills, and more. Additionally, the project might have some excellent documentation and governance written down, but there is still a fair amount of “cultural knowledge” in the project, so the person will learn about the current maintainers’ style, personality, work ethic, technical skills, and so on over time, which will determine whether this is the right fit for them or not.

Mentorship is a great tool here, as it gives both the prospective maintainer and current maintainer that space to determine whether the fit is there; let’s learn more about that now.

Using mentorship to bring in a new contributor

One of the biggest challenges talked about with organizations is hiring great talent. As I spoke about in the previous section, both the organization and the employee need to see whether there is a mutual fit. Open source projects are no different; each has a different style and culture, which aren’t right or wrong, but not everyone is a great fit for each one. A great way to discover this for both maintainers and prospective maintainers is through mentorship.

One of the groups I work with, Open Mainframe Project, holds a summer mentorship program. The goal of this program is to bring in students and those in career transition to work on one of the open source projects in the mainframe space, with the anticipated end goal of both good contributions to the project and involving the mentee in the industry and the project going forward. The project has seen this work out great for bringing in new persons to the mainframe industry, with many taking jobs in the mainframe ecosystem post-mentorship. For projects, we’ve had three great examples of a mentee getting involved and taking leadership roles in the community:

• Alpine Linux (https://www.alpinelinux.org/) was ported to s390x (the architecture for the mainframe) in 2017 thanks to a mentee doing the initial porting work during their mentorship and then sticking with the project to complete the porting work. This person as of the time of writing is a maintainer for Alpine Linux and both the s390x and POWER ports.
• Software Discovery Tool (https://www.openmainframeproject.org/projects/software-discovery-tool) is a project that builds a tool for discovering open source project compatibility with the mainframe, as well as working with various Linux distributions and other groups to maintain a database of compatibility. After doing a mentorship to help build out parts of the infrastructure, a mentee stayed involved in the project and became a maintainer after they had a great experience working with the community.
• COBOL Programming Course (https://www.openmainframeproject.org/projects/cobolprogrammingcourse) provides an open source course for learning COBOL. This project also did a mentorship and had a few mentees participating in building parts of the coursework. One mentee in particular really enjoyed both the project community and the mainframe ecosystem itself and stayed involved in the project by becoming a maintainer, and the next year became a mentor to the next group of mentees.

These examples illustrate formal mentorships, but informal mentorships work just as well. Early in my open source career, I built the PHP Windows Installer with support from the current maintainer of the Windows support project for PHP. This person provided me with some advice and guidance on how PHP is best installed and configured on Windows, helped validate my approach, and then worked with me to get the code into the project itself. You could use this same pattern for getting people engaged in other aspects; I’ve seen projects that might not have a strong Continuous Integration/Continuous Deployment (CI/CD) environment have someone step up to help, and this person has become a maintainer of that work with the support of other maintainers. The main idea here is that there is an interest for the person, a need in the open source project itself, and the opportunity to work together on something that gives each party a good sense of what working together is like.

As mentoring and shadowing continue between a current maintainer and a potential future maintainer, you get a better feel for whether this contributor will serve well as a maintainer. Let’s now look at those conditions.

When is a contributor ready to be a maintainer?

Mentorship can be a slow path. You don’t want to overwhelm yourself or the contributor too much, as it will become frustrating to you both. On the other end, if the contributor isn’t getting involved in the maintainer group much, they will become disinterested and drift away. Mentorship done well is an intentional process, with both the contributor and the maintainer setting clear goals and timelines to ensure the expectations are clear while having good communication to know how things are going and address concerns early on.

Sensing the moment at which a contributor is ready to become a maintainer tends to be more of an “art” rather than a “science.” There are some signals to look for to best gauge how things are going – let’s look at some of them now.

Signs that mentorship is going well

Each mentorship and project is a bit different, but you can generally look for a few signs to tell whether things are going well; here are some:

• The contributor proactively engages. This could mean the person asks and answers questions regularly on mailing lists or forums. It could be they do timely reviews of bugs and issues. You may see them speak publicly about the project in meetups, events, or blog posts. The key is “proactive” – meaning you as a maintainer are not specifically asked to do something, but you are out there doing it. They might ask whether something is okay first – and that’s fine – but the point is they are taking the initiative.
• The contributor understands the project and the community. You can tell this by the engagement; does it have the same tone as others in the project leadership? If a maintainer has given feedback on something, has the contributor taken this feedback and incorporated it into future work (and hopefully not repeated their mistakes)? This doesn’t mean the person doesn’t have their own personality and approach – in fact, it’s good if it is a bit different. What you are looking for is someone that does things in a way that allows other maintainers not to worry about what they’ve done.
• The contributor is recognized in the project community as a leader. Being a leader isn’t something the person can accomplish alone; it’s based on the work they do and the interactions they have. If the project community doesn’t recognize this person as a leader, that could mean there is friction between this person and others, or maybe the person isn’t being vocal and presenting themselves as a leader.
• There is a good personality fit between the contributor and the other maintainers. This doesn’t mean everyone is best friends, nor is it a “personality contest”; the contribution should be via good, professional interactions and communication.
• The contributor has the aptitude to grow from any shortcomings they have in terms of the previous points. We are all humans, and sometimes we struggle to see our weak points. What’s most important is whether a person can learn and grow from those points. Note that a person might not be perfect on each of the preceding points; that doesn’t rule them out from being a maintainer but gives them space to grow.

Building on that last point, a great example in a different domain is being a sports official. Recently, I got involved in being a certified volleyball official, and one thing that impressed me is all the good and great referees who constantly work on improving their skills. It might be that they are good at recognizing net faults but aren’t good at recognizing alignment issues, or perhaps they understand how to properly assess sanctions but aren’t as good at back-row awareness. Officiating has multiple aspects to it and can be demanding, but the way you improve is by recognizing what you’ve done well and not as well and setting a plan on how to improve on each skill. Becoming a great official requires humility, recognizing the skills you need to improve on and having the desire to improve.

The same is true of being a maintainer; great maintainers are made over time. The domain and scope of a maintainer stretch across deep technical knowledge, public speaking, and community management; you will rarely be good at all of these at first, but over time, you improve in each area. All maintainers go through the same struggles and learning experiences, but much like the examples with a volleyball official, the great maintainers go through those experiences, learning how to improve and grow.

We hope that mentoring a potential maintainer goes well and that they develop into the maintainer role and become an asset to the project, but it doesn’t always end that way; how do you manage a situation where they may never be ready to be a maintainer? Let’s look at this situation and see how to handle it gracefully.

What if the contributor is never ready?

Sometimes, even with the best of mentors, the contributor isn’t a great fit for being a maintainer. It could be the person is a poor communicator, or perhaps disorganized. Maybe the person’s personality isn’t a great fit for the project community. This doesn’t mean they are wrong for the project, just not right for the role. And that’s not a permanent status; over time, people grow and change (as the project does as well) and the fit might be better at a different stage.

Some tips for managing when it might be good to end a mentorship include the following:

• Talk to the person directly and privately about the concerns.
• Be receptive to the feedback they have. When there are issues, it’s rarely one-sided, so they may have critical feedback for the maintainers themselves. It could be resolvable feedback, or it might not be. There’s more on this in Chapter 8, Dealing with Conflict.
• Ensure everything they were involved with has a new owner, which might be yourself ;-).
• Try to find other ways a contributor could participate. Maybe there is a feature that needs to be developed and the skills they have are a better fit there. Perhaps there is documentation or other writing needed, or they could just help answer questions in mailing lists or forums.
• Try your best to end the mentorship amicably. Often, if you do not see the fit working, the other person likely sees the same thing as well. Walking away amicably ensures goodwill and sets a tone for how maintainers interact with others.

Remember – being a maintainer isn’t for everyone. Even if someone has the aptitude to be a maintainer, it doesn’t mean the interest is there. Another thing to remember is that moving from being an end user to a contributor and then to a maintainer isn’t per se a career path, and not becoming a maintainer isn’t a failure. There might be other roles the person might have within the project community; perhaps they will be out there answering questions or writing blog posts. Be appreciative of any contributions people make to a project because without them, it would fall on you.

Summary

If your goal is to have a successful, sustainable open source project, thinking about how you develop your project leadership over time is crucial. As we spoke about in Chapter 2, What Makes a Good Open Source Project?, and Chapter 5, Governance and Hosting Models, end users look at how a project is run as much as the code itself. A project might have an amazing code base, be technically innovative, and solve the exact problem an end user is looking to solve, but to use it as a critical part of their infrastructure, they will want to make sure this project is maintained for years to come. As a maintainer today, that might not seem like a big deal, but after years of maintaining a code base, answering questions, fixing issues, and doing releases, being a maintainer can lose its luster. The only way to make a project sustainable for the long term is by bringing new maintainers into the project regularly.

One of the main stressors on maintainers, as well as open source projects in general, is conflict. Conflict is a sign of a healthy project; it means you bring diverse opinions and perspectives to help a project have better outcomes, but conflict can be a stressor, especially when that conflict becomes negative. Let’s look at strategies for dealing with conflict in our next chapter, Chapter 8, Dealing with Conflict.