Top White Papers
Apparently the "Many Eyes" Need Glasses
While Steve Ballmer cheerfully spreads his brand of Fear, Uncertainly, and Doubt, never let it be said that Microsoft doesn't let all of its employees join in on the fun.
If you think that the patent trolling comments are the only thrust of Microsoft's relentless attacks on Linux and open source, I am sad to inform you that this is not the case. The company has many ways to disseminate the FUD, and it's not coming from just the top.
Take this article on Microsoft TechNet I found this morning. In it, Senior Product Manager Pat Edmonds writes a lengthy piece about how the "Many Eyes Makes Bugs Shallow" mantra of open source development is just plain wrong.
If you hadn't heard this one before, the "many eyes" statement was a phrase coined by Linus Torvalds when describing the fact that since open source code can be seen by anyone who cares to look at it, the number of bugs that are caught and fixed increases dramatically.
In the article, Edmonds postulates that the many eyes process is not effective because, for one thing, not all of the pairs of eyes are qualified security experts. Therefore, he reasons, a lot more bugs are going to slip by because people are not going to know what to look for. Oh, and because searching for bugs is boring, no one will want to do it:
"In reality, the 'many eyes' mantra for Linux security has largely been disproved for two primary reasons. First, it assumes that all of the 'eyes' are qualified to know what they are looking for. In reality, security expertise is not widely distributed across most users, but is actually a fairly rare and valued skill set. Second, the 'many eyes' argument implies that all the 'eyes' want to voluntarily peruse code for bugs. Actually, debugging and testing code is not necessarily one of the more exciting pastimes for many volunteer developers, who more often than not would rather devote their spare time to creating the next great application.
First off, who disproved this notion? Because no one let the Linux kernel developers know about it. Oh, wait, Edmonds quotes an open source expert:
In fact, this quote has been highlighted on Microsoft's anti-Red Hat page for some time, and Laurie has already addressed it quite well, including the fact that he was never "Director of Security" at the Apache Software Foundation. So, not only is Edmonds writing FUD, he's giving us recycled, months-old FUD. Which is still factually and contextually wrong.
I think I'm insulted.
To make matters worse, Edmonds also throws in the series of "studies" conducted by Jeff Jones on the security vulnerabilities of Linux versus Windows as proof that what he is saying it the honest gospel truth. With pretty graphs.
I love pretty graphs. Let me link to the first one, just to show you how pretty it is.
In it, we can clearly see that in the first six months of their respective releases, the Windows applications had far fewer bugs than the Linux distros examined. Not only that, some of the Linux bugs disclosed are not even fixed yet! Horror of horrors, because you will note that all of the Windows bugs were all found and fixed. No outstanding bugs remained.
Except, hm, that doesn't seem right. The logic of this graph seems to imply that there are no disclosed Windows bugs waiting to be fixed internally at Microsoft. Huh, that's funny. So what Microsoft is trying to tell us is that once bugs are found (spontaneously, it seems), they are instantly fixed.
This is perhaps the biggest flaw in this graph. At the end of six months, Jones is indicating that there were no flaws in Windows waiting to be fixed. This means either Microsoft had indeed only found and fixed everything it could in six-month's time (just 10 bugs in Vista! 10!), which is frightening because we all know there were bugs found in Windows at Launch+7 months, +8 months, and so on. Or it's frightening because (and I think this is the reality of the situation) there were bugs that Microsoft's security team was working to fix in the Windows code, but because they weren't disclosed, they didn't count as open and unfixed.
In one single graph, we see the huge flaw in Microsoft's attitude towards security, which is the "whatever makes us look good" model. Microsoft only reveals bugs right before it issues a fix. Or right after. Either way, that means customers are unknowingly running systems with bugs that Microsoft is aware of but chooses not to share information about.
If Jones' graph is true, that means that at least customers running Red Hat Enterprise Linux 4 Workstation are aware that there are vulnerabilities in their software and can take steps to reduce their risk. I find that a much better position to be in.
And that's another thing about Edmond's conclusion: if open source developers are indeed so unskilled and so uninterested in finding bugs, how did they manage to find and fix more bugs than paid, hard-working experts at Microsoft (and Apple)?
While it is always fun to poke holes in recycled statistics that are supposed to actually prove something, I want to point out the sub-text that I get from Edmonds report. The one piece of FUD that is not recycled, which I think we will be hearing a lot more of in the weeks to come.
The line of attack will be: sustainability. In the context of vulnerabilities and bug fixes, Edmonds cites open source developers as being too bored, too interested in other features, or too incapable to handle big, enterprise-level projects. I think that's the new message coming from Redmond these days, and this report was replete with it.
This may not be just FUD, however. This may be what Microsoft genuinely, secretly believes about open source development: that unpaid, hobbyist developers don't have what it takes to sustain real, lasting projects. Only paid developers do, they think. Thus, it becomes ever necessary to stop commercial vendors like Red Hat from making enough money to start paying more developers.
This is the waiting game I think Microsoft is really playing. Throw out patent and litigation FUD to try to slow deployment of commercial Linux and open source products, while waiting out the open source community until they move on to something else. Watch and see.