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?"
I would start working with the Mozilla source code, here is your first assignment. Create a 3d UI for mozilla, you could take the Quake 1 source code and incorporate it into the browser for the 3d UI. This should be pretty easy if you know C++.
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.
Rather than starting a new project (which, in most cases, is just going to duplicate other effort), find a small to medium size project with relatively uncomplicated functionality. For example: an ICQ client, a news reader, or a configuration editor. Use it for a while and see what it needs in terms of making it more useful and more pleasant to use. Then try to add that.
Perhaps the simplest thing is bugfixes. Bang on an app with a 1.0 version for a while until you get something funny to happen. Duplicate it. Now do it from a debugger and start hacking.
This kind of work is both easy to get into, and probably the most useful thing you can do for the open source community as a whole. We've got lots of very nice apps which need "just" a few more tweaks and improvements to be really slick. But of course, that last 5% is often the hardest part...
Bill - aka taniwha
--
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
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
Most folks don't use IDEs in Unixland because we don't call them IDEs. We call them "programmer's editors", and they fill the same task. Not that there aren't IDEs here, but they haven't really caught on.
Check out emacs and vim. No, don't glance at them -- really look at them. Both use syntax highlighting, and emacs has click-on-the-error-to-go-it. Emacs has integrated GDB support (not 'just launching' it, but following through the code, etc). If that's not enough, there are several (I can think of three off the top of my head) graphical frontends to gdb available with the features you mention.
As for the 'good error reference'... hrm? what kind of reference? A null pointer dereference is a null pointer dereference no matter what platform you're on. Would you mind being a tad more explicit about what kind of thing it is you need?
I would say go the other way. Write some assembly programs, write more C. Then write some ML or LISP, prolog, smalltalk or something truly high level
> Try to stay well away from C++ until everything you write comes out object oriented just because you can't help it
Fuck that. I can't think of worse advice. Stay away from C++ if you like - it *is* complicated, but OO is no panacea. In fact the main reason why there are still no good Java applications is that it forces everything to be OO.
http://rareformnewmedia.com/
As has been pointed out, contributing code immediately is probably not the best step. Support, documentation, etc. are all fine, but if you're interested in contributing code, I think your best bet is to really examine the existing codebase first.
For instance, I gained a lot of understanding of UNIX systems programming through reading the CircleMUD codebase. That isn't to say I necessarily write code the same way, but that I learned a lot by examining the code and just evaluating the solutions to various problems and what other possible solutions there might be. It was a simple matter of just picking a file, and reading it. Understand the functions there, where they're called elsewhere, etc..
While I haven't contributed back to it, beyond a third party feature patch, (and CircleMUD, being based off of DIKU, isn't open source), I found that I gained a much better understanding of the code and was far more capable of making my own modifications.
By doing this, you'll become familiar with the style used in that codebase, and be better equipped to contribute when you see a bug that needs fixing or a feature that should be implemented.
--
Kevin Doherty
kdoherty+slashdot@jurai.net
Kevin Doherty
kdoherty+slashdot@jurai.net
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 a project that you like. Read the code. Use the app. Play with it and tinker. Find something in the application that YOU would like to use yourself. Write it. Improve it. If it works for you, submit a patch to the maintainer. Don't feel hurt if it doesn't make it into the distro. Write something else - use it, improve it, submit it. Don't feel hurt if it doesn't make it into the distro and so forth. While you're doing all this writing, you're getting experience even if it's never used in the official release. Additionally, take a poke at the TODO list and challenge yourself. When you finally do get something included in the distro of whatever OSS project you've selected, it'll be worth it - you'll have written a lot of code, gotten a lot of experience, learned how to work with a distributed team of writers and hopefully had a blast doing it...
Mike
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
I learned a lot about programming by porting other people's programs to currently unsupported machines and operating systems. If you are really ambitious, get yourself something unusual like an Alpha. It's a great way to learn how to write portable code (No, the world is not a VAX) and you can learn many things that aren't in textbooks by reading other people's source code.
Mea navis aericumbens anguillis abundat
it may sound silly, but try coding on a mud to start out. my personal experience was with the envy and merc types. the code is generally clear and modular and simple so it's fairly easy to drop in commands, new features, etc. (just about everyone either does work with the color code or messes with writing a bank their first time out...i did ;P)
and it's fairly easy to see the immediate results of your code in the game state
-dk
-dk
Dream with the feathers of angels stuffed beneath your head.
can't moderate above 5, but it's a great point.
One more thing - don't feel you HAVE to get involved.. open source is for free, from the developers to you lot. We're not saying "here's some code, so give us something back". We're just saying "here's some code". (full stop) I used to feel guilty about using linux but not writing much code. Now I write loads of code and don't care what my users give back! As long as I've made a few people happy, my project has done well, and that's why I did it!
One problem with programming classes is that they teach you to write code that compiles, but they don't teach you how to comment. Here are some of the habits I've picked up regarding comments:
You can find the "XXX" or "FIXME" comments with grep. If you don't put them in now, you'll never remember to fix the problem later.
- The range of acceptable inputs (if the
function takes a char *, is it okay
to give it a NULL? What about a non-NULL, but
empty, string?)
- What the function does when all goes well.
- What the function does when there's an
error.
- What assumptions the function makes.
It's amazing how many problems you can avoid this way.You can write something new.
;-)
I think 1010011010's point was that plugins are new code, but NOT a new PROJECT. A newbie can create something new without the huge investment of creating a new project (such as makefiles, docs, mailing lists). Someone writing a plugin (such as an Apache or Linux module) has lots of example code and an existing community with which to learn and share.
Open source projects like Apache and Linux have blossomed specifically because they have a plugin architecture. I like to call this a "Christmas tree" architecture because new features the original designers never dreamt of can be added to the project, like hanging ornaments on a Christmas tree.
cpeterso
You can always contribute to what is missing. So what's missing? Lots of stuff in the average OSS/FS project. That stuff may not be coding, however, but so what? Get your name known to the developers by doing some of the unglamorous stuff while you learn the code base better.
Documentation. If you have decent language skills and half a brain, write handbooks, reference manuals, tutorials, etc. Follow the guidelines of the LDP (or the appropriate project) to ensure consistency. And don't ignore API documentation.
Testing. It's absolutely asinine that the majority of projects dump untested code onto the end user. You, as an individual, can put a stop to this insidious practice. Start testing the code while it's in a prerelease state. Go over the bug logs and verify that old bugs are still gone in newer builds. If there's any sort of design/req/spec documents, test against those. And submit full, clear and complete defect reports.
Process. All too often the hacker leaves the principles of proper software engineering at work. If you see a project without any formal design or architecture, create some. Ditto for requirements and specifications. You will have to be very tactful with the project members on this issue though. But most developers worthy of the name will welcome your help in this area. You will have to know the code pretty well to do this.
Example code. All libraries and a few applications need example code. All to often they are missing or what they have is cheesy. Write some decent sample code for the project. And write a decent template while you're at it.
The ideas abound. Just use your brain and you'll think of something.
A Government Is a Body of People, Usually Notably Ungoverned
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
Advogato has a good discussion on this. One of the good links from this was Bazaar, in the sense of the cathedral and the bazaar, where there is a list of other peoples itches.
I guess the one major hurdle is getting a understanding of the code, because one program where I found an annoying bug, I downloaded the source, and there wasn't a single comment in the code relating to what was being done. I couldn't for the life of me figure out where to look for this bug, so I couldn't do anything about it. It doesn't matter it bugs are shallow if the water is muddy. See ESR's cathedral and the bazaar to put the last comment in context (yes, I just read it fully again).
- Find a project you're interested in.
- Download the source.
- Compile and run it.
- Find something that needs changing, be it a bug or feature.
- Change/fix it.
- Email the maintainers saying "Hi, I'm new at this, but I downloaded your project and saw a bug, so I fixed it. Here's the source."
- Be amazed as maintainers write back to you saying "Wow! Thanks!"
Presto, you're an open source programmer.That last bit will likely fail in one of three cases. Either you decide right off the bat to tackle one of the biggest projects out there (like Wine or Gnome or something) and you simply get lost in the shuffle, OR you pick a dead project whose maintainers are bored with it, or else the people running the project don't really have the spirit and don't want your help, they want all the glory for themselves.
Kindly do NOT fall into the trap of "Hmm, I want glory and fame right away, so I'll start my own project and then whine when nobody helps me." Not everybody can be the chief, somebody has to be the indians. Show that you're a real team player with some real integrity and desire to see the goals of open source succeed -- join a team. If it's the right kind of team you'll be welcomed right away. There's really nothing that magic about it.
www.HearMySoulSpeak.com
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.
--------------------
Just do it. There's no substitute.
I learnt three things:
I *still* really hate C as a GUI application language
Miguel de Icaza is a *really* nice bloke (he answered an email - I was *so* happy)
If you unfamiliar with a platform/language/API, read the code of the masters. SameGnome was written by people who *think* gtk+. Best practice examples were there for the stealing.
Summary:
Read code by Linus, Alan, Miguel, David Faure[I used to work with David - he coded an XML parser in PL/SQL - 'nuff respect], Ted T'so. And weep until you can at least aspire to that level of purity.
Hack on the code for fun. Get friends to join in. That's why you were given the source.
Never code in C. [I feel strongly about this ;-)]
We achieved a lot. We added several dialogs, a neatly encapsulated network layer, completely re-engineered the 'player' logic (we moved an inherently one-player game to two players - adding more would now be trivial). We had some fun. Do it.
Share and enjoy.
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)
Having learned enough C, C++, and perl to at least read most code (and thus be dangerous), I went through the software I was actually using, and whose code looked comprehendable to me. Psh for one, Xfce for another. Signed up for the dev lists, looked at what they were working on. Downloaded the source to xfce, fiddled with it, broke it, downloaded it again & backed it up this time, messed with some of the smaller features until I found one I thought I could improve. Emailed the project guy, who was very nice, and told me how to get code to him. Borrowed my roommate's GTK book, hacked on it until it worked, and sent the modified source in. My name is in the changelog now :)
So basically, look at the stuff you use, on your system, and see which parts you might want to change. Then do it, and if your changes work out, see if the maintainers are interested in them. My change was probably under 50 lines of code, and there was a bug in it when I submitted it, but it's how you get started.
--
Communication is only possible between equals
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.
This is especially true for projects that export an API, like the Linux kernel. Practically every other OS comes with documentation (in many cases, in print) that describes all the APIs, structures, constants, and so on, so that the programmer can know what's available to him and how it's supposed to work.
Anyone who claims that the source code is enough documentation for any programmer is really fooling himself and doing more harm than good. If I had a choice between source code and documentation, I would pick source code, because at least it's possible to glean the documentaion from the source, but not the other way around. However, why should I have to choose?
By providing documenation, you do the following:
One caveat, though: check your English! Most programmers have horrible language abilities (which I think is really ironic). Bad spelling, bad grammar, and just plain poor writing skills are a serious problem in the tech community. However, good writing skills can be incredibly useful for an engineer. You'd be surprised how much good it can do to be able to write something that other people want to read. I've heard plenty of stories of engineers who have taken writing classes, and then find out that their reports are the only ones that management bothers to read because the other engineers just can't write well! So perhaps we should add a fourth benefit:
Frankly, I think it's a win-win situation for everyone.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
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.
I worked on a the "gentoo" distribution for awhile (www.gentoo.org), back when it was called "enoch", ... it was quite an experience to say the least ...
ultimatley, your contribution will come down to this equation:
[ ( how much time you have to comit / how quickly you learn ) * how well you work with others ]
Free Techno/Jazz/DNB/MI Music by guys obsessed with monkeys!
Therefore I suggest you find some existing project and add some kind of new features to it. Don't pick a huge, complicated project like Mozilla; start small.
As a concrete, specific suggestion: the Gnome version of Freecell has, IMHO, ugly playing cards. There is no way to change them. On the other hand, the Same Gnome game allows the user to load different images for the playing pieces. It might be a good project for you to study Freecell, study the Same Gnome code for loading images, and then modify Freecell to allow the user to load different playing card images.
This is a project that will take a certain amount of studying, but it shouldn't take months of work. To some extent you would be able to cut-and-paste code from Same Gnome, but you would also have to modify it. When it is done you will have something you can show to even your non-techie friends! I'm not trying to tell you what to do, so if you don't like this suggestion do something else.
By the way, if you look at the TODO file in the Gnome Freecell sources, you will notice an item that says "Make card bitmaps library." In other words, my suggestion was already thought up by the people working on Freecell. You might want to look at the various projects and read the notes in each, and perhaps you will see something you really want to work on.
By the way, I have to say I like your attitude. I hope you have lots of fun with this project.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Most of all stay away from jerks like the guy who posted this message.
When punk rock is outlawed, only outlaws will have punk rock.
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.
I have to disagree.
The maintainers of the project are most likely experienced coders, and will not accept a poor patch. The only way to get better at coding is practice, and documentation, while essential doesn't help one code better.
I think it is better to submit code, and have it rejected then to only write documentation.
Once your code is rejected, you can patch that, and after a while it will get accepted.
just my 2 cents.
"This is not a company that appears to be bothered by ethical boundaries."
Attorney General Mike Hatch on Microsoft
The next time (in 1997), it was already a lot more usable, but the optimizer was basically non-existent. Since I liked tinkering with assembler, I started on the peephole optimizer, submitted some patches (by email) and after half a year or so I got CVS access. I've never regretted starting on it.
BTW: this story also contains a quite valuable tip (imho) for people who want to start a (successful) open source project: make sure you are prepared to work on it alone for quite a while until it becomes usable. Only then most people will join in to help.
--
Donate free food here
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
At least they would see working code and have to learn how it works.
Fight Spammers!
improve the slashdot moderating system: this clearly insightful post has 4 "insightful" ratings and 1 "funny" rating and it gets score (4, Funny).
a bug we need to fix?
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.
That said, at least some basic engineering and testing standards would certainly help. Some of the big projects today are as bloated and buggy as anything Microsoft has ever put out, and it bothers me.
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.
I would only add one caveat. Everybody hates to see messages with subject lines of "Please help a newbie!".
Doug Alcorn
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 the original questionner was). This is only speaking for myself (and I've had limited experience with open source projects) but I would expect that many people are willing and open to working with inexperienced programmers, as long as they know that's what they (the experienced ones) are getting into. It is extremely gratifying to know that you've helped someone learn more about a language or programming technique, or even about life in general, but just as frustrating when you expect someone is capable of performing some task (as he claims) but is not up to the job and you get back shoddy work.
The best thing to do IMHO is pick which language you are most confident with, find a small app written in that language which interests you, and see if you can understand the code. If you can, see if there are any features you could add on. If you can't understand the code, look for something else, or try a different language.
And yes, the best way is to just jump in, heck this is the Internet, it's not like you have to walk up to a crowded room where the average IQ is over 200 and introduce yourself..
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
If you are inexperienced then the best way you can contribute is by building your skill set and following some open source projects without contributing code. Wait until you're a little more seasoned before you jump onto someone elses project. The open source community needs good experienced coders more than anything else.
Alternatively you could find or start a small open source project that has other inexperienced programmers.
I'm now a well respected project leader but i dread to think of the contributions i would have made to a project when i was a high school hacker. Writing code is easy, writing good code is hard but writing maintainable code seems to only come with experience.
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
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 someone who's worked on numerous open source projects and reviewed some too, I can say if they need anything, it is definitely more inexperienced programmers. It's just too hard to find them these days!
On a serious note, think of something YOU want to do, and start out on it. Even if no one joins up to help you, you will then have this to your credit. The inspiration for a program needs to come from you though, good luck.