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?"
specifically, this link. You may need an account to view it, I don't know.
~/.sig: No such file or directory
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.
"but most are overloaded with jargon like upstream/downstream, nightly builds, and so forth"
Um, this is pretty basic language used on real-world projects. You need to learn the "jargon" as well as actual programming. That's just the way it is. If this scares you, you may want to consider another line of work.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
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.
Mod parent to +5 (or +11, depending on how high your dial goes).
The only thing left out was that joining the mailing list and discussion boards will help you learn the lingo fastest. The only way to learn how to talk like a 133t hax0r is to lurk among them for a while. Every group is going to have their own slang. There is no "master list". Your background in CS will help you piece things together (well, related to the CS stuff). A classic example? In X Windows, knowing that the server is your screen and the client is the processes (apps) isn't easy to figure out unless you hang around them long enough.
But being a coder, like the parent post says, picking an item off of the TODO list and doing it will give you a good start. Pick an "easy" one. Read the code. Re-read the code. Make an attempt. Re-read the code. Redesign your solution to fit closer to how everything else works. Talk on the boards with people about how you have a mostly working solution. Then, you'll get a feel for their slang as they respond to something that you are pretty familar with.
Layne
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.
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
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.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
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:
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.
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.
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.
You're far better off shooing the sub par off than giving them even a small job.