I recently gave a presentation for the LFX Mentorship Showcase where I reflected on the process of growing as an open source contributor. Here’s the recording and here’s the slides.
I want to clarify a bit about who my target audience is. The Mentorship Showcase is “open to anyone who would like to learn more about the experiences of LFX Mentorship Program mentees, find out more about some of the programs our projects are working on, recruit new talent, and support new developer contributions.” This is a broad category of people and I can’t give a meaningful presentation to everyone. So for the remainder of this post, and for my presentation, my target audience encompasses potential open source contributors and open source mentors. To the first group of people I wanted to show how they could grow as open source contributors, and to the second group I wanted to thank them for everything that they do and to validate the things that work.
I’ve had some success contributing and participating in the Linux Kernel community, and it has been nothing but a transformative journey. I want to empower as many people as possible to have such an experience.
My previous open source experiences
I really want to help potential open source contributors get into the game, because, for the longest time, I was one of the people who desperately wanted to contribute to open source. The unfortunate reality is that from the outside, open source seems intimidating and it’s very hard to work your way into the community. Those who are part of the community may disagree of course, but here’s my experience, and maybe it rings a bell with some people.
When I first started out, I was inspired by numerous videos and blog posts talking about open source culture and all the things you can learn and gain by participating in it. So I did my fair share of scrolling through bug trackers, reading Github issues, subscribing to mailing lists, and making tentative pull requests. The problem was that I’d often get stuck.
Making your first open source contribution
There are many resources out there that talk about making your first open source contribution, and many projects these days include some sort of tag for easy issues reserved for “first timers”. Often, a recommendation is to fix some documentation as one’s first contribution.
My general experience is that these worked out well. Documentation fixes are great because they bring about clear and immediate value1, are easy to review, and usually introduce the contributor to the code base, build system, and contribution workflow. Easy issues are really great too because they usually involve localised parts of the code base and have the added benefit of introducing the contributor to issue trackers and related workflows.
But while documentation fixes and reserved easy issue are great, it’s hard to progress from there as a beginner. It’s not impossible of course, I didn’t use the word “impossible”. It’s certainly been done before: Mariatta Wijaya shared her story of how she started her journey on becoming a Python Core Developer by fixing typos. It might even be a great way to progress — some of my biggest progress made in grokking a part of the Linux kernel was by rewriting the documentation for it —, but it’s hard for a beginner to see a path forward from here.
The goal of starting small is to make one’s first contribution manageable. After all, you can only swallow a mountain one bite at a time. But one wants their contributions to grow from there, so we need to talk about making one’s second contribution to an open source project2.
Making your second open source contribution
Sometimes, one then manages to make a contribution with greater depth than before. I experienced this after I dove into the CPython codebase and gained the confidence to tackle a longer-existing bug.
But depending on the community, it’s hard to proceed from here. I used to find myself stuck after making a couple of initial contributions, and I wouldn’t know how to continue growing as a contributor.
Making your third open source contribution
This brings us to the point of this blog post: how does one break through this roadblock and make their “third” contribution to an open source project.
On the value of mentors
I have to admit that I probably couldn’t have figured this out on my own. I had the fortune of knowing great mentors — Shuah Khan, Greg Kroah-Hartman, and Daniel Vetter — who showed me the ropes on becoming a Linux kernel developer. Shuah and Greg are both Linux maintainers and fellows at the Linux Foundation, and they were the official mentors of the Linux Kernel Mentorship Program. Daniel Vetter is a maintainer for the graphics subsystem in Linux, and had the fortune/misfortune to have had to review many of my patches.
Broadly speaking, my mentors helped me break through the contribution barrier along two axes — the technical axis, and the emotional axis.
Along the technical axis, my mentors compiled many invaluable learning resources for all steps of the journey. And, crucially, they provided very fast feedback for everything I did. They commented on my patches, and pointed me towards other areas of the codebase that have similar problems or could be improved. Sometimes, when I submitted a patch that I didn’t realise would break the kernel, they would point out what went wrong and point me towards continuous integration resources that I could use to test my patches.
Along the emotional axis, my mentors provided encouragement and career advice. We often forget that programming is hard, technical, and creative work, and as with such work, emotional blockers can hold us back. I think I speak for many people when I say that there’s a lot of self-doubt involved when working on a project that’s larger and older than ourselves, with much more experienced people working on it. Hearing directly from maintainers that our work is valued helps remove the hesitation and worries when making contributions. Career advice too is surprisingly powerful. It’s great for helping advisees understand the industry better, and of course helps with landing a job. But an unexpected powerful aspect is that it sends a clear message that you belong in the community, that you are a Linux kernel developer, and that you have a future in this line of work.
The technical and emotional aspects are two legs that one needs to walk on in order to grow as a contributor and to go past any barriers.
A guide for making your third contribution
(in open source, or in life, the universe, and everything)
At this point, I imagine someone would start saying “well that’s great and all Desmond, but how do I make my third contribution without the benefit of a structured mentorship program?”
Taking the lessons from my summer of working on the Linux kernel, I’ve discovered a set of steps (not exhaustive) that I’ve applied elsewhere with success. This really isn’t a specific guide on how to grow as a contributor to open source, but on how to grow as a contributor to anything. Here they are:
- Get interested
- Follow the conversation
- Do something! Anything!
- Find mentors (formal and informal)
- Stay in the game (go to step 1)
The first step is to get interested. Remember that contributing to creative work isn’t simply a technical battle, but also an emotional one. You need a strong enough “why” to help push through any struggles that you’ll face along the way. Do this by talking to friends, to people in the community, or, my favourite, by reading tons of blog posts about the subject.
The second step is to follow the conversation. All projects have communities, and all communities have conversations. Contributing to the project partly involves being able to listen to the conversation and jump in with the right thing at the right time. For example, during the mentorship program, I followed every single email thread that came out of the Syzkaller google group. Doing this had the benefit of showing me how other people approached problems, how they discussed them and eventually worked towards a solution. It also showed me that I wasn’t alone in rubbing my head about how to fix some of the bugs that appeared.
Step three is to do something. Anything, really. We often get caught up thinking that we need to make a perfect and impactful contribution. But this biases us towards inaction, and is very emotionally draining. Instead, do whatever you can, and you’ll feel excited to do more from there. For example, the first patch I ever made to the Linux kernel was to remove a link to a non-existent documentation page. And it was thrilling. I still remember how much my heart pounded when I released my work into the world.
Next is to find mentors. Official mentors, if you can. But communities also present many opportunities for unofficial mentorship. In the Linux kernel community, you can always bet that either a maintainer or a fellow contributor will have something to say about your patch to help you improve it (though you might have to ping them sometimes).
And the last, and perhaps most important step, is to stay in the game. The true champs are often those who outlast everyone else, rather than being the toughest and sharpest tool in the shed. And this is advice that applies no matter what stage you might find yourself in. I think all these steps are worth revisiting over a career, and not simply when one is starting out.
Closing thoughts
Open source powers the world. But there isn’t enough support for the developers and fledglings who want to get into the game. The recent Log4j vulnerability sparked many conversations about how to better support open source maintainers and contributors, but as always the result is just underwhelming. I don’t purport to know how to fix these issues, but I can at least do my part for those of us who participate in open source because we see the magic in it. Hopefully these reflections can help someone along the way, or show someone that they’re not alone in their journeys to grow as contributors. And if anyone ever wants to reach out, my contact details are available on this website.
Notes
- Brett Cannon mentions in his talk on Setting Expectations for Open Source Participation that an open source contribution can be like someone trying to give you a puppy you didn’t want. The takeaway here is that the puppy a contributor gives must be obviously good (at least, until they have a reputation of giving obviously good puppies).
- In case it isn’t already clear, I’m not referring to literal first/second/third contributions, but rather three classes of contributions that one progresses through.