Slashdot Mirror
Good Ways To Join an Open Source Project?
Tathagata asks: "I'm a student, on my final year in a college in India, and I have been using GNU/Linux for quite sometime now. Though I'm from a Computer Science background, getting into a project that involves serious programming was not possible, as people (read teachers) run away if you utter the word 'Linux'. They are generally not bothered about mentoring someone on an exciting project, and they would suggest you to get settled with Visual Basic, .NET, — and would prefer a 24 hour solution when it comes to programming. So, my programming endeavors have remained limited to writing few lines of C/C++, or Java. For last few days, I've been googling, and trying to read how to join an existing Open Source project." What suggestions would you pass along to someone who is willing to join his first Open Source effort?
Most of the things I've read suggest that a good place to start is by submitting patches, fixing bugs, becoming package maintainer — but most are overloaded with jargon like upstream/downstream, nightly builds, and so forth. Additionally, how does joining the mailing list, or the IRC channel help when you don't even understand the slang, not to mention the intricacies of the technical discussion? It 's quite an overwhelming world to step in. Could you suggest a road map, links to essential tools or a few projects, for people like me, who would want to improve their skills by contributing FOSS?"
and do one of the items, test the patch, and submit it. Then repeat.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
there's plenty of positions for open source developers there...
~/.sig: No such file or directory
i think the advise you've received so far is spot on. first pick a couple projects you're interested and have a vested interest (i.e. you actually use the software on a daily/semi-regular basis) and join the forums. i wouldn't worry about the slang right off the bat, most of that will come with time and participation. join the discussions with suggestions and help if you can provide it, or ask questions regarding configurations, installation, etc if you're a new comer.
regarding posting in discussion groups:
if your asking questions, be thorough in you description of problems you're experiencing, be ready to provide logs and details regarding your system and installation, and be courteous. nothing worse than a call for help on a forum: "i'n a new user, don't know what i'm doing, but i need help. and if you can't help me this software sucks!" i've seen many calls for help that go unanswered because of the issue listed above.
if you are offering help and/or suggestions, be thorough in your answers, don't be insulting("RTFM newb!"), and give realistic options. i've seen responses that are overly terse in tone that makes the response seem like it's an annoyance or statements that have an air of arrogance that have turned users away from FOSS projects.
the point of joining the discussion groups is to see if there is a fit for your skills. is the delevopment team in need of your abilities, or do they have too many contributors? is the process of contribution thru an individual or comittee? is the project in active development, or has it been obsfucated by another project? only way to answer some of these questions is to join and read the discussions. then you can make a better decision as to which project to join.
figure out what you want to join first before deciding what you want to do with the project. if your commited to the project, theres a way to find your niche.
three can keep a secret, if two are dead - benjamin franklin
Sourceforge has a help wanted page for project owners to advertise for additonal project members, or go to google code and browse there to see if anything catches your eye.
Reality is that which, when we cease to believe in it, still exists. - Philip K Dick
Two words: Source. Forge. As in Sourceforge.net, the birthplace of countless OSS projects.
End of story. Go there, find something that's interesting, and if it's no longer in development, take it over or fork it, and if it's in development, see if you can join the team (if they need help, there is usually a "help wanted" link on the main project page). Most groups need help, and if you're competent, they'll be glad to have you.
If you're moving into a big team, be polite. You're a young programmer, and lots of young programmers have a lot of hubris. If you can't work with the people there (and this happens a lot; I once took a Java project, and simply updated it as it stood to get rid of depricated functions, almost no other changes, and I got flamed like you can't even imagine by the lone devloper who hadn't even released an update for 2 years) move on and do something else. There are so many projects, there is bound to be something awesome out there that you want to be a part of.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Submit it. Read the feedback you get (if you get any). Write some more code. Repeat. That is all.
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.
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.
Just start your own! Then you can do whatever the hell you want!
submit patches! I fyou can do it, just do it!
-P
http://halo.willisburg.org/
Check out the project, and drop us a line if it interests you.... we can always use another hand or two on the project.
-Willis
"but most are overloaded with jargon like upstream/downstream, nightly builds, and so forth"
Um, this is pretty basic language used on real-world projects. You need to learn the "jargon" as well as actual programming. That's just the way it is. If this scares you, you may want to consider another line of work.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Perhaps, when you are finished with your bachelors at this school, you should consider a school with better professors for your masters.
.net, VB, etc might be where all the paying jobs are but this isn't going to last. Eventually something else will come along (even from Microsoft) that will make these skills obsolete. Professors are, IMHO, under obligation to ensure you get an education, not training.
This is such a shame when so-called "professors" actually hinder your learning experience. I'm sure they think they have your best interests in mind. Right NOW
The advice you have gotten thus far is good. To get your foot in the door, I would suggest you find a project you find personally appealing in the open-source community. Become familiar with its use and operation. The next step would be to become familiar with CVS or Subversion (SVN). Seeing as you are coming from a more Microsoft background you will be familiar with source safe (most likely), CVS and subversion are simply open source, source control system. You will want to become familiar with their basic use.
Once you have accomplished those basic tasks, download the source of your new found project to your PC with your source control client (each project will have these procedures documented on their web pages, somewhere). Then become familiar with their architecture. Read through the routines, and their data structures. Once you have a basic understanding of the projects source, you will want to join mailing lists, look at their bug tracking software, and forums. Track down bugs in the projects software and solve them. Using your knowledge of CVS and/or SVN (and hopefully the diff command), you will be able to produce usable patches, or revisions to code that you can submit to primary developers.
Once you become a valued member of the bug tracking and eliminating community, you may want to begin tackling the projects TODO list for new releases. Adding new features to the product. The rest of the terms you bring up (and many that you didn't) will become more familiar to you as you become more involved in a projects build process.
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.
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!
Or some other type of abstract class of programming task. Writing documentation is also a good way to learn - there's always a need for good docs, and you have to get to know the software really well to write them.
Pull the current source. Take a poke around. Grep for comments. Look at the changelogs. Look at what's being worked on, where the problems are, how much activity is going on, how many contributors there have been. Scratch your itch!
And if you can't find anything you actually *want* to do, why, then you can't do better than get some good experience on the wonderful Mozilla projects! Head over to https://bugzilla.mozilla.org/, pick an interesting open bug, and go to it!
Good luck, and have the appropriate amount of fun :)
Everything I needed to know about life, I learnt from Blake's Seven
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.
I hear there's plenty of positions for open-source development at firms like TiVo, Cisco, et al... but they mostly involve bending over.
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.
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.
look at the wishlist, read the code and implement the wish.
then send patch.
thats all there is to 'joining' an open source project.
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.\
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.
--
make install -not war
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
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.
Not long ago, I did this. I didn't set out to 'join an open source project', but that's what ended up happening.
I found a piece of software I was -very- interested in, felt I could help the team, and started talking to them. It wasn't long before I felt I had something to contribute, and they gave me SVN access. I did, they really liked it, and I was part of the team.
The key is that you have to -really- want to be a part of -that project-. If the goal is simply 'join any project' then you are going to hate it and the team will probably get quite upset with you for either contributing crap or not contributing much at all, and simply causing ruckus on the forums.
Again, don't join a project unless you really care about the project itself.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
If moderation could change anything, it would be illegal.
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.
SJW n. One who posts facts.
First, find "an itch to scratch". What excites you? Databases? Web development? Audio processing? Image editing? The first step is to find a project that you would be interested in using.
:)
Second, read, read, read. Lurk in the mailing lists, IRC, etc. Get a feel for how the project is maintained and the tone of the developers and users. Don't be one of those who shows up new on the scene and suggests ideas that have been repeatedly rejected for the project or patches that break things or show no understanding of the project design and goals. Try to determine if you would "fit in" with the group.
Third, use the program and dig through the code till you have a good understanding of it. You will learn a lot...including whether or not you want to find a different project.
Fourth, if you have found that exciting project and the code or people haven't scared you away, find out where you can contribute. It's not just about coding. Large projects have people contributing to code, documentation, public-relations, mail-list management, answering questions on the mailing lists, and so on. If you are really focused on programming, peruse the bug list and find some solutions. You will build your reputation by repeated posting of quality patches.
Fifth, be humble. There's nothing wrong with "I'm new to this project and have been digging through and learning the code. I think this patch might fix bug #1138? Is there something I have overlooked?". It's far better than "Hey guys - here's how to fix that dumb bug..." You could be right, but it's more likely you will find 15 developers jumping into the discussion to tell you what you forgot to take into account with your stupid suggestion. That will set your reputation way back.
On the other hand, if you are just looking for something to jump into so it can go on your resume, forget it. You won't have the interest and passion to stick around long enough to be useful.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
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.
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.
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)
is a Best Buy or a Barnes 'n Noble. you're going to need to know the tools and procedures of open source development before you can get anything done or changes submitted.
D .b ook.html, http://autotoolset.sourceforge.net/tutorial.html, http://www.amazon.com/Autoconf-Automake-Libtool-Ga ry-Vaughan/dp/1578701902, http://www.st-andrews.ac.uk/~iam/docs/tutorial.htm l%5D.
0. Install an Open Source operating system with development tools, such as [Net,Free,Open]BSD or Linux
1. Learn CVS [http://cvsbook.red-bean.com/, http://www.cs.kent.ac.uk/systems/cvs-howto.html%5
2. Learn the basics of the GNU C Compiler [http://www.faqs.org/docs/learnc/].
3. Learn Automake, Autoconf and Libtool [http://sources.redhat.com/autobook/autobook/auto
4. Download a tarball of some source code and compile it, learn how to edit Makefiles, etc.
5. Check out the source code of the same application from CVS, mess around with it.
I am doing a Google Summer of Code project this summer. I have found it a really great way to join an existing Open Source project. This may be too late for you since you are in your last year of school, but other folks should check it out.
"Asleep at the switch? I wasn't asleep, I was drunk!" -- Homer
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 )
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.
[Insert pithy quote here]
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 or the Ubuntu Forums. 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.
The liquid that comes out of a landfill is called leachate. Now that's a good word to know.
It's not wasting time, I'm educating myself.
Lots of great suggestions already. You might also want to read a good book on best practices for open source development projects. Karl Fogel's "Producing Open Source Software" is excellent and available in print form or free online here.
Once you have that, the best way to find out about what's going on from there is to join the developer mailing list for the project, and to check out their IRC channel. Usually it's best to lurk for a bit before just jumping in stating that you'll do X, Y, and Z for them - that way you get a sense for the current status of the project and what they need.
A couple of other tips that might be helpful:
:)
- Take a look at the mailing list archives from the past few months and look for threads that interest you.
- Take some time to report a few bugs in the program, or to try and triage a bug that someone else has reported. - Join an IRC "meeting" of a group that you're interested in to see what they are doing and what their goals are
As a rule of thumb, most projects will be glad to have you if you're polite and actually do some work. If you are doing some work, and are polite, and they aren't happy to have you . . . Feel free to move elsewhere.
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
Cheers!
Atheist: Buddhist in a Prius
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.
(Hell, anyone who lived through the .com fiasco saw what happened to Java programmers immediately before and immediately after. Java's a good solution to a number of problems, but the market became glutted when the bubble burst, making it a totally unmarketable language in the immediate aftermath.)
People have noted Sourceforge, and that is definitely a good place to go. If you're only "allowed" to add a few lines, then I'd also recommend investigating Unmaintained Free Software for projects that probably need relatively little work but which aren't receiving any attention at all. One of the benefits of going for an orphaned project is that you have much more freedom on where to take things. You are also, by definition, not subject to jargon on chat groups or mailing lists as there aren't any. It also gives you a chance to test the full range of computer science skills - analyzing, designing, implementing and testing - in a way a current project generally doesn't allow for. You'd be exercising one whole revolution of the software lifecycle.
The benefits of an existing project cannot be overstated, though. If there are existing coders, there are more pairs of eyes looking at what you're doing. There are people to ask for help/advice. You're less likely to be overwhelmed. There's also a touch more "street credibility" attached to being associated with a project that's better known, which won't hurt your employment prospects in the least.
If this is a final-year project, they'd better damn well want something non-trivial or I will most certainly have stern words with them. Not that my words are worth anything, I just write a lot of them. A half-way point between the full lifecycle (which makes for a wonderful final-year project report, which is ultimately all that matters) and working on an existing project is to pick something that accepts plug-ins or modules of some kind. There may be abandoned projects of that kind you can borrow from, but it's also stuff that's just simple enough that writing from scratch isn't going to kill you.
Hope that gives you some ideas.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
And do it! For instance, improve a feature of a game that you like. Or implement a missing feature that you've been hankering after. I think this is a great way to get started, because it gives you the satisfaction of reward.
For example, I like to use the free software Theora video codec to rip DVDs under Linux. It used to support SIMD-acceleration, making it encode movies about twice as fast... but only on 32-bit x86. Well, I had just gotten a new AMD64 box, and wanted it to rip movies faster. So I checked out the Theora code, refreshed my knowledge of assembly language, and within a couple days I had a working MMX/SSE-accelerated encoder. It was a very satisfying feeling!! And that code went into the mainline Theora release a couple months later (1.0alpha6).
My bicyles
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, are at the intersection of fast-rising language (Ruby) and fast-rising GUI (wxWidgets) but could use more help.
www.genezzo.com
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.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
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.
http://saveie6.com/
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.
UTF-8: There and Back Again
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
Ideal "candidate"
To learn more, contact the project admin listed here.
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.
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/ 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 Busy Coder's Guide to Android Development
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.
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.
My karma is not a Chameleon.
Open source projects are always looking for help, this is from ubuntu open week IRC logs with explanation of various things Ubuntu does and how you can help,a lot of questions for beginners are answered https://wiki.ubuntu.com/UbuntuOpenWeek
I m ean google code project hosting.
Or, um, you could look at my project, I'm in need of the helps..
http://code.google.com/p/nmod/
Reality is that which, when we cease to believe in it, still exists. - Philip K Dick
The Webinject 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.
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.
MidnightBSD: The BSD for Everyone
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
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.
Don't fight for your country, if your country does not fight for you.
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
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)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
This is worth reading:
http://producingoss.com/
Hi --
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.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
Frankly, Google should scrap their Summer of Code and have a Summer of Documentation. There's already too much badly documented (or undocumented) code.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Yes, I've seen all your supposed facts and evidence that open source software helps people learn to program and provides many more people with the tools they need. Unfortunately, I don't go by facts and evidence. I go by my gut.
My gut tells me that free software is just wrong, and that if you don't get paid for your work, you just might be a communist. So please don't submit patches and support this drain on our economy. Go out and *buy* the software you need. That way you'll be able to support the country and economy again next time an upgrade or new version comes out. My gut and thousands of democracy-loving programmers thank you.
Fixing some WoW mods?
Tons of Lau, EASY programming, plenty of defineable todo's, and a comunity which will actually use your product!
How much is your data worth? Back it up now.
Are ya interested in D&D?
tasks(723) drafts(105) languages(484) examples(29106)
It's called "swarf!" http://en.wikipedia.org/wiki/Swarf
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.
All this is fine but I (BTech, CS student from India) hardly know about the Linux kernel or stuff like that. Those things are never taught in deep here. All we learn is basic languages and that too in the most bookish of all ways possible. Can you please suggest some way to learn more about the kernel, etc???
One of my co-workers is Indian and he consently bitches about the lack of native language support in software. I'd say start by seeing if your favorite piece of software has support for your local native language. If not, go about modifying the software to properly use language tags so it does.
Yes Francis, the world has gone crazy.
The first step is to join an open source community. Lurk for a while, use the software, see what works and what doesn't.
Then start getting active in the community. Give support, feedback, and the like.
In the mean time, if you can fix bugs, great. If not, just getting involved may help you get a feel whether this is the right community and project for you.
Oh, and decide what you want to accomplish. Do you want to get your name out there? Earn income by coding? Just have fun? This will determine what sorts of projects you want to get involved in. (I prefer to do all three.) If you want to earn income as a coder, and are willing to program in PL/PGSQL and Perl, I would recommend the LedgerSMB project primarily because we seem to have a chronic shortage of coders interested in doing commercial work. On the other hand, if business process problems aren't interesting and hard-core computer science is, maybe some of the compiler projects or kernels, or something new altogether.
LedgerSMB: Open source Accounting/ERP
Most open source offerings are tools (ie. databases, operating systems, etc.) and there is room for only so many tools, but there is a need for as many specialized business applications as there are types of business and it is possible to make money on those because businesses will pay for solutions, not tools. The Apache Open for Business Project (http://ofbiz.apache.org/) is truly disruptive technology in this regard. It is a brilliantly designed framework for developing apps and it comes out-of-the-box with working enterprise level software. It takes a while to learn the environment, but it is so rich that it makes knocking off vertical apps a breeze once you know it. It is Java based, but also has a strong XML-based scripting environment that makes it possible for domain experts, not just Java gurus, to develop apps. Developing an application for a small business and making money on it helps both you and the small business. I think this model has the potential for delivering much more on the promise of open source than anything that is out there.
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 direction. Different projects do things in different ways. Many use one of many different source version control systems. Some don't use any at all. Larger projects have dedicated servers and recompile everything from the latest check-ins (new source added in) every night or so. Some just do it all manually when someone feels like it. My own projects are written by myself and have none of that fancy stuff.
now we need to go OSS in diesel cars
For the problem of "geek slang" you mention, a few tips which can help:
/. and forums, but also some literature...
- Google define: Type "define:" followed by what you search in the Google search bar. For example: nightly build
- Many of the above will lead to Wikipedia, which is a good resource for anything geeky (and other stuff also)
- Sometimes, the Urban Dictionary can help
- In forums or mailing lists, when you come across an unknown term, just ask.
- Don't only read
Already do this. Hell, the Atari 2600 did this 30 years ago.
Next!
I am very small, utmostly microscopic.
Why would he need "dynamic programming" out here in the real world? Care to explain? Why does he even need to master common algorithms? Trees, sorting - all of this is already done twenty times over. This is not to say that strong background in algorithms doesn't help, it does. This is to say that 90% of programming has nothing to do with computer science, and as a beginner, that's the 90% he'll be doing.
Then most of what you're learning in school, will probably be worthless in the real-world (as is a lot of the times the case), unless your idea of 'real world' involves working as a .NET developer, in which case, I feel for you. =p
IRC, mailing lists, and LUG/SIGs are a great way to get familiar with things, especially IRC, since it's a real-time international discussion.
Find some applications with bugs. Fix the bugs and submit them to the project's BDOL.
If I may suggest, one project that I am particularly fond of, and would like to see it further developed, is multi-aterm.
the only permanence in existence, is the impermanence of existence.
There are a number of programs and utilities out there that are currently command line only. I have been thinking about working on a GUI front end for one of these as one of my next projects. Seems to me that this could be easier than learning the internals of a given existing project. This way you can slowly implement functionality using the framework of your choice.
www.DIYTVAntennas.com
It's unfortunate you're in your last year. College students are typically the most valuable contributors to a project because they have fewer hard demands on their time like work, spouses, young children, etc. Also, upon graduation, you will often find that the leaders in the project are more than happy to write you references after you graduate - I did on a number of occasions.
.signature is before you start sending mail out. Be sure that you turn it off.
(In no particular order)
DO pick a project that interests you.
DO lurk for awhile on the relevant mailing lists so that you get an idea of who the leaders are, what the pressing issues are. You'll also be able to learn that way how contributions are expected to be made. It is also a good idea to read archives of older postings, understanding history is very important and often ignored.
DO be aware of how the project is licensed. Some projects require copyright assignment and will not touch any work you do until you perform copyright assignment.
DO consider doing documentation patches first. Bug fixes are cool, but it is only the very rare person who tackles documentation. There never tends to be an oversupply of people of doing documentation.
DO get involved doing build testing especially if you have access to non-standard or rare hardware.
DO learn what a
DO read any relevant FAQs before offering any suggestions.
DO NOT repeat a suggestion that has been turned down repeatedly (ex. why can't we replace the lisp engine with Perl?, why can't we have a stable Linux 3.0, etc.)
DO NOT get angry at someone in public.
DO NOT contribute to off-topic threads, you should know what these are, you've read the FAQ, right?
DO practice your English writing skills, this will help you in your career too.
DO NOT be disappointed when your patches get rejected, learn from your mistakes and keep trying.
DO try to answer questions more than you ask them, when your answers are correct you will earn a lot of reputation.
DO be sure that you're having fun.
Fedora. Fast-paced perhaps but plenty to learn and contribute.
Open source organizations don't care what you do as long as you use the right lingo and slang.
Give my regards to my job, asshole.
What's amazing is that Linux is so much powerful than the toy OS one would have to classify say "Windows" as. Linux is much better designed, more secure, has faster development, and will give more knowledge to you than any other OS. Windows is sort of toyish. It has been that way from the first time I used it back in 1984 (I think that was when I saw it first). I ran it off one floppy drive and had to swap out floppies to use it as I went. It was incredibly slow, almost incompetently slow.
I've watched Window from then and watched the industry leaders and trend setters. If you carefully follow what has happened in the industry you'll note that Windows really was quite rinky dink for a long time. Only under Windows 95 did it start to flesh out, but there was a lot of toyishness to it then too. Unfortunately that toyishness is still there.
I've watched the Linux community now for the past 4 years and I have been very impressed at the speed of their advancement and the sheer quality of the work on the kernel and interface. Granted there are still some toyish aspects to it but my educated opinion tells me that it has exceeded that of Windows.
Vista, today, isn't much more than a bigger pigish toy with a bit of lipstick. I have no desire to see anyone waste their time on a closed source environment that is only documented as well as Microsoft permits it to be, and only permits it to the extent that it doesn't allow another company to produce a product that competes with its own.
I think generally, and mostly overall, few would consider Linux to be a toy, at least moreso than Windows is. Even the term Windows is toyish. Vista is just a theft term with misleading connotations. Heh, that's how I perceive it. I remember windows meant windows on the screen. Now Vista is supposed to mean expansive view but it has nothing to do with windows on the screen. On top of that it's not even expansive as Microsoft has done so much to inhibit our free and open use of our computers.
You can lead a man with reason but you can't make him think.
It's his job now
Some open source projects are created in such a way that you can add features to them by writting plugins (Rockbox, Media Portal, Mythtv, etc.) That might be a good way to get involved with the community.
Coder's Stone: The programming language quick ref for iPad
Since I could only find Windows programmers at my university (the most recent C++ course wanted us to learn MFC, go Windows 3.1!!) I decided to go it my own. Now I work in the marketing/communications field and I plan IT projects with the knowledge of how software works. It is a very useful skill to have and you would not belive the sigh of relief when you show up at a new company and you explain to the IT group that you know what grep, sed and awk mean. They like projects where the planners actually have a grounding in writing software. Best of luck finding your path in the workforce!
it's about skills. You'll most likely never use dynamic programming to solve a business automation problem but studying such algorithms and solving hard problems gains you skills. Debugging skills, analysis skills, the self confidence, ability to read and interpret complicated texts.. When you study algorithms, you don't do it for the purpose of publishing a new STL. It's already been done "20 times over". You study them to improve your mind.
If your dream job is being a code-monkey that converts design documents to code, then correct, you don't need to know computer science at all. You can just get the knowledge you need and start churning. This often gets people in trouble when they come across something slightly complicated. If you never coded anything more complicated than nested loops, what are you going to do when you need to debug some spaghetti coded by an idiot 10 years ago? I've known quite a number of people who had been doing exactly what you propose for 10+ years, just learning what's needed for the problem at hand. They used to come to me for advice even though I was fresh out of school. Just obtaining knowledge thru experience doesn't get you anywhere. Anywhere nice at least.
I think having excess skill is a must for a developer, not an option.
...three years ago. I decided to finish my education before getting involved in something real.
Everything modded highly above so far is good and there's no point repeating it, so I will just mention the Indian stuff. :P
Problems
Solutions
Perhaps I should add a proper detailed howto for Indians on my home page sometime. Anyway, good luck!
Oh and also check out Sarovar along with sourceforge. (I am not affiliated with Sarovar or anything, btw.)
Do what I did: start your own project. Instead of wading through the poorly-written source code of others, generate your own code. Find a niche that has not yet been filled, and just start writing. For me, it was an equivalent to Microsoft Paint on the Mac: there are absolutely none. So I sat down with a good Cocoa programming book, and just did what I could. Fifteen thousand downloads later, and my project has exceeded my wildest expectations. (Shameless self-plug)
Warning: Contents May Be Flammable. Keep Out Of Reach Of Children.
I've submitted some patches for an OSS game at one point, and it was as simple as introducing myself to the team saying that I was interested, reading the code until I got it, while watching what kind of changes were being made lately by other people (through cvs), and learning to patch so I could submit mine where it was reviewed (I suppose, I don't know the process; it just took a while).
^^ Wow, that's a long sentence, but I'm no grammerologist.
My reason for posting, though:
This post made me have to ask, is it at all a common practice for an OSS team to have 'structure guru' type role where someone doesn't particularly have too much emphasis on the coding of new things as they do just knowledge of how it all fits together and works out? I'd imagine it to be beneficial, because while it is one less coder, it is a reference for anyone else who would like to fix/revise/add/whatever and are new to the project... like a team mentor that's there to bounce questions off of where documentation might not cut it (for instance, maybe a very broad view of how all the modules of an application fit together). Just curious, never heard of it happening.
Another possibility to consider is to package an existing project. For example, if you like Debian, you could find a program that interests you that is not yet available in a Debian package and package it yourself. You'll have to learn your way around the code to some extent, learn how the build system works, etc. You may have to write some documentation. You'll also learn about a bug control system and patching. (Debian requires a man page, for example, which not all projects provide.) Initially you'll have to submit the package for someone else's approval, but in time you can become a full-fledged package maintainer in your own right if you want to.
Get a better attitude.
You spend half of your question whining (yes, whining) about your professors. Now, maybe you're at a really bad university, but it's more likely you've got an overdeveloped sense of entitlement.
So take all the rest of the advice you got here and remember that an open source project maintainer, supervisor, whatever, probably won't hold your hand either.
A few years ago, I wanted Mozilla to be able to play a sound when a download completes. I got on IRC and asked for help, and a couple very patient developers helped me understand where the code was that needed to be patched, and how to fix the issue. As I found other things that were missing, or things I didn't like, I wrote more and more patches, each time with less help - probably 99% of the lines of code in my early patches were written over IRC by more experienced devs, and pasted into a text editor by me :-).
I started taking on code-cleanup-type bugs, and eventually, as I became more familiar with the codebase, more visible bugs (and even ones that didn't affect me personally). I've fixed quite a few bugs now, and have quite a bit of responsibility.
I don't know how well it'll go if you don't have a vested interest in your contributions - it's incredibly difficult to get into a huge codebase like Mozilla. I had written programs of up to a few thousand lines of code before, but working in a multi-million-line project is very different. Start with small changes, and don't feel bad when your patches have to go through many revisions before being accepted.
My server
I think you're confused. Every X "server" is a framebuffer or framebuffer emulator and input device nexus. It also houses a clipboard, font resources, and some other less used facilities.
No client to receive the video is required unless the XServer is actually a proxy (i.e. Xnest, XVnc, or whatever).
Now what you're thinking about with Unix sockets is when X clients (like firefox or konqueror or the display manager) which are running local to the machine that is running the XServer on the console; these connect via a local socket or shared memory for fast graphic display.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
The good news is that (if you believe the OP) the Indian software developer community is concentrating all its efforts on Windows. Which means, plenty of open source work left for us here in the western hemisphere. Besides which, they're digging themselves into a trench. Windows development is so ten years ago; open source and web-platform development (mutter mutter iphone mutter mutter) is the future. That being said, perhaps the poster's best path would be open source software evangelism in his local area?
Follow the advise above, and don't be like some guys who ask to join and then never contribute a single line of code. It's like they ask to join just so that their name is in the list of developers.
The world needs more regular end-user software. We are awash in duplicate open source programmer/library projects however there is always room for more common sense simple APIs. You no doubt suck and your chances of figuring out CVS sytems and programming languages at the same time sounds like an excruciating endevor.
I've also been trying to start doing open-source projects. I've added a couple new features (no svn access, so emailed the sole developer with the diff) to one project I found very interesting, but after my first email, the developer has stopped replying. What should I do? Continue to submit new features/fix bugs (maybe he's been busy?) or stop (for whatever reason, he doesn't want my help?)? Thanks.
Since you want to code on a free operating system and your professors are still tied to One Microsoft Way, why not pick a project which runs in both environments?
.Net!
There are lots of cross platform development environments - anything from a plugin for Firefox to applications that run in mono and
That way you can develop under your OS of choice and your professors might learn something from you...
just my 2 cents but start by getting active on the programs ( web site,forum,mailing list) for example i have been doing maps for Celestia for 3+ years and some minor debuging find a program you use and LIKE and go from there
"I don't pitch OpenSUSE Linux to my friends, i let Microsoft do it for me
I was in a similar situation when I got out of college. I had a lot of theoretical training in college and wanted to get my hands bloody. I was coding at work, but it was odd embedded stuff and I wanted some different experiences to "cleanse the palate". I ended up doing work for two projects: Vim and Mozilla. I chose these projects for two reasons: I liked what they did, and they had lots of room for additional coders.
Vim was sort of a dive-right-in situation. Bram maintains a vast TODO list that ships with every version of the product. I spent a while reading it, picked out a couple things that seemed like they ought to be easy, and got to work. I joined vim-dev and mailed out patches. I didn't do a ton for the app, but I got a few things in.
Mozilla was a different beast in many ways. It was a much more structured environment due to the review process and the presence of Netscape. Also, it was in C++ (which I barely even knew, thanks to some shoddy university training), and not just any C++, but XPCOM. At first I was intimidated by the size of the code and not knowing where to start, so I didn't even touch the code. I spent several months just sitting in #mozillazine and triaging bugs. I dup'd, I closed, I changed to NEW, all that good stuff. Through this, I achieved two important things: I got a much better sense of how the product worked, and I met some of the players involved through IRC contact. By this time I was sitting on #mozilla as well, but I never said a word.
Eventually, I downloaded the code and bought a copy of Don Box's "Understanding COM" for background reading (that book is amazing). From all the time spent triaging, I knew some of the areas where bugs were piling up and nobody was looking at them, so I started there. I submitted a few small patches, had them reviewed, had people check them in for me. The reviews were harsh sometimes, but I was learning a lot. Eventually I moved around a bit and took on larger fixes.
I did this for a year or so before I got too busy with work and dropped out of sight. To this day it was some of the most fun I've had as a coder. For all its flaws (in those days, Firefox was still "m/b", and Netscape ran the show), it was a great project, and some of the people who worked on it were the best programmers I've ever worked with.
So, my advice: start slow, start small. Figure out who you can ask for advice about something. Look for other (non-coding) ways you can help out that will help you get familiar with what's going on. It's worth it.
http://www.freebsd.org/projects/ideas/
My suggestion?
Join the KDE Project. Just monkey around in some smaller projects inside there. They have IRC Chat discussions, forums, mailing lists, the works. And I don't know a single person in there who doesn't have their arms open to new motivated developers.
You won't find all the anger and aggression in the KDE project like you do in other projects like the Kernel, or others.
Your ignorance is infinitely greater than you realize.
Join the mailing list! this is the most important thing to do if you don't have experience with the project.
Listen for a while about what is being done. Then get involved (ask beforehand if what you'd like to do is desirable from the point of view of the community).
One thing to remember: don't be a bone head! If they tell you a few times your approaches are wrong for such and so reasons don't fight it very much, you'll just reduce the signal/noise ratio.
Why should the kernel adapt to a misbehaving module? Wouldn't it make *far* more sense to shorten the symbols in the NI module to something sensible?
You're far better off shooing the sub par off than giving them even a small job.
Or suck it up and deal with the fact that you've been trained for call centre work.
I think you always need to be in that special inspired state in order to produce quality work and advance. I get a kick from reading about the superstars, such as Rob Pike (http://interviews.slashdot.org/article.pl?sid=04/ 10/18/1153211&tid=189), Brian Kernighan, Dennis Ritchie, etc. Also, check out David Wheeler's page and read some stuff from Larry Wall, the outspoken creator of Perl.
Definitely read good books - Bruce Eckel's Thinking in * are fabulous. Also see Martin Fowler's collection and may others.
And, oh yea - write code no matter what!
You can try todo Translations for languages that you know, such as India language.
Translations are generally very easy todo...
In case you are interested, here we do welcome Final Year Projects and MSc candidates who are keen on joining or starting or writing a FOSS project or thesis.
And I am sure there are many other universities out there who do likewise.
I ran across this open source group via the fancy Jeff Han stuff. www.nuigroup.com. They're taking images from a webcam, and doing fancy blob detection for a multi-input touch interface kind of thing. They work in windows mostly, with a c++ lib, porting into other windows-y programming environments. Open sound control (a lightweight protocol) VVVV (I'm still not sure what this is), DirectX layers, and more.
It would work great to try and integrate as a lower level windows driver. Right now only applications work with a library. But perhaps a driver, working with a webcam driver, presenting itself as an input device? Eh? Well its certainly got potential to consider.
Ironically I got interested in the project from the perspective as a linux project. It would work very well on an embedded linux system, passing information on the pci or usb bus to any which os. But embedded programming is a whole different ballpark from the rest of the programming world.
This is the worst possible advice that I could possibly imagine. Real World Problems are the one problem where you can be ultimately effective. On the job training is the most effective training ever.
You are advocating mental masturbation, you insensitive clod!
It's only Debian that caved into Stallman's desire to rename Linux for his own glory.
Lots of us Linux hackers are more or less peeved at the situation, especially Stallman's abuse of his control over the GPL preamble and the uname command to force the issue.
I cannot believe that linux is frowned upon at this college. Funny, where I go, WINDOWS is frowned upon and all student projects and coding has to be done on linux or any other unix variety.
Instead of joining an open source project, why not talk to people, understand what they do, understand their needs, find out what their problems are, and then try to devise ways to help them solve their problems (assuming that the problem can be solved through automation).
Then, once you have identified a problem, you interview them (your customers) as to how they solve the problem manually, then through your knowledge, experience, and willingness to try new things, you should be able to develop a program to fulfill their needs. Once you have developed (road-mapped, if you will) the solution, then coding it is simply a matter of choosing a relatively efficient language to code to(it doesn't really matter which, as long as the language is capable of supporting the task in a logical manner), and transferring the logical manual steps to computer code.
The coding part is easy (relatively speaking), the hard part is designing what needs to happen, what order things need to happen in, what could go wrong, accounting for them, and then implementing your solution.
If you are like me, that means that once you have found the logical steps to solve the problem, you then find/search for the best language that you can learn/experiment with, to eventually solve the problem. The learning curve can be excessively steep, but the rewards tend to match the effort put forth.
I have found that while I am not formally educated in computer science, I can do what needs to be done, as the situation calls for it. It is most rewarding!
Speaking as someone who runs a couple of open-source projects (Java Web Parts - javawebparts.sourceforge.net, DataVision - datavision.sourceforge.net, as well as some smaller ones), and as someone who has contributed to a number of open-source projects, my advice is simply to get out there do do something.
Submitting patches is indeed the first usual step. The existing team members need to see (and have a responsible to see) that you know what your doing. This means different things to different people, but at a minimum it means that you have enough competency to not break anything. Being on the mailing list is indeed the other logical first step. Don't be afraid to jump in to conversations (once you have a clue), just do so politely and which as much forethought as you can muster. If anyone involved in the project attacks you if you've done both of those things, than you don't want to be involved with that project anyway.
Something else that a lot of people don't consider is you don't necessarily have to be directly involved with the project. In fact, that's how the most popular component in Java Web Parts (AjaxParts Taglib) came into existence: it was originally an extended Struts HTML taglib, but the Struts team didn't have any interest in it. So, originally I release it as part of the Struts SourceForge project, and then later spun it off into its own thing (completely independant of Struts now). So, don't be afraid to fork code, or start your own project on SourceForge or Google Code or somewhere like that.
The other key point to remember is that any open-source work you do should be for YOU first and foremost. Don't just do something for the sake of being involved, do it because it interests you, because it "scratches an itch" for you. If something if useful to you, it tends to be useful to others.
At the end of the day though, don't be shy! Ask questions, submit patches, take some baby steps and get your feet wet. Yes, there's a lot to learn, and yes it can seem overwhelming at first, but I guarantee you'll pick things up pretty quickly once you get into it. The two projects I mentioned are always accepting contributions, so feel free to stop by, join the mailing lists and get rolling!
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
"and frankly I don't particularly believe in the guy"
even if he came and said "hi"?
This is the lackey approach.
The same fellows who were lucky to write a small program in the 90s are now big time maintainers of mainstream projects. And they say "duh! we gaveth yuo this software for free, which yuo would have otherwise paid for! now, yuo owe us and yuo must contribute back by cleaning our toilet!"
But they're forgetting that back then they were little students who wouldn't put up with existing crapware that did not allow them to do interesting things!
Screw them. Write your OWN project and release it to freshmeat/newgroups. Of course it's going to be burried by the noise of mainstream software. But releasing on freshmeat is the first step to understanding oss.
Then, you can hack on projects, but ONLY when this is FUN or you have direct interests in the features you're hacking about. Even then, your patches may be dropped by asshat maintainers.
It's probably too late for my comment to be highly moderated, but really, if you want to be involved in a large and existing project, you have two choices. The first one is to fix bugs. The second way is to write documentation. Some people suggest TODO lists, but those are usually the hard parts that developers intentionally put off until there's nothing else they can feasibly do. What you really want is experience going through the motions of finding code, reading it, evaluating it, suggesting an improvement and following through.
;)
If you're a linux user for some time, I hope you've become accustomed to the practice of filing bugs with your distribution. Pick one that annoys you and decide to fix it. This is a very common way for a user to become a developer: fixing the problems that are important to them. That you haven't done this yet suggests you don't have such a pet bug. Trying to fix someone else's bug is usually painful. First you have to be able to duplicate the problem, then make sure it's a problem with the code, that it's not fixed in CVS, etc.
This is why I suggest that you write or verify documentation, especially man pages. There's numerous advantages to this approach:
* man pages have a standard format that you can learn and follow to guide you
* man pages are a standard tool everyone else uses to find information
* it demonstrates your ability to communicate eloquently in written language
* it requires you to read source code and become familiar with a lot of the body of the code
* your contribution will not be limited by your ability to understand obscure coding mistakes or hardware interactions you can't reproduce
* there are far fewer people writing documentation than fixing bugs
* using the revision history to determine when a feature was added is far simpler than determining when a bug was introduced
* if there's a crazy build system, you won't be required to figure it out, though it would make sense to so you can write about it
Because you've taking a holistic approach to contributing, you'll be one of the few contributers who knows the whole source code. And you'll know so much of functionality that determining which reported bugs are configuration errors versus genuine bugs in code will be easier.
I Browse at +4 Flamebait
Open Source Sysadmin
if you want to work on a c++ project, you need to sit down and learn c++ first. You've said you've only written a few lines of code. You just aren't ready to work on a large project right now in c or c++, or java. You could work on a smaller project maybe, but you might be best off writing tools and going through the learning process first.
.NET languages you've used. There's probably even open source projects in visual basic .NET, although I suspect a lot fewer.
First, I'd look for projects that use skills you already have, and build on those. There are open source projects in c# if that's one of the
Also, generally, as a developer you should have a number of tools available to you. At some point you should probably learn c, as a ridiculous number of projects use that language (even many projects where it is arguably not the best choice). Don't bother learning c++ until you've mastered ANSI c unless you need c++ for a job or something. C projects are far more common in the open source world than c++ projects.
Also, if you're more comfortable in higher level languages, you might consider java or python. Both are widely used in open source and commercial settings. Python especially is easy to learn quickly and use to produce something.
It sucks not having any mentors around, but remember that many people teach themselves most of this stuff, and that books and the internet are good resources. If you have difficult technical questions, the best place to ask them is probably a mailing list (for libraries) or usenet group (for languages).
The main thing to remember is to keep learning stuff and not to be satisfied with whatever training your college gave you. It sounds like your particular college was training people to use a specific tool chain to do a job, but as a developer you need to be able to learn how to use whatever tools are available. It's more valuable to just have really good problem solving skills, and a good understanding of computers.
Perhaps you've partially answered your own question -
Try putting in your sig the following (as you see fit) for anyplace you care to participate:
"I'm an Indian grad student whose CS teachers run away at the mention of Linux. Any assistance or advice on how to mesh with this group is most appreciated. I want to contribute and need help getting started."
Ignore anyone who criticizes you for this - anyone who can't recall their beginnings is a lost cause, and to be avoided.
It's about contributing, not power or prestige. You'll find your home. Best luck, and hope this helps!
Pathological kinda promises Path + Logical - but instead, you get stuck with pathetic.
If you want to improve your skills, just start writing small programs that do the things you want them too. Put them up on a page, doesn't have to be fancy. To a business person, and even some IT, it looks amazing that your even doing it.
Insisting people use the name GNU/Linux is what best serves Stallmans cause; promoting the idea that Free Software is benefitial to society, whereas proprietary software is not.
A lot of books on GNU/Linux acknowledge that GNU is the technically correct name for the operating system, but that they choose to use the more known term "Linux" to avoid confusion. I'm all for avoiding confusion, but believe this is a simplification that only makes things more confusing for the uninitiated. While "what is GNU?" is easy to answer, "what is Linux?" will bring a multitude of more or less contradicting answers because the term is being used so generally.
I'm not like other individualists.
My standard advice: http://ometer.com/hacking.html
Anyway, you don't join a project - there's no membership list, and there's nobody who will tell you do this or do that or whatever.
What you do is get on the forums (usually mailing lists, IRC, and bug tracker), start following the discussions, and help out where help appears to be needed. That's it.
If you wait for hand-holding or permission you won't get anything done. You have to be persistent and just start doing stuff.
Development on Windows NT and Linux started about the same time, and in a technical sense Linux has always been behind in nearly every respect. NT had symmetric multiprocessing first, kernel threads first, file system journalling first, non-x86 ports first, a preemptable kernel first, asynchronous I/O first and the list goes on. A lot of features designed into NT from day one took literally more than a decade to be implemented on Linux, and some still aren't there at all.
Linux isn't a bad system. It's a good Unix clone, and goes well beyond the classic Unix kernel, but it's always been a technological laggard compared to systems like NT or Solaris. That's simply the reality, and if you insist on calling one of the three systems (Unix, NT or Linux) a toy, I'm afraid Linux is by far the best candidate for the label. However, even if Linux was a toy in the 90s, and realistically it was, it isn't any longer. That doesn't mean it's caught up with NT and Solaris, but it's become a respectable system.
Non developers never use kernel interfaces. You have an API, work within it unless you absolutely can't. Simple coding style is not justification to make changes in the kernel which may silently cause bugs for thousands or millions of people.
Elitism is not always a bad thing.
Impliment threads in Clisp. Everyone would cheer you. Seriously.
Hi, We group of 7-8 graduates working on FOSS(Free and Open source) from last 3 years. We mainly work for spreading digital divide. we had done many e-gov projects freely. if you want to work on free and open source projects and live projects, you can join us. we love FOSS things.If you want to work with us, then you can contact us on my email-id i.e kanhaiya.kale@gmail.com or you can give me ring on 09970059663. Best Regards,
I'm afraid I have to throw some actual facts into this perky troll-vs-troll thread: Kernel Comparison: Linux (2.6.21) versus Windows (Vista)
Want to hear the voice of GOD? cat
Says who? Linus himself has said that the whole GNU/Linux thing is stupid, and the Lignux thing before that.
People gathered around Linus to make an OS. An FTP admin in Finland chose the name.
I guess it was a mistake to use Stallman's trivial little tools. (and they really were trivial, even gcc, until the Linux people started supplying fixes) Who'd have thought back in 1991 that he'd try to take over, crowning himself King?
The kernel is the central part of the OS. Everything else just got dragged in bit by bit, most of it NOT from Stallman's gang.
It's a very nice opensource project. It's easy to get started. You can write code in javascript. The community is friendly and small. There are many areas needing work. Check out: http://groups.google.com/groups/TiddlyWiki http://groups.google.com/groups/TiddlyWikiDev http://trac.tiddlywiki.org/
Go to berlios.de, sf.net and check "Help wanted" section. Find an correlation between trends at job market, your goals and project which are currently looking for developers, choose right one.
Enjoy.
Many projects suffer more from lack of good sample or reference applications than good features. If you want to get attention, show people how to use a technology in a way they haven't thought of before. For example, one of the real accelerators for Ruby on Rails has been the success of BaseCamp, which is a really good sample application for RoR. In our project http://sourceforge.net/projects/activegrid/, we have posted a number of ToDos related not just to features but to providing examples of how to use the features http://dev.activegrid.com/community/?q=node/179 To misquote, a sample is worth a thousand features ;-)