Open Source Motivations Final Paper

Introduction

Two extremes typically characterized Open Source (OS) discourse. One extreme speaks of OS, like a religion, as a revolutionary production model operating under a new, different, set of political, social, and economic rules. The other extreme is entirely pessimistic and posits OS as a passing fad since it is ultimately economically unsustainable. To policymakers and others interested in OS issues, these opposing characterizations, at minimum, makes it confusing and difficult to construct meaningful OS policies.

This policy brief is not an attempt to provide the final answer on which characterization of OS is most truthful. Instead, we will provide policymakers with tools to better think through OS issues by discussing the role of motivation and rewards, a theme underlying most of OS discourse, to which each extreme characterization posits opposing views.

Specifically, we explore the role of motivation from the supply and demand sides. For example, what prompts developers to contribute to OS, given the assumption developers contribute to OS projects using their own time and without compensation? Is this assumption even true? Do the benefits associated with OS software differ from closed source (CS), for-profit software? On the demand side, why do consumers want OS over CS technology? In addition, various world governments as well as state governments in the U.S. have increasingly turned to OS. What are their incentives? Furthermore, for-profits are employing OS both as a tool to help run their businesses and as a basis for their business models. Why? And what are the kinds of business models emerging in these nascent markets?

This policy brief will explore these issues of motivation. Chapter 1 will discuss developers' motivations. Chapter 2 will discuss consumers' motivations for adopting OS. Chapter 3 will dicuss the private sector's incentives to employ OS and OS business models. Chapters 4 and 5 discusses the public sector's motivation for increasingly adopting OS. Regardless of the veracity of either extreme OS characterization, our discussion of motivation in relation to OS will provide policy makers with some tools to think through their decisions on both OS policy and OS use.

A Survey of Software Developers’ Motivations to Contribute to Open Source Software Projects

What motivates commercial software developers and students of the craft to freely contribute to open source software projects? 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] He remembers Arthur’s knights as volunteers for the common good, selflessly practicing feats of bravery and rewarded with esteem.

Cook paints a rosy portrait of open source developers (I’ll call them OSDs). 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 frequently 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. We visit psychology, economics and learning theory as we discover the motivations of software developers toward volunteer projects.

The Selfless 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.

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. They organized into small teams. And they volunteered their work. If you accept that open source projects are indeed social movements, then social psychology describes collective motives as reasons why participants engage in development projects. If a developer values the goals of the open source project, and if that developer envisions its goals as attainable, then the more likely she is to participate in the project. Social motives, such as the expected reaction of friends, family and professional community, also motivate participants in social movements.[6]

A prevalent motive in geek culture is the intellectual motive or hobby motive, the challenge of solving a difficult problem and submitting the solution to immediate peer review.[8] Some software developers are motivated by simply solving a hard problem.

Learning theory offers a similar explanation of the intellectual motive. 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 their daily practice.”[11] Newer developers may join an open source project to solve a problem with the software that personally affects the developer. They stay affiliated as long as they continue to learn from and intersect with more experienced developers in the project.

But are social and cultural 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.

The Selfish Explanation

Contrary to the musings of advocates in the open source movement, participation in open source projects can also be explained in selfish terms. Open source developers contribute because it helps them professionally.

Through their participation in volunteer projects, open source developers gather professional credentials and improve programming skills. Developers are motivated by improved professional reputation and the status of public association with an open source project. Reputation can be conveyed by acceptance of a contributor’s work into the project codebase1, public peer-review of developers’ software contributions and even credits in the source code (in geek jargon – a “greputation”). [2] Economic research shows that 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] Familiar epistemic communities in our society are communities of research scientists. Community participants are highly motivated by influence and reputation.3 Actors in such communities can become politically-motivated because of the reputation gain at stake. Open source communities organize hierarchically with a small number of elite developers managing the contributions of many less-involved programmers. The process of 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 contributors improve programming skills, a practical motivation that can directly assist them in commercial situations. Legitimate peripheral participation addressed learning for its own sake, but the learning process in contributing to open source projects also has obvious professional benefit.

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 also help the broader user community for the software.

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. Most developers contribute to projects during their non-working hours. Developers in open source projects benefit by signaling proven programming productivity and marketable skills to employers.[5]

The first way to economically motivate a software developer is to increase the benefits of participation. 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 This benefit of open source participation can be called the career concern incentive.[7]

The second way to motivate a software developer is to reduce the costs of participation. The economic costs of participation in open source projects 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] The software developer is also economically motivated by full initiative. The developer takes full responsibility for design and development of the contributed source code. There is no supervisor interference, for example, as with commercial products.[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]

We have seen that 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.

Consumer Motivation

We now shift the focus of our brief to the consumer.motivations for using open source software as an alternative to closed source software. What causes individuals and public and private organizations to adopt open source software even though closed source software is usually more widely advertised and accepted? There are four major reasons that tend to come up as you research who the consumers are: cost, flexibility, ideology, and reliability.

Cost

When the topic of open source software is brought up, many people falsely assume that open source software is free. Open source software, while free to install, is not free to maintain. There are still rather important costs for support and maintenance that must be considered if one chooses to use an open source solution. However, for many applications the costs associated with open source software is far less than the cost of using closed source software. It is for this reason that many consumers choose to use open source solutions.

In 2000, Conoco decided to use Linux as an operating system for a supercomputer that analyzes seismic data that they accumulate 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, claims 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 interuption, 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. had to make a decision between using Unix or using Linux 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. Because the tradeoff cost of support for the open source software is not necessarily any higher than the cost of the same support with purchased software, the overall cost is usually far less when open source software can be used as an alternative to licensed software.

Flexibility

While it’s important for software to be low-cost, it is also important that it be flexible enough to meet whatever needs you have. Some companies require more specialized software than can be found on the traditional closed-source market due to custom hardware or unique business practices.

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.” 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.

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 soultions 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 your needs. In addition, it is usually not hard to switch between versions of the software if you find that one company’s product or support is not meeting your needs. This will not be the case with clsoed source software, which will almost always be provided by only one company.

It is far easier for copmanies 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 is a much better alternative than creating the necessary software from scratch with a much larger number of developers.

Ideology

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), where the main character’s friends throw out quotes like “Human knowledge belongs to the world.”

Of course, 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.”

It’s worth noting, however, that Linus Trovalds 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 software is being used in such a capitalist way, believing that software belongs to the world and not to the companies responbile for its creation.

Reliability

The final reason that consumers choose open source software that we will discuss is the increased reliability that many open source projects boast. 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 reviwed 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 faiulre 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 (IIS) web server software 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 which were run off of Microsoft’s ISS software had twice as much downtime as the websites which were run off of Apache.

The fact of the matter is that most open-source code is viewed by far more programmers and therefore 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.

Private Sector Motivations

Why are firms supplying or contributing to OSS and even basing their business models on OSS? This sub-section focuses on the supply-side reasons for and against firms’ motivations to turn to open-sourcing. The demand-side explanations for firms consumption of OSS is discussed in the “Consumer Motivation” sub-section. In the first part, I lay out and discuss the merits behind the most common arguments against open-sourcing. In the following section, I discuss reasons for firms’ adoption of OSS. In the last section, I discuss some of the emerging business models employing OSS.

Arguments against Open-Sourcing

Literature on open-sourcing suggests there are three main arguments against open-sourcing. First, it is more difficult and requires more effort and creativity to make money from OSS since its sale value as a salable commodity is zero. Businesses who do employ OSS 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 closed-source software. Indeed, I discuss later the 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 OSS.

Eric Raymond debunks the claim that it is more difficult and requires more effort and creativity to make money from OSS since its sale value as a salable commodity is zero. He argues that this claim is rooted in the “manufacturing delusion” 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. 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.”

Another reason firms do not turn to open-sourcing is the belief 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. 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. 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-sourcing. Eric Raymond, I think rightfully, 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.” Thus, open-sourcing may be more favorable in different contexts.

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

Reasons Supporting OSS

In contradistinction from proponentes of closed-source software, supporters of OSS believe open-sourcing offers “better quality, higher reliability, lower costs, and increased choice.” Thus, firms supply OSS because they believe they are at a market advantage by providing OSS services or products. The least controversial claim is that open-sourcing provides lower 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 in favor of OSS is that it is more reliable. One variant of this argument states that firms engaging in OSS take advantaged 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 employing OSS have a “fail-safe” community of developers available. As Steve Weber puts it, “the ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing.” The other variant of the argument that OSS is more reliable is the belief that OSS is less “buggy.” The process of peer review, in this view, is seen as a highly effective mechanism in testing an application.

Is OSS qualitatively better than the closed-source alternative? This is a more difficult question to answer and proving the veracity of OSS supporters’ claims will likely rely on subjective evidence at this point. In some ways, the reasons given in support of OSS 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 OS operating systems. Thus, the final and absolute answer to the question of OSS’ quality remains unclear.

Similarly, the argument that OSS provides increased choices is also controversial. In this schema, many supporters of OSS 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, less choices. However, in an open-source world, it is not clear to me 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. Arguably, this might be the main reason firms are willing to turn to open-source and, indeed, make open-sourcing critical to their business model. As Steve Weber eloquently puts it:

The point is that open source software is not simply a nonrival 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. In the following section, I provide examples of the various ways firms are employing OSS as part of their business models.

TODO: Finish section.

Public Sector Entities

Introduction

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 chosen to relax 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.

Cost Factors

The simplest argument is that open source software is typically 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 [cite], the economy of governmental purchases is often quite different from that in effect for the business sector.

The argument in [cite] states that the cost of purchasing software consists of 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 [chart?].

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 . 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 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. [cite]

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 (either directly or indirectly; training may be subject to intellectual property restrictions).

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.

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 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.

Open source software often claims that upgrading is not a revenue model for its community, and therefore users are immune from these costs. However, upgrades will be driven by the same needs, 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).

Public sector entities may have in place technical staff that is capable of addressing these issues in open source products, but this is not universal.

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.

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, 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.

Nonetheless, reliability is a claim by the open source community that, with little objective evidence, is one of the factors in its adoption in some circles.

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, but it 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.

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.

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.

TODO: Insert Table Here

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 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. 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.

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.

TODO: Insert image

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 “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.

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.

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.) 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.) 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.

Correlations: What Motivates Whom?

[This section in development….]

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.

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.

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.

Conclusion

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.

Government Motivations

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. In this section, 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 . 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.

What Motivates Government to Support Open Source

Government, like business, is motivated to purchase open source based upon ideology, cost, and a technical “best fit”. Until the late 1990’s, government at various levels, especially domestically, had mandated prepackaged “closed-source” software purchases for the perceived support and accountability offered by those packages and vendors. Recently, however, there has been a fast-growing trend among national governments encouraging the exploration of open-source alternatives to prepackaged software. 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 programmes).”

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

Governments will consider OSS 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 OSS 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”. 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 OSS 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.

The eEurope initiative is not radical by any means, as similar policies have recently mandated throughout Asia, including Singapore, Taiwan, China, and Japan, as well as in the United States . Excepting France, which has been the most vocal proponent of open-source systems for ideological reasons and a potential burn with Microsoft, there has been a general consensus that public policy should be limited to promote compatibility standards that serve public needs, and not specific groups or corporate interests, including open-source.

Conclusion

TODO: Conclusion to entire paper

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 http://www.computerworld.com/softwaretopics/os/story/0,10801,49312,00.html

13 http://www.linuxplanet.com/linuxplanet/reports/4990/1/

14 http://www.cioinsight.com/article2/0,3959,1419629,00.asp

15 http://www.nwfusion.com/ee2/2003/1110qa.html

16 http://www.popmatters.com/film/reviews/a/antitrust.shtml

17 http://www.infoworld.com/articles/hn/xml/02/11/27/021127hnerniball.html?s=IDGNS

18 http://kerneltrap.org/node.php?id=71

19 http://kerneltrap.org/node/view/159

20 http://www.opensource.org/advocacy/fuzz-revisited.pdf

21 http://web.archive.org/web/20010606035231/http://www.zdnet.com/sp/stories/issue/0,4537,2387282,00.html

22 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