Proprietary software has a charismatic new champion and his name is Larry McVoy. Those who follow Linux kernel development have long been treated to his righteous tirades against the arrogant and ungrateful who are deluded by the mythology of open source. This means everyone else has been missing out, which hardly seems fair. Daniel Lyons of Forbes has attempted to correct this by delivering his message to a wider audience[1]. What does this straight talking industry veteran have to say?

"Open source as a business model, in isolation, is pretty much unsustainable." Devastating.

Or is it? Something about that phrase is suspicious: what exactly does the "open source business model in isolation" mean here? Is there any business model that is sustainable when sufficiently isolated? Let's dig deeper. Mr. McVoy says, "We believe if we open sourced our product, we would be out of business in six months. The bottom line is you have to build a financially sound company with a well-trained staff. And those staffers like their salaries. If everything is free, how can I make enough money to keep building that product for you and supporting you?"

Aha. So spending heaps of cash on software development and corporate perks without any plan for generating revenue is unsustainable. That's clearly true but hardly enlightening. McVoy doesn't appear to have tried building a business identical to BitMover with the exception that theproduct would be free software, but perhaps he is right that it wouldn't work. Even so, it doesn't follow that it would be impossible to build an entirely different kind of company that develops free software. That would be a much tougher argument to make because many companies that do so actually exist.

Some companies spend money to develop free software to make the hardware products they sell more appealing. Those apparently don't count. "Nobody wants to admit that most of the money funding open source development, maybe 80% to 90%, is coming from companies that are not open source companies themselves," says Mr. McVoy. Those statistics seem like wild guesses, but suppose they're accurate. Is it really true that nobody is willing to admit this? I guess that means Bruce Perens is a figment of our collective imaginations. Or if not he certainly didn't dare to write, "Thus, hardware manufacturers have taken a large role [in funding Open Source development.]" Except that he did[2].

But there's still a problem. Mr. McVoy warns, "What happens when these sponsors go away and there is not enough money floating around? Where is innovation going to come from? Is the government going to fund it? This stuff is expensive. If hardware companies stopped funding development, I think it would dramatically damage the pace at which Linux is being developed. It would be pretty darn close to a nuclear bomb going off."

What a bombshell! That really would be just like a nuclear bomb going off. Except without all the mushroom clouds, radioactive fallout, buildings destroyed, people dying and stuff like that. Actually, come to think of it, this would be almost entirely unlike the effects of nuclear bomb.

Still, if the companies that spend billions of dollars on the development of free software were to stop for some reason that would surely slow the pace of progress. Again, though, this is not enlightening. Wouldn't the pace of proprietary software development slow if the venture capital firms stopped investing in software companies? Wouldn't a rabid hoard of bloodthristy hedgehogs descending on Redmond and eating the flesh from the bones of Microsoft developers delay the release of Longhorn by at least a week? Maybe even two weeks.

Bill Gates probably doesn't lie awake at night worrying about this because while it's not impossible it's not plausible either. Why would the contributions of hardware companies to free software suddenly dry up? Maybe one of Sun, Apple, HP, IBM, Nokia, Sharp and the scores of other companies that support free software development might go out of business or undergo a radical shift in business strategy. But all of them at once?

Perhaps Mr. McVoy means these companies will gradually lose interest in giving away something and getting nothing in return. If so he has misunderstood what drives them to contribute in the first place. None of these companies are charities. For quite some time they have been investing in free software development with the intention of realizing greater returns in the future, for example in the form of more hardware sales. Wouldn't they have stopped by now if this strategy wasn't effective?

Some companies spend money to develop free software and charge for services and support. This does not impress McVoy: "One problem with the services model is that it is based on the idea that you are giving customers crap--because if you give them software that works, what is the point of service?" What indeed? Of course, this does leave the mystery of why McVoy felt the need to spend nearly $500,000 per year on "support" for the Linux kernel developers using BitKeeper. He would probably not accept the explanation that BitKeeper is crap.

However the real problem with McVoy's comment is aptly pointed out by... well, by Larry McVoy. He says, "Open source software is like handing you a doctor's bag and the architectural plans for a hospital and saying, 'Hey dude, if you have a heart attack, here are all the tools you need--and it's free.' I'd rather pay someone to take care of me." So perhaps there is a reason to pay for service after all.

Of course the intended meaning of this comment is that free software cannot be integrated and presented to end users. Someone should explain this point to the developers of projects like Firefox, OpenOffice and Knoppix. These clearly resemble a finished product rather than raw components, with no heart surgery required. Wal-Mart and Sharp apparently didn't get the memo either, since the former is shipping desktop computers loaded with GNU/Linux and the latter is selling ready-to-use hand-held devices that come loaded with free software.

Well, no matter. McVoy goes on: "The other problem is that the services model doesn't generate enough revenue to support the creation of the next generation of innovative products." Somehow he seems to have drifted from the original question, which was whether free software is sustainable. A simple way to answer this might be to point to companies that participate in its development as part of their business and are profitable.

How does Mr. McVoy explain the existence of companies like RedHat which focus on free software and have actually turned a profit? He does what any good lawyer would do. When the facts are against you, argue the law. When the law is against you, argue the facts. When the facts and the law are against you, change the subject: "The open source guys can scrape together enough resources to reverse engineer stuff. That's easy. It's way cheaper to reverse engineer something than to create something new. But if the world goes to 100% open source, innovation goes to zero. The open source guys hate it when I say this, but it's true."

(We should be thankful that this logic has escaped the attention of proprietary software companies. They might try to illegally leverage monopolies to embrace and extend the products of their competitors. Then innovation would go to zero. Oh, wait...)

Contrary to the apparent meaning of statements such as, "Open source as a business model, in isolation, is pretty much unsustainable," McVoy appears to believe that free software is in fact sustainable. His real complaint is that free software cannot be a source of innovation. Why didn't he say so in the first place?

In the words of Daniel Lyons, "But McVoy says open source advocates fail to recognize that building new software requires lots of trial and error, which means investing lots of money. Software companies won't make those investments unless they can earn a return by selling programs rather than giving them away."

Something must have been lost in translation. Could McVoy really believe that lots of trial and error is something a globally distributed band of people working in parallel can't accomplish? That seems to be something free software developers do exceptionally well, in fact. But don't lose track of that next sentence: we learn that software companies won't make investments unless they can earn a return. Fair enough, but so what? Where is it written that innovative software can only be developed by software companies?

That seems to be the core of McVoy's confusion. "Red Hat has been around for a long time--for a decade now. Yet try to name one significant thing--one innovative product--that has come out of Red Hat," says McVoy. Whether RedHat has been innovative depends to a large extent on where one sets the bar, but let's humor him and ask whether proprietary software does better. While we're at it, let's stack the deck in his favor by comparing RedHat to the most successful software company in history. Microsoft has been around for a long time -- for over two decades now. Yet try to name one significant thing -- one innovative product -- that has come out of Microsoft.

David Wheeler tried to do so and failed[3]. He did notice that "several major innovations were first implemented" in free software, "especially for those involving networks"[4]. One of these that should be close to Mr. McVoy's heart is lock-less version control, which first appeared in a program called CVS. Arguably the most important features of BitKeeper are an incremental improvement on this simple idea.

None of that matters to Mr. McVoy, who says, "It costs a huge amount of money to develop a single innovative software product. You have to have a business model that will let you recoup those costs. These arguments are exceedingly unpopular. Everyone wants everything to be free. They say, 'You're an evil corporate guy, and you don't get it.' But I'm not evil. I'm well-known in the open source community. But none of them can show me how to build a software-development house and fund it off open source revenue. My claim is it can't be done."

Perhaps Larry McVoy is not an "evil corporate guy" (whatever that means) but does he really get it? He demands that the community show him how to build a "software-development house" and fund it with some substance he calls "open source revenue" which conveniently excludes all the ways companies that contribute to free software are already making money from doing so. Maybe Mr. McVoy needs to solve this bizarre puzzle. The rest of us don't. We need great software and the freedom to adapt it to our needs.

The free software community is delivering.

[1] http://forbes.com/technology/2005/05/26/cz_dl_0526linux.html
[2] http://perens.com/Articles/Economic.html
[3] http://www.dwheeler.com/innovation/microsoft.html
[4] http://www.dwheeler.com/innovation/innovation.html

[This is a bit of a mess for the moment. I've copied the text out of some debates I've engaged in on the [de]merits of checked exceptions before it falls of the end of Slashdot's 24 comment limit.]

Checked exceptions are bug not a feature. An exception is useful only because it allows a programmer to handle an error or unusual condition in the place on the stack that makes the most sense. Checked exceptions force every method on the stack to have some sort of boilerplate code to manage the exception even the only thing to do is pass it on up the stack. One might as well revert to returning error codes -- this will yield more efficient code too.

Worse, the entire concept breaks down when interfaces are involved. An interface can't predict what kinds of exceptions its implementations might want to throw, so there is no correct way to define them. Checked exceptions do more harm than good. Maybe that's why no language other than Java has adopted them.

First of all, checked exceptions are not the only, not the best and not even a particularly good way to get documentation about what exceptions might be thrown. Programmers can and often do declare "throws Exception" which completely defeats the purpose. An automated documentation tool like javadoc can and should enumerate the possible exceptions each method might throw.

Second, checked exceptions are an unacceptable burden on programmers for several reasons. They are a tedious obstacle to rapid prototyping, where a programmer cannot really know what exceptions are likely to be thrown and shouldn't be asked to enumerate them. You won't get a chance to write a server application that has to work 24/7 if you can't create an effective demo in time. Even when creating production code there is no reason to soak up programmer resources fighting pointless compiler errors. Some code simply should ignore exceptions, but checked exceptions don't allow that.

A good example of code that should ignore exceptions is interfaces. Checked exceptions make it impossible to correctly declare interfaces because there is no way a programmer can forsee every possible checked exception anyone might ever want to throw in an implementation class. Were all of this not true, why would Sun have officially enshrined swallowed exceptions in the JDK libraries with the "cause" method?

No other mainstream programming language has checked exceptions, and even languages that exist primarly to duplicate the good features of Java aren't adopting them. Why? Because they are a bad idea. It's that simple.

Client code can use "catch (Exception e)" and have some default behavior for dealing with unanticipated exception types. This is the correct thing to do, because it gives library implementations maximum flexibility while still permitting exceptions to be caught and handled specially where necessary. Many times the interface implementation is effectively a callback mechanism for the client code, so they belong to the same codebase and there is no question about what exceptions can be thrown.

I like the concept of the AWT. A consistent look and feel for applications is desirable. Also, having as much as possible of the system -- and especially the fundamentally non-portable things -- implemented in a more efficient language is a good thing. All of the advantages of Java are application focused, which may be why things like JavaOS never went anywhere. The trouble with AWT as I see it is that the interface caters to the lowest common denominator, which is backwards. An interface should cater to the highest common denominator and emulate features on systems that don't have them.

Sure, use a Java tree widget on platforms that don't have tree widgets, but give me an AWT interface that makes it impossible for me to tell that native code isn't being used without a special query. This lets the system improve as the underlying platform does without forcing anyone to rewrite code. Methods that can't be supported can throw exceptions (runtime exceptions please -- I loathe checked exceptions).

The problem I have with Swing is that it has so many bells and whistles that I don't need or even want, but nevertheless have to pay a performance cost for. I use GTK+, so I've already got a theme engine. An AWT backed by GTK+ would give my applications a consistent look of the sort I want. This will happen before long because of gij, but exposing all of GTK+ would either require more widgets or non-portable code.

Please don't pester me with breathless praise of HotSpot. I understand and agree that it is in principle possible for dynamically compiled Java code to be faster than C code in some cases. However in practice this just doesn't happen. All of my C applications run significantly faster than equivalent Java applications for all cases I have ever tested. I consistently test with the latest Sun JRE and periodically retry old tests.

I also concede that higher productivity can outweigh higher performance in many cases, and that some programmers do better in this regard when using Java. I'm not one of them. My productivity is consistently higher with object oriented C or C++. Feel free to presume that this is because I don't know this or that important facet of using Java effectively, but try not to think about how this undermines the argument that Java is easier to use. ;-)