Vuja Dé: An experience like nothing I’ve ever seen before.

What isn’t vuja de is the e-mail I regularly receive: “Microsoft doesn’t innovate! Windows, mice, GUIs, fonts, keyboards, and the name ‘Bob’ all came from someplace else — Microsoft just repackaged them.”

It’s a perfect non-sequitur. Henry Ford didn’t invent the automobile so by the same logic, the early Ford didn’t innovate, a conclusion that’s simply wrong. Microsoft, as did Ford once upon a time, has delivered real innovation — not, for the most part with grand concepts, but in terms of features and integration. Not that all of its innovations are good ideas. For example, if I could ever figure out what Hailstorm actually is I suspect I wouldn’t like it, but I’m pretty sure it would turn out to be innovative.

Which brings us to the question of whether the open source community can be innovative. Eric Raymond, one of its more eloquent evangelists, makes a strong case in favor in his essay The Cathedral and the Bazaar.

Raymond’s first premise is that “Every good work of software starts by scratching a developer’s personal itch.” Whether or not you use open source software, or even like the idea of it, Raymond is only partially right, but this statement does quite eloquently describe the scope of problems open source software can address.

To quote him further, “… too often software developers spend their days grinding away for pay at programs they neither need nor love.”

It’s a fascinating statement, suggesting that when programmers write code in exchange for pay to create value for someone else, it’s somehow a bad thing. But Raymond is looking at the wrong end of the horse. The non-tail end is what’s important in managing your company’s applications.

The open source community can create great software because its developers understand the problems they’re trying to solve in their bones, not just by reading printed specifications. This eliminates the need for the time-consuming, tedious, and usually self-defeating methodologies IT has created to figure out what business applications should do. You can use this insight to your advantage.

Want your developers to deliver great software? Get them away from their desks, out into the business where they can absorb the problems you need them to solve into their bones. Once they’re doing the actual work themselves, they’ll devise solutions far superior to what formal methodologies deliver.

They’ll have to. After all, have you ever tried to not scratch an itch?