
"If I Get Paid Lots of Money To Write Articles Online, Why Am I So Dense?"
Andrew Brown of the Guardian wrote an article in which he uses OpenOffice to prove that open source is a failure as a software development method. Without wasting too much time on the obvious logical fallacy of drawing conclusions based on a single, non-representative sample, I will also point out several additional (and less obvious) flaws in his logic and provide counter-examples to help illustrate that Mr. Brown is either woefully misguided or under the influence of a Microsoft payoff.
Of all the myths that have grown up around open source software, perhaps the most pervasive is Eric Raymond's aphorism that "Many eyes make bugs shallow", suggesting that if lots of people can view a program's source code, they will find and fix its errors more quickly than commercial products whose code is jealously guarded. The only problem with this is that it's not true
...Except that it is true. Anyone who has spent any time at all developing software can attest to the fact that it's a lot easier to track down bugs when there are as many sets of eyes as possible looking at the code. In fact, I can't even count the number of times I've stumbled on the most elusive of programming blunders simply by trying to explain to someone else why my code couldn't possibly be doing what it was doing. :-) While I certainly won't claim that it's a sure thing, given the choice between bug-hunting solo or being one member of a team of debuggers, I'll take choice #2 every single time.
The myth of open source rests on two improbable assumptions. The first is that a significant proportion of users can fix bugs. That is true at the Massachusetts Institute of Technology, where the concept of open source was first formalised in the 1980s by Richard Stallman and others, and it is true in some of the geekier corners of the internet.
Okay, first off, RMS did not formalize open source. He'd be the first to tell you that he's about "free software," which is the computing equivalent of a hippie commune, and not "open source," which is about explaining the strengths of a less shrouded method of developing, testing, and deploying software products to the decision makers in business who don't understand or care about the idealistic politics associated with RMS and the FSF. Using the term "open source" while referring to RMS is like citing the famous "I Have a Dream" speech of David Duke.
Secondly, I don't know a single open source developer (of which I most certainly am one) who actually believes that the majority of users know enough about programming and software engineering to locate and correct erroneous code. I will say vociferously, however, that no one is better at triggering bugs than users who can't code!
But what's missing here is one undeniable fact: open source does not make bugs any harder to find! Let's take his example of OpenOffice. As the article states, Sun employs about 100 full-time developers for OpenOffice. Those 100 people have access to the code and are able to find and fix bugs regardless of whether OO is open or closed source. So at best, the project is no worse off open than closed. The power of open source comes from the fact that more people can access the code. And even if there's only 1 additional person on the entire planet who can help the Sun-employed team find/fix issues, open source is advantageous.
No, it's not always the end-all and be-all solution, but it sure doesn't hurt.
This is important because of the second crucial false assumption: that even if not all users can fix a bug, they can help find them. They can't. Most users just think: "The computer isn't doing what I want."
Same problem as before. Even if 1 additional user can find/fix a bug, the team is better off. There will be users who don't understand problems with software regardless of the development methodology you employ. Mr. Brown implies that making the source available somehow makes users less able to find bugs. Those users who can't, can't, regardless of whether or not the code is accessible.
Companies lose from user dissatisfaction in a way open source software doesn't, and so have an incentive to avoid errors in the first place: the number of calls to a support desk grows exponentially with the number of bugs and users.
While open source software doesn't necessarily have a "support desk" (though some do!), we do have mailing lists, web forums, and IRC. And believe me, we too have that same incentive. The more questions we must answer and bugs we must crush, the more of our time is required. And for us, time is our currency. Just because we don't lose lots of money doesn't mean we don't lose.
Where's the support desk for OpenOffice?
Right here.
And if you actually look at that page, it wonderfully illustrates the power of the open source model with respect to support. Not only can you get commercial support from the original vendor (Sun) but also from the community and numerous independent consulting firms as well. That's the power of open source: Freedom of Choice. Unlike closed source products, like Microsoft's, where you have to rely on one single vendor who has no competition and can gouge you for support however they choose.
But what about the innumerable volunteers who can download the code and fix what they like? They take one look at the effort involved and run. OpenOffice is an extremely complex mountain of source code.
Yes, it most definitely is. But that's not why so few people contribute to the actual code. The reason is that OpenOffice has by far the worst software build framework I've ever seen. And if you can't build the code to test your fixes, you're pretty much screwed. OpenOffice is such a horrific tangle of code that making sense of it all as a newcomer is an incredible challenge. Most folks simply don't have the time.
Brown also points out that OpenOffice began its life as a closed-source project. The largest successful open source projects of comparable size to OO (such as KDE, X, and the kernel) began as open source. Being able to follow a project over time is very valuable, and that wasn't possible with OO.
Even Mozilla/Firefox have gained scores of developers since going open source. There are numerous examples like this of successful open source projects of considerable size.
Another obvious barrier is the "legalese" cited which is required before one can contribute. OpenOffice has stabbed itself in the foot by essentially discouraging contributions.
Interesting, though, how Mr. Brown just "happened" to choose this one project which isn't fully open as an assassination of open source development. Why did he do that? Because most anything else would've proven him wrong!
Most software has similar irritations. But complex open source projects seem uniquely badly placed to fix them. They rely on a very small group of programmers relative to the user base
Well, duh! Show me a piece of software that has anywhere near as many developers as it has users! The only ones that would qualify are the very small, personal/niche projects. Anything of appreciable size, including Apache, Windows, Lotus Notes, and Solaris, all have many, many times as many users as developers! That's hardly a valid argument against open source.
Sure, OpenOffice has some pretty significant issues. But being open source is clearly not one of them.