Did you land on this story looking for advice on how to start contributing to open source? There are tons of these stories on the inter-webs, aren't there?
And I am sure you must have read a lot of them by now, because you've been trying to start contributing for quite sometime. And you still feel like you've not progressed at all.
I get that feeling. I was in the exact same position until a few weeks ago. Let me tell you my story.
I've been trying to contribute to open source for about two years now.
Yes. Two years.
And there is one thing I can tell you with a lot of certainty – it's intimidating. It's tough to get started. You have to learn how to work within a large code base. You have to learn and adhere to a project's coding style guides.
Nothing makes sense. The control flow, how different modules interact, how and why the code is organized the way it is – it's all one big maze.
I feel like this all the time because I am, after all, just an amateur trying to learn as much as I can.
So I tried to take the easy way out: fixing typos in docs or comments in the code, doing trivial bug fixes because it was obvious what needed to be changed and where. I didn't want to ask too many questions or try to understand the code base.
Every time I wanted to contribute, I went to Github – or any bug tracker – and tried searching for issues with labels “easy”, “beginner”, “good first bug”, “low hanging fruit.” After sifting through hundreds of them, I found something trivial enough to do without any major external help.
Now, this worked for a while, until I realized that I could make better use of the skill set I was building up. I'd learned so many new things, but I couldn't figure out where to apply them. Just learning – without applying – counts for very little. I was stuck on a plateau, and I wasn't moving forward at all.
Then something happened that made me terribly scared about being a new contributor, trying to wade my way through the world of open source. I picked out an issue that seemed easy enough from a large, popular project.
I thought it would be better to ask clarifying questions before making any changes for fear of messing up. So I posted a comment saying that I was a new contributor, and asking how a particular piece of text should be altered so as to close the issue.
The reply I got was: “If you can't figure out how to make the change, you're not qualified to make the change.” This response baffled me, and made me even more scared to ask questions when I didn't understand something about a project.
Maybe I wasn't wanted because I didn't know enough? Maybe I needed to work more on my skills instead of asking stupid, lame questions to experienced people who're super busy?
This is when my quest for a mentor began as well. I felt that maybe if I knew someone with whom I was comfortable asking questions, things would be OK and I can make myself more useful.
So I emailed a bunch of people, asking them to help me get started since I was feeling particularly intimated after the aforementioned experience. I received a lot of positive replies full of encouragement, but I still didn't find exactly what I was looking for.
I felt like I was bumping into a closed environment in the world of opensource.
Everything seemed to suggest that I just put myself out there and not be scared. But I just wasn't up for this at the time.
Discovering Mozilla
I landed on this Mozilla project which helps you test web extensions one fine evening searching for issues to work on. I was glad to find a few issues labelled as “good first bugs”, but none of them were as simple as fixing a small typo.
Boy, I am so glad about that right now.
I started working on one of them, but quickly realized that I had to ask questions if I wanted to be able to close the issue. I skimmed through the code base. Once I had some sense of what was going on, I asked for more direction. And voilà ! I was able to solve the issue after getting all the relevant details I needed.
Now that I've opened three pull requests – one merged, and the other two on their way to being merged – I'm glad I took the plunge. I'm glad I didn't back down when it came time to ask relevant questions, even if it meant risking looking stupid sometimes.
It's okay to not know everything, and take one step at a time to learn something new.
The folks at Mozilla mentoring these issues have been nothing less than super helpful and supportive. They've guided me all the way, taking time out to break things down and explain them in incredible detail. This is despite the fact that they could've fixed these issues themselves in a few hours instead of spending time mentoring me toward a solution of my own over the course of several days.
I've learnt and discovered so many new things by working on just three basic issues. And I'm super excited to work on even more challenging bugs and expand my understanding and knowledge.
I can't thank them enough for being such a positive experience, because it led to setting up Firefox locally and scouring for bugs on Bugzilla every other day. (I'm saving the how's and why's for a more in-depth post).
I plan to continue contributing to Mozilla as regularly as possible. Every time I've asked a relevant question – be it on IRC, Github or Bugzilla – I've gotten a very friendly response.
As of now, I've closed three issues in web-ext, and gotten a patch accepted and landed for Firefox.
My contributions were noticed by the community, and I made it into theAddons Contribution Recognition document, as well.
All in all, my experience over the past few weeks has been nothing short of wonderful. I've learned so many things, big and small, that no engineering textbook can ever teach me.
My advice to fellow beginning developers who want to contribute to open source:
Tip #1: Don't be afraid to ask questions.
I can't stress on this enough. I lost a lot of time because I kept holding myself back, and this was my biggest inhibition.
Everyone is scared of looking stupid. But don't let that crippling fear result in stunted growth.
It's okay to ask if you don't understand something related to the project. The maintainers of the project have been well-versed in the project for years. They can help you fairly quickly. The alternative is you spending hours lost in their codebase trying to figure something out that you're not even supposed to know in the first place.
But be careful about asking for information that is already readily available to you via some documentation or Google searches. You want to be respectful of project maintainers' time.
Tip #2: It's OK to have holes in your knowledge.
You're not expected to know everything in and out if you want to start contributing to a project. The idea is to learn and grow as you start solving harder issues becoming more familiar with the project and the tooling they use. The time it takes for this to happen varies from project to project and person to person.
Tip #3: Just start
Don't waste a lot of time choosing the “right” project. If you know a project or a organization with a beginner-friendly community, just start there.
Find an issue you're comfortable taking up – preferably in a language you've been working with for a while – and try to figure out what needs to be done. Ask for the relevant information to fill the gaps in your knowledge, then get to work. Don't wait.
Thank you, open source maintainers!
A huge shout-out to all the open source maintainers who have been super responsive and encourage of new contributors. You are helping newcomers navigate huge code bases and contribute in maybe a small yet meaningful ways. Your efforts are truly appreciated and needed.
As a newbie and a junior developer, I'm just trying to find my way through this vast and incredible tech industry. A few minutes of your mentorship – be it being introducing to a simple debugging technique or showing me how to write proper test cases – will help me become a better developer in the long run.
You have the experience, and I have the incessant desire to learn as much as I can.
A special thanks to Guido, Kumar McMillan, and Luca for being amazing mentors throughout this journey, following up every time, and answering my various questions. I really appreciate all the time and effort you've invested in me. :)
If you're a fellow struggling newcomer to open source, I'd like to hear about your experience and story. If I can help you in any way, please don't hesitate to reach out!
I plan to document my journey of contributing to open source, so if there is anything in particular you'd like me to write about, please drop a comment.
Thanks to Pawan Dubey and Quincy Larson for helping me refine this article.
This article was originally published on Medium.
Top comments (1)
Like. Keep it up!