Readers Talk Back: OS Choices

Computerworld - "I believe IT managers should dictate the operating system of choice for an organization, not developers, who overwhelmingly wrote to me about the virtues of Linux," columnist Pimm Fox writes in his column, "Don't Leave OS Choice to Developers." "If your company wants to run Microsoft Access or Office 2000 instead of StarOffice, then your operating system choice is going to be made for you without regard to TCO or the technical advantages of Linux."
Our readers had a lot to say about Fox's view of Linux in the data center. Here's a sampling:

The entire article could have been replaced with the phrase "shut up and code."
The "shut up and code" philosophy is nothing new -- I've seen it since becoming a developer in 1984. The "shut up and code" philosophy dictates that the IT manager first asks developers for input into what tools they will use, then disregards all that advice in favor of advice from one of his golf buddies.
To do "shut up and code" right, it's imperative that developers not be told the overall goals of the organization, but instead be kept in a little sandbox. Then, when developers complain about their glitchy, cumbersome tools, the IT manager can say, "You don't see the big picture." The truly adept "shut up and code" manager prevents developers from directly communicating with end users -- instead filtering data that will become specifications and design through himself or one or more of his sycophants who understand little of what is practical to develop.
What's the track record of "shut up and code" development? For years half the projects started were abandoned after considerable expense. Most of the others half came in severely late and over budget.
As an IT manager, what's the alternative?
1. Let developers know the overall strategy and how that affects tool selection. That way they'll understand your tool preferences are based on more than just plain stupidity. If they can can suggest a way a different tool can achieve the same high level goals, keep an open mind.
2. Give the developers complete access to end users. The end users enjoy the attention and the ability to provide input into the final product, and the end user/developer communication results in a better product.
3. You pay your developers to develop. Give them decent tools, and listen very hard to their input.
4. If your developers overwhelmingly extol the virtues of Linux, they know something you don't. Investigate.
5. About your golf buddies: Unless