Slashdot Mirror
Good Ways To Join an Open Source Project?
Tathagata asks: "I'm a student, on my final year in a college in India, and I have been using GNU/Linux for quite sometime now. Though I'm from a Computer Science background, getting into a project that involves serious programming was not possible, as people (read teachers) run away if you utter the word 'Linux'. They are generally not bothered about mentoring someone on an exciting project, and they would suggest you to get settled with Visual Basic, .NET, — and would prefer a 24 hour solution when it comes to programming. So, my programming endeavors have remained limited to writing few lines of C/C++, or Java. For last few days, I've been googling, and trying to read how to join an existing Open Source project." What suggestions would you pass along to someone who is willing to join his first Open Source effort?
Most of the things I've read suggest that a good place to start is by submitting patches, fixing bugs, becoming package maintainer — but most are overloaded with jargon like upstream/downstream, nightly builds, and so forth. Additionally, how does joining the mailing list, or the IRC channel help when you don't even understand the slang, not to mention the intricacies of the technical discussion? It 's quite an overwhelming world to step in. Could you suggest a road map, links to essential tools or a few projects, for people like me, who would want to improve their skills by contributing FOSS?"
And do it! For instance, improve a feature of a game that you like. Or implement a missing feature that you've been hankering after. I think this is a great way to get started, because it gives you the satisfaction of reward.
For example, I like to use the free software Theora video codec to rip DVDs under Linux. It used to support SIMD-acceleration, making it encode movies about twice as fast... but only on 32-bit x86. Well, I had just gotten a new AMD64 box, and wanted it to rip movies faster. So I checked out the Theora code, refreshed my knowledge of assembly language, and within a couple days I had a working MMX/SSE-accelerated encoder. It was a very satisfying feeling!! And that code went into the mainline Theora release a couple months later (1.0alpha6).
My bicyles
Fixing bugs is the best way to become part of an open source project.
Unless you fix a bug that nobody cares about or doesn't understand what the bug really is. For instance, for years ptrace() in Linux didn't behave like any other ptrace() in other commercial Unices. My colleague spent long hours analyzing the bug, creating a fix, and exhaustively testing the fix to ensure it didn't open up security holes (admittedly ptrace() is a touchy part of the kernel that is prone to security issues). Nonetheless, when he sent the patch to the Kernel mailing list, it was completely ignored. No discussion...not even to say "we are too afraid to accept a patch for ptrace() from someone we do not know". Another example involved an effort to get an interface into the kernel for virtualizing and accessing hardware performance counters (this is in the days before oprofile and something other Unices have long had). A dude submitted a very very nice kernel patch and user library for allowing virtualized access to hardware performance counters. The Linux kernel mailing list completely ignored it. No discussion whatsoever.
Some projects - the one that comes first to mind is the Glasgow Haskell Compiler (ghc) - have fields in their bug trackers that rate the anticipated difficulty to fix a particular bug. That's a great help in identifying what's doable right away and what's not.