Raymond is stating that open-source will grow to threaten software developed in the "traditional" way, that this competition will be based on the performance of products developed in the two regimes (rather than on any belief about morality or ethics) and that open-source will "triumph" in this competition, not in selected areas, but across the board. These claims deserve to be investigated.

That open-source is a threat to "cathedral" software (1) is an established fact. Microsoft's now notorious "Halloween Document" [2] makes it clear that this cathedral behemoth finds that:

"OSS poses a direct, short-term revenue and platform threat to Microsoft" (2)

"OSS is long-term credible"

"The ability of the OSS process to harness the collective IQ of thousands of individuals across the internet is simply amazing"

It is also clear that (at least in the case of Linux) the success of open-source is a marketplace victory, due to the quality of the product that it generated. The growing adoption of Linux can not be seen as the result of any philosophical set of views about whether or not software source code should be free or not.

Yet, while it is clear that Linux is competing well and will continue to do so against Windows, it is difficult to believe that open-source culture will triumph in the development of every possible type of software application. A quick, extreme, anecdote will make this point more clear:

My accountant (as I write this, April 15th is looming larger and larger in my mind...) uses a very sophisticated software tax package to generate my 1040 Forms, Federal and State. Simpler versions of such packages, like TurboTax, are sold at the retail level. Would hackers choose to develop an open-source tax package? Probably not. And if such a package existed, would there be demand for it? Would accountants, whose professional reputations ride on every calculation they make, trust a software package developed in an open-source environment? Possibly not. It might be more likely that they'd pay money for software developed by experts in tax law who hired programmers, rather than by programming experts that had a knowledge of tax law.

If open-source can win on the operating systems battlefield, but not in the market for CPA-tax-package software, it is a reasonable thing to ask:

• Which battles will be won by open-source? Which by cathedral software?
  
  
• Can we determine the characteristics of software applications that decide the battle one way or the other? Can we determine the outcome of each battle in advance, so that the more effective development path is taken and the battle need not be waged?

The Shoulders We Stand On
This paper approaches its motivating questions from the perspectives of microeconomics and competitive strategy. The microeconomics of open-source software must concern itself with examinations of the supply and demand for such products, and how this supply and demand interact in the marketplace. These market structure questions regarding the number of competitors and the nature of competition in the software industry naturally spill over into a discussion of prescriptive strategy for competition.

The economic supply of open-source software has been studied directly by Rishab Aiyer Ghosh [3,4] and has been indirectly addressed by Eric Raymond [5]. Supply revolves around the relationship between the market price of a product or service and the willingness of developers to bring it to market. Of course, open-source software has no market price. That such a product exists puzzles the hell out of economists; any open-source contributor is an irrational person in the minds of traditional economists, at least in the minds of those who don't peer too deeply into the open-source phenomenon. The typical economist cringes upon hearing the words, "gift economy" used to describe the way in which hackers donate their energy to the development of open-source. Economists have a near religious level of belief in utility theory, which basically says that people choose to do those things that make them happy ("maximize their utility" in econ-speak).

Economists have a very hard time understanding why anyone would give anything away; this blindness may contribute to the lack of attention that the corporate world paid to the open-source movement in its early days. Ghosh solves the paradox of the supply of open-source, reminding us that the concept of utility includes all things that matter to a person, including reputation, recognition and the possibility of future remuneration. He points out that open-source developers are recognized in the hacker community, that their reputation grows there with increasing levels of contribution, and that this recognition and reputation may one day create an opportunity for the contributing hacker to make an upward career move. Raymond addresses the same topic. Economics is the study of the movement of scarce goods and services; in an interview, Raymond was asked, "So the scarcity that you looked for was the scarcity of attention and reward?" His reply was, "That's exactly correct".

These arguments should be sufficient to dismiss the standard objection to gift economies in the economic literature: that there is an incentive to receive but not give, and that since each person has such an incentive a gift economy should collapse. But there is a subtle question not yet raised. It is, "What are the necessary conditions for an open-source gift economy to form?" Raymond [1] addresses this question from one perspective and claims that the qualifications of the project leader and the state of the project at the time the source is released to the public are critical issues. But is there more? Is the nature of the project and the composition of the intended user community material in this analysis?

The economic demand for open-source vs. closed-source software is has been presumed to be a closed issue. Open-source has been touted as better software for free. But there are many open issues on the demand side of the equation. First and foremost, is a product produced in an open-source environment always better? An even more interesting question is: is an open-source product always better for each customer segment in the marketplace? These questions also deserve some attention.

From the perspective of competitive strategy, this paper follows in the tradition of Porter [6] and Ghemawat [7] who described the fundamentals of competitive strategy and sustainable competitive strategy. Clemons and Weber's [8] analysis of competitive strategy and market micro-segmentation in information-intensive environments also inspires this paper.

A Little Bit of History
The cathedral model of software was not the first way in which software was developed and distributed. As Martha A. Garcia-Murillo [9] points out, software was once free. In the 1950s and early 1960s, when software was not portable and each program was written for a particular piece of hardware, software was developed and given away by hardware manufacturers. This was done as a way of enhancing the competitive position of one mainframe against the rest of the market. User groups, where customers met with each other and the developers, were common. There was no reason not to make source code available to these user groups, as the only potential users all already had a copy of the program. Source code had no value, other than as a way of extending the use of a particular piece of hardware. If the users suggested or wrote an improvement, everyone benefited.

Once compilers were written and source code became increasingly portable, software took on a value of its own. The natural consequence of this was that software began to be sold as an unbundled product. It is important to ask why the user groups and the co-development of software that they fostered did not survive this transition. What was it about the environment of the portable software industry twenty-five or thirty years ago that was different enough from that of today so that an open-source movement did not happen at that time? Some possible answers are that there were far fewer hackers at that time, and that the demand for software was far lower.

Value - An Economic and Competitive Perspective
The foundation of an analysis of the relative success of two competing products rests on the concept of "value". A similar concept is what an economist would call "demand", not just the quantity of a product demanded at its current price, but the quantity that would be demanded at any price that you could imagine. If two (or more) competitors bring their products to the same market, it is reasonable to believe that the lion's share of that market will go to the service or product that provides the best value to its customers. We've all heard many labels for this concept; Cost Benefit Analysis and "Bang for the Buck" are two.

What is value, really? Some have said that it is the difference between what something is worth to a customer and what that customer pays for it. And while this definition makes some sense, it fails to incorporate a notion of competition between suppliers in an explicit way. A better metric of value in competitive analysis (thanks to David Croson of the Wharton School for this one) is the difference between what you'd pay and what it costs to make. Why is this a better definition? An example makes this clear:

Suppose you and I both provide a service for a price of $8 that a typical customer thinks is worth $10. We each provide $2 of value, right? Well, suppose that the activity costs me $6 to do and costs you $7. I make $2 and you make $1. In a competitive market, I'll cut my price. Suppose I cut prices to $6.50 - you go out of business. In the long run, you've got to copy my production technology or find another line of work. And in the long run, the customer gets a service valued at $10 and the provider pays $6 - there's a difference between customer value and production cost of $4 that somehow gets split between them.

Initial Market Conditions	My Service	Your Service
Market Price	$8	$8
Worth to Customer	$10	$10
Customer "Surplus"	$2	$2
Production Cost	$6	$7
Producer's Profit	$2	$1
Value (=Customer's Surplus + Producer's Profit)	$4	$3

Competitive Market Conditions	My Service	Your Service
Market Price	$6.50	Can't compete
Worth to Customer	$10	$10
Customer "Surplus"	$3.50	-
Production Cost	$6	$7
Producer's Profit	$0.50	-
Value (=Customer's Surplus + Producer's Profit)	$4	-

The product providing higher value wins.

So if production costs and what a customer thinks the product is worth are what matters, how do traditional and open-source software compare on these dimensions?

The Envelope, Please...
First let's examine what software is worth to the customer. There are many dimensions of worth, some of theses are: reliability, speed of execution, breadth of features, adaptability, support, and ease of use. Eric Raymond [1] argues that software developed in an open-source environment is faster, more deeply featured, more adaptable, and easier to use.(3) For example, Raymond argues that open-source products will have more functionality because for every need a user might have, there is someone in the hacker-donor community who would find creating that functionality to be a relatively fun and easy task. These claims are predicated on the existence of a community of hackers dedicated to the development of the product. If there is not a critical mass of users who are interested in improving the product and are capable of doing so, these claims are not appropriate. So we see that the target audience for the product influences the product's development strategy.

This critical mass of hackers is an important concept. If we accept Ghosh's notion [3], that hackers are motivated to contribute in an open source environment by ego and reputation issues, asking these people to do open-source development for users rather than other hackers is like asking a comedian to perform in front of an empty house. And this issue feeds on itself, there may be no middle ground. Either the audience has hackers in it, who appreciate the contributions of other hackers or it does not. An environment where there are only a few others who'll stroke the ego of a contributor may not be stable, for if these people are not joined by other they may well leave for "greener pastures".

In this way the open-source development environment is like a co-ordination game [10] where there are multiple equilibria; where the hackers devote their energy may well be far less important than the fact that many of them have chosen the same focus for the creativity.

The cost of a software package also has many components. Purchase cost is one, and clearly a competitor using an open-source philosophy has an advantage on this dimension. Other costs include those associated with: training, maintenance, upgrade, consulting, and downtime. There is also programmer time spent in search of resources, like previously written modules and documentation. Here too we see market segmentation issues. Training and upgrade costs are clearly lower in an environment populated by programmers, people who are proficient in the use of computers.

Though the industry is as of yet too immature to confirm this, I suspect that consulting time for open-source software will be more expensive than consulting time for traditional software. Here's two reasons why:

• Developers have an incentive to price consulting time at a lower rate. Consulting for traditional software can (but won't necessarily) be done by the developers. These firms can bundle consulting with the sale of the product, in order to generate sales.
  
  
• The developers of software in a cathedral model may be more familiar with the entirety of the code than others. This may give them a cost advantage in consulting, which they may pass on (in part or in whole) to the customer.
  

The Cathedral versus the Bazaar: ...and the Winner is...
Let's summarize the comparative provision of value that is provided to the users of open-source and closed-source software:

Value Provided	Open Source	Closed Source
Increased Benefits	Reliability, breadth of features, adaptability, ease of use (hackers)	Ease of use (users)
Reduced Costs	Zero purchase cost	Lower consulting cost(?), search costs
Determined case-by-case	Participation by hackers (creation of an open-source product), the degree to which the customer requires training, the specialized needs of the users, etc.

The claim that one of these methodologies is better (provides more value) than the for the development of a particular application must clearly be the result of two factors:

• The existence of programmers willing to work in the "better" environment on the application,
  
  
• The relative importance of each of the benefits and costs outlined above.
  
  

The first of these goes to supply, the second to demand.

As was argued above, an open-source project requires the contributions of hackers, and these contributions in turn require that there be other hackers involved in the project who will "appreciate" each donation. Furthermore, as in the tax application anecdote, the application must be one which the hacker community is excited about, else there will be too few contributions to create a competitive application. If we combine these two concepts, we see that applications that require in-depth knowledge of a user's profession (non-programming, e.g., accounting, engineering, medical, etc.) are less likely to be viable candidates for an open-source effort.

Given that a large enough community of hackers finds participation in an open-source programming effort to be "fun", and a competitive open-source product is developed, when will the users demand this product over the traditionally developed product? When the benefits and costs of using the open-source product outweigh those of the closed-source product. This may be true in a number of areas:

• When users are relatively poor. In this scenario, the lack of purchase costs is a boon.
  
• When users are relatively savvy. Here, the need for outside help (and its accompanying costs) is limited.
  
• When users had specialized needs. In this environment, the special nature of an open-source product comes to the fore.
  

All of this can be summarized by two claims:

1. The larger the scope and the broader the use of the application project, the more likely it is that an open source effort will succeed. This is so because larger scope projects require more functionality, and providing functionality is a strength of the open-source method. This is also true because the broader the use of the product, the more likely it is that any potential contributor needs such a product and will contribute to its development.
   
   
2. The more that the application's user community consists of hackers, the more likely it is that an open-source effort will succeed. This is logical for two reasons. First, if the target market of a software product is programmers, the potential for contribution in an open-source development project is higher. Second, the more targeted a program is toward programmers, the less likely it is that specialized knowledge of another industry (e.g., accounting) is needed in its development.
   

Evidence
The first question that must be asked of any theory is: Does it fit the data that are already gathered? In the next figure, we place the following open-source applications: Linux, Netscape, GNOME and fetchmail.

Linux, as an operating system, is a member of the most widely used class of program there is. The number of applications written "on bare metal" these days is very, very low. Everyone else interfaces with computers via an OS. The scope of operating systems is very large, they get between every task a user requests and the actual doing of the request. And just as every user needs an OS, so does every hacker. Consequently, Linux is placed in the upper-right corner of the figure.

Netscape is a competitor in the browser market. While not as broad a product class as operating systems, browsers provide a great variety of functionality. And while not every computer user is an internet user, it certainly seems to be increasingly the case. As for the composition of the group of users of browsers, it is certainly true that every hacker uses one. Therefore, Netscape is positioned on this chart just below Linux.

GNOME is an open-source graphical-user-interface (GUI) for Linux. It is reasonable to say that GUIs have as broad an appeal and as broad a use as browsers. And clearly, the large hacker/user base that Linux has could all be reasonably assumed to be potentially interested in a GUI. GNOME is placed next to Netscape.

Eric Raymond's fetchmail is entirely aimed at hackers, being a program to move mail from machine to machine. As a single-function program, its scope is more limited than that of the other examples cited above. We place fetchmail in the extreme lower-right corner of the chart.

As an exercise, let's consider the accounting package mentioned earlier. A professional accounting package would have limited scope; it is a single function program. Its breadth of use would be limited to CPAs. No (or perhaps a very weird few) programmers would be users of such a program. A program like TurboTax would have a broader set of users (all heads of households) but the number of hackers who would be qualified to work on and interested in working on TurboTax in an open-source environment would probably be small. We place these programs on the chart as well.

While the data are anecdotal, and the placement of these data points on the chart is speculative and subject to debate, it seems safe to say that the "real world" is not blatantly in contradiction to the theory posited here.

The Chapel
If we accept the above analysis, we can certainly see why Microsoft is worried about Linux. Operating systems seem to be the ideal product for an open-source development effort. We can also see why Microsoft is concerned about open-source in general. Microsoft's major source of revenue today, and in their plans for the future come from mass-appeal (high breadth of use) applications, and their expertise is in information processing intensive fields, rather than in medicine or law. Microsoft is now and will for the foreseeable future be positioned in the very vulnerable upper-right hand corner of the figure. Open-source threatens everything about Microsoft.

In fact, open source threatens all general purpose information processing products. If "the Cathedral" refers to St. Patrick's, the Bazaar looks like a sure bet. But what about the great middle ground of the figure, the area where the cathedral is not so large and all-encompassing? The area where the cathedral might more reasonably be called "the chapel"?

If closed-source programming is to have a viable financial future, it is in the chapel and not in the cathedral. By staying away from areas that are broad, general purpose applications of computing appealing to vast user segments, and by focussing on applications where specialized knowledge of a non-programming nature is needed to compete, private software houses can develop programs without fear of the open-source movement.

An example of this niche strategy is educational software. My three-year-old daughter plays with a variety of programs, none of which would probably appeal to a hacker's creativity. And while there are a lot of three-year-olds in the world, not many of them are programmers. Additionally, the degree of specialized knowledge necessary to design a competitive piece of educational software is fairly high - the credits on these pieces of software list many names with masters degrees or doctorates in education.

The Swap Meet The old saying, "There's nothing new under the sun" is most certainly true, at least when it comes to the activities of businesses. The term "open-source" may be particular to the software industry, but the concept it embodies is not. An example of a parallel process can be found in the field of process quality. Here, firms that are acknowledged as having "best practices" or being "best in industry" with regard to some measure of process or product quality routinely permit competitors and representatives of other industries to visit their plants and facilities to discover what the cutting-edge of industrial practice is.

These firms are practicing a kind of open-source quality. They readily share their procedures and work together to develop better ones. There is a subtle difference, though. While the participants in this process will all state that quality is an integral part of their product or service, it is not their product or service per se. This makes the quality arena more of a swap meet than a bazaar. In a bazaar, I sell my product. In a swap meet I trade things of value that are not my main product that I have for things you have that I might value a bit more.

The swap meet model might be applied to the free-software movement as well. Freeware libraries of utilities could be seen in this light. Perhaps the open-source movement can develop a swap meet model of software to compete with businesses in the chapel; perhaps these firms can develop a way of using a swap meet to better compete in their niche markets.

Keeping It Up
Finally, we must address the issue as to whether or not an open-source strategy is sustainable. There are three fundamental criteria for being able to sustain a competitive advantage:

• You must have a competitive advantage
  
• Others may not be capable of fully duplicating what you've done
  
• You must be able to continue doing those things that give you advantage
  

Clearly, open-source software has an advantage in both cost and benefits over cathedral software. There is no reason for others to duplicate an open-source effort, they can join it! And if they decide to duplicate it, for whatever reason, they will be creating another open-source competitor for the cathedral. As for continuing to do what they do: open-source efforts have some of the most motivated "employees", they recruit worldwide at no cost to themselves, their stockholders never become irate. Short of governmental action banning this form of innovation, it is difficult to see how open-source projects could fail to continue to develop quality software.

Conclusions
A competitive analysis of the software market, focussing on the relative competitive position of open-source and closed-source software confirms Microsoft's worst fears - open-source is here to stay and has the ability to take on and beat Microsoft and other cathedral behemoths on their own turf.

This analysis also points out that there are software market segments where closed-source initiatives should be able to out-compete open-source projects. This should happen when the scope of the project is limited and specialized knowledge is required of the programmers, when the target market is small enough that a "critical mass" of hackers is not attracted to the effort, and when the users are not hackers.

Bibliography

1. Eric S. Raymond, The Cathedral and the Bazaar
   
   
2. http://www.opensource.org/halloween1.html
   
   
3. Rishab Aiyer Ghosh, Cooking pot markets: an economic model for the trade in free goods and services on the Internet
   
   
4. Rishab Aiyer Ghosh, Institute for Technology and Enterprise teleconference
   
   
5. http://www.techweb.com/internet/profile/eraymond/interview
   
   
6. Michael E. Porter, Competitive Strategy
   
   
7. Pankaj Ghemawat, Sustainable Advantage
   
   
8. Eric K. Clemons and Bruce W. Weber, Using Information Technology to Manage Customer Relationships: Lessons for Marketing in Diverse Industries
   
   
9. Martha A. Garcia-Murillo, Institutional Development in the Software Industry: Intellectual Property Protection, Unpublished Dissertation, University of Southern California
   
   
10. Any introductory Game Theory book provides a discussion of coordination games.

---

(1) The terms "cathedral" software, "traditional" software, and closed-source software are used interchangeably throughout this paper.

(2) The terms "OSS", open-source software, and open-source are used interchangeably throughout this paper.

(3) Raymond was almost certainly saying that open-source software is easier for hackers to use, i.e., easier to adapt to their own needs.