Comments: /TotW/microsoft_history.htmlgreenspun.com : LUSENET : Economic History (and Related Observations) : One Thread
The Dilemma of Antitrust: A Short History
-- Bradford DeLong (firstname.lastname@example.org), May 04, 2000
>Your argument is also needlessly weakened by a couple >of statements of >dubious validity. For example, you say "It seems to be >easier to get >Microsoft FrontPage working well when the Web server it >uploads files to is >running Microsoft Internet Information Sever rather than >when it is running >open-source Apache." I don't think this is true....
I had thought that the server extensions were the key: that they worked *well* on IIS and were very buggy elsewhere...
>Another shaky statement is the assertion that "Software >for minicomputers >stagnated in the 1980s because each brand's version of >the Unix operating >system was incompatible with the others." I've used >many of those different >"flavors" of Unix. While the differences are a nightmare >from a system >administrator's point of view, the differences are really >quite minor from >the user's perspective.
But not from the viewpoint of the software producer... Phil Greenspun, for example, strongly recommends Suns because Oracle develops on Suns, and then tackles other dialects of Unix...
But since I beat up on Charles Ferguson in the _Harvard Business Review_ for ignoring open source, it's only fair that I get some of the same medicine.
-- Bradford DeLong (email@example.com), May 04, 2000.
I read your article in today's L.A.Times with considerable interest. But I think you have confused two things in your discussion of economies of scale.
There are indeed considerable benefits to everyone using the same software, or doing things the same way. But this benefit stems from standards, not market domination. We've known for a long time that even a bad standard is better than none, in nearly all situations.
You partly recognize this distinction by referring to "the benefits of bigness, or at least coordination." But it really is coordination that's involved, not bigness and predatory policies like Microsoft's.
Your argument is also needlessly weakened by a couple of statements of dubious validity. For example, you say "It seems to be easier to get Microsoft FrontPage working well when the Web server it uploads files to is running Microsoft Internet Information Sever rather than when it is running open-source Apache." I don't think this is true. There's no logical connection between the server-side software and the Web-page "authoring tools" (as they are known these days). What I think you are referring to is the connection between Microsoft's FrontPage and its browser, which is full of proprietary (and non-standard) features. It's possible that Apache might have difficulties serving Web pages that contain some of the more esoteric features (or bugs!) of the Microsoft software; but Apache has a reputation for reliability and robustness, which is why it has taken over the great majority of the Web servers. So I doubt that there's really a problem there. In any case, there's no reason why the Apache server should make FrontPage work less well. Your may be talking about a real interoperability problem, but if so, I think you have mis-identified it.
Another shaky statement is the assertion that "Software for minicomputers stagnated in the 1980s because each brand's version of the Unix operating system was incompatible with the others." I've used many of those different "flavors" of Unix. While the differences are a nightmare from a system administrator's point of view, the differences are really quite minor from the user's perspective. And why? Because the UNIX community quickly realized they needed standards, and agreed on a set (ever hear of "POSIX"?). Instead, the real problem was that AT&T, the copyright owner of UNIX, began restricting access to the source code. Whereas they had formerly given away the source free, or nearly so, to universities -- which led to the great profusion of new and productive features at your own university, so that "Berkeley UNIX" is a well-known phrase in the software comminuty -- AT&T started charging something like $50k or more for a source license. It was these restrictions that led to the invention of Linux; and this open-source community has now breathed fresh life into the UNIX movement. In short, now that source code is freely available, there are thousands of people working on improvements to Linux, while the closed-source Unices languish and are full of bugs and problems (I can attest to having encountered several in the past year; our system administrator has dealt with these matters by replacing the proprietary utilities with open-source versions that work better.)
Here, again, the benefits flow not from bigness and market domination, but from standards and openness, as opposed to proprietary "closed" code and conventions.
An additional point not covered in your article is the notorious lack of innovation displayed by Microsoft. It's well known that the "Windows" model was copied from Apple's user interface -- and it's a second-hand theft at that, as the whole thing arose at Xerox PARC rather than at Apple. Microsoft wasn't interested in the Internet until Netscape began to be successful.
There are many other examples, but you get the idea. The result has been that Microsoft has done rather badly in areas outside of PC operating systems, where they managed to obtain a monopoly early and dominated the market. Look at their difficulties in the hand-held area, where Windows CE is regarded as slow and underpowered, and has only a relatively small fraction of that market. A lot of what Microsoft touts as innovation arose in other companies they later acquired by using their monopoly power. Many people in the software industry have argued that consumers would have much better PC software today if Microsoft had not deprived them of the opportunity to have it. The inroads that Linux is making on the desktop today suggest this is true.
It sounds as if the anti-trust people are re-fighting previous wars, and don't understand much about what's important in the area of software. It's not that times have changed, but that this is a different type of business than the heavy industries that were the monopolists of the past. The efficiencies in software come from standards, not bigness. And standards thrive in an atmosphere of cooperation, not cut-throat competition.
It's likely that the most productive move the courts could make would be to force Microsoft to publish its source code. Open code would quickly get cleaned up and improved; consumers would benefit; and in the long run, Microsoft would have won the battle for domination it has fought for so long. "Breaking up" Microsoft looks like a futile effort, in contrast. This isn't the phone company, or Standard Oil. --
-- Andrew T. Young (firstname.lastname@example.org), May 04, 2000.
>>dubious validity. For example, you say "It seems to be easier to get
>>Microsoft FrontPage working well when the Web server it uploads files to is
>>running Microsoft Internet Information Sever rather than when it is running
>>open-source Apache." I don't think this is true.... >
> I had thought that the server extensions were the key: that they
> worked *well* on IIS and were very buggy elsewhere... > Well, that's an example of violation of standards -- it's like what MS did with Java. They did similar things with their browser; though of course so did Netscape. Some of these "extensions" are useful, but some are just deliberate incompatibilities inserted to make sure the competition's software will look as if it isn't working. Whether these things are bugs or features often depends on where you're standing....
>>Another shaky statement is the assertion that "Software for minicomputers >>stagnated in the 1980s because each brand's version of the Unix operating >>system was incompatible with the others." I've used many of those different >>"flavors" of Unix. While the differences are a nightmare from a system >>administrator's point of view, the differences are really quite minor from >>the user's perspective. > > But not from the viewpoint of the software producer... Phil > Greenspun, for example, strongly recommends Suns because Oracle > develops on Suns, and then tackles other dialects of Unix...
An interesting point. I think of myself as a software producer, though it's mostly for my own use. But I don't use database products like Oracle. But I've run on many different Unices from AT&T SysV to Berkeley, with Xenix and Linux somewhere in between. (Then there are the rather peculiar ones like IBM's AIX, which I've also had to work on.) For the most part, if you stay away from systems programming and stick to applications and shell scripts, it's easy to write fairly portable code for all these.
Oddly enough, it was Sun's software that gave me the problems that were cleared up by replacing it with open-source versions.
So I suppose it depends on what you're doing. I think of Sun as a producer of scientific workstations; it seems odd to me that a business-software outfit like Oracle would use them. My own work is all scientific programming.
I had an interesting year back in 1992 developing software for the European Southern Observatory's MIDAS data-analysis system. Their stuff has to run on a dozen or more different platforms; they had recently switched from VAX VMS to UNIX, so they even had to run (still) under VMS. They basically had their own operating-system layer that ran on top of the actual OS, so my problem at that time was in dealing with the quirks of various Fortran compilers. Lots of things that conformed to the ANSI Fortran standard did not actually work on one or another of the several systems, so I had to reduce all my code to a sort of lowest common denominator. Fortunately I had read a bit about how to write portable code (as well as having had to port my own for over 30 years) so I already was writing fairly portable stuff. It still surprised me how many deficient compilers there were out there. That experience, despite these difficulties, really impressed me with the value and importance of having standards -- especially clear, unambiguous ones.
-- Andy Young
-- Andrew Young (email@example.com), May 04, 2000.
Thanks for the info. I really enjoy your information. BTW, have you read any of the Leibowitz/Margolis skeptical regard for increasing returns?
-- firstname.lastname@example.org (email@example.com), May 04, 2000.
I appreciated reading your cogent analysis, but I do think you missed 1/3 of the triad when you wrote
However, the dilemma of antitrust will remain: bigness vs. freedom of choice, competition vs. economies of scale.
without adding also: "fair play" vs. unethical business practices
Your statement "A second possible direction would be to have greater tolerance for monopolies that played fair" was a step toward this conclusion, but did not go far enough.
Indeed, I think the major impact of the MS trial will be in the "fair play" area. For this reason, I cannot agree with your statement:
" ... Technology also seems to be moving sufficiently rapidly to make whatever antitrust remedy is reached in that case of doubtful relevance: The market and the industry will have changed too much. "
If MS gets past this trial with only a slap-on-the-wrist, many other companies will be encouraged to adopt extreme marketing practices like those described for MS in the judge's findings. This could cause a widespread deterioration of the high tech marketplace. As there would be less competition going forward, technical progress would slow generally (just as MS has made very little technical innovation for years), and prices would cease to decline (becoming stable just as MS prices have done). I would call that outcome a major impact on the economy.
Conversely, if MS is seen as being called to task over their practices, then other technology companies will be able to take the risk of competing in areas that were previously too close to MS' sphere of influence to be "safe". In this scenario, high tech will undergo yet another surge of creativity and growth.
Thanks again for putting out a thought provoking piece.
-- Peter Eirich (Eirich@erols.com), May 04, 2000.