Ask HN: How to begin contributing to an open source project?

Find a project you're actually interested in (not just interested in the notoriety of being a part of). The ide/environment kind of depends on the project and the language/assets that you'll be working with specifically.

Once you find a project you're interested in, find them on irc. Don't be too pushy, hang out and try to pick up on the dynamic. That doesn't mean you should be silent, just don't be annoying.

A great way to catch up on an existing project (the earlier you get on board btw, the easier it will be to start) is to start helping out with testing. A lot of programmers don't enjoy writing automated tests (which they should be writing first anyways), so that stuff usually gets left to someone to clean up. An ancillary benefit of which is that you can learn a ton about a project by adding tests.

The only other thing you'll probably need some experience with kind of across the board is version control. Experiment a little with git/svn so that you aren't intimidated by submitting patches (version control can seem intimidating before you've worked with it, but most of the time it's pretty basic).

First step: find the project you want to contribute. I would've picked a project which 1) I already use, so im already familiar with it 2) Has a little codebase so diving into it would be a little bit easier 3) Has an active development community

Second step is to use it, if you havent used it already. You wont be able to contribute to a software which you havent even used by now.

And when you use software, you will have little ideas to improve it. Or little bugs that annoy you.

Third step is diving into the source code, understanding the codebase and actually doing the changes. At this step, you might need to communicate the authors. This is an imporant part.

You can usually find developers on mailing lists and/or irc channels. Use these tools to contact authors and ask for their help. Dont be afraid, you are not supposed to do it all by yourself without asking anything. On the conterary, asking developers assures that you're doing it the right way. However, you should ask smart question. This one makes differrence. (Read Eric Reymond's article about this.)

Last step, is giving the patch to authors. if the project uses a proper SCM, you will be able to produce a patch easily. Send the patch to authors and wait for their response. Some projects have reviewboards which you can post your patch there and wait for their review.

Now, depending on the project, the path you go may differ. Dont bug developers too much. Dont hurry. Be friendly with them. Be Patience.

Also, this website is created for this exact purpose: http://openhatch.com

(Some projects have JuniorJobs, which are easy tasks for newcomers to start contributing, if you havent already found 'what' you want to do)

Fix bugs. That's the best way to learn and make friends. It will give you exposure to the code base and existing code conventions.you'll learn much more and get some street cred.

I second what has been said already. Pick something you like and really enjoy. That makes it worthwhile.

Look for projects that make it easy to contribute and have reasonable documentation.

Being always on the lookout for great people, I'll toss our project contributor's page here to see if you are interested (hehe) and show what I mean http://wiki.amahi.org/index.php/Contribute :)

It is a bit hard to answer the questions you're asking without knowing what languages you know (or what languages you feel vaguely comfortable with the syntax of).

In any case, one bit of advice that I'd like to throw out there that isn't usually suggested: Follow up on the patch. After sending it in, check up on it. Make sure the folks behind the project are happy with it (else it might sit and gather bitrot while waiting for someone to fix it up). If/when it is committed, look the commit over. Is it an exact commit, or did the developer who committed it modify it somehow (formatting, to use a different method, etc)?

This way, if (or likely, "when," if you're serious about this) you submit a second patch, it'll be slightly better -- slightly more likely to be committed, slightly less effort for the dev to review, etc.

Start reading the code, write patches, send them to the author/make a pull request.

I would recommend in addition to contributing to other projects, to try to start something of your own. Find something small and useful you can work on, and release it. It doesn't matter if it's small - the experience you get maintaining your own project will teach you a lot about how to contribute to other people's projects.

My first open source project was a PHP script called "DBMailer" that I wrote when I had been programming for only a few weeks. I'm sometimes embarrassed that it's still floating around the internet with my name on it, but I learned a lot from the feedback I got from it at the time.

I wrote a blog post a while back with some do's and don't's for both contributors and maintainers, maybe you'll find it interesting:

http://njclarke.com/posts/how-to-do-open-source.html

Good luck, and stay enthusiastic!

There is no general answer, because every project has a different workflow and culture. If you would like to hack on my little command-line bug tracker the answers would be like this:

- checkout the code from GitHub http://github.com/beza1e1/later

- use the "later" executable itself to find out, what issues are unresolved (e.g. "Web frontend")

- get familiar with the code base and especially the plugin architecture

- write some code (with whatever IDE or editor you like)

- send me a message, when you have something to look at

- after some reviewing (and probably changing) we can merge your code into the mainline

- Congratulations!

I use an instance of mediawiki for my project and am always looking to have little things done. I usually end up paying programmers on a case-by-case basis. If you or anyone else want me to send you emails when something pops up I'll be more than happy to :)

If you're just starting out, you could try one of the big projects that have a well established community and guiding processes/mentors to help you out.

I've been a Fedora Project contributor for about two years and it's been great. They have a lot of very different ways of contributing and a lot of different projects.

I contribute to the Infrastructure team; almost all of Fedora's infrastructure is built and maintained by the Fedora community. There are a lot of apps, APIs and they all communicate with one another: build service, accounts system, updates management, package database etc. Most of them are python TurboGears apps.

I'm also a package maintainer and that's another great way to learn how different open source projects work and interact with upstreams. Being a package maintainer is a lot more fun and challenging than it would appear. It's also a great way to find out other projects to contribute to.

There's a lot of information about contributing on this page: http://fedoraproject.org/wiki/Join and you can feel free to ask me more here or in private.

"OpenHatch: thousands of bite-sized bugs"

http://openhatch.org/

I was just looking into this subject today, right before I read this post. Here's what I'm doing and would recommend.

Join the forum related to your Linux/BSD distro of choice and check out the project page and see what needs help and what needs work. See if there's anything you're interested in already and go with that. If not, a good project to join would be bug tracking; for an example see the corresponding project from Fedora:

https://fedoraproject.org/wiki/BugZappers

Or Debian:

http://www.debian.org/Bugs/

Follow the directions, get your feet wet and eventually, if not from the very start, ask for a mentor already in the project and ask questions of them. Follow the project #IRC for a while and you'll get a good feel for where the work is needed. If you graduate into more technically challenging projects while at the same time being beneficial to the project, you will surely learn a lot and hopefully gain some invaluable experience.

You need to find some project you actually use (say, FreeBSD). Then, you must fall in love with it (because it had a beautiful design decisions, like arc, or coded elegantly, like nginx or just got a lot of buzz, like clojure). Due to your love, you will read all developer's mailing lists, sites and blog posts related to it. After that you probably feel an urge to improve the thing you love. Now you can start contributing. Everything else will be obvious at that time. ^_^

Choose something you use yourself. From the discussions on the user mailing list/forum you will soon find out what features users are missing. Or take a look at the bug tracker. Many procects have todo lists somewhere in the source tree. The usual way would be to implement a feature you miss.

Before contributing, check how the developer team reacted to patches in the past -- there are teams that tend to ignore them.

Most often developers will happily help you if you have specific questions about the code.

Start with small patches or isolated modules that don't take the core developers too long to review and adapt to their "style".

Adhere to the project's coding style.

Either pick a project you're using yourself and look at the bug/feature tracker and ask the developers what they'd recommend working on (probably best place is IRC). Or start your own (small) project for something you always wanted to do.

Here's how I became a contributor of mootools (a javascript framework).

1. I stumbled upon the project pre 1.0, loved it's ideas, but my javascript wasn't good.

2. I checked out the code and loved the style.

3. I started hanging around in IRC where the core developers chatted about decisions and problems.

4. I read the source code and when I wasn't sure why some code was like it was, I asked in the channel. Either someone of the team explained why it's that way, or committed my minor suggestion.

5. That way I learned more and more about the language and the project. My suggestions became better. I loved to see my suggestions being picked up and used in the wild.

6. Eventually I got commit rights (though that wasn't important to me)

My advice is to just go for it. Join the IRC room, talk with the people. Help with bugs or documentation. It's easier to get involved than you might think, there are never enough people working on such projects.

You will be welcomed by the community!

Check out these screencasts (links below). Even if you never work with Rails or Ruby it'll give you an idea of how to contribute to other projects.

http://railscasts.com/episodes/50-contributing-to-rails

http://railscasts.com/episodes/113-contributing-to-rails-wit...

Almost all open source projects are very happy to get additional help. It might be difficult though to be able to contribute to their source code in some cases if you have too less experience in the field (for example, to contribute to the Linux kernel, you either must have very good OS knowledge or specific knowledge about how to implement a new kernel driver for some yet unsupported hardware or so). And I guess from your question that you are mostly interested in contributing to the code.

What open source tools are you using yourself? Have you ever found some bugs in some of them? Or missed some feature? Then this might be a good place where you could start: Just implement that feature or fix the bug. If you don't really know how to provide your patch to them or where to start: Just speak with their devs; in most cases, they will be glad to help you out.

Some other questions you should maybe ask yourself:

Do you prefer to work in a very big project (KDE or so) or would you prefer to work in a very small one? You will find OSS projects of all sizes, even often just of a single guy/girl where you could ask to join him/her. The experience you will get might be quite different depending on the size of the project. I think, but that is also hard to tell, that it maybe might be more fun in a smaller team (because then you know everybody and you just need less bureaucracy). You will also find quite a lot of dead projects, i.e. projects where there is no active developer anymore. The old maintainers of such projects will be very happy if you tell them that you want to revitalize that project.

What type of project should it be? Some tool? A webbrowser (Chromium, Firefox)? A game? A whole Linux distribution (Debian, Ubuntu, Gentoo, ...)? A window manager (KDE, Gnome, E17, ...)? Depending on that, the programming experience you will get will also differ quite a lot. I have found that developing a game will often lead to the most wide range of experience and knowledge. (I have written an article about that: http://www.openlierox.net/wiki/index.php/Why_game_developmen... )

Where I am at it: I am one of the leads of the OpenLieroX project and of course, we can also need some help. :) We are a quite small team (3 devs basically) and have a quite huge codebase right now (about 300k loc -- could need some cleanup, though). Just for the purpose to tell people where to start, we also have a small article: http://www.openlierox.net/wiki/index.php/Contribute_to_the_s...

In that article, I also describe some further ways how you could get more experience at coding. Another way might be to start your own project from scratch, maybe together with some friends (or ask here or elsewhere for some strangers who might join you). However, this might be a quite difficult taks. Often, you are overestimating what you can do and the project will become quite big and often stay unfinished forever.

OpenLieroX started as an almost dead project. It was closed source in the beginning (called LieroX), then the original developer (just a single guy) stopped the development. And he did the right thing: Before letting the project die, he released the source code. And there is where OpenLieroX started. First there were two separated projects, one by me, one by another guy but once we have heard about each other, we also did the right thing and merged to one single new project.

The flip side of this is just as interesting and not as often discussed: as a project maintainer, what can I do to make sure people like the submitter feel comfortable and welcome contributing to my project?

Here are a few things I've done with Leiningen, my Clojure build tool:

* Start "low-hanging fruit" threads after every release explaining simple ways people can contribute.

* Create a HACKING guide describing the overall architecture and flow of the project. Include style guidelines and instructions for submitting patches.

* Give people commit rights as soon as possible. I've adopted the "one accepted patch, and you're good" policy from the Rubinius project. Yes, this means unqualified people will have the power to make ill-informed commits directly. But in practice people tend to behave when you give them responsibility. Evan, the Rubinius lead, has had to perform less than ten reverts in the three years he's used the policy.

Make sure you know how to use a mainstream version control system, Git is gaining popularity quickly among DVCS' but there are still a lot of projects out there using regular old SVN.

If you know PHP, I suggest contributing to Drupal at http://drupal.org/contribute

Start by installing Drupal, then learning how to checkout code from the CVS repository, then how to apply patches, how to review patches, and finally you can apply for CVS access to contribute back your own code.

I'd be happy to mentor you if you want to give it a shot.

Stu Halloway's Refactotum talk offers a good approach...

http://thinkrelevance.com/blog/2008/05/23/refactotum-overvie...

First find an open source project that you want to contribute to. Next find it's issue/bug tracker. Find an issue that you can reproduce relatively easily. Next get the source code and start tinkering around till you try and figure out why the issue happens. Next try and fix the issue and if necessary add tests. Create a patch and submit!

Even if you can't solve the issue, just reproducing it and reporting your findings can be very helpful! Also make sure you read any contribution guidelines for the project if available.

You will also need version control-fu, whether it's Git, Mercurial or SVN or whatever the project is using. You need to be able to use it, at least the basics to make a patch.

Most importantly have fun and be nice! :)