Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Good Ways To Join an Open Source Project?

Cliff posted more than 6 years ago | from the a-journey-of-1000-steps-must-start-with-a-first-one dept.

Programming 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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Read the TODO list (5, Informative)

Watson Ladd (955755) | more than 6 years ago | (#19611939)

and do one of the items, test the patch, and submit it. Then repeat.

or fix the bugs :) (5, Insightful)

sofar (317980) | more than 6 years ago | (#19612023)

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 :) (5, Interesting)

Anonymous Coward | more than 6 years ago | (#19612925)

Fixing bugs is the best way to become part of an open source project.

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:Read the TODO list (4, Insightful)

SQLGuru (980662) | more than 6 years ago | (#19612203)

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.


Re:Read the TODO list (4, Insightful)

bfields (66644) | more than 6 years ago | (#19612239)

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.

Bob Gotse is the future of Open Sores (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19612375)

Bend over and spread your cheeks.

That's the only sure-fire way to join an Open Sores project.

Netcraft confirms: Bob Gotse is the future of Open Sores.

If you want to learn to code get a job. You can have mine. (j/k no more H1B visas left :-). Don't waste your time on some toy application for a toy operating system.

Find something that you'll ENJOY (5, Interesting)

MoxFulder (159829) | more than 6 years ago | (#19612557)

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 [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 (1)

LiquidCoooled (634315) | more than 6 years ago | (#19612857)

I agree with this statement as much as the grandparents.

Its no use trying to work on a project which you have no affinity for.

My first public jump into Open Source was helping to fix the Flashblock [mozdev.org] addin on firefox.
When flash 8 came out it stopped working, so I took the dive and started pottering about with the code.
After a few inital stumbles I found the right balance and was able to code up a solution to the problem within the existing framework. (My initial codefix was OTT and essentially rebuilt the entire thing, my sig is appropriate...)

Re:Read the TODO list (5, Insightful)

Anonymous Coward | more than 6 years ago | (#19612945)

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.

you've already gotten good advise... (5, Informative)

capsteve (4595) | more than 6 years ago | (#19611973)

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.

Re:you've already gotten good advise... (2, Informative)

drinkypoo (153816) | more than 6 years ago | (#19612483)

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 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 just fine :) But the point is that I was motivated to fix the problems because they affected me. Some are bugfixes and some feature enhancements, but all are patches I wrote that were accepted, and both fixed my problem and made me feel good.

go look at some help wanteds (3, Informative)

iHasaFlavour (1118257) | more than 6 years ago | (#19611983)

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.

Easy (4, Informative)

SatanicPuppy (611928) | more than 6 years ago | (#19612001)

Two words: Source. Forge. As in Sourceforge.net [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.

Re:Easy (1)

marktoml (48712) | more than 6 years ago | (#19612073)

SourceForge also has a "Help Wanted" section where project folks post what skills they need.

Good way to find something you are ready to tackle.

Re:Easy (2, Funny)

Anonymous Coward | more than 6 years ago | (#19612151)

End of story.

Interesting that over 90% of your post occured after you said "End of story."

Re:Easy (-1, Troll)

Anonymous Coward | more than 6 years ago | (#19612513)

End of story.

Interesting that you have a "One Inch Penis."

Start small. Ideas are cheap, so pay your dues. (0)

Anonymous Coward | more than 6 years ago | (#19613073)

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.

Yes, and don't go proposing your great new idea until after you've paid some dues by bugfixing, maintenance, whatever. Because your idea will get blown off even if it's good unless you develop credibility with the team first.

Also, don't get discouraged if your first attempts at finding a niche fail. Unfortunately, lots of people jockey for position and reject newcomers to protect themselves. Its lame, but its human nature. Politics is inevitable, and many excellent geeks aren't good at that part of the game -- especially at first.

Finally, if at all possible, find a mentor. Find someone on the project with established seniority and develop a one-on-one relationship with that person. Take their advice until you can stand on your own two feet.

Write some code. (0, Redundant)

dudeman2 (88399) | more than 6 years ago | (#19612011)

Submit it. Read the feedback you get (if you get any). Write some more code. Repeat. That is all.

join in IRC (0, Redundant)

wikinerd (809585) | more than 6 years ago | (#19612017)

join an IRC channel and get to know the participants, state that you are a student and you wish to learn how to help. Browse the TODO list or the bug list and ask them how one could fix a particular bug, then try to do it.

easy solution (0)

Anonymous Coward | more than 6 years ago | (#19612035)

Just start your own! Then you can do whatever the hell you want!

We can use your help if you're interested... (2, Interesting)

Anonymous Coward | more than 6 years ago | (#19612055)

http://halo.willisburg.org/ [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.


Re:We can use your help if you're interested... (0)

Anonymous Coward | more than 6 years ago | (#19612641)

"The Gnu-HALO Project is an experimental Linux distribution..."

Another one? Why bother? Meh.

Or help here... (0)

Anonymous Coward | more than 6 years ago | (#19612687)

...if you'd also like a chance to get your name on some scientific publications. Check out QSIMS [sourceforge.net], a software package for doing high-precision quantum dynamics simulations for certain classes of quantum systems. QSIMS has applications in physics and chemistry, and was originally written to study quantum gate operations in optical lattice-based quantum computers.

Project overview
QSIMS is written in C++, and uses XML for input and output (as of version 0.5, which is in CVS but not yet available as a tarball).

Project status
Right now, the code has been developed to the point where it works and I can use it for my own research, but it still needs a lot of polishing, refinement, and optimization to be accessible for other researchers. I wrote docs for version 0.4, but haven't updated them for 0.5, which has a completely new input/output file format (XML-based). Nothing has happened with the project for about a year and a half because I've been working on a different project, but I'm about to start back into it as the other project is wrapping up.

To do list
  • Further optimization, to speed up simulations
  • Update documentation
  • Add multi-processor and/or distributed computing support to allow for use on very large jobs

Ideal "candidate"
  • Excited about being involved in physics / chemistry research
  • Knows C++
  • Interested and willing to learning some math and physics
  • Interested in optimization, distributed computing, and other aspects of scientific computing

To learn more, contact the project admin listed here [sourceforge.net].

Jargon? (4, Insightful)

misleb (129952) | more than 6 years ago | (#19612069)

"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.


Re:Jargon? (4, Informative)

drinkypoo (153816) | more than 6 years ago | (#19612173)

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.

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.)

Re:Jargon? (0)

Anonymous Coward | more than 6 years ago | (#19612469)

But *I* know everything....


Re:Jargon? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#19612759)

"If this scares you, you may want to consider another line of work."

"...had bloody well better know what a "nightly build" is. Especially since it's not exactly a fucking secret..."

That's another thing to look out for: passive agression. There's quite a lot of it on the Internet. There's about ten times as much in the F/OSS world. I'm not really sure why. People seem to get more possessive about things that they're giving away.

It's also a big problem. With all the jargon about, the rule is "don't be afraid to ask". With all the agression, that becomes "be afraid, be very afraid". Fortunately, you can just leave the angry people alone and move on to something more fun. Just remember, they're lucky to have you. Probably. Unless you're an idiot or something.

Re:Jargon? (1)

drinkypoo (153816) | more than 6 years ago | (#19612921)

It's also a big problem. With all the jargon about, the rule is "don't be afraid to ask". With all the agression, that becomes "be afraid, be very afraid". Fortunately, you can just leave the angry people alone and move on to something more fun. Just remember, they're lucky to have you. Probably. Unless you're an idiot or something.

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 someone who knows something to potentially help with my problem - it's a continuum.) But what I cannot respect is someone who doesn't even fucking try to find out the answers before they come begging for you to explain everything in the world to them.

Besides, if you simply ask google to define: nightly build [google.com] then it will do so. The result (from wikipedia) highlights another place to go for help, and so on. Not only do I abhor this false laziness (it's actually easier to ask the computer because then you don't have to deal with humans) but someone who needs their hand held to that extent is probably going to need their hand held constantly.

I don't have time to hold hands - I'm not a crossing guard.

I help those who help themselves :)

Re:Jargon? (1)

Rakishi (759894) | more than 6 years ago | (#19612407)

Let me add that with search engines and wikipedia there is no excuse for not knowing the terminology except laziness.

If you can't be bothered to spend an hour reading up on things then please find another profession for everyone's sake.

Skool... (4, Informative)

Nezer (92629) | more than 6 years ago | (#19612077)

Perhaps, when you are finished with your bachelors at this school, you should consider a school with better professors for your masters.

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 .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.

Re:Skool... (1)

twitter (104583) | more than 6 years ago | (#19612211)

This is such a shame when so-called "professors" actually hinder your learning experience.

It's strange that they don't teach them on GCC. The easiest way to make sure your students spend their time learning programming is to set them up with shell accounts and let them log on. This is the way I've seen it done.

Re:Skool... (1)

xgr3gx (1068984) | more than 6 years ago | (#19612323)

I don't think you can go wrong with a C style language that is cross platform. C, C++, Perl, PHP, Python. They're pretty similar, even Java too, and they all run on NIX and Win.
If you learned Perl, than changed jobs to a company uses mostly C, the transition shouldn't be that hard.

Re:Skool... (1)

Rakishi (759894) | more than 6 years ago | (#19612361)

Until they need to debug because their program seg faults (so printfs don't help) and promptly try to kill you.

Re:Skool... (1)

Dan Ost (415913) | more than 6 years ago | (#19612897)

Flush your buffers and it won't matter if the program seg faults.

Alternatively, load the core dump into gdb (I prefer the printf's though).

Re:Skool... (1)

SatanicPuppy (611928) | more than 6 years ago | (#19612805)

Shrug. I learned on java, but it was java on the command line. Had to have a basic working knowledge of unix (Solaris) to do anything; the few projects I had in C used cc, rather than gcc, not that there is a whole lot of difference there.

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 more than having Eclipse or Studio One work them out for you automagically. Moving on later to work with apps like Tomcat...You've got to know how to manipulate the raw commands.

Re:Skool... (2, Informative)

Compholio (770966) | more than 6 years ago | (#19612331)

Professors are, IMHO, under obligation to ensure you get an education, not training.
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... (3, Funny)

i.r.id10t (595143) | more than 6 years ago | (#19612569)

Crap, I'm doing it wrong! I teach hte only Linux class here at the Comm College I work at (in another department) as an adjunct, adn I spend time with my students showing them how to use man pages, search google effectively, read the "How to Ask Smart Questions" doc by ESR, etc.... Any other tips on how I can change my ways?

Re:Skool... (1)

CaymanIslandCarpedie (868408) | more than 6 years ago | (#19612647)

Any other tips on how I can change my ways?

Yes, encourage your students to preview their comments before posting as to avoid lots of "hte" and "adn"s. ;-)

Re:Skool... (1, Insightful)

Anonymous Coward | more than 6 years ago | (#19612779)

He was probably just typing too fast, because he was so irritated by the dumbass parent post.

Re:Skool... (3, Insightful)

bfields (66644) | more than 6 years ago | (#19612545)

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:

  • Run linux, if you don't already! It's easier to understand and care about the software that you use daily.
  • Work on documentation for some project. Even a lot of the most succesful projects are desperately in need of better documentation, so they'll be really happy to have you. And it's an easy way to get to know the project--both the technical details and the various personalities and projects. You'll probably at least learn how to build it, contribute patches, etc.
  • Find a bug (if you've done the above, you've probably run across one or two). The ideal bug would be something easy to reproduce.
  • Or find some interesting new feature you really want, and work on that.
  • There's a lot of technical stuff to learn (C, bash, various other languages, autotools (yipes), gcc, the basic posix api's, etc., etc.)--don't try to figure it out all at once. Figure out what you need to for a given project.
  • Document what you learn as you go along, and spend some time helping out newbies--if nothing else, it's a good way to make sure you really understand things yourself.

Step #1, become familiar with the software (4, Informative)

pjwalen (546460) | more than 6 years ago | (#19612125)

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.

Scratch the itch (0)

Anonymous Coward | more than 6 years ago | (#19612153)

That's it basically. There's always politics and in-fighting on larger teams so if you're looking to join a F/OSS project for the sake of it you risk disillusionment. If you narrow the field to fixing something that benefits you, you've narrowed the field and increased the chance your patch will be good.

All said there's plenty of work that needs doing, if you take a bug from a project tracker the developers may guide you through the process. Some Mozilla maintainers can be really good at that.

Good luck.

2 things, including: that's not computer science (1)

Oo.et.oO (6530) | more than 6 years ago | (#19612159)

1: that's not computer science. that's software, software engineering (maybe), programming.
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 use gnu/linux, so you know what has to be "fixed" from your point of view. find an easy one. get the code, fix it and ask for help if need be and you have exhausted all the effort in obtaining your own answers.

good luck!

Re:2 things, including: that's not computer scienc (1)

vigmeister (1112659) | more than 6 years ago | (#19612497)

From the perspective of an Indian student, Computer Science is often confused with Software Engineering.

Computer Science is a B.Sc program that lasts 3 years in India. This encompasses roughly half of what they teach in BS programs in the US.

The B.Tech in Comp Science program is a 4 year program and teaches you Software Engineering with a heavy focus on programming. This is usually what almost everyone who gets into an engineering program wants to do and if you are in the top 10% of the applicants who got in, you are considered a fool if you pick something 'lower' like Mech. Engg :)


Re:2 things, including: that's not computer scienc (0)

Anonymous Coward | more than 6 years ago | (#19612515)

Computer Science is the Science of Computation.... We use computers and programming languge to experement in this science. You can be an expert Computer Sciencetist without programming (It does help though) Concepts such as Objects, Data Sctructures, Logic Flows, OS Therory... Are concepts learned from the science of computation.

Secondly I am glad Indea is teaching bad computer science. I already make good money when companies realize they get a better job done from american workers.

Something that interests you (2, Informative)

OriginalArlen (726444) | more than 6 years ago | (#19612161)

Find something that you find really interesting. That could be a specific kind of software (media players, CRM systems...), or particular functional areas - say, printing, bookmarks, inter-component messaging frameworks...) Or just a particular bit of software you get interested in because you find yourself using it a lot, and are *constantly* getting annoyed by that *one* missing option to use an LDAP backend, which would make it perfect for you... I've got involved (very very slightly) with a web browser, and some network security stuff, because I was using them anyway (or working in the general area in some way); I was also consciously looking out for some way to contribute something - you take the opportunities you find.

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 (3, Informative)

drinkypoo (153816) | more than 6 years ago | (#19612969)

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/ [mozilla.org], pick an interesting open bug, and go to it!

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.

Test it (0)

Anonymous Coward | more than 6 years ago | (#19612163)

You could try testing the program. Then when you find a bug, try to figure out where in the code it is and then fix it. Then submit the fix. It's a great fast way to learn the program and to contribute something unique.

My suggesion ... (-1, Troll)

Tim Ward (514198) | more than 6 years ago | (#19612183)

... believe your teachers.

They might, just might, see their job as giving you training that will best enable you to earn a living.

Re:My suggesion ... (0)

Anonymous Coward | more than 6 years ago | (#19612987)

Im sorry but are you kidding?

Following my teachers suggestions would have never lead me anywhere close to where i am now.
Not trying to offend anyone but 90% of the teachers i have ever met, didn't know much about what's happening in the real world reguarding what they teach.

Iv always heard , and never liked the saying : "those who cant do, teach" but unfortunatly it has been my experience in too many cases.

Get an education, not training. That means learn what things mean and not just how to reproduce them.

good luck

Re:My suggesion ... (0)

drinkypoo (153816) | more than 6 years ago | (#19613057)

... believe your teachers.

If you don't know the instructors in question, this is stunningly bad advice.

I have had both good and bad teachers/instructors/professors from the beginning of my school career until the present day. Sometimes they are idiots. Sometimes they have gone senile! My lady had a prof once that would literally pause in the middle of a sentence for as long as fifteen minutes before picking up where he left off. Many complained, but he had tenure and nothing was done.

Bottom line to me is that you should be learning a variety of languages. Learning one language prepares you to write programs in that language. Learning two languages prepares you to learn more languages. No one language will suit all needs or will be around for eternity.

Unless you plan to be in the industry just long enough for one trend to rise and fall, learning just one language is limiting and foolish. Computer science isn't about learning languages - they are a means to an end, which is to say, learning the disciplines of computer science which include mathematics, data structures, algorithms, blah blah blah. Mostly stuff I am lame about :) But I've had these discussions several times with people who are not lame in these areas. I grew up around a bunch of CS and related majors, many of whom went on to be successful and make a lot more money than me (born too late, blah blah blah)

Cisco (0, Flamebait)

spungo (729241) | more than 6 years ago | (#19612195)

I hear there's plenty of positions for open-source development at firms like TiVo, Cisco, et al... but they mostly involve bending over.

Start with documentation (1, Informative)

Anonymous Coward | more than 6 years ago | (#19612197)

Find a project you want to help with, and believe you can learn enough to help with.

Next teach yourself what things do, or get help from the devs, and take notes. Turn those notes into documentation, either as comments in the code, or readmes/howtos/etc. This has several advantages:

#1 - Documentation in most cases (not just open source) tends to be shoddy, this helps out a lot for the end users and the other devs.
#2 - You've learned a lot more about the project/software, and can be more help to the project at this point.

Pick an interest and run with it (3, Insightful)

igotmybfg (525391) | more than 6 years ago | (#19612199)

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.

find a project that you like (1)

Comsn (686413) | more than 6 years ago | (#19612227)

look at the wishlist, read the code and implement the wish.

then send patch.

thats all there is to 'joining' an open source project.

Just listen. (0)

Anonymous Coward | more than 6 years ago | (#19612245)

Join a mailing list or IRC channel and just listen, and read everything posted, for as long as you need. Eventually you will start to understand how the development process works, how patches are reviewed, what sorts of things are recurring problems that might need to get fixed, who to talk to about various aspects of the project, etc.\

Just Do It (1)

Doc Ruby (173196) | more than 6 years ago | (#19612265)

Pick one that looks worth completing, with people who look worth working with/for, and just contribute some code. Or test something and contribute your bug reports - or patches.

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 (4, Insightful)

Anonymous Coward | more than 6 years ago | (#19612271)

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

Start with documentation (1, Informative)

Anonymous Coward | more than 6 years ago | (#19612281)

Find a project that needs developer documentation. That could include documenting build/test processes. That'll force you to read lots of code and get a feel for things. It sounds like you don't have much experience with the tools and processes that do the real work - if you've only worked with MS tools, much of that stuff is hidden behind pretty interfaces. Start by learning how makefiles work; learn a little bit of shell programming; try to learn a bit about the various tools commonly used in makefiles, e.g. sed, grep, etc. You should be able to pick up on a bunch of the jargon as you proceed; the Jargon File can be helpful.

Caveat: Java projects tend to use different build techniques; Python has it's own secret handshakes, etc. So once you learn the basics you'll need to pick a path to follow.

IOW, I wouldn't worry about making technical contributions until you've acquired a certain level of skill with the tools. Even bug-hunting can involve a lot of technical expertise.

I did this. (2, Insightful)

Aladrin (926209) | more than 6 years ago | (#19612293)

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.

Join mine (0)

Bluesman (104513) | more than 6 years ago | (#19612305)

Link's up above. We could use an Indian translation, and I'd be happy to help you along as time would allow, although my time is limited lately. You'd also have the opportunity to learn C++, C, BASIC, Lisp, Flex/Bison, and Qt, as we use them all, and you'd get pretty good at writing a compiler and interpreter.

Patches. (1)

serviscope_minor (664417) | more than 6 years ago | (#19612307)

It depends on the projects. I have made significant contributions to one and not joined in any official capacity. I hand out on the mailing list and exchange patches with other users and the developers.

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 contribution, by coding up something big for the project.

In the end, its hit and miss whether you join, and it often doesn't matter. You can still keep contributing either way.

That said, since you have only limited experience with C and C++, you will have to improve your skills (by writing patches for instance), before you will be good enough to make a contribution which is big enough.

In case you haven't realised my message yet, "patches" is the way to go.

Finally, when I did start getting invitations to join, the developers were all helpful with my n00bishness about version control, regular builds and so on.

Find an itch (4, Insightful)

linuxwrangler (582055) | more than 6 years ago | (#19612313)

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.

Re:Find an itch (0)

Phil06 (877749) | more than 6 years ago | (#19612843)

Pick something with a cool name. Only look for cutting edge type projects, blow off the device driver and mundane bug fix stuff. Better yet, grab some random buzzwords and start you own project, like Ajax on Rails.

Docs (0)

Anonymous Coward | more than 6 years ago | (#19612329)

I know that there are a lot of projects that are lacking in documentation. If you're not ready to contribute code, contributing to the documentation efforts could still be a worthwhile endevour.

passion and community (0)

Anonymous Coward | more than 6 years ago | (#19612349)

I would suggest looking into how the community interacts, and also what you feel passionate about.

For example, Joel de Guzman, of Spirit++/Boost fame, has engendered a community which is generally kind, considerate, helpful, *and* highly skilled programmers. In 4+ years of dealings with the Spirit++ community I think I've only seen one RTFM posts. There are other groups I have had the displeasure of reading those kinds of comments on a weekly basis, and they still do not answer the questions or give sufficient pointers...

Last, follow your bliss. The only way you are really going to learn is to do. The more you do, the better you can become. When you love the programming it is not work but a joy, and you will have no regrets in the end.

Find a project you're interested in (1)

Dracos (107777) | more than 6 years ago | (#19612373)

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 up being as rewarding.

In short, all you have to do is participate.

Also, almost all projects have staff needs beyond coders. If anyone reading this thread has ever hesitated to join a project because you don't write code, think again. Documentation, testing, interface design, infrastructure maintenance, graphics, even marketing, are all skills that get sidelined/minimalized sometimes. If you can do something, do it well, and make the project better, everyone benefits.

(Shameless plug in sig)

an easy place to start (2, Informative)

Anonymous Coward | more than 6 years ago | (#19612377)

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.

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 [kent.ac.uk].
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/autob ook.html, http://autotoolset.sourceforge.net/tutorial.html [sourceforge.net], http://www.amazon.com/Autoconf-Automake-Libtool-Ga ry-Vaughan/dp/1578701902 [amazon.com], http://www.st-andrews.ac.uk/~iam/docs/tutorial.htm l%5D [st-andrews.ac.uk].
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.

Re:an easy place to start (2, Insightful)

brteag00 (987351) | more than 6 years ago | (#19612937)

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.

I remember the first time I had to extract a .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!

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.

Google Summer of Code (3, Informative)

jestill (656510) | more than 6 years ago | (#19612397)

I am doing a Google Summer of Code [google.com] 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.

Jargon (1)

makapuf (412290) | more than 6 years ago | (#19612403)

Don't let this disturb you, the jargon is quite simple and you'll get accustomed to it. Besides, there's always google and let me point you to a famous site (mostly folklore/trivia, but it might light a bulb sometimes in reading mailing lists : the jargon file by eric s raymond : glossary is there : http://catb.org/esr/jargon/html/go01.html [catb.org] )

Something that interests you (1)

rlp (11898) | more than 6 years ago | (#19612423)

As a bunch of people said, create an account and get on source forge. You can work as part of a team OR you can develop your own project. If you choose the latter, pick something that interests you. Think of an application that you'd like to have. A tool that you could use. A software library that you wish was available. Then develop it and put it on source forge. You'll learn a lot and it will be a lot more enjoyable if it's something that you have a real interest in.

Re:Something that interests you (1)

kie (30381) | more than 6 years ago | (#19612577)

For a small - medium size project here is one idea:

The equivalent of DTXMania (a simulators to play Drummania) for Linux.
http://www.gdamania.net/ [gdamania.net]

I don't think that there is any linux equivalent and I've been unable to get
dtxmania or the other simulators to work with wine on debian etch.

Start at a Linux Forum (0)

Anonymous Coward | more than 6 years ago | (#19612425)

Not all open source projects are Linux related, but I think some of the lowest learning curves to getting into open source development and learning the jargon are found on Linux forums such as the Gentoo Forums [gentoo.org] or the Ubuntu Forums [ubuntuforums.org]. You don't have to deal with mailing list etiquitte and you don't have to learn how IRC works, but you can get exposed to a lot of open source projects, particularly the popular ones, which tend to have better documentation and are more newbie friendly.

Learning about OSS projects (2, Informative)

twasserman (878174) | more than 6 years ago | (#19612487)

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 [producingoss.com].

Start with what you know, and with what you like (2, Insightful)

j1mc (912703) | more than 6 years ago | (#19612491)

If you're using a free or open source piece of software that's really the place to start - you shouldn't have to google very much to find out information about a project that you could join up with, just look at what you use. Look for something that wouldn't be too overwhelming for you to start out with.

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. :)

Sadly... (4, Informative)

jd (1658) | more than 6 years ago | (#19612525)

I cannot recommend a good place for your lecturers and professors to undergo brain transplants. First off, any lecturer that recommends a specific language is violating the first rule of computing - EVERYTHING is transitory, nothing lasts forever. Their lecturers probably swore by Cobol or PL/I. Only a total idiot tells students that they should adhere to a solution rather than a methodology. Solutions come and go, but the same methodology will apply to them all and make learning the specifics a piece of cake.

(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.

Step-by-step guide (0)

Anonymous Coward | more than 6 years ago | (#19612571)

Here are some steps you could take:

1. decide what language(s) you want to use (C++, Ruby, etc.)
2. decide what license you want to support (GPL, BSD, MIT, etc.)
3. decide what platform you want to support (Linux Only, Windows Only, Cross-Platform, etc.)
4. decide if you prefer server-side or client-side programming (web server vs GUI, for example)
5. decide if you prefer working in large teams or small teams
6. use the above criteria to filter out projects in places like sf.net, tigris.org, CPAN.org, etc.
7. check the mailing lists of potential projects to see if the communication style (or maturity) of developers match yours
8. initiate contact by letting them know your interest and how exactly you'd like to contribute

There are numerous projects in need of help. Some of them, like wxRuby [rubyforge.org], are at the intersection of fast-rising language (Ruby) and fast-rising GUI (wxWidgets) but could use more help.

I prefer working on the real problems. (1)

John Sokol (109591) | more than 6 years ago | (#19612651)

There are many sugestions posted, here. But I have always taken the approach that we don't need more of the same.
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 planning to start working on in a serious way.

Find a real problem that pushes the boundries of technology, or solves real world needs and work on it. It helps if it's something that interests you or directly effects you also.
SPAM has been a irritation for me personally for many years.

I was also thinking maybe someone could start a project to slowly replace each sub-components in Q-Mail one at a time until there would be an entirely new work alike package that would be under a much better software liscence(BSD/GPLx) and could be better maintained.

I'd love it if someone would join my afterburner web server project also on sourceforge and update that code, and make it more Linux friendly.

The single threaded server engine in there has made an excellent video server and chat server for me in the past. I'd like to make a simple yet fast mail server using it also. Or maybe some gaming servers. RTP/RTSP video server would also be a great addition, all the video on cell phone people would love something better then Darwin Streaming server that is resource heavy.

I also have some New Operating system concepts I'd love to see coded up, but I had resigned myself to only work on profitable ventures since I an tired of being strapped for cash all the time. But if anyone want's to carry that torch, i'd be happy to point out some amazing ideas.

Like Multitouch, multi HID/ Mice and users on one screen.
No OS supports more then one focus and one pointing device at a time. Both Windows and X are very deeply hardwired internally for just one cursor/pointer. Why? Why can't I connect two keyboard and two mice and have color code each pair so two users share a desktop? Think about this one, there are some rather large ramifications for that.

Re:I prefer working on the real problems. (1)

alphamugwump (918799) | more than 6 years ago | (#19612929)

Why can't I connect two keyboard and two mice and have color code each pair so two users share a desktop?

Why would you want to? I could see it being useful just to give yourself more input devices for gaming or 3D modeling, but what good would two mouse pointers be? Unless you're ambidexterous, of course. Sure, you could have a friend use the computer at the same time, but at that point, why not just set up a second terminal?

ECK (0, Troll)

Billly Gates (198444) | more than 6 years ago | (#19612659)

No you can not write any reasonable piece of software for business in 24 hours??

Are your lecturers or professors professional programmers? Don't they have any experience in the real world? Or did they learn how to teach by getting their cs degree in mathmatics and read one "learn vb.net in 24 hours!" books that somehow makes them an expert to teach it?

3 months is what is used here in the US for quality projects written in C++ using business objects or vb.

I learned java from an instructor who worked at Bell Labs during the 80's. He actually learned OOP from Bourne Strastop. Basically it takes awhile to do any real Object Oriented work and specifying requirements before any real code is written. Not bad from a community college.

Any solution done in 24 hours is simplistic and very very poorly written and does not meet requirements for the project.

Documentation (1)

halcyon1234 (834388) | more than 6 years ago | (#19612675)

One thing many open source projects are lacking is good, solid documentation. There's a thousand minds working on the code, but not all of them know what everything does. Documentation would help, especially when it comes to answering some of the more common questions.

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 some way to contribute.

Author already knows how to find a damn project! (0)

Anonymous Coward | more than 6 years ago | (#19612707)

Almost everyone is telling the author WHERE to go and find a project to join but the author wants to know HOW to join a project. The author is wondering what (if any) barriers to entry there are, what assumed requirements typically exist, whether there is a formal structure for open source development teams, etc... Simply pointing the author to Sourceforge is about as useful as saying RTFM. By the way, if the answer is RTFM, at least point him or her to the damn manual. I think it's important to not brush off someone so eager to help with a mere URL and assume that they "obviously" know how an open source project is structured internally.

I am also curious to know the answer to the author's question, so hopefully these questions will actually be addressed. I realize that in most cases, the answer to the above questions probably begin with "it depends" but those with experience can at the very least relate to us what they find to be typical or how they've organized their teams and recruited members in the past.

I commend the author for being willing to contribute to the open source movement. Considering this topic has about 40 responses that don't even begin to address the actual questions, best of luck to the author in figuring out how to properly get started.

Producing Open Source Software, by Karl Fogel (1)

mmurphy000 (556983) | more than 6 years ago | (#19612719)

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.

The Self-Support Mentality (1)

cylence (129937) | more than 6 years ago | (#19612741)

A terrific way to get involved in the community is to simply take on the attitude that, whenever you encounter a problem or annoyance in software that you use and care about, you will take responsibility for fixing it. This is, in fact, how I have recently gotten involved in several FLOSS projects in the last year and a half.

Every time you encounter a bug, feel free to report it, but also, investigate it. Is it crashing? Whip out the debugger (and recompile from source, if necessary, to get debugging symbols). Some annoyance? Look at the code logic, and write up a patch, including it with your report to the developers.

This is not only a great way to get involved in FLOSS projects; it's also a terrific way to learn about the software you use, and further your education as a software developer.

It's easy..... (1)

Stumbles (602007) | more than 6 years ago | (#19612755)

Find a project you like, grab the source code, compile it, play with it, find bugs, report bugs, offer a patch if your capable, rinse and repeat. It's really that simple. And who knows, at some point the project leader might ask if you want to be a developer for them.

webinject (1)

mu51c10rd (187182) | more than 6 years ago | (#19612821)

The Webinject [webinject.org] tool is popular among those using Nagios for testing web functionality. The owner has not done any upgrades in quite some time. Might be a worthwhile to look at working on.

My advice as the head of two projects (1)

laffer1 (701823) | more than 6 years ago | (#19612961)

The answer to your question depends on the project. Well established projects tend to have rules to gain access. FreeBSD developers often have to submit a few patches, get a mentor and go through two years of hell to get in. It really depends in that case on what you want to do. Joining ports is easier than working on the kernel. The Linux kernel development effort has a lot of structure so it will take time to get noticed.

Smaller projects, new projects, or projects with few developers are much more likely to take you in right away. For instance, with MidnightBSD I usually just want to see 1 patch that looks reasonable. With Just Journal, I'd take anyone who wants to work on it just like that.

Some projects require that you get friendly with other developers. I work on a gaming mod called FalkconET. I started by offering to host their website and moved up to working on the Mac port. I knew two of the guys from playing Enemy Territory.

Just be nice and patient. With my projects, I like to get an email from interested developers. Also, be willing to learn the "jargon" and a version control system. Most projects use Subversion (SVN) or CVS.

How to contribute as a non-hacker (1)

houghi (78078) | more than 6 years ago | (#19612989)

Mny people are not hackers or programers and give as excuse that they are non-technical and thus can not contribute. However there are many ways to contribute.

* Make a level for your favorite game and contribute it back to the maker
* Make a skin for you favorite program that uses skins
* Make Icons, wallpapers or any art for whatever you desire
* Translate website and manuals to your language
* Beta test software as a simple user
* Burn distributions for those who can't
* Have your bittorent upload your favorite distribution all the time
* Tell the maker of smaller programs that you use it, or even a simple thank you

The last will encourage the maker to keep maintining the program. Not all help needs to be directly, or even technical. Just telling people you use OSS is enough. If enough people tell this, at some point it will catch on. It is word of mouth.

Choosing the right school (1)

OhRock (617808) | more than 6 years ago | (#19613039)

I know this might not apply to the question's originator, but factoring the following in your school choice is not that difficult.

Find out what is the CS department running in their servers and if the have a Unix/Linux lab, if they have subjects where gcc is used, what do the school do for the OS/Architecture classes.

Also, visit the school's LUG's and/or ACM's website and mailing lists. See what they are doing, ask them about it.

Find out if the professors are doing research on areas that overlap with FOSS, as they will be likely to use it then.

Ultimately, enroll in a school that has a Unix tradition - out of Chicago UIC is the only one.

I took some of this things in account when looking for school, and I end up enrolling in UIC as I also wanted to be close or in a big city. I could not be happier with my choice, all the development is done in python/java for 100 level classes, JAVA running in linux for the 200 levels, and then gcc for the anything that requieres C/C++. Most everything is done using UNIX/Linux. On top our ACM is very Linux friendly, and both LUG and ACM do lots of really interesting things in the FOSS area.

Roberto "ohrock" Serrano
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account