next up previous contents
Next: Perils to Open Source Up: Introduction Previous: Use the Source, Luke


Innovation Through the Scientific Method

The most fascinating development in the Open Source movement today is not the success of companies like Red Hat or Sendmail Inc. What's intriguing is to see major corporations within the computer industry, companies like IBM and Oracle, turn their attention to Open Source as a business opportunity. What are they looking for in Open Source?


Science is ultimately an Open Source enterprise. The scientific method rests on a process of discovery, and a process of justification. For scientific results to be justified, they must be replicable. Replication is not possible unless the source is shared: the hypothesis, the test conditions, and the results. The process of discovery can follow many paths, and at times scientific discoveries do occur in isolation. But ultimately the process of discovery must be served by sharing information: enabling other scientists to go forward where one cannot; pollinating the ideas of others so that something new may grow that otherwise would not have been born.

Where scientists talk of replication, Open Source programmers talk of debugging. Where scientists talk of discovering, Open Source programmers talk of creating. Ultimately, the Open Source movement is an extension of the scientific method, because at the heart of the computer industry lies computer science. Consider the words of Grace Hopper, inventor of the compiler, who said, in the early 60s:

To me programming is more than an important practical art. It is also a gigantic undertaking in the foundations of knowledge.

Computer science, though, differs fundamentally from all other sciences. Computer science has only one means of enabling peers to replicate results: share the source code. To demonstrate the validity of a program to someone, you must provide them with the means to compile and run the program.

Replication makes scientific results robust. One scientist cannot expect to account for all possible test conditions, nor necessarily have the test environment to fully test every aspect of a hypothesis. By sharing hypotheses and results with a community of peers, the scientist enables many eyes to see what one pair of eyes might miss. In the Open Source development model, this same principle is expressed as ``Given enough eyes, all bugs are shallow.'' By sharing source code, Open Source developers make software more robust. Programs get used and tested in a wider variety of contexts than one programmer could generate, and bugs get uncovered that otherwise would not be found. Because source code is provided, bugs can often be removed, not just discovered, by someone who otherwise would be outside the development process.

The open sharing of scientific results facilitates discovery. The scientific method minimizes duplication of effort because peers will know when they are working on similar projects. Progress does not stop simply because one scientists stops working on a project. If the results are worthy, other scientists will follow up. Similarly, in the Open Source development model, sharing source code facilitates creativity. Programmers working on complimentary projects can each leverage the results of the other, or combine resources into a single project. One project may spark the inspiration for another project that would not have been conceived without it. And worthy projects need not be orphaned when a programmer moves on. With the source code available, others can step in and take over the direction of a project. The GIMP sat idle for a year, but ultimately development did continue, and today the GIMP is pointed to with pride when Open Source developers consider what they can do in an area that is new territory for them: end-user applications.

Fortune 500 companies want to leverage off of this powerful model for innovation. IBM will happily charge a tidy sum to set up and administer the integration of Apache into MIS departments. This is a net win for IBM; they can install an exceptionally stable platform, which reduces the cost of supporting the platform, and really deliver service that can truly help their customers out. Just as important, IBM engineers share in the cross-pollination of ideas with other independent developers in the Apache Team.

This is precisely the reasoning behind Netscape's decision to make its browser Open Source. Part of the goal was to stabilize or increase market share. But more importantly, Netscape looked to the community of independent developers to drive innovation and help them build a superior product.

IBM was quick to see that tightly integrating software technologies like Apache into server platforms like the AS400 and the RS6000 line can only help in winning contracts and selling more IBM hardware. IBM is taking this to the next step and is porting their popular DB2 database to the Linux operating system. While many took this as being a response to Oracle releasing its Oracle 8 line on Linux, IBM has taken its role in the community seriously and has dedicated resources to the open software cause. By porting Apache to the AS400 platform, IBM has taken its most popular mainframe and legitimized the open technologies in ways only IBM can do.

It will be interesting to see what will happen in the competitive bids that companies like Coleman (of Thermo-electron), SAIC, BDM, and IBM make to the federal government and to industry. Consider the software cost of installing 1,000 seats with NT or Solaris and compare them with installing 1,000 seats with Linux. When you can drop your bid price by over a quarter of a million dollars, you can compete more effectively for these sorts of bids. Companies like CSC, who have a reputation of commonly forgoing a percent or two of profit margin to get more contracts, are probably just trying to figure out how to leverage technologies like Linux.

While companies like IBM, Oracle, and Netscape have begun to integrate their business model with Open Source, many traditional software companies continue to focus on purely proprietary solutions. They do so at their peril.

In the web server space, Microsoft's complete denial of the Open Source phenomenon is almost amusing. The Apache web server has, at the time of writing, more than 50% of the web serving market according the Netcraft survey ( When you look at advertisements for Microsoft's Internet Information Server (IIS) you see them tout that they own over half the market in web serving -- over half the commercial server market, that is. When compared against competitors like Netscape and Lotus, they have a substantial edge in the market share, but that ``edge'' looks puny in the overall server market where Microsoft's 20% is dwarfed by Apache's 53%.

The irony deepens, however. The fact is that 29% of the Web now runs on Linux-based servers, according the surveys conducted by the QUESO and WTF. QUESO is a tool that can determine the operating system a machine is running by sending TCP/IP packets to it and analyzing how the server responds to them. When run in conjunction with the likes of the Netcraft query engine, which analyzes the identification tags that the server responds with, it can produce a telling picture of the Web by OS and server type.

In fact, proprietary software vendors have already suffered a number of quiet casualties. Linux and Free BSD have really eliminated opportunities to successfully sell a proprietary Unix on PC hardware. One such company, Coherent, has already foundered. The Santa Cruz Operation (SCO) has gone from a leading Unix vendor to an afterthought in the span of a couple of years. SCO, the company, will probably find a way to survive, but will its flagship product, SCO Unix, be another casualty of Open Source?

Sun Microsystems has in many ways provided support for open-source development over the years, whether through donations of hardware and resources to help with the SPARC port of Linux, or through supporting development of John Ousterhout's Tcl scripting language. It's ironic, then, that the company that grew out of the joyous free software roots at Berkeley that Kirk McKusick describes so often struggles to grasp the significance of the Open Source phenomenon.

Let's take a moment to do some comparison and contrast with SCO and Sun.

Sun makes the majority of their money from supporting and servicing their OS and hardware. Sun's product line goes from a desktop workstation that is competitively priced with a PC to large enterprise class server-clusters that compete in the mainframe space. Their profits in the hardware realm do not come from their low-end Ultra series so much as they do from the service, sales, and support of their highly specialized and customized E and A series servers. It's estimated that Sun enjoys fully 50% of their profits from support, training, and consulting services.

SCO, on the other hand, makes money by selling the SCO Unix operating system, programs like compilers and servers, and training and education on the use of the SCO products. So while SCO has a nicely put together organization, it is in danger the same way that a farm with one crop can be vulnerable to a single blight destroying a harvest.

Sun sees the development of Linux as perhaps more concern for the lower end of their product offering. Sun's strategy is to make sure that Linux can run on the Sun hardware so people can choose to run Linux on Sun hardware. This is interesting because Sun can then continue to offer hardware support for their machines. In the future, we would not be surprised to see Sun offer software support for Linux on their lower-end machines.

In many ways, this is a short step for Sun. In fact, if you were to call a Sun administrator right now and ask him or her what's the first thing they do when they receive a new Sun box, they will tell you ``Download the GNU tools and compilers and install my favorite shells.'' Sun will perhaps finally get this message from their customer base and just do this for people as an outreach measure. However, Sun will operate at a disadvantage until they see the service their customer base can provide for them: innovation through cross-pollination of ideas based on source code release.

SCO, on the other hand, has a less flexible model. SCO's pricing model sells the OS first, with additional costs for tools that the Linux user takes for granted, such as compilers and text processing languages. This model simply can't be sustained in the face of competition from a robust free OS. Unlike Sun, which has added value in its broad hardware line, SCO has no hardware to tie profits to. Their OS is essentially all they have, and in SCO's case, that's not good enough. What will SCO do?

Their response so far has not been enlightened. In the beginning of 1998, SCO sent out a letter to its vast mailing list of users slamming open Unixes like Linux and FreeBSD as unstable and unprofessional while offering a reduced price on the SCO base OS. They were widely scorned for this move and had to do some serious backpedaling. The letter insulted a number of people by blatantly lying about the credentials of Linux. SCO didn't give their customers credit for being smart enough to see through the FUD. SCO eventually published a retraction on their web site.

In late 1998, SCO sent out a press release talking about how SCO Unix now has a Linux compatibility layer, so that your favorite Linux programs can be run under SCO Unix. The response was underwhelming. Why spend money on an OS just to make it compatible with a competitive free offering?

SCO is in a unique position to benefit from the Open Source movement. SCO has some very valuable intellectual property that they can leverage into a real position of power in the Open Source future. They must, however, make a leap of faith. Instead of seeing Open Source as a threat that would erode SCO's intellectual property, they need to see Open Source as an opportunity to bring innovation to that intellectual property.

Of course the maneuverings of a company like SCO or even Sun with respect to Open Source pale compared to the actions of Microsoft. So far Microsoft remains locked in its proprietary model, and seems determined to see that model through at least the release of Windows 2000.

Our guess is that Windows 2000 will ship in the latter part of 2000 or early 2001 to great fanfare. This will be the great merging event of NT and 98 after all. Somewhere around this event, or six months before, there will be an announcement for a new Microsoft Windows operating system. Microsoft has always coveted the ``Lucrative Enterprise Market,'' a place where the machines serve a company's lifeblood of data. So far, however, there's no evidence that Microsoft can deliver a Windows NT system or Windows 2000 system with the greater stability this market requires. So this new system will be decreed as the coming solution.

Let's call the product that represents this phantom change ``Windows Enterprise'' or WEnt. Microsoft will look at NT and say, essentially, how can we make it more reliable and stable? OS theory, as Linus Torvalds points out in his essay, really hasn't changed much in the last 20 years, and so Microsoft engineering will essentially come back and say that a nice, tightly-written kernel without any pollution in the executive level of execution is the best way to accomplish reliability and speed. Thus to fix the major errors of the Windows NT kernels, namely the inclusion of ill tested or ill-chosen third party drivers and making the GUI part of the kernel, Microsoft will have to either write a monster slow emulation layer, or just break a ton of old applications. Microsoft is certainly capable of pursuing either course. But open-source programs may well have reached the maturity where corporations who are buying software will ask themselves if they trust Microsoft to give them what is already available under the guise of Linux, namely a stable kernel.

The answer will of course show itself with time. No one really knows if Microsoft can actually write solid stable software at this level. The ``Halloween Documents'' that Eric Raymond refers to suggest that even within Microsoft there are serious doubts.

next up previous contents
Next: Perils to Open Source Up: Introduction Previous: Use the Source, Luke

Download this document: [src.tar.gz][ps.gz][html.tar.gz][dvi.gz]

Open Resources (
Last updated: 1999-08-06