> Sun is the loose cannon of the computer industry. Unable to see past their raging fear and loathing of Microsoft, they adopt strategies based on anger rather than self-interest. Sun's two strategies are (a) make software a commodity by promoting and developing free software (Star Office, Linux, Apache, Gnome, etc), and (b) make hardware a commodity by promoting Java, with its bytecode architecture and WORA. OK, Sun, pop quiz: when the music stops, where are you going to sit down?
Eight years later, we finally know the answer to Joel's question.
They weren't making all software a commodity though, just the ones that their rival had market dominance of, or where they had no chance of gaining dominance themselves.
It's easy to point and laugh at Sun, but that's the same approach to open source (and standards) that Apple used to get out of the shadow of Microsoft and they seem to be doing okay.
(The same probably applies to Sun breaking lock-in to Intel based hardware architectures. Again this applies to Apple as they had to switch from PPC to Intel, but their cross-architecture experience gave them the leg up on ARM based phone and tablet markets.)
Joel missed the commodity/complement parts of Java. Sun's approach with Java was to commoditize the language, especially as it ran on PCs, so that they could license the Java Virtual Machine (JVM), especially on embedded systems (e.g. phones). The Java language is the complement of the JVM. Sun was actually pretty successful in this approach.
Having said that, recent history indicates that Joel's take on Sun's problems with their strategies (plural because they flip-flopped strategies) ultimately was correct.
I think the other bit he missed was the early focus Sun placed on Java Applets. I think they initially saw Java and JVM primarily as platform for distributing client side code to web browsers, to set-top boxes, to mobile phones, etc. In this way Sun's focus on Java is analogous to Netscape's efforts to distribute a free web browser--they are trying to commoditize the client to sell more servers.
Of course, as it played out Java got a lot more traction on the server side than the client side. (I think the ability to easily develop on Windows and deploy to Unix/Linux played a role in that.) But by 2002 Java had already pretty much lost on the browser side, supplanted by Flash and later robust JavaScript. I think 2002 might have been the thick of their JavaME (mobile platform) efforts though.
I think Joel's missing a very basic assumption in the Linux comparison. Economics is about incentives. The basic assumption he's making is that money (or lack thereof) is an incentive for producing open source software.
I seem to recall Mother Teresa being told by a reporter that they couldn't be paid enough money to do what she did. Mother Teresa's response was something along the lines of "You couldn't pay me enough money to do it either". For me the loss of time and money is negligible compared to what I gain in learning, which is immeasurable.
He's not making an assumption about cost == money at all. In fact, he says "...when an economist considers price, they consider the total price, including some intangible things like the time it takes to set up, reeducate everyone, and convert existing processes".
So when he's arguing against the "claim that it's OK for every Linux kernel revision to make all existing drivers obsolete, because the cost of rewriting all those existing drivers is zero", he's saying "there is a cost, it's just not monetary." The alternative to requiring people to rewrite device drivers is having some people make the kernel backwards-compatible with old drivers. Presumably that's simpler than rewriting every driver. What else could you add to Linux if that many developers could do something that wasn't rewrite working code?
At the individual developer level, you are correct. There are quite a number of people who prefer, to varying extents, to work on FOSS software and who will accept certain amounts of disincentives, inconveniences, and sacrifices to do so because they're outweighed by the personal incentive of working on such projects.
Joel is talking at the level of corporations, not of individuals. All of his examples are of the strategic move of a company, not the personal belief of an individual (or the collective action of a group that is united by their beliefs). And the major take-away is, you don't need a non-monetary incentive to support FOSS, because there are monetary incentives. Open-source and profit-motive are not inherently opposed.
So yes, the assumption he's making is that money is an incentive for promoting open source. For some, especially for companies, it is. For some, it is not. It's reasonable to expect that when companies are supporting it, they have something to gain by doing so, and Joel is spelling out how. That doesn't invalidate the personal motivations that some people may have, but neither do those motivations invalidate the more traditional monetary motivations that the companies (and some individuals) have either.
He's a Microsoft fanboy writing in 2002 about open source software. Of course he's wrong.
Having said that, I don't think he's wrong on the big picture economics, more on the particular facts of the examples. It's about people wanting to ship binary drivers rather than just release the source so that others can fix it for you. Or generalize it so that your specific hardware widget is just one of many similar widgets all running the same basic code that can be mainained at a much lower cost (by any measure).
Of course hardware folks don't want to do that if they feel they have lock-in, for exactly the reasons discussed in this article. They don't want to be an interchangeable commodity, Linux and end-users do want them to be commodities. Once again Free Software is shown to be about who has control, not how much you pay. (Though probably mostly it was just fear of the unknown)
More recent developements include the Linux Driver Project:
"We are a group of Linux kernel developers (over 200 strong) and project managers (over 10) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 Linux kernel driver as an end result."
> Economics is about incentives. The basic assumption he's making is that money (or lack thereof) is an incentive for producing open source software.
Not at all. Economics is about "how to best allocate scarce resources". "Resources" for an open source project translate to manpower or developer hours.
Given that you develop primarily for fun and learning: Would you rather spend this week making the 17th version of the same hardware driver (because the latest Linux core version broke it), or would you rather spend that time on attacking a new problem?
The economic argument is simply that if
a) making Linux backwards compatible takes x developer hours
b) updating every Linux driver in existence takes 1000x developer hours (summed over all developers)
then choosing b) is a net loss for Linux, since all those extra developer hours could be spent on something more interesting.
Yeah, and it is funny that he has 'retired' from blogging yet his stuff still makes it to the frontpage. I personally think some of these old articles were the best.
Eight years later, we finally know the answer to Joel's question.