
Ask HN: How to contribute to open source projects? - bookshelf
I've been writing code for almost a year now. A friend told me once that contributing to open source projects can really improve my coding skills.<p>My question is, how do I actually do that? How do I become a contributor for an open source project?
======
emilsedgh
Find a project you are passionate about, fix the code, send a patch. Its
'that' easy.

Many mature software projects have some bugs marked as 'Junior Jobs'. They are
issues which maintainers felt could be fixed by a newcomer.

OpenHatch[0] is a website which helps you find such projects/issues easily.

[0] <https://openhatch.org/>

~~~
BellsOnSunday
In between steps 0 and 1, hang out on the mailing lists, IRC channels or
wherever the devs talk to each other. You can get a feeling for the culture of
the community, who the most active people are, the best people to ask newbie
questions without getting flamed, and so on.

~~~
naturalethic
Yup, freenode is a great place to get on the inside of any project.

------
westoque
First you have to find a project you would like to work on. After that it
usually goes like:

\- Adding New Features

Is it a new feature I want to add to the project? If yes, find out if someone
is already doing this feature, and then you have the option to work with them,
otherwise, start coding and submit a pull request (or something similar).

\- Fixing Bugs

Is it a bug you found while working with the project? If it is, then this is a
good time to go inside the code and fix it and do the same pull request cycle.

\- Performance Fixes

If you're a curious guy like me, you can go ahead and look through the source
code and find places where you think performance can be improved, then start
refactoring, after you're done, make sure you publish benchmarks in comparison
to the old results.

Have fun coding! :-)

~~~
thewarrior
How do i know if I'm skilled enough ?

~~~
leviathan
As other said, just dive in. And if you're lucky to have your patch criticized
and ripped to pieces, you'll learn a lot more from that than you would have if
you just work alone. And next time, you'll know to think better about how your
code interacts with the rest of the project before submitting another patch.
This will give you a lot of insight on how to work nicely with others, without
stepping on each others' toes.

------
JosephRedfern
GitHub code search can be handy - search for "TODO". Indexing by time index
rather than relevance helps get legit results:
[https://github.com/search?q=todo%3A&type=Code&s=inde...](https://github.com/search?q=todo%3A&type=Code&s=indexed)

~~~
jakub_g
Another useful phrases are "FIXME" and sometimes also "xxx".

------
davidw
Find something that you use and improve it: "scratch an itch", so to speak.

Or release some of your own software - something that other people would find
useful.

------
JoeKM
I think discovering OSS projects for one's aptitude and interest is a field
ripe for disruption. A few sites have been mentioned, but I think even more
can be done. At the same time I wish GitHub was more newcomer friendly.

If you have a full-time job and family life, and side-projects of your own
that are not OSS, how do you find time for OSS?

You need to find OSS that you're motivated to develop for. You shouldn't pick
some random project that you have no interest in for the sake of boosting your
GitHub activity. You need to set up your project environment. You need to
debug/test your patches. You need to learn and conform to the coding standards
of the project you're dealing with. You need to communicate with the project
team and be available.

All these things together require a lot of time. Great if you're single and in
college or without a job.

OSS projects, and GitHub in particular, have an elitist stigma surrounding
them these days. I don't think it was like that ten years ago. All the Silicon
Valley hot-shots are contributing to the OSS projects all over the place. One
may think reading HN that everyone and their dog contributes to GitHub and is
active, but I don't think that's the case (at least outside of Silicon
Valley).

------
aidenn0
I'll tell you how I've gotten involved in every project I contribute to.

Step 1: Use the software

Step 2: Swear at the top of your lungs when you encounter a bug

Step 3: Download latest version from source control in hopes that it's fixed

Step 4: Discover it's not fixed, fix it and submit a patch.

~~~
cadalac
Step 5: Take a break, maybe look into anger management...

~~~
aidenn0
I think it's pretty ordinary to be angry when something you use regularly
breaks; is there anything particularly unhealthy about expressing your anger
by yelling at an inanimate object? If so then I may need to change some
habits.

~~~
cadalac
I personally get more angry with bad design annoyances that will probably
never change. Like the way YouTube videos stall and reload when you click back
in the video or not begin able to filter out certain news items on Google News
etc.

PS. I was kind of teasing. Don't take me to seriously ;-).

------
supar
I cannot believe that people can have that question. Or, well, I do believe
it, but then my second question usually is: did you ever use linux/bsd or any
OSS project in the past?

I don't want to be rude at all, but the suggestion of "contributing to an OSS
project" makes a lot of sense if you already had to work with/use OSS
software. Because, _if_ you had to use one of these projects, you would
probably already understand the most important _social_ aspect of it. Coding,
IMHO, is just secondary (and is not necessary _at all_ ).

Thus my suggestion would be: if you never dealt with an OSS project before,
try to find some OSS software which you genuinely like and try to use it (and
well) and follow its development. Once you did, you will _certainly_ know how
to contribute. There's nothing more to it.

If you are already familiar with OSS, but so far never found anything
"interesting", the best thing to do IMHO would be starting your own. Release
something that you did and that you would like others to use.

Most importantly, do all of that for _fun_. Don't do that because you _have_
to and because they said "it would be helpful". Helpful for what? Coding
style\quality varies wildly, as is the community around the project itself.

The biggest difference between a "professional" and OSS project is exactly
this: people work on OSS project for many reasons, but it's mostly for fun or
passion. Some projects strive for quality, some for functionality, and some
just solve an "itch" somebody had. Understanding the social aspect, _again_ ,
is the biggest differentiating factor.

There's no point in contributing to OSS unless:

1) you released something that you like to maintain 2) maintain something
somebody _else_ released 3) fix an itch you have 4) having fun coding (or any
other activity around said project)

~~~
tedyoung
I won't address the "I cannot believe" part...

>If you are already familiar with OSS, but so far never found anything
"interesting", the best thing to do IMHO would be starting your own

I couldn't disagree more. If you haven't found a project that is "interesting"
or simply useful, then you're not really programming (or perhaps aren't
looking in the right place?). There are SO many useful projects, or semi-
useful projects (and lots of not very useful ones) that there's got to be at
least one (if not dozens) that would be interesting.

Regardless, if one couldn't find an interesting one to contribute to (at least
a little bit), starting a new one would be a bad idea because, unless it's
really unique or compelling, won't get a lot of attention and you won't get
any good feedback on what you're doing (which is critical if you want to
learn).

I do agree that the _social_ aspects of contributing to and/or running an OSS
project is important. So even if you're not contributing code to a project, if
you're filing issues or making comments on other issues, that's a great way to
learn.

~~~
supar
If you are not familiar with Linux (for example, you're working on Windows or
mostly doing web-development), it could _entirely_ be. Mac OS is more
friendly, but I certainly saw many developers that didn't scratch the surface
and directly went with XCode/ObjC/iOS. In that sense, you can build a career
without ever considering OSS development/usage.

What's best for somebody that, as of now, is questioning _which_ project
should be looking at? If you don't know what you're looking for, any advice is
just as good as a google or github search (ie: useless).

If you start by having fun, even by publishing your random projects, you will
be dragged in by dependencies (that's ironic). I would rather recommend
choosing something fun to work _with_ than a random project to look _at_.

------
C1D
I created a Github account and found a really interesting project (Adobe
Brackets). At that time I was looking for an open source project and found
brackets, I enjoyed using it and when I realised I could contribute I started
building whats missing. I've contributed to Arabic Translation, Text
Highlighting and Code Recognition. So my advice to find something you like and
contribuite to that :)

------
mangoman
A lot of the advice on here is fantastic, but mostly relies on "being
passionate about a project", or "pick a project you use". To me, the hardest
part is actually finding the project you want to contribute to. I heard in
school that I should contribute to open source, but at the time, all the
programming I did was for class projects. When I heard the term "contribute to
open source", my head heard something along the lines of "patch the linux
kernel". I never really used all the cool libraries that exist for web or
mobile development, so I had no idea what I would contribute to if I were to
contribute to open source.

I'd say first pick a project by going and building something that relies on
some cool Github library. I don't think anyone but me clicks on the "Explore"
tab on Github, but check it out, find a repository that you think is awesome,
try using it in your own small project. Then I'd say go ahead and look at the
issues that the library is having, and start tackling them one by one.

------
grobmeier
You have different options - here are some reflections of mine when I became
V. P. Logging:

[http://www.grobmeier.de/hey-i-became-a-vice-
president-070720...](http://www.grobmeier.de/hey-i-became-a-vice-
president-07072012.html)

Here is another link, which helps you to understand how Apache works:
<http://www.apache.org/foundation/how-it-works.html>

Of course, you don't need to go to the ASF when doing Open Source. I found it
great because its all around community there and there are many nice people.

You could also simply start with getting the sources of the
tools/lib/framework you use every day, be it on ASF or not. For example, I got
the source code of Angular.js because I use it daily. Now when I need to
implement something which makes me confused, I am looking into the Angular.js
code to understand why it does confuse me. In many cases it's not easy and I
leave it up for "later" (aka never), because of the time. But if I am REALLY
interested I simply ask on the mailing list how things work. When you have got
that knowledge, you can investigate if there is a better way and propose a
patch/pull request.

Also simply looking at the issue tracker and finding issue which are matching
your skill level are a good start. You could also try to understand issues
which are above your skill level, just to understand better how things work.

After all, becoming a contributor is easy: asking and answering questions on
mailing lists IS already a contribution to the open source project. Finding
out on background, sending patches for typos in the docs, improving unit tests
or implementing new features is of course a bigger contribution.

If you are serious about getting into open source, then my advise is to flesh
out an hour a day and walk intensive through code you find interesting. If it
bores you, take something else. If not, understand things and simply get in
touch with the dev, hopefully with some great patches.

------
felixgilles
You can subscribe for projects that interest you on
<http://www.codetriage.com/>

You will receive each day a PR or an issue of each project. Then you can see
if you can resolve the bug and propose your solution.

------
thinkbohemian
Late to the party but I wrote a website to help you do exactly that
<http://www.codetriage.com>. Find a GitHub repo you like, then subscribe to
receive one issue in your inbox each day.

------
milliams
Jos Poortvliet wrote about this just the other day
[http://blog.jospoortvliet.com/2013/05/getting-involved-in-
fr...](http://blog.jospoortvliet.com/2013/05/getting-involved-in-free-
software.html)

------
jaur
Most projects have a special page with instructions for beginners. Generally,
all instructions are similar and contain several steps:

\- subscribe to the mailing list for developers;

\- preview of the coding standart;

\- familiar with the procedure for sending patches to review;

\- contribute :) ;

In my opinion the best way to contribute is to add that functionality, which
does not get to you personally. As an example, you can see the page of GNOME
for beginners <https://live.gnome.org/GnomeLove> .

------
jakub_g
If you don't want to start with big projects, and you're fine with JavaScript:

1\. Go on to <http://userscripts.org/> and find some non-trivial script

2\. Does it work with Firefox, Chrome, Opera? Sometimes a little fix can make
it more portable.

3\. Do you think it lacks any features, configuration options etc.? Go on and
implement it.

Most of the US are opensource-licensed and small enough to get started
quickly.

------
kiallmacinnes
I would pick a project you use, a framework/library/whatever and look through
the bug list.. then fix the bug!

Most projects will want to know you before accepting anything major, as they
are on the hook for maintenance once you disappear!

~~~
negrit
Even more simple. When you find a bug tell the dev(s).

It's sometimes frustrating to find out a bug that has been around for ever and
drove users crazy but no one ever signaled it.

Edit: The first project I ever contributed was phpBB. It was years ago. I
never coded before, so I was moderating the community and then I learned how
to code. Sometimes, It's not all about coding.

~~~
Cogito
I can second this.

I was involved in a relatively large server mod community, primarily as a dev,
but as time went on more and more time was spent moderating the community and
managing incoming work.

By getting involved, even without coding anything, you will learn a lot about
how the 'core' team operates and communicates. If you are able to support by
testing or triaging that can help even more. Once you get an idea of how
things work you will probably also find something that you can fix.

By all means, jump into the code as soon as possible, but don't discount the
other parts of an open source project.

p.s. Documentation is an area that _always_ benefits the entire project,
without requiring much more than a comprehension of the code.

------
eliben
The Python project has a special "mentorship program" designed to increase the
amount of core contributors to Python. See - <http://pythonmentors.com/>

------
ippisl
have a look at codemontage.com or openhatch.org.

