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.
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.
http://halo.willisburg.org/
Check out the project, and drop us a line if it interests you.... we can always use another hand or two on the project.
-Willis
"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
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
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.
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
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.
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.
(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)
And do it! For instance, improve a feature of a game that you like. Or implement a missing feature that you've been hankering after. I think this is a great way to get started, because it gives you the satisfaction of reward.
For example, I like to use the free software Theora video codec to rip DVDs under Linux. It used to support SIMD-acceleration, making it encode movies about twice as fast... but only on 32-bit x86. Well, I had just gotten a new AMD64 box, and wanted it to rip movies faster. So I checked out the Theora code, refreshed my knowledge of assembly language, and within a couple days I had a working MMX/SSE-accelerated encoder. It was a very satisfying feeling!! And that code went into the mainline Theora release a couple months later (1.0alpha6).
My bicyles
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
Yes, I've seen all your supposed facts and evidence that open source software helps people learn to program and provides many more people with the tools they need. Unfortunately, I don't go by facts and evidence. I go by my gut.
My gut tells me that free software is just wrong, and that if you don't get paid for your work, you just might be a communist. So please don't submit patches and support this drain on our economy. Go out and *buy* the software you need. That way you'll be able to support the country and economy again next time an upgrade or new version comes out. My gut and thousands of democracy-loving programmers thank you.
And if you cook it down and carmelize it it becomes "dulce de leachate". Yum!
It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
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
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.
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
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.