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

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

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

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.