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?"
Re:try sourceforge... (Score:5, Insightful)
or fix the bugs :) (Score:5, Insightful)
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.
Jargon? (Score:4, Insightful)
Um, this is pretty basic language used on real-world projects. You need to learn the "jargon" as well as actual programming. That's just the way it is. If this scares you, you may want to consider another line of work.
-matthew
Pick an interest and run with it (Score:4, Insightful)
Re:Read the TODO list (Score:5, Insightful)
The only thing left out was that joining the mailing list and discussion boards will help you learn the lingo fastest. The only way to learn how to talk like a 133t hax0r is to lurk among them for a while. Every group is going to have their own slang. There is no "master list". Your background in CS will help you piece things together (well, related to the CS stuff). A classic example? In X Windows, knowing that the server is your screen and the client is the processes (apps) isn't easy to figure out unless you hang around them long enough.
But being a coder, like the parent post says, picking an item off of the TODO list and doing it will give you a good start. Pick an "easy" one. Read the code. Re-read the code. Make an attempt. Re-read the code. Redesign your solution to fit closer to how everything else works. Talk on the boards with people about how you have a mostly working solution. Then, you'll get a feel for their slang as they respond to something that you are pretty familar with.
Layne
Re:Read the TODO list (Score:5, Insightful)
Skills first (Score:4, Insightful)
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
I did this. (Score:3, Insightful)
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.
Find an itch (Score:5, Insightful)
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.
Start with what you know, and with what you like (Score:2, Insightful)
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 bit before just jumping in stating that you'll do X, Y, and Z for them - that way you get a sense for the current status of the project and what they need.
A couple of other tips that might be helpful:
:)
- Take a look at the mailing list archives from the past few months and look for threads that interest you.
- Take some time to report a few bugs in the program, or to try and triage a bug that someone else has reported. - Join an IRC "meeting" of a group that you're interested in to see what they are doing and what their goals are
As a rule of thumb, most projects will be glad to have you if you're polite and actually do some work. If you are doing some work, and are polite, and they aren't happy to have you . . . Feel free to move elsewhere.
Re:Skool... (Score:4, Insightful)
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:
Re:Jargon? (Score:1, Insightful)
"...had bloody well better know what a "nightly build" is. Especially since it's not exactly a fucking secret..."
That's another thing to look out for: passive agression. There's quite a lot of it on the Internet. There's about ten times as much in the F/OSS world. I'm not really sure why. People seem to get more possessive about things that they're giving away.
It's also a big problem. With all the jargon about, the rule is "don't be afraid to ask". With all the agression, that becomes "be afraid, be very afraid". Fortunately, you can just leave the angry people alone and move on to something more fun. Just remember, they're lucky to have you. Probably. Unless you're an idiot or something.
Re:Skool... (Score:1, Insightful)
Re:an easy place to start (Score:2, Insightful)
I remember the first time I had to extract a
Certainly, there are a few exceptions (sendmail? autoconf?) where a good reference text makes a huge difference. But for "getting involved in Open Source development", I don't think B&N is the place to start.
Re:Read the TODO list (Score:5, Insightful)
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:or fix the bugs :) (Score:5, Insightful)
Also, be patient. Unlike the parent, talk to the maintainer before making dangerous changes.
Final note, Linux kernel list is notorious for ignoring patches... That's why it's good to read the mailing lists etc before trying to submit. Get a feel for the project.
Re:Read the TODO list (Score:5, Insightful)
Yep, definitely.
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:Skool... (Score:3, Insightful)
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 developers need to finally nail the problem.
Re:Read the TODO list (Score:3, Insightful)
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 move up the chain to more difficult bugs.
Regular developers will appreciate this contribution, because it will free up more of their time to focus on the bugs which require more experience with that particular project.
Let me throw in one additional important point for the original question-asker: Be nice to people. Other developers will welcome you into the fold if in addition to your contributions you seem like a nice person. There are plenty of egos in the world, so leave yours at home and just contribute in a positive and friendly way.
My suggestions for new contributors (Score:3, Insightful)
(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
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.
Re:or fix the bugs :) (Score:5, Insightful)
It's not about knowledge (Score:1, Insightful)
If your dream job is being a code-monkey that converts design documents to code, then correct, you don't need to know computer science at all. You can just get the knowledge you need and start churning. This often gets people in trouble when they come across something slightly complicated. If you never coded anything more complicated than nested loops, what are you going to do when you need to debug some spaghetti coded by an idiot 10 years ago? I've known quite a number of people who had been doing exactly what you propose for 10+ years, just learning what's needed for the problem at hand. They used to come to me for advice even though I was fresh out of school. Just obtaining knowledge thru experience doesn't get you anywhere. Anywhere nice at least.
I think having excess skill is a must for a developer, not an option.
I am an Indian and I faced the same thing (Score:1, Insightful)
...three years ago. I decided to finish my education before getting involved in something real.
Everything modded highly above so far is good and there's no point repeating it, so I will just mention the Indian stuff. :P
Problems
Solutions
Perhaps I should add a proper detailed howto for Indians on my home page sometime. Anyway, good luck!
Oh and also check out Sarovar [sarovar.org] along with sourceforge. (I am not affiliated with Sarovar or anything, btw.)
Re:Jargon? (Score:4, Insightful)
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.
-matthew
Start slow, start small, stick with it (Score:4, Insightful)
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.
Re:Easy (Score:3, Insightful)
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.
Re:or fix the bugs :) (Score:5, Insightful)
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.
Go read the mythical man month (Score:4, Insightful)
Re:Jargon? (Score:2, Insightful)
For one thing, English is one of the official languages in India - many of their governmental offices were set up by the British (apologies for any inaccuracies in this, my Indian friends explained it to me this way).
For another, the guy is getting trained as best he knows how and is already intimidated by the jargon - advice to seek work elsewhere isn't fair. It's about contributing, not power.
You were green once too, you know.