FUD is good for you

Looking at the Declaration of Lawrence R. Goldfarb, it looks we've got the first solid link between Microsoft and the SCO brouhaha. The Wall Street Journal has a story, and so does IDG. The actual declaration has more than our story: Goldfarb talked with more people at MSFT than just the one. But all legal considerations aside, isn't FUD in general a benefit to the company being "attacked"?

People in the IT business complain about "Fear, Uncertainty, and Doubt" directed at their products. The inventor of the term FUD, Gene Amdahl, lost business because of it. But today, other companies' FUD attacks are good for you, and the more of it that I see, the better it looks.

I first started seeing the beneficial effects of FUD in the embedded software market. This is an area of software that depends absolutely on supporting customers who aren't just users, but whole product development organizations. You win ("get a design win") when your customer launches a successful product. Nobody talks about a "design lose" when your customer's product development fails, but you don't want to be stuck throwing support effort at a failure, burning out your support people, and getting no cool product to put in your lobby display case.

So how do you weed out the dysfunctional organizations from your customer base? You can't -- but when the FUD-mongers come along with the "GPL means you have to let hippies camp in your yard and use your bathroom" white papers, they'll do it for you. Several embedded vendors make a habit out of throwing off badly-researched license FUD, which helps keep their less well-informed customers away from Linux.

Not only does that make the life of Support at the Linux companies easier, Moen's Law of Bicycles says, "Good customers make for good products." A "good" customer is one who's not only smart, organized, and capable of telling a good product from a bad one, but has an incentive to succeed with the product. The person in charge of ATMs for a bank has an incentive to buy machines that don't let people walk off with the money; the person in charge of voting machines for the state doesn't have a corresponding incentive not to let the wrong candidate be elected. The wrong candidate, once in office, might even be grateful. So ATMs have better software than voting machines.

FUD is great, isn't it? Drive away the FUD-susceptible customers, and all of a sudden Support is doing a better job, the product is getting better because "better" customers are using and talking about it, and I'm just getting started. Number two reason you want FUD thrown at you is that it can turn Geoffrey Moore's "tornado" of hard-to-manage growth into a profitable trade wind. For example, Red Hat had heinous growing pains around 2002-2003, and needed a breather to be able to catch up on support for Big Enterprise IT Projects, which seemed to be going from pilot to mission-critical all at once. Then the SCO v. IBM case popped up, and 12 to 19 percent of companies considering enterprise Linux projects decided to cancel, postpone, or reconsider. Red Hat got badly needed time to catch up, staff up, and fix up.

Third, FUD-mongers are not liars. Neil McAllister says BEA CTO Rob Levy is giving the media "half-truths and misleading facts", but it looks like Levy's OODA loop is just messed up. Observe, Orient, Decide, Act -- you have to be doing all four at the same time. If you're observing too much of your own FUD, and you've internalized FUD-friendly biases that get you oriented wrong, you lose. John Robb writes, on the dangers of propaganda, "Facts are misinterpreted/misrepresented for marketing externally, these tainted facts are consumed by internal audiences, and bad internal decision making is the result."

Finally, sometimes FUD efforts actually reveal useful information, more than the FUD-monger intended to. FUD-mongers aren't out to lie or deceive, so sometimes their efforts actually raise a concern that the FUD-monger and its customers have, but that you haven't paid attention to yet. The Mindcraft benchmark showed off a performance advantage for Microsoft Windows/IIS over Linux/Apache in one fairly rare hardware configuration. LWN: "Two months after the benchmark, the TCP stack was fully SMP threaded; five months after that the entire networking subsystem was fully parallelized. The end result: last months Specweb results which blow away everything else."

As we all know by now, Linux needs some development work in the area of power management. There is a lot of hardware on a modern server that can be safely shut down, and should be safely shut down if you want to be kind to people's power and HVAC budgets, but that Linux leaves running for lack of some yet-undone coding and testing. And imagine the consequences of 30 millisecond resume from suspend times on a lightly loaded small office server. So where is the FUD-monger who will put out the "Power-hogging Linux to be illegal in Kyoto-signatory countries" press release? The Linux industry could use him or her right about now.