I was recently interviewing for an internship for this summer. This was the first time I had interviewed so extensively, and I was a little suprised at their focus. Most of them asked me about the work I did with Pootypedia instead of my college education. Every interviewer quizzed me about some random code-patching that I did last November. Nobody bothered with the courses I had taken. The college education on which I spend so much time was less valuable than little code hacking that I did for fun.
I think working with open source software makes a few strong statements about you. Firstly, it says that you are interested in computing, you do it in your free time, with no cash incentive, which can only mean that you love it. In management talk, this would be "strongly motivated", "driven", "proactive", and a few other words with lots of alphabets in them.
Secondly, it means that you are capable of working with existing software, and this I think is more important. In most projects at work, you do not have the luxury of starting from scratch. Most work involves maintaining someone's code, or adding features to an existing codebase. A lot of work is looking through someone's gnarly code and finding a bug, and then fixing it. Under time pressure, with little resources, and the developer either missing, or very reluctant to admit that it was his sloppiness that is causing you misery. Compare this situation to school, where every project requires you to start from scratch, implement something, and demonstrate that it works. These two require completely different skill sets. I don't know of any classes that teach you how to maintain code, or to understand someone else's code. Fixing a bug in Firefox says that you have the capability to enter unknown territory, find that bug, and smash it. It might not go on your resume, but it is documented, you are acknowledged as the fixer, and others benefit from this action of yours. If you fix a big bug in Firefox, Apache, or other high-profile Open Source projects, I would recommend putting it on your resume. Chances are, that will be the first thing a recruiter will ask you about.
Starting an Open Source project that fills a need is also a great way of getting recognition. If your project happens to be used by millions all over the world, people will know you, you will be invited to talks, and companies will be beating your door down to hire you. Starting and maintaining a project is clearly a lot more work, and finding an unmet need might be half the battle. Most of the easy problems are taken, and the tough ones remain undone for a reason: they are tough. If you can start a project, and take it to 1 million users, though, recognition is guaranteed.
The open source world, and software in general isn't about starting new projects, necessarily. It is about good utilities, and good contribution. A patch that brings a new capability to an existing project is much better than writing a new program altogether. Instead of writing a program to read WordPerfect documents, add Wordperfect support in Open Office or KOffice. This way you get all the existing users of these programs for free: which means more bug reports, bug fixes, and inclusion into the big distributions.
Now comes the strange part: you probably already have all the tools required to do this. If you are viewing this on a computer on which you can install any program, then you have everything required already. You can get a compiler (gcc), a debugger (gdb), some editor (emacs). But that is the small stuff. What you really need is the source code. This is where Open Source shines: the source code is there for you to look at, download, copy, deface or improve as you see fit. Without asking for permission. Without revealing that you're a 14 year old in a small Indian city, and your mom disapproves of your late night hacking. And if you contribute a bug fix, nobody cares that you are a 14 year old. Open Source is a brutal meritocracy. You, as a 14 year old kid can beat a 40 year old veteran software developer.
What is even more surprising is that competing projects don't mind cross pollination. You can do a bugfix for GNOME, and then fix something in KDE. Use emacs one day and fix a bug there, then give the vi developers some of your love by patching their code. Unlike the software industry, nobody in the Open Source world holds you from working with competing projects, there are no non-disclosure clauses, and no one-year waiting period, twiddling your thumbs and forgetting everything you learnt in your previous job. You could use some of GNOME's code to fix KDE's bugs, just as far as you acknowledge the original author.
In a year of bug fixing, you could get your name in twelve projects. All from your room, while your parents are blissfully unaware of your moonlighting hero-work. One high level techie in a very large and well-known software company told me that he would do this if he was my age right now.
Here's the Indian context. You could be a college student, unhappy at the intense competition for the IITs, RECs, or local Engineering colleges. (They aren't that good, believe me.) You could be a BA student, sad that the Engineering world has passed you by. You could be an engineering student, keen to see the real world, cut your teeth into world-class problems. You could be a school kid, eager to know what real software development is like. Or you could be super smart and itching to prove it. This is your opportunity. An invitation to the Open Source University: with no fees, great books and reference material, and some brilliant fellow students. You decide when you are smart enough to enter, and smart enough to leave. And if you do well, the world acknowledges you, and you get entries into your resume that can be independently verified by anyone in the world.