What does it take to be a good open source maintainer? I know from personal experience that the skills it requires don’t come naturally to many engineers. But as I’ve worked at being a better maintainer myself, I’ve realized that it’s also a very learnable role. In this first post of two, I want to share what I see as the key characteristics of good maintainership. Next time, I’ll go into more detail on perhaps the trickiest aspect of the job: person-to-person interaction.
When we talk about “maintaining” something, we typically mean the job of simply keeping it working. It’s a cost, or an expense, and not an especially creative or hard thing to express conceptually. But when we talk about “maintaining” an open source project, we’re referring to a larger and more particular challenge.
Open source maintainers must ensure the continued healthy development of their respective projects while often heading up an entirely volunteer team and receiving no direct payment for their work.
Those specifics have fed a couple of stereotypical views of open source maintainers. There’s the idea that we’re peace-loving hippies lacking the will or ability to plan effectively or keep other people on track. And there’s the mirror version, where maintainers are arrogant, controlling egomaniacs who want things to go their way or they’ll take their ball and go home.
Both of these stereotypes have roots in real examples of poor maintainership, but they’ve also been reinforced by the tech news and the blogosphere to the point that we tend to think of them as more common than they are. And they help obscure what it actually means to be a good maintainer.
First and foremost, being a maintainer means doing detailed engineering work. It’s not that dissimilar from what it takes to be a lead software engineer. A junior software engineer mostly writes code. But a lead software engineer is:
- a code writer, debugger, reviewer, and approver
- organized
- knowledgeable
- respected and trusted
- a thinker
- biased for action
- a curious learner
- an owner
That skill set includes people skills and begins to feature some of the attributes that a good open source maintainer needs. A maintainer has everything in the list above but is strong in one extra dimension: people leadership. They care about the code, but they also care about their community and the people in it.
A useful concept here is the idea of “servant leadership.” If you look forward to becoming a very senior engineer because you’ll get to make all the choices and tell everyone else what to do, you won’t make a good maintainer.
Maintainers are facilitators. They work to understand the skills, resources, and partners that the people on their project need in order to succeed and then help them secure them. Importantly, they also know that they are not expected to do everything themselves. As in many other walks of life, leaders like that burn out fast. Good maintainers understand when and where to delegate, when to explain, and even when to leave things for people to discover on their own.
That’s a nuanced and complicated thing to get right, especially for those of us who got into computing because we liked spending time with computers more than people. So it can be a hard transition for engineers to make. But it’s also very doable if you enter a mindset of leveraging your team’s various skill sets rather than feeling you need to tell everyone what to do in order to maintain their respect.
As a broad rule of thumb, here are four key things that a good maintainer will learn to focus on:
- articulating the project’s high level needs – this is as much a written communication task as an engineering one.
- soliciting others to fulfill project needs – recruiting comes in here, as well as having a view across other projects to learn about solutions that might work for the project you are heading up.
- delegating wherever you can – find out your team member’s strengths and leverage them wherever possible.
- providing the glue that interconnects others’ contributions – while you aren’t writing the bulk of the code anymore, you’ll need to make small contributions that allow disparate parts to function together as a unified whole.
Get a handle on these four areas and you’ll be doing a very decent job.
All of these areas, however, require that you develop skills in a key area that most engineers have very little training: human interaction. So in the second of this two-part series, I’ll look at the challenges of getting people to work successfully together on a shared but entirely volunteer project in a little more detail.
Stay tuned to the Open Source Blog for part 2 and follow us on Twitter (@vmwopensource) for all the latest open source news and updates.
