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
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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
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.
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:
He was probably just typing too fast, because he was so irritated by the dumbass parent post.
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.
.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!
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.
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.
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.
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.
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.
.signature is before you start sending mail out. Be sure that you turn it off.
(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.
it's about skills. You'll most likely never use dynamic programming to solve a business automation problem but studying such algorithms and solving hard problems gains you skills. Debugging skills, analysis skills, the self confidence, ability to read and interpret complicated texts.. When you study algorithms, you don't do it for the purpose of publishing a new STL. It's already been done "20 times over". You study them to improve your mind.
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.
...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 along with sourceforge. (I am not affiliated with Sarovar or anything, btw.)
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 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.
You're far better off shooing the sub par off than giving them even a small job.