PUTTING A VALUE ON OPENNESS: THE EFFECT OF PRODUCT SOURCE CODE RELEASES ON THE MARKET VALUE OF FIRMS1 OLIVER ALEXY
Technische Universität München
TUM Business School
Arcisstr. 21, D – 80333 Munich, Germany
E-mail: firstname.lastname@example.org WORKING DRAFT (5 OCTOBER 2007) PLEASE DO NOT CITE OR CIRCULATE FEEDBACK IS HIGHLY APPRECIATED!
1 The author would like to thank Jörn Block, Joachim Henkel, and Simone Käs for valuable feedback on this
paper. Special thanks go to Hans Zischka for valuable assistance in data collection and to Josef Waltl for help
with earlier versions of this paper. All remaining errors are of course my own.
1 PUTTING A VALUE ON OPENNESS: THE EFFECT OF PRODUCT SOURCE CODE RELEASES ON THE MARKET VALUE OF FIRMS ABSTRACT
This study examines the effect of releasing the source code of commercial software
products as open source software on the market value of firms. Using a sample of 30 software
companies in the time span from 1 January 1999 to 30 April 2007, I find that market valuation is
influenced by investor sentiment—abnormal returns take a curvilinear shape over time—and the
business model firms choose for their OSS efforts—non-existence of an explicit revenue model
is punished by the capital market. From my findings, I deduce several implications for IT-related
event studies and research on open innovation processes.
Keywords: open source software; event study; investor sentiment; business model;
2 PUTTING A VALUE ON OPENNESS: THE EFFECT OF PRODUCT SOURCE CODE RELEASES ON THE MARKET VALUE OF FIRMS – AN EVENT STUDY INTRODUCTION
Does open source software (OSS) pay off? Over the last years, researchers have put a lot
of effort in explaining the open source phenomenon, its impact on the innovation process within
and outside firms, and the economic effects of open source strategies of commercial firms (e.g.,
Dahlander, 2005; Lerner & Tirole, 2002; Stewart & Gosain, 2006; von Hippel & von Krogh,
2003; West, 2003; West & Gallagher, 2006). They found that, in many cases, patterns of
contributing code are consistent with profit maximization.
Still, the current research on open source software does not yet answer the question
whether open source activities in general and the releasing of product source code in particular
encompass an effect on the value of firms—and, more specifically, a positive
effect. In this
paper, I thus tackle the question of whether product source code releases have a significant
impact on the market value of firms and which factors might influence or drive this effect. After
identifying a set of business models firms may choose to generate and appropriate value from
releasing proprietary software as OSS, namely using OSS as a competitive weapon, cost or risk
reduction, dual licensing, and the sale of complementary goods or service, I analyze how the
capital market reacts to firms announcing a release of proprietary software as OSS and which
factors are influential to this. I maintain that the time of the announcement in relation to the
general market perception of OSS and the choice of business model affect the abnormal returns
that firms may generate.
The event study method is an approved technique to measure market reaction to specific
events. It is widely used in research to measure the impact of managerial decisions (McWilliams
& Siegel, 1997). Nevertheless, to my knowledge, no event study measuring the effect of OSS or
open innovation (Chesbrough, 2003) efforts on the value of firms has been conducted up till
now. There is one event study in the related field of open vs. proprietary Extensible Markup
Language (XML) standardization where Aggarwal et al. (2006) discovered that capital markets
react negatively on open XML standardizations in years from 1999 to 2003.
During the time span from January 1, 1999, to April 30, 2007, I find a curvilinear (u-
shaped) trend in the market reaction to firms announcing the release of source code as OSS
which can be ascribed to negative investor sentiment after the burst of the dot.com bubble.
Furthermore, I maintain that the capital market specifically reacts to the choice of business
model of the firm announcing the release of a (potential) product under an OSS license. In
particular, investors punish firms engaging in OSS without a revenue model.
The rest of this paper is organized as follows. I will first review the literature on
advantages and disadvantages of OSS for firms as well as business models they might choose
when releasing their proprietary software and l deduce the hypotheses for the event study, also
including the market and investor perspective. Next, I introduce data and methods, and,
thereafter, present the results. Finally, I discuss the implications of my findings and limitations of
the study and give recommendations for future research. THEORY AND HYPOTHESES DEVELOPMENT Definition of Open Source Software
Since its inception in April 1998, the term OSS is exactly specified by the open source
initiative (OSI). Following their definition, OSS is software that is licensed under an OSS license
approved by the OSI.2 OSS does not necessarily mean that the software is gratis (although this is
2 As of September 13, 2007, the OSI had approved 61licenses.
very common). For a license to be OSI compliant, users of the respective software have to be
provided access to the source code (upon request, at least), the distribution of derived work must
be allowed, and no discrimination against persons, groups or fields of endeavor is allowed (OSI,
2001). Advantages of Releasing Proprietary Source Code as Open Source Software
By releasing their software under an open source license, companies can, first of all,
benefit from external developers’ support and the latter can make improvements and further
developments to the software. As these developers will be making adaptations for other
companies, in most cases the feedback received is direct user input to better tailor existing and
future products to existing markets. Overall, it is highly likely that a piece software will develop
faster than if kept proprietary (Dalle & Jullien, 2003; Henkel, 2004; Lakhani & von Hippel,
2003). In addition to this, by having customers make further developments to a piece of software,
the company might not only be able to get a gratis stream of innovations to its product, it can
also achieve higher rates of customer satisfaction. By allowing the customers to make changes
and additions to the software on their own, they will be more likely to fully commit to the
product, and make the improvements needed and hoped for (Goldman & Gabriel, 2005;
Morrison, Roberts, & von Hippel, 2000; von Hippel, 2001). In this way, the company might also
be able to receive knowledge that might have been difficult to find, transfer, or acquire
otherwise, so-called “sticky information” (von Hippel, 1994, 1998). Furthermore, the community
might not only help the company with the actual program, they might also engage in more
mundane tasks such as user support or documentation. Again, this will reduce the amount of
developer resources the company will have to spend for activities unrelated to core business that
also do not generate any revenue (Goldman et al., 2005; Lakhani et al., 2003; Shah, 2006).
Standard setting and compatibility issues also play important roles. Releasing a piece of
software gives the company the opportunity to make the software the standard in a certain area if
none has existed there before, to tip the standard race in favor of its piece of software, or to
prevent a proprietary standard. All of this is useful to the company and actually an opportunity to
increase profits: if the company defines (parts of) the standard – even if it is an open one – it is
highly likely that it includes parts that are only beneficial to that one company, may it be because
only the company itself knows of them or because they are already optimally realized in an
existing product (Goldman et al., 2005).
If one strong standard already exists, releasing a piece of software can make it part of this
standard, or, at least, it will increase compatibility of the software to others (Harhoff, Henkel, &
von Hippel, 2003; Hecker, 1999; Henkel, 2004; Raymond, 2001a). In any case this increased
compatibility will create network effects that not only encourage distribution and adoption of the
software, but also related innovations and second generation innovation built on the software
(Bonaccorsi, Giannangeli, & Rossi, 2006; Farrell & Gallini, 1988; Farrell & Saloner, 1985;
Harhoff et al., 2003; Henkel & von Hippel, 2005; Katz & Shapiro, 1985, 1986; Shepard, 1987).
The attempt to set a standard or to at least influence the standard race might also be motivated by
strategic reasons. If there is already a dominant standard or a dominant competitor in the market
that the company has trouble keeping up with, building on OSS or releasing the software as OSS
might be a valuable option. Potential Downsides of Releasing Proprietary Software as OSS
While the possibility of free bugfixes and new features seems promising at first glance, a
company has to bear in mind that releasing software under an OSS license does not
automatically attract lots of developers who will do all the work and cost nothing. On the
contrary, if the code is not modular enough, people will simply not be able to grasp the nature of
the software and will only be able to make minor contributions – the company will basically still
have to do all the further developments by itself (Baldwin & Clark, 1997; Goldman et al., 2005).
Thus, the source code needs to either be modular from the beginning or modified accordingly
before being released. In addition to this, the source code needs to be sanitized, e.g. all
inappropriate comments need to be removed, business logic extracted, and so on, which can
bring a significant amount of start-up cost (Hecker, 1999).
The most obvious risk of releasing the source code of proprietary software under an OSS
license is of course a loss of intellectual property, and, consequently of competitive advantage.
The idea is that the company’s competitors are able to right away start working with all ideas
contained in the product at no additional cost. However, a caveat is in order. While spillovers to
a competitor may be problematic, the firm may nevertheless profit from going OSS if the added
value – lower costs of development, new features and fixed bugs, and new sources of revenue –
outweighs the losses as needs to be addressed by a preceding business case (West et al., 2006).
Still, the threat of losing intellectual property hampers the release of proprietary software. As,
with OSS, customers will also have direct access to the source of the company’s products, they
may see less of a reason to pay for it. Indeed, with OSS it will no longer be possible to demand
license fees for the product, so it is likely than no direct revenue stream will come from the
software any longer. Instead, the company will have to look for new, mainly indirect sources of
revenues, such as the sale of complementary goods or services (Raymond, 2001a).
From a technical point of view, several dangers arise. In case the source code is
incomplete or of low quality, the outcome of an OSS project could range from the public merely
ignoring the OSS efforts to a serious damage of the company’s technical reputation. However, in
no case will the possible benefits of an OSS strategy be reaped (Goldman et al., 2005; Henkel,
If a company has managed to successfully establish an OSS project based on formerly
proprietary software, the danger of forking remains:3 if people are unhappy with the way the
company manages the OSS project they may simple take the existing code base and start their
own project as is permitted by many OSS licenses (FSF, 2006; OSI, 2001). Open Source Software-based Business Models for Proprietary Software Firms “How do I make money on software if I can't sell my code?
You can sell your code. Red Hat does it all the time. What you can't do is stop someone
else from selling your code as well. That just says that you need to add extra value to
your code, by offering service, or printed documentation, or a convenient medium, or a
4certification mark testifying to its quality.”
Despite the advantages presented above, at first glance, it may seem hardly if at all
possible to directly earn money with OSS. One even has to reveal the source code of one’s
product to the customer which seemingly dries up all revenue streams possibly coming from this
piece of software! Still, there are ways to make money with OSS, may they be indirect ones in
most cases, and it is possible to build up a business around open source software. Indeed, it is
explicitly allowed to demand money for the software, as was already stated in the introductory
quote to this chapter. Independent of what a company is selling, it can charge every amount of
money it wants to. However, what it cannot do is barring its customers from giving away the
software they purchased for free, by for example putting the source code to the program on the
web (FSF, 2006). According to the rights given to customers by the OSS license the company
decided to use, they might also be able to create new proprietary software based on the
company’s existing OSS product. Yet, in most situations, the customers will either have no
3 “A fork
is a competing project
based on a version of the pre-existing project’s source code. All OSS/FS projects
can be ‘forked’; the ability to create a fork is fundamental to the definition of OSS/FS.” (Wheeler, 2002,
formatting copied from original source)
4 http://www.opensource.org/advocacy/faq.php, retrieved March 10, 2006, 2:50 p.m.
interest in doing that, or the further distribution of the software might even be beneficial to the
company, as in the case of standard setting.
Using the least common denominator found in the literature, I define a business model as
the way in which the firm creates and delivers value for the customer, whereas the revenue
model focuses on how the firm appropriates the rents from the business. The revenue model,
consequently, is an important part of a business model (Amit & Zott, 2001; Chesbrough &
Rosenbloom, 2002; Richardson, 2005). From the existing literature on OSS and the advantages
of OSS specified before, four different but non-exclusive business models can be deduced: using
OSS as a competitive weapon, cost or risk reduction, dual licensing, and the sale of
complementary goods or assets. Indeed, oftentimes, a combination of several of these models
seems more promising than choosing a single one.
In Table 1, I have briefly summarized these business models and given examples of firms
using them in the past showing that the four business models not only differ with respect to the
goals that firms may reach when applying them, but also with respect to time horizon and
appropriability, that is, an easily applicable revenue model.
Insert Table 1 about here
As is shown in Table 1, there are important differences in the revenue models
accompanying the four business models. When thinking about investors valuating those
differently, it is important to understand that releasing proprietary software as OSS using the
strategies of cost and risk reduction, dual licensing, and sale of complementary goods and
services can be easily expressed as a business model, and a revenue model in particular, whereas
the use of OSS as a competitive weapon shows little to no clear short-term benefits, and the hard-
to-quantify long-term benefits might be ignored by the capital market (Dos Santos, Peffers, &
Mauer, 1993; Oh, Gallivan, & Kim, 2006). On average, I thus expect that firms who announce a
release of proprietary software as OSS for merely strategic reasons will see this more negatively
evaluated than firms choosing one of the three other strategies.
H1: Firms following the competitive weapon strategy will be evaluated less positively by
investors than those firms releasing proprietary software as OSS using another business
Time does not only play a role with respect to the effects, that is, the time horizon
, of the
decision to go OSS, the timing
of the announcement, too, might be of vital importance. When
looking at the period of time since when OSS activities of firms can be observed on the capital
market, it is important to note that this started before the burst of the dot.com-bubble in mid-
2000. The importance of this observation lies in the fact that, sometimes, capital markets may be
inefficient with respect to investors not behaving rationally (De Long, Shleifer, Summers, &
Waldmann, 1990; Lee, Shleifer, & Thaler, 1991): investors will value stocks more positively in a
time of positive investor sentiment and more negatively in a time of negative investor sentiment.
As an example for investor sentiment with respect to the IT market around the dot.com bubble
burst, Lee (2001) and Cooper, Dimitrov and Rau (2001) show that IT markets react favorably to
firms changing their name to include ‘.com’ before mid-2000, whereas Cooper et al. (2005)
show a positive effect of the removal of ‘.com’ from the firm name after mid-2000. Similarly,
Dehning et al. (2004) report positive effects on stock price caused by the announcement of e-
commerce initiatives in 1998 and—depending on the method they use—negative effects or
indications for those for the forth quarter of 2001.
Concerning the valuation of firms announcing “openness”, Aggarwal, Dai, and Walden
(2006) compare the effect of the announcement of open vs. proprietary XML standards by firms