Ask HN: How to begin contributing to open source?

17 points by tarasyarema ↗ HN
I've been coding for 5 years already and I was always interested in open source projects. I'm always exploring new projects on Github and looking at code from one place or another, but I feel like I do not have the skills to go to the issues, pick one, and begin to help the project in question.

I'm not asking how to make pull requests or anything. Just for advice for someone that wants to introduce himself to the open source world.

So, any tip for picking a first project, without any preferences besides (maybe) the language?

Note: The languages I more or less know are Python, C/C++, Javascript and Go.

13 comments

[ 3.3 ms ] story [ 27.1 ms ] thread
What about documentation? Often times its easier to improve the docs than to improve the code. And let's face it - most open source projects have awful documentation!

If you don't want to interact with open source project maintainers, you could try writing example programs, tutorials, or guides for products you like - that's another form of contribution.

That's exactly what I did in a recent project. Basically, I found a cool library, but the docs were pretty spotty, so I fleshed it out a bit as I became more familiar with the code. I ended up doing some minor refactoring to make the library more consistent (e.g. naming, this was just before a major release).

After that, I ended up finding a bug, and since I was already familiar with the code from fixing minor documentation stuff, I was able to submit a patch without asking anyone.

You should find something that your interested in. My first project was Mixxx because I was interested in DJing. This doesn't have to be hobby related, it can be something that satisfies an intellectual curiosity.

Contributing to OSS is a bit like working out, when you get into a routine its easy but starting is very difficult. The trick is to just start.

Pick any a project that interest you and whose language and domain matches your skillset. Find its mailing list or IRC channel or whatever community it has. Ask for help selecting a first ticket from the issue tracker.

Most communities are thrilled to get new contributors and willing to put in the effort to get you pointed in the right direction the first time around. If they aren’t, move on to another project. In fact, skimming the recent mailing list archives can be a good way to get a pulse on the culture of a project and how welcoming it’s community is.

Asking the community is the important part.

I went into a community asking where to get started working on a feature I wanted, and I got a lot more pushback than I expected. Basically, it was obvious that I didn't know the codebase very well and was expecting someone to walk me through it. Starting with a small ticket is a good way to get introduced to a limited portion of the codebase, which will help you ask better questions when you inevitably want to add a feature.

I went into another community with a patch for my use case, and it was rejected because it didn't fit with the overall goals of the project. If I had made more of an effort to engage over the mailing list, I could have saved myself a lot of work and perhaps ended up with a better solution.

So yes, absolutely get involved in the mailing lists after doing some basic legwork yourself (get your dev environment set up, read some recent mailing list entries to get a feel for the most active people, etc).

I like documenting how the devenv is setup and making a pull request against the readme as an introduction.

Finding the right project from a personality aspect is really key. Not everyone is going to click and that is ok. Finding a project will make working on the codebase and interacting with folks invigorating, the wrong project makes it feel like a job.

Pick a project with an "easy" or "first bug" tag on their issues. If you get stuck, just ask for help. The nice thing about the tag is that it's a demonstration of interest in helping people get started.
One idea would be to pick a project that you actually use. This means you'll already have an understanding of what the project is about, and you can directly benefit from whatever work you end up doing, which is a nice added incentive. Even big projects will likely have lots of small fixup/documentation issues which no one has gotten around to, but will add value, so don't feel too put off by the size of a project.
That's a tough one... Find something you're passionate about - something you'd truly like to build yourself.

If there's already something on github, join that - you can even do a fork first, and play around.

Otherwise, just build a new project on github, commit to it, and let people know here/reddit - and see if they'll join

List all the open source dependencies you use at work or at home. Start by checking out the one that turns up the most often and work your way down from there.