I know how exciting the FOSS world seems, the first time we discover it. You
are dying to contribute. You want to contribute, Right Now! But you've no
clue, what, where and how. Relax. Give yourself time. You've a lifetime
ahead of you. Explore. Explore, even more. Play with things, Try out
stuff, Break stuff, Spill things all over the place. Have fun!
Given that you are reading this, I presume that, you do have access to the
Internet. But, if you don't, it could turn an impediment to your goal. Easy
access to a decent internet connection is a prerequisite.
Learn a programming language, well. By learning, I don't mean
getting familiar with the syntax or passing a bunch of exams. Get familiar
with the paradigms of the language. Learn to think in that language. Write
code that does something real, instead of doing toy examples. Also,
it helps know bits and pieces about the history and evolution of the
language. This will give you a sense of why some features are present (or
absent) and will help you program better, in that language.
Some projects will definitely catch your eye, while you are exploring. Start
using the ones that you need. Follow them!
Start with using the bleeding edge software. Bleeding edge refers
to the latest sources of the project, where the active development is going
on. Given the continuous nature of software development, using the latest
- prevents you from wasting time on fixing bugs that have already been fixed
- lets you look at the latest changes being made and contribute effectively
Also, start following the project's mailing lists – both the dev and the
user lists, if they are separate. The user-list discussions will help you
discover functionality and possibly give you some chance to peek at the
source code, too. Don't be surprised or worried if you don't follow most of
what goes on, in the dev-list. Be patient and keep at it. You will learn a
lot about the what, why and how of the project. Also don't be afraid to
look foolish there! There wouldn't be one developer who doesn't have some
embarrassing logs of stuff she said in public, in her initial days.
Slowly you'll start to learn the dynamics of the community – how things
function, the DOs and DON'Ts, etc . Also, there's a good chance
that the project has an active IRC channel. If it does, hanging out there
will give you more insights. Contributing to the documentation, is often a
useful step before contributing code. Cleaning up the documentation or
writing documentation, often requires you to read the code and helps you
understand it better.
Next, start acting on Bug reports (or tiny feature requests). Start with
trying to reproduce the bugs and sending confirmations. Gradually, start
looking at the source and trying to figure out where the problem is. Be
patient, with this . Once you get comfortable with the code
and the coding style, start sending code snippets and comments, explaining
what you think might be the problem. One fine day, you will be able to send
a full working patch! But, before that don't hesitate to send partial fixes.
You can learn a lot from the comments of the devs and looking at how they
finally fixed it. Also, IRC could be a good place to ask for help, if you
are stuck and are looking for some quick help, so you can move further.
In all of this, it helps if you have one (or a bunch of) favorite area(s)
or module(s) of the project, specially in a big project. You should pounce
upon any issues in your favorite area.
Participate in sprints. It's not uncommon for projects to have regular
sprints. Make it there ! Also, a couple of developers may decide
to meet up on a weekend and hack. If it's happening in your neighborhood,
ask if you can join. Don't be surprised, if they shout out a big YES! You
will definitely learn a lot, when there is help so close-by.
A shortcut would be to start your own project! It is easier (in some ways)
to release your own code under a FOSS license, than contribute to some of the
existing projects. You don't have to have your code approved by the project
leads, you don't need to mould your code to fit the standards of the project,
you don't have to read and understand all the (relevant parts of the)
existing code, etc. But all of this, definitely teaches you a lot.
As a beginner, I think it is important to solve your own problems, problems
that you care about (at least at that point in time). Most of the projects,
started off with their developers wanting to solve their own problems. Only,
incidentally, they solved some of the World's problems, too!
Start small, though. Don't start off with a project that aims to replace
Chrome or Firefox as the best browser, or an editor to replace Vim or Emacs.
Writing extensions to your favorite software could be a good place to start,
for instance an Emacs minor/major mode, a Chrome
extension, etc. Stand on the shoulders of giants!
Also, take this as an opportunity to gain some of the skills that would be
useful, when you want to start contributing to others projects.
- Learn to use Version Control (Git + GitHub is awesome!)
- Learn to use build and setup tools.
- Learn about packaging and distributing your software.
- Learn how to license your code.
- Learn to Collaborate!
All of this, I hope, would suffice to get your first contribution in. But,
there are a few things that will help you in the long run.
Good English. Specially written communication, since that is how you would be
communicating, more often than not. Fair or not, hackers are known to be
very particular about good communication. I'm not exaggerating when I say,
what you say may be ignored even if it makes perfect sense, if you said it in
Using a *nix would put you in some great company. At the very least, you
save time when looking for solutions to known problems. Using a good editor
and learning to type quickly can be big productivity gains. You only get 24
hours a day!
An understanding of licensing issues, can come in handy, many a times.
For more, read How to Become a Hacker by Eric Raymond.