How Can New Programmers Contribute to Open Source? 135
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?"
Journal (Score:1)
also, learn how to patch (Score:1)
Learn to program (Score:1)
That doesn't mean you shouldn't try though. It's a fact that the best (only) way to learn programming is by doing it. But you should start by absorbing a few decent books on software design.
Assuming that your tuition so far has been mostly language specific rather than focussing on problem analysis and structural design techniques you will need to re-educate yourself from the beginning.
While you are studying up, check out freshmeat.net and try to find a moderately-sized application which interests you from an engineering, problem-solving point of view (not everything is mozilla-sized! Many of these apps have been written by a single person in their spare time. Download the source and get some practise reading other people's code. Critique the structure according to what you have learned about software design. Then consider what changes you would make if you were going to write your own version from scratch.
OK that's the practical. Now here's the theory part of the curriculum (skip any parts you are already *completely familiar* with but don't try to fool yourself about what *completely familiar* means):
You should start with a solid primer on the older top-down, stepwise refinement method and do some of the end-of-chapter exercises.
Then move on read a good college text on the technique which has become known as bottom-up design, i.e. data abstraction and functional programming (the latter does not not necessarily mean declarative languages like Lisp or Scheme though; it's more useful to use strongly typed languages with nested scope, like Pascal and Modula-2).
It is worth learning how to design code bottom-up effectively before moving on to the next stage because that's the simplest and easiest (and therefore the quickest) way to learn how to think in the right terms about the most basic aspects of designing an implementation.
Only when you have mastered that should you move on to object oriented design. Object Orientation is much more finicky and demanding and tends to hem you in to a smaller range of acceptable solutions - but only if you know what you are doing by this point!
If you haven't already mastered the plain old bottom up thing then your attempts at object orientation are likely to be a horrible mess: only half object oriented with poor decoupling because of inappropriately public members and each class's fingers probing deeply into the guts of its neighbours.
This defeats the whole point of OOP. And its sadly typical of what newbie programmers do because in the rush to get people skilled up, many programming courses nowadays are nothing more than an idiot's guide to some particular language's syntax. most usually C++. Unfortunately C++ is the worst possible language to learn first because, while it is incredibly powerful in the hands of a master, it provides so little to encourage neophytes to develop good habits. As a direct result of this most of the C++ code in the world is worthless crap; and a large and increasing proportion of "enterprise resource" object oriented software development is now being done in Java in an attempt to avoid similar problems.
So for the same reasons when you do move onto OOP, you will go further faster if you begin with a relatively strict OO languate like Smalltalk, Java or Eiffel. Failing that go for some form of Object Pascal (like Delphi) or Objective C. Try to stay well away from C++ until everything you write comes out object oriented just because you can't help it. You will know that day has come when you are writing something in plain ANSI C and lo and behold you suddenly realise that what you just wrote was almost completely object oriented and the last several days of tweaking were spent in an instinctive struggle to simulate things like inheritance and polymorphism just to make it perfect.
By this point you should have developed a rational style and learned to write code other professionals will find acceptable.
Then, only then, a Jedi will you be
Of course in the real world (i.e. out of school) it's impossible to follow such a long term battle plan without at least some significant diversions. But if you do manage at least to keep the above in mind as an ideal progression, stay reasonably close to it and avoid rushing straight into C++ you'll wind up a better programmer than those who don't.
Don't be intimidated (Score:1)
an excellent suggestion (Score:2)
OMG! I can't believe what I am reading! (Score:5)
seggy
Here's what I did. (Score:4)
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
And while you're at it... (Score:1)
Small changes (Score:3)
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...
Re:Get involved... (Score:2)
Bill - aka taniwha
--
Re:Get involved... (Score:5)
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
--
Re:I just hate the lack of good IDEs (Score:2)
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?
OO is not an end in itself (Score:2)
> 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.
Programmer Documentation (Score:1)
Read through the code (Score:3)
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
Source code (Score:5)
Perhaps if you want to work on a smaller Mozilla related project check out MozDev [mozdev.org] 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 [sourceforge.net] and look for a smaller open source project you can help out with.
The FreeBSD project always has openings (Score:1)
You can port applications to FreeBSD, this gives you a chance to collaborate with other open source projects.
You could wind up working on the base system, a niche project (PicoBSD, TrustedBSD, etc) or the kernel.
Or you could write and correct documentation in the system and the website.
Best of luck,
Re:I just hate the lack of good IDEs (Score:1)
2. An IDE that uses both syntax highlighting and that will jump to errors by clicking on them.
What's GNU/Emacs do? I suggest you review the tools more closely.
Re: IDEs are generally restrictive (Score:1)
3 things you can do to help (Score:5)
- 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.Learn something! (Score:5)
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.]
Do it for yourself first... (Score:3)
Mike
How to get involved... (Score:4)
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
Write something you need... (Score:1)
If you can't think of something that you really need, then go to Sourceforge and find something that you are interested in. Or, think of a program you currently use that is not longer being maintained or that doesn't have a feature you need. Maintain it, or add it!
The massive amount of source for Linux can seem overwhelming, but if you can get it to compile you can start making small changes here and there and you are getting experience.
Enjoy programming and you will excel at it!
Re:an excellent suggestion (Score:1)
Recently to better aquaint myself with OSS (sound) I took libosd for onscreen displays and wrote a small programm that used it to change the sound volume. Programs that provide api's for plugins is a GREAT way to write from scratch solid programs that are also contributing to a larger goal. We could always use new XMMS plugins, etc..
One of my earlier works was an importer for LW object files into a Slideshow presenter called Achtung!. We could always use more gimp filters too.
Seriously consider plugins as a good way in, it will help you become familiar with the rest of the project. Once you are familiar with the rest of the project, you have now learned how to work with these larger opensource applicaitons.
my experience (Score:1)
If you are unexperienced, it is probably best to finish learning the language. If it's C++, make sure you fully understand how to use classes.. all the way up to templates, because then the source code for a program is actually going to make sense. I don't know any other language as well, but most large projects are going to take full advantage of all the abstraction available in the language.. you've got to know it backwards and forwards as well as whoever wrote the code.
After that, find a project that suits your skill level and just spend a lot of time reading the code. When you come across something you don't understand, look it up. I've spent a few weeks just reading the source code for icewm and dfm, and I've learned quite a lot.
Port a Program (Score:3)
Re:code on a mud (Score:1)
wget ftp://ftp.envy.com/pub/mud/servers/Envy_22.tar.gz
-dk
code on a mud (Score:3)
and it's fairly easy to see the immediate results of your code in the game state
-dk
What I am doing... (Score:1)
1. Got a Unix machine (indy) and installed Linux on an older PC.
2. Set up the build environment on both machines, and started to compile stuff. Learned a lot on this, and have even helped a few people so far with IRIX binaries of xmame. This experience gave me the general structure and practices of a working project. BTW building xmame was an excellent start for me. There were just enough issues on IRIX that I learned a lot about the build process. The added advantage was that I got to play some nice games when I was done.
3. Having made sure that the development environment was set up properly, I began to code small things. Literally went to the net and typed into google 'c programming language tutorial'. This worked very well. Since I can build most things, debugging my own small pieces of code was pretty painless as I understood the difference between a build problem, and a coding problem.
4. Now I am working on something that I like. It fits many of the criteria mentioned above. (ie. scratches an itch, is small, is fun.) My first project was to build an STL (cad design) file viewer using opengl. This I completed on the SGI as that is where I started learning things. Learning OpenGL worked the same as learning C. Typed in the need for tutorials into google, and followed the links from there.
5. Project is basically done. Now comes more learning. Building it on different platforms. This is where the real value is in this process. You get to see how people write things, and what they link against. Some structures and methods are portable, and some are not. My next build of the project was for win32. I was pleasntly surprised to find that my code only had two issues. Changed the code to work on both platforms, and moved on. I am working through Linux now as I have a machine that can do 3D.
To sum this up I am doing what I like, and learning way more than I would by trudging through books and tutorials without any goals. Just to cite one more example. I like Nedit. It has some nice features on the Linux distribution, and one of those is syntax highlighting. Well the guys at SGI disabled those features when they included it as part of IRIX. Learning to build things got those back. Seems like a small thing, but there is a *lot* of power in that. Worth doing, good luck.
Re:Read Miguel's code (Score:1)
Here are a few quick points:
I should also mention some of C's good points:
Please don't read this wrong... LOTS of EXCELLENT code is written in C. And I wouldn't dream of getting rid of C... it is, for instance, a great language for compilers to OUTPUT. But if I had a choice, I'd rather not program in it.
-- Michael Chermside
Just hang on to the ethics.. (Score:1)
1) it's almost all object-orientated C. The best way to learn this is to get half-good at C++, then drop back down to C (C++ teaches proper classes.. once you understand it, you can just "pretend" with structs and intelligent naming of functions (and void*)). You may just prefer to stay with C++.. no problem, but appreciate that you'll piss off the purists
2) ALWAYS be ready to change what you don't like. The whole point of open source is that you can scratch that itch. Don't be afraid to search for that itch in several million lines of code. If the code is so badly written that you can't find that itch, then it's the fault of the programmers, not you.
3) Never give up.
4) Stay cool
THIS IS BETTER THAN MY COMMENT (Score:2)
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!
Feedback both ways (Score:1)
While I accept patches from all sorts of people, they rarely make it into the source as-is: I do exercise editorial control. A lot of times, the patch I receive will omit something like error-checking, or else it doesn't quite fit in with what I'm planning to do with the code.
Sometimes I get submissions from newbies with good ideas, bot who make some mistakes. When I find these, I either try to fix them, or at least add an XXX comment to the code.
In any case, of course, the submitter gets full credit for the patch.
Re:Documentation (Score:2)
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."Christmas tree" architecture (Score:2)
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.
Contribute to what is missing (Score:2)
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.
It doesn't matter if you're not experienced (Score:5)
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 [sourceforge.net] to find a project appropriate to your skill level.
-m
Re:For god's sake . . . (Score:1)
I spent some time flipping around sourceforge looking for a project to help me get some practice with PHP, and my query came back with 600+ hits for projects implemented in PHP. There are a *lot* of projects covering the same ground. How many PHP-based online scheduler/calendars are there on sourceforge? I guess that's not totally a bad thing, but it does make it harder for me to pick which one to work on.
Hey, anyone working on something nifty on PHP and looking for some not very expert help?
Lots of ways.... (Score:3)
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).
What is the perceived obstacle? (Score:3)
- 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.
geez.. dare to dream :) (Score:5)
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.
--------------------
Re:no offense... (Score:1)
Because these statements come so closely together, if you manage to misconstrue them you either have a chip on your shoulder or a sack of shit on your neck.
Don't forget the Docs (Score:1)
Re:Learn to program (Score:1)
Good God... What is this, a college Dissertation?
1. Program
2. Have fun!
If you happen to write something someone can use, then it is a bonus, and you feel good!
Just do it (Score:3)
Just do it. There's no substitute.
Read Miguel's code (Score:3)
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.
Re:Inexperienced == Bad code (Score:1)
-_Quinn
I Take Offense (Score:1)
I'd like to point something out to you that you may not realize, and I'll use me as an example. People can know a language inside and out, and have no 'real' experience useful for getting a job.
For instance, I recently had a code challenge handed to me. It was to read a bit of C code with quadruply indirected pointers. I did it. what's more, I did it without a debugger or even pencil and paper. But I can't get a job programming. Why? No real experience. In other words, since nobody has paid me to code for them, I don't have experience in coding.
Without speaking for the requester, he may very well be in the same boat. He might be able to code circles around other people. But without having been paid for it, it's very difficult to find a job doing.
Documentation! It teaches you everything! (Score:4)
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...)
plugins (Score:1)
You can document something.
You can write something new.
________________________________________
Learn some project, any project. (Score:1)
The best suggestion I can make is this: You need experience in how one goes about creating and working with a large project. You need to know how one develops something so that it fulfills the multitude of functions that make it a large project, yet does it elegantly and efficiently enough that it's modifiable and understandable to new users. At the time when I wanted to get into larger things than yet another tic-tac-toe clone, I was playing around with MUSH (multi-user shared hallucination, a derivative of MUD). I knew the functionality and use of the system intimately, which is a definite plus. It's important to really understand everything that a system does before you dive in and read its code. From there, you can go on a "this is how they did this part" basis, and learn your way through the code. I suggest keeping notes so you remember what parts do what. The important part here is to read all the code you can get your hands on, modify it if you want so that you can see if you really understand what does what, but most importantly, read read read. It'll make you develop your own opinions and theories on large project management, at which point you should feel ready to get into larger projects.
At this point, however, I'm nowhere near ready to tackle the linux kernel or mozilla
And another sidenote: don't learn on MUSH. The codebase has forked so many times and remerged and reforked and I think even spooned a few times. *shudders*
Similar problems with burnout (Score:1)
Overcomming programmers block (slashdot article) [slashdot.org]
Speaking as a burnt out oldie, I have tried to get my skills up to speed by getting involved in a startup (which has open sourced its main project so far) in my spare time. Maybe I just do not have the energy, time and comitment anymore.
My main job just seems like a huge rut with no mentors, or peers in my own small area. My problems are complicated by being manic depressive, but I probably dwell/whinge about that too much. Ok so maybe I should get out more into the local linux or unix user group, (or help some newbies) to find people to sap their enthusiasm like a modern day vampire.
Getting involved (Score:1)
2) Find a project that looks interesting, that isn't too hot, isn't too cold, isn't too hard, isn't too soft, isn't too tall, isn't too short, but juuuuuust right.
3) See if they need help coding or would be willing to take comments.
4) Look at the code and add your contributions.
5) Grow young Skywalker, Grow.
--
In any sufficiently large group of people most are idiots.
Learn something! (Score:1)
In short: Don't be afraid to work with larger teams on bigger projects; this is good experience for the future!
SourceForge help wanted (Score:1)
Check it out!
How I did it (Score:3)
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.
--
Write documentation (Score:1)
Guess what I did. (Score:1)
Anyway, once I got DSL KPPP wouldn't excactly work for bandwidth monitoring, so I went searching on Freshmeat and came across a nice little PERL script that took info from
Anyway, that's my story of getting involved... may you have luck too.
Grades, Social Life, Sleep... pick two.
Re:plugins (Score:4)
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. ]
High Profile (Score:4)
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 [generation5.org] 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.
Start small! (Score:5)
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.
Re:3 things you can do to help (Score:1)
The GIMP would need no manual for NEW users if it just brought up a dialogue asking what file they want to apply the whirl filter to, and then took them to the whirl filter with pinch disabled, then saved it as a BMP and a GIF.
Diablo II doesn't need much of a manual, because there is only one goal, and the game knows in advance what the goal is. It is much more difficult to provide "feedback" or an "intuitive interface" for, say, the GIMP. Making it too easy to use would intrude on the experienced user.
Don't believe me? Feel free to implement your changes. I'd love to try them out.
free software attitudes (Score:1)
Personall, I think the free software community is very elitist. So, probably the only way to get in on something is to get in on something small. Also, realize that at first, you'll probably be fixing bugs for a long time. That's how I got statted at my first proramming job and its a good way to familiarize yourself with the code and catch on to the other programmer's coding styles.
When I was working on Canvas for linux, we tried numerous times to contribute our source back to the WINE community and were rejected numerous times. And I was contributing not only my changes, but changes for my co-workers who have 10 years of coding experience. We submitted our patches as diffs, to the mailing list, and directly to the WINE programmers, but they were never merged into the main branch. And our changes definitely worked, we tested them, we have an entire testing department. Basically, we sent patches in for months that were never accepted.
So, if I were you, I'd lok for a project that only has a few people working on it, who will really appreciate the help.
I think this is really a problem for the free software movement. People need to have more of an activist attitude in trying to get the word out and trying to bring new programmers up to speed.
I'm not looking for flames here, I just passionately care about free software and I've dedicated a lot of time and energy to making it work. I know of course lots and lots of people have, by creating all these wonderful pieces of free software we have. But I think that bringing new programmers onboard should be a high priority.
___________________________
http://www.hyperpoem.net [hyperpoem.net]
How can new programmers help with opensource? (Score:1)
The question is: How can open source and programmers help bring the interent to all the citizans. Please note that the fastest growing segment of the internet is people OVER 50 years old, i.e., your parents and grandparents. Look to them for guidence, they will show you how you can best help. We old geezers did not have to learn how to be mechanics to drive our autos (except way back in the very beginning). We did not have to be radio/television engineers to listen to the radio or watch television. HEHE, for a while, we did have to be engineers for the VCR, though. No, don't ask how one can contribute to the open source, ask how open source can contribute to us. For us, the computer is a major investment, and for now, Microsoft Windows and MAC are the only viable operating systems. I am very sorry to say that the best is yet to come, for until we old, warn out grandma's and grandpa's from yesterday can use Linux INTUITIVELY, then open source will remain a toy of the programmers.
Documentation (Score:3)
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.
--
Send money... (Score:1)
:^)
Re:What you can expect (Score:1)
That makes no sense - if that was the true, the faster you learn, the less you will get done. Something like this would be more accurate:
[(time available * speed of learning) / ('barrier to entry': skills required to be useful)] * ability to work with others
Re:I just hate the lack of good IDEs (Score:1)
For god's sake . . . (Score:5)
--
Start small, gain experience (Score:5)
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 [sourceforge.net] 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.
What you can expect (Score:3)
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 ]
Modify something (Score:3)
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 [gnome.org] has, IMHO, ugly playing cards. There is no way to change them. On the other hand, the Same Gnome [gnome.org] 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 [gnome.org] 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
Get an open source job (Score:1)
That's how I just got a job doing linux kernel development with a big linux vendor (in top 5 by boxes shipped). I start on Monday--I must say I'm a bit nervous, but very happy, too!
heisenbug! (Score:1)
Re:no offense... (Score:2)
Re:no offense... (Score:5)
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
find something you want to fix? (Score:4)
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.
Re:Inexperienced == Bad code (Score:3)
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.
Just do it (tm) (Score:2)
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.
--
Get involved... (Score:5)
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.
Get them to (Score:2)
At least they would see working code and have to learn how it works.
try this project: (Score:2)
a bug we need to fix?
Inexperienced == Bad code (Score:4)
You are more than the sum of what you consume.
Re:OMG! I can't believe what I am reading! (Score:2)
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.
Don't worry, we weren't experts either... (Score:5)
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.
Re:Let them know that you aren't experienced (Score:2)
Re:Get involved... (Score:3)
Ask for things that you want! (Score:5)
Also be honest about your background (Score:2)
Just give it a try (Score:2)
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..
It doesn't work that way. (Score:4)
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.
It takes a bit of push ... (Score:5)
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
The best way to contribute (Score:2)
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.
start with something you like or need... (Score:5)
Itch, Scratch: or how to care and then contribute (Score:4)
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.
--
Let them know that you aren't experienced (Score:5)
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.
Re:How to get involved... (Score:2)
yes! (Score:2)
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.
Re:Just do it (Score:3)