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?"

Comments

Read the TODO list

[Watson Ladd]

and do one of the items, test the patch, and submit it. Then repeat.

Re:Read the TODO list

[Anonymous Coward]

I believe you and most people are missing what this guy is asking for. Patches, and talking to the developers is the general advice given, but there is far more to it than just that. In my experience which is very limited, I've noticed most projects all have their own way of doing things, naming conventions, rules, ways to get around problems..Almost to the point that before you can submit patches, you need to know how the whole project fits together, and have an understanding of a lot of the underlying work.

This person I reckon is asking for links, advice on places to go to learn some of the common conventions used in open source, as they're usually quite different to closed source systems.

For example you can assume a nightly build is what it says in the name, but there is more to it.. Such as what does get included, what doesn't.. If you've been working on something all day but it still doesn't work, do you commit it for the nightly build knowing that it'll break but may be useful for others to see what's going on? You probably wouldn't commit it if you knew it wouldn't work..Which really puts it down to only making small changes which you've checked work(to the best of your ability) then commit. There is definitely an area of uncertainty surrounding these things.

There's naturally the case of feeling intimidated talking to people who have been working on the project for ages, and a fear surrounding asking what they could consider stupid questions. Nobody likes being laughed at with intent to hurt.

I think he's really looking for an 'entry point'.. As well as material to read (and where to read it) so he can feel more confident talking the lingo, and being able to ask more sensible questions, without as much fear from asking stupid ones.

you've already gotten good advise...

[capsteve]

i think the advise you've received so far is spot on. first pick a couple projects you're interested and have a vested interest (i.e. you actually use the software on a daily/semi-regular basis) and join the forums. i wouldn't worry about the slang right off the bat, most of that will come with time and participation. join the discussions with suggestions and help if you can provide it, or ask questions regarding configurations, installation, etc if you're a new comer.

regarding posting in discussion groups:
if your asking questions, be thorough in you description of problems you're experiencing, be ready to provide logs and details regarding your system and installation, and be courteous. nothing worse than a call for help on a forum: "i'n a new user, don't know what i'm doing, but i need help. and if you can't help me this software sucks!" i've seen many calls for help that go unanswered because of the issue listed above.

if you are offering help and/or suggestions, be thorough in your answers, don't be insulting("RTFM newb!"), and give realistic options. i've seen responses that are overly terse in tone that makes the response seem like it's an annoyance or statements that have an air of arrogance that have turned users away from FOSS projects.

the point of joining the discussion groups is to see if there is a fit for your skills. is the delevopment team in need of your abilities, or do they have too many contributors? is the process of contribution thru an individual or comittee? is the project in active development, or has it been obsfucated by another project? only way to answer some of these questions is to join and read the discussions. then you can make a better decision as to which project to join.

figure out what you want to join first before deciding what you want to do with the project. if your commited to the project, theres a way to find your niche.

or fix the bugs :)

[sofar]

Andrew Morton has said it before, and it holds best: "What do I do if I want to be a kernel hacker?". His answer: "fix bugs". This applies for all open source projects. If developers have established that their software has shortcomings, they are very likely to accept solutions. Fixing bugs is the best way to become part of an open source project.

Re:or fix the bugs :)

[Anonymous Coward]

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.

Re:or fix the bugs :)

[ninevoltz]

I can confirm that your work will be for nothing, if you are not well known. Even patches written by project members will be ignored if the rest of the members don't feel like addressing the bug. Andrew Morton wrote a patch for a kernel bug that I submitted relating to National Instruments Data Acquisition drivers not working with the Fedora kernels. The symbols in the NI drivers are too long for modpost to handle, so he created an expanding buffer patch. Then it went nowhere. This kind of pisses me off. I love Linux, but I fucking hate elitist nerds. This is why more people will not accept Linux when valid hardware drivers can't be properly supported because of personality problems.

Re:or fix the bugs :)

[billcopc]

You hit the nail on the head: elitism is what kills our efficiency. We suffer from inflated head'ism, where any ideas that come from outside the clique are seen as threats. Just look at all the major open source projects, not just the kernel but Apache, Samba, Gnome and KDE... they all suffer from this bizarre "us vs them" attitude.

I can certainly understand that there are a lot more dumb whiney people than clever ones, but an open-source project manager, like any other manager, needs to learn to maximize the resources available. If you have a half-brained monkey banging on your door, give up some boring job that no one else wants, that will keep them busy AND get your work done. Likewise if someone comes along with a bright idea, don't get jealous and vindictive, instead try to find ways to incorporate these new ideas and skills in your team.

OSS projects should be run like any other project, with one extremely important advantage: there are no salaries to be paid, so you can get the right-sized team for the project. Too few people and things won't get done, people will tire and give up. Too many people and you spend all your time herding cattle, or hearing your lead developer bitch about how the new kid shat all over CVS.

To the original poster: if you're a fresh coder and you want in on a project, you're going at it the wrong way. Don't shop around like it's a day job, rather find something you're good at and do it, then show off your work. If you're worth the bandwidth, someone will notice. There is so much fluff in the marketplace, kids who just want their name in Google so they can butter up their resume, that people begging for work don't even get the time of day, except from other newbies who don't know any better.

Find something that you'll ENJOY

[MoxFulder]

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).