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
A couple years ago (I'm a senior in high school right now as well), I had taught myself to program and was itching to write something. I was also eager to help others, but also realized that it would be great if I could start a couple of projects myself.
:)
:) Good water-cooler anecdotes.
I released some small Perl utilities first. Pilot2pine, my first creation, used the pilot-libs package to grab the address list from a palm pilot and converted it into a Pine e-mail addressbook. Very useful
I also wrote a few more fairly interesting Perl scripts. I posted them to freshmeat, where they were received quite warmly. This was back when freshmeat wasn't swamped with 139485719834751984 different projects.
After writing some Perl tidbits, I decided to get my feet wet with C (my feet are still pretty damn dry) and started work on GDict - perhaps you've heard of it. At the time, a friend of mine had a small console application that looked up user-specified words on the MIT dictionary server.
I used this as a base to learn the GTK widget set. I wrote a front-end, gave it some buttons, etc, and released it, bugs and all, (it really was some pretty shitty code) to the world, where it received a fair amount of use.
A few months later people started submitting patches. To me! The project got better and better, until someone eventually started working on the thing more than I did (as you can imagine, school got more and more time-consuming. Homework bites.)
So I passed the project along to the new developers (http://gdict.dhs.org) and they extended it into an awesome little app with full GNOME functionality and stuff like that. It was eventually integrated into the GNOME desktop distribution and is bundled with every distribution that comes with GNOME. Pretty damn cool, huh? I still get positive feedback on the project today, even though I don't actively participate in it (school again!)
A funny story: my coworkers (who didn't know I started the little project) were using GDict one day and they were telling me how great it is. Apparently they use it all the time! I clicked on the About... box and they were pretty shocked to see my name listed in the credits (in pretty big font, too!)
Writing GPL stuff is a pretty fun. And it gives some good stuff to put on your college applications!
- Mike Hughes
The dangers of knowledge trigger emotional distress in human beings.
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.]
Find your itch and then scratch it.
Is there some open-source program you use that you think could be better? Or it works well, but you'd like it better if it had this one new feature? Or it's got this one really annoying bug?
Those are all opportunities to get involved. Improve the program, add the feature, or fix the bug. Start with small improvements, features, and bugs, and then work your way up. Before you know it, you'll be starting your own project and people will be coming to offering help.
Look for these opportunities, they're everywhere.
--Jim
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.
--------------------
Offering to help document a project is one of the best thing you can do. Correcting comments, or writing a small web page (basic HTML takes about as much effort and intelligence as personal hygiene), even if that web page won't be viewed over the web but shipped as local documentation instead -- it's all helpful.
And, in the process of reading the code or observing the behavior or seeing what bug reports come in, you'll learn a huge amount about the project, and probably discover bugs at the same time. (Nothing gets outdated faster than code comments.)
Keep in mind that documentation doesn't always have to be for the end user. You could just start keeping some notes, and offer them as docs for developers for that project. Those can easily be of more use than docs for the end user, because it makes joining the project easier for future newbies like yourself.
As somebody who writes such documentation, lemme tell ya, it's a good way to get involved in coding. (Now I have no time to write documentation...)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Okay, I'm going to play the devil's advocate and say this probably isn't the best way to get started.
However, that depends on your definition of "best." There's a lot you can learn from starting your own open source program from scratch, but the problem is, that's about the limit: there's a lot you will learn. In terms of contributing to open source as a whole, you might or might not get anything done.
If you do have a great idea for something that just NEEDS to be written, at least check out Sourceforge first and try to make sure someone else hasn't started it yet. If there is someone else out there, great! Consider it a head start on the app of your dreams.
On the other hand, if there's nothing in particular that "itches," then certainly don't start anything new. Flex your newfound programming muscle by finding an interesting program and add a feature (I would say "fix a bug," but I don't want to scare you away). I think my next thing, after I recompile my own kernel on my new machine, is going to be installing KDE2 and contributing to the mail client. I use the KDE1.1 kmail, and kind of hate some things about it.
[ That said, I wouldn't really want to discourage someone from starting their own new project. Just be realistic about expecting it to make a difference in the community. Chances are your pet project is just that - yours. ]
Dont go after high profile projects like Mozilla and the linux kernel for your first project. Those type of projects attract a large number of the best programmers, leaving few interesting jobs for the less experienced. If you do want to work on Mozilla, etc, it will be appreciated, i'm sure, but it will not be nearly as satisfying to you (well, thats my experience, at least)
You should decided what you're interests really are. If you are more interested in games, there are plenty of games being developed that could use any help that can be gotten. If you are interested in AI, check sourceforge or Generation 5 there's always something going on.
You'll benifit from a smaller, less important project because the project leaders will be more willing to take you under their wing and help you smooth out your programming skills. There's also the equivalent of a small fish in a big pond, or a big fish in a small pond... you'll be more vital to a smaller project than say Crystal Space or, especially, kernel work.
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
I have a slightly different take: find yourself a project you like and make any change you like. Download the source, and read through it. Start by trying to add a button in a particular location that prints something on the command line, or something. Or make something display differently. The point here is just to become comfortable with how the particular program works. You'll begin to understand the code a little, and when you feel like it, you'll be ready to fix bugs or add features. But it seems to me that can't be the very first step, especially if you're new to open-source, and likely not very confident of your coding skills be begin with.
I say to start, just break stuff and then try to fix it. Do that for a couple weeks or until you've delved into the code sufficiently to understand what it is you're breaking. Then, I think you'll be ready to take on some bugs and add some features.
Just make sure you announce that you're still a novice. People are usually very willing to help beginnger.
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
I suggest that you don't start coding for a project right away. Despite what can be taught in books, you still won't write great code since you have so little real world experience. My suggestion? Find a project (should be tons of other sites mentions in comments) and try doing a non-coding aspect, such as documenting for a few months. You can gain an incredible amount of experience this way, and in all honesty, writing free software with bad code can be a very terrible thing. This isn't trying to be insulting, just suggesting that you not get too high and mighty simply because you've spent a lot of time ordering from FatBrain.
You are more than the sum of what you consume.
You are more than the sum of what you consume.
Desire is not an occupation.
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. :)
Open source doesn't work well with a 'what should I do/How should I contribute?' type situation.
It works much better if *you* have a need for something. You need an IDE for development? Grab an OS one and add the features that *you* need, fix the bugs that it contains. You need a share dealing system? Grab one, add the features you need, fix the bugs.
If you just try to 'contribute' random features to a random project, your contribution will not be as good as if you *need* those features.
Government of the people, by corporate executives, for corporate profits.
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);'
If you take the premise that good open source software starts with scratching an itch, then the first thing you have to do is figure out where you're itching.
:) Good luck.
So:
1) sit down, make a list of your itches
2) find out if there's any open source projects out there that fit (freshmeat, sourceforge).
3) pick one. Start _using_ it. Chances are you'll find an issue that you'll want to do something about, eventually. Chances are that before you're even done INSTALLING it, you'll find something you think could be done better. If nothing else, you can document it. With some research and some help, you may even be able come up with a fix yourself.
I'll give you an example. LinuxPPC. I've installed it on some older model macintoshes, but I've had an iBook for 6 weeks and haven't got it to run on the iBook yet. This despite the documentation out there and the patient help of several people from comp.os.linux.ppc. It will take patience, but I'm going to get this, and by the time I'm done with this, I expect that I'll be able to write a half-decent HowTo that will be a contribution to the community. I'll also have some familiarity with kernel issues and open firmware and other stuff that may help me if I ever get an itch to contribute code.
And if there is no project for your itch, well, then you get to strike out on your own.
--
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
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