Thanksgiving is the most American of holidays. It’s a day we reserve for remembering how good things are. That we do so underscores what the rest of the year is for: Acting on our desire for improvements.

Since the atrocities of September 11th, many Americans have wondered and worried why “they” hate us. But there’s no answer: Hatred doesn’t need reasons. Some leaders cultivate the emotion for its own sake so they can then direct it at targets of their choosing. The leaders don’t feel any hatred, only the desire for power, and recognition of who their enemies are. For Osama bin Laden and the other Taliban leaders, America is the enemy.

What makes us their enemy? Is it our prosperity? Our embrace of religious pluralism? The concept of freedom itself?

I don’t think so. More than anything else, I think we’re engaged in a battle between our plan to live in the future and their desire to live in the past.

If we have a national religion, it’s a belief in progress — that through our own efforts we can make the future better than the past. We’ve been to the moon and yearn for warp drive; the Taliban preach that everything worth knowing was written long ago. They fear us because they understand what will happen if their people start to believe in progress.

Progress is the point. Affluence is its reward, not the goal. Businesses that remember this, treating financial prudence as a means rather than an end, generally thrive. Those for which profit is the sole reason for being eventually implode from obsolescence and irrelevance.

As information technology professionals we are, or at least should be, evangelists, helping define and promote progress within our organizations. Faith in progress, even though we vary in how we envision it, is our bedrock value.

The term “vision” has been cliched by a clique of leadership consultants who disparage the hard work and discipline needed for its achievement. Nonetheless, vision — definition of what we consider to be progress — is the difference between aimless activity and purposeful action. It’s important.

Enjoy your Thanksgiving. Gorge yourself on turkey and watch football until you’re stupid.

Then, after the holiday, remember the difference between us and them: We’re agents of progress.

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?