What open source project should I contribute to?

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

https://octodex.github.com/repo/

This is a question I’ve had countless times:

Pranu just made his first pull request: https://github.com/Automattic/mongoose/pull/3644

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 Grunt, Gulp, Webpack, or Browserify and feel like an API could be improved or documented better. Or maybe you’re working with a React library or Angular module 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.

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 stepping into function calls with a debugger. For example, what happens when you call angular.module? (gif below may take time to load, sorry).

So nobody feels left out, see React’s and Ember’s :-)

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 just 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 recently released series about how to contribute to open source projects on GitHub:

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:

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!

Do you need an introduction to GitHub and Git? Check this out from GitHub:

And if you’re interested in creating your own project, be sure to check out my series on Egghead.io:

And as always, I’ll see you around on Twitter and GitHub :-)