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 think you need to document your journeys. See what you yourself are lacking and as you learn, make sure you publish it: the journal of the lessons you learned while learning how to program in larger environments.
Project leads like it when a person can submit a diff or patch that requires minimal effort to add to their project. Get familiar with writing a proper patch and you'll be able to do small-scale bugfixes and additions even on the big projects.
With respect, the experience you have doesn't sound like it is going to be enough to help you produce anything for public consumption yet.
:o)
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.
Programming does not involve the higher mental faculties. It's a lot of drudgery. The reward of doing it is a feeling of satisfaction at completing a hard task. Mathematics and Physics give you a different kind of reward: one of finding or inventing something beautiful. Doing something good in Math or Physics requires giant leaps; programming requires lots of tiny steps. The result is that most programmers are not very smart people; they rely on hard work mostly. So, don't be intimidated by them. So, if you want to program, just give it a shot; you'll likely succeed; but if you're really smart do something else. -C
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.
integrate StarOffice, Apache, and Perl into Mozilla. Immagine the possibilities!
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/
Get involved by digging into the source code, then writing about what it does. Programmers desperately need detail about the tools they use, regardless of the platform they work on. Writing summaries of functions and data structures is an excellent way of contributing to both the community and an individual project.
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.
The FreeBSD project is always looking for developers, depending on your interest/skill level you can be involved in many things dealing with the project.
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,
- Alfred Perlstein - Programmer and Administrator, Wintelcom.
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.
Slashdot: Where nerds gather to pool their ignorance
The main problem with IDEs in Windows is that once you create a project using one of them, you're pretty much limited to just using that IDE, or shifting the project wholesale to another IDE. In OSS land, that would never work, you would limit your target developer audience to the fans of that particular IDE. IMO, OSS projects need to be equally accessible to VI, EMACS, KDevelop, etc. users.
- 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
IMHO The best way to get experience in writing software and in practicle programming is to write as much code as possible that you CARE about. Writing code for a project that you are not interested in will leave you bored and unwilling to finish. Think of a little utility that you are always saying "I wish I had a program that did X" and then write a program that does X. Maybe you want something that renames all your MP3s to their ID3 tags, or maybe you want a little program that reminds you when your girlfriends birthday is by sending you an e-mail. These things have all been done before, but by finding an "itch" and scratching it you gain experience and something new to add to the list on Freshmeat :)
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!
Problem number one is figuring out how large projects are organized and compiled.
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.
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
wget ftp://ftp.envy.com/pub/mud/servers/Envy_22.tar.gz
-dk
-dk
Dream with the feathers of angels stuffed beneath your head.
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.
I feel your sentiment exactly. Opensource is both very rewarding, and intimidating at the same time. I am a converted NT admin/user. Got hooked on SGI machines :) My first thought when I looked at Open Source was 'what a fraggin mess!'. How could anybody even size up a few projects, let alone code something for them. Here is my progress so far.
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.
Blogging because I can...
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
when you're good enough, you'll just write the stuf.. as long as you don't join the dark side, you'll be fine. In the mean time, learn at your own rate. A few tips about open source :
:-)
:-)
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
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!
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.
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
Or how about another IRC client? The world desperately needs more ICQ clients, too. Maybe you should work on a MUD? Also, there is a desperate lack of alpha release "slashdot style" web board engines on sourceforge...
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?
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.
--------------------
Don't put words in his mouth. He claimed only to have taught himself these languages, and openly admits to being inexperienced.
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.
I was like Daniel coming out of High school. I taught myself several languages, but had almost zero experience. I tried to get into driver programming for some amateur radio equipment and had little success in actually writing the code. What I did get out of that experience was a better understanding of how drivers worked. The documentation for the drivers that somebody else eventually wrote were lacking beyond belief, and I found a void that I understood well enough to put into text. Mind you, I am no English major... While I can generally put the technical stuff onto paper, I have to rely on somebody to proof read for me... (read; my wife). The whole idea here is that there is more to the open source project than just the code. The Documentation is just as needed, and maybe what you are good at.
Some days I get the sinking feeling Orwell was an optimist.
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.
One of the things a good C/S education (from college, usually) can do is help you side-step /many/ of the common newbie errors, and expose you to about many of the elegant ideas that Very Smart People have come up with over the last fifty or so years. Writing code is an artistic endevaour, but whether you use photoshop (vb) or mix your own paints (assembler) knowing about perspective (efficient algorithms) is going to help you.
-_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
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.
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
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)
You could always find a project of some interest to you that takes plugins, and write a plugin.
You can document something.
You can write something new.
________________________________________
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
You remind me a lot of myself a year or two ago. I'm in college now studying cs, but I got a headstart because I've been coding for awhile. I found myself in the position you were in awhile back.
;)
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*
Overcomming programmers block (slashdot article)
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.
Be Free: Free Software Tuition
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.
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
This is a GOOD point! The most valuable thing that you may learn is how to work well with others on a project. Working on a medium-to-large size project with 30+ programmers is VERY different than what you're probably used to. There are many factors which you probably haven't been exposed to that are of paramount importance in the "Real World." You should try to get as much of this experience as possible before you hit the job market. Employers look for this sort of thing!
In short: Don't be afraid to work with larger teams on bigger projects; this is good experience for the future!
665: The mark on the forehead of Satan's slightly less evil brother, Stan.
SourceForge currently has a Help Wanted page with 61 projects looking for developers of all skill levels. Skill requirements include PHP, Perl, C, Java, C++, MySQL, etc.
Check it out!
They call me the working man. I guess that's what I am.
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
If there is a project you like, but the code is to large and complex, chances are there is whole bunch of people in the same situation. So it may be useful to document the code, api, internals or whatever. Pick a small piece of the code, go through it, figure out what is going on and document it. Then continue with another piece. This way you will produce something very valuable, and chances are that somewhere in the middle, you may find a bug or a way to do things better.
AccountKiller
I was about in your situation a few months ago (except probably younger, I'm still 15 :)). Anyway, you described me pretty well - self-taught, no formal training or experence, PERL/C/C++. All that. It's me.
/proc/net/dev and printed it up. But the UI sucked. Anyway, I wanted to be able to just look over and understand it, so guess what I did? I wrote a new UI! I submitted it to the guy running the project, it was accepted, now I'm even mentioned in the credits.
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.
--Justin Mitchell
"2nd Place is a fancy word for losing" --Bender (Futurama)
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.
It's definitely a good idea to look for a small project to get involved in.
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
New programmers can jump right in and help, that is not the problem. The real question MUST be: How can open source help those of us who are not at all interested in learning how to program, or even learning computer technology. We are totally lost in the computer language and must even resort to WYSIWYG HTML. Some, even, must let other do that for them, such as a legally blind friend who is a published poet, but who's eyesite is too poor to do the HTML.
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.
Retired dinosaur, simple user, volunteer, guinea pig
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
Really! Open source projects always need cash. Lots of cash. Preferably unmarked tens and twenties. You can send them to me and I'll be sure they get into the right hands.
:^)
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
Also check out kdevelop--you can tell it to use an external debugger if you want--I would also recommend DDD. (You can find both on freshmeat).
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
Find a job at www.dice.com, etc., that involves working on an open source project. Lie your way past the headhunters and say that of course you have X number of years working on "linux kernel" (just another tech buzzword they don't understand). In your interview concede that you know little or nothing, but show what a sharp youngster you are, and how very much you want to work on the Linux kernel. Say you're willing to be very flexible about pay.
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? ROFLMAO Thanks for that little gem. People will be hearing it around my office for sure.
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'm facing a similar situation as the person who posted the questions to /.
I am considering going back to University for a second degree, this time a B.Sc. in Computer Science. I would like to learn to program everything from low-level drivers and kernel work, up to end-user applications. I'm not sure if one person can cover that scope of programming... is that possible?
Does anyone have advice on how a person can learn to write low-level device drivers?
I once was reading about DEC's commercial Unix OS, and the fact that it had (according to the Byte article) highly-optimized drivers. If I wanted to write such drivers, what level of detail will I have to get into?
For example, a hard drive driver. Does a highly-optimized driver require writing assembly code for the DSP in the actual drive? Or assembly code for the IDE/SCSI controller?
Thanks for the tips!
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
I have exactly the same experiences as you have. Especially in my beginning years on Linux, I really wondered how it is that one can "contribute". Even though all this code is available and around, something keeps you from working on it, and you think it's lack of practical experience -- but how do you get pratical experience then?
;-)
For one thing, I think I didn't get much experience because I am a theoreticus; I love learning about algorithms etc., but when push comes to pull, I haven't written that much code as of yet.
I have been working with Linux for at least three years before I passed the "Hello, World!" phase, but meanwhile I learned everything from assembly boot block to GNOME programming, and as a result I can now say "Hello, World!" in a lot of languages
It is only the last few months that I realize that I've read about every book in the school library and about every doc on UNIX programming, that I say to myself: "Stop doing theory. Act!" And now I am, actually, amazed at what I can. A few web sites I help on, needed a few scripts. I wrote one, and I found another on the web and enhanced it. I never before did Perl, but thanks to my basis, I learned it really quickly. Now, I've got myself a few toy projects in GNOME. Again, I never really coded in GNOME, and some parts aren't that intensely documented. But being eager to find things out, I made myself some test programs for a few GNOME libraries, and thanks to the clean-ness of my code, I had very little trouble combining them into one bigger program for my toy projects. Lots of more ideas are in my head.
So here's my advice: go out and play with the code! Give yourself a (small) task and then "just do it." Don't think it's hard: read docs, ask questions, and show yer code. It works, even though it may take time to get used to it.
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I think the perfect way for you to get in to open source/unix would be to fix a problem you see. In this case, help the compiler/IDE projects! This will help you understand how Open Source projects work (if you need it), and make a better development. It's killing two M$es with one nuke (alright, that didn't make much sense, but we don't kill birds with stones anymore)!
They that quote Benjamin Franklin on liberty and safety deserve neither.
I use micq, Matt's icq clone, because I like having a terminal shell icq client. Here's a project for you. I'd like to be able to fix mispellings in outgoing messages with the s/foo/bar/ notation, which would change foo to bar.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
Play nethack, or a similar open-source game. This is a game that in order to get good at, you'll need to spend time wading through the source. It's well written, and you can generally find the right piece of code using "grep". As you become more familiar with it, you can experiment making changes and enhancements to the game.
Oh, and you'll have fun playing a great game while you're at it :-)
Also, if you're interested in learning more about programming UNIX, I heartily recommend Advanced Programming in the UNIX Environment by W. Richard Stevens. It takes you through just about every UNIX system call and explains not only what it does, but how it works. This is the sort of book you'll still be pulling off the shelf to reference years down the road.
The most important thing is to keep at it; read, tinker: learn.
The more you do, the more you'll learn, and the more you learn, the more you'll be able to do.
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
Learn object oriented programming with some real OO language (like Java or even Smalltalk). When you have actually implemented some real world software, and feel that you get the point of OO, move into C++ or whatever you want/need. You will notice that learning new languages and libraries is trivial.
Early on, avoid messes like GNOME/GTK+ or perl like plague, unless you want to rot your brain. Later you will actually be able to grasp what is wrong with them.
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?
There's plenty of stuff for just about any level of programmer listed at http://www.gnu.org/help/help.html
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.
If you want to get your feet wet without jumping in and sinking, try taking something you like and coding it again. You can focus on the bits you want to learn.
Try writing another napster client. You can fiddle with the gui, or you can concentrate on the networking...anything. There are certainly enough open source nap clients out there to play with.
At least you know how it's supposed to work when you're done, and there are usually enough "personal" versions out there to compare yours to. I'd suggest starting from scratch, otherwise you might get stuck into the limitations of someone else's design...which would be such a great learning experience.
This is how I learned to program Xwin/Motif/Unix almost 10 years ago. I had a favorite file browser on my amiga, and back then (pre-linux??) unix file browsers were pretty limited. I actually went so far as to GPL the code, I just never released it.
My point is that you should start somewhere, anywhere. This worked for me, and I still reference that code from time to time.
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
I find myself in this position myself, although perhaps a step removed. I am attempting to scrape together a Linux system to work on (I think I might be able to do it soon).
Once I have a machine to develop on, however, my question is what software (development environment basically) am I going to need to do this? What basic documentation should I read to gain an understanding of the *nix environment as developers see it, specifically for development in GNOME?
_______________________________________________
All circuits busy.
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. :)
Try http://www.asynchrony.com I haven't joined yet, but it looks to be a really interesting thing, and you get to choose between Open Source and non-Open Source projects! The Open Source ones don't make you as much money, but they're Open Source, and that makes it cool....the non-Open Source ones make you more money, but...well...you get the point.
I'm in the same situation. I've got a project course this semester to write a simple instant messaging client with encryption technology and a key/contact manager being the main feature. I'm fairly confident I shouldn't have too many problems doing this in java (my current plan), but what I'd really like to do is write it in C on/for linux. Unfortunately I am still a linux newbie and am worried I won't be able to finish it. My current plan is to use as much code/libraries from other people as I can and just try and make it dance. My main fear is that there will be some stuff built into java that will make it so much easier, and will take me so much more time on "C". I really don't know if this is the case. Any suggestions/comments appreciated.
Find a application you enjoy. Start sending in patchs, after a while either you'll be asked to be a developer or ask them. Just beware of certain projects out there that don't want other developers. Theres is quite a number of them, I learned the hard way on about 10 of them.
until (succeed) try { again(); }
until (succeed) try { again(); }
Well, maybe Windows Programming isn't your cup of tea, but if you want to learn about it, I would suggest writing a few Litestep modules. This is good way to learn Windows programming because you can make something small or something big and there's plenty of ideas floating around at Mind Junction. It's also nice because you can write things that you want to write.
(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.
You better have.
If you don't can use vi or Emacs then you won't be of much use in any project as a developer.
Don't let that stop you. What is most needed is docs, not code.
Suppose that I write some pretty decent comments every time I write a new function. Then some night around 2am when I'm adding some little feature or stalking a bug, I don't remember to change the comment along with the code. Now the comment may be worse than nothing - it could be actively misleading. Even if no one else ever reads this code, I am going to be pretty ticked at myself when I try to figure out what is going on in this function six months later.
This is why undisciplined people like me would welcome newbies to look over the code and say "Yo, I think you have some documentation rot here, let me fix that." We have plenty of comments in our code. It's just that half of them are wrong.
Also, never drink and code, but that's another story entirely.
"The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life"
Thank you!!!! and keep up the GREAT work.
You are right. There is a lot of complaining but hardly any thanking.
DRM? No thanks, I'll just get it somewhere else...
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.
First, I'll qualify that statement :-) I've been programming on and off for some 16 years starting from ZX Spectrum basic (at age 8), through Z80 machine code (age 12) to designing and building my own system and coding on bare metal (age 16) to get it to accept data from and send data to a terminal. I then learned visual basic (and I won't add that any skill I had was destroyed!).
Therein followed a break of quite a few years whereupon I learned Perl (a truly wonderful language, all praise be to Larry Wall and other deserving idividuals). I'm working on a couple of private projects at the moment (to keep my hand in and for fun too - visual control interface for CERN-HTTPD webserver and a simple program which uses Wigner's theorems to calculate the charcters of irreducible representations of a few simple point groups (much easier than it sounds)). The question is this: where do I progress to?
I tried reading a book on C++ when I was 17 and it made no sense to me whatsoever. The problem in part is that I am totally self-taught so when someone talks about dynamically scoped variables and other such bizarrely named thing I have no clue.
Any ideas?
Elgon
Not reinventing the wheel is also good, but thats been stated above :)
Welcome aboard,
Scott
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
^^^ What an asshole! ^^^
Get my free Hitchhiker's Guide Tribute Novella:
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.
I've been programming for quite some time now. I'm a first year in Uni, and I'm currently doing a (non-uni-related) project which has reached around 2,000 lines so far. Your best bet is to try adding features to smaller GPL programs, and work up to larger ones. Don't expect to be able to just look at a program and understand it. You've got to spend some time just looking through the code to see how it's structured.
Help with Miranda
http://miranda-icq.sourceforge.net
I thought I was the only inexperienced programmer here. I'm a junior high school student, and like you I got intimidated with the fast changing open-source world. It seems it's a really fast race. I also learned programming by myself. But gaining real experience seems haunting. So I started to join a starting project and inquired for a small job. I asked for the job of a web designer. Luckily, I got it. I also told them I can help in LaTeX formatting and some small c++ coding. I wish you good luck and other "inexperienced" programmers out there!
I had this problem back in high-school. I loved to program, but there just wasn't anything I could do due to my lack of in-field experience. Once I got into college I joined a research team. At my University we do a lot of work in *NIX, I got a great deal of experience in writing massive programs and software that is widely used.
lim brain -> meltdown