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?"
Read the TODO list (Score:5, Informative)
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.
Re:or fix the bugs :) (Score:5, Interesting)
Unless you fix a bug that nobody cares about or doesn't understand what the bug really is. For instance, for years ptrace() in Linux didn't behave like any other ptrace() in other commercial Unices. My colleague spent long hours analyzing the bug, creating a fix, and exhaustively testing the fix to ensure it didn't open up security holes (admittedly ptrace() is a touchy part of the kernel that is prone to security issues). Nonetheless, when he sent the patch to the Kernel mailing list, it was completely ignored. No discussion...not even to say "we are too afraid to accept a patch for ptrace() from someone we do not know". Another example involved an effort to get an interface into the kernel for virtualizing and accessing hardware performance counters (this is in the days before oprofile and something other Unices have long had). A dude submitted a very very nice kernel patch and user library for allowing virtualized access to hardware performance counters. The Linux kernel mailing list completely ignored it. No discussion whatsoever.
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:or fix the bugs :) (Score:4, Informative)
Some projects are actively trying to get newbies involved. I've heard of GnomeLove [gnome.org] (though I don't actually know much about it), and Subversion has a list of bite-sized tasks [tigris.org].
Re:or fix the bugs :) (Score:5, Insightful)
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: (Score:2, Interesting)
Writing and translating documentation, testing, and doing sales (yes, I'm serious) will endear you
to some project teams more than you probably imagine. My sister-in-law is doing sales and marketing
for a GNU-licensed open source project and is getting paid rather respectably, and traveling the world.
It's pretty cool, and it shocked the hell out of me that a person could make a living wage in *sales*
in the open source world, but I've se
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)
Re: (Score:3, Informative)
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: (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 m
Re:Read the TODO list (Score:4, Interesting)
Find something that you'll ENJOY (Score:5, Interesting)
For example, I like to use the free software Theora [wikipedia.org] 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).
Re:Find something that you'll ENJOY (Score:4, Funny)
- The Lone Punmen
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: (Score:3, Informative)
But YOU, really understood where I'm getting stuck!
Now making the choice amongst so many inetresting projects is undoubtedly difficult, everything(well, almost) seems interesting. But my main query is how do you get the entire picture of the whole project and locate the needle hiding itself in the haystack just looking at the bug report.
Sounds silly, but from a bug report to submiting patches - how do you do it?
I'm eager to RTFin
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
As a project maintainer, I would say... (Score:3, Informative)
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 s
try sourceforge... (Score:2)
Re:try sourceforge... (Score:5, Insightful)
you've already gotten good advise... (Score:5, Informative)
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.
Re: (Score:3, Informative)
I cannot agree with you enough. It is by far most sensible to start with a project you actually care about. Some of the first patches I ever submitted (not precisely the first but it's been a while) were for various Drupal modules. I made some mistakes, and some were not accepted, but most were and both I and the community got over the experience j
Re:you've already gotten good advise... (Score:4, Informative)
Next I submitted a one line patch. [Heck at that point I could not even use diff]
Then I wrote a manual. I worked out how to use diff, subscribed to the developer mailing lists. More patch, modules written by me.
I am now one of the administrators of the project.
From small acorns, big trees grow.
go look at some help wanteds (Score:3, Informative)
Easy (Score:5, Informative)
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.
Re: (Score:2)
Good way to find something you are ready to tackle.
Re: (Score:2, Funny)
Interesting that over 90% of your post occured after you said "End of story."
Re: (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.
We can use your help if you're interested... (Score:2, Interesting)
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
Re: (Score:2)
Re: (Score:2, Informative)
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
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
Re:Jargon? (Score:5, Informative)
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.)
My jargon word (Score:2)
Re:My jargon word (Score:4, Funny)
A chip? (Score:2)
It's called "swarf!" http://en.wikipedia.org/wiki/Swarf [wikipedia.org]
Some jargon is BS though. Investing jargon drives me nuts "taxflation", "bear", "bull", "forex", "fundies"...
Ugh. Don't get me wrong, the financial sector jargon is fine. It's very necessary and describes precise concepts. It's just this wishy-washy investing stuff.
Re: (Score:2)
Uh, no. Swarf may be the name for a collection of chips, but a single piece of metal that has been cut off a piece of work (typ. on the lathe, but also the output from a milling operation) is called a chip (unless it's a whole block you cut off, I don't even know what that's called, because I'm not really a machinist.)
Next time try wiktionary [wiktionary.org] as well as wikipedia, it will tell you that a chip is "A small piece broken from a larger piece of solid mate
Re: (Score:2)
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.
Nah, the real problem is that people have forgotten what the analogies really mean. Bandwidth is a plumbing-related analogy (the wider the band of a pipe, the more you can fit through it). A heap or a stack are pretty much great descriptions in *plain english* of what is logically going on.
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.)
WHo doesn't understand what it means to "build software?" Who doesn't understand what the word "nightly" means? Why is "nightly build" so hard to understand?
I would talk about your gardening knowledge but it seems y
Re: (Score:2)
I didn't mean to imply that none of them were good metaphors. But there is no good analogy to describe the difference between a IEEE-1284 (did I get it right? is that parallel port? stupid numbered stan
Re: (Score:2)
I have been known to answer questions, even ones I think are stupid. I've spent hours on various irc channels doing it, just to give something back (and while waiting for someon
Re: (Score:3, Interesting)
But that's just it, your not "giving it away" in the w/FOSS software world. You're sharing your work. With commercial software there's an understanding that you don't really own your work. You're selling your time to a company. So of course F/OSS developers t
Re: (Score:2)
Because most of them are not giving it away. They're trading it for respect and recognition. And for some reason there are many people who think that they have to act "superior" or arrogantly for people to respect them. This usually doesn't work, however, but
Re: (Score:3, Informative)
Re: (Score:2)
If you can't be bothered to spend an hour reading up on things then please find another profession for everyone's sake.
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
Re: (Score:2)
Ok smartass, please use search engines and wikipedia to give us a good definition of 'upstream build' and 'downstream build'. Make sure you filter out the non-programming usage of 'downstream build'. Pretend you're a second year college student trying to figure this stuff out.
Given that I have no idea what the terms mean it's not hard to pretend.
It seems that Debian people apparently use the terms upstream and downstream quite often. That leads to among other things this:
http://lists.osuosl.org/pipermail/darcs-users/2006 -June/010045.html [osuosl.org]
There are a few other references to conflicts and angry rants.
Upstream seems to refer to the packaged release type builds, with all the README files and so on (what apt
Skool... (Score:4, Informative)
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
Re: (Score:3, Informative)
Our department actually states that one of three "missions" is to educate students in how to go out and figure things out for themselves. Some of our professors even suggest that this mission is the fundamental difference between a community college and a university - that community colleges attempt to "train" you to do a particular task while universities attempt to "educate" you in figuring out how to learn on your own.
Re:Skool... (Score:4, Funny)
Re: (Score:2)
Yes, encourage your students to preview their comments before posting as to avoid lots of "hte" and "adn"s.
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: (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 develo
Re: (Score:2)
Re: (Score:2)
Alternatively, load the core dump into gdb (I prefer the printf's though).
Re: (Score:2)
Re: (Score:2)
Having to work from the command line is something I think of as hugely valuable in programming...Helped me out a fricking ton with Java, I tell you, because working with java classpaths and such is weird enough that having to actually type it out will teach you so much mor
Step #1, become familiar with the software (Score:4, Informative)
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.
2 things, including: that's not computer science (Score:2)
computer science is the theory and history of computer programming from an unbiased (read: non-implementation point of view). so, objects, data structures, logic flow, operating system theory.
2: you went to the wrong school. why did you stay there for so long?
these two problems are easily corrected with time and effort. it sounds like you are interested, that is step one. step two would be jumping in. you us
Something that interests you (Score:3, Informative)
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 [mozilla.org] projects! Head over to https://bugzilla.mozilla.org/ [mozilla.org], pick an interesting open bug, and go to it!
Good luck, and have the appropriate amount of fun :)
Re:Something that interests you (Score:4, Informative)
With Mozilla, or many other large projects, it's a better idea to go look at the build instructions, and once you can understand and follow them and get a working executable out, THEN try messing with the code. Mozilla projects can be very difficult to get compiled (there are lengthy guides on the subject) and being able to actually test your code is an important first step.
Pick an interest and run with it (Score:4, Insightful)
find a project that you like (Score:2)
then send patch.
thats all there is to 'joining' an open source project.
Just Do It (Score:2)
If you don't like what happens, then pick another. You'll find one you like, maybe on the first try.
There's no penalty for picking the wrong one. But there is a penalty for not picking any: missing the experience.
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
Who the fuck promoted this as insightful? (Score:2)
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.
Patches. (Score:2)
Other projects, I have been invited to join based on my contributions (ie patches).
Others, I submitted small patches and neither wanted to, nor was invited to join.
So, yes. Submit patches.
If you can find a piece of software that you like, but you want to improve, then you can make a more significant contribut
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.
Re: (Score:2)
Also, consider a few other topics, eg: Distributions (interface stuff for Ubuntu, DSL enhancements), VoIP (linphone/ekiga), embedded (
Find a project you're interested in (Score:2)
Start by looking for a solution to a problem you have. Chances are, someone's already working on it. Install the code and evaluate it. Join their mail lists, hang out in IRC. Get to know the other developers as well as the code, and of course their tools and processes. Submit some patches. If your efforts have merit, eventually you'll be brought into the fold.
Starting with a project you can personally use or have an interest in gives you a reason to participate. Picking a project at random won't end
an easy place to start (Score:2, Informative)
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%5D
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
Re: (Score:2, Insightful)
I remember the first time I had to extract a
Certainly, there
Google Summer of Code (Score:3, Informative)
Something that interests you (Score:2)
Learning about OSS projects (Score:2, Informative)
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 b
Sadly... (Score:5, Informative)
(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 [unmaintain...ftware.org] 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.
Genezzo database project looking for Perl coders (Score:2)
I prefer working on the real problems. (Score:2)
We don't need more programming languages or librarys or classes.
What we need is are fixes for the big broken problems.
Electronic Voting is badly broken, I have mailclad, on sourceforge and web site mailclad.com
using almost the same underly concepts and technology there is Decash, electronic cash and a new scheme for Anti-spam I will most likely put up at maildr.com or unmailable.com that I am pla
Gaming consoles (Score:2)
Next!
Documentation (Score:2)
If you pick a project, but don't want to/don't know how to jump right into coding, download the code. Read it over. Document it (comments, docs, faqs, whatever). You'll get to know the code in and out, and in doing so, probably figure out
Seconded (Score:4, Informative)
Re: (Score:2)
Frankly, Google should scrap their Summer of Code and have a Summer of Documentation. There's already too much badly documented (or undocumented) code.
You should see the code the LedgerSMB project inherited. No documentation, and the structure resembled either a big ball of mud or a plate of spaghetti depending on your viewpoint. (I meld these together and call it the big ball of worms architecture). While the program's use is documented, and while new code is documented, older code is rarely commented and those comments that exist are actually a part of the code (remove at your own risk!).
Six months later, we are making a dent in the old code. In an
Re: (Score:2)
Producing Open Source Software, by Karl Fogel (Score:2)
While the subtitle for Karl Fogel's _Producing Open Source Software_ is "How to Run a Successful Free Software Project", the reviews on Amazon suggest it is good for participants as well. It's available for free at http://producingoss.com/ [producingoss.com] and is fairly inexpensive if you want it in paper form. I worked with Mr. Fogel at CollabNet and he's first-rate at this, so while I haven't read the book (it's on my to-be-read pile...), I suspect it may prove useful to you.
My advice as the head of two projects (Score:2)
Smaller projects, new projects, or projects with few developers are much more li
Re: (Score:2)
Read a book and choose a problem or domain (Score:2)
Read one of those books that introduce you to the toolsets and cycles in open source programming.
Also, choose a domain you want to work in, or one in which you have some expertise. Is it user interfaces, graphics, mathematics, little enhancements to GNOME or KDE, etc?
And remember that Linux is not your only choice: you also have OpenSolaris and the *BSDs (FreeBSD, OpenBSD, NetBSD and DragonflyBSD).
HTH.
Don't (Score:4, Funny)
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.
How about... (Score:2)
Tons of Lau, EASY programming, plenty of defineable todo's, and a comunity which will actually use your product!
Vocabulary tips (Score:2)
- Google define [google.com]: Type "define:" followed by what you search in the Google search bar. For example: nightly build [google.com]
- Many of the above will lead to Wikipedia, which is a good resource for anything geeky (and other stuff also)
- Sometimes, the Urban Dictionary [urbandictionary.com] can help
- In forums or mailing lists, when you come across an unknown term, just ask.
- Don't only read
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.
How I did it (Score:3, Informative)
I started taking on code-cleanup-type bugs, and eventually, as I became more familiar with the codebase, more [mozilla.org] visible [mozilla.org] bugs [mozilla.org] (and even ones that didn't affect me personally). I've fixed quite a few bugs [mozilla.org] now, and have quite a bit of responsibility [mozilla.org].
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.
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.
Mod parent up (Score:2)
Yes, the author is a newbie. Apparently he is not a newbie at development and programming, but is a newbie to the way open source is structured. Something that is specific-project-neutral but tells people about how open source is done would be very helpful. Beyond that, the best I can suggest is to hold your breath and dive in. Don't be afraid to ask question; just admit what you don't know and show you're willing to learn, and willing to do the work to learn, but just need to be pointed in the right di