Version 10/14/01
You will note that there are links from many of the words and phrases in this text (hyperlinked.) By clicking on these links, an additional browser window will open. Many of these links will take you to a Dictionary of Terms, in order to explain the word/phrase (other links take you to other relevant documents.) The purpose of the Dictionary of Terms is to allow many users, with different levels of knowledge, to benefit from the text. If there is a term in the text you feel should be better explained, please email me at alex@udel.edu and I will include it.

Content

Open Source ... A Revolution?

Before reading this, please review Cathedral and the Bazaar

As we consider developing systems projects, an emerging issue is whether to use Open Source alternatives, or to develop software that is then made available to others via open source. The following looks at the remarkable development of the Open Source Initiative. Open Source, as defined by the Open Source Definition is software that is:

Given these unusual requirements, especially: it is worth understanding the principles that allow this to happen, the business models that may make open source a better alternative, and reasons why a company might chose open source its software vs. remaining closed source. Before we do this, a brief history can establish context.

History Behind the Open Source Revolution

The following is a brief timeline of major events in the evolution of Open Source:
  1. UNIX Hacker culture, from the 1960s
  2. The Free Software Foundation FSF, established in 1983
  3. The GNU Project, established in 1984
  4. Linux development, established in 1991
  5. Cathedral and Bazaar Paper, 1997
  6. Netscape's Mozilla Project, 1997
Briefly, the UNIX hacker culture, as described in A Brief History of Hackerdom was the birth ground for the movement that was later to become known as the Open Source movement. The hackers enjoyed the pure creativity of developing software, and sharing that code with fellow hackers, in order to expand the overall knowledge-base of the hacker community. This is therefore a very cooperative environment. The evolution, at this time, was somewhat limited with respect to the available platforms to work with, and the ability for the community to communicate with each other. Typically small communities would evolve around specific proprietary technologies, for example Digital's PDP 10 series. Eventually the technology would be discontinued and new knowledge development was required. In 1983, Richard Stallman, tiring of this state of affairs, determined he wanted to develop a set of software tools, and an operating system, that were freely available for anyone to use, based on open standards. He established the Free Software Foundation which developed the GNU Project (GNUs Not Unix --- a recursive acronym, typical of the community!) This project is still thriving today, and the GPL license (known as copyleft) was developed for software developed for the GNU project. The GPL license stipulates: The GNU project has been very successful in most respects, but it has not been able to develop a working operating system. The UNIX operating systems had fragmented (forked) and were not a viable proposition for the developing PC market. The PC market was becoming increasingly controlled by Microsoft and the Windows Operating System. This was a very frustrating situation for the hacker community, which did not appreciate the dominating position of the market leader (they used to have disdain for IBM for the same reason). Some factions of the culture actually believed that software should fundamentally be free for all, and it was morally wrong to charge for it. (Stallman GNUs philosophy, hence the term "Free Software.") This was not the case for the entire community however. (Eric Raymond's paper The Magic Couldron establishes viable business models, and hence the Open Source movement.) The fundamental issue was the correct use of the term "free." While people assume it is used due to the cost structure of the software, it is actually used to highlight the "freedom of use" issue. Thus the user is free to use the software as he/she desires, by accessing the source code and making any necessary changes. The user would then share these changes with anyone who wanted to adopt them. This type of sharing and developing would lead to rapid development cycles for products. (Sometimes daily in the case of the early days of Linux!)

This climate allowed an opportunity for someone to initiate the development of an operating system, that would clearly get tremendous support from the hacker community. Linus Torvold a student in Finland at this time, decided he wanted to develop an operating system that allowed him to do more than the Minix operating system would allow. This operating system was developed by one of his professors, and was used in his computer science classes. He developed his first beta version of Linux, using much of the Minix code. This code was soon replaced, however, as its license was more limiting than the GPL license (of the GNU project). Linus announced his project on a Minix discussion group (hosted at udel at the time!) in 1991. The Linux Operating System is the outcome of that early beginning. Linux is now considered a more stable, robust and flexible operating system than Microsoft's Windows, and it has been in development for significantly less time! The excellent essay: In the Beginning was the Command Line highlights the differences between the major Operating Systems.

Pre-conditions for the recent success of Linux include:

As the Linux Operating system has become more popular, and the writings of Eric Raymond (a major hacker) have allowed us to understand the phenomena more clearly, other companies have paid close attention, and considered the commercial opportunities of the open source development. Netscape's announcement of the Mozilla project was the first mainstream (previous Wall Street Darling!) company to switch its product to open source. This allowed the movement to gain additional momentum.

How does Open Source Work?

Sucessful open source projects require the following: Leadership and managing the project is critical to an open source success. While this may seem obvious (and therefore not worth mentioning) it is critical if one wishes to get volunteer contributions of effort in developing the project, when the availability of that effort is a finite, and a scarce resource. Thus the project also needs to be very imteresting and useful to the hacker community (accomplish something that is important to others, not simply the project leader). Leadership involves communication to the community, and rewarding those in the community for the work they provide. Unlike traditional work, where the reward is purely economic, in the open source community it relates to ego (being recognized in the readme file), seeing work being implemented quickly (instant gratification) and being able to take advantage of the network effects of open source development (i.e. each person contributes a little, but gains from all others' contributions). This is also a political process, as developers essentially form alliances. The Prisoner's Dilemma model can help explain the issues with respect to continued cooperation within this community.

Discussion Topic: Identify specific tasks an Open Source project leader needs to undertake in order to facilitate a successful project (e.g. maintain an FTP site, website?)

The developer community, as a volunteer resource, is finite. This leads to markets that can only support (effectively) one open source project. We see the winner takes all phenomena in play. If there are two open source projects, the market will tip towards one project, as a positive spiral will take effect, the market leader will survive and become robust, others will diminish (but not die, since they are open source! Closed source projects die, open source projects lay dormant until they are picked up by someone else. This is an important distinction.)

The Advantages of Open Source

The network effects of developing in an open source environment can be very powerful. By engaging many developers, each developer will benefit from all other developers in the project. Thus as more developers work on a single open source project, that project will become more rewarding for each developer. The outcome of this effect is that it can lead to rapid development cycles of the software. This development model, if implemented effectively (as in the Linux process,) is more robust and leads to a greater evolution of the product, than in the closed source development model. This can allow a market leader to move down the learning curve more rapidly, increasing its market leadership. It can also allow a market follower to gain momentum on a closed-source market leader, something that is very hard to accomplish for a closed source competitor in a networked economy!

Open source also guarantees you (if you are considering an open source alternative) or your customers (if you are marketing an open source solution) against lock-in. Open source provides alternative vendor solutions, as well as the life of the software. Thus if you purchased a close source commercial solution, that solution is only workable as long as the vendor that provided it remains in business, and the vendor's business goals remain aligned with that software solution. An open source software solution would allow you to develop and maintain the code yourself, or switch to another open source vendor of the code. As a company marketing an open source solution, you can use it to your advantage by stipulating you are allowing your costumers freedom of choice. This issue can also be related to the issue of being dependent on a closed source platform for your software solution to function. If the platform was open source (Linux vs. Windows,) software developers would have much more control of the development of their own software!

Microsoft is not passive about the threat of the Open Source initiatives, as highlighted in the Halloween Memo w/o Raymond.

One of the often cited disadvantages of open source is the notion of the free-rider effect. This argument has been put forth along with the essay Tragedy of the Commons. Clearly however, in the case of open source development, the code-base is not a finite resource that diminishes in quality with additional users, whether they are users that contribute to the evolution of the code, or users that simply use the product for free without contributing any resources (economic or developmental). The latter, the free-riders, do not have a negative effect on the resource, assuming they are not a burdon to the community (asking questions etc.) In fact, it is likely that this group will adopt a commercial version of an open source product, thus paying for the customer service and after sales support and helping broaden the market for the open source solution. Those that use the product for free, that don't contribute to the development effort, are going to be more expert in the knowledge of the product, and are potential contributors to the knowledge-base at some point in the future when additional needs for the product arise. This group are therefore likely to get locked-in to the product at the initial stages, and perhaps become contributors at a later stage.

Discussion Topic: Consider arguments that suggest a closed-source alternative is better than an open-source alternative, from either the vendor or client viewpoint.

Open vs. Closed: An Economic Perspective

Open Source software is available for free, commercial versions of the same open source software may also available at a price. These versions include customers service, packaging, detailed instructions and free upgrades. (Redhat's version of Linux for example.) The question is, does this pricing structure make economic sense. Should software be sold on a per unit basis to recover development costs, or sold on the basis for charging for ongoing support.

The factory, industrial age, model would suggest charging on a per unit basis for the intellectual property of the code (closed source). While this makes clear sense for automobiles and houses, that include significant variable costs per unit, software, and other digital products tend to zero variable costs (zero marginal costs). The costs associated with these products is fixed and sunk (development costs). Thus additional units that are retailed do not cost the company anything, unless the customer needs support after the sale! This support is important for the product to be effective for the users in the medium- to long-term. Thus by charging on a per unit basis, to try to recover sunk costs, creates an incentive for developing software that is purchased but not used (no need for customer support). While the customer support center is considered a cost center, the after sales support will be limiting, which in turn will lead to under-served customers. A product that is given away for free, but has a paid alternative that supports the customer service infrastructure (a free alternative is required for the Open Source license for those offering commercial versions) makes perfect economic sense. This is the strategy adopted by RedHat and this actually extends the market for the software beyond its traditional base of hackers. This argument therefore supports the economic issues related to pricing open source software, but it should also be applied to ALL types of software.

Since a significant portion of total costs are in bug fixing and additional support and maintenance, the pricing structure should account for this, and have the developer community help develop the software (network effects).

**Discussion Topic: Highlight examples of digital products that are priced on a usage basis, rather than simply an upfront price?

Life Cycle of Open Source Process

As we consider the product life cycle, its important in relation to when to "open source" a project. Clearly some context has to be established, such that external developers are going to be interested enough to contribute their finite resources to the project. Thus an alpha version of the product needs to be complete. This was the case before Linus announced the Linux Operating System to the Minix news group. On the other hand, the project does not want to be so mature, that it is no longer interesting for external developers (their ability to contribute becomes marginal) and since they were not part of the evolutionary process of earlier development, it is hard to engage them at this point. This issue, along with the issues of poor architecture can help explain the initial "lack of perceived success" of the Mozilla Project.

An argument can be made for offering a product open source, at a later stage in the life cycle, to extend the product's life while shifting internal development resources to new development efforts. This will help guarantee the life of the product for the current installed base until they switch to the new product.

Workable Business Models for Open Source

As highlighted in the The Magic Cauldron, there are a number of business models that rationalize the open source motive. The major models are highlighted below, refer to The Magic Cauldron for others.

Cost Sharing Approach: As companies share common needs with respect to technology, it may make sense to share resources in order to develop common technologies that help each business. Clearly this should be done in areas that do not offer competitive advantages to single businesses, but many business processes would fall into this category. The Apache web server is a very good example of this. The Apache web server is the leading server in terms of market share according to the Netcraft survey of web servers. Clearly a web server is important to the running of a business (critical) and the options available to those implementing a server are:

While chosing an open source alternative may appear foolhardy, the market suggests this is what many are doing, and it does make sense. The code was initially developed by the NCSA team that developed the Mosaic browser. As many of the team left to join Netscape, the code was not maintained, and those using the server were not getting any support. They decided to collaborate and continue developing the product, using the open source model. They have proven very successful. Each contributing participant is helping improve the code-base, thus the product is clearly able to take advantage of network effects as each participant benefits from others participation. Since the Apache server includes the source code, each user is able to modify the code to their specific needs, and the life-time of the server is guaranteed to live beyond any one development team.

The Apache Software Foundation provides support for the Apache community of open source software projects.

Risk-Sharing Approach: Similar to the cost sharing approach, for areas that are critical to the effective functioning of the organization, but not deemed a competitive advantage, it makes sense to pool resources with other companies to develop a technology that is then available for all to use. This is a better alternative than to simply develop it internally, and then (potentially) lose the internal developers and realise the code does not live beyond the lifetime of the original developers. This occurs more frequently that we would care to admit!

Market-Positioning Approach: This is the strategy Netscape adopted with the Mozilla Project. Netscape was losing significant market share in the client-side browser market. They were in jeopardy of losing their client-side franchise altogether. While this did not have much impact on revenue (since most of their browsers were given away) it was important to have a stake in the client-side to guarantee their server-side market. If Microsoft could own the client-side market, they could start dictating specifications that force the Microsoft server-side products to become proprietary industry standards. This is clearly not a good situation for Netscape, or the market as a whole. By open sourcing the client-side, they are guaranteeing the future of the browser, without regard for any revenue generation (since it was not generating revenue anyway)!

Free Product, Pay for Service: This is a strategy adopted by RedHat. with its Linux Operating System. RedHat sells its operating system on a CD, with customer support, instructions and upgrade options. It also offers the source code for the product for free on its website (a requirement to comply with the open source definition). Thus the cost for the product is associated with the additional support that RedHat offers. They essentially broaden the market for the Linux Operating System by making it available to people beyond the hacker community.

The Ecology of an Open Source Marketplace

Looking at the Linux market is instructive in understanding how an open source marketplace can work. The Linux operating system is available at no cost, for all to download, from the internet (check freshmeat and linux.com). Many hackers have freely contributed to the initial code developed by Linus Torvold in 1991. They have essentially built an operating system that is more stable and robust than any commercial competitor (Windows, Mac) in a much shorter timeframe. Unfortunately it is only available, under these conditions, to fellow hackers, as the complexity involved in using the system as available for free, is too much for the average PC user. (Author included!)

This creates a market space for commercial Linux providers (like RedHat) who can charge for a commercial grade version of the software that targets more typical PC users, helping broaden the Linux franchise (since it competes with Microsoft, this is a good thing for the hacker community). Since the software license for Linux (GPL) allows anyone to charge for the product, hackers do not feel this behavior is descriminating against them (since they could also do the same). The license also requires each commercial provider to provide a version at no cost, they do, without the support.

The commercial providers, on top of providing customer support, upgrades and packaging, can also target additional resources to work on parts of the Linux system that are not as appealing to the hacker community. Clearly one area that needs work on at this point is the development of an effective Graphic User Interface (GUI.) Since this is particularly important to the commercial market (and not as important to the hacker community) then resources can be supplemented by the commercial providers. The GNOME project and KDE project are focused on some of these issues. Commercial providers also hire some of the hacker community and therefore provide economic incentive to develop the technology.

Discussion Topic: Discuss the risks and benefits to the relationship between the hacker community and the commercial Open Source software providers (like RedHat). Would you consider the relationship symbiotic or parasitic? Is this marketplace sustainable in the long run?

An Ideal Marketplace?

In an networked markeplace we know that large enterprises can take advantage of network effects, reduce their average costs and increase their progression down the learning curve. All these issues point to the larger the market share, the more efficient a company can operate. The company with the largest marketshare is able to offer better (more useful) products at lower costs. In fact, if the market was a monopoly, the monopolist would be able to maximize these advantages. This is unlike traditional markets (auto industry etc.) which do not scale as well, where at some point size creates inefficiencies (decreasing returns to scale, a function of problems with communications etc.) The problem with a monopolist marketplace is, who can control the behavior of the monopolist. (Microsoft has shown that it is easy to manipulate the market when you have the power they have.)---reduce innovation, control marketing channels etc. etc.

One can then consider that an "ideal" market, for a networked marketplace is where the technology innovation takes full advantage of network effects, learning curves etc. ...but the marketplace for the consumer product is competitive. Thus we would have an open source development model, where all development effort is focused one developing one code-base (clearly if all energy is focused on one solution, we would have a better product than if there were multiple simultaneous and fragmented efforts that are proprietary) with commercial competition between the vendors (like redhat linux market) who develop commercial distributions of the product.

Discussion Topic: Discuss the pros and cons of this type of marketplace.

Now go to the discussion board http://www.delphi.com/alex1 and be prepared to contribute to ongoing discussions under the Week 6 and 7 Folder, with regard to this material, paying particular attention to the suggested discussion topics, highlighted in red.