Itches You Shouldn't Scratch

You've probably heard this sage advice about figuring out what open source software to write: "scratch your own itch." The intent of the advice, of course, is to tell you that the easiest way to choose a bit of software to work on is to find something that you want and write it. But easy though this advice is to give - which may account for why it's given so often - there are times when it is, I think, just flat-out wrong.

The problem is that an awful lot of developers have the same itch - and they don't always look around before they scratch it. Think about the number of text editors in the open source world, or the number of CMS's, or the number of Rails documentation sites. Don't we already have enough of some categories of software?

I'm not suggesting that the large incumbent open source projects are perfect - far from it. What I am suggesting is that there's very little chance that a brand new bug-tracking system, say, is ever going to get much traction in a world where there are hundreds of choices already. If bug-tracking is your itch, you should think long and hard before scratching it, well, from scratch. Your efforts are much more likely to be useful to the community if you get involved with an existing project and improve its code instead.

Being part of an open source team isn't as much of an ego boost as being the lead on a new project. And it can be hard to come into a large existing codebase and get a good enough handle on it to contribute effectively. But you have to ask yourself whether you're coding for ego, or to have some well-used software that you can say you're a part of. For most developers, the long-range benefit of success should be more important than being the lead developer.

And if you do have a unique itch, or think you can beat out all the existing products in a niche - go for it! Just don't be surprised if the world doesn't beat an immediate path to your door.