Nota bene:
This is my final paper for Professor Howard Besser's Impact of New Information Resources: Multimedia and Networks at UC Berkeley's School of Information Management and Systems (SIMS) in the fall semester of 1998.

Open Source Software (OSS):
A New Business Paradigm?

Submitted by Rick Murtha on December 10, 1998

Table of Contents (click below to jump to sections of interest)



The Cathedral and the Bazaar
Is OSS a Real Threat to the Software Commercialization Establishment?
But Why is OSS such a Threat?
Software Licensing Arrangements
What Makes OSS Feasible?
OSS Infrastructure
Why Do Hackers Do It? What's In It For Them?
An Examination of Hacker Culture

Is the OSS Model Sustainable as a Long-Term Business Model?


Seemingly, ever since Microsoft busted onto the scene about twenty years ago, one of the most outstanding and most profitable business models in the world was that of developing and selling proprietary software. Microsoft understood full well that a computer is inert, just a handful of cold circuits and resistors. What gives it life is software: software is the computer's lifeblood. Microsoft took advantage of this expertly and wrested control of the PC industry from computer manufacturers. In fact, many trace the effective beginning of the information age to this shift of importance from hardware to software, propagated by Microsoft's budding business strategy.

However, over the past few years an intriguing phenomenon has begun to pick up steam, that of open sourcing of software code. Open source software (hereinafter OSS) is often mistaken for "shareware" or "freeware" but there are significant differences between these licensing models and the process around each product. For example, according to Dale Dougherty, CEO of Songline Studios, if you refer to OSS as "free software", then the mantra in explaining it is, "Think free speech, not free beer." This refers to the concept of freedom as opposed to free of charge. According to Microsoft engineer Vinod Valloppillil, "open source software is software in which both source code and binaries are distributed or accessible for a given product, usually for free. OSS (uses) a development process which promotes rapid creation and deployment of incremental features and bug fixes in an existing code / knowledge base." Missing from this definition is the evolutionary manner in which code fixes are generated and included in the standard.

Independent software developers (throughout this document I will use this term or "independent developer" interchangeably with the word "hacker") have taken different applications and freely circulated their source code looking for colleagues to take it and improve upon it, to pick up the ball and run with it for a while too. It is a peculiar phenomenon related to the computer hacker culture. Some say it's one upsmanship, the intellectual challenge of making something better through hard work and brainpower, or a gift culture in which the developer's status within the community is tied to how much s/he gives or the quality of the gifts s/he presents. Still others believe that these hackers operate from an anti-Gates/anti-monopoly moral high ground. Yet others believe that ultimately their real motivation is the promise of long-term financial gain. Whatever their motivations might be, open source software is changing some long-held assumptions about how software is produced and distributed/disseminated. I am interested in examining the intriguing phenomenon of OSS hackers' motivations as embodied in the intriguing hacker culture.

I am also interested in looking into the economic sustainability of the open sourcing model. Linux, which is a Unix-based operating system, is one of the most outstanding examples of high impact open-sourced software, and is gaining in leaps and bounds on Windows 95/NT as an operating system. It is among the very few to give Microsoft a run for its money. Will this trend continue? Will open-sourced software be able to dethrone the current software development and sales paradigm? Will the generalized desire of IT administrators to stay away from proprietary technology and use open standards bode well for Linux and its ilk? These are the main questions I will examine in this paper.


The Cathedral and the Bazaar

Before discussing the viability of OSS as a sustainable business model and the developer motivations which help fuel its existence, I think it would be helpful to take a look at Eric Raymond's take on OSS as discussed in his paper, The Cathedral and the Bazaar. Raymond equates the traditional software development and commercialization business model to the construction of a cathedral. According to Raymond,

"I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like Emacs) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time."

The cathedral metaphor Raymond employs represents the traditional software development business model. He equates it with the development of monolithic applications and proprietary technologies. These frustrate customers for a number of reasons.

  • less than desired quality because of infrequent releases
  • non-interoperable with competing technologies
  • customer lock-in to a particular vendor by products which
    • only work with (or work optimally with) products from the same vendor
    • make migration difficult because of the threat of stranded investment

After witnessing the great success within an open source software development effort of the Linux operating system, Raymond equated it to a bazaar.

"(OSS') style of development - release early and often, delegate everything you can, be open to the point of promiscuity - came as a surprise. No quiet, reverent cathedral-building here -- rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches..."

Raymond's bazaar metaphor refers to the new business model represented by OSS, ie. open evolutionary software development constructed by a wide variety of contributors. He equates it with the openness brought about by the establishment of open computing standards. Then when comparing the cathedral and bazaar software development styles, he identifies the core difference between these styles

"In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect. In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena -- or, at least, that they turn shallow pretty quick(ly) when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door."

Raymond contrasts the benefits and drawbacks of these two competing business models. Although he says there will continue to be a place for software development which adheres to the cathedral metaphor, he trumpets the usefulness of the latter and the "evils" perpetrated by adherants of the former with almost religious fervor. It is Raymond's contention, and I agree with it, that OSS overcomes many or most of the drawbacks of software developed under the traditional cathedral metaphor while nearly equalling, matching or even surpassing the benefits of such software development.


Is OSS a Real Threat to the Software Commercialization Establishment?

Apparently so. According to Dataquest, in 1998 Linux will account for 1% of the operating systems sold for PC servers versus more than 60 percent for Microsoft NT. But it isn't this single-point-in-time snap shot which concerns Microsoft and the rest of the traditional software development world. The worrisome statistic for them is that corporate customers' usage of Linux was up 30% in 1997 over 1996 and is forecast to go even higher, according to ProData Information Services.

This has gotten Microsoft's attention. On November 2, 1998 Eric Raymond, a leading evangelizer and developer of OSS, released an annotated version of an internal Microsoft memorandum titled Open Source Software: A (New?) Development Methodology. This document, which was written by Microsoft's Valloppillil, asserts that

"OSS poses a direct, short-term revenue and platform threat to Microsoft - particularly in server space. Additionally, the intrinsic parallelism and free idea exchange in OSS has benefits that are not replicable with our current licensing model and, therefore, present a long-term developer mindshare threat."

Soon thereafter, Raymond released an annotated version of another internal Microsoft memorandum titled Linux OS Competitive Analysis: The Next Java VM. Together, Raymond refers to these memos as the Halloween Documents because of the date he received them from his undisclosed internal Microsoft source (10/31/98). Microsoft later acknowledged the authenticity of these documents. The former document acknowledges that OSS is indeed a threat to Microsoft's business model and proposes numerous strategies the company might employ to combat it. The latter document discusses the legitimacy of Linux as a network operating system and in its title equates the threat posed by Linux to Microsoft to the threat posed by the Java Virtual Machine. The Java VM is a "write once, run anywhere" programming language which would allow the one-time development of software applications which could run on a number of different operating systems, thereby enhancing application interoperability, reducing Microsoft's stranglehold on desktop operating systems, and possibly commoditizing its Windows 95/NT OS platform all at the same time. Microsoft has effectively defused this threat so far by adding proprietary extensions of functionality (into its J++ version of Java) which have reduced Java's effectiveness. The former document discusses replicating this strategy of making proprietary extensions in order to close open standards, which would cut down on their interoperability, maintain Microsoft's command of the OS markets and avoid the commodification of their OS platform.

Many consider the documents damning and damaging to Microsoft's position because the proposed strategies seem to be anti-competitive. However, others lend the document less credence as a window (no pun intended) into Microsoft's real thoughts. They believe Microsoft strategically released the documents to coincide with their anti-monopoly federal court case brought by the Department of Justice as a public relations move designed to reduce the perception that they are an invincible monopoly. They do not believe Microsoft actually feels as threatened as it alleges in the internal memos.

I tend to believe that these documents do reflect actual Microsoft sentiment as regards OSS. Microsoft can be accused of a lot of things, but they don't tend to underestimate their business competition. If anything, they have demonstrated a constant fear (some would call it paranoia) of their competitors and perpetual dissatisfaction with their current state of affairs. Over the years they have taken these energies and constructively channeled them toward formulating winning business strategies. Some would say they destructively channel these energies, a statement I don't entirely disagree with. While this may not always lead to superior product development, it has pretty consistently led to outstanding business strategies and formulas which in turn have led to overwhelming success in the marketplace.


But Why is OSS such a Threat?

There is a variety of reasons why OSS poses a serious challenge to the traditional software business model and those who practice it.

  • Mindshare
    By pooling together their combined talents and time, independent developers bring varied ideas to the virtual table. OSS solutions tend to be rigorous because the OSS development process often elicits the best solution among competing ideas. The development effort becomes a large widespread team effort. This phenomenon has come to be known as mindshare.

  • Agility of software development
    Mindshare also tends to be a faster way to develop software. The solution which gets incorporated into the OSS standard is the fastest, best solution. For example, when security holes are discovered, independent developers can pool their talents and post security patches sometimes in as few as 24 hours.

  • Quality of software development
    Because of the mindshare modus operandi, the quality of development tends to be very good, rivaling that of commercial software development initiatives and often times outdoing them.

  • Immunity to FUD tactics
    OSS is impervious to traditional software developers' marketing tactics which attempt to introduce fear, uncertainty and doubt in customers' minds about competing products. These tactics have been instrumental in inferior products achieving market dominance over products of superior quality

  • Ghost competition
    OSS is not a threat posed by one company. It is a business model (Microsoft calls it a "process"), therefore it is much harder for traditional software development companies to formulate and target focused business strategies to deal with. How do you construct and aim competitive strategies at an entity you can't see or touch?

  • Network effects
    Because of network effects, the traditional software development business model and OSS may not be able to coexist on a competitive basis in a single market, leading to a winner-takes-all market result.


Software Licensing Arrangements

In his first memo, Valloppillil categorized software into a useful classification matrix, or software licensing taxonomy as he puts it. It lists seven categories of software on the vertical axis and compares them with five relevant defining software characteristics beneficial to the customer along the horizontal axis. This matrix follows.


Software Licensing Taxonomy
Software Type
Zero Price Avenue
Unlimited Usage
Source Code Available
Source Code Modifiable
Trial Software
Non-commercial Use
Royalty-free binaries ('freeware")
Royalty-free libraries
Open source


A few highlights from this table:

Commercial software has the most restrictive licensing terms for users. It must be purchased, may not be redistributed and is typically only available as binaries to end users. Its source code is unavailable and of course not modifiable.

Royalty free binaries are typically referred to as freeware. These software products may be freely used and distributed in binary form only. Microsoft Internet Explorer is an example of this category of software.

Open source software comes in a few flavors. The most interesting of these is Linux style in which the user is given the greatest freedom to use and modify source code. Users are free to modify the code as long as their derivative code is modifiable. This is framed in Linux's General Public License which I will cover below.

This software licensing taxonomy clearly demonstrates some of the licensing advantages OSS gives its users and is a window into why traditional software developers feel highly threatened by it. OSS provides the user with a much greater degree of flexibility than do traditional commercial software products.


What Makes OSS Feasible?

In Raymond's paper, "The Cathedral and the Bazaar," the author identifies a number of rules of thumb as well as general conditions which must be in place for OSS development to hold water. In this section I make a few observations of these.

1. Raymond again:

It's fairly clear that one cannot code from the ground up in bazaar style. One can test, debug and improve in bazaar style, but it would be very hard to originate a project in bazaar mode. (A) nascent developer community needs to have something runnable and testable to play with.

I think the non-economic aspect of OSS development makes the establishment of a ground up software development project in OSS style next to impossible. At the very least it would make it extremely difficult to reconcile with developers' geographic dispersion. Furthermore, it would prove challenging to drum up interest from hackers who can't tangibly see what needs to be fixed. Starting a project from scratch would also conflict with what Raymond calls the need to give a plausible promise.

When you start community-building, what you need to be able to present is a plausible promise. Your program doesn't have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is convince potential co-developers that it can be evolved into something really neat in the foreseeable future.

2. Every good work of (open source) software starts by scratching a developer's personal itch.

OSS development starts when, in the course of his/her personal computing, a hacker is faced with a problem that available software can't fix. The hacker starts to solve his/her own problem, not somebody else's.

3. Good programmers know what to write. Great ones know what to rewrite (and reuse).

Why start from scratch when a partial solution probably already exists somewhere out there?

4. Plan to throw one away; you will, anyhow. The best of competing OSS solutions prevails and gets included in the standard.

It is exceedingly difficult to know beforehand whether or not the development route taken will be successful. In fact, it is likely that at some point the hacker will reach a dead end and have to scrap the code already developed. Simply starting over will be more efficient then trying to rework faulty dead-end code. Though he doesn't say it explicitly, I believe Raymond is getting at the hacker's management of his/her own expectations. It will be a lot easier to go forth after trashing dead-end code if you expected from the start that you might have to do so.

5. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

I think this rule of thumb comes from the growing emphasis placed on understanding the end user's requirements by actually talking to the end user. When your end user is another hacker who has the competence to improve code, allowing him/her to participate in code improvement is a smart way to leverage that knowledge to develop better code more quickly.

6. Release early. Release often. And listen to your customers.

The more often you release, the more quickly bugs will become apparent and fixed by the developer community. This observation aligns with a business maxim which says that the earlier you catch mistakes, the less costly a solution will be. Having your customers help you catch mistakes seems to be a good way to enhance the ability to catch mistakes and reduce the costliness of correcting them.

7. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

This rule of thumb seems almost to be a corrollary of rules 5 and 6. Spotting errors is tough and so is fixing them. But you can't fix what you haven't spotted, so identifying a problem almost takes precedence over actually solving it. The large tester base concentrates more attention on the possible problems allowing them to be more easily identified. Once the problem is clearly identified, the problem solvers can get to work and the solution will in all likelihood be apparent to someone within that group.

8. Parallel development.

This speaks to the speed with which you can develop software. Parallel development of course is quicker than serial development. It is also likely to produce a higher quality solution since the best of competing solutions gets picked.

(W)hile coding remains an essentially solitary activity, the really great hacks come from harnessing the attention and brainpower of entire communities. The developer who uses only his or her own brain in a closed project is going to fall behind the developer who knows how to create an open, evolutionary context in which bug-spotting and improvements get done by hundreds of people.

9. Parallel debugging.

Speed again is the crux of this rule of thumb. Additionally, as in rule 7, the fix will be obvious to someone.

10. A visionary leader who other contributing independent developers are willing to defer to.

OSS requires that its leader be capable of:

  • harnessing the strength of numerous geographically dispersed hackers
  • smart enough (technically speaking) to recognize good code and code problems
  • political enough to give recognition to those who contributed to the effort

OSS Infrastructure

In addition to the rules of thumb and general conditions mentioned above, there are two other required pieces of OSS infrastructure, so to speak. These are the communications medium and the licensing arrangement.

It is no coincidence that OSS development "projects" picked up steam with the popularization and availability of the Internet. Hackers finally had a communications medium which could be used as a forum for discussion of fixes as well as a medium for conveyance of the software code in question. This piece of infrastructure advanced OSS light years by facilitating the establishment and organization of geographically dispersed development groups. Without it the complication of adding more and more developers to a project would increase administrative complexity geometrically while only increasing productivity linearly. The Internet keeps the growth of administrative complexity on a linear path.

All of the above observations are of course important to OSS development. Nonetheless, I consider that it is the licensing arrangement that makes OSS work. For example, not to understate the importance to Linux of its visionary founding developer, Linus Torvalds, but, in my opinion, it is the General Public License (hereinafter GPL) that gives it cohesiveness and prevents the fragmentation of the development effort (for the full GPL see Richard Stallman and the Free Software Foundation he directs developed the GPL for their GNU (GNU's Not Unix) project. They also refer to the GPL as CopyLeft (as opposed to Copyright). The GPL allows developers to make improvements on a work of software and get those improvements included in the software standard as long as they return the improvements to the licensing party, ie. the licensor.

The importance of the GPL to the viability of OSS cannot be understated. Without the open conditions enforced by the GPL, the motivation of independent developers to selflessly contribute to a distributed, unadministered open source software development effort would be greatly reduced. Hackers would become concerned as to recognition and attribution to them of their work, financial gain, misuse of their work, etc. The GPL obviates these concerns in return for other rewards which ring the bells of those who belong to the hacker culture (see discussion below). It is the GPL which lays the groundwork and sets the playing rules ensuring that distributed independent development works. In other words, it is the glue which makes OSS hang together.


Why Do Hackers Do It? What's In It For Them?
An Examination of Hacker Culture

It is hard for most people to fathom what would possess brilliant and accomplished hackers to dedicate free time (which, by all accounts, is of scarce avail in a hacker's life anyway) to the development of software which will, apparently, bring little financial reward. Well, maybe they get other rewards for their diligence or maybe they expect to make money after all. However, when independent developers first started participating in OSS development, I don't believe that an expectation of future payoffs factored into the motivations equation. After establishing reputations for coordinating the OSS development of widely-used products, many of these pioneers have begun to reap benefits by writing custom applications built upon their initial products, providing technical support and furnishing other services in general to the companies which began using these products. They certainly don't appear to be getting rich off of it, but, by all accounts, it is producing a comfortable living for them. Nevertheless, this is not to say that in the future today's batch of budding independent developers won't have riches in mind when performing their OSS development.

Well, if financial reward is not the motivating factor, then what is? I think there are several motivating factors which, together, explain the independent developers motivation to participate in OSS development. I think the independent developer's sense of belonging to a new kind of community of developers with marked cultural traits is extremely important in determining his/her motivations for contributing to OSS development efforts. This hacker community's culture is defined by a number of components.

An informal survey reveals that non-hackers and hackers agree: software hackers are a different breed. They are feared by some, reviled by others, enigmatic to still others, and embraced by few. Still, hackers have the natural human desire to feel themselves a part of some kind of community. OSS is, in large part, a manisfestation or materialization of this desire. Maybe "they act different because they are different." I consider that there is a hacker culture defined by a range of characteristics which are complex, rich, and not always evident, predictable, or easy to understand.

Though some may say that OSS development is apparently altruistic, I think that it has a component which is in fact self-serving. It has to do with the way others' perceptions of you help shape your own self image. In this case, the industry respect and attributions which accompany OSS development help pad the hacker's ego. As part of this culture, Raymond's observation on "egoboo," (the enhancement of one's reputation among other hackers), attempts to explain the basic drive behind the volunteer activity which fuels OSS development. Another explanation for this community's motivations is that of the gift culture in which your status is tied to how much you give or the quality of the gifts you present.

Two other components of this hacker culture which results in OSS are the competitive juices of one upsmanship and the intellectual challenge of improving/extending software functionality by finding flawed code and writing patches or simply writing new code altogether. These are basic to the motivations for becoming a software engineer in the first place. OSS development provides hackers an outstanding venue to fulfill these driving motivations.

Most hackers seem to adhere to the notion of letting information be "free." As much as or maybe more than others, hackers feel frustration with the IT industry's long history of producing proprietary, non-interoperable products which cut into the free flow of information. The investment associated with picking a platform and/or vendor is so great that these business practices effectively lock customers in at the expense of customer solution flexibility. Furthermore, the solutions were almost never interoperable with other vendors' solutions. To top it all off, there is a lot of resentment of the arrogant treatment of customers by companies which have wielded the upper hand and taken advantage of their position of strength to squeeze customers to the proverbial last drop. IT vendors' who try to peddle proprietary technology have come to be seen as the enemy. IT users have been stung so hard, and so often that their mantra has become open standards/interoperability. I believe that independent developers alignment with OSS is a visceral reaction to many years of being "manhandled" so to speak by IT vendors.

Along these lines is a special case of frustration and resentment, that of anti-Microsoft sentiment. Microsoft is depicted as a bloodthirsty corporate behemoth, a giant to be wary of and hopefully to be slain. Microsoft's business strategies and profit-seeking are contrary to what hackers consider the discipline of software engineering. In addition, there is personal enmity which transcends even anti-Microsoft sentiment, that is anti-Bill Gates sentiment. He is considered a hacker pariah who betrayed the discipline of hacking and turned it into a business. In effect, Bill Gates sold out hackers everywhere.

Hacker culture is not mutually exclusive of the traits which mark other cultures. It shares characteristics with other cultures as well. For example, hacking can be viewed as a subset of inventor culture. As such it inherits some traits from the parent culture. One of the aspects shared with inventor culture manifests itself as a motivation, simply put, that says necessity is the mother of invention. If the software you need is either not out there or too expensive, there is a motivation to create. Raymond states this a little differently but the message is the same. He likes to say, "Every good work of software starts by scratching a developer's personal itch." In my opinion, this motivation far outstrips financial motivation to develop OSS as far as independent developers are concerned. A sort of corollary to the necessity motivation is that the lack of financial resources to purchase everything they would want for their computing environment motivates contribution to an OSS development effort.


Is the OSS Model Sustainable as a Long-Term Business Model?

Ah, there's the rub, the question on a lot of people's minds. I tend to agree with Raymond's argument that it is long-term sustainable. It will not replace commercially developed software. There will always be a market for that, especially in small niches which require specialized application functionality. OSS is a force to be reckoned with in those broader markets where the application is widely used. Interestingly, two of those broader markets are currently dominated by Microsoft, ie. network and stand-alone desktop operating systems, and office productivity suites (MS Office). What OSS can do is open up the market, so to speak, for those types of software (operating systems and applications) which fulfill the unique characteristics and adhere to the rules of thumb outlined by Raymond in The Cathedral and the Bazaar. I believe that those software domains where these special conditions apply are likely candidates for eventual future domination by OSS development.

Why do I say this? Because the concept of free or low cost software which surpasses, matches or even nearly equals commercial software functionality is extremely powerful. To see why let's take a look at some economics. Simple economics (the law of supply and demand and value theory specifically) teaches us that consumers attempt to maximize their utility function, ie. get the most bang for their buck. Given the above condition coupled with consumer knowledge of its availability, OSS would quickly chisel away at more established higher-priced markets and market shares as customers maximize their utility function by acquiring OSS software which is always cheaper and sometimes better than software distributed under the cathedral model. After initial penetration, the strong winner-take-all network effects of the IT industry, and of the software industry in particular, would quickly snowball OSS market penetration and carry it like a 300-foot tsunami overwhelming the defenseless shores of established commercial software developers. By network effects I mean that the value of a software package to an individual increases with the number of other users the package has. For example, the value an office productivity suite has for me depends in large part on how widely used it is by others because I typically want to be able to share electronic copies of documents with other users. Therefore, the more people who have a particular office suite, the more value that office suite holds for me. This holds for operating systems as well and probably moreso because operating systems are pervasive infrastructure for all application layers which reside on top of them.

So, it has been established that OSS has a viable product. But how will this viable product be taken to market. Linux resellers are learning a lesson that many who have gone before them have learned and applied very successfully. One of the key points surrounding the whole question of the long-term viability of an OSS business model is post-adoption support. Support is what will make OSS commercially viable. Heretofore, there has been reluctance on the part of many corporations to jump on the OSS bandwagon for fear of getting stuck utilizing unsupported software packages. What has begun to happen is that small companies which furnish post-sales support (such as technical support or custom application development) are starting to spring up such as RedHat which sells and supports Linux. They sell the software licenses for a nominal fee (much lower than what it costs organizations to buy Windows NT licenses or even commercial Unix licenses). At some point, their revenue stream will be composed mostly of software support.

This business strategy in which the company sacrifices profits on initial equipment/product sales in order to latch on to long-term service contracts has been applied in countless industries. For example, in cellular telephony, the phones are subsidized (sold well below production costs) in order to provide cellular telephone service. Another example is the elevator/escalator iundustry. This industry gets about a third of its revenues from sales of new equipment, whereas about two thirds comes from the fixed-term maintenance service contracts their customers purchase for many years after the initial sale. Some other examples are photocopiers/computer printers and toner cartridges / maintenance, razors and blades, zip drives and zip disks, etc. Initial equipment/product sales represent only a fraction of the lifetime revenues a customer will furnish. What a company really wants to tap into is a steady revenue stream which will support continued long-term prosperity. Therefore, upfront sacrifice on the equipment sale assures long-term success.

Companies do not want to participate in commodity markets as prices in these markets are usually driven by small markups on production costs. This is commonly referred to as a buyer's market. Companies are always looking for ways to differentiate themselves from the competition in order to form a seller's market. However, physical products themselves often have a tendency to be commoditized leading to buyer's markets. In a commoditized buyer's market, where a company can distinguish itself from its competitors is in the quality of service they provide. In fact, many companies simply leave the commodity market to manufacturers seeking the greener pastures of service markets. Higher quality service businesses can charge premium service fees. OSS is an outstanding candidate to apply this tried and true business model.

But OSS does not just have network effects and a tried and true business model going for it. It has open standards going for it as well. OSS development efforts invariably employ open standards because of their widespread availability and interoperability, among other reasons. Since OSS hackers are not in it for immediate financial reward, there is little incentive to develop closed proprietary technology. Because of the advantages of speed of development and interoperability, it makes much more sense for OSS hackers to take existing open standards and apply them to the development of OSS.

Additionally, OSS enjoys the benefits of the religious fervor of people who adhere to open standards strategies. Some may point to Apple and conclude that religious fervor is not particularly important to have in your corner. But I say that this fervor promises to do OSS more good than it has done for Apple. The main reason for Apple's fall from grace was precisely its closed proprietary technology and its unwillingness to license the technology to third party manufacturers, licensing concerns which in the case of OSS development have been smartly overcome by the openness of the GPL.

What of Netscape's recent acquisition by America Online, you say? This acquisition was widely viewed as Netscape's failure to compete with Microsoft in the browser and network computing markets even after pursuing an OSS strategy by releasing its browser source code in January 1998. Some may even go so far as to say, therefore, that optimism regarding OSS' long-term sustainability should be tempered in view of Netscape's failure. But I believe that Netscape's plight is probably not very telling because it is probably a case of too little, too late. There was not enough time for OSS inertia to build up and really start generating the kind of code improvements that a product like Linux has enjoyed over the course of a few years. With such late reactions, it's no wonder Netscape's market results were less than stellar.

Furthermore, Netscape did not employ an OSS development strategy from the ground up, so to speak. From its inception, Netscape pursued a traditional software development and commercialization strategy. When Microsoft started giving their competing Internet Explorer browser away, simple economics and network effects took over, as noted above, and started eating away at Netscape's dominant 80% browser market share. In an attempt to stop the hemorrhaging, Netscape's two most concrete responses were giving away their Navigator browser for free to match Microsoft's price and finally releasing the source code. I think it is pretty safe to say that these were drastic measures conceived in panic and did not provide a very good cultivating environment for Netscape's OSS strategy to succeed.



OSS has demonstrated that it is a force to be reckoned with. After years of getting burned by IT vendor and platform lock-in, customers are very wary of putting themselves in this position again. There is a generalized pre-disposition toward using technology which employs open computing standards ensuring interoperability. This pre-disposition is often framed as "religious" fervor. OSS addresses these customer desires very well whereas proprietary technology with protected source code does not. OSS enjoys the efficient communications possibilities afforded it by the Internet which reduces the administrative inefficiency historically associated with adding developers on to a software project. Because of the nature of OSS development projects, many heads can be combined into an efficient software functionality-extending, debugging machine. The mindshare resulting from the pooling of talents into a collective IQ proves formidable. Furthermore, OSS seems a perfect fit with a tried and true business model in which initial sales are leveraged to assure long-term service. As Raymond notes,

"I think the future of open-source software will increasingly belong to people who know how to play (the OSS) game, people who leave behind the cathedral and embrace the bazaar. This is not to say that individual vision and brilliance will no longer matter; rather, I think that the cutting edge of open-source software will belong to people who start from individual vision and brilliance, then amplify it through the effective construction of voluntary communities of interest. And perhaps not only the future of open-source software. No closed-source developer can match the pool of talent the Linux community can bring to bear on a problem. Very few could afford even to hire the (large communities of developers who work on OSS projects). Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding'' is morally wrong, but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem."

An OSS strategy seems to match broad-based software packages such as operating systems and office productivity suites particularly well, although it is also manifest in other niches such as web programming applications (eg. Perl), and IP address-domain name translation (Bind). I think that the real test for OSS strategies will be in the most conspicuous broad-based markets. Linux is at the forefront of these efforts. It will be most interesting to see if it is able to take on the world and fulfill its great promise. I look forward to the day when some of these predictions, considered lofty by most, start coming true.



Abate, Tom, The Brains Behind Freeware to Meet, The San Francisco Chronicle, Business Section, April 2, 1998

Abate, Tom, FREEWARE PIONEERS: Innovators Advocate Free Software, The San Francisco Chronicle, Business Section, April 9, 1998

Abate, Tom, FREEWARE PIONEERS: Torvalds' Linux Broadened PC Choices, The San Francisco Chronicle, Business Section, April 9, 1998

Beckett, Jamie, FREEWARE PIONEERS: Perl Created With Missionary Zeal, The San Francisco Chronicle, Business Section, April 9, 1998

Beckett, Jamie, FREEWARE PIONEERS: Vixie's Bind Made Names for Web, The San Francisco Chronicle, Business Section, April 9, 1998

Beckett, Jamie, FREEWARE PIONEERS: Paquin Promotes Netscape Freeware, The San Francisco Chronicle, Business Section, April 9, 1998

Dougherty, Dale, taken from a presentation made by its author at UC Berkeley's School of Information Management and Systems Symposium series on September 9, 1998.

Einstein, David, The Penguin that Roared: Little Linux freeware gaining ground against giant Microsoft, The San Francisco Chronicle, Business Section, September 8, 1998

Einstein, David, Turning Freeware Into a Moneymaker, Emeryville startup looks to profit off of e-mail program, The San Francisco Chronicle, Business Section, March 14, 1998

General Public License, Free Software Foundation, GNU Project

Raymond, Eric, Open Source: The Future is Here, last updated November 22, 1998

Raymond, Eric, Open Source Software: A (New?) Development Methodology (Halloween I, version 1.9), November 2, 1998, annotated version of an internal Microsoft Corporation memorandum dated August 11, 1998.

Raymond, Eric, Linux OS Competitive Analysis: The Next Java VM? (Halloween II, version 1.2), November 3, 1998, annotated version of an internal Microsoft Corporation memorandum dated August 11, 1998.

Raymond, Eric, Microsoft's Reaction on the 'Halloween Memorandum' (Halloween III, version 1.1), November 2, 1998, annotated version of an internal Microsoft Corporation memorandum dated August 11, 1998

Raymond, Eric, The Cathedral and the Bazaar, last updated November 22, 1998

Raymond, Eric, Homesteading the Noosphere, last updated November 22, 1998

Information Rules: A Strategic Guide to the Network Economy, Carl Shapiro and Hal Varian, University of California, Berkeley, February 23, 1998