

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

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.<p>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?<p>Thanks for the advice, Kevin
======
technomancy
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.

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

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

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

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

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

~~~
Locke1689
_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.

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

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

------
jankassens
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!

~~~
kevinburke
How do you get started with IRC on a Mac?

~~~
Zev
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. :)

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

------
albertzeyer
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...](http://www.openlierox.net/wiki/index.php/Why_game_development_is_a_great_learning_playground)
)

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...](http://www.openlierox.net/wiki/index.php/Contribute_to_the_source_code)

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.

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

------
compay
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!

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

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

------
frossie
"OpenHatch: thousands of bite-sized bugs"

<http://openhatch.org/>

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

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

~~~
keefe
yeah seriously git clone X fix something obvious git push

repeat

------
SteveC
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...](http://railscasts.com/episodes/113-contributing-to-rails-with-git)

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

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

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

------
beza1e1
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!

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

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

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

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

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

[http://thinkrelevance.com/blog/2008/05/23/refactotum-
overvie...](http://thinkrelevance.com/blog/2008/05/23/refactotum-
overview.html)

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

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

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

