Commentary: For developers who want to become leaders in their chosen open source communities, the process is easier (and more difficult) than you might think.
Image: Getty Images/iStockphoto
There are at least two ways to become an open source project maintainer. The first is perhaps the most straightforward, though hardly easy: Start a project. This is the path taken by Simon Willison (Datasette), Rich Felker (musl libc), Gerald Combs (Wireshark), and others. The other is to build up credibility with an existing project over time, eventually earning the maintainer mantle. In some ways, this might be the harder path, but it’s one that Lili Cosic (kube-state-metrics/Kubernetes), Madelyn Olson (Redis), and Whitequark (Solvespace) have taken.
Most of us will never start our own project. But with a significant percentage of developers contributing to open source projects (49% of women and 64% of men, according to a DigitalOcean survey), there’s a real opportunity for developers to earn a leadership role within their preferred projects. For reasons I’ll detail below, it could be a more realistic goal than you might think.
SEE: How to build a successful developer career (free PDF) (TechRepublic)
Faster than you might think
In a series of conversations with open source project maintainers, I kept being surprised by how quickly goodwill could be earned within a project. For example, both Cosic and Olson have been full-time engineers for five or six years, and only engaged with their respective open source projects for two to three years. To go from limited/no involvement to the highest honor accorded an open source contributor in roughly two years is amazing. As Cosic said, “Some people say it’s very fast growth, but for me it’s just because I am very passionate about it.”
That passion shows up as commitment to a project, and such commitment ultimately builds influence within the community.
For the developer who goes by the name Whitequark, her story is similar. In an interview, she said when she first encountered the Solvespace code, it was excellent at its core functions but was decidedly crufty in its code–it needed a revamp. She set to work:
I started to gradually and very carefully improve it. The fact that it was so stable and reliable was one of its two best qualities, along with the ease of use, so I did not want to make haphazard changes that would result in backwards incompatibility or losing data. (In the end, it took me something like two years to become comfortable with modifying most of its 30 kLOC codebase–purely in terms of programming, not going into any of the underlying math.) I kept a carefully updated patch set–I aspired to the same standards as the LLVM compiler patches, which I also used to co-maintain–and periodically asked Jonathan [the founder and maintainer] to review and merge them….
After a few months of this work, the maintainer decided he needed to move on, and entrusted the Solvespace maintainership to Whitequark. In her story, as well as those of Cosic and Olson, the key to becoming a trusted contributor (and, ultimately, maintainer) of an open source project emerges: Consistency.
“Consistency is the key”
Cosic called this out straightaway in our conversation: “Consistency is the key. Regardless if you contribute large pieces of code or small, it’s more about consistently contributing over a period of time. Usually…you need to contribute at least for a few months consistently. And that includes reviewing PRs and answering issues [on GitHub Issues, Stack Overflow, etc.].” Open source projects aren’t necessarily looking for would-be contributors to develop the equivalent of a cure for cancer for them–they just need people to show up and do the little things.
For Olson, she had no grand ambition to become a maintainer of Redis, the open source database to which she contributed. “There was no pathway to me becoming a maintainer,” Olson said. “I was not expecting it. I was just trying to be helpful and that ended up paying off.”
In “trying to be helpful,” Olson didn’t try to commit major new functionality. Instead, she made it easier for others to do that work. “Almost all of my contributions are minor,” she said. “Normally I’m the one making small fixes all over the place, and then when someone really wants to commit something big, I help them get the code in better shape and then they submit it and I’m the ambassador to say, ‘Hey, Salvatore [project founder], we built this great thing.’ But I normally try to let the other person get more of the credit.”
Such consistent, behind-the-scenes work might seem to go unappreciated, but it’s actually the precise work that most projects need. By consistently contributing “little” pull requests, developers can build their influence within a project and, perhaps, earn the distinction of being a maintainer on the project.
If I’m making this sound overly simple, I don’t really intend that. As Drupal founder Dries Buytaert has pointed out, for example, “Open source is not a meritocracy,” because “inequality makes it difficult for underrepresented groups to have the ‘free time’ it takes to contribute to open source.” It’s a valid point.
SEE: How to become an effective software development manager and team leader: Tips and advice from Drupal founder Dries Buytaert (TechRepublic)
Even many who are fortunate to have full-time employment aren’t necessarily encouraged by their companies to make time to contribute. For such, this is a mistake, as contributing to open source projects is a great way to influence their direction and care for customers. So for companies that depend upon open source (and that’s every company), it’s time to carve out space for your developers to make those consistent contributions over time.
Disclosure: I work for AWS, but the views here are mine and don’t necessarily reflect those of AWS.
Open Source Weekly Newsletter
You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications.
Delivered Tuesdays
Also see
