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

[SQLGuru]

Mod parent to +5 (or +11, depending on how high your dial goes).

The only thing left out was that joining the mailing list and discussion boards will help you learn the lingo fastest. The only way to learn how to talk like a 133t hax0r is to lurk among them for a while. Every group is going to have their own slang. There is no "master list". Your background in CS will help you piece things together (well, related to the CS stuff). A classic example? In X Windows, knowing that the server is your screen and the client is the processes (apps) isn't easy to figure out unless you hang around them long enough.

But being a coder, like the parent post says, picking an item off of the TODO list and doing it will give you a good start. Pick an "easy" one. Read the code. Re-read the code. Make an attempt. Re-read the code. Redesign your solution to fit closer to how everything else works. Talk on the boards with people about how you have a mostly working solution. Then, you'll get a feel for their slang as they respond to something that you are pretty familar with.

Layne

Re:Read the TODO list

[bfields]

That can be trickier than it'd seem at first. Sometimes stuff on the TODO list is straightforward. But sometimes the reason something's stuck on the TODO list is that people aren't really sure yet what exactly needs to be done. Without experience it may be difficult to sort out the doable stuff from the stuff that needs someone with a real breadth of knowledge about the project architecture, user requirements, etc. But, sure, ask around for advice about given projects, see what people tell you.

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.

Re:Read the TODO list

[bfields]

In that case its best to email the project owner or the dev list announcing your intentions.

Yep, definitely.

If the people who run it are cool they'll take a little time to sketch out what needs to be done. If not, they're probably jerks and you might do well to find a better project to donate your time to.

It's not necessarily that simple. I've got plenty of projects that need doing where it's exactly producing that sketch that would be the hardest part. It might be a solid week of work for me to to get the project broken down to the point where it'd be reasonable for somebody unfamiliar with the project to get a good start on it. And even then it might come down to "try doing x, y, and z, and then get back to me with what you've done so far, and *then* we'll be able to decide whether this is actually the right approach or whether we need to scrap it all and start over differently."

And it's painful for somebody new to have to do a ton of work like that maybe just to prove that we're barking up the wrong tree. At least when they're starting out, I'd rather have people work on something that'll be more immediately rewarding for them.... But, anyway, the developer should be able to help you find the right project. Just keep in mind that sometimes finding the right project isn't always easy, and they don't yet know whether you're someone they can count on to follow through, so there's probably only so much that you're going to get from them at first.

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.

Easy

[SatanicPuppy]

Two words: Source. Forge. As in Sourceforge.net, the birthplace of countless OSS projects.

End of story. Go there, find something that's interesting, and if it's no longer in development, take it over or fork it, and if it's in development, see if you can join the team (if they need help, there is usually a "help wanted" link on the main project page). Most groups need help, and if you're competent, they'll be glad to have you.

If you're moving into a big team, be polite. You're a young programmer, and lots of young programmers have a lot of hubris. If you can't work with the people there (and this happens a lot; I once took a Java project, and simply updated it as it stood to get rid of depricated functions, almost no other changes, and I got flamed like you can't even imagine by the lone devloper who hadn't even released an update for 2 years) move on and do something else. There are so many projects, there is bound to be something awesome out there that you want to be a part of.

Re:try sourceforge...

[froggero1]

specifically, this link. You may need an account to view it, I don't know.

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

[dup_account]

Ok, don't go for the gold right out of the box. Find a smaller/lesser know OSS project to work on. Ideally, find something you are interested in or are already using. Maybe you have something about an OSS project that bugs you... Try to go in and make it work like you want.

Also, be patient. Unlike the parent, talk to the maintainer before making dangerous changes.

Final note, Linux kernel list is notorious for ignoring patches... That's why it's good to read the mailing lists etc before trying to submit. Get a feel for the 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:or fix the bugs :)

[Anonymous Coward]

Ok, don't go for the gold right out of the box. Find a smaller/lesser know OSS project to work on.

Some projects are actively trying to get newbies involved. I've heard of GnomeLove (though I don't actually know much about it), and Subversion has a list of bite-sized tasks.

Jargon?

[misleb]

"but most are overloaded with jargon like upstream/downstream, nightly builds, and so forth"

Um, this is pretty basic language used on real-world projects. You need to learn the "jargon" as well as actual programming. That's just the way it is. If this scares you, you may want to consider another line of work.

-matthew

Re:Jargon?

[drinkypoo]

Um, this is pretty basic language used on real-world projects. You need to learn the "jargon" as well as actual programming. That's just the way it is. If this scares you, you may want to consider another line of work.

Yeah, this kind of thinking just kills me. I was having a similar conversation with my girlfriend a week or two ago about all the jargon in tech. Then she went off about some gardening thing and I couldn't understand at least one word in every damned sentence. There's always a body of specialized knowledge, that's why they call them skills. You're skilled, or you're unskilled, in any particular area. Nobody knows everything, if they did they would be god and frankly I don't particularly believe in the guy :)

But the thing is that people often think that the jargon is for no good reason, like people are trying to obfuscate their terminology to leave others in more awe. But since computing has so many concepts for which there are no good analogues or metaphors, there will necessarily be a ton of jargon. Each of those words means something, and usually it breaks down to an acronym or initialization which actually means something. Most long-lived trades (like, say, gardening) have all kinds of jargon based on various words that no one uses any more, and so there's little to connect them to! So there's a tradeoff.

Anyway, point being, machinists know those curly metal thingies that come off the "stock" they're "turning" is called a "chip", and software developers had bloody well better know what a "nightly build" is. Especially since it's not exactly a fucking secret, the answer is in the name. (I realize that you might have trouble with that one if English is not your first language, but from the comment it's clear that they should know what both of these words mean.)

Skool...

[Nezer]

Perhaps, when you are finished with your bachelors at this school, you should consider a school with better professors for your masters.

This is such a shame when so-called "professors" actually hinder your learning experience. I'm sure they think they have your best interests in mind. Right NOW .net, VB, etc might be where all the paying jobs are but this isn't going to last. Eventually something else will come along (even from Microsoft) that will make these skills obsolete. Professors are, IMHO, under obligation to ensure you get an education, not training.

Step #1, become familiar with the software

[pjwalen]

The advice you have gotten thus far is good. To get your foot in the door, I would suggest you find a project you find personally appealing in the open-source community. Become familiar with its use and operation. The next step would be to become familiar with CVS or Subversion (SVN). Seeing as you are coming from a more Microsoft background you will be familiar with source safe (most likely), CVS and subversion are simply open source, source control system. You will want to become familiar with their basic use.

Once you have accomplished those basic tasks, download the source of your new found project to your PC with your source control client (each project will have these procedures documented on their web pages, somewhere). Then become familiar with their architecture. Read through the routines, and their data structures. Once you have a basic understanding of the projects source, you will want to join mailing lists, look at their bug tracking software, and forums. Track down bugs in the projects software and solve them. Using your knowledge of CVS and/or SVN (and hopefully the diff command), you will be able to produce usable patches, or revisions to code that you can submit to primary developers.

Once you become a valued member of the bug tracking and eliminating community, you may want to begin tackling the projects TODO list for new releases. Adding new features to the product. The rest of the terms you bring up (and many that you didn't) will become more familiar to you as you become more involved in a projects build process.

Skills first

[Anonymous Coward]

If you want to advance your programming, joining an open source project is not a very good first step. You see, projects out there mostly are written to solve real-world problems. Real-world problems are not very interesting. The interesting ones are the hardest to contribute anyway, due to steep learning curves and huge code bases.

I'd advise you to work on programming problems first. Things like combinatorial search, dynamic programming etc.. Once you master common algorithms, you can be an effective contributor. Open source project admins are probably not interested in teaching a newbie about programming. They just want someone to work with and get some job done.

Once you're confident in your programming, you can learn any API or language easily. Trying to understand existing code is much harder than writing your own, especially if you lack experience. Contrary to popular advice I'd say, don't bother yourself wrestling with already poorly written code. Make yourself capable of writing the thing yourself thru problem solving and then contribute to a project if you feel like it.

Good luck

Find an itch

[linuxwrangler]

First, find "an itch to scratch". What excites you? Databases? Web development? Audio processing? Image editing? The first step is to find a project that you would be interested in using.

Second, read, read, read. Lurk in the mailing lists, IRC, etc. Get a feel for how the project is maintained and the tone of the developers and users. Don't be one of those who shows up new on the scene and suggests ideas that have been repeatedly rejected for the project or patches that break things or show no understanding of the project design and goals. Try to determine if you would "fit in" with the group.

Third, use the program and dig through the code till you have a good understanding of it. You will learn a lot...including whether or not you want to find a different project. :)

Fourth, if you have found that exciting project and the code or people haven't scared you away, find out where you can contribute. It's not just about coding. Large projects have people contributing to code, documentation, public-relations, mail-list management, answering questions on the mailing lists, and so on. If you are really focused on programming, peruse the bug list and find some solutions. You will build your reputation by repeated posting of quality patches.

Fifth, be humble. There's nothing wrong with "I'm new to this project and have been digging through and learning the code. I think this patch might fix bug #1138? Is there something I have overlooked?". It's far better than "Hey guys - here's how to fix that dumb bug..." You could be right, but it's more likely you will find 15 developers jumping into the discussion to tell you what you forgot to take into account with your stupid suggestion. That will set your reputation way back.

On the other hand, if you are just looking for something to jump into so it can go on your resume, forget it. You won't have the interest and passion to stick around long enough to be useful.

Sadly...

[jd]

I cannot recommend a good place for your lecturers and professors to undergo brain transplants. First off, any lecturer that recommends a specific language is violating the first rule of computing - EVERYTHING is transitory, nothing lasts forever. Their lecturers probably swore by Cobol or PL/I. Only a total idiot tells students that they should adhere to a solution rather than a methodology. Solutions come and go, but the same methodology will apply to them all and make learning the specifics a piece of cake.

(Hell, anyone who lived through the .com fiasco saw what happened to Java programmers immediately before and immediately after. Java's a good solution to a number of problems, but the market became glutted when the bubble burst, making it a totally unmarketable language in the immediate aftermath.)

People have noted Sourceforge, and that is definitely a good place to go. If you're only "allowed" to add a few lines, then I'd also recommend investigating Unmaintained Free Software for projects that probably need relatively little work but which aren't receiving any attention at all. One of the benefits of going for an orphaned project is that you have much more freedom on where to take things. You are also, by definition, not subject to jargon on chat groups or mailing lists as there aren't any. It also gives you a chance to test the full range of computer science skills - analyzing, designing, implementing and testing - in a way a current project generally doesn't allow for. You'd be exercising one whole revolution of the software lifecycle.

The benefits of an existing project cannot be overstated, though. If there are existing coders, there are more pairs of eyes looking at what you're doing. There are people to ask for help/advice. You're less likely to be overwhelmed. There's also a touch more "street credibility" attached to being associated with a project that's better known, which won't hurt your employment prospects in the least.

If this is a final-year project, they'd better damn well want something non-trivial or I will most certainly have stern words with them. Not that my words are worth anything, I just write a lot of them. A half-way point between the full lifecycle (which makes for a wonderful final-year project report, which is ultimately all that matters) and working on an existing project is to pick something that accepts plug-ins or modules of some kind. There may be abandoned projects of that kind you can borrow from, but it's also stuff that's just simple enough that writing from scratch isn't going to kill you.

Hope that gives you some ideas.

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

Re:Find something that you'll ENJOY

[Mathness]

I like to use the free software Theora video codec to rip DVDs MoxFulder, dude! Run man, the mafiaa have you targeted now, and I think one of them is a chain smoker.

- The Lone Punmen