Become a fan of Slashdot on Facebook


Forgot your password?

Good Ways To Join an Open Source Project? 282

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?"
This discussion has been archived. No new comments can be posted.

Good Ways To Join an Open Source Project?

Comments Filter:
  • Read the TODO list (Score:5, Informative)

    by Watson Ladd ( 955755 ) on Friday June 22, 2007 @02:49PM (#19611939)
    and do one of the items, test the patch, and submit it. Then repeat.
    • or fix the bugs :) (Score:5, Insightful)

      by sofar ( 317980 ) on Friday June 22, 2007 @02:56PM (#19612023) Homepage

      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.
      • by Anonymous Coward on Friday June 22, 2007 @03:57PM (#19612925)
        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.
        • by dup_account ( 469516 ) on Friday June 22, 2007 @04:13PM (#19613131)
          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.
        • by ninevoltz ( 910404 ) on Friday June 22, 2007 @05:24PM (#19614117)
          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.
          • by billcopc ( 196330 ) <> on Friday June 22, 2007 @08:22PM (#19615753) Homepage
            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: (Score:2, Interesting)

        by fishbowl ( 7759 )
        >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 se
    • by SQLGuru ( 980662 ) on Friday June 22, 2007 @03:06PM (#19612203) Journal
      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.

    • by bfields ( 66644 ) on Friday June 22, 2007 @03:08PM (#19612239) Homepage
      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: (Score:3, Informative)

        In that case its best to email the project owner or the dev list announcing your intentions. 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.
        • by bfields ( 66644 ) on Friday June 22, 2007 @04:27PM (#19613331) Homepage

          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.

      • Re: (Score:3, Insightful)

        by zCyl ( 14362 )

        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.

        For beginners to programming or just to a project, it may be wiser to start out fixing the more recent and less critical bugs. These are more likely to be straightforward, and are probably not done yet just because someone hasn't gotten around to it. After doing a few of these and becoming familiar with the code base, one can m

      • by Mr.Ned ( 79679 ) on Friday June 22, 2007 @08:02PM (#19615567)
        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.
    • by MoxFulder ( 159829 ) on Friday June 22, 2007 @03:29PM (#19612557) Homepage
      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).
    • by Anonymous Coward on Friday June 22, 2007 @03:58PM (#19612945)
      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: (Score:3, Informative)

        by Tathgata ( 1117237 )
        Thanks to all of you, for such valuable suggestions [half-way through reading].
        But YOU, really understood where I'm getting stuck!
        Now making the choice amongst so many inetresting projects is undoubtedly difficult, everything(well, almost) seems interesting. But my main query is how do you get the entire picture of the whole project and locate the needle hiding itself in the haystack just looking at the bug report.
        Sounds silly, but from a bug report to submiting patches - how do you do it?
        I'm eager to RTFin
    • hat's how I started. When compiling some open-source projects found bugs, fixed, sent the fix. Later started to help out stratagus (named freecraft at the time) and improved my skills a bit. Now I'm working on Stargus (starcraft support for stratagus on the weekends). It's very fun!
      • Looks interesting :) Just as an FYI, I read the front page of your project. Starcraft actually runs perfectly under Wine set to emulate Win2K actions in Ubuntu 7.04. I just double-clicked setup, and it installed and ran, everything as it's supposed to be. So, you can play Starcraft under Linux other than with your mod. But I'll definitely keep an eye on it.
    • Exactly; you don't join or leave an open source project. There are no membership rolls. You just write code and if other people like your code, they use it.
    • The first step is to join an open source community. Lurk for a while, use the software, see what works and what doesn't.

      Then start getting active in the community. Give support, feedback, and the like.

      In the mean time, if you can fix bugs, great. If not, just getting involved may help you get a feel whether this is the right community and project for you.

      Oh, and decide what you want to accomplish. Do you want to get your name out there? Earn income by coding? Just have fun? This will determine what s
  • there's plenty of positions for open source developers there...
  • by capsteve ( 4595 ) * on Friday June 22, 2007 @02:51PM (#19611973) Homepage Journal
    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.
    • Re: (Score:3, Informative)

      by drinkypoo ( 153816 )

      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 cannot agree with you enough. It is by far most sensible to start with a project you actually care about. Some of the first patches I ever submitted (not precisely the first but it's been a while) were for various Drupal modules. I made some mistakes, and some were not accepted, but most were and both I and the community got over the experience j

    • by bmsleight ( 710084 ) on Friday June 22, 2007 @05:22PM (#19614085) Homepage
      I could not agree more. I start asking question about a project I was using. Then I answered other questions in the forums, for other users, based upon the knowledge I picked up.

      Next I submitted a one line patch. [Heck at that point I could not even use diff]

      Then I wrote a manual. I worked out how to use diff, subscribed to the developer mailing lists. More patch, modules written by me.

      I am now one of the administrators of the project.

      From small acorns, big trees grow.

  • by iHasaFlavour ( 1118257 ) on Friday June 22, 2007 @02:52PM (#19611983) Homepage
    Sourceforge has a help wanted page for project owners to advertise for additonal project members, or go to google code and browse there to see if anything catches your eye.
  • Easy (Score:5, Informative)

    by SatanicPuppy ( 611928 ) * <> on Friday June 22, 2007 @02:53PM (#19612001) Journal
    Two words: Source. Forge. As in [], 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.
    • by marktoml ( 48712 ) *
      SourceForge also has a "Help Wanted" section where project folks post what skills they need.

      Good way to find something you are ready to tackle.

    • Re: (Score:2, Funny)

      by Anonymous Coward
      End of story.

      Interesting that over 90% of your post occured after you said "End of story."

    • Re: (Score:3, Insightful)

      "You're a young programmer, and lots of young programmers have a lot of hubris."

      I'm an old programmer and I can tell you that hubris is not something that only young programmers are guilty of. It's just that people are more likely to put up with it if you're experienced.
  • by Anonymous Coward []

    Check out the project, and drop us a line if it interests you.... we can always use another hand or two on the project.

    • While you may need more programmers, you desperately need a technical writer. Reading your project main page made my brain hurt. Its okay to end a sentence. One thing you may want to try is reading it aloud. If you need another breath before you finish the sentence, then the sentence is too probably too long.
  • Jargon? (Score:4, Insightful)

    by misleb ( 129952 ) on Friday June 22, 2007 @02:58PM (#19612069)
    "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.

    • Re:Jargon? (Score:5, Informative)

      by drinkypoo ( 153816 ) <> on Friday June 22, 2007 @03:04PM (#19612173) Homepage Journal

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

      • The liquid that comes out of a landfill is called leachate. Now that's a good word to know.
      • It's called "swarf!" []

        Some jargon is BS though. Investing jargon drives me nuts "taxflation", "bear", "bull", "forex", "fundies"...

        Ugh. Don't get me wrong, the financial sector jargon is fine. It's very necessary and describes precise concepts. It's just this wishy-washy investing stuff.

        • It's called "swarf!" []

          Uh, no. Swarf may be the name for a collection of chips, but a single piece of metal that has been cut off a piece of work (typ. on the lathe, but also the output from a milling operation) is called a chip (unless it's a whole block you cut off, I don't even know what that's called, because I'm not really a machinist.)

          Next time try wiktionary [] as well as wikipedia, it will tell you that a chip is "A small piece broken from a larger piece of solid mate

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

        Nah, the real problem is that people have forgotten what the analogies really mean. Bandwidth is a plumbing-related analogy (the wider the band of a pipe, the more you can fit through it). A heap or a stack are pretty much great descriptions in *plain english* of what is logically going on.

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

        WHo doesn't understand what it means to "build software?" Who doesn't understand what the word "nightly" means? Why is "nightly build" so hard to understand?

        I would talk about your gardening knowledge but it seems y

        • My point is-- these are standard English words which are *good* analogies when properly understood. Sometimes we need to slow down and remember that this is English and that it is just a matter of good analogies. Listeners too need to understand that this is just a set of good metaphores using plain English.

          I didn't mean to imply that none of them were good metaphors. But there is no good analogy to describe the difference between a IEEE-1284 (did I get it right? is that parallel port? stupid numbered stan

    • by Rakishi ( 759894 )
      Let me add that with search engines and wikipedia there is no excuse for not knowing the terminology except laziness.

      If you can't be bothered to spend an hour reading up on things then please find another profession for everyone's sake.
      • Re:Jargon? (Score:4, Insightful)

        by misleb ( 129952 ) on Friday June 22, 2007 @07:08PM (#19615123)

        Let me add that with search engines and wikipedia there is no excuse for not knowing the terminology except laziness.

        Well, i dunno about that. Lack of genuine interest could also account for it. That is part of the reason why I suggested the possibility of a new line of work. It wasn't an insult. I wasn't suggesting that he's necessarily lazy or dumb.

        Any time I meet a graduate of CS, or in this case in their final year, who hasn't already gotten involved in an OSS project or even some significant personal project, I can't help but question their level of interest in the subject. Especially if they are a Linux user already. I mean, how can you NOT already be familiar with things like "nightly builds" as a linux user? Never been on a mailing list for a project you're interested in?? Come on! Most good programmers I know were writing code before they even got to college... some of them didn't even bother with a CS degree.

        Of course, this could also be part of a culture diffeernce between India and the US that I am not aware of. I'm open to that possibility.
  • Skool... (Score:4, Informative)

    by Nezer ( 92629 ) on Friday June 22, 2007 @02:59PM (#19612077) Homepage
    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.
    • Re: (Score:3, Informative)

      by Compholio ( 770966 )

      Professors are, IMHO, under obligation to ensure you get an education, not training.

      Our department actually states that one of three "missions" is to educate students in how to go out and figure things out for themselves. Some of our professors even suggest that this mission is the fundamental difference between a community college and a university - that community colleges attempt to "train" you to do a particular task while universities attempt to "educate" you in figuring out how to learn on your own.

      • Re:Skool... (Score:4, Funny)

        by i.r.id10t ( 595143 ) on Friday June 22, 2007 @03:31PM (#19612569)
        Crap, I'm doing it wrong! I teach hte only Linux class here at the Comm College I work at (in another department) as an adjunct, adn I spend time with my students showing them how to use man pages, search google effectively, read the "How to Ask Smart Questions" doc by ESR, etc.... Any other tips on how I can change my ways?
        • Any other tips on how I can change my ways?

          Yes, encourage your students to preview their comments before posting as to avoid lots of "hte" and "adn"s. ;-)
    • Re:Skool... (Score:4, Insightful)

      by bfields ( 66644 ) on Friday June 22, 2007 @03:29PM (#19612545) Homepage

      Yeah, absolutely, consider a graduate degree, and make sure you do a lot of research on the schools you consider to make sure they have people whose interests are closer to your own. Google is your friend here.

      Might also be worth taking a harder look at your own school--are you sure there isn't an odd corner of some department someplace you hadn't previously noticed that's a hotbed of linux hackers? And if you're sure there's not, consider finding a meeting place, printing up some flyers, and starting something--maybe you'll be surprised by who comes out of the woodwork.

      Other advice:

      • Run linux, if you don't already! It's easier to understand and care about the software that you use daily.
      • Work on documentation for some project. Even a lot of the most succesful projects are desperately in need of better documentation, so they'll be really happy to have you. And it's an easy way to get to know the project--both the technical details and the various personalities and projects. You'll probably at least learn how to build it, contribute patches, etc.
      • Find a bug (if you've done the above, you've probably run across one or two). The ideal bug would be something easy to reproduce.
      • Or find some interesting new feature you really want, and work on that.
      • There's a lot of technical stuff to learn (C, bash, various other languages, autotools (yipes), gcc, the basic posix api's, etc., etc.)--don't try to figure it out all at once. Figure out what you need to for a given project.
      • Document what you learn as you go along, and spend some time helping out newbies--if nothing else, it's a good way to make sure you really understand things yourself.
      • Re: (Score:3, Insightful)

        by bfields ( 66644 )

        Find a bug (if you've done the above, you've probably run across one or two). The ideal bug would be something easy to reproduce.

        Oh, and by the way, if you're not yet equipped to completely understand and fix the bug, you can still be extremely helpful (and learn a lot) just by reporting what you find out about the bug to the mailing list. Steps to reproduce it, partial results of any debugging, etc.--a lot of that grunt work can help you understand the project, and can provide just what the other develo

  • 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.
  • 1: that's not computer science. that's software, software engineering (maybe), programming.
    computer science is the theory and history of computer programming from an unbiased (read: non-implementation point of view). so, objects, data structures, logic flow, operating system theory.

    2: you went to the wrong school. why did you stay there for so long?

    these two problems are easily corrected with time and effort. it sounds like you are interested, that is step one. step two would be jumping in. you us
  • by OriginalArlen ( 726444 ) on Friday June 22, 2007 @03:03PM (#19612161)
    Find something that you find really interesting. That could be a specific kind of software (media players, CRM systems...), or particular functional areas - say, printing, bookmarks, inter-component messaging frameworks...) Or just a particular bit of software you get interested in because you find yourself using it a lot, and are *constantly* getting annoyed by that *one* missing option to use an LDAP backend, which would make it perfect for you... I've got involved (very very slightly) with a web browser, and some network security stuff, because I was using them anyway (or working in the general area in some way); I was also consciously looking out for some way to contribute something - you take the opportunities you find.

    Or some other type of abstract class of programming task. Writing documentation is also a good way to learn - there's always a need for good docs, and you have to get to know the software really well to write them.

    Pull the current source. Take a poke around. Grep for comments. Look at the changelogs. Look at what's being worked on, where the problems are, how much activity is going on, how many contributors there have been. Scratch your itch!

    And if you can't find anything you actually *want* to do, why, then you can't do better than get some good experience on the wonderful Mozilla [] projects! Head over to [], pick an interesting open bug, and go to it!

    Good luck, and have the appropriate amount of fun :)

    • by drinkypoo ( 153816 ) <> on Friday June 22, 2007 @04:00PM (#19612969) Homepage Journal

      And if you can't find anything you actually *want* to do, why, then you can't do better than get some good experience on the wonderful Mozilla projects! Head over to [], pick an interesting open bug, and go to it!

      With Mozilla, or many other large projects, it's a better idea to go look at the build instructions, and once you can understand and follow them and get a working executable out, THEN try messing with the code. Mozilla projects can be very difficult to get compiled (there are lengthy guides on the subject) and being able to actually test your code is an important first step.

  • by igotmybfg ( 525391 ) on Friday June 22, 2007 @03:06PM (#19612199) Homepage
    I find that I work best (hardest, smartest, and longest) on projects that are personally interesting to me; I suspect that you may find the same is true for you.
  • look at the wishlist, read the code and implement the wish.

    then send patch.

    thats all there is to 'joining' an open source project.
  • Pick one that looks worth completing, with people who look worth working with/for, and just contribute some code. Or test something and contribute your bug reports - or patches.

    If you don't like what happens, then pick another. You'll find one you like, maybe on the first try.

    There's no penalty for picking the wrong one. But there is a penalty for not picking any: missing the experience.
  • Skills first (Score:4, Insightful)

    by Anonymous Coward on Friday June 22, 2007 @03:11PM (#19612271)
    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
    • Why would he need "dynamic programming" out here in the real world? Care to explain? Why does he even need to master common algorithms? Trees, sorting - all of this is already done twenty times over. This is not to say that strong background in algorithms doesn't help, it does. This is to say that 90% of programming has nothing to do with computer science, and as a beginner, that's the 90% he'll be doing.
  • I did this. (Score:3, Insightful)

    by Aladrin ( 926209 ) on Friday June 22, 2007 @03:13PM (#19612293)
    Not long ago, I did this. I didn't set out to 'join an open source project', but that's what ended up happening.

    I found a piece of software I was -very- interested in, felt I could help the team, and started talking to them. It wasn't long before I felt I had something to contribute, and they gave me SVN access. I did, they really liked it, and I was part of the team.

    The key is that you have to -really- want to be a part of -that project-. If the goal is simply 'join any project' then you are going to hate it and the team will probably get quite upset with you for either contributing crap or not contributing much at all, and simply causing ruckus on the forums.

    Again, don't join a project unless you really care about the project itself.
  • It depends on the projects. I have made significant contributions to one and not joined in any official capacity. I hand out on the mailing list and exchange patches with other users and the developers.

    Other projects, I have been invited to join based on my contributions (ie patches).

    Others, I submitted small patches and neither wanted to, nor was invited to join.

    So, yes. Submit patches.

    If you can find a piece of software that you like, but you want to improve, then you can make a more significant contribut
  • Find an itch (Score:5, Insightful)

    by linuxwrangler ( 582055 ) on Friday June 22, 2007 @03:13PM (#19612313)
    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.
    • One more thing: I suggest you aim for a small project. It tends to be easier to get involved, and since developers are more scarce, you'll be able to make more of a difference. Also, the source tends to be a bit smaller, so it's easier to understand. Big projects (eg kernel, kde, firefox, OOo) are still very welcoming to developers, but you may find it harder to get started.

      Also, consider a few other topics, eg: Distributions (interface stuff for Ubuntu, DSL enhancements), VoIP (linphone/ekiga), embedded (
  • Start by looking for a solution to a problem you have. Chances are, someone's already working on it. Install the code and evaluate it. Join their mail lists, hang out in IRC. Get to know the other developers as well as the code, and of course their tools and processes. Submit some patches. If your efforts have merit, eventually you'll be brought into the fold.

    Starting with a project you can personally use or have an interest in gives you a reason to participate. Picking a project at random won't end

  • by Anonymous Coward
    is a Best Buy or a Barnes 'n Noble. you're going to need to know the tools and procedures of open source development before you can get anything done or changes submitted.

    0. Install an Open Source operating system with development tools, such as [Net,Free,Open]BSD or Linux
    1. Learn CVS [, [].
    2. Learn the basics of the GNU C Compiler [].
    3. Learn Automake, Autoconf and Libtool [
    • Re: (Score:2, Insightful)

      by brteag00 ( 987351 )
      Meh ... I'm not so sure I agree. I don't think the best way to learn CVS is to read a book about CVS, but rather to puzzle through downloading a source tree, making a few changes, creating a diff, etc. There's no better incentive to learn how to use a tool than having a job you need to get done with it.

      I remember the first time I had to extract a .tar.gz archive ... the man page had me completely lost, and the GNU info pages weren't any better. But darn it, I had to get the archive open!

      Certainly, there
  • by jestill ( 656510 ) on Friday June 22, 2007 @03:19PM (#19612397) Journal
    I am doing a Google Summer of Code [] project this summer. I have found it a really great way to join an existing Open Source project. This may be too late for you since you are in your last year of school, but other folks should check it out.
  • As a bunch of people said, create an account and get on source forge. You can work as part of a team OR you can develop your own project. If you choose the latter, pick something that interests you. Think of an application that you'd like to have. A tool that you could use. A software library that you wish was available. Then develop it and put it on source forge. You'll learn a lot and it will be a lot more enjoyable if it's something that you have a real interest in.
  • Lots of great suggestions already. You might also want to read a good book on best practices for open source development projects. Karl Fogel's "Producing Open Source Software" is excellent and available in print form or free online here [].
  • If you're using a free or open source piece of software that's really the place to start - you shouldn't have to google very much to find out information about a project that you could join up with, just look at what you use. Look for something that wouldn't be too overwhelming for you to start out with.

    Once you have that, the best way to find out about what's going on from there is to join the developer mailing list for the project, and to check out their IRC channel. Usually it's best to lurk for a b

  • Sadly... (Score:5, Informative)

    by jd ( 1658 ) <{moc.oohay} {ta} {kapimi}> on Friday June 22, 2007 @03:27PM (#19612525) Homepage Journal
    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.

  • There are many sugestions posted, here. But I have always taken the approach that we don't need more of the same.
    We don't need more programming languages or librarys or classes.
    What we need is are fixes for the big broken problems.

    Electronic Voting is badly broken, I have mailclad, on sourceforge and web site
    using almost the same underly concepts and technology there is Decash, electronic cash and a new scheme for Anti-spam I will most likely put up at or that I am pla
  • One thing many open source projects are lacking is good, solid documentation. There's a thousand minds working on the code, but not all of them know what everything does. Documentation would help, especially when it comes to answering some of the more common questions.

    If you pick a project, but don't want to/don't know how to jump right into coding, download the code. Read it over. Document it (comments, docs, faqs, whatever). You'll get to know the code in and out, and in doing so, probably figure out

    • Seconded (Score:4, Informative)

      by metamatic ( 202216 ) on Friday June 22, 2007 @04:16PM (#19613171) Homepage Journal
      Frankly, Google should scrap their Summer of Code and have a Summer of Documentation. There's already too much badly documented (or undocumented) code.
      • Frankly, Google should scrap their Summer of Code and have a Summer of Documentation. There's already too much badly documented (or undocumented) code.

        You should see the code the LedgerSMB project inherited. No documentation, and the structure resembled either a big ball of mud or a plate of spaghetti depending on your viewpoint. (I meld these together and call it the big ball of worms architecture). While the program's use is documented, and while new code is documented, older code is rarely commented and those comments that exist are actually a part of the code (remove at your own risk!).

        Six months later, we are making a dent in the old code. In an

    • by Intron ( 870560 )
      Not possible. The only useful documentation the intent of the code, which can't be learned from looking at the source. An example is this brilliant piece of software by Brian Kernighan. If you hadn't seen it before, how long would it take you to figure out what it does and why its better than the more obvious way to do it?

      unsigned int c;
      for (c=0; v; c++) {
      v &= v - 1;
      return (c);
  • While the subtitle for Karl Fogel's _Producing Open Source Software_ is "How to Run a Successful Free Software Project", the reviews on Amazon suggest it is good for participants as well. It's available for free at [] and is fairly inexpensive if you want it in paper form. I worked with Mr. Fogel at CollabNet and he's first-rate at this, so while I haven't read the book (it's on my to-be-read pile...), I suspect it may prove useful to you.

  • The answer to your question depends on the project. Well established projects tend to have rules to gain access. FreeBSD developers often have to submit a few patches, get a mentor and go through two years of hell to get in. It really depends in that case on what you want to do. Joining ports is easier than working on the kernel. The Linux kernel development effort has a lot of structure so it will take time to get noticed.

    Smaller projects, new projects, or projects with few developers are much more li
  • Mny people are not hackers or programers and give as excuse that they are non-technical and thus can not contribute. However there are many ways to contribute.

    * Make a level for your favorite game and contribute it back to the maker
    * Make a skin for you favorite program that uses skins
    * Make Icons, wallpapers or any art for whatever you desire
    * Translate website and manuals to your language
    * Beta test software as a simple user
    * Burn distributions for those who can't
    * Have your bittorent upload your favorite
  • Hi --

      Read one of those books that introduce you to the toolsets and cycles in open source programming.
      Also, choose a domain you want to work in, or one in which you have some expertise. Is it user interfaces, graphics, mathematics, little enhancements to GNOME or KDE, etc?
      And remember that Linux is not your only choice: you also have OpenSolaris and the *BSDs (FreeBSD, OpenBSD, NetBSD and DragonflyBSD).

  • Don't (Score:4, Funny)

    by Statecraftsman ( 718862 ) on Friday June 22, 2007 @04:17PM (#19613183) Homepage
    Yes, I've seen all your supposed facts and evidence that open source software helps people learn to program and provides many more people with the tools they need. Unfortunately, I don't go by facts and evidence. I go by my gut.

    My gut tells me that free software is just wrong, and that if you don't get paid for your work, you just might be a communist. So please don't submit patches and support this drain on our economy. Go out and *buy* the software you need. That way you'll be able to support the country and economy again next time an upgrade or new version comes out. My gut and thousands of democracy-loving programmers thank you.
  • Fixing some WoW mods?

    Tons of Lau, EASY programming, plenty of defineable todo's, and a comunity which will actually use your product!
  • For the problem of "geek slang" you mention, a few tips which can help:

    - Google define []: Type "define:" followed by what you search in the Google search bar. For example: nightly build []

    - Many of the above will lead to Wikipedia, which is a good resource for anything geeky (and other stuff also)

    - Sometimes, the Urban Dictionary [] can help

    - In forums or mailing lists, when you come across an unknown term, just ask.

    - Don't only read /. and forums, but also some literature...
  • by SL Baur ( 19540 ) <> on Friday June 22, 2007 @05:02PM (#19613803) Homepage Journal
    It's unfortunate you're in your last year. College students are typically the most valuable contributors to a project because they have fewer hard demands on their time like work, spouses, young children, etc. Also, upon graduation, you will often find that the leaders in the project are more than happy to write you references after you graduate - I did on a number of occasions.

    (In no particular order)

    DO pick a project that interests you.
    DO lurk for awhile on the relevant mailing lists so that you get an idea of who the leaders are, what the pressing issues are. You'll also be able to learn that way how contributions are expected to be made. It is also a good idea to read archives of older postings, understanding history is very important and often ignored.
    DO be aware of how the project is licensed. Some projects require copyright assignment and will not touch any work you do until you perform copyright assignment.
    DO consider doing documentation patches first. Bug fixes are cool, but it is only the very rare person who tackles documentation. There never tends to be an oversupply of people of doing documentation.
    DO get involved doing build testing especially if you have access to non-standard or rare hardware.
    DO learn what a .signature is before you start sending mail out. Be sure that you turn it off.
    DO read any relevant FAQs before offering any suggestions.
    DO NOT repeat a suggestion that has been turned down repeatedly (ex. why can't we replace the lisp engine with Perl?, why can't we have a stable Linux 3.0, etc.)
    DO NOT get angry at someone in public.
    DO NOT contribute to off-topic threads, you should know what these are, you've read the FAQ, right?
    DO practice your English writing skills, this will help you in your career too.
    DO NOT be disappointed when your patches get rejected, learn from your mistakes and keep trying.
    DO try to answer questions more than you ask them, when your answers are correct you will earn a lot of reputation.
    DO be sure that you're having fun.
  • How I did it (Score:3, Informative)

    by CTho9305 ( 264265 ) on Friday June 22, 2007 @06:54PM (#19614973) Homepage
    A few years ago, I wanted Mozilla to be able to play a sound when a download completes []. I got on IRC and asked for help, and a couple very patient developers helped me understand where the code was that needed to be patched, and how to fix the issue. As I found other things that were missing, or things I didn't like, I wrote more and more patches, each time with less help - probably 99% of the lines of code in my early patches were written over IRC by more experienced devs, and pasted into a text editor by me :-).

    I started taking on code-cleanup-type bugs, and eventually, as I became more familiar with the codebase, more [] visible [] bugs [] (and even ones that didn't affect me personally). I've fixed quite a few bugs [] now, and have quite a bit of responsibility [].

    I don't know how well it'll go if you don't have a vested interest in your contributions - it's incredibly difficult to get into a huge codebase like Mozilla. I had written programs of up to a few thousand lines of code before, but working in a multi-million-line project is very different. Start with small changes, and don't feel bad when your patches have to go through many revisions before being accepted.
  • by ardran ( 90992 ) on Friday June 22, 2007 @08:06PM (#19615603)
    I was in a similar situation when I got out of college. I had a lot of theoretical training in college and wanted to get my hands bloody. I was coding at work, but it was odd embedded stuff and I wanted some different experiences to "cleanse the palate". I ended up doing work for two projects: Vim and Mozilla. I chose these projects for two reasons: I liked what they did, and they had lots of room for additional coders.

    Vim was sort of a dive-right-in situation. Bram maintains a vast TODO list that ships with every version of the product. I spent a while reading it, picked out a couple things that seemed like they ought to be easy, and got to work. I joined vim-dev and mailed out patches. I didn't do a ton for the app, but I got a few things in.

    Mozilla was a different beast in many ways. It was a much more structured environment due to the review process and the presence of Netscape. Also, it was in C++ (which I barely even knew, thanks to some shoddy university training), and not just any C++, but XPCOM. At first I was intimidated by the size of the code and not knowing where to start, so I didn't even touch the code. I spent several months just sitting in #mozillazine and triaging bugs. I dup'd, I closed, I changed to NEW, all that good stuff. Through this, I achieved two important things: I got a much better sense of how the product worked, and I met some of the players involved through IRC contact. By this time I was sitting on #mozilla as well, but I never said a word.

    Eventually, I downloaded the code and bought a copy of Don Box's "Understanding COM" for background reading (that book is amazing). From all the time spent triaging, I knew some of the areas where bugs were piling up and nobody was looking at them, so I started there. I submitted a few small patches, had them reviewed, had people check them in for me. The reviews were harsh sometimes, but I was learning a lot. Eventually I moved around a bit and took on larger fixes.

    I did this for a year or so before I got too busy with work and dropped out of sight. To this day it was some of the most fun I've had as a coder. For all its flaws (in those days, Firefox was still "m/b", and Netscape ran the show), it was a great project, and some of the people who worked on it were the best programmers I've ever worked with.

    So, my advice: start slow, start small. Figure out who you can ask for advice about something. Look for other (non-coding) ways you can help out that will help you get familiar with what's going on. It's worth it.

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller