Open Source Motivations Final Paper

Introduction

Discussions of open-source methodologies and projects can be characterized as the meeting of extremes. One extreme speaks fanatically of open-source projects as revolutionary - operating under an entirely new and different set of political, social, and economic rules. The pessimistic extreme posits open-source software as a fad and a model that is ultimately economically unsustainable. To policymakers and others interested in issues of open-source development, these strong characterizations confuse the discourse and increase the difficulty of constructing meaningful policies.

This policy brief is not an attempt to provide the final answer on the truthful characterization of open-source software. Instead, we will provide policymakers with tools to for improved consideration of open-source issues by discussing the role of motivation and rewards in the life cycle of open-source software products. We explore economic, social, intellectual, governmental motivations. What prompts developers to contribute to open-source projects on their own time and without compensation? Is this even the dominant programming model? Do the benefits of open-source software differ from closed-source, proprietary software? Why do consumers demand open-source technology rather than similar closed-source products? Why are national and regional governments increasingly evaluating and deploying open-source software? What are the incentives of implementing open-source technologies? Why are for-profit corporations deploying open-source software and adopting business models based in open-source methodologies? What are the new business models emerging in nascent open-source software markets?

Section One surveys motivations of software developers to contribute to open-source projects. Section Two explores consumer motivations for adopting open-source software. Section Three discusses private sector incentives to implement open-source software and business models. Section Four covers public sector motivations for open-source software adoption.

Section One: Developer Motivations

What motivates individuals to contribute to open source software projects on their own time and without pay? Johnathan Cook, a Computer Science professor at the University of New Mexico, considers open source developers to be “Knights of the Round Table”, benevolent and authoritarian bands of developers working for the common good. Motivated by dueling senses of philanthropy and self-interest, developers improve the systems that they themselves use, reaping recognition, acceptance and praise from the key developers in the project.[1] Cook remembers Arthur’s knights as volunteers for the common good, selflessly practicing feats of bravery and rewarded with benevolent public sentiment.

Cook paints a rosy portrait of open source developers. His metaphor is an apt opener because he captures the traditional incentives for developers to freely participate in uncompensated, open source software projects. Computing literature cites a perceived increase in reputation, praise from more experienced developers and Eric Raymond’s famous “scratching a personal itch” as motivators for open source contributions. But the motivations of open source developers are far more complex. We started in Camelot and we visit psychology, economics and learning theory as we discover the motivations of software developers to contribute to open-source software projects.

The Social Explanation

Benevolence. Altruism. Community Improvement. These sociological terms aren’t often discussed in reference to software development motivations. Eric Raymond discusses “gift culture” and the “craftsmanship model” when explaining why software developers freely give to open source projects. He evokes pride of ownership and creation, and the desire for public evaluation as motivators.

If you accept that open source projects are social movements, then social psychology describes collective motives as reasons why participants engage in development projects. The more a developer values the goals of the open source project and envisions its goals as attainable, the more likely she is to participate in the project. Hertel et al. surveyed a community of Linux kernel developers and interpreted the results as a “social movement with political interests” as a method of determining the motivations of participants. The kernel developers mounted a collective effort to solve a common problem. Other common motives, such as the expected reaction of friends, family and professional community, motivate participants in social movements and open-source software development.[6]

The Intellectual Explanation

Geek culture is rich with intellectual motivations. Numerous open- and closed-source software products began as hobby projects. The intellectual motive for open-source software development is the motivating challenge of solving a difficult problem and submitting the solution to immediate peer review.[8] Some software developers are simply motivated by the desire to solve a hard problem.

Learning theory offers a similar explanation for intellectual motives. The idea of Legitimate Peripheral Participation is that “learning is situated in social situations, and learning takes place when members of a community of practice intersect with each other” in daily work.[11]

Applied to open-source development, we see scenarios where software developers join an open-source project initially for other reasons, say to solve a software problem that personally affects the developer. The developer stays affiliated with the project because she enjoys the community of practice. As long as she continues to learn from and interact with more experienced project developers, she keeps contributing to the project. Open source contributors also improve programming skills, both an intellectual and selfish motivation.

The Selfish Explanation

But are social and intellectual motivations enough to explain participation in open source projects? Hann et al. remarks that “it is not clear why such noble behavior would be limited to the field of software development”.[5] For further explanation, we look to more hedonistic motives. Participation in open source projects can also be explained in selfish terms. Open source developers contribute because it helps increase their own professional standing.

Through participation in volunteer projects, open-source developers gather professional credentials and improve programming skills. Developers can be motivated by improved professional reputation and the status of public association with an open source project. Enhanced professional reputation can be conveyed by acceptance of a contributor’s work into the project codebase [1], public peer-review of developers’ software contributions and even credits in the source code (in geek jargon – a “greputation”).[2] Economic research shows that publicly crediting developers is essential in the open source movement.[7]

Modeling open source projects as epistemic communities can also explain the motivations of enhanced reputation. An epistemic community is an interdisciplinary collection of people who share principled beliefs and values, shared feelings of validity and truth and a “common policy enterprise” – a set of common practices and competencies. The participants’ shared causal values make them good candidates for problem-solving.[3] One familiar epistemic community in our society is a collaborative group of research scientists.

Participants in epistemic communities are highly motivated by influence and reputation.[3] Actors in such communities can become politically motivated because of the reputation gain at stake. In the open source realm, communities of software developers are organize hierarchically. A small number of elite developers manage the contributions of many less-involved programmers. Submitting contributions for inclusion in the project can become a heated, political event. One can see how a group of volunteers on a technical project might organize as an epistemic community, highly motivated and subject to reputation and ego concerns.

Open source developers often contribute software to projects for which they were originally avid users. The developer discovers a bug or a missing feature, and contributes the software to fix her own problem with the software. This is inherently a selfish motive but it can have altruistic side-effects, like broadening the user community for a software product.

The Economic Explanation

Simple economics says that a software developer will participate in an open source project if the benefits of participation outweigh the costs. What are the costs of participation? Primarily, the costs are time and effort.

One way to motivate a software developer is to reduce the costs of participation in open-source software projects. The economic costs of open-source participation may be reduced in several ways. The alumni effect reduces the cost of participation by having numerous samples of similar solutions available for developer perusal. All open-source software has freely available source code, so there is wide availability of previous work to reference. This source code may be freely used for learning purposes.[7] A software developer may also be motivated by the full initiative of independent participation. The developer takes full responsibility for design and development of the contributed source code. There is no supervisor interference, for example, as with the production of commercial software.[7]

The benefits are harder to understand. In some cases, the developer modified the open-source code for personal use. He decides to submit the modification to the project to avoid the cost of merging the private patch with every new version of the software. Developers in open source projects benefit by signaling proven programming productivity and marketable skills to employers.[5] Because most developers contribute to projects during their non-working hours, open source participation displays the ability to program beyond a normal professional schedule.

Some economists believe that open-source participation is a way for a developer to signal productivity or human capital to potential employers. Participation in open-source projects shows an investment in training, skills enhancement, self-reliance and productivity. These topics might be difficult for a programmer to convey directly to an employer.[5] Participation in open-source can also demonstrate that the developer actually enjoys software development. These participation benefits can be generally called the career-concern incentive.[7]

An economic term for the behavior of volunteer developers in open source projects is free revealing. Free revealing is the revealing of innovations without expectations of protection or compensation. Traditionally, economists worry about free revealing because it violates the central theory of innovation - innovations require inventors to keep innovations protected in some way, usually by patents or copyrights.[9] In open source projects, contributing developers freely reveal source code to the community!

Free revealing makes no sense in the commercial software markets, where black-box innovations are the norm. In the open-source market, the benefits of free revealing unexpectedly outweigh the costs! Free revealing occurs when some non-compensatory benefit can be attained. For open source developers, the benefits of free revealing are all the benefits of open source participation. Free revealing also leads to better open source software and an increase in the market for related products. The costs of free revealing to an open source developer is very low, usually simply posting improved source code to a website.[10]

Summary of Developer Motivations

We have seen that software developers have social, economic, personal and professional motivations for contributions to open source projects. Developers contribute freely when it conveys some benefit to themselves, the software products they frequently use, and the software communities in which they desire to participate.

Section Two: Consumer Motivations

We now shift to consumer motivations for using open-source software as an alternative to closed-source software. We use a wide definition of consumer to encompass public and private organizations and individuals. What causes consumers to adopt open-source software even though closed-source software is more widely advertised and accepted? Four major reasons typically arise for consumer motivations: cost, flexibility, ideology, and reliability.

The Cost Motivation

When the topic of open source software is brought up, many people assume (falsely) that open-source software is free. Open-source software, while freely obtainable, is not free to maintain. Implementation and maintenance costs of hardware and personnel expertise still apply. Costs for support and maintenance must be considered when deciding between open-source and closed-source solutions.

Typically, the costs associated with open-source software are far less than the cost of using closed-source software [36]. It is for this reason that many consumers -- individuals or firms -- choose to use open source solutions. For example, in 2000, Conoco decided to use Linux as an operating system for a supercomputer that analyzes seismic data that they accumulated while looking for oil and gas [12]. Conoco determined that they would save a lot of money by going with a Linux-based system over a closed-source software solution. Dr. Alan Huffman, manager of the company’s Seismic Imaging Technology Center, claimed that the Linux-based system costs one-tenth as much as they otherwise might have spent.

Boscov, a department store company, is another business which is choosing to go with Linux. Boscov has decided to gradually migrate from Windows and DOS platforms to Linux systems so that it doesn’t cause a major interruption, but eventually would like to be using Linux on most of its systems [13]. The chain decided that it could more efficiently use its servers and IT staff by using Linux on their machines instead of closed source alternatives. In addition, Boscov has already saved about $5,000 by not having to license the software they use to communicate with Visa and Discover.

Harris Interactive Inc. is another example of a firm opting for an open-source solution, deciding to use Linux as opposed to Unix for data-tabulation applications. According to their CIO Peter Milla, “It was a real no-brainer for us,” he says. “It's a $20,000 investment in a tier-one [Compaq] box, which allowed us to increase our throughput and avoid a $100,000 investment in an H-P Unix box. Like most companies, we have a lot of Intel-based expertise on staff, and this lets us leverage that.” [14]

These are only a few of the numerous companies that have found that they could save money on IT costs and product licensing if they went with open source software instead of going with closed source software. The greatest cost savings are in licensing and the ability to leverage IT solutions from outside sources [35]. Because the trade-off costs of support for the open source software are not necessarily any higher than the costs of the same support with purchased software, the overall costs are usually far less when open source software can be used as an alternative to licensed software.

The Flexibility Motivation

While it is important for software to be low-cost, it is also important that it be flexible enough to meet whatever needs consumers have. Some companies require more specialized software than can be found on the traditional closed-source market due to customized hardware or unique business practices. For example, Conoco manager Dr. Alan Huffman, whose project is mentioned above, said that “We jumped on Linux because it had the flexibility to customize to our needs.” [12] Conoco needed to rework its software to work with special hardware that they created. This made Linux an attractive solution because the open source allows for companies to rework the software for their own needs. Another example is when Travelocity chose to move its website to a Linux/Java platform in large part due to CTO Barry Vandevier [15]. Barry is passionate about open source solutions and especially likes that they provide flexibility which can decrease time to market due to a collaborative creation process and an ability to speak with other people who have had experience with the software to see what solutions they have used for similar problems.

Not only is there flexibility in how you re-engineer software that has been created, there is also flexibility in what company you choose to acquire software from. Because the source code is open, many companies may be providing essentially the same product. However, the product may be slightly reconfigured or come with a different support package that more closely fits a consumers' needs. In addition, it is usually not hard to switch between software versions if a consumers' needs are not. This will not be the case with closed-source software, which will almost always be provided by only one company.

The nature of open source also makes modifications and customization of the software easier. It is far easier for companies to modify software to meet their own needs when they have access to the source code. Many companies require software that is too specific to find on the closed-source market, so the flexibility of open source mixed with a small number of capable programmers appears to be a better alternative than creating the necessary software from scratch with a much larger number of developers.

The Ideological Motivation

Some people and businesses absolutely hate the idea of purchasing software, thinking that software is something that should be free to the world and thus choose to use open-source software instead. This mindset can clearly be seen in movies such as Antitrust[16], a “not-about-Microsoft” movie about Microsoft’s monopoly practices, in which the main character’s friends throw out quotes like “Human knowledge belongs to the world”. Many people who fit into this category may just have a grudge with Microsoft.

One such company may be the guitar string manufacturer Ernie Ball, whose CEO claims to have left Microsoft behind for Linux because it is unhappy with Microsoft’s licensing policies [17]. Ernie Ball was turned into and convicted by the Business Software Alliance in the year 2000 for not being able to prove that it had licenses for many of its software products.

In a petition written at Ohio State University in March of 2002, members of the Ohio State University Open Source Club were upset about a proprietary Linux tool being included in documentation in an official Linux release [18]. In the petition they state: “We, the undersigned members and officers of the Open Source Club at the Ohio State University, are unhappy with the advocacy of the proprietary BitKeeper software for use in maintaining the Linux kernel. The Linux kernel is an important symbol of Open Source and Free Software for many people, and a project in which many thousands have participated in active development. It is fine if some kernel developers choose to use BitKeeper on their own machines, but officially endorsing proprietary software as the means of working on the kernel is a large step backwards for Linux, and for the Open Source and Free Software communities.” [18]

It is worth noting, however, that Linus Torvalds has been quoted as saying “Quite frankly, I don't want people using Linux for ideological reasons. I think ideology sucks. This world would be a much better place if people had less ideology, and a whole lot more ‘I do this because it's FUN and because others might find it useful, not because I got religion’”. [19]

Nonetheless, there are many people who prefer open source for no other reason than that they do not feel that the closed-source model is a good one. Many people are concerned that source code is being used and kept secret for profit instead of being given out freely to better the world, believing that software belongs to the world and not to the companies responsible for its creation.

The Reliability Motivation

Another reason consumers choose open source software is increased reliability. The main reason that open source software is thought to have this characteristic is that the source code is usually read, understood, edited, and peer reviewed by a much larger audience than the closed source competition. In “Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services,” the authors found that utilities that they tested on commercial versions of UNIX had failure rates of 15-43% [20]. Meanwhile, Linux had a lower 9% failure rate and GNU utilities had only a 6% failure rate.

Another study done by ZDNet pitted Caldera Systems OpenLinux, Red Hat Linux, and Windows NT Server 4.0 against each other by setting up network servers on equivalent hardware [21]. After 10 months, equivalent network requests to all three servers revealed interesting results: the machine configured with Windows NT crashed an average of once every six months; neither Linux configured server went down a single time in the entire 10 months!

A 1999-2000 study compared the open source Apache web server software with Microsoft’s closed source Internet Information Services web-server software by trying to access 100 of the most popular Swiss websites from 4 different locations every 5 minutes for 3 months [22]. The study found that websites that used Microsoft’s web-server software had twice as much downtime as the websites that used Apache.

More programmers view open-source code than closed-source code, and, therefore, open-source software has a much better chance of having its bugs and holes discovered and solutions designed for the next release. Numerous studies have been able to validate this result and prove that open source software tends to be more reliable and have less downtime than its closed source substitutes. [20, 21, 22]

The Trust Motivation

Users sometimes choose open-source software instead of closed-source freeware or commercial systems because they trust open-source software to be "on their side". (See "Section One: Software Developer Motivations" for more information about social motivations.) If an open-source developer does something that users hate, it is likely that another developer will fork the code, and users will switch to the forked version. As a result, open-source developers rarely make choices that result in revenue for the author at the expense of annoyance for users. Eric Raymond has called the ability to fork "the essence of the bazaar", or open-source model of software development [27].

Some common annoyances with freeware are in-program advertising, bundled malware, and increases in price. Because of forking, these annoyances are almost always absent in open-source software.

In-program advertising

Freeware authors often derive revenue from in-program advertising. In some freeware, the advertising gets increasingly annoying with new versions of the software. For example, AOL Instant Messenger's advertising box once only contained animated images, but now sometimes includes Flash video advertisements with sound and ads that create pop-up Internet Explorer windows if you so much as move the mouse over them for a tenth of a second. Open-source software rarely contains any advertising.

Bundled malware

Malware includes spyware, which sends private information about the user to a server, and adware, which displays advertisements in a way that tries to hide the source of the advertisement. Malware is often difficult to uninstall, even after the user determines which program it came with. Freeware authors bundle malware because they derive revenue from the sneaky advertisements and gathered data.

One famous example of freeware that bundled malware is Kazaa, a popular file-sharing program [30]. But the bundled-malware problem is not limited to programs of questionable legality such as file-sharing programs: recent versions of AOL Instant Messenger have included Wildtangent and Weatherbug, both widely regarded to be spyware [28].

Many users are afraid of unknowingly installing malware, and some users turn to open-source software in order to avoid it.

Increases in price

Users of freeware cannot be certain that future versions of the software will remain free. Blogging software Movable Type was free for personal use for years, but with the release of version 3.0 in May 2004, its free personal use license became restricted. Users affected by the restrictions would have to pay the developers a lot of money or continue using Movable Type 2.6, which was suffering from severe comment spam problems at the time. Users who could not upgrade to version 3.0 for free felt deceived. Users who switched to other blogging software as a result of the Movable Type licensing change often chose to switch to Wordpress, in part because Wordpress is open-source and thus could never surprise them with similar license changes [29].

Section Three: Private Sector Motivations

Why are firms supplying or contributing to open-source projects or even basing business models on open-source software? This section focuses on the supply-side reasons for and against firms’ motivations to turn to open source software. (The demand-side explanations for corporate consumption of open-source software is discussed in Section Two.) In the first part, we analyze common arguments against private-sector adoption of open-source software. In the second part, we discuss reasons for corporate adoption of open-source software. In the third part, we focus on some emerging business models employing open-source software.

Motivations for Avoiding Open-Source Software

Software literature suggests there are three main arguments against open-source software. First, it is more difficult and requires more effort and creativity to make money from open-source software since its sale value as a commodity is zero [A]. Businesses who do employ open-source software as a fundamental aspect of their business model must believe that some other aspect or process exclusive of its sale value will be more profitable than what would have been gained by the sale value of equivalent closed-source software. Indeed, we discuss later various business models including some that are contrary to this claim, in which firms in part base their business model on the sale value of open-source software.

Eric Raymond debunks the claim that it is more difficult and requires more effort and creativity to make money from open-source software. He argues that this claim is rooted in the “manufacturing delusion” [B] as opposed to viewing the software industry as a service industry. The argument goes that most people apply the “factory model” when understanding software. Two key premises of the “factory model” are the sale value of a commodity pays for the developers’ time and the actual sale value is calculated in relation to the development costs and use value.

According to Eric Raymond, both of these characteristics when applied to software do not hold up [C]. He argues that a majority of a developer’s time goes into upgrading, maintaining, and debugging software as opposed to its creation. Thus, when a firm no longer provides customer and maintenance support, the maximum price consumers are willing to pay for it drops near zero regardless of the development costs and use value. “The effect of making software ‘free’, it seems, is to force us into that service-fee—dominated world — and to expose what a relatively weak prop the sale value of the secret bits in closed-source software was all along.” [D]

Another reason firms do not turn to open-source software is the belief that it aids competition. Typically, this claim asserts that competitors gain advantage by accruing the net benefits without paying the development costs for the initial development of the software done by the firm that decides to open up their source code [E]. Thus, if one’s now opened-up software becomes popular, the belief is that one’s competitors can now use it and attain the benefits without paying the development costs one initially puts into a software [F]. A conceptual problem with this scenario is that it is often framed as a trade-off between the increased advantage of having a plethora of developers improving software and the sunk costs from initially developing the software. The development costs had to be done even if the firm did not open up their source code, and, thus, the development costs should not count as a cost attributed to open sourc. Eric Raymond puts it, “The real question is whether your gain from spreading the development load exceeds your loss due to increased competition from the free rider” [G]. Thus, open source may be more favorable in different contexts.

Finally, some proponents of closed-source software argue that relying on open-source software is more tenuous, risky, and uncertain. In this perspective, open-source software is framed as a relatively new phenomenon and its long-term sustainability is highly questionably. Open source is seen as a passing fad. Thus, relying on open-source software, the argument goes, is tenuous, risky, and uncertain since the pool of contributors may evaporate. Furthermore, there is no guarantee that the pool of contributing developers will continue to be large enough to provide the gains advanced by supporters of open-source software [H]. Some evidence shows that open source may not be as widespread as believed, be more concentrated in certain regions, and dependent on the wage rate of certain programming classes within a region [I]. Ironically, supporters of open-source software support similar arguments against closed-source software. We discuss this in depth in the following section.

Motivations for Supporting Open-Source Software

In contrast with proponents of proprietary software, supporters of open-source software believe open source offers “better quality, higher reliability, lower costs, and increased choice” [J]. Firms supply open-source software because they believe they are at a market advantage by providing services or products supporting the open-source software.

The least-controversial claim is that open source software reduces costs. The belief is that by taking advantage of an “unlimited” pool of free developers, a firm shares the cost by spreading the development costs instead of simply relying on in-house developers.

Another reason for companies to make their software open-source is that it can simplify the recruiting process. For example, Netscape, which based versions 6 and higher of its browser on the open-source Mozilla browser, was able to hire many Mozilla volunteers [58], knowing that they were strong hackers who were interested in making Mozilla successful. Furthermore, these new employees were already familiar with the code and much of Netscape's development process, so they could become productive employees quickly.

Another motivation to adopt open-source software is that it is more reliable. One variant of this argument states that firms engaging in open-source software methodologies take advantage of increased risk-spreading. Unlike the closed-source scenario, in which firms and individuals must rely on vendors to continually provide support and maintenance, firms deploying open-source software have a “fail-safe” community of developers available. As Steve Weber puts it, “the ability of the open-source software process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing” [K]. The other variant of the argument that open-source software is more reliable is the belief that the software is less “buggy.” The process of peer review, in this view, is seen as a highly effective mechanism in testing an application.

Is open-source software qualitatively better than the closed-source alternative? This is a more difficult question to answer and proving the veracity of open-source supporters’ claims will likely rely on subjective evidence at this point. In some ways, the reasons given in support of open-source software as more reliable suggests it has better quality. However, some empirical evidence suggests the contrary. In one study, Microsoft Windows was shown to be better able to respond to various attacks than the other open-source operating systems [L]. Thus, the final and absolute answer to the question of open-source software quality remains unclear.

Similarly, the argument that open source provides increased choices is also controversial. Many open-source supporters want to counter the tipping tendencies of network goods and markets, and thus, leading to monopolies. Microsoft’s Windows is the prime example here. Thus, although technological innovation can quickly unseat a monopolist’s advantage, in the closed-source world, there is less competition and, hence, fewer choices. However, in an open-source world, it is not clear whether increased choices simply follows. Arguably, early on there will be increased choice to firms and individuals as well as increased competition between firms when there is a mixture of open-source and closed-source software. However, if further down the road the world appears to be dominated by open-source, it is unclear to me whether increased choice and competition follows.

Since the value of a network good to another person increases as more people use it, firms want to capitalize on this. This might be the main reason firms are willing to turn to open-source and, indeed, make open source critical to their business model. As Steve Weber eloquently puts it: "The point is that open source software is not simply a non-rival good in the sense that it can tolerate free riding without reducing the stock of the good for contributors. It is actually in the sense that the system as a whole positively benefits from free riders [M]."

In the following section, I provide examples of the various ways firms are deploying open-source software as components of business models.

Open-Source Software Business Models

Business models are emerging in response to the open-source movement. Some of the basic examples of business models and the companies employing them are the following [N]:

• Branded distributions (Red Hat Linux): This model builds upon the notion that similar to the bottling water market, consumers are willing to pay for a product when packaged because they trust it more.
• Sell hardware, give away software (IBM, Intel, HP, Dell): This model builds on the attractiveness of and demand for hardware by giving away software complementing hardware for free.
• Sell services and support (IBM, Red Hat, Novell): This model is perhaps the most obvious way for companies to make money since like closed-source software, open-source software does not preclude the need for technical support and customization services.
• Dual versions (sendmail)
• Dual licensing (mySQL)
• Value-added software
• Sell sponsorships (Open Source Development Lab)
• Sell ads and t-shirts (Sourceforge)

This list is not exhaustive, and over time, companies will surely come up with more innovative ways to make a profit from not only using but developing open-source software. The following paragraphs give more detail about several of these business models.

Some companies support open-source software to gain a strategic advantage, often in order to sell hardware, software, or support. These vendors "see [open-source] as a loss leader for profitable services." [33] An example is IBM, which invested $1 billion in Linux 2001, and then took more than $2 billion in Linux-related revenue in 2003 [31]. IBM's revenue comes from consulting and from selling hardware and software. Eighty percent of IBM's software revenue comes from middleware [32]. Middleware has highest demand when large companies want their software to run on multiple operating systems, so IBM gains a strategic advantage by helping Linux weaken Microsoft's monopoly on operating systems. IBM also sells hardware that runs Linux.

Another strategy is dual licensing. Under this business model, the company provides an open-source version of the software and simultaneously sells a proprietary version. For example, MySQL AB distributes its MySQL database under both the an open-source license and a commercial license. Because the open-source version uses the GPL as its license, closed-source software cannot incorporate MySQL. As a result, closed-source software developers who wish to incorporate MySQL must purchase a commercial license [57]. Another example is the QT cross-platform GUI toolkit, which is free for Linux but not for Windows. In order for a company to use a dual licensing model, it must ensure that open-source contributions do not restrict its ability to distribute proprietary versions. The company can retain rights to distribute proprietary versions in several ways. First, it can do all development in-house and release the code under GPL but not accept contributions of GPL code. Second, it can require that contributed GPL code be copyright-assigned to the company. Third, it can use an NPL-style license [56], which allows the original developer (but only the original developer) to distribute closed-source versions.

Section Four: Public Sector Motivations

Introduction

Recently, the open source movement has attracted a great deal of attention in the political arena, prompting several national governments to institute policies explicitly tilting the software economy to support open source. Previous sections have explored individual and corporate interests in the open source software movement, but we must now discuss who is perhaps the most important and powerful player with regards to open source: government.

Governmental entities are major purchasers of computer software by any measure. It is no wonder that the software industry has gone to great lengths to court this customer, especially as a successful contract usually involves very large sums of money. Governments obtain extraordinary treatment in terms of volume pricing, support contracts and, often, limited access to otherwise secret source code (such as Microsoft’s Shared Source license).

In recent years, however, there has been a trend for public sector entities to consider the alternative of software under open source licenses. This phenomenon can be observed at the federal, state and municipal levels in the United States, as well as in countries around the world. It is fair to say that no public sector entity with an IT policy has failed to examine the open source model. Some entities have relaxed restrictions against open source software, while others have affirmatively encouraged its use. Yet other governments have gone so far as to mandate open source licensing of any software purchased with public funds.

The motivations for public sector entities to encourage or require the use of open source software are as diverse as the governments who are making these choices, and in many cases are rooted in cultural and political attributes of a nation and its inhabitants. In this section, we will examine the motivations that have been demonstrated in published literature, as well as the response to these factors from the proprietary software industry, where it exists. Futher, we address many important questions with regard to government. What roles does government play in the open source model? What motivates government to support open source products and agendas through legislation and/or economic incentives?

The Roles of Government

Government, unlike all other entities, plays three roles in the software economy: consumer, producer, and regulator. The triple role played by government creates an interdependent, complicated array of potential motivations which we will discuss in this piece. As previous sections have discussed the motivations of consumers and developers, this section attempts to focus only on those areas where the motivations are fundamentally different or require clarification.

As a consumer, the government is not unlike a consumer of any other product – be it an extremely large consumer. In F2000, the US government alone spent an estimated $3.7 billion on prepackaged software.[23] State and local governments spent an additional $4.5 billion. Like business, governments have traditionally made software purchasing decisions based on some weighting of key factors, including technical merit and price.

On the production side, government is equally large. Through direct and indirect employment, government is typically among a nation’s largest employers. Though no estimate was found to quantify the total dollar value of research and development dollars devoted to software specifically, the end result of many research projects involves some kind of software development. Typically, governments have adopted a policy whereby the resultant works are distributed freely under some kind of GPL, though obviously software written for certain segments of government is never released for security reasons.

The regulator role of government is what makes government an interesting and complicated character. Government, especially national government, has the ability to award temporary monopolies in the form of intellectual property to corporations and individuals, presumptively rewarding and creating incentives for ingenuity and innovation. Given this power, government has some inclination to support the policies undertaken by its numerous offices.

Cost Factors

The simplest argument is that open source software typically is less expensive than proprietary software; in some cases it is seemingly “free”, as in obtainable for no charge (beyond the effort to acquire it, i.e. downloading over a network connection). Although there have been well- structured arguments that the cost benefit of open source software is illusory [37], the economy of governmental purchases is often quite different from that in effect for the business sector.

The cost of purchasing software can be decomposed into the following elements:

• Cost of acquisition

• Cost of adoption (which may include customization for a given use)

• Cost of training

• Cost of post-purchase technical support (bug fixes, technical advice on use)

• Cost of future upgrades (changes in underlying platform, protocols, etc.)

A brief examination of these factors demonstrates a broad range of thinking and belief.

Cost of Acquisition

Of these factors, the cost of acquisition is the most visible and easiest to understand. This is the metric by which the public will most often judge the advisability of a public sector purchase; said public wishes to see its money (obtained through taxation) spent wisely. Public officials often cite their thriftiness with public funds as an attribute, especially in countries with free elections.

The cost of acquisition of proprietary software is typically set to allow the seller to cover some portion of the expenses it incurred in creating the software. In the realm of open source software, there are several models; as has often been cited, “free” means “freedom”, not “free beer”.

While some open source software can be acquired for only the effort of downloading it over a network connection, this arguably incurs some expense and can be prohibitive for those lacking sufficient network bandwidth. While this is not a factor for the governmental agencies of developed nations, many emerging nations have only minimal network capacity (as discussed in [38], [39]).

It is also common to obtain open source software through physical distribution channels, such as compact discs or magnetic tape that are often a simple archive of online resources. Several companies have created a business model based in part on this convenience, including Red Hat, SuSe and other distributors of the Linux operating system . It is conceivable that a particular public sector entity might choose to download the software once and transfer it to physical media, but the low cost of commercial products of this type is likely to render this exercise uneconomical for any but the smallest distributions. Further, these commercial entities can be engaged under contract to create custom distributions, and the scope of governmental contracts would be suitable for this practice; again, however, the cost of acquisition is creeping upwards.

It is also common for computer systems to be shipped preconfigured with a set of software. In this case, the cost of acquisition is borne by the hardware vendor, and can quickly disappear in an accounting of volume sales.

Cost of Adoption

This refers to the cost of installing, configuring and (if necessary) customizing software for a particular use. The proprietary software industry has expended considerable effort in reducing this cost through installation and configuration utilities that detect the peculiarities of a given hardware platform and take appropriate decision branches in the initial setup coding. (Indeed, there is a separate market for installer software tools that perform this task for software authors.) The open source community has a hit-and-miss record in this regard: while operating systems have made great strides in auto-detection and automated configuration, many products still require extensive configuration and even customization (i.e. modifying existing code or writing new code). For instance, the widely used open source program sendmail (which transports the majority of electronic mail on the Internet) uses a cryptic script language for configuration; it has been said that editing its configuration file once makes you a serious systems administrator, while performing the task twice makes you insane. [40]

The importance of this cost varies with the customer. While a non-technical consumer does not want to engage in significant configuration, a governmental user may have a technical staff already in place that can execute on this set of tasks. Governmental buyers typically seek homogeneity in the user environment, which means little variety in hardware; a configuration script might be written once and run many times. Moreover, if the software is purchased with the hardware and is preinstalled, the volume purchased by a typical public sector entity will justify extra effort on the part of the vendor to pre-configure the machines to the customer’s wishes, that cost being absorbed into the agreed-upon price.

Cost of Training

Issues with training are similar to those of adoption, but will likely involve a larger user population. This cost will be dependent on the sophistication of the user population and the relationship between the quality of the user interface and the complexity of tasks to be performed with the software. For instance, if the software supports a small, fixed set of tasks such as order entry, the user may interact only with a user interface generated by the public sector purchaser (either directly or through contract with a software developer), and the details of the underlying operating system are completely irrelevant to the user. But in the case where more sophisticated tasks are performed by the user, such as a knowledge worker, it may be necessary to interact with only a thin layer of user interface between the user and the core software. In general, it may be stated that the less defined the use of computing systems, the greater the training cost. To date, the open source marketplace has not been as successful as the proprietary software industry in either user interface design or error detection and handling, and the user will need considerable training to be able to effectively use the computer in his or her daily tasks.

Training is sometimes included in volume purchases, but the proprietary software industry has historically had greater resources in this regard; that cost is another factor incorporated into the license cost. Public sector entities may have in place resources that can address this issue, but this is typically not the case. However, support can potentially be obtained from a competitive network of providers, rather than a single entity.

These issues have been discussed by open-source software adopters in US federal and state governments: one adopter stated that "Indiana's traditionally Windows-centric employees will need Linux training. State officials have not yet determined the training costs, he said." And, "GSA officials had high training fees to educate the IT staff about the open-source world." [41] Of course, in developing nations, there is less likely to be pre-existing knowledge, and training costs will be incurred with either closed-source or open-source products.

Cost of Post-Purchase Technical Support

Technical support is a major burden for proprietary software vendors, and sophisticated systems exist to attempt to control this cost. This task is composed of assistance with software defects (bugs) discovered after the software has been sold; assistance with customer usage that was not anticipated in the user interface or product literature (i.e. how do I…?); and customer questions based on ignorance and/or insufficient training.

For public sector customers, large proprietary vendors often maintain a distinct workforce to address customer needs. Smaller vendors may contract with another commercial entity that provides such service, or may be unable to compete in government contracts due to inability to meet expectations of technical support.

While the open source community argues that open source gives the user control over the situation – after all, they have the source code – it is not necessarily true that the user can make use of this information. Even the relatively sophisticated customer may be daunted by core operating system code, generally considered the most complex programs written. The provision of technical support is the primary flaw claimed by open source detractors and the key advantage claimed by commercial distributors of open source software. Indeed, it is arguable that this single benefit has enabled commercial distributors of open source software (e.g. Red Hat) to become publicly traded entities.

The open source community also argues that the community supports its users. This may be of questionable value if the user does not have sufficient technical expertise to make use of the help offered, or even to ask the right questions. Moreover, computer systems employed by public sector entities (particularly a military or financial sector user) may require confidentiality that would complicate a request for assistance. However, entities with a more open role have experienced benefit from the "open forum": for instance, NASA has found that the support of "the greater scientific community" is a substantial time- and cost-saver for an agency with significant resource limitations. [41]

Public sector entities may have in place technical staff that is capable of addressing the majority of technical issues that arise, but this is not universal, and is less likely outside urban areas. However, support can potentially be obtained from a competitive network of providers, rather than a single entity (that may only do business in another time zone).

The cost associated with post-purchase technical support is generally considered by both the proprietary software industry and the open source community to be the greatest portion of the end user’s total cost in IT.

Cost of Future Upgrades

The lesson of history is that it is often necessary to change or replace software to meet new needs, understand new protocols of data transfer or communication, or interact with new hardware that did not exist when the initial installation was performed. For instance, the original Web browsers that helped drive the popularity of the World Wide Web are barely usable on today’s Web, if at all; many times, modern Web sites are so dependent on modern protocols that they will detect and disallow older browsers.

While proprietary software vendors may occasionally offer upgrades for little or no cost, it is far more common that the upgrade cycle is a key source of revenue. The advertising of vendors - "Upgrade now!" - may fall on deaf ears, but the day that some new document format cannot be read or that a newer, faster peripheral will not operate with the existing software, the upgrade cycle takes another turn. Those who fail to upgrade may discover that support is either no longer available or only available at increased cost. For instance, Microsoft Corporation provides only paid support for its products after five years. [42] As another example, Sun Microsystems ends all support after five years. [43]

Open source software is not under the control of a for-profit entity, and therefore the "upgrade cycle" is not a revenue stream through license fees. There is an extensive discussion of upgrade costs and issues from a public sector perspective in a report published by the Danish Board of Technology. In part, the Board states "No equivalent pressure for upgrading comes from open-source software, as there is no opportunity for earnings closely linked to upgrades." [44]

However, upgrades will be driven by the same needs as those driving closed-source software, and it is important to consider two different costs that must be incurred. First, existing software must be either modified or replaced; the former may require considerable technical skill and the latter incurs similar costs as the original cost of adoption. Secondly, the user must determine whether the desired upgrade has dependencies on other software modifications, and the entire chain of changes must be applied in the correct sequence and validated against expected behavior (regression testing). Tools such as the Red Hat Package Manager (RPM) have been developed in the open source community to simplify this set of tasks.

Summary of Cost Issues

Cost elements are significant in all governmental purchasing decisions. In developed nations and particularly in urban areas, it is more likely but not given that governmental agencies will have access to trained technical staff that can address the issues that add to the cost of open source usage, and are therefore not dependent upon the support structures customarily provided by proprietary software vendors. In emerging nations, the lower cost of labor may lessen the impact of post-acquisition costs. Further, while training local talent to address post-purchase costs may necessitate additional investment, it is a one-time expenditure; the additional non-economic value of this investment is discussed below.

The attention paid here to cost is not intended to reflect its importance in the decision process of public sector entities, but rather its visibility and exposure in the discussion of software licensing alternatives.

Technical Quality

Reliability

Open source partisans claim that their software is more reliable. This is a difficult claim to objectively examine, as the term “reliability” means many things to many people.

For instance [45], Microsoft Windows is adjudged to be less “reliable” because under certain circumstances it will spontaneously reboot: the infamous “blue screen of death.” However, one of the primary reasons for this occurrence is the malfunction of a software module called a device driver. Responsible for the interaction of the operating system with a physical device (for instance, a network adapter), the device driver is typically written by the manufacturer of that device, not by Microsoft. Nonetheless, this software module is allowed within the most privileged layer of the operating system; this is an artifact of the design of the system.

When a device driver malfunctions – for instance, attempts to access memory locations outside its allocated area – the operating system responds by considering it a malicious module. Since there is no clear way for the operating system to know whether this trusted module may have caused damage within its trust zone, the system takes the safest course – if the most disturbing to the user – and reboots the system, to return to a well-known state.

The Linux operating system, faced with the same scenario (which is equally common in both systems, according to open source community statistics), continues to operate in most cases. Only in the most egregious cases, such as exhaustion of memory resources, will Linux terminate a malfunctioning driver. This appears to be more robust – the system has not failed – but it is not possible to know whether data has been lost or corrupted, or whether the system can continue to operate reliably.

One study offers ambiguous results based on reported bugs in open and closed source systems of similar usage [54]. The author of this study seems to "have faith" in open source process, but the results trend in favor of open source for one class of product, and in favor of closed source for another. It is clear that there is an effective defect resolution mechanism for open source products, but it is not conclusive that this mechanism is better or worse than that of closed source products.

Nonetheless, reliability is a claim by the open source community that, with little objective evidence, is one of the factors in its adoption in many discussions by governmental entities.

Security

There is a perception that open source software is somehow more secure than proprietary software. This perception must be considered from more than one perspective, and bears greatly on decision processes.

The most commonly considered aspect of security is restricting access to authorized entities. This includes both data security and resource security. The former is self-explanatory; the latter encompasses the realm of ‘vandalism’ attacks such as denial of service attacks, as well as preemption of computing capacity for purposes such as distributed denial of service attacks or computationally intensive attacks (such as computationally defeating encryption algorithms). Research has not demonstrated a significant benefit in this regard [45], and exploits against open source software continue to be discovered [46]. Nonetheless, the security claim is still cited as a motivation by many governmental agencies.

Part of the justification for this belief is an underlying premise that software that is “visible” to many people does not rely on “security by obscurity”. In other words, the belief is that proprietary software relies at least in part on the opacity of the compiled binary form to resist penetration or uninvited use of its resources. Broad use of open protocols makes this less relevant, but does not completely invalidate this premise or its influence. [49]

Another aspect of data security in particular is ensuring that the authorized entity can access its data. This has been discussed as a particularly important issue for governmental entities, who accumulate large quantities of data on behalf of the public. If that data is managed in a proprietary format, the owner of the format becomes a de facto owner of the data; upgrades, changes in product line (no longer supporting that data format) or dramatic changes such as cessation of business may place the data’s true owner in a difficult position. Maintaining data in openly documented formats ensures that the data can always be accessed by its owner, and eases the task of migration, should it become necessary. Use of open source software also allows the data’s owner to support the legacy format, if necessary, through modification of that software. Open source software is thus seen as a safer repository for public data entrusted to governmental agencies. [48, 49]

Interoperability

Related to the issue of data security through open formats is the concern of interoperability among dissimilar systems. This is an attempt to enable potential network externalities and enable a truly competitive marketplace. There is a perception that open source software is somehow superior in this regard, but this belief is not well founded in logic or experience. Open standards are particularly important with proprietary software, which is typically a “black box” to the end user. This is because the consumer wants to leverage network externalities to avoid a monopolistic price structure and minimize risk of obsolescence of single-source products.

Open source software offers an advantage where open standards do not exist: since both the data structures and associated procedures are visible to the consumer, a sufficiently skilled consumer can engineer interacting systems based on that knowledge. Of course, the liability is, once again, that unsophisticated users may be unable to take advantage of this transparency.

Resource Utilization

The question of resource utilization is simple in principle: how much hardware (in several dimensions) do I need to run this software? For application software, the issue is not as simple to define; resource utilization is a function of the purpose of the software, and varies widely. However, operating system software is the foundation on which applications are supported, and the resource requirements of the operating system typically dominate the decision-making process for desktop users. Therefore, it is a useful metric, and one often quoted by all software vendors.

In the particular case of the Microsoft Windows operating system versus the Linux operating system, there is a significant difference in the level of computing resources required to support the two products. (Note: Debian Linux was chosen for comparison rather than the more commonly known Red Hat Linux because its product information was in a similar format to Microsoft's data, making this comparison simpler.)

	Windows XP Home Edition	Debian 3.0 Linux
Processor	233 MHz Intel Pentium or equivalent minimum, 300 MHz recommended	Intel processor, 386 or later; numerous other processors, including Motorola 680x0, DEC Alpha, Sun SPARC, ARM, IBM PowerPC
System Memory	64MB minimum, 128MB recommended	12MB minimum
Persistent Storage (disk)	1.5GB minimum	400MB (for X Window GUI)
Video display	SuperVGA minimum	VGA
Sources	http://www.microsoft.com	http://www.debian.org

As a practical matter, open source operating systems such as Linux and OpenBSD can run effectively on less powerful, less expensive hardware than that required to support Microsoft Windows. The hardware that is thrown away every day by businesses employing Microsoft Windows [50] can serve as perfectly usable platforms for open source operating systems. One example of this is a project at Uganda Martyrs University in Africa, where a project was launched to create a Linux distribution for 386-class computers that will be suitable for primary and secondary schools [51]. Another project seeks to port Linux to Intel 8086 and 80286 processors , again to support deployment of legacy hardware in the emerging world; the Linux ELKS project also cites the goal of serving as a learning tool for operating system concepts. [52]

Balance of Trade

A map of the world that shows the borders between nations is called a “political” map. Indeed, differences in politics drive much of international relations, both between diplomats and between economies.

Historically, computing technology emerged in the United States, through a number of factors that are beyond the scope of this discussion. As a result of this fact, American companies largely own the core software industry, despite both academic and commercial talent worldwide.

Top 10 software companies, ranked by revenue and market capitalization [53]

</tr>

Company	Annual Revenue (millions of $)	Market capitalization (millions of $)
Microsoft	31,375	260,000
Oracle	9,487	63,400
SAP	7,700	32,300
Computer Associates	31,375	260,000
VERITAS	1,531	10,100
Electronic Arts	2,489	9,300
Intuit	1,373	9,000
Adobe Systems	1,194	8,000
Symantec	1,328	6,600
PeopleSoft	1,949	4,700
Competition to top 10	8,445	28,582
Total	69,954	444,400

Note that only one of these companies is based outside the United States. This fact is not unnoticed, nor universally admired.

Economic Factors

In 1998, the European Community began an investigation of the Microsoft Corporation for alleged anticompetitive behavior, which eventually led to formal legal action. One of the remedies sought by the EC is compulsory licensing of significant information regarding Microsoft software’s internal workings, including matters that may currently be considered trade secrets. The stated goal of this remedy is to allow competitors to interact better with Microsoft systems; the argument is that Microsoft deliberately engineers its server products and client products to work together better than competing products can work with either class of Microsoft products. European nations, individually and in concert, have likewise objected to other companies’ behavior, including Oracle’s proposed purchase of PeopleSoft.

A study in Australia [55] “does the math” and provides a dollar figure for the amount of cash money exported from Australia for foreign-made software, i.e. the IT trade deficit. The paper suggests that this considerable amount could serve to fund a healthy Australian IT industry, based on open source software, that would work to Australia’s economic strengths and obviate its weaknesses.

Even within the United States, political boundaries exist within the IT industry. There is clear competition between Microsoft, the companies of the so-called Silicon Valley region , and the Northeast, often called Route 128 (for a highway in Massachusetts that was at one time the home of several major players in IT products, such as Digital Equipment Corporation and Data General). These regionalisms are demonstrated by the alignments of antagonists in the Microsoft antitrust trial and other lawsuits.

Generally, open source software is seen as a way to keep local dollars and/or jobs (which translates into tax revenue) within the jurisdiction; in other words, if money is to be spent, spend it “at home.” This is recognition of the argument that cost of acquisition is a small part of the overall cost of software, in a manner that seeks to promote local economic activity over global. The Australian study cited supra refers to the latter as “paying rent.”

Non-Economic Factors

Another study suggests that the local employment created by open source is of a higher level or caliber. Use of products such as Microsoft Windows is seen as creating jobs requiring less skill in the subject matter; in a sense, this is a “backhanded” compliment to Microsoft, as their goal is to create software that is easier to administer. But it is also seen as creating an IT culture that becomes dependent upon that built-in ease of use, and never deepens its understanding of fundamental principles – and is thus barred from contributing to IT at a core level. Open source software, it is argued by the proponents of proprietary software, requires deeper understanding of the software in order to meet its users’ needs; rather than seeing a liability in this, many emerging nations see opportunity to develop a self-sustaining local IT industry.

Relating this to the argument of overall cost: while it may be necessary to provide training to achieve this level of expertise locally, that talent, once trained, can be retained locally with little effort. The cost of this training can be seen as a one time investment.

Social and Cultural Affinities

Localization

Commercial software developers often develop versions of their products that serve people who do not speak the language of the developers; the most common case is software written for speakers of American English being modified, or “localized” for speakers of other languages. Localization involves more than simply replacing text strings. Localization issues include punctuation styles, word breaking algorithms (what constitutes a word in this language) and unit conversions (e.g. metric or imperial).

Commercial software developers will typically choose to localize in languages that are spoken by large markets. Localization is not an inexpensive task: it is necessary to employ (either full time or on contract) competent speakers and/or readers of the localization languages, and these speakers should have sufficient technical expertise to understand the meaning of the product’s functionality that is being described.

Emerging nations find that their languages are often underrepresented in localization efforts. Moreover, software developers from another nation and culture may make assumptions about use metaphors that are not valid for all users. African studies have consistently called out the need for "customizability to local languages and cultures as the main benefits of adopting open-source software as part of [an] e-government strategy." [49]

Open source software allows sufficiently sophisticated consumers to address these issues on a local basis. The requirements are no different from those of a proprietary software vendor, but the availability of the product source code enables a different model than that of the proprietary vendor. While the commercial vendor may find it unprofitable to localize in a given language/region, the local user base can disregard the economic issue or, in the alternative, derive revenue through meeting the local need.

Public Good

Open source license can be divided broadly into two categories. One category is dominated by the General Public License, or GPL, which places considerably restrictions on how licensed code may be used. The other category is best represented by the so-called BSD license, under which Berkeley Systems Division Unix was originally licensed. The BSD-style licenses usually do little more than reserve attribution rights, while allowing for nearly unfettered use of the licensed code. One of the key differences is that BSD-style licenses do not preclude use of the licensed code in a proprietary, commercial derivative work. The GPL-style licenses, on the other hand, require that derivative works are licensed under GPL terms.

It has been argued many times that GPL-licensed code serves a public good, promoting sharing of the licensed code throughout the community of consumers and programmers and allowing none to restrict its distribution or use. (The catchphrase “digital commons” is often used in this regard. [59]) Some public sector entities have explicitly addressed this ‘public good’ thesis. A quote from an academic in Uganda is a particularly clear example of the sentiment:

Many parallels can be drawn between the Open Source philosophy and the African idea of “Ubuntu”, which means that people [and ideas] grow and develop through other people. The major challenge to bridge the growing technological and digital gaps (also labeled the “digital divide”) is to marry the community spirit of Africa with the community spirit of open source. (Brackets in original.) [51]

This sentiment represents both a positive perception that sharing of such works is a benefit to society, and the negative perception that the developed world seeks to exploit or oppress emerging nations through the economics of proprietary software products.

Copyright and patent law have the effect of producing monopolies, and American law allows this to a great extent (although it then places restrictions on the actions of monopolists, in a strange legal tension). Other nations do not protect the interests of the individual to this extent, while some nations are quite honestly socialist in their political or social policies, and open source software, particularly that licensed under the GPL, seems quite natural in its protection of societal rights to a perceived benefit over individual rights to profit. [59]

Correlations: What Motivates Whom?

This section will attempt to draw some general conclusions regarding the influence of these various motivating factors on classes of governmental consumers.

US Public Sector Entities

The motivation for American states and municipalities to encourage open source software in government acquisition appears to be based almost exclusively in perceived cost benefits and economic balance-of-trade factors between regions and industry segments.

Developed Nations – Western World

European nations likewise seem to be motivated by balance-of-trade concerns, both economic (the “rent” complaint) and non-economic (co- option of the local IT industry). The latter concern is not as focused on individual development (i.e. training individuals to participate in the IT ecosystem), but rather on the ability of local industry to compete with American companies. In Europe, there is also a significant concern for data security and interoperability, to leverage network externalities in avoidance of monopolistic pricing and to avoid the perception of being “held hostage” by a foreign vendor.

The European Commission, for example, has asked all member nations to begin considering open-source alternatives alongside prepackaged software packages. In a June 2000 Action Plan, the European Commission outlined its eEurope initiative, which made specific mention of open source. One specific entry sets the target that “during 2001 the European Commission and Member States will promote the use of open-source software in the public sector and e- government best practice through exchange of experiences across the Union (through IST and IDA programs).”

Member nations have acted upon the policy in similar ways, with the following key characteristics [24]:

• Governments will consider open-source software solutions alongside proprietary ones in IT procurements. Contracts will be awarded on a value for money basis. (Total cost of ownership)

• Government will only use products for interoperability that support open standards and * specifications in all future IT developments.
• Government will seek to avoid lock-in to proprietary IT products and services.
• Government will consider obtaining full rights to bespoke software code or customizations of commercial “off-the-shelf” software it procures wherever this achieves best value for money.
• Government will explore further the possibilities of using open-source software as the default exploitation route for government funded research and development software.

Though decisions for actual implementation of these policies vary between member nations, the rationale is very clear. Germany, for instance, through an initiative known as “Bundestux” declared that “introduction of a free operating system in the Bundestag” to be a “necessary signal for Germany” to satisfy “basic regulation, competition, and location policy, as well as for democratic reasons”. [25] The UK, perhaps more succinctly, describes the following justifications for the European policy:

"There is a need to always procure a solution that gives the best value for money, be it an open-source solution or a proprietary one, or some mixture of both. Decisions should be made on a case by case basis. There is a need to ensure that interoperability of systems is provided and maintained. Every effort should be made to reduce the cost and risk to government systems. "

Developed Nations – Eastern World

In Asia, one might consider a division of the world into Japan and everything else. This may seem unfair to China, as it has developed a considerable technological base in recent years; but in IT, China is still an emerging nation.

Japan seems mostly content to transact business with proprietary vendors; one opinion is that Japan feels it is an equal partner in these transactions due to its overwhelming advantage in commodity computer hardware.

Emerging Nations

Governments that are in the process of establishing IT cultures are very attracted by the low cost of acquisition of open source software. The other elements of cost are of less concern because of the public good considerations: governmental agencies feel a duty to improve the lot of the individual citizen (or, in the alternative, identify economic value in doing so, by reducing unemployment and poverty). Nationalism is also a strong driving factor, especially in countries whose politico-economic system is different from that of the United States; socialist tendencies have particular affinity for the “forced good will” of GPL licenses.

Section Four Summary

Public sector entities – governments at various levels, from municipalities to nations – have taken notice of open source software, and many have embraced it to varying degrees. While low cost of acquisition is a very visible and defensible argument, it is actually a lesser factor than freedom from various economic, social and political restrictions, either actual or perceived. Among developed nations, balance of trade issues predominate; these include both economic and non-economic factors.

Emerging nations are seeking to “catch up” in this market, and are reluctant to “pay rent” to developed nations in perpetuity to enjoy the benefits of information technology. Open source software is seen as a way to jumpstart a local IT economy, through low cost of acquisition, and as a means to develop a local IT workforce and avoid long-term dependence on developed nations. In addition to economic considerations, local social and cultural factors may philosophically support this pro-open source position.

Conclusion

Four distinct interest groups are involved in the life-cycle of open-source software. Developers freely contribute to the creation of such products. Consumers and private-sector entities implement and deploy open-source software. Private-sector entities base profitable business models on the products of the open-source movement. Governments craft policy to manage the propagation of these products. Public-sector entities strategize to support and control open-source proliferation. These interest groups share common social, intellectual, economic and idealogical motivations for progressing the craft and policy of the open-source movement.

It is clear that the lure of "free software" (as in "free beer") is overstated in common perception. The interest groups described herein have found other motivation for the adoption or encouragement of the open-source software marketplace. Developers enjoy the freedom from the constraints on the practice of their craft that is often the byproduct of a corporate environment: they are free to "scratch the itch" that motivates them to create; those whose creativity lies in business are developing new strategies that allow these developers to enjoy financial remuneration. All consumers (public, private and individual) feel they have more choice, and perceive that their needs are more clearly heard and more quickly addressed. They are negatively motivated by the perception that proprietary software is defect-ridden and insecure, as well as the feeling of their data being "held hostage" in proprietary data formats. Governments see an opportunity to reverse the trend of centralization of software development - and accompanying revenue opportunity - in a few large American corporations. For many Third World countries, free software is not about anything as simple as cost: it is about freedom to develop as nations and as cultures, developing their people as well as their IT infrastructure. For the developing world, open source software is a second chance at defeating IT colonialism.

When producers and consumers freely assist in the production, propagation and consumption of open-source software, in apparent contradiction with accepted economic models, policymakers have the responsibility to evaluate the emerging software trend and understand how the new methodologies can stand to benefit people and organizations in their own jurisdictions.

References

1 Cook, Jonathan. Open Source Development: An Arthurian Legend. Department of Computer Science, Mew Mexico State University.

2 Crowston, Kevin, Hala Annabi and James Howlson. Defining Open Source Software Project Success. Twenty-Fourth International Conference on Information Systems. 2003.

3 Edwards, Kaspar. Epistemic Communities, Situated Learning and Open Source Software Development. Technical University of Denmark. (working paper) 2001.

4 Gomulkiewicz, Robert. How Copyleft Uses License Rights to Succeed In the Open Source Software Revolution and the Implications for Article 2B. Houston Law Review, 1999. p. 180 – 194.

5 Hann, Il-Hom et al. Why Do Developers Contribute to Open Source Projeccts? First evidence of Economic Incentives.Carnegie Mellon University and Apache Software Foundation.

6 Hertel, Guido et al. Motivation of Software Developers in Open Source Projects: An Internet-Based Survey of Contributors to the Linux Kernel. Research Policy Special Issue on Open Source Software Development. 2001.

7 Lerner, Josh and Jean Tirole. The Simple Economics of Open Source. Harvard Business School, NBER and IDEI. February 25, 2000.

8 Nichols, David M. and Michael B. Twidale. Usability and Open Source Software. University of Waikato, New Zealand and University of Illinois at Urbana-Champaign. 2003.

9 von Hippel, Eric. Open Source Software Projects as User innovation Networks. MIT Sloan School of Management, June, 2002.

10 von Hippel and Georg von Krogh. Open Source Software and the “Private-Collective” Innovation Model: Issues for Organizational Science. Organization Science, Vol 14. No 2. March – April 2003.

11 Ye, Yuwan and Kouichi Kishida. Toward an Understanding of the Morivation of Open Source Software Developers. University of Colorado and SRA Key Technology Lab.

12 Conoco deploys Linux-based supercomputer for use in oil exploration. 31 Aug. 2000. ComputerWorld. 13 Nov. 2004. <http://www.computerworld.com/softwaretopics/os/story/0,10801,49312,00.html >.

13 Boscov's Inches Into Linux. 4 Sept. 2003. LinuxPlanet. 14 Nov. 2004. <http://www.linuxplanet.com/linuxplanet/reports/4990/1/ >.

14 Technology: Open Source. 1 Dec. 2003. CIOInsight. 7 Nov. 2004. < http://www.cioinsight.com/article2/0,3959,1419629,00.asp >.

15 Travelocity's flight to open systems. 10 Nov. 2003. NetworkWorldFusion. 13 Nov. 2004. <http://www.nwfusion.com/ee2/2003/1110qa.html >.

16 Defy me! PopMatters. 10 Nov. 2004. <http://www.nwfusion.com/ee2/2003/1110qa.html >.

17 Guitar maker plays a Linux tune. 27 Nov. 2002. InfoWorld. 24 Nov. 2004. <http://www.infoworld.com/articles/hn/xml/02/11/27/021127hnerniball.html?s=IDGNS >.

18 Linux: SCM, Software Licensing, Petitions... 7 Mar. 2002. KernelTrap. 17 Nov. 2004. <http://kerneltrap.org/node.php?id=71 >

19 Linux: Open Source Ideology. 21 Apr. 2002. KernelTrap. 18 Nov. 2004. <http://kerneltrap.org/node.php?id=71 >.

20 B. Miller, D. Koski, C. Lee, V. Maganty, R. Murthy, A. Natarajan and J. Steidl. Fuzz revisited: A re-examination of the reliability of unix utilities and services. Technical report, Computer Sciences Department, University of Wisconsin, 1995.

21 Can You Trust This Penguin? 1 Nov. 1999. ZDNet. 14 Nov. 2004. <http://web.archive.org/web/20010606035231/http://www.zdnet.com/sp/stories/issue/0,4537,2387282,00.html >.

22 Pressrelease. 7 Feb. 2000. SysControl. 12 Nov. 2004. <http://web.archive.org/web/20011211235539/www.syscontrol.ch/e/news/Serversoftware.html >.

23 Evans and Reddy 2002

24 Open Source Software Use Within European Government, UK Envoy Office of Government Commerce

25 “Tux Takes its Seat in Germany's Federal Parliament”, published February 28, 2002, <http://www.heise.de/english/newsticker/data/anw-28.02.02-006/ > (accessed November 30, 2004).

26 US Office of the Budget

27 Kevin Bedell. "Open Letter to Sun from Eric Raymond". November 22, 2004. <http://www.oreillynet.com/pub/wlg/5961 >

28 David Worthington, Betanews. April 16, 2004. "AOL Answers Privacy Concerns in AIM Beta". <http://www.betanews.com/article/AOL_Answers_Privacy_Concerns_in_AIM_Beta/1082143843 >

29 Mark Pilgrim. "Freedom 0". May 14, 2004. <http://diveintomark.org/archives/2004/05/14/freedom-0 >

A This assertion might hinge on the type of license used by the open-source developers.

B Eric Raymond, The Cathedral and the Bazaar, Sebastopol, CA: O’Reilly & Associates, Inc., 1999, p. 117-122.

C Eric also debunks the myth that “the information wants to be free” in order to avoid the moral question on whether software should be free or not. See p. 123-128.

D Id., p. 122.

E Another argument typically associated with the notion that open source aids competition is the belief that open source will reveal a firm’s trade secrets, that is, confidential aspects of a firm’s business plan. This claim is problematic in that the source code of a software should not reveal aspects of a firm’s business plan, and, if it does, then it is a result of bad design. See p. 129.

F Id., p. 128.

G Id.

H I discuss this in detail in the following section.

I David Lancashire, "Code, Culture and Cash: The Fading Altruism of Open Source Development," First Monday, vol. 6, num. 11, December 2001.

J Raymond, The Cathedral and the Bazaar, Sebastopol, CA: O’Reilly & Associates, Inc., 1999, p. 117.

K Steven Weber, The Success of Open Source, Cambridge, MA: Harvard University Press, 2004, p. 127.

L See Ed’s lecture.

M Steven Weber, The Success of Open Source, Cambridge, MA: Harvard University Press, 2004.

N See Ed’s lecture.

30 Dan Ilett. ZDNet UK. "Kazaa creates worst spyware threat, says CA". November 25, 2004. <http://news.zdnet.co.uk/internet/security/0,39020375,39175030,00.htm >

31 Cynthia L. Webb. Washington post. "IBM's Open-Source Lovefest". September 13, 2004. <http://www.washingtonpost.com/wp-dyn/articles/A17842-2004Sep13.html?nav=rss_technology >

32 Computerworld. October 27, 2003. "IBM's Mills Sets Software Sights on Middleware, Linux". <http://www.computerworld.com/softwaretopics/software/story/0,10801,86443,00.html >

33 Christopher Koch. CIO Magazine. March 15, 2004. "Your Opensource Plan". <http://www.cio.com/archive/031503/opensource.html >

34 John Koenig. IT Manager's Journal. "Seven open source business strategies for competitive advantage". May 14, 2004. <http://management.itmanagersjournal.com/management/04/05/10/2052216.shtml?tid=85 >

35 Linux cheaper than Windows for web serving. 25 Dec. 2002. ITWorld.com. 8 Dec. 2004. <http://www.itworld.com/nl/ecom_in_act/12252002/ >.

36 Faster, Better, Cheaper: Open-Source Practices May Help Improve Software Engineering. 3 Dec. 2003. National Science Foundation. 8 Dec. 2004. <http://www.nsf.gov/od/lpa/news/03/pr03132.htm >.

37 Steve Ballmer, Customer Focus: Comparing Winodws with Linux and UNIX. Oct 2004. Microsoft Corporation. <http://www.microsoft.com/mscorp/execmail/2004/10-27platformvalue.asp >.

38 Kenneth Neil Cukier, Bandwidth Colonialism? The Implications of Internet Infrastructure on International E-Commerce. Communications Week International, France. <http://www.isoc.org/inet99/proceedings/1e/1e_2.htm >

39 Bram Dov Abramson, Internet Connectivity in LDCs. <http://www.itu.int/osg/spu/ni/ipdc/workshop/presentations/Abramson.pdf >

40 Neil Rickert et al., sendmail.  : O’Reilly & Associates, Inc., 1993.

41 Alan Joch, The Real Cost of Open Source. 22 Nov 2004. <http://www.fcw.com/fcw/articles/2004/1122/feat-open-11-22-04.asp >

42 Microsoft Support Lifecycle. <http://support.microsoft.com >

43 Sun Microsystems End Of Service Life policies. <http://www.sun.com/service/support/eosl/index.html >

44 Mogens Kuhn Pedersen et al, Open-source software in e-government. Oct 2002. Danish Board of Technology. <http://www.tekno.dk/pdf/projekter/p03_opensource_paper_english.pdf >

45 Transcribed ad hoc from a lecture by Rob Short, Microsoft Corporation, "Issues with Building the Most General Purpose System Ever", delivered at University of Washington, Jan 2004.

46 John Viega, Open Source Security: Still a Myth. 16 Sep 2004. <http://www.onlamp.com/pub/a/security/2004/09/16/open_source_security_myths.html >

47 Matthew Boersma, New set of Linux security flaws unveiled. 8 Dec 2004. <http://www.techworld.com/security/news/index.cfm?NewsID=2768&Page=1&pagePos=2 >

48 Edgar David Villanueva Nunez, Letter from Congressman Nunez to Juan Alberto Gonzalez, President of Microsoft Peru, dated 8 Apr 2002. Viewed 12/2/2004 at <http://gnuwin.epfl.ch/articles/en/reponseperou/villanueva_to_ms.html >

49 Government Information Officers' Council, South Africa, Using Open Source Software in the South African Government. 16 Jan 2003. <http://www.oss.gov.za/docs/OSS_Strategy_v3.pdf >

50 Megan Santosus, Rising Costs of High-Tech Garbage. 15 Apr 2003. CIO Magazine.

51 Victor van Reijswoud, Open Source Software - the Alternative for Africa. 15 Feb 2003. Uganda Martyrs University. <http://www.wougnet.org/ICTpolicy/docs/oss+in+africa.pdf >

52 The Embeddable Linux Kernel Subset. <http://elks.sourceforge.net >

53 United Nations Conference on Trade and Development, E-Commerce and Development Report 2003, Chapter 4: Free and open-source software: Implications for ICT policy and development. 2003.

54 Jennifer Kuan J, Open source software as lead user’s make or buy decision: A study of open and closed source quality. 18 Jan 2003. Paper presented at the second conference on “The Economics of the Software and Internet Industries”, Toulouse, France, 17–18 January.

55 Brendan Scott, Open Source and the IT Trade Deficit. Jul 2004. Open Source Law. <http://www.opensourcelaw.biz >

56 Stallman, Richard. On the Netscape Public License. 1999. <http://www.gnu.org/philosophy/netscape-npl.html >

57 MySQL AB. MySQL Licensing Policy. Mar 2004. <http://www.mysql.com/company/legal/licensing/ >

58 For example, Netscape hired Mozilla contributors Blake Ross, Asa Dotzler, Ben Goodger, David Baron, Boris Zbarsky, and Jesse Ruderman as interns, on-site contractors, or full-time employees. Personal knowledge, Jesse Ruderman.

59 Derek Keats, Idlelo: First African Conference on the Digital Commons. Jan 2004. Report to Department of Science & Technology, South Africa.

Team Member Participation

The "Motivation and Rewards of Open Source Development" team has six members.

• Gail Frederick, UW: Author of "Section One: Developer Motivations". Editor of all sections of policy brief.
• Jeff West, UW: Author of most of "Section Two: Consumer Motivations".
• Richard Michaelson, Berkeley: Author of Introduction and most of "Section Three: Private Sector Motivations". Editor of all sections of policy brief.
• Jesse Ruderman, UCSD: Author of "The Trust Motivation" in section two and "Open-Source Software Business Models" in section three.
• Ian King, UW: Co-Author of "Section Four: Public Sector Motivations".
• Kevin Watt, Berkeley: Co-Author of "Section Four: Public Sector Motivations".