This site runs best with JavaScript enabled.

What open source project should I contribute to?

June 03, 2019


My silver bullet answer to this frequently posed question, and how to get started

This is a question I've had countless times:

Pranu first pull request soon after tweeting this

And in direct messages, emails, etc. The general gist of it is: "What open source project can you recommend I start contributing to?" Many of these people read my First Timers Only post and are hoping to find a project that is friendly to newcomers making pull requests.

The Answer

My silver bullet answer comes from my blog post Open Source Stamina:

You contribute best to something you use regularly

Where I've found the most satisfaction out of contributing to open source is in projects that matter to me and (possibly) others. And then contributing to that project regularly. To do that you need to have an understanding of the use cases and pains associated with a particular tool or library. This is why I say it's best to contribute to something you use regularly.

What open source libraries/frameworks/tools do you use regularly? Perhaps you're working with Webpack and feel like a configuration option could be improved or documented better. Or maybe you're working with a React or Vue library that could use a little polish. One thing's certain, whatever you're building, you're probably using an open source project or tool that you could personally benefit from contributing to.

Step 1: Open your package.json and read through the dependencies you have. Think back on your experience learning and using that module. Remember struggling with one of them? Pick that one.

Contributing

Once you've found the project you want to contribute to, how do you know what to contribute? Many projects have a CONTRIBUTING file. Look for that first to find instructions for contributing to the project. If there isn't one, there may be instructions in the README (normally shown on the homepage of the project). If there aren't any such instructions, you might submit a pull request to add just a skeleton CONTRIBUTING.md file to start a conversation about adding one.

Familiarize yourself with the project. Reading documentation is good, but my favorite way to learn how a project works is by reading the code. My favorite way to do this is by sticking a debugger before I call a library function or when a library calls my function and jumping around the call stack, like this:

Step through the code and you'll learn a lot about how the framework/library works. Don't worry if you don't understand what's going on right away. That will come with time. Keep at it. You can do it! You can do this same thing with non-browser based tools with your favorite node debugger (or add console.logs).

Once you've figured out the standards and processes for contributing to the project and familiarized yourself with its inner-workings a bit, you'll need to identify the changes that the project needs. I recommend you look at existing issues and comment on ones you think are interesting. Work with the maintainer(s) to identify a good implementation and make your pull request!

If you have your own idea of a bug fix or a feature you want to implement, I strongly recommend you run it by the project maintainer(s) in a GitHub issue first. Perhaps they'll say it's out of scope for the project or they're working on it, or they could give you some direction. You'll waste less time by making sure your pull request will be accepted before you make it (just like how I was certain my wife would answer "yes" when I asked her to marry me before I asked 😃).

Also, see this page for more tips on contributing.

Your First Pull Request

For your first pull request, feel free to just find a random project out there with a good first timer bug/feature and try your hand at contributing. Let the project maintainer know that you're new and are wanting some guidance to learn how to get into it. Maybe they're too busy to help, if so, move on and find another project. That first contribution is the hardest, you may want some help and coaching. The actual code contribution matters less than learning the process. So find a project or someone who has time and patience to mentor you.

You might also be interested in watching my free egghead.io course How to Contribute to an Open Source Project on GitHub:

Course Artwork

Resources

Take a look at GitHub's issues for issues labeled first-timers-only, good for beginners, good first bug (or good-first-bug), or help wanted (more here... we need to standardize on this).

Also, here are good resources for finding simple ways to contribute:

Your First PR (@yourfirstpr)

first-timers-only (@first_tmrs_only)

24 Pull Requests

Up For Grabs

MunGell/awesome-for-beginners

My first PR was to fix a typo in a comment (find yours). It was super small and it was to a project that I didn't really use all that much (discovered the typo when stepping through their code in a debugger). It was a great first contribution, even though I didn't really make a lasting impact on the project and I wasn't motivated to continue contributing, it got me over the hump of contributing for the first time which is the hardest part.

Conclusion

Contributing to open source has been awesome for me and I highly recommend others to get into it. It's really hard getting started, but once you get over the first contribution, making future contributions is much easier. It's not all roses. The open source community has its warts here and there. Keep working at it. You'll do great! Good luck!

By the way, if you're interested in creating your own project, be sure to check out my series on egghead.io:

How to Write an Open Source JavaScript Library

Discuss on TwitterEdit post on GitHub

Share article
loading relevant upcoming workshops...
Kent C. Dodds

Kent C. Dodds is a JavaScript software engineer and teacher. He's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices. He lives with his wife and four kids in Utah.