Getting started with open source
3 min read
If you take a look at my repositories, you will see that a majority of them are small projects. Working on your own projects can teach you a lot, but working with others can teach you even more. You can learn a lot by reading someone elses code. I wanted to do this for some time now and last week I actually started doing that.
I thought about contributing to open source for some time now, but never did because most project were too intimidating. If that sounds familiar, then I might be able to give you some advice on starting out.
Finding a project you want to work on
The first step is to start looking for a project you want to contribute to. The advice I heard the most, was: “Start contributing to a project you already use”. For, me this didn’t work for a couple of reasons.
Looking at Firefox, Jekyll, Vagrant, Rails, Bundler and a couple others, I didn’t know where to start. Issue descriptions sounded cryptic, were very platform specific or involved knowing about a couple dozen different source files.
But working on a tool that you actually use sounds really nice. You know how the tool is supposed to work. And maybe you already have a rough idea how it is put together. But if there’s nothing you can contribute, you will have to look beyond projects that you use on a daily basis. That’s what I did. I started looking for projects that I liked and that I would like working on. Additionally I came up with some criteria that the project should meet as well:
- It is active. This includes time of the last commit and comment activity on issues or pull requests. If didn’t merge any pull requests within a couple months, chances are, yours probably won’t be merged either. If the last commit is 6 months old, that’s also an indicator for an abandoned project.
- Good documentation. There should be a guide on setting up the project. There should also be a guide on how to get your changes merged in.
- Lots of issues to pick from. Maybe they also have a beginner tag for issues.
- Manageable size. The bigger the project, the harder it will be to figure out where to change something in order to fix a bug. You will be able to contribute faster on smaller projects.
People won’t be mad at you for contributing to their project
Before you start working on a feature or bug report, make sure you have read the available documentation on how to contribute. My biggest fear was that I would mess something up with my branching and the pull request as I never used pull requests before. Reading the documentation has helped a lot. Make sure you have read Creating pull requests and Using pull requests.
If you are stuck with something, just ask in the specific issue. More often than not people will help you with problems. Some projects also encourage to submit pull request early. This way you can get feedback on your work before making more changes to it.
Some projects also have an IRC channel or a mailing lists. Spend some time reading those and learn what everyone is working on. See how the atmosphere is in general. Are people encouraged to ask questions? If you find that there is a lot of bickering, maybe start looking for another project.
Your first contribution
If you have read through the available documentation on your project, then it’s time to pick an issue you want to work on. You want to start out with simple issues, to get some experience with making pull requests and the issue system. Your first issue should be as simple as adding some documentation or adding a translation.
Contributing to open source projects really isn’t as scary as I thought it would be. I hope this post contains some useful advice. If you have decided to contribute to an open source project, let me know!22 Jan 2014