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?"
Read the TODO list (Score:5, Informative)
you've already gotten good advise... (Score:5, Informative)
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.
go look at some help wanteds (Score:3, Informative)
Easy (Score:5, Informative)
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.
Skool... (Score:4, Informative)
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
Step #1, become familiar with the software (Score:4, Informative)
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.
Something that interests you (Score:3, Informative)
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 [mozilla.org] projects! Head over to https://bugzilla.mozilla.org/ [mozilla.org], pick an interesting open bug, and go to it!
Good luck, and have the appropriate amount of fun :)
Re:Jargon? (Score:5, Informative)
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.)
Start with documentation (Score:1, Informative)
Next teach yourself what things do, or get help from the devs, and take notes. Turn those notes into documentation, either as comments in the code, or readmes/howtos/etc. This has several advantages:
#1 - Documentation in most cases (not just open source) tends to be shoddy, this helps out a lot for the end users and the other devs.
#2 - You've learned a lot more about the project/software, and can be more help to the project at this point.
Start with documentation (Score:1, Informative)
Caveat: Java projects tend to use different build techniques; Python has it's own secret handshakes, etc. So once you learn the basics you'll need to pick a path to follow.
IOW, I wouldn't worry about making technical contributions until you've acquired a certain level of skill with the tools. Even bug-hunting can involve a lot of technical expertise.
Re:Skool... (Score:3, Informative)
an easy place to start (Score:2, Informative)
0. Install an Open Source operating system with development tools, such as [Net,Free,Open]BSD or Linux
1. Learn CVS [http://cvsbook.red-bean.com/, http://www.cs.kent.ac.uk/systems/cvs-howto.html%5
2. Learn the basics of the GNU C Compiler [http://www.faqs.org/docs/learnc/].
3. Learn Automake, Autoconf and Libtool [http://sources.redhat.com/autobook/autobook/auto
4. Download a tarball of some source code and compile it, learn how to edit Makefiles, etc.
5. Check out the source code of the same application from CVS, mess around with it.
Google Summer of Code (Score:3, Informative)
Re:you've already gotten good advise... (Score:3, Informative)
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 just fine :) But the point is that I was motivated to fix the problems because they affected me. Some are bugfixes and some feature enhancements, but all are patches I wrote that were accepted, and both fixed my problem and made me feel good.
Learning about OSS projects (Score:2, Informative)
Sadly... (Score:5, Informative)
(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 [unmaintain...ftware.org] 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.
Re:Something that interests you (Score:4, Informative)
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.
Re:Read the TODO list (Score:3, Informative)
Re:We can use your help if you're interested... (Score:2, Informative)
This project is building off of a microkernel architecture, working to introduce portable applications and user profiles across all *nix platforms, improve and make the UI more consistent and user friendly, design a *nix environment that even if it can be breached cannot be altered past a reboot, and lower system overhead significantly. This is not just "another one" with a couple minor UI tweaks. Genuine effort to make major changes is being done, and with the number of coders we have, we're never going to get a proper alpha release out the door without more help.
Pan it if you like, your attempt at a scathing comment to belittle this project has done nothing but reaffirm that it's being done for the right reasons and demonstrate that it's more than just another wannabe in the OSS landscape.
Seconded (Score:4, Informative)
As a project maintainer, I would say... (Score:3, Informative)
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 sorts of projects you want to get involved in. (I prefer to do all three.) If you want to earn income as a coder, and are willing to program in PL/PGSQL and Perl, I would recommend the LedgerSMB project primarily because we seem to have a chronic shortage of coders interested in doing commercial work. On the other hand, if business process problems aren't interesting and hard-core computer science is, maybe some of the compiler projects or kernels, or something new altogether.
Re:Jargon? (Score:3, Informative)
Re:you've already gotten good advise... (Score:4, Informative)
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.
How I did it (Score:3, Informative)
I started taking on code-cleanup-type bugs, and eventually, as I became more familiar with the codebase, more [mozilla.org] visible [mozilla.org] bugs [mozilla.org] (and even ones that didn't affect me personally). I've fixed quite a few bugs [mozilla.org] now, and have quite a bit of responsibility [mozilla.org].
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.
Re:or fix the bugs :) (Score:4, Informative)
Some projects are actively trying to get newbies involved. I've heard of GnomeLove [gnome.org] (though I don't actually know much about it), and Subversion has a list of bite-sized tasks [tigris.org].
Re:or fix the bugs :) (Score:2, Informative)
Re:Read the TODO list (Score:3, Informative)
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 RTFineM and goolge is my friend - but any links would be highly appreciate and thanked.