Slashdot Mirror
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?"
and do one of the items, test the patch, and submit it. Then repeat.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
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.
three can keep a secret, if two are dead - benjamin franklin
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.
Reality is that which, when we cease to believe in it, still exists. - Philip K Dick
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Perhaps, when you are finished with your bachelors at this school, you should consider a school with better professors for your masters.
.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.
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
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.
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 https://bugzilla.mozilla.org/, pick an interesting open bug, and go to it!
Good luck, and have the appropriate amount of fun :)
Everything I needed to know about life, I learnt from Blake's Seven
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.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Find a project you want to help with, and believe you can learn enough to help with.
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.
Find a project that needs developer documentation. That could include documenting build/test processes. That'll force you to read lots of code and get a feel for things. It sounds like you don't have much experience with the tools and processes that do the real work - if you've only worked with MS tools, much of that stuff is hidden behind pretty interfaces. Start by learning how makefiles work; learn a little bit of shell programming; try to learn a bit about the various tools commonly used in makefiles, e.g. sed, grep, etc. You should be able to pick up on a bunch of the jargon as you proceed; the Jargon File can be helpful.
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.
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.
D .b ook.html, http://autotoolset.sourceforge.net/tutorial.html, http://www.amazon.com/Autoconf-Automake-Libtool-Ga ry-Vaughan/dp/1578701902, http://www.st-andrews.ac.uk/~iam/docs/tutorial.htm l%5D.
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.
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.
"Asleep at the switch? I wasn't asleep, I was drunk!" -- Homer
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.
(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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Yeah, there are several "experimental distros" out there, but how many of them are actually truly experimental?
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.
Frankly, Google should scrap their Summer of Code and have a Summer of Documentation. There's already too much badly documented (or undocumented) code.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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 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.
LedgerSMB: Open source Accounting/ERP
Don't know the Jargon? Wikipedia is your friend. You are lucky to work in the CS field. That portion of wikipedia is actually full of good entries
Help! I'm a slashdot refugee.
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.
My server
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.
Or join a smaller one, one that doesn't have a zillion developers. Know php? check out http://www.xoops.org/ - they'd be happy to have a developer I'm sure. Just surf around on sourceforge and find one you like and would be valuable to with not a whole lot of developers, and jump in. The worst that can happen is the project dies or it's dead and nobody responds. (I don't have anything to do with Xoops beyond being a user - although I do have some input at http://www.winpackman.org/ where I'm positive they would love to have you =) )