The roller coaster of Open Source

Frank Zammetti, wrote this, and as I'd written bits of this, he asked me to write a forward, which goes something like this:

The funny thing about getting heavily involved in an open source project is the roller coaster ride you embark on. There's the buzz from seeing the hits to the web server and reading what people think of your project. There's the gnawing feeling of responsibility when you discover very large websites using your code, and you're worried about bugs you might have created. There's the total flat feeling when a friend tells you they're taking your code out of a project because they prefer an alternative; and there's the burnout when you just can't keep up with the volume of work, and realize that a huge percentage of what you do is not directly development related.

My experiences with open source have opened a huge number of doors. I've met people that I wouldn't have met otherwise and had job offers that I wouldn't have dreamed of before. There really is a magic buzz to open source.

Marc Andreeson, one of the minds behind Netscape and Ning, wrote recently about how to hire good developers. To paraphrase Marc: "Hire someone that has worked on open source software".

Some companies rate candidates using trick questions: they get the developers that are good at typing "interview questions" into Google.

Some companies rate candidates using industry certifications (MCSD, SCJD, etc): they get people that work at rich companies that depend on training not talent.

Some companies rate candidates using CVs/resumes: they end up hiring ‘talent embroiderers’.

Some companies rate candidates using interviews: they get the people that sound good and look good.

Unsurprisingly, these selection techniques don’t get you the best candidates. So how do you find the developers that love writing good code, that get a buzz from solving the problem in a neat way, and that do take pride in their work?

The answer according to Marc, and according to my experience, is to hire people who love their work enough to get involved with a project that was optional.

So here's your invitation to get a leg up on getting a job with people that hire great developers—get into open source development. It doesn't have to be DWR, although we've love to have the extra help. Just pick something that excites you and get involved.

The problem with getting started is a typical crossing-the-chasm problem. The first few minutes are easy. You’ve used a project, liked it, and maybe joined the mailing list. You might even have found something you would like to work on. When you are involved in a project, you know what you are doing and can contribute. But there is a chasm between these places where you are learning the code, learning how the project does things, learning the process, and so on. While you are crossing the chasm, you are unproductive because you are in unfamiliar territory.

So here are a few hints about how to cross the chasm. First, find somewhere that the chasm isn’t too wide – start by fixing something small. The chance of any IT project failing is inversely proportional to the size of the project. Start with a simple feature that makes something better. Almost all IT projects have these in abundance.

Second, don’t think that because it’s tricky, you must be stupid, or the project must be misguided. There are always reasons why things are tricky. The answer could be historic: when the code was written, people didn’t expect the code to be used in this way. Or maybe there is some refactoring that needs doing that hasn’t been completed. DWR’s code is fairly good because the code is young and we’re fanatical about re-factoring, but some projects have more history to them.

The difference between those that can cross the chasm and those that can’t is - drive. You don’t need to be a genius, to have a brilliant CV, or to look good at an interview. Even the ability to type ‘interview questions’ into Google is optional. The people that can cross the chasm are those with the drive to succeed.

Getting involved can come in many forms, and sometimes it's even sort of tangential to the project itself, such as writing a book about the project. Sometimes the tangential help is some of the most valuable. The things developers leave out are often things they are bad at. For years I’ve wanted there to be a DWR book, but known I’m the wrong person to write it, so I’m particularly pleased to see Frank step forward to write the first DWR book. Thanks for having the drive to get involved, Frank.

Practical DWR 2 Projects by Frank Zammetti is out today - officially on the 30 Jan. You can order it from Amazon and many other good bookstores.