Slashdot Mirror
How Can New Programmers Contribute to Open Source?
DanPeng asks: "I'm an inexperienced programmer who has been following the Open
Source movement for a few years now, and recently I've been looking for opportunities to write some code and contribute to an Open Source
project. As a a senior in high school, I've taught myself C, C++, Perl, and a few other languages. I have a basic understanding of algorithms from AP
Computer Science, and I've toyed with GNOME/GTK+ and *NIX
programming. I lack, however, any 'real' programming experience writing code for projects of any great size or importance. How should a new developer contribute to Open Source?"
"I've worked with no more than one or two other people on programs of no more than a few thousand lines of code each. The 80 MB sources of Linux and the 160 MB sources of Mozilla seem to me these enormous morasses of code far too deep and intricately interconnected to wade through at all. Surely there must be thousands of similar students with basic programmming skills who want to help but are intimidated by the sheer enormity of even finding their place in hundreds of megabytes of source code. I would think that after the experience of a few projects, one would get the hang of it, but how can a new programmer get a foothold for that first experience? What kind of project should he be looking for?"
Look at you people, look at every single post, telling him to just dive into it, Just do it! Just scratch it! Hah, that is like telling a shy geek who wants to get laid to put on a pimp coat, carry a cane, find any lady, mack on her and just do it! It ain't easy! I repeat, It is not easy, It is much easier to start a project from scratch than to dive into an opensource project, It is very hard to read other people's code, especially when you are not involved from the beginning or when you come in late, only to find that there is no specs. I value Opensource, I appreciate opensource, and I dream and pray that it grows more and more, but one thing that the vast majority of opensource software out there are lacking are solid software engineering processes. Talk about processes, and you get frowned up, People who have never written past 1000 lines of code, jump on and such. Hacker mentality is the way, Just code! Just do it! We need a way to open up the door to newbies, We need a way to hold their hands and guide them to the proper path. opensource culture reminds me so much of the MIT hackers lab culture in the 60's, I ready Hackers by Steven Levy. ;) The hackers in the 60's had this idea of, you either got it or you dont', we ain't gonna hold ya hand, sit down, shut up and code or else get out! I see the same thing here today, not as brutal. The most exciting thing I have done in my life is teach others, I once taught a bunch of wannabe-script kiddies how to code C, via IRC around 4 years ago, they lot interest in hack/phreak and went coding, where they are today, I don't know. around 3 years ago, I met this kid via IRC, 13 years old, interested in C and asm, People made fun of him at this age and told him to go learn BASIC, just a few minutes here and there every other day for a few months, he was able to stand on his own. I myself need a hand holding! I don't wanna write another small blah blah project, I want to work on significant stuff, I am not out here to scratch my itch, pretty much most of my itches have beens cratched by someone, I want to contribute to softwares that can change the world for better, ah well, I dream.
seggy
Ways that newbies can contribute:
There's probably all sorts of other things a newbie can do to contribute, and I was not being facetious with that last item: never underestimate the value of morale support.
Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
Perhaps if you want to work on a smaller Mozilla related project check out MozDev however most of these are projects that build on top of Mozilla using XUL and js.
Alternatively why not look on a site such as sourceforge and look for a smaller open source project you can help out with.
- Document. Document document document. Use the whatever and write/elaborate on the FAQ, manuals, etc.
- Debug. Try out the features & discover what works & what doesn't work. Go through the code and attempt to fix the problems.
- Support. Lots of groups could use someone to help handle their administrivia, clean up their website, write some PR stuff, whatever.
Of course out of this you get some real skills, lots of hands-on project experience, and are exposed to a wide variety of real-world code & coding styles.I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
Others have rightly pointed out "find a bug and fix it". I'll weaken this a little: find a bug and identify it. To start, you needn't even find the "correct" fix -- for some problems this can be hard to do, especially if you are inexperienced and didn't architect the code in the first place.
It is *VERY* important to your development as a programmer to get involved with sophisticated code that someone else has written. You'll see good code, bad code, ugly code, and learn to tell the difference between them. This will improve your own coding styles. You'll learn about various coding techniques, data structures, etc. in something resembling a real application.
[rant about deluge of unmotivated "I just want a job" students in CS academia deleted for brevity.]
Remember, you don't have to start as a coder. There is a lot of overhead in running a project. Documentation, code cleanup, test writing, and resource development (sound, graphics) are all areas where you can start, then move on to coding as you become more familiar with the project. Many great projects go unused because they aren't sufficiently documented or the distributions are too hard to install.
Check out SourceForge to find a project appropriate to your skill level.
-m
I suggest opposite. find a great book, pick a project.. and get in over your head.
If it sucks, you will get peer review and get better.
Sooner or later you will hit a point to where you are appreciated for your contributions and the pain will be worth it.
Obviously the person that posted this article doesn't program, or at least doesn't understand the spirit of 'open' source.
Almost a BSD attitude.
--------------------
I feel your pain! (=
I'm a freshman in college, with about as much experience and interest as you have...and the OpenSource world is very intimidating! My suggestion: start small. Really, really small. Eg, I have made exactly one contribution to the WINE project: if your Windows program calls GetDeviceCaps with capability "94", you get a fixme: unimplemented CAPS1 capability error. That's mine. (-; A couple of newly #defined constants, a few code comments...and an error message.
But, seriously, look at what I learned from the experience. (I learned to hate MS's undocumented API features, for one.) I can now maintain a WINE CVS tree. I can diff changes I make against a current tree. I have some feeling for the organization of the project. (I got my name in WWN this week!) I feel a little more confident...next, I might try my hand at the EnumFontFamilies bug that keeps MINITAB from drawing graphs....and I'll probably fail miserably. But the people on the wine-dev list have seen my name a few times, and maybe they'll help.
The other thing you can do is work on smaller projects. 160 Mb of Mozilla source is something I wouldn't even try to compile, much less try to contribute to. But look at littler, one- or two-man projects (like GtkTiLink)...they're riddled with bugs and usability problems...and the source code won't overwhelm you. When you see a problem, it's usually reasonably easy to track down the problem...even if you can't fix it.
Let's face it. Neither you nor I have the expertise to help Linus and Alan Cox with the latest 2.4.0 show-stopper. Heck, just compiling the blasted thing scares me. But there are still little ones you can help with, little contributions you can make...and those will help you step up to the bigger challenges.
Whatever you do, don't try to release another damn Linux distro. Like we need another one of those.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Find a project you care about, find a bug and fix it...
I think the key here is to not think on the scale of participating with major contributions, but to try and fix the odd bug or two. Find something on SourceForge that interests you, but which is small enough that you feel you can handle.
Once you've gained some experience working on minor fixes, you'll start to get the confidence you need to tackle larger projects. There's no need to try and jump right in over your head.
Start small and use the experience you gain to work your way up to more significant contributions, there's no reason why a beginner can't use Open Source to get their feet wet.
Unix is user friendly, it's just selective about who its friends are.
Walt Parazadier, saxophonist for the band Chicago, once told a story about his dad, who is a 70 or 80 year old trumpet player who had played trumpet his entire life. His dad apparently was practicing one recent day, and turned to his son, who was visiting, and said of the trumpet, "Someday I'm going to learn this thing." The point, of course, being that you have never truly mastered the instrument and that there is always more to learn.
I'd say it's the same with C++. You could program in it for 20 years, and you'll still look at your code one day and say, "Someday, I'm going to learn this language."
ChicagoFan
Go to SourceForge - find a project that needs help in a language you are familliar in - and take on tasks...
Once you are comfortable doing code to some-one elses specs - you could try your hand at adding in features you feel are needed, or even trying to manage a portion of a project.
There are all sorts of 'job postings' on sourceforge for projects that need help.
BlackNova Traders
We weren't experts either. In fact, many of the people who started the big name open source projects you see today were college and even high school students, who had never written a large piece of code before. (Some would say it shows, but I digress.)
So how do you get started? Dive in. Find a bug you want to fix, or a feature you want to add, and do it. Ask questions if there's something you can't figure out. There's no pressure; you don't have to even tell anyone you're doing it until after the fact. You can take all the time in the world.
And maybe, just maybe, if you're lucky, when you do publish your result, someone will thank you for it.
Good luck.
Even if you aren't an expert on some code, you can surely find ways to improve it just by using it. So contact the maintainers of the source tree, and give them feedback and suggestions for fixes, features or other improvements. Then, as you become more familiar with the program, you can start to delve into the code itself and code your own fixes, features and improvements. :)
Just find a project you are interested in (theres several on practically everything out there) and email whoever is administering it offering your services. Explain that you are new and willing to learn and you will find something to do. A lot of the people working in open source are either hobbyists or self taught and to them the simple fact that you want to learn means a lot. However there will always be some who will deride and mock (see half the troll replys you'll get to this slashdot post for examples), so a bit of thick skin may be required.
Finally if no one seems to care then download some early version of an open source project where you have some knowledge, check their bug lists and fix something. This should at least get you in the door with most projects and from there it is up to you how much you take from/give to the project
Slashdot: Proof that a million monkeys at a million typewriters can create a masterpiece
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
I concur with the previous poster in that you don't need to be concerned regarding screwing things up since your code will be reviewed, but I would point out to the authors that you are a newbie.
There are good programmers, bad programmers and new programmers. A lot of "mistakes" are made by new programmers - that is how they learn the craft of programming, and a lot of mistakes are made by bad programmers who will never be any good at programming. If you qualify yourself as a newbie, then if you make mistakes, the authors will be willing to review with you the things that you did correctly and provide some insight into why some of the things that you did are wrong. If you don't qualify yourself as a newbie, they might just disregard changes that you send it, and you won't get any constructive feedback that will help you become a better programmer. One of the quickest ways to become a good programmer is to have a mentor who will help point you in the right direction.
"Microsoft has made computing accessible to a population who would otherwise not be able to use computers" - B. Kernigha