The Mechanics of Contributing
Contributing to open source can be done in 4 steps.
- Find an opportunity
- Fork the repository
- Make changes on your fork
- Submit a pull request
The first 3 steps have been covered ad nauseam. If you’re interested in the mechanics of making a pull request, Kent C. Dodds has created a great resource on submitting your first PR.
The mechanics of submitting your pull request are, unfortunately, the easy part. They’re the same no matter who you are or what project you’re contributing to. The real magic happens at step 1: finding an opportunity.
2 Ways to Find an Opportunity
Aspiring web developers are interested in making contributions to open source because they believe it makes them look better to prospective employers. I ran a quick informal poll on Twitter to find out if this is actually the case. The responses were interesting and maybe a little surprising.
Christopher Hawkins@chris_hawk
@raddevon Speaking as a longtime employer of developers, I have exactly zero interest in whether or not a candidate contributes to open source.04:50 AM - 19 Nov 2018
Ben Hyrman@hyrmn@raddevon @venikunche Yes I look. For me they can help and they never hurt (eg, I wouldn't hold "bad" code against a junior). If it is the person's own work and "substantial" then I get a sense for their existing strengths and interests.14:02 PM - 19 Nov 2018
Stella Pantela@stylianipantela@raddevon Zero unless the candidate lists out a specific project on their resume or brings it up.14:23 PM - 19 Nov 2018
Brett@bzmw_@raddevon @venikunche I do not look unless they call it out on the resume. And even then there are so many things to be considered: are they just updating docs, are they making a meaningful contribution, is the project "serious"19:51 PM - 19 Nov 2018
It looks like, at least for most of the people who responded, open source contributions are not a factor they consider. For the one respondent who said they do look at it, I get the sense you wouldn’t be disqualified if you hadn’t contributed to open source; it’s just a bonus if you have.
Even if it may go unnoticed in your job search, contributing to open source is a worthwhile pursuit. You can help the developer community, make yourself more visible, and solve some of your own problems. Here are the two ways you might approach finding where you can contribute as a new developer.
Seeking Out Opportunities
This is the approach most new developers take since they want to start touting that contribution in their interviews. In my experience, this is the more difficult approach for newbies. Ideally, you’re going to pick a library you’ve used before so you’re at least somewhat familiar with it. Then, you’ll browse the repository’s open issues to find one you think you can tackle.
If you want to contribute code, you’ll need to gain some familiarity with the codebase first so that you know where you need to be working to add the desired feature or to fix the bug you’re targeting. It’s a pretty big ask for a new developer: grab an issue, figure out the codebase, and write a pull request to address the issue. Reading code is not an easy skill and is a big part of this process.
If you’re going to go this route, here are some ideas and resources to make your life easier.
- If you want to contribute to a library you’re unfamiliar with, start with the documentation instead of the code. This is a natural fit for you since you’ll be using the documentation to learn the library anyway. You’re bound to find weaknesses. When you find them, clean them up for the next person who reads the docs.
- Libraries often have labels to identify newbie-friendly issues. React, for example, has a label called “good first issue.” Seek these out to find an issue you can tackle.
- Many sites curate good opportunities for newbies to contribute to open source. Check out Up For Grabs or the Awesome First PR Opportunities repo for a couple of good examples. Since the awesome list is itself a repository on Github, you could actually contribute to it by adding other good newbie opportunities you find. So meta!
- Hacktoberfest is an annual event encouraging contributions to open source projects. The event helps you find great opportunities and rewards you with a t-shirt for!
Since this is the hardest road to take and since it doesn’t seem to have much impact on your job prospects, I’d avoid this approach in favor of a more “organic” approach to finding opportunities to contribute to an open source project.
Waiting for an "Organic" Opportunity
When you stop trying to force things, you’ll find it much easier to contribute to an open source project… although it might take more time for the opportunity to present itself.
My first merged pull request was for a library called Telescope (now VulcanJS). It was a framework built on MeteorJS to make it easy to set up Reddit-style link voting social networks. I was using the framework to build a news sharing site for indie game developers called GameDev News.
Telescope made my life a lot easier, but it lacked one feature I really needed: it didn’t expose comments through the API. When you made a request, you would get the posts but no comments.
This was a great opportunity for me to start contributing to open source for a few reasons.
- I was already familiar with the codebase. I had been using the framework to build my site for a few weeks already.
- It was solving my own problem. That’s loads of motivation to dig into someone else’s code and make a contribution.
- I didn’t have to go hunting for an opportunity. The opportunity came to me.
I wrote a few lines of code to add the feature and submitted the pull request. The maintainer got back to me with a problem he saw while reviewing. I fixed that, and the pull request was merged!
All of my contributions have fit this mold. In one case, I found a library that sounded like it would do what I needed. The only problem was, it didn’t work. It simply failed to do what it claimed to do! I checked out the code to see if I could find the problem. It was really simple: the library was looking for a function to return a truthy value, but that function didn’t return anything.
I fixed it with two lines of code and submitted a pull request. That one still hasn’t been merged, (The library appears to be completely abandoned.) but I was able to use my fixed fork in the project I was working on.
If you keep building and keep your eyes open, you’ll find many of this kind of opportunity for you to fix your own problems while also contributing to open source.
Need some help navigating all this and increasing your chances to become a professional web developer? Set up a free mentoring session, and we’ll figure out your next steps together!
I want to help you take the next step to your web development career. Join me for a free mentoring session where we'll work together to help you move forward! Sign up at Rad Devon.
Don't Sweat the Timing
If the responses to my tweet are any indicator, you’re probably not going to get a job on the back of your contributions. That means the timing isn’t important. Instead of trying to force it, just let the opportunity to contribute to an open source project come to you. It’s a fantastic goal, but you don’t have to accomplish it today.
Top comments (8)
Fabulous post!!
Thank you, Ben! 😁
Hi! I have enjoyed every single inch of this post as I've never contributed to open source before. I also have a question.
Let's say I have built an app from watching a tutorial and later on I have added my own features. Does it make sense to submit a PR with these new features?
I have decided to go with the "organic" way of contributing to open source.
Thank you for your time. Happy holidays!
Glad you enjoyed the post, Andrei!
PRs are most useful when you're helping out with code other people maintain. A PR is basically a proposal to add some code to someone's project. They maintain the project. You have written some code you believe improves the project, but it's ultimately up to them to make the call. Hence the pull request.
When you're working on your own code, you're only going to write the code you know you want in the project, so making a pull request to yourself isn't really that useful. To add code to one of your existing projects, I'd just work on a branch until you have things the way you want them and then merge it into the master branch directly. No PR required.
Hope that helps. Happy holidays to you as well!
Great post, thank you!
Thx for this! This is really what I wanted. Helped A LOT.
Can I translate in Korean this post? If you don't mind, I wanna share this awesome post in Korean. Surely, There will be a link directing to this original post.
That would be great! Point back to the original source if you don't mind: raddevon.com/articles/how-do-i-con...
Glad you liked it!
This is wonderful post thank you!