Bringing you the latest news from the Linux World.
Dedicated to keeping Linux users up-to-date, with concise news for all interests
Linux in the news
All in one big page
Here is the permanent site for this page.
See also: last week's LWN.
LWN Lite this week: Executive Editor Jonathan Corbet is taking a much needed break somewhere in the Utah desert. Jon wrote the front page editorial before leaving, the rest of this week's LWN has been put together by the skeleton crew consisting of Rebecca Sobol and Forrest Cook. Please excuse our smaller than usual content, it's been a ghoulishly tiring week and we're both feeling like zombies.
Remember the Halloween memo? The Halloween memo, remember, was an internal Microsoft document that was leaked to Eric Raymond right about on Halloween, 1998. It was a look at open source software as a competitive threat to Microsoft, and it was, in a way, the first externally-visible sign that Microsoft was getting worried. It was a big deal at the time; there was much curiosity about how Microsoft would react to Linux and free software. The Halloween memo seemed to give some answers to that question; as was stated in Salon:
Still, the approach [author Vinod] Valloppillil outlines is consonant with Microsoft's previous behavior. Don't be surprised if the strategies he outlines play out in the headlines over the next two or three years.
Well, it is three years later, and, thus, a good time to look back and see how things have really gone. Here is a retrospective on some of the Halloween highlights.
One of the first conclusions made in the document was:
Commercial software development processes are hallmarked by organization around economic goals. However, since money is often not the (primary) motivation behind Open Source Software, understanding the nature of the threat posed requires a deep understanding of the process and motivation of Open Source development teams. In other words, to understand how to compete against OSS, we must target a process rather than a company.
That observation certainly remains true. Much more open source work is done with a commercial motivation these days, but the process, at its best, remains. Open source software can not be killed off by destroying companies.
Here's an interesting claim that nobody really challened back in 1998:
Like commercial software, the most viable single OSS project in many categories will, in the long run, kill competitive OSS projects and `acquire' their IQ assets. For example, Linux is killing BSD Unix and has absorbed most of its core ideas (as well as ideas in the commercial UNIXes). This feature confers huge first mover advantages to a particular project
Offhand, we would guess that users and developers of the BSD variants would take exception to the claim that Linux is "killing" them. KDE's "first mover" advantage has not kept GNOME from picking up large-scale developer and company support. It is, in fact, quite rare than one open source project "kills" another. There is indeed competition between projects, but it takes a different form.
Here's a fundamental conclusion of the document:
Loosely applied to the vernacular of the software industry, a product/process is long-term credible if FUD tactics can not be used to combat it. OSS is Long-Term Credible. OSS systems are considered credible because the source code is available from potentially millions of places and individuals.
In other words, free software, unlike the proprietary variety, does not simply disappear if things go wrong. There is no better example than the recent Nautilus release; the company that created Nautilus is gone, but the software remains and continues to improve. HP's OpenMail vanished when the company ceased to support it; sendmail is (unfortunately, some might say) here forever.
Microsoft has indeed found that FUD (fear, uncertainty, and doubt) attacks against Linux tend to be ineffective. At their best, they are laughable; at their worst, they make up a task list of things for Linux developers to quickly address - the Mindcraft report, for example, worked in this way. The company seemed to hold out a bit more hope for FUD attacks against free software licenses, but those, too, have subsided recently.
On project management:
The biggest roadblock for OSS projects is dealing with exponential growth of management costs as a project is scaled up in terms of rate of innovation and size. This implies a limit to the rate at which an OSS project can innovate.
Some free software projects are huge - think KDE, GNOME, Mozilla, OpenOffice, or the kernel. Certainly some of those projects have shown management problems at times - for example, the "Linus burnout" episodes in 2.1 kernel development. There are two things to keep in mind, though:
Is free software future credible?
A very sublime problem which will affect full scale consumer adoption of OSS projects is the lack of strategic direction in the OSS development cycle. While incremental improvement of the current bag of features in an OSS product is very credible, future features have no organizational commitment to guarantee their development.
Proclamations from open source developers on future features may or may not be credible - think about Linus's "2.5.x looks like it will open in a week or two" comment from last June. That may be part of why open source developers tend to be reluctant to make promises about what will come. They tend to let the code speak for itself in its current state.
One could argue that future features in open source code could be more credible, not less. Features in Microsoft code are hidden from public view until they spring, fully developed, from the head of Bill. Until a product is released, nobody really knows how development is progressing. Those interested in how a free software development is coming along can look at the code, run a development version, and see exactly where things stand.
What does it mean for the Linux community to "sign up" to help build the Corporate Digital Nervous System? How can Linux guarantee backward compatibility with apps written to previous API's? Who do you sue if the next version of Linux breaks some commitment? How does Linux make a strategic alliance with some other entity?
Hmm...one hears a lot less about digital nervous systems these days... And who, exactly, do you sue if Microsoft breaks a commitment?
There were few answers to the last question above at the time, but now the answer appears obvious. "Some other entity" can make a "strategic alliance" with a free software project by joining in the development process. Thus, for example, a number of distributors have built "strategic alliances" with the kernel developers - by employing them.
The memo concluded that Linux was unlikely to be a threat on the desktop. There were a few reasons for that; first:
OSS development process are far better at solving individual component issues than they are at solving integrative scenarios such as end-to-end ease of use.
Three years later, there is perhaps some truth to that. The desktop projects are getting a better handle on integration and ease of use, however. Detailed user testing, for example, has begun to be a part of their process, though they could do more.
Switching desktops is hard and a challenger must be able to prove a significant marginal advantage. Linux's process is more focused on second-mover advantages (e.g. copying what's been proven to work) and is therefore unlikely to provide the first-mover advantage necessary to provide switching impetus.
For the purposes of most desktop users, this claim is probably true. Reproducing what is available on a Microsoft desktop will win some users, but it is not enough. It may yet turn out, however, that Microsoft's licensing will provide that impetus to switch.
Ease of use must be engineered from the ground up. Linux's hacker orientation will never provide the ease-of-use requirements of the average desktop user.
The desktop projects are being engineered from the ground up. It remains true that ease of use is not always at the top of many hackers' priorities, however.
So, how was Microsoft to beat Linux?
Fold extended functionality into commodity protocols / services and create new protocols. Linux's homebase is currently commodity network and server infrastructure. By folding extended functionality (e.g. Storage+ in file systems, DAV/POD for networking) into today's commodity services, we raise the bar & change the rules of the game.
This was the core of the document's strategy: move toward proprietary protocols and services. The antitrust trial may have slowed this process down, but it's happening: .NET and HailStorm provide ample evidence. The world, however, is increasingly suspicious of proprietary protocols, and this will still prove to be a hard battle. In three years, Microsoft has not gotten too far with it.
The document took a look at Mozilla, predicting that it would continue to drop behind Internet Explorer. Much controversy came from the document's use of declining traffic on the Mozilla lists as evidence that development was slowing. Mozilla-general went from 1862 postings in April, 1998 to 687 in June. Mozilla-ui went from 285 to 76. For the curious, Mozilla-general seems to have bottomed out with 211 messages in October, 1999; it carried 1451 postings in September, 2001. Mozilla-ui carried 243 messages, and appears to be headed toward double that in October.
In other words, three years later, Mozilla is alive and well, and reaching the point where it can do numerous interesting and novel things. While IE development has slowed, Mozilla has picked up. For many, Mozilla or its derivatives (Galeon, Skipstone, etc.) are the browser of choice. Mozilla and IE have not yet come to a real "battle;" it will be interesting to see what comes out when that happens. But it's clear that Mozilla will be there for that battle.
Heading toward a conclusion, the report asked how Microsoft could "capture" the benefits of open source development. The recommendations included putting more source out there, something that Microsoft is experimenting with in its "shared source" program. Also included were a number of internal changes - radical things like giving the Excel team access to the Windows source. It is, of course, harder to know if such changes have happened within the company. Then, of course, there was the famous recommendation:
OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market.
Microsoft has certainly made efforts in this area, and will continue to do so. Most of the important protocols remain free, however, for now. How that will play out in the future remains to be seen.
The report concluded with a list of "interesting links," one of which was LWN.net. Three years later, we're still trying to be interesting...
Penguin Gallery Update. The LWN Penguin Gallery has been updated again. Head penguin wrangler Dennis Tenney reports:
Today's update added eight penguins. Two of the penguins are from a really nice collection of desktop backgrounds from the German magazine C't, at http://www.heise.de/ct/motive/. This site would be worth a mention on the desktop page, if we had one.
Inside this LWN.net weekly edition:
This Week's LWN was brought to you by:
November 1, 2001