On Friday, March 22, 2013 08:27 PM, Sandeep Sukhani wrote:
Overwhelming to see such concern from team. I am a student, about to finish
my masters. I always wonder how to get started, even by going through "get
started" column of open source or linux communities' website.
That's something we hear very often.
Many people seem to be expecting a step-by-step guide for how to start
contributing, but... that's just not how FOSS works. :-/
What is very important to understand is that you are trying to join a
(mostly) volunteer-based community, to which you would contribute as a
As such, you are the one who will choose what you will contribute to,
what you will do.
And **that** is how you get started: by figuring out what you enjoy,
what you'd have fun doing.
I have keen interest in working on systems programming,
Then that is what you should contribute to. :)
One thing to note, though, there isn't much opportunity for contributing
**code** to Fedora. That's because Fedora is a distributor: we take
software made upstream, package it as RPMs, and try to integrate it all
into a coherent whole.
So if you want to contribute code, you should do so directly upstream.
Now, when you say « systems programming », that could actually cover
quite a lot of stuff.
It could be the kernel, low-level userspace like systemd, low-level
libraries like the glibc, important daemons like firewalld or httpd, etc...
But it really has to be a personal journey, where you identify the stuff
you want to be working on, and then you just get to doing it.
Here's how it usually goes.
1. Find a cool project to contribute to
This is actually the hardest part, and is where no one can really help you.
To give you some clues where to search, try to look at the software you
use. Any project that you enjoy using, that you think has a positive
impact on the world, or just that looks cool.
2. Get familiar with how the community works on the project
You need to find how they communicate (mailing-lists, forums, IRC,...),
where the source code is hosted (github, sourceforge,...), what is the
procedure for contributing code (sending a patch by email, attaching to
the bug report, sending a pull request,...), where is the documentation
for building and installing the code, etc...
3. Find a bug in that project
The best is a bug that you encountered yourself, because that provides
you additional motivation to get it fixed.
Otherwise, go find the bug tracker for that project, and read all the
reports one by one, until you find something that 1. you can reproduce
(this is very important) and 2. you feel would be a nice hack.
4. Get the code, straight from the VCS
Previous step told you whether the code was hosted in Git, SVN,
So just check it out (or clone it), and then build/install it, and try
to reproduce the bug again.
Turns out, some bugs could be present in the Fedora package, but already
be fixed in the latest development branch.
If you can still reproduce the bug, then go ahead and fix it.
That's the part where you have fun reading code to understand where the
problem is, bang your head a few times against the wall, and magically
get a bug fix out of it.
And because you spent time on step 3, you know how to contribute your
6. Wash, rinse, repeat
If you enjoyed fixing that bug (some code bases are horrendous that you
might want to run away and forget about that project), if you found it
was a pleasure to interact with the community (some are much more
welcoming than others), and if you feel like it, then go back to step 3.
If not, then go back to step 1, and find a new project which will
provide you with more fun.
7. Have fun
This is critical.
You will need a sustained motivation to keep hacking. Some people get it
through a salary, but as a volunteer contributing to Free Software, you
won't get that (at least, not right away ;) )
So you must get something out of it, or else you will burn out, get
depressed, and the community will lose a valuable contributor.
Find something that gives you joy. Find something where you have fun.
Find something where you feel like you're having a positive impact.
If the project is a pain to work with, thank them and walk away, towards
Most of the above works for non-code contribution by the way. Steps
might have to be slightly adapted, but the journey is always similar.
I dont have much experience,
This has never been a problem for anyone. If you're passionate, you'll
learn what you need to. :)
I understand this is probably not the answer you expected ("hi, project
$foo needs help, read this and that page and do that to get started"),
but we can't really do much more.
If we assign you to a project, you might not like it, and as a result
you'll either give up or provide crappy contributions.
Nobody can find the right project for you, except you.
Hope that helps.