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?"
http://halo.willisburg.org/
Check out the project, and drop us a line if it interests you.... we can always use another hand or two on the project.
-Willis
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.
>Fixing bugs is the best way to become part of an open source project.
Writing and translating documentation, testing, and doing sales (yes, I'm serious) will endear you
to some project teams more than you probably imagine. My sister-in-law is doing sales and marketing
for a GNU-licensed open source project and is getting paid rather respectably, and traveling the world.
It's pretty cool, and it shocked the hell out of me that a person could make a living wage in *sales*
in the open source world, but I've seen it. If I had time, I could plug into that same project as a
developer and, apparently, could even be paid market wages if my contribution was sufficient.
But I don't want to stop working in science, low pay and university "perks" nonetheless.
-fb Everything not expressly forbidden is now mandatory.
But that's just it, your not "giving it away" in the w/FOSS software world. You're sharing your work. With commercial software there's an understanding that you don't really own your work. You're selling your time to a company. So of course F/OSS developers take things more personally. It *is* personal. And that is why it is so great.
Don't be "afraid" to ask. Just be careful to do some leg work on your own. It is very easy to get used to having your questions answered that you don't stop and do some basic research on eyour onw. It happens to me every once in a while. You start asking question and then you realize (or have someone politly or not so politely point it out) tht you could have just googled the answer or tried it. For example, you might ask a group "What if I typed this, woudl I get the right result?" Well, the simple thing to do would just be to try it and find out. I don't think the agression is really as common ans you make it sound. Sometime people (even smart people) ask dumb questions and waste people's time. And sometimes these people need to be told "Hey! RTFM!"
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
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.
http://www.freebsd.org/projects/ideas/