Ask HN: How to begin contributing to an open source project? | Hacker News Reader

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

56 pointskevinburke37 comments

I'm a fourth year college student with a few years of programming classes, but not much outside-class experience. Many people have said that contributing to open-source projects is a good way to show off your ability level and to learn more about how to code. I'm not sure how to begin - in other words I don't know what I don't know about open source projects.

Which open source project should I contribute to? How do I know what part of the project to work on? How do I get the code and how do I submit changes? How do I ask for guidance/get feedback, besides asking HN? Which IDE should I use?

Thanks for the advice, Kevin

View on HN

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.

Of course, I'm also interested in hearing from would-be contributors: anything else that could smooth along the process?

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.

This is good advice. I'm a Debian guy, but I'm impressed by the organisation of the Fedora Project. I went and read the project wiki just now and it's obvious people starting out could learn a lot there.

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.

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.

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).

This is very important. If you're a systems/C hacker then my recommendations will be a lot different than RoR or Python.

I have minor patches in a lot of different projects so I can give you a feel for which ones are beginner friendly (good coding style, maybe some documentation, friendly people) and which ones may be a bit more of a chore.

Python, Java, and Web languages - HTML, CSS, Javascript

The Tahoe-LAFS maintainers are super nice and helpful, and the project is very sexy. I mean, a distributed networked secure least authority file system, how much cooler can you get?

If you got on the Tahoe news group or IRC and said "I would like to contribute to the project" (after reading up about what it does), someone would point you in the right direction. I imagine that is true of most mid-sized open source projects.

Mercurial and Django both have some decent documentation. You may email a maintainer and ask for a simple bug or feature to get started on.

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!

How do you get started with IRC on a Mac?

Textual is a very good IRC client for the Mac.

Colloquy's an open source IRC client for Mac/iPhone/iPad!

(Disclaimer: I happen to contribute to Colloquy. In this case, it just means that I'd be delighted to look over any patches that anyone has. :)

I've always used Colloquy, it's an almost perfect client ;)

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.

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.

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!

I would actually recommend against starting by launching your project.

Havoc Pennington (GNOME guy) wrote "Working on Free Software" in 1999 to explain why. In my opinion every word there is still valid today, with possible exception of CVS.

http://ometer.com/hacking.html

And you see, it was called "free software" back then, not "open source project". Sigh.

Except when you're a buck novice it can be very intimidating and difficult to make a contribution among people who know WAY more than you. It's unfortunately very common for expert programmers to treat novices with disdain, and this can be extremely discouraging.

I think there's a lot to be said for practicing your skills on your own so that you have a reasonable level of practice before trying to contribute to other projects.

"OpenHatch: thousands of bite-sized bugs"

http://openhatch.org/

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.

yeah seriously git clone X fix something obvious git push

repeat

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...

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).

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.

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! :)

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 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 :)

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 :)

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.

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

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

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

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.

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. ^_^

I'd agree with this. Pick something you already use and fix or extend it in ways which make a meaningful difference to you, but be aware of and respect the design goals of the original authors.

In practical terms, you can just start hacking on the code yourself which will normally be available from a version control system somewhere, but when you've made changes you'll need to submit patches for consideration to the project maintainers at first. If you're unsure what format to use, just email to ask. For projects hosted on github you can just fork the project there which will make it technically easier to get patches back into the main branch. As you build up trust with others involved in the project you'll be able to get commit access to the project repository and make changes yourself.

As for IDEs etc, each project will have conventions and project metadata (makefiles, project indices etc.) suitable for a specific setup, so figure this out when you've picked a project and work with what's already in place as much as possible.

[edit] One other thing: it will be really hard to get started - getting up to speed with how a new piece of software works is difficult at the best of times and most projects aren't designed to make this easy. Persevere, as once you've got to grips with layout and conventions and got to know the other contributors things will become much easier.

Reply on news.ycombinator.com