Contributing to open source projects will make you a better developer. There’s nothing quite like feeling the pressure of potentially thousands of other people using and experimenting with your code. The mass accountability of open source will hone your developer skills like nothing else.
X-Team is a big proponent of open source; it’s an important factor in our decision on who to hire. But we also understand that jumping into an open source project can be a daunting prospect for those who are new to it. So we asked X-Teamers experienced with contributing to open source projects for their most valuable nuggets of insight.
Finding the Time
Let’s get a common excuse out of the way first. Deep down, we all know that “I don’t have time” really means “I don’t care for it enough.” You have enough time to contribute to open source projects, but you might need to reshuffle your priorities.
At this point, it’s worth mentioning that contributing to open source is not just charity work. That’s a gross oversimplification.
For one, as said above, companies look at your record of open source contributions to determine whether or not to hire you. A regular open source contributor has a much higher chance of being hired than someone who’s never contributed to open source. It’s the fuel you can use to sell yourself with.
“Think of the benefits. There are a lot of benefits of sharing your library with others: you’ll get feedback from other developers in the same situation as you, hone your programming skills, learn how to deal with feature requests, how to talk with others, and how to have a tech discussion. Those qualities are invaluable.” (Rubens Mariuzzo, Full-stack Web Developer)
Secondly, open source doesn’t always mean you'll coding for free. Let’s take the example of Evan You, the creator of JavaScript framework Vue. He made the time and pushed out Vue 1.0 while on a vacation (he was working for Google at the time). Fast-forward to today and he earns over $15,000 per month because of all the people who funded him through his Patreon page.
That’s not even talking about the impact he’s made to the open source community and the programming world in general. Money shouldn’t ever be the primary motivator for contributing to open source. It’s about honing your skills, making yourself sellable, and creating your programming legacy.
Finding the Right Open Source Project
When you're looking for your first open source project, don’t just trawl GitHub repos looking for a project. Start the search within the realm of your own needs and interests. What small frustrations do you have that an open source project solves? Go work on that project. If something makes a personal difference to you, your contributions will be so much better.
When you’ve found a project, you first want to make sure it’s still being worked on. Next, you want to consider the people. Look for the hallmarks of a good project: an up-to-date list of issues and a wiki will help you a lot. Make sure it’s a project that takes care of its committers. Medium-sized, established projects are usually the way to go.
How to Start Contributing
Don’t feel as if every contribution needs to be a masterpiece before sharing it. The owner of a project will usually be very happy with your contribution, as long as you’re adding value for someone (even if that someone is you). This can be a small contribution, too. Just make sure you explain your use case and how your pull request solves for it.
Additionally, don’t just throw code at people. Have a conversation. Consider the difference between sending a PR that says “what do you think about this?” versus one that says “here are some changes, please merge.” Which one do you think will get a better reaction?
Consider what unique value you can bring to the table too. Perhaps you’re a native speaker in a less popular language? Perhaps you can host an event about the project you’re working on? Open source isn’t just about code. It’s a community too. It can be a great avenue to meet new people.
Finally, don’t be afraid to ask for help. You’re in this together with the other developers; they’re not the programming masterminds we sometimes fear them to be. Some might be further along on their programming journey, but all were beginners at some point and most are very willing to help. So don’t be shy asking them for advice.
In Conclusion
Working on an open source project is worth your time. It makes you a better developer, makes it easier for companies to hire you, and it shapes your programming legacy. When choosing a project, make sure you start with one that you want to see succeed because it solves one of your own problems. Next, make sure it’s being maintained properly.
Start with a small contribution to get the hang of it. Have a conversation when sending a PR and try to find out what unique value you can bring to the project. When you struggle with something, ask for help. It’s a community of like-minded individuals, most of whom are passionate about programming, and many will be happy to help you out.
Top comments (4)
Relatable 🙋 I may admit that finding that project is very difficult. My trick is to check at the dependecies of your personal projects or some tools that I get from various mailing lists.
Dependencies 🤯 nice.
I find getting stuck (or missing a feature) with a package the ideal moment to have a look how it works and if it's doable to add it yourself. Daunting at first, and there might be occasions where it turns out to be uncomfortable at your current experience level.
Still, looking into the source code can be very valuable - and the moment you can build your missing feature will come. When struggling with creating a pull request the first time, I'd recommend having a look at this guide by Matt Stauffer.
I'm looking around for some projects currently, great advice in the article on how to taper down the search.
Do you think there is any relationship between project size and PR size? For example, in the case of a newer, smaller project, perhaps navi (not clear to me if that's open source?) I would probably feel comfortable writing a couple hundred lines before making a PR. If I were attempting to contributing to TypeScript, I think I would be inclined to submit PRs well under a hundred lines.
I would appreciate your thoughts ✌️