Jump to ContentJump to Main Navigation
The Comingled CodeOpen Source and Economic Development$

Josh Lerner and Mark Schankerman

Print publication date: 2010

Print ISBN-13: 9780262014632

Published to MIT Press Scholarship Online: August 2013

DOI: 10.7551/mitpress/9780262014632.001.0001

Show Summary Details
Page of

PRINTED FROM MIT PRESS SCHOLARSHIP ONLINE (www.mitpress.universitypressscholarship.com). (c) Copyright The MIT Press, 2018. All Rights Reserved. Under the terms of the licence agreement, an individual user may print out a PDF of a single chapter of a monograph in MITSO for personal use (for details see http://www.mitpress.universitypressscholarship.com/page/privacy-policy). Subscriber: null; date: 21 June 2018

Assessing Government Policies toward Software

Assessing Government Policies toward Software

Chapter:
(p.157) 6 Assessing Government Policies toward Software
Source:
The Comingled Code
Author(s):

Josh Lerner

Mark Schankerman

Publisher:
The MIT Press
DOI:10.7551/mitpress/9780262014632.003.0006

Abstract and Keywords

This chapter focuses on government policies on computer software. It examines how a government can develop a framework that facilitates the competitive interactions between open source and proprietary software in a manner that boosts efficiency and innovation. It analyzes arguments for why the government should support open source software and suggests that when it comes to regulation, governments should encourage vigorous competition between open and proprietary software. This chapter also argues that the government should play a lead role in providing information about the features of different types of software to consumers.

Keywords:   computer software, government policies, open source software, proprietary software, competitive interactions

Both in developed and developing countries there are vocal calls for public support for open source software. Many governments have adopted such initiatives. According to one tabulation, in 2008 there were 182 different initiatives in force worldwide, and many more proposed.1 These take a wide variety of forms, including R&D support, subsidies, preferences in government procurement, and even outright mandates for public institutions to adopt open source. They span the globe: of the 182 initiatives adopted in 2008, 95 were in Europe, 47 in Asia, 20 in Latin America, but only 9 in North America.

We can illustrate this movement toward open source support with a few concrete examples. Under the Malaysian Public Sector Open Source Software Masterplan, as of 2004, all government procurement must show a strong preference for open source software.2 In 2008, Argentina proposed a bill to make open source mandatory throughout all government institutions, as Brazil had done in 2005 (Kingston 2005; Marson 2005). Similar proposals have been made in a number of other countries. Since 2003, Singapore has offered tax breaks to companies using GNU/Linux operating systems rather than proprietary ones in order to encourage the development of the local software sector (UNCTAD 2003). The government of Thailand actively promotes the adoption of the Linux operating system in government agencies, schools, and universities through its Software Industry Promotion Agency, and Indonesia has a similar program to encourage the use of open source IGOS, which stands for “Indonesia, go open source!” (Marson 2005; CNET Asia 2006).

(p.158) In 2004 a brochure published with the help of the United Nations Development Program stated, in a way that is representative of many claims in support of such initiatives:

At the national level, FOSS (free and open source software) aids in the development of local capacity/industry, reduces imports, conserves foreign exchange, increases the security of the national ICT infrastructure (this is distinct from application level security), reduces copyright infringement and brings localized ICT tools to help develop local knowledge communities …. FOSS provides many socio-economic benefits. The most commonly cited are fostering the ICT industry through increased competition, lowering the ICT application cost and Total Cost of Ownership, increasing access to powerful yet localized ICT applications, increasing security of ICT applications and providing vendor independence …. Yet for all these clear benefits, many nations find that without a national FOSS policy, the uptake of FOSS in the country is far too slow for their needs. There are a number of reasons why FOSS requires policy intervention, including limited marketing of FOSS, lack of attention to its many non-commercial benefits and the need to overcome entrenched legacy systems. (Wong, 2004)

The American humorist, Will Rogers, once said, “It isn’t what we don’t know that gives us trouble, it’s what we know that ain’t so.” As the previous two chapters should have made clear, many of the asserted facts used in the preceding quote to justify government support for open source software do not stand up to closer examination. For example, in chapter 5 we show that there is no evidence that open source software has a lower total cost of ownership. It has a different cost structure than proprietary software, which is attractive to some types of users but not to others. Indeed even the idea of there being a single TCO, one that is common across the population of heterogeneous users, does not stand up to scrutiny.

However, the fact that there are bad reasons for governments to give preferential treatment to open source software does not mean that there are no good reasons, grounded in “real” facts. What is important is to have a policy environment that promotes innovation and efficient use of software in general, and open source in particular. To accomplish this end, governments need to formulate public policies based on systematic evidence and solid economic reasoning. In this chapter we build on the empirical analysis of the software sector presented in earlier chapters to examine the extent to which government intervention is warranted on economic grounds, and to discuss the broad form of government policies that should be adopted with regard to the software sector.

(p.159) Governments have two main channels through which they can influence the development and use of open source software: first, as large-scale buyers of software and, second, as regulators who set the rules of the competitive game between open source and proprietary software, including the provision of incentives and the policy toward standards that affect software compatibility. In this chapter we focus on two main questions:

  • Should governments favor open source software in their procurement policies?

  • Should they provide special incentives for firms who develop or use open source software?

In both their procurement and regulatory roles, we will come to the conclusion that government should adopt a neutral attitude that favors neither proprietary nor open source software. We argue that market failures are not large enough to suggest that either mode of software development is seriously disadvantaged by the normal play of competition. While the installed base of proprietary software is certainly larger, the analysis in chapters 4 and 5 shows that there is already extensive comingling of the two types of software both by users and software developer firms. This fact suggests that network effects do not pose a serious enough threat to effective competition that would justify government intervention, provided that an appropriate regulatory framework is in place. We argue that the primary focus of such regulation should be promoting “open standards” and a vigilant competition policy to prevent any abuse of network effects. These twin policy instruments will go a long way toward ensuring effective competition between, and comingling of, open source and proprietary software. Of course, just as parents should not treat their children identically, even if they do not favor one over the other, this does not imply that the treatment of the two categories of software should be absolutely identical. They have different characteristics, and we will explain how, and where, public policy can sensibly respond to these differences.

We begin our analysis by presenting new survey evidence on how developers and users view alternative regulatory regimes for software. The evidence shows a dominant preference among all categories of developers and users for a regime that allows them the freedom to choose, rather than one that restricts their choices to either open source or proprietary software. We then take up a series of arguments often (p.160) made to justify proactive government support of open source, as reflected in the introduction to this chapter. We use economic analysis and empirical evidence to assess whether, and under what conditions, any of these arguments are valid. In this analysis we deal with possible imperfections both on the demand side of the market (e.g., users lacking information about open source) and the supply side (e.g., the argument that open source uses more local resources and less foreign exchange). We then turn to a discussion of the two key roles of government in shaping the software market: procurement and regulation of standards. Finally, we provide new survey information on the extent to which governments provide incentives of various forms for open source and proprietary software development, and discuss whether there is a good economic justification for them.

What Regulatory Regime Do Developers and Users Prefer?

Many observers who call for government intervention in the market for software do so because they believe that the market has coordinated on the “wrong” solution. The quotation from the United Nations in the introduction to this chapter suggests such “coordination failure” too, by asserting “the need to overcome entrenched legacy systems.” As we discussed in chapter 3, the presence of network effects can create the possibility that users choose to buy a particular type of software because others do, or have done so in the past. Because the installed base can strongly affect the trajectory of purchases in the future, it is possible, at least in theory, that all users (and software developers) might be better off if they switched en masse to another solution. But if this were the case, we should expect users and developers to be aware of this fact and, if asked, to register regret at having to purchase an inferior good in order to flow with the crowd.

Our survey provides us with the first available data on the regulatory framework that software developers and users in different countries prefer. We asked software developers and users to rank five alternative regimes: only open source allowed, open source when available, only proprietary allowed, proprietary when available and complete freedom to choose. For simplicity, we aggregate these into three categories: open source, proprietary, complete freedom to choose (the conclusions are similar if we use the full breakdown). As table 6.1 shows, both users and developers overwhelmingly favor the unrestricted (freedom to choose) regulatory regime. Turning first to panel (p.161)

Table 6.1 Regulatory regime preferred by software developers and users (percentage of firms giving top rank)

Open source

Proprietary

Complete freedom to choose

Panel A: software developers

Aggregate

15.8

(0.8)

31.6

(1.1)

52.6

(1.1)

Developers of only proprietary

12.1

(0.9)

36.3

(1.3)

51.6

(1.3)

Developers of only open source

25.6

(1.8)

24.0

(1.7)

50.4

(2.0)

Developers of both

18.8

(1.4)

25.0

(1.5)

56.2

(1.7)

Panel B: software users

Aggregate

18.0

(0.8)

30.9

(1.0)

51.1

(1.0)

Users of only proprietary

13.8

(0.9)

36.7

(1.2)

49.5

(1.3)

Users of only open source

38.1

(4.1)

15.8

(3.1)

46.1

(4.2)

Users of both

23.9

(1.7)

19.8

(1.6)

56.3

(2.0)

Note: Multinomial standard errors are in parentheses. These are computed as √p(1 – p)/n, where p is the reported proportion and n is the sample size.

A in the table, we see that 53 percent of software developers prefer a regime which leaves complete freedom to choose between proprietary and open source software. Of those who prefer some kind of targeted regime, two thirds of them (32 percent of all respondents) prefer a regime which favors proprietary software and one third (16 percent of all respondents) prefer a regime that favors open source. This majority preference for “freedom to choose” holds not only for firms that currently develop both proprietary and open source software but also for firms that currently develop only one type of software.

Panel B in the table confirms that the picture is very similar for software users, where 51.1 percent prefer the complete freedom to choose over any kind of restricted regime. As with developers, the dominant preference is for a neutral regime for all three types of users—those who currently use only open source (this only constitutes 5.9 percent of users), only proprietary, and both types of software.

(p.162) Of course, the regulatory regime that developers and users prefer might be expected to depend on their characteristics. For example, large software development firms and users, who are more likely to find diversification an attractive strategy, might have stronger preferences for regimes that ensure freedom to choose. In fact the reported preferences are remarkably similar across the spectrum of software firms and users, though there are a few interesting exceptions, as we summarize here. The most important conclusion from these tables is that all categories of developers and users register a dominant (plurality) preference for “complete freedom to choose.” This is true for developers in each size, ownership and business model group. While there is some variation in the strength of preferences across these groups, econometric analysis shows that these variations are not statistically significant. The only factor that has a statistically significant effect on their preferences is the firm’s current development focus. Unsurprisingly, software firms that develop both open source and proprietary software (as opposed to only one of them) are especially likely to prefer “complete freedom to choose.”

For users, two additional noteworthy conclusions emerge. The first conclusion we want to highlight is that smaller firms are more attracted to a regime of “complete freedom to choose” than large firms. This finding might seem initially surprising, since small firms are less likely to diversify and thus one might have expected them to benefit less from such freedom. But the evidence shows that this is not the case.3 Moreover the finding has an important policy implication for governments that are interested in promoting a supportive environment for entrepreneurship and small firms. The second noteworthy finding is that the majority preference for “complete freedom to choose” is registered not only by domestic firms, but even by government agencies (51.6 and 52.0 percent, respectively). Later in this chapter we will return to the issue of government regulation of software use by its own agencies.

While all categories of developers and users tend to prefer a regime that allows them complete freedom to choose the software most appropriate to their needs—and to comingle them, as we have seen—there

(p.163)

Table 6.2 Preferred regulatory regime (users), by country (percentage of firms giving top rank)

Open source

Proprietary

Complete freedom to choose

Brazil

24

15

61

Chile

4

24

72

China

21

26

53

France

16

14

69

Greece

4

27

69

India

19

51

30

Israel

23

31

46

Kenya

41

15

43

Mexico

19

32

49

Poland

12

38

50

Russia

13

16

71

South Africa

13

35

52

Singapore

13

39

48

Thailand

24

64

13

Turkey

22

38

39

is considerable variation across countries. Table 6.2 summarizes user preferences in the survey countries (the conclusions are similar for developers, but the table is omitted for brevity). In eight of the fifteen survey countries, there is a strict majority preference for freedom to choose, and it is the dominant preference (a plurality of users register it) in all but two countries, India and Thailand, which prefer a proprietary software regime (a policy that restricts use to only proprietary or proprietary when available). The proportion of users who prefer an open source regime (a policy that restricts use to only open source or open source when available) varies from a low of only 4 percent in Chile and Greece to a high of 41 percent in Kenya. It is clear from table 6.2 that there is no relationship between the level of economic development and the preference for particular regulatory regimes.

Of course, we fully recognize that the extensive survey evidence presented in this section is not by itself sufficient to make the case for a neutral government policy that gives developers and users complete freedom to choose. There is the risk of “coordination failure” among these responses. The fact that the majority of respondents individually prefer a particular regime does not ensure that such a regime would be efficient. Nonetheless, the pervasive preference by developers and users for an unrestricted regulatory regime certainly provides, at a (p.164) minimum, a prima facie basis for thinking that government policy should be neutral between open source and proprietary software. In the remainder of this chapter we explain why we feel they are right on this account. Given these preferences, any argument that governments should favor one or the other type of software would have to explain why users and developers have the “wrong” preferences. We turn next to an economic evaluation of the various arguments that are often made in favor of nonneutral policies.

Should Governments Support Open Source Software?

Economists generally agree that in market economies, governments should intervene not only to provide for public goods (e.g., national defense or education), and perhaps to redistribute income, but also in order to correct market imperfections. For instance, the market does not attach a price to the environmental cost of polluting activities. As a consequence firms and consumers facing this distorted market would pollute more than is socially optimal, and governments intervene through regulations and taxes to correct this “market failure.”

As we discussed in chapter 2, the software market has a number of potential market imperfections, suggesting that there may be scope for government remedies. However, we are well advised to keep in mind that government intervention is far from perfect in practice: like everyone else, public officials make mistakes and are subject to political and lobbying pressures that can lead to policy choices motivated more by personal than public interest. Thus, in any specific situation, policy analysis must weigh the costs of “market imperfections” against the costs of “government imperfection.” Disagreement about the advisability of policy interventions is often due to differing assessments of these costs, but it is important that any such assessments be grounded in evidence, not wishful thinking.

We now turn to a review the types of public policies that can be implemented to correct market imperfections in the software market, and more specifically, those affecting the choice between open source and proprietary software. We do this in two steps. First, we review the policies that can be used to correct “demand side” imperfections—namely reasons why the choice by users between open source and proprietary software might be distorted, as compared to what would be socially optimal. In the second step, we discuss “supply side” imperfections that affect the provision of new software. This analysis (p.165) will provide us with the background that we need for analyzing some specific policies.

Correcting Demand Side Imperfections in the Software Market

We begin with a discussion of the demand side because it is the only one for which formal policy analysis has been conducted in the economic literature.4 We first present a simplified and nontechnical version of the model developed by Schmidt and Schnitzer (2003) that has become the canonical model to study the consequences of government support for the use of open source software (for the interested reader, appendix 6.1 provides a more technical description of the model). After the analytical framework is described, we show how it has been used to address some policy issues.

To give the underlying intuition behind the argument that we will develop, we start with a simple observation. As explained in chapter 2, providing one more customer with a copy of a program is very inexpensive; in many cases it is only the cost of uploading the additional copy. However, when the program is sold by a profit-maximizing firm, its price will be substantially above this marginal cost because firms need to recoup the large fixed cost they have had to incur to develop the software. This creates an economic inefficiency, as some users who would have been willing to compensate the producer of the software for the extra cost of providing them with a copy will choose not to acquire it. For example, if distributing an extra unit of the program cost $2 and it is sold at a price of $200 by the producer who needs to recoup the fixed cost of production, there could be many consumers willing to pay, let us say, $100 who will not buy it. From a social welfare point of view, the inefficiency stems from the fact that a potential increase in welfare of $98 (= $100 – $2) is not realized. This inefficiency is a manifestation of the basic trade-off in the economics of innovation between static and dynamic efficiency, which we discussed in chapter 2. To provide incentives for innovation, the firm needs to cover the associated fixed costs by marking up price above marginal cost, but to promote efficient use of an existing innovation, price should be set equal to marginal cost.

(p.166) This applies to proprietary software, but what about open source? It is true that the production of open source is not free from a social perspective, even if it done by “volunteers.” Not only are private firms active in developing and/or funding open source software, but the time and other costs incurred by individuals who contribute to open source projects also constitute real social resources that need to be somehow compensated. However, as we have seen in the previous paragraph, economic theory tells us that in an ideal world these “fixed costs,” which are independent of the utilization of the software, should not be reflected in the price. Therefore open source software, which is priced at (or near) zero, is appropriately priced from a social perspective when we restrict our attention to the efficient distribution of the software (as opposed to ensuring incentives for development of the software). As a consequence consumers are choosing between open source, which is “well priced,” and proprietary software, which is “over priced.” This distortion in pricing creates a distortion in the choices made by users. The formal model developed below examines how this works, and what policy conclusion emerges from it.

Consider a market in which both an open source and a proprietary program are offered. To make things simple, we assume that both programs are produced at a marginal cost of zero and that the open source program is sold at a price of zero.5 (Of course, as we discussed in chapter 5, in reality open source users incur other forms of costs; these could easily be included in the analysis without changing the main insights). The programs are of the same quality, but different consumers have different taste for one or the other. Each consumer is characterized by a “taste” parameter, which we denote by t, that takes values between 0 and 1. The benefit the user attaches to one program or the other depends on her taste parameter t: the smaller is t, the more she likes the open source program; the larger is t, the more she likes the proprietary program. A natural way to interpret this taste parameter, here is as a summary index of the various costs the user incurs in adopting that type of program, apart from the initial cost of obtaining the software (e.g., the costs of switching, interoperability, support services, or upgrades).

We represent this situation in the left panel of figure 6.1, which depicts the value the user attaches to the open source program. When

(p.167)

Assessing Government Policies toward Software

Figure 6.1 User benefits from open source and proprietary software

Assessing Government Policies toward Software

Figure 6.2 Comparing benefits from open source and proprietary software

her type t is equal to 0, she values it at v; the larger her t, the less she values the open source software, so users with a taste parameter equal to 1 value it the least. Assume for a moment that the proprietary program is given away for free. Then the value it has for the different users, which is represented in the right panel of figure 6.1, is the mirror image of the value that they attach to the open source program. For the hypothetical user, this value is v and this value decreases as t declines.

In figure 6.2 we combine the two previous graphs to enable us to compare the values derived from the two programs by the different users. The users whose taste parameter t is less than 12 attach a higher value to the open source program than to the proprietary program; given the choice between the two (at the same price), they would (p.168) choose the former. The preferences are reversed when t is greater than 12. These assumptions of very strong symmetry between both programs are made in order to help focus the analysis on the main difference between them: the mode of distribution.

The distance between the two lines in figure 6.2 represent how much more the users are willing to pay to have access to their favorite programs. For instance, the length of the segment AB¯ represents how much more the consumer whose taste parameter is 5/6 would be willing to pay for the proprietary program than for the open source program. If the price difference between these two programs were equal to this difference, the consumer would be indifferent between acquiring one or the other.

Depending on the applications, users can be more or less attached to their favorite program: an increase in the slope of the two lines represent how much more a change in the taste parameter affects the value that users attaches to the different programs. The larger the slope, the larger is the difference between the value that a user attaches to his favorite program and the smaller is the value that he attaches to his least favorite program: as the slope increases, the length of AB¯ in figure 6.2 increases.

Of course, the developer of a proprietary program does not give away its program. The value that a user derives from using the proprietary program will be equal to its intrinsic value minus the price she pays to acquire it. This adjustment simply shifts the line for proprietary software in figure 6.2 down by the amount p. No adjustment is needed for open source software, on the assumption that it is available to the user for free.

We put these elements together in figure 6.3, where we analyze the choice users make between the two programs when the developer of the proprietary software charges a price equal to p. For all taste parameters smaller than , the straight line that plots the benefits to the users for the open source program is above the line that plots the benefits for the proprietary program: thus, users with t will choose the open source program. On the other hand, users with taste parameters t will choose the proprietary program. The allocation of the users between the two programs is represented by the arrows below the horizontal axis.

If the price of the proprietary software were zero, the figure would be symmetrical and would be equal to 12: the users would split themselves half and half between the two programs. On the other hand, (p.169)

Assessing Government Policies toward Software

Figure 6.3 Choosing between open source and proprietary software

when the price p is positive, the “P program” line shifts downward and increases: fewer users purchase the proprietary program and more purchase the open source program. Therefore the developer of the proprietary software faces a trade-off between increasing his profit per unit sold, which is equal to the price, and increasing the number of these units. This is represented graphically on the figure by the gray rectangle: the profit is proportional to the price, which is equal to the distance between v and vp, multiplied by the proportion of users who choose this program, which is equal to the distance between and 1 on the horizontal axis.6

In appendix 6.1 we show that this leads the developer to choose a price that is proportional to the slope of the benefit lines: the more the users are attached to their preferred program, the higher the price the developer can charge without losing too many clients. This increase in price decreases the number of buyers. In the special case we consider, where the allocation of taste parameters is uniform, these two effects cancel each other out and the proprietary software firm sets the optimal price at 34. At this price 25 percent of consumers buy the proprietary program and the other 75 buy open source. However, recall that the socially efficient allocation would have the market split equally between open source and proprietary software. Thus the market generates overuse of open source software.

(p.170) Schmidt and Schnitzer use this model to highlight this inefficiency in the relative use of open source and proprietary software. Consider the user with taste parameter t = 2/3. If the two programs were sold at a price equal to marginal cost, namely at a price equal to zero, this consumer would choose to buy the proprietary software. However, because he must pay for the proprietary software, he chooses open source software and ends up using the program he likes less, despite the fact that the costs of production are the same. To put it in other terms, because the proprietary software developer is extracting profits by charging a higher price than the open source community, its product is not utilized enough. This implies that policies that would extend the use of open source software will, at least in the simple version of the model, decrease social welfare.7

To summarize the essential elements: in this model, each consumer buys either an open source or proprietary program. Consumers have different tastes for the two types of programs, which can be interpreted as the switching and other costs associated with using that software (other than the initial purchase price). The consumers for whom these other costs are relatively low (a “taste for open source”) adopt open source, which is available at a price of zero, while users for whom these other costs are high prefer to pay the price for proprietary software. The division of consumers depends on the price set by the producer of proprietary software. If the price of both proprietary and open source software were equal to the marginal cost of production (here assumed to be zero), the model generates an equal division of the market. This is the socially efficient allocation of consumers in this framework. But because proprietary software is priced above marginal (p.171) cost, the equilibrium involves greater use of open source than this efficient outcome would dictate.

The conclusion that governments should try to extend the use of proprietary software might seem paradoxical, perhaps even unwarranted and unfair. After all, in the model it is proprietary software that is, from a social welfare point of view, mispriced, with a price above the marginal cost of production. Yet we are drawing the policy conclusion that government should, in some sense, reward it for this mispric-ing by facilitating its use: for example, it may be that government policy should encourage the use of Microsoft Office because it is sold at a positive price, whereas Open Office is distributed at no cost. As we have already mentioned, and will discuss in more detail below, part of the unease stems from the fact that the model does not include important aspects of reality arising from the supply side that might counterbalance these effects.

Supply Side Arguments

While most of the formal economic literature focuses on the demand side of the market, many of the arguments put forth by proponents of government intervention in favor of open source software rely on supply side arguments. It is often claimed that the development process for open source software is more efficient, and that some form of market imperfection hinders its development. It is these arguments that we will review now. We pay special attention to developing countries, since many authors have argued that open source software is especially well adapted to these countries. In this section, we review the reasoning behind the advocacy of proactive governments in favor of open source software. In later sections, we will discuss specific ways in which governments can intervene and the advisability of such policies.

Local Content Argument

One of the main supply side arguments used by advocates of government support for open source is that it is stimulates greater use of local resources than proprietary software. The argument runs as follows: even if the total cost of ownership of open source and proprietary software were similar, open source software requires more complementary support services (in fact, there is only weak evidence for this fact in our data on the cost components of TCO analysis; see table 5.3 in chapter 5). The use of labor for support (p.172) services contributes to local employment and skill acquisition in the software sector. On this account, proponents argue, open source development should be promoted. In addition proprietary software is typically imported, and it is better to generate local information technology employment rather than draw on foreign firms. It is also argued that such additional skilled programmers make a net contribution to future economic growth.

This type of reasoning is well illustrated by the following statement of the Chief Information Officer of South Africa’s State Information and Technology Agency:

Adopting open source software would boost the local software industry.… Most companies that supply open source software applications are local companies. Money spent on open source software would most likely be kept within the South African economy, as opposed to money spent on proprietary software that goes to foreign companies.8

Similar sentiments are found in pronouncements by the Malaysian Minister of Energy, Communications and Multimedia, who stated at the 2003 World Summit of the Information Society:

As an option to reduce dependency, the idea of using open source software needs to be explored and evaluated. Besides cost competitiveness, the use of open source software can also complement efforts in capacity building and development of local content in line with our commitment to cultural diversity.9

These views are not limited to policy makers in developing countries. Similar arguments have been expressed by the United Nations, the German Foreign Minister, and representatives of other industrialized countries.10

These arguments rely on the assumption that the prices for labor and foreign exchange are not set properly. When prices of these inputs are market based, they adjust so as to reflect the social cost of the resources in the absence of serious externalities. Given two goods of equal quality, (p.173) it is not only privately but also socially advantageous to choose the cheapest. For our purposes this implies that there is no justification for preferring one type of software over another on the basis of the amount or mix of inputs that go into producing them, including the extent of “local content.” This applies to labor and foreign exchange, as to other inputs, and it applies both to decisions by private firms and governments.

A simple example may help illustrate this important, but often neglected, point. Consider two alternative software projects of equal quality. The proprietary project has a total cost of $500,000. The open source project costs $480,000 up front but uses four more developers than the proprietary project. If the market wage of a developer is $15K, then the total cost of the open source project is $540,000. If the government ignores the $60,000 required to pay the four extra developers—on the basis of the argument that these funds support local employment—the open source project looks like the cheaper option. That line of reasoning, however, ignores the value of the production of the four developers in the next-best alternative employment. If labor markets are working properly, this “opportunity cost” is given by their wages of $60,000. Properly accounting for the value of the extra human capital used in the open source project makes it more, not less, expensive than proprietary software, by $40,000. Choosing the open source project would be justified only if its up-front cost was less than $440,000. If quality is the same, not only profit-maximizing firms but also governments should choose the least expensive project after taking account of the opportunity cost of any additional developer time.

In reality, of course, there are imperfections in labor markets, persistent unemployment being their clearest manifestation. In the example above, if the four extra developers needed for the open source project were otherwise going to be unemployed for a year, then choosing the open source project might make sense. However, unemployment among skilled workers indicates problems with matching the right person with the right job, the volatile nature of demand for information technology and other labor market distortions. A policy preference for more labor-intensive software is a blunt and indirect instrument for addressing these problems. It is hard to imagine that additional demand for developers stemming from government software purchases will somehow overcome these labor market imperfections. Indeed experience has shown that distortions in the economy should be (p.174) corrected as directly as possible rather than through indirect means whose side effects are extremely difficult to predict.

Furthermore a strong case can be made that developers’ skills are a relatively scarce resource both in emerging and developed economies. There is clear evidence of the high demand for these skills, as registered in the relative wages we observe. In a sample of nine countries for which we have information, the average ratio of the salary of a “software engineer/developer/programmer” to the average wage in the country is 5.85, with a low of 1.20 in Singapore and a high of 16.91 in Thailand.11 The wages of developers in these economies has been bid up because their services are in high demand, not because they are sitting around waiting for something to do. Their talents should be directed to high-value endeavors, not to make-work projects.

The argument in favor of open source software, based on the fact that much proprietary software is imported, relies on similar reasoning. If the exchange rate is set correctly, it represents the relative value of domestic and foreign goods. Returning to our example above, suppose that the proprietary software is imported at a cost of $500,000. The open source software requires imports of goods and services valued at $480,000 and four local developers. Thus the open source project requires $20,000 less in imports. But, if the local annual wage is 30,000 pesos and the exchange rate is two pesos per dollar, then the time of the four developers for a year is valued at $60,000 at the current exchange rate. It is socially inefficient to use $60,000 of developer time in order to save $20,000 in imported inputs. Favoring local production distorts the markets in an inefficient fashion in the same way as an import tariff.

Common Input (Platform) Argument

For a long time governments have subsidized the development of software tools that they felt would not be commercially viable but would be useful to a large community. For instance, the development in the early 1980s of the widely used scientific typesetting software TeX, by Donald Knuth was supported by both the National Science Foundation and the Office of Naval Research (see Knuth 1984). Of course, such software is a public good, akin to a scientific discovery, and traditional economic theory tells us that it (p.175) should be supported with public funds. However, the implementation of such support is complex and risky, and the aim of this section is to examine how government can organize it.

To do this, we build on the analysis of Camara and Fonseca (2007) and Camara et al. (2008), who examine the development of open source projects in developing countries. They argue that there is room for targeted government subsidies towards “low-shared conceptualization, high-modularity” open source projects. This term refers to projects with a high degree of innovation, usually with no proprietary counterpart, a relatively simple software kernel, and a high degree of innovation at the periphery. In simple economic parlance, these are programs that generate strong externalities. Camara and Fonseca illustrate their more general analysis with a case study from Brazil. Since 2000 the Brazilian government has been funding a large-scale open source geographical information system (GIS) project, TerraLib, which is an open source library for GIS and associated applications. The project was developed by two research groups, at the cost of more than 50 person-years of training, and “aims to offer functionalities for spatio-temporal data handling that are not available in any commercial or open source GIS software.” Eventually the program was put into a format so that it could be used by other parties. The Brazilian government has guaranteed its long-term support, and INPE, the Brazilian National Institute for Space Research, “provides capacity building for developers, and supports service companies that use the software.” By mid-2007 approximately ten service providers used TerraLib in commercial applications, constituting 10 percent of the Brazilian market.

There are strong theoretical arguments for such a policy: there are clear economies of scale in having the basic software developed only once, and distributing such a program at marginal cost (which is close to zero) is what classical economic theory would recommend. However, the practical implementation of such policies is much more difficult. In the absence of price signals, it is difficult for governments to do the appropriate cost–benefit analysis before subsidizing such projects, and the risk of undue political influence is large. In the best case, some firms might want the government to subsidize their products, even when the cost to society is higher than the benefits. In the worst case, firms lobby so that they are put in charge of developing a product that has very little use to anyone.

In any case, such a policy is not necessarily a subsidy in favor of open source software if the infrastructure is not restricted in its subsequent (p.176) use. As in the Brazilian case the “periphery” can be composed of proprietary as well as open source programs, and it is the sponsors of these peripheral programs who are the ultimate beneficiaries of the subsidies.12 To ensure that the firms in the periphery could indeed use the program, TerraLib has been released under the LPGL license, which allows the creation of proprietary applications.

A similar argument arises with respect to the appropriate software license for such “common inputs (platforms).” There are many possible alternative licenses that could be used, both proprietary and open source. However, open source licenses may have the benefit of familiarity for users and lower transaction costs. This line of argument has been made for the use of open source licenses for software developed with the collaborative support of several governments. For instance, Steven Chu, the US Energy Secretary, has argued that cooperation between developed and industrializing countries is indispensable for improving the technology to design more energy-efficient buildings. He advocated that this be done through open source software so that the “intellectual property is co-owned, co-developed, free to be used by each country” (see Mackenzie 2009).

While it may seem natural that these “common inputs” software should be distributed under an open source license, proprietary licenses could also be adopted. Governments could own the copyright (or patent), and license the program under commercial terms with special dispensation given to users whom it deems worthwhile—in particular, national users. However, if the costs of implementing such a licensing policy are high enough, it may make sense to use an open source license. Even in this case there is a legitimate debate on which type of open source license should be used. TerraLib is distributed under the LPGL license: as a consequence it can be used in conjunction with proprietary programs, but any change to the program itself falls in the public domain. One can imagine that a BSD-type license would be more suitable for some programs, especially when substantial private incentives for development are needed and when the dangers of “forking” are limited.13

(p.177) Twin Roles of Government: Procurement and Standards

In the last section we reviewed some of the arguments put forward in favor of government support for open source software. In this section and the next, we review some of the policies through which governments can implement this support and, more generally, influence the software industry. We will find it convenient to group these policies in two categories: procurement and regulation. First, governments are very large purchasers of software, when we aggregate the purchases of all its departments and its agencies, so their procurement rules can have industry-wide implications. We study these rules in the next section. In addition to their procurement role, however, governments can powerfully influence the development trajectory and use of software through the laws and regulations they adopt. We study this important aspect of policy in a subsequent section. In both cases we focus primarily on aspects that influence the balance between open source and proprietary software, rather than arguments for general support to information technology. Before doing so, in this section we present survey evidence on the importance of the government as a purchaser of software, and then discuss two different strategies government can adopt in its procurement role.

Government as Purchaser of Software

Most observers would agree that the government sector is an important purchaser of software. Our survey of software developers allows us to examine this supposition with hard evidence, and to establish whether the importance of government software procurement is similar for open source and proprietary, and between firms of different types. Table 6.3 summarizes the survey data on the percentage of revenues for software firms (combining open source and proprietary software) that originate from different types of consumer accounts.

While corporate sales are the dominant source of revenue—accounting for 60 percent in the overall sample—governments account for 21 percent, about equally divided among the federal, local, and municipal governments. Government purchases are a less important source of revenue for small companies, but for all three size categories, government is a significant client. The separate revenue breakdowns for open source and proprietary software are very similar to each other (not shown, for brevity). One noteworthy point is that the client mix is not significantly different for domestic firms and foreign subsidiaries, (p.178)

Table 6.3 Sources of revenue for software firms (percentage of total revenues)

Government

Corporate

Subtotal

Federal

State

Municipal

Individuals

Aggregate

61.3

20.8

6.2

7.0

7.6

17.9

(1.1)

(0.6)

(0.6)

(0.6)

(0.9)

Size

Small

63.4

18.2

5.2

5.9

7.1

18.4

(1.4)

(0.6)

(0.7)

(0.7)

(1.1)

Medium

57.8

24.9

7.9

8.7

8.3

17.3

(2.0)

(1.1)

(1.1)

(1.1)

(1.5)

Large

58.3

26.8

8.0

10.1

8.7

14.9

(5.3)

(2.9)

(3.2)

(2.7)

(3.8)

Ownership

Domestic

60.9

20.7

6.3

6.7

7.7

18.4

(1.2)

(0.6)

(0.6)

(0.6)

(0.9)

Foreign

64.4

22.1

5.6

9.5

7.0

13.5

Subsidiary

(3.3)

(1.6)

(2.0)

(1.8)

(2.4)

Note: Multinomial standard errors are in parentheses. These are computed as √ p(1 – p)/n, where p is the reported proportion and n is the sample size.

and this holds both for open source and proprietary software. There seems to be no national bias as far as government software purchases are concerned, at least when we average across the countries in our survey.

Finally, inspection of the individual country results (not reported, for brevity) confirms that the public sector is an important software client in almost all of the countries in our survey, but its role varies considerably. The three countries where the government accounts for least are (in percent) Turkey (5.7), India (8.1), and Singapore (9.5); the top countries are Thailand (39.3), Israel (37.2), and Kenya (35.2). Clearly, the government’s software procurement impact is not related in any simple way to the level of economic development.

Because governments are large consumers of software, whether or not they intend to do so, their procurement policies materially influence the sector. In the next sections we identify the issues at stake and analyze how economics can help shape appropriate policies.

Two Procurement Strategies for Government

Government is the largest single buyer, but there are also many smaller corporate and individual consumers in the software market. As a starting (p.179)

Table 6.4 Adaptive play

Others

Big player

A

B

A

(9, 8)

(11, 5)

B

(8, 4)

(10, 6)

point, we need to review how “big players” like the government can use their power. To do this, we follow the game theory literature in distinguishing between two basic types of strategies big players can adopt: adaptation and leadership strategies.

When a big player uses an adaptation strategy, it makes its decisions so as to maximize its own payoff (whatever form that takes), assuming that its decision will not affect those of the other smaller players. Of course, its choices affect the other players, but the big player does not take this into account when designing its own strategy—it simply adapts to the environment; the other players do the same thing. An example of an adaptive strategy is when the government makes its procurement decisions strictly on the basis of a TCO analysis, without consideration for how that decision might shape the decisions of smaller consumers. In game theory adaptation strategies are referred to as “Nash strategies,” and we will do so here.

We can illustrate this mutual dependence with a simple software example with two players, one “big” and the other not. Each must choose between two programs, A and B. The game is represented in table 6.4.

In each cell of the table, the first number represents the benefit of the “big player” and the second the benefit of the other players. For instance, if the big player chooses program A, while the others choose program B, the benefit of the big player is 11 and the benefit of the others is 5. Given the (admittedly arbitrary) numbers that we have chosen for our example, the outcome (“Nash equilibrium”) when the big player adapts to the behavior of the others is (A, A). If the big player deviated by choosing program B, its benefit would decrease from 9 to 8, while if the others deviated from A to B, their benefit would decrease from 8 to 5. It is easy to see that no other cell has the same property.

We next describe the leadership strategy. In this case the big player takes into account its influence on the other players. When the big (p.180)

Table 6.5 Leadership play

Others

Big player

A

B

A

(9, 8)

(11, 5)

B

(8, 4)

(10, 6)

player acts in this way, it computes the way its behavior will affect the strategy of the others in making its own decision. This is referred to as a “Stackelberg strategy.” In the numerical example given above, this kind of behavior yields an outcome where all the players choose software B as in table 6.5.

Given that the big player has committed itself to software B, the others are better off also choosing B (they take the big player’s strategy as given). This yields a benefit of 10 for the big player. If it had committed itself to choosing A, the others would also have chosen software A, and its benefit would have been only 9.

Economists often interpret the difference between these two types of strategies as a matter of which player “moves first.” In the case of adaptation strategies, we say that the players choose their strategies simultaneously, while in the case of leadership strategies the “big player” is the one who plays first. Note that this is largely metaphorical—governments and other users typically buy software at the same time. The real distinction here is that the leadership strategy occurs when one of the players can pre-commit to a particular behavior, which we normally associate with a big player.

Of course, “the” government does not typically make purchases—procurement is done through its agencies. But the government is a leader with respect to its agencies: it sets the rules that govern their procurement (objectives and trade-offs between cost, quality, security, etc.), and in this capacity it can instruct them to use either an adaptation or a leadership strategy.

If the agency has the same preferences and capacities as the central government, the fact that the policy implementation is delegated to the agency creates no difficulty. However, in general, preferences and capacities are not the same, and this can change the preferred strategy. To illustrate this, let us modify the numerical example above by assuming that the “big player” is the agency. Suppose that the government is what economists call “benevolent,” in that its objective is to (p.181)

Table 6.6 Is leadership a desirable policy?

Other players

Agency

A

B

A

(9, 8, 17)

(11, 5, 16)

B

(8, 4, 12)

(10, 6, 16)

maximize the benefits of society, given here by the sum of the benefits of the government agency and other consumers.

Table 6.6 represents the game. The benefit of the government is represented by a third number (underlined) in each cell. If the government instructs the agency to use an adaptation strategy, it will do so taking into account only its own payoff. Following our earlier analysis, this leads to the (A, A) outcome. By contrast, if the government instructs the agency to use a leadership strategy, the (B, B) outcome will occur. In this example, the government is better off instructing its agencies not to use their potential power to commit.

In reality the situation is much more complicated, but it is generally true that the government sets the long-term objectives that are embedded in formal policy statements. As a first (and sometimes loose) approximation, we can think that these policies are chosen in a more or less open way, after public debate, and reflect the values of societies as a whole. On the other hand, the decision taken by the agencies will be done faster, with more awareness of deadlines and ease of administration, and it is likely to be subject to more lobbying activities.

As the example above shows, when the preferences of the agency and the government are not perfectly aligned, it can make sense to restrict the behavior of the agency to respond to the environment and not to try to shape it. However, in other circumstances it may be preferable for agencies to adopt a leadership strategy. An example of a leadership strategy would be for a government agency to announce, and commit to, a preferred programming language for its purchases of customized software. This is a way of ensuring interoperability and may make sense where that is considered to be a critical feature. This is the approach adopted by the US Department of Defense for the Ada programming language.14 At the same time it may be preferable for a (p.182) government agency to act as a Nash/adaptive player when it chooses standards for transmitting information to outside parties, where intra-agency interoperability is not an important requirement. There is no hard–and-fast rule about this choice between adaptation and leadership strategies; governments need to make this assessment on a case-by-case basis.

In the next sections we use this simple analytical framework to examine the two key roles of government: software procurement and the choice of standards.

Government as Software Purchaser: TCO Analysis and Beyond

As we showed in chapter 5, there are strong indications that governments are not doing an adequate job rationalizing their purchasing decisions. Governments, which are very large buyers, are less likely to do a TCO analysis before adopting software than even medium-sized firms. This may not be so surprising—the public sector is less subject to competitive pressure or effective internal incentives than private sector firms, and thus less likely to base their decision making on efficiency criteria, and public accounting and management systems may not be designed in a way that encourages efficient allocation of expenditures. Still it surely ought to be a source of concern.

In what follows we discuss some aspects of the purchasing policies of governments. We begin with a quintessential example of adaptive strategies: how should government agencies evaluate the different software options in the market in their adoption decisions? We then turn to examples of leadership strategies, where the government takes advantage of its size and power of commitment to compensate for imperfections in the software markets.

Governments Should Use TCO Analysis

While weak efficiency incentives and monitoring may play a role, part of the reason government agencies do less TCO analysis than most large firms may be due to their not having access to a proper methodology for choosing between different programs. What is needed is a set of formal guidelines for government agencies to assess the full range of cost and benefits of different software choices. While there is undoubtedly going to be variation across agencies in detail and implementation, to ensure coherence and consistency of these rules, the central (p.183) government needs to take a more active role in developing the evaluation framework. Independent consultants can help agencies evaluate specific software products, but it is important to have a general framework specially adapted to the public sector of each country.

This is not the place to develop such an evaluation framework in any detail, but we would like to discuss some aspects. From an economic perspective the best approach is to identify the key performance characteristics of the software (speed, durability, adaptability, etc.), attach a monetary value to each of these features, add them up to get an estimate of total value, and then adopt the software with the largest difference between this value and the full cost of the software (in practice, measuring the quality of the software in monetary terms can be very difficult, and a “point” system might provide a reasonable second best alternative.) The cost dimension should be measured by the TCO, as discussed at length in chapter 5. Perhaps more than for the other dimensions of software evaluation, there is a need to have widely accepted (“standard”) TCO evaluation frameworks to enable public institutions in both developed and emerging economies to assess the full costs of the software more effectively before adoption.15 Especially for large projects any evaluation of costs will be fraught with uncertainty, and some analysis of the impact of alternative (uncertain) scenarios should be included in the evaluation.

While certainly challenging, this task is not insuperable. Even if imperfect, a rigorous methodology, based on explicit criteria, would go a long way toward addressing the weaknesses of public decision making, in particular, the biases introduced by public accounting and management practices.16 Such a methodology would compel decision makers to make the reasons for their choices between different programs more explicit. It would also help alleviate the widespread dissatisfaction among software vendors about the ways in which public purchasing is conducted, with proprietary software firms complaining that the use of open source software is often politically motivated, and (p.184) open source proponents complaining that the greater marketing clout of proprietary firms biases evaluations.17

The cost analysis should be based on the best offers obtained directly from different suppliers. Vendors adjust their price both to competition and to the “willingness to pay” of customers. This customization of price to the reality of the particular market is a normal part of business; economists refer to it as price discrimination. It is a well-known principle of economic theory that in industries with large fixed costs such as the software industry, such price discrimination is both privately and socially beneficial under very general conditions.18 In the case of software, price-discriminating behavior by software firms will normally induce lower software prices in poorer countries.19 In the absence of such price discrimination, one would expect open source software, available at a low up-front cost, to be comparatively more attractive to developing countries than to developed countries. In the presence of price discrimination, this comparative attractiveness will depend on how aggressively proprietary software firms differentiate prices across regions.

When government agencies purchase customized software, the total cost of ownership can be influenced by the form of the software license.20 An open source license (e.g., GPL) guarantees that the agency will be able to benefit from subsequent improvements made by the (p.185) open source community, including perhaps other governments. On the other hand, a developer might accept a lower price for its proprietary software if it owns the copyright or patent and expects to be able to sell the program to other customers (other government entities, domestic or foreign). Other considerations might also be relevant, such as the risk of lock-in and the future bargaining power of the developer (though the evidence in chapter 5 indicates that users do not assess these risks very differently for open source and proprietary software).21

Making purchasing decisions on a neutral evaluation procedure based on explicit criteria, and at the same time imposing open specification standards (see below), will put important competitive pressure on both open source and proprietary software providers. And opening the competition to as many suppliers as possible enhances the bargaining position of governments.

Compensating for Imperfection in the Software Market: Favoring Open Source Software?

As we argued in the previous section, in making its software decisions, it is often sensible for government to take the behavior of the rest of the society as given—adopting an “adaptive strategy”—rather than aim to shape it. This is essentially what government does when it employs a TCO analysis for making its software purchasing decisions.

However, as we discussed in chapter 2, it is possible for society to become “locked in” to inferior software for historical reasons. Because of network effects and switching costs, consumers may find it attractive to stay with the dominant software, and this can entrench market power. In such cases, although each customer finds it individually rational to continue using the leading software rather than a challenger, users would be collectively better off if they could coordinate on a shift. It might appear that a possible solution to this “coordination failure” is (p.186) for government to announce a changeover to the new software. If government purchases are large enough to affect network externalities, or if it can enforce the change by selection of standards, this would induce customers to switch, with a gain in social welfare.22

In later sections we will discuss the role of government procurement and standard setting as ways to shape the environment. In this section we examine other types of government policy that can affect the software market, and open source in particular.

There are three main types of policies that can be used to intervene in favor of open source software: public provision of information about open source, subsidies, and mandated adoption of open source software (e.g., by government agencies). Economists have made some progress in analyzing whether policies to promote open source software are likely to increase or reduce economic welfare. In this section we discuss a few key papers, to bring out what we consider to be the main lessons for policy (this is not intended as a exhaustive literature review). While these papers are certainly not the last word on the subject, they provide a cautionary lesson about jumping to any quick conclusion about the advisability of such policy measures. Of course, all models are simplifications that abstract from some relevant features of reality, and the policy lessons they deliver always have to be interpreted in light of those limitations. Nonetheless, the models are useful because they help systematize, and discipline, our thinking about these important issues. At the end of this section we highlight some of main limitation of the models, after we have discussed the insights they provide.

The model by Schmidt and Schnitzer (2003), which we discussed in a preceding section, shows that there is overuse of open source software because of distorted pricing (proprietary prices are above marginal production cost). However, in recent work Comino and Manenti (2005) have emphasized that informational imperfections can cut the other way and lead to underutilization of open source. Some consumers may simply be unaware of the availability of open source programs that can meet their needs, and at least some of these uniformed users might choose open source if they knew about it. Comino and Manenti study three alternative policies to address this problem: direct government provision of information to consumers, subsidies for open source use, and government mandates of open source adoption. In each case (p.187) they study how the policy is likely to affect economic welfare. The evaluation of these policies is quite complex, especially in the presence of network externalities, so we will only summarize their policy conclusion and the underlying economic intuition.

We begin with information provision. The main policy conclusion reached by Comino and Manenti is that a policy of information provision generally increases economic welfare (by which we mean consumer and producer surplus). They extend the framework of Schmidt and Schnitzer, introducing imperfect information on the part of consumers by assuming that a certain proportion of users are unaware of the open source alternative. By making these users aware, the policy generates two forms of welfare gains. The first is that some of these users (depending on their “tastes”) end up adopting open source, which generates more benefit for them than the proprietary option they would have selected in the absence of the information. In addition, when consumers have this information, price competition is intensified (consumers know of the alternative to proprietary software). This lowers the price of proprietary software and again increases welfare. Comino and Manenti find that the policy conclusion that information provision improves economic welfare is quite general, but it can be reversed in two circumstances: first, when network externalities are very strong (and thus migration of consumers away from proprietary software raises costs substantially) and, second, when the cost to the government of providing information is too high, compared to the number of consumers reached.23

The second form of policy intervention is direct subsidies (or tax credits). Later in this chapter, we provide evidence from our surveys of fifteen countries that shows that governments provide a variety of incentives for both open source and proprietary software development and use (including direct subsidies and tax credits). But are such incentives justified in terms of economic principles? Are they likely to increase economic welfare? In their study Comino and Manenti also (p.188) analyze the welfare effects of a policy of directly subsidizing open source software. They reach the stark conclusion that this policy always reduces economic welfare. The basic trade-off involved is between the underutilization of open source created by the informational imperfection as against the overuse of open source induced by its being priced too low relative to the socially optimal level. Their particular model produces a clear result—there is net overuse—so an open source subsidy only makes things worse. But, in general, the result could go either way, so we cannot state with certainty that open source subsidies are ill advised. The key message here is that there is a trade-off, and governments need to evaluate it carefully before adopting subsidies.

Finally, we turn to policies that mandate adoption of open source software. This type of government policy has also been examined by Comino and Manenti (2005), who extend the Schmidt–Schnitzer model to study the welfare consequences of a government requirement that a specified proportion of users adopt open source software, even when their individual preferences would be to purchase proprietary software. In this they are thinking of agencies, schools, universities, and publicly owned firms, over whose procurement government has some measure of control. They assume that these entities have exactly the same (distribution of) tastes as the rest of the population. This assumption can be defended on the ground that the government does not have the means to know the value of the taste parameter for each of these users, so it cannot make the policy contingent on that parameter. In this setting Camino and Manenti show that the policy of mandating adoption of open source unambiguously decreases social welfare. This result is not particularly surprising under these assumptions, since open source software is already overused due to underpricing, and the mandate exacerbates the distortion.

In their original paper Schmidt and Schnitzer (2003) also studied a government policy of mandated use for public entities. They modify the setting of their model by allowing for a group of “devoted” consumers who always use proprietary software, whatever its price, and a group that always uses open source. These authors study the welfare effects of having the government force some of the consumers devoted to proprietary software to buy open source. Not surprisingly, this policy also reduces social welfare: the policy is similar to that studied by Camino and Manenti, but targets the mandate for open source on users who are, on average, even more averse to using it. These two analyses illustrate the potential costs of a government policy that would require (p.189) agencies to use open source software more than they would think it desirable on the basis of their own TCO analyses.

The important policy lesson we draw from our review of these academic studies is that a policy of providing information to consumers is more likely to improve economic welfare than direct subsidies to open source, and that government-mandated uses of open source software are likely to be damaging. Yet it seems that governments have generally taken the opposite approach, focusing more on incentives and mandates than on information provision to improve consumer choice and facilitate more effective competition between the two modes of software.

Of course, the academic literature in this area is still young and underdeveloped. Despite considerable advances, the modeling efforts have not yet incorporated some important, but challenging, dimensions of the problem. Some features the models omit may weaken the specific policy conclusions, others may strengthen it. There are four main limitations of the models that should be acknowledged:

  • First, they are static models and thus do not capture the complex dynamics of learning effects on the part of both users and developers. While such learning effects are present in both open source and proprietary, there is a presumption that other things being equal, open source generates greater, and more rapid, knowledge spillovers precisely because the code is open. Models that do not incorporate this feature are likely to understate the case for policies that favor open source.

  • The second limitation involves their treatment of network effects in software. These models make no allowance for vendor behavior that can weaken network advantages that one form of software may initially have—in particular, firms with a smaller installed base (network disadvantage) can reduce price to enlarge its demand.24 When this is allowed, the competitive advantage due to network effects can be substantially reduced. This is likely to weaken the case for open source support, since part of their justification is “kick-starting” markets with network effects and overcoming the legacy costs of the existing installed base.

  • (p.190) Third, the existing models treat consumers as choosing either an open source or proprietary program, and software firms as offering one or the other. Yet our analysis in chapters 4 and 5 shows that software users and developer firms typically comingle the two types of software, reflecting the synergies that often exist between them.

  • Finally, it is important to keep in mind that there are “government imperfections” as well as market imperfections. Even when there is the potential for a government policy to improve welfare, this does not ensure that it will. Taking serious account of the welfare costs of policy errors (e.g., choosing the wrong standard) is also urgently needed.

Whether these various considerations will tilt the balance in favor of, or against, government intervention on behalf of open source remains to be seen. Nonetheless, we are skeptical of policies justified by the “coordination failure” argument—that network externalities and switching costs led society to be “locked in” to an inferior outcome over the long run. There is very little concrete evidence for the loss of welfare due to such “coordination failures” in software. A better way to guard against abuse of any entrenched network positions may be for government to maintain a vigilant competition policy in this sector and to set standards that facilitate interoperability among different types of software, and thus intensify competition among them. We take up the important issue of standards in the next section.

Government Policy and Open Standards: Ensuring Competition and Efficient Comingling

Governments are not only some of the largest single purchasers of software and have the same concerns as all large buyers of obtaining the best possible combination of quality and price. They must also ensure interoperability across a wide variety of government departments, between different (federal and subfederal) levels of government and sometimes with agencies in other governments. In addition they have the special concern of ensuring public access to government information services. This may imply something as simple as making sure that laws and regulations are made available on the Web in a way that can be read by the whole population, or something much more complicated like the possibility for firms to participate in online procurement without the cost of buying expensive special software. Of course, private users also want the information they provide to be easily accessible (p.191) and widely distributed. But for governments, the obligation is stronger: they have a fundamental responsibility of ensuring access to information to all the citizens in their countries.

This obligation to provide access to information can be fulfilled by a Nash strategy: the government uses the software and associated technology that are the most likely to reach the greatest number of citizens at the lowest total cost of ownership. But it can also be fulfilled as part of a Stackelberg strategy that tries to encourage society as a whole to use a particular type of information technology. This applies, in particular, to the types of standards governments use in their internal and external communications, and more specifically to their promotion of “open standards.” While such standards can be, and are, used by proprietary software, they are linked in the mind of many proponents to open source software (see Wheeler 2006). In this section we use economic analysis to examine the appropriate role of government in promoting standards. We begin with a short general discussion of standards. After defining them and explaining how the “adaptation” and “leadership” strategies can be used in their choice, we turn to an analysis of “open standards.”

Communications between computers are mediated through the use of standards. For instance, many computers (depending on the operating system) know that files whose extension is .htm or .html are intended to be read through a browser, and the browser “knows” that it should interpret the file according to the HTML “standard.” From an economic perspective, although not in strict computer usage, this naming convention is also a standard. A simple HTML file would read, for instance, as illustrated in the text box. The fact that 〈p〉 opens a paragraph while 〈/p〉 closes it is part of the standard, and all the browsers must be programmed to “know” that.

Assessing Government Policies toward Software

Clearly, the use of standards gives rise to the type of network externalities that we discussed in chapter 2: users prefer to utilize standards that have many other users. For many applications there are competing standards. For example, there are many different standards for (p.192) encoding audio files, and some devices cannot play certain of these files. This limits the transmission of files between music-playing devices and lowers the network externalities that can be enjoyed by the users. It does not necessarily follow that there should be only one standard: different standards may be better adapted to different uses, and society faces a trade-off between taking advantage of network externalities and allowing for standards well adapted to these different uses.

Governments can decide to use a “Nash strategy” and simply choose the standards that have been adopted by the rest of society. For instance, many documents published by government agencies are encoded in the PDF format because most computers are able to interpret PDF files. Much more sophisticated analysis is needed in some circumstances, for instance, when deciding which standards to use for communicating data between government agencies. This is well illustrated by a recent speech by the then European Union Commissioner for Competition Policy, Nellie Kroes:

As purchasers, we need to be smart when we buy technology. We need to be aware of the long-term costs of lock-in: you are often locked-in to subsequent generations of that technology. There can also be spillover effects where you get locked in to other products and services provided by that vendor …. That is just bad purchasing. (Kroes 2008)

And she went on to explain how this could influence the practice of the Commission when purchasing technology:

For all future IT developments and procurement procedures, the Commission shall promote the use of products that support open, well-documented standards. Interoperability is a critical issue for the Commission, and usage of well-established open standards is a key factor to achieve and endorse it.

In these statements, Commissioner Kroes is using the same type of reasoning that any large buyer of technology would use: how do I ensure that my decisions are wise in the long run? This is standard Nashtype reasoning. On the other hand, some commentators argue that governments should take advantage of their size and play a “Stackelberg strategy” in which they try to influence the standards adopted by society as a whole. They can use a number of techniques to do this: for example, favoring one specific standard by ordering communications between government agencies to use this standard or, more aggressively, announcing that communications to and from government agencies use specific standards. We also find traces of this strategy in Commissioner Kroes’s speech:

(p.193) No citizen or company should be forced or encouraged to choose a closed technology over an open one, through a government having made that choice first.

What is the source of this concern? She is clearly worried about the possibility that the government might choose the wrong “Stackelberg strategy” and lock users into suboptimal standards.

These quotations are representative of the important recent debate about the use of “open standards,” which is, at least according to some commentators, linked to the issue of choice between open source and proprietary software. In what follows we begin by discussing the definition of “open standards”—which turns out be quite a difficult task—and then move to discuss the links to the debate over open source.

Open Standards

In chapter 5 we showed that switching and software interoperability costs are important elements of the total cost of ownership for consumers, especially for open source users. At the same time both users and developers register strong preferences for a regulatory regime that allows them the freedom to choose between open source and proprietary software. In order to ensure that this freedom is meaningful, enabling both users and developers to comingle as they find most appropriate, governments need to maintain open standards. They are the key to lowering switching and interoperability costs, and thereby intensifying competition between open source and proprietary software.

Over the last few years the definition of open standards used by most authors has changed. In 2005 Wikipedia defined them as follows: “[They] are publicly available specifications for achieving a specific task.”25 According to this definition, a standard was open as soon as its description was available for use by anyone. By 2009, the definition became more restrictive:

The term “open” is usually restricted to royalty-free technologies while the term “standard” is sometimes restricted to technologies approved by formalized committees that are open to participation by all interested parties and operate on a consensus basis.

Notice the two main requirements in this newer definition: open standards should be royalty free, and they should be managed by a (p.194) Standard Setting Organization (SSO) where decisions are taken under some form of consensus rules.26

This book is not the place to do a complete analysis of this problem, but we need to examine some aspects that affect the use of open source software. In order to clarify discussion, we adopt the distinction between “open specification” formats, which are publicly available, and “open standards,” which are maintained by a standards body.27 We will use the new term “open specification standards” to designate standards whose use is open to everyone under “reasonable” conditions, as distinct from open standards, which must be royalty free and maintained by a standard setting organization.

It is important to understand that open standards can be, and are, respected both by proprietary and open source products.28 Therefore, by itself, a commitment to open standards provides no basis for a preference for one type of software. For example, the Internet and the World Wide Web were the result of the efforts of government and academic institutions, for-profit companies and individuals who developed the standards (e.g., IP, TCP, DNS, PPP, HTTP, HTML, XML, SMTP, and POP) on which the Internet is based. This was done through standard-setting organizations such as the IETF and W3C. Many implementations of these technologies were developed both in open source and proprietary software and are distributed under a wide variety of open source and proprietary licenses.

On the other hand, some standards embed proprietary technology, and the owners of the technology demand compensation. In principle, one could imagine open source software that would be compatible with the payment of licenses to such owners. For example, each user could be responsible for paying them. In practice, however, the fact that software is easily copied would make enforcement of this requirement very difficult. As a consequence standards that embed proprietary technology are typically only implemented in proprietary software.

Users are concerned about making a commitment to a standard that requires licensing of technology for its implementation. The fear is (p.195) that once the standard is widely used, the owner of the relevant intellectual property can try to exploit the lock-in of users by raising its licensing fee. To circumvent this problem, SSOs often require their participants to divulge any intellectual property they own that they believe bear on the standard, and to commit to not overcharging for the use of the intellectual property. This last requirement is usually referred to as a commitment to RAND (reasonable and nondiscriminatory) or FRAND (fair, reasonable and nondiscriminatory) licensing terms.29

The most important features of standards are that they can be used by anyone and are subject, at most, to RAND license fees for any intellectual property they contain. In principle, the use of open specification standards could ensure that the general public will have access to the information provided by the government and that different government agencies can communicate with each other. But for this to happen, the standard must be implemented in software that users can afford in practice. Insofar as possible, government agencies should choose standards that are widely used and that can be implemented in (p.196) reasonably priced software (this way they participate in the creation of network externalities). A reasonable price might be zero when the information is to be accessible to everyone (as in the case of tax documents), but it could be higher when firms require access to specialized information. Looking to the future, governments need to ensure that the specifications of the standard remain open in the long run and are modernized as technology improves.

However, open source advocates emphasize that any type of licensing of technology creates major difficulties for open source software—the fact that licensing terms are reasonable has nothing to do with the issue. For example, the Open Source Initiative has developed “Open Standards Requirements for Software.”30 The objective of these “requirements,” which they believe should be part of any formal definition of open standards, is to ensure that any such standard “not prohibit conforming implementations in open source software.” This implies that “all patents essential to implementation of the standard must [either] be licensed under royalty-free terms for unrestricted use, or be covered by a promise of nonassertion when practiced by open source software.”31

There is little doubt that standards that do not meet a rather strict definition of openness, including no fees, create difficult issues for open source software. But public policy regarding the intellectual property in standards has another concern: innovation in standards is important, and firms that are investing in the development of new technologies should expect to be rewarded. A policy that favored standards with no licensing fees, simply in order to level the playing field for open source software, would undoubtedly be detrimental to innovation.

In practice, both patent policy and the functioning of standard-setting organizations are very imperfect, and some of their failings are certainly more costly to open source software. To take just one example, it is likely that weak patents (whose validity is unlikely to be upheld by courts, if tested) create more difficulties for open source software than for proprietary software, where the developer can at least threaten to defend against their enforcement. How the system should (p.197) be reformed to limit these distortions raises a host of very difficult issues that are far from resolved. We will focus on only one of them: should the government try to compensate for these distortions by requiring that every standard used by its agencies is “open” in the sense which the Open Source Initiative gives to the term?

Adopting such a policy would be an example of a Stackelberg (leadership) strategy: the government is exploiting its size and ability to commit to a policy in order to change the nature of the market. We have the same reluctance to endorse Stackelberg strategies for government policy toward standards as we have for using government procurement to compensate for imperfections in the software market. The design and evaluation of such policies requires very sophisticated analysis of the consequences of such actions, which is especially difficult in the technologically dynamic settings under consideration. Furthermore the politics of standards setting are complicated and perilous—endless discussions can arise over the fact that this or that SSO is really driven by consensus.32 We do not believe that government procurement policy or standard-setting efforts should introduce industrial policy through stealth, and there is a real danger of this occurring. Nonetheless, we fully recognize that the issue is very complex and requires further analysis. Easy answers are not on the horizon.

Government Incentives and Promotion of Open Source

The government influences the development of the software industry in many ways—most important, as purchaser of software, as regulator, and through the provision of incentives. We have discussed the arguments for and against proactive government intervention in the development and use of software through procurement and regulation.33 In this final analysis we present evidence on the provision of software incentives by governments.

How Common are Software Incentives?

Governments intervene in the development and adoption of software through various incentives. Our surveys of developers and users (p.198)

Table 6.7 Incentives for software development and adoption (percentage of developers/users receiving incentives)

Developers: proprietary

Developers: open source

Users: proprietary

Users: open source

Aggregate

12.2

7.4

12.2

8.9

(0.8)

(0.8)

(0.7)

(0.6)

Size

Small

9.7

5.7

8.1

6.9

(0.9)

(0.9)

(0.9)

(0.9)

Medium

16.3

10.0

17.7

12.0

(1.5)

(1.6)

(2.2)

(1.9)

Large

15.9

7.7

10.0

6.8

(4.0)

(3.7)

(2.0)

(0.6)

Ownership

Domestic

11.8

6.5

7.8

5.3

(0.8)

(0.9)

(1.2)

(1.0)

Foreign

14.9

13.2

13.8

7.0

(2.6)

(3.1)

(4.1)

(3.0)

Government

27.2

19.3

(3.3)

(2.9)

Sector

Services

32.8

22.0

(4.3)

(3.8)

High-tech manufacturing

8.4

9.1

(1.4)

(1.4)

Low-tech manufacturing

8.5

4.8

(1.4)

(1.1)

Wholesale/retail trade

10.6

3.3

(1.5)

(0.9)

Note: Multinomial standard errors are in parentheses. These are computed as √ p(1 – p)/n, where p is the reported proportion and n is the sample size.

provide detailed information on the extent and form of government incentives for proprietary and open source software development and adoption. The survey questions ask specifically about software-related incentives, distinguishing them from general investment incentives.

Although the public debate seems more focused on government policies to promote the development and adoption of open source software, the survey evidence indicates that both proprietary and open source software benefit from incentives of various forms. Table 6.7 shows that, averaging across the fifteen countries in our survey, 12.2 percent of firms developing proprietary software say that they receive (p.199) some form of incentives, as compared with 7.4 percent for open source developers. These figures are not statistically different from each other, so we can say that the frequency of incentives is similar for the two types of software, at least when we average across all countries in the sample. The frequency of incentives for software adoption (given in the last two columns of the table) is nearly identical to those for software development.

The likelihood that firms and users receive incentives depends on their characteristics. This could be due to provisions in government policies that target specific types of firms or users, or to different takeup rates among potential recipients. With the available information we cannot distinguish between these hypotheses. In any event, we find that small firms and users are less likely to receive incentives for proprietary (but not open source) software development and adoption than larger entities. Regarding ownership, there is no statistically significant difference between domestic firms and foreign subsidiaries, but we find that government agencies are more than three times as likely as private firms to receive some form of incentives for software adoption.

Incentives for software development or adoption can take a variety of forms, including monetary incentives such as direct subsidies and tax credits. But they can also be more indirect, such as when governments attach specific software conditions to procurement decisions, regulatory policy and even informal pressure and “moral suasion.” Our survey provides information on the relative importance of these different forms of incentives for proprietary and open source. As table 6.8 shows, the sources of developer incentives are broadly similar for proprietary and open source software, the main difference being that indirect subsidies through procurement are more important (and tax credits less important) for open source than for proprietary software. Nearly a third of developers rank procurement conditions as the leading form of incentives. For users, the dominant forms of incentives for proprietary software are direct subsidies and tax breaks. For open source, the ordering of these two is reversed, with tax credits being more important than direct subsidies. For both types of software, informal and regulatory channels are much less important as incentives for software users than they are for developers, with only 13 percent giving them top rank for open source and 2 percent for proprietary.

As the survey does not provide any information about the magnitude of these incentives, we cannot evaluate whether the current (p.200)

Table 6.8 Form of incentives for proprietary and open source software adoption (percentage of firms giving top rank)

Developers: proprietary

Developers: open source

Users: proprietary

Users: open source

Direct subsidy

34.7

30.4

43.2

20.6

(2.2)

(5.1)

(3.0)

(4.9)

Tax credit

37.6

29.1

25.3

41.2

(3.3)

(5.1)

(2.7)

(6.0)

Procurement contract conditions

22.1

32.9

28.8

25.0

(2.8)

(5.3)

(2.8)

(5.3)

Regulation and informal

5.6

7.6

2.7

13.2

(1.6)

(3.0)

(1.0)

(4.1)

Note: Multinomial standard errors are in parentheses. These are computed as √p(1 – p)/n, where p is the reported proportion and n is the sample size.

incentive regime is neutral between the two types of software. But it is worth asking what would constitute a neutral subsidy scheme. To do this, we draw on the detailed survey evidence on the composition of the total cost of ownership, which we presented in chapter 5. Even if the subsidy rates were the same for open source and proprietary software, such incentives would not be neutral. The initial price of software is only one component of the total cost of ownership, though a larger proportion for proprietary software. Subsidies to the other cost elements, such as switching and interoperability costs, are harder to implement because of difficulties in monitoring the true expense incurred by the user. This implies that a uniform rate of subsidy for both types of software would, in practice, favor proprietary software where price is a larger component of the TCO. Designing a truly “neutral” subsidy policy would involve setting different rates if it is only applied to the purchase price of the software. The information on the cost structure of open source and proprietary software, presented in chapter 5, might be helpful in calibrating appropriate, neutral subsidy rates if policy makers choose to support software in general in this way.

Conclusion

In this chapter we provided an economic analysis of some key aspects of government policy in the software sector. In particular, we focused on a variety of arguments made by proponents of open source for why government policy should promote it. We hope to have shown how (p.201) economic principles can help to assess the validity of these arguments and to formulate good public policy. In addition, drawing on our unique surveys in fifteen countries, we provided new evidence on the regulatory regimes preferred by software developers and users, and on the extent to which governments provide incentives of various forms for the development and adoption of open source and proprietary software.

We would like to highlight four main conclusions that emerge from the analysis:

  • First, our survey evidence shows clearly that the dominant preference among software developers and users is for a regulatory regime that allows them complete freedom to choose between open source and proprietary software, rather than one that either requires or favors one or the other. This finding holds in each of the fifteen countries we surveyed, and for software firms and users with different characteristics. The pervasive preference for an unrestricted regulatory regime certainly provides, at a minimum, a prima facie basis for thinking that government policy should be neutral between open source and proprietary software. The heavy burden of proof should be on those who advocate policies that favor preferential treatment of either form of software.

  • Second, in their role as a large buyer of software, government can influence the choices of private-sector consumers through both network and demonstration (information) effects. Whether they should exercise such leadership strategies in their procurement policies is far from clear, however, and we argue that this depends very much on the specific context. In cases where an adaptive strategy is warranted, governments should base their purchases on evaluations of the total cost of ownership of the software alternatives in the market, on the basis of their individual quality and costs rather than the type of licenses under which they are distributed. What is needed is a set of formal guidelines for government agencies to assess the full range of cost and benefits of different software choices. To ensure coherence and consistency of these rules, the central government needs to take a more active role in developing the evaluation framework.

  • Third, in its regulatory role, governments should adopt policies that promote effective competition between open source and proprietary software. Foremost among these are an aggressive competition policy to prevent abuse of network dominance and a policy to encourage the (p.202) maximum degree of openness in standards to intensify competition between different forms of software, but cognizant too of the need to preserve economic incentives for innovation in standards.

  • Finally, our survey evidence shows that governments currently provide a range of incentives, both formal and informal, for the development and use of both open source and proprietary software. But we argue that the economic justification for such incentives is generally weak. There is a stronger case for a proactive role for government in providing information to consumers about open source to correct informational imperfections in the market. There is also some argument for government sponsorship of selected demonstration projects involving open source, and perhaps also proprietary software, but it is critical that these not become a source of ongoing subsidy or industrial policy by stealth.

Governments face many challenging and important issues regarding the use and development of information technology in general and software in particular. They need to improve the procedures governing government procurement in information technology; to formulate evidence-based policies about whether, and how, to promote the use and development of software; to organize and finance the use of modern information and communication technologies in education; to ensure a healthy competition interaction between open source and proprietary software; and much more. In all these areas more research is needed to assist decision makers with the difficult choices they have to make. We hope that some of the energy that has, in recent years, been directed at the rather polarized debate between open source and proprietary software will be redirected more constructively toward these issues.

Appendix 6.1: Model for Policy Analysis

For the interested reader, in this appendix we summarize the technical version of the Schmidt–Schnitzer model, which we use in the text for policy analysis. The authors develop a Hotelling model in which both an open source and a proprietary program are offered. This is a model of horizontal product differentiation, in which users differ in their preferences between open source and proprietary software for some specific task, but there is no intrinsic quality difference between the two types of software (i.e., no vertical differentiation).

(p.203) To make things simple, in this model we assume that both programs are produced at a marginal cost of zero, and that the open source program is sold at a price of zero. The developer of the proprietary program chooses its price p to maximize its profit.

Each consumer is characterized by a “taste” parameter, t, that describes her preferences between open source and proprietary software. This parameter takes values between zero and one. She obtains benefits equal to vαt if she buys the open source software at a zero price, and vα(1 – t) – p if she buys the proprietary software.34 Higher values of t correspond to a stronger preference for proprietary software, relative to open source. In the software context it is natural to interpret this taste parameter as a summary index of the various costs the user incurs in adopting that type of program, apart from the initial cost of obtaining the software (e.g., the costs of switching, interoperability, support services or upgrades). The parameter α describes the intensity of the consumer’s preference for one type of software.

The consumer chooses to buy the program that yields the greatest benefits (net of price). Thus, she buys proprietary software if

να( 1t )pναtt αp 2α ,

and open source software otherwise. Note that if p = 0, all the consumers with taste parameter t 〉 1/2 choose proprietary software, while the others prefer the open source software. If we assume that the parameter t is uniformly distributed on the interval [0, 1], then (αp)/2α is the proportion of consumers who acquire the open source software and 1 – (αp)/2α is the proportion of consumers who purchase the proprietary software. Letting N denote the total number of consumers, the demand for the proprietary software is

N×( 1 αp 2α ),

which generates profit equal to (p.204)

N×( 1 αp 2α )×p.

The developer chooses the price p to maximize this profit. It is easy to confirm that this yields a price of α/2. The firm’s profit is

N×( 1 αα/2 2α )× α 2 = 3α 8 N.

The consumers who buy the proprietary software are those consumers for which

t αα/2 2α = 3 4 .

Thus the proprietary software is sold to one-fourth of the consumers and open source software to the other three-fourths. Recall that the efficient allocation would involve an equal division of the market between open source and proprietary software. Thus the market generates overuse of open source, which occurs because it is available for free.35

An increase in the parameter α corresponds to increase in the attachment of consumers to their preferred software. When α is higher, a rise in the price of proprietary software discourages fewer of its consumers. This induces the developer to raise the price, and due to the specific formulation of the model, it does that in such a way that the number of programs that it sells stays constant (e.g., this would not be the case if the distribution of t were not uniform). Because the price increases and its sales do not change, the profit of the developer increases.

Schmidt and Schnitzer use this model to highlight the resulting inefficiency in the relative use of open source and proprietary software. Consider the consumer for whom t = 2/3. If the two programs were sold at a price equal to marginal cost, namely at zero, this consumer (p.205) would choose to buy proprietary software. However, because she must pay for the proprietary software, she chooses to buy the open source software and ends up using the program she likes less, despite the fact that the costs of production are the same. To put this point another way, because the proprietary software developer is extracting profits by charging a higher price than the open source “community,” its product is not utilized enough. This implies that policies that would extend the use of open source software will, at least in this simple static model, decrease social welfare. It is policies that extend the use of proprietary software that increase social welfare. But as we discuss in the text, there are other considerations—including imperfect information by the consumer about open source—that can have a countervailing effect. (p.206)

Notes:

(1.) A good summary of policy initiatives in favor of open source software, both at the federal and lower levels of government worldwide, can be found in Lewis (2008).

(2.) http://opensource.mampu.gov.my/index.php (accessed September 8, 2009).

(3.) If we restrict our attention to firms that are not in favor of freedom to choose, they are more likely than large firms to prefer a regulatory regime that favors open source software. Among firms that do not prefer complete freedom to choose, 67 percent of small firms and 61 percent of large firms prefer a regulatory regime that favors open source. But, as in table 6.2, there is variation in this regard across countries.

(4.) There is an analytical literature exploring the supply of open source software, including the reasons for and consequences of voluntary contributions of code and the implications for economic growth. Leading examples include Lerner and Tirole (2003), von Hippel and von Krough (2003), Belenzon and Schankerman (2008), and Saint-Paul (2001). But, for the most part, these papers do not do normative (welfare) policy analysis.

(5.) As we discussed in chapter 4, many open source programs are sponsored by firms who generate income by selling complementary programs or services. For a model that studies the consequences of this fact, see Lambardi (2009).

(6.) We are assuming that the taste parameter is uniformly distributed between zero and one. This means that tastes are not bunched at any particular point. This assumption is not needed for the model to generate the main policy conclusion we focus on here.

(7.) This conclusion will be familiar to economists (and probably counterintuitive to noneconomists). A standard argument in economics is that to correct the underproduction by a firm with market power using the price system requires a subsidy, rather than a tax, which would only exacerbate the problem. The benchmark used in this analysis is how prices should be set to ensure socially efficient use of software: prices set at marginal costs. This is what economists call the “first-best” solution, as it maximizes welfare. However, this is only so if it is assumed that the fixed costs of developing software (both proprietary and open source) are compensated by government transfers to the firms or other agents who incur them. In practice, this is unrealistic, and in such cases socially efficient pricing that ensures development of software would require prices above the marginal costs (economists refer to this as the “second-best” solution). A full analysis of optimal pricing is beyond the scope of this discussion. The key point we want to emphasize is that the often-heard argument that there is underuse of open source that justifies a subsidy is not supported by economic principles (an exception might arise because of informational imperfections, which we discuss later).

(8.) See Yarney (2003). This quotation is drawn from Lerner and Herman (2005). At the same time (and perhaps as a consequence of such statements) the South African government accepted a donation of Microsoft in February 2009 that will provide free proprietary software for all of South Africa’s 32,000 government schools (http://www.bridges.org/commentaries/115 (accessed July 28, 2009).

(10.) In 2003 the United Nations Conference on Trade and Development (UNCTAD) called on poor countries to adopt open source software. See UNCTAD (2003). The statement of the German Foreign Minister is available at Steinmeier (2009).

(11.) The countries covered are Brazil, Greece, India, Israel, Mexico, Poland, Russia, Singapore, and Thailand. The data come from the Economist Intelligence Unit and http://www.payscale.com/salary-survey (accessed June 1, 2006).

(12.) The issues here are similar to those that arise in discussions of government support to R&D and of the terms under which it should be licensed to private firms. There is a large economic literature on the topic. For a good example, see Jaffe and Lerner (2001).

(13.) The TeX code was simply put in the public domain so that anyone can use the code as she sees fit. However, the name TeX cannot be used for a modified version of the program.

(15.) The Danish government has commissioned development of a TCO model to facilitate such assessments, with the intention of making it available to all public institutions.

(16.) For instance, the article “Administration centrale: 225 chantiers ouverts,” which describes the use of open software in French public administration states “… le libre évite de passer un appel d’offres public, processus coûteux” (… free (software) escapes the requirement of a formal public procurement process, which is costly). Notice that this is very bad managerial practice, which favors projects whose immediate costs are low as opposed to those who deliver lower costs over the long range, in order to go around formal procedures which are considered too onerous. See Caillerez (2005).

(17.) We would assume that the difference of marketing clout between open source and proprietary software has certainly decreased in recent years, as suppliers of open source software are more and more professionally run firms, some of them very large.

(18.) For discussion of this important result, see Tirole (1988, ch. 3).

(19.) This phenomenon is illustrated by Mr. Jumrud Sawangsamud, president of the Association of Thailand Computer Industry. When discussing the budget PC program, which is aimed at providing Thai households with low cost computers, he explained: “We talked to Microsoft and let them know people in the remote areas could not afford an expensive system. Microsoft offered us a lower priced version of the operating system which was localized for the Thai language.” This quotation is taken from the Thai case study we conducted as part of this research project, which is available on line as part of the supplementary materials for this book.

(20.) This sensitivity to the consequences of different types of licenses is compatible with neutrality between open source and proprietary software. For instance, the US Office of Management and Budget (OMB) issued a memorandum on software acquisition on July 1, 2004, that reminded senior procurement offices that acquisition should be vendor and technology neutral and stressed that this policy applied “to acquisitions of all software, whether it is proprietary or Open Source Software.” It also stated “These differences in licensing may affect the use, the security, and the total cost of ownership of the software and must be considered when an agency is planning a software acquisition.” See Evans and Burton (2004).

(21.) This seems to be the lesson drawn from the following episode reported by Jean-Marie Lapeyre, head of the Copernic Program, on the effort by the French Tax Administration (Direction Générale des Impôts) to modernize its IT infrastructure: “The ILIAD system was built around two technologies: a Unix server, which is AIX 4.2, by IBM, and another technology, Oracle Forms version 3. One day in 2000, Mr. IBM, came in and said, ‘We do not support version 4.2 of AIX anymore. You have to switch to 4.3.’ We said ‘OK’ and planned a migration. But then Mr. Oracle said, ‘Version 3 of Oracle Forms is not supported on AIX 4.3. You have to switch to Oracle Forms version 6.’ We had very little choice in the matter. We had to pay for the migrations at a separate cost of €15 million. And the service was worse!” This quotation is taken from the French case study we conducted as part of this research project, which is available online as part of the supplementary materials for this book.

(22.) A discussion of these issues by four authors with different perspectives can be found in Hahn (2002).

(23.) A similar conclusion is reached by Gutsche (2005). His analysis is narrower in that it focuses on consumer welfare alone, but it is more general because he takes into account both network effects and consumer switching costs. This extension is important because the survey evidence in chapter 5 shows that switching costs are an important component of the total cost of ownership for software users, and are particularly prominent for open source software. In addition he takes into account the fact that in many countries the profits of proprietary software firms accrue to foreigners, which reduces the domestic benefits. But even with these extensions, Gutche concludes that “we do not find much support for interventions in favor of OSS on the whole.”

(24.) As we discussed in chapter 2, the recent work by Chen, Dorazelski, and Harrington (2009) shows that allowing for price competition can, under certain circumstances, dramatically change the dynamics and long run equilibrium in markets with network effects. In particular, the risk of persistent dominance is mitigated by competitive pricing behavior by the firm(s) with the smaller installed base.

(26.) This is consistent, for example, with the definition used by the European Commission in its “European Interoperability Framework for Pan-European eGovernment Services,” http://ec.europa.eu/idabc/servlets/Doc?id=19529 (accessed July 6, 2009).

(28.) Wheeler (2006) argues that every successful open standard has one implementation in an open source program.

(29.) The dangers involved are well-illustrated by the effort by Rambus, a semiconductor designer, to control computer memory technology. As with software, an important feature of the computer memory industry is that both computer makers and consumers benefit greatly if the memory products made by different companies are interchangeable. This requires that memory chips be designed consistent with industry “standards”—technical specifications ensuring that any memory chips, meeting the standards, will work as expected in any computer design. At the same time this creates the strong danger of “holdup,” since any company with a patent that covers technology required by such a standard can insist on royalties from the entire industry. For this reason the standard setting body, JEDEC, like many such associations, requires their members to (1) disclose any pending patent applications that bear on the elements of standards under discussion and (2) license any patents that end up covering the standard to everyone in the industry at “reasonable” royalty rates. Of course, defining what constitutes a “reasonable” royalty and enforcing a reasonable royalty policy are tricky undertakings. This difficulty makes the disclosure obligation all the more important, so people working on drafting standards have a clear understanding of the extent to which products designed to conform to the standard are going to be subject to royalty claims.

In the early 1990s, when the standards for SDRAM chips were being discussed at JEDEC, Rambus was a member of the organization. The JEDEC committee working on standards for DRAM knew that one patent from the 1990 application had been issued. But Rambus did not disclose to the committee that it had additional applications pending. Worse, unbeknown to the other members of JEDEC, Rambus was crafting yet more applications (still retaining the original priority date) in which it attempted to cover the features of the JEDEC SDRAM standard as that standard was being discussed at committee meetings, attended by Rambus representatives. Ultimately Rambus initiated an aggressive litigation campaign against fellow industry members that continues to this day.

For a more detailed discussion of the Rambus case, the reader is referred to Jaffe and Lerner (2007 paperback edition).

(30.) http://opensource.org/osr (accessed August 19, 2009).

(31.) A more explicit attack on the term RAND licensing can be found on the Free Software Foundation site: “That term white-washes a class of patent licenses that are normally neither reasonable nor non-discriminatory … these licenses … discriminate against the free software community, and that makes them unreasonable.” http://www.gnu.org/philosophy/words-to-avoid.html (accessed August 19, 2009).

(32.) For an example of the type of discussions to which this can lead, see David Wheeler (2008).

(33.) Governments also influence the development of the software industry through their choice of intellectual property policy. This problem was briefly explored in chapter 3, and we will not revisit it here.

(34.) We assume that v is large enough to ensure that, if there were no proprietary software available, all consumers would choose to use the open source program rather than none. The consumer with the least taste for open source software is the consumer for whom t = 1. Therefore this assumption translates into the restriction vα 〉 0. This ensures that when proprietary and open source software compete with each other, all consumers purchase at least one of them: “the market is covered.”

(35.) A slightly more sophisticated version of the model can allow one program to be intrinsically better than the other. A consumer of taste parameter t then obtains benefits of vOSαt if he buys the open source software, and vPα(1 – t) – p if he buys the proprietary software, where vOS can be either larger or smaller than vP. In this case the efficient allocation is for consumers with t ≥ 1/2 + Δv/(2α) to purchase the proprietary software, where Δv = vOSvP. However, the profit maximizing proprietary developer will charge a price of α/2 – Δv/2 and it is only consumers with t ≥ 3/4 + Δv/(4α) who purchase its product. As in the simple version of the model, there is underconsumption of proprietary software. (This reasoning holds only if Δvα; if this were not the case, no consumers would purchase proprietary software, even at zero price.) The economic conclusions drawn from the analysis are the same in this more sophisticated model.