Free Revealing: How Firms Can Profit From Being Open

Oliver Alexy Free Revealing

GABLER EDITION WISSENSCHAFT Innovation und Entrepreneurship Herausgegeben von Professor Dr. Nikolaus Franke, Wirtschaftsuniversität Wien, Professor Dietmar Harhoff, Ph.D., Universität München, und Professor Dr. Joachim Henkel, Technische Universität München

Innovative Konzepte und unternehmerische Leistungen sind für Wohlstand und Fortschritt von entscheidender Bedeutung. Diese Schriftenreihe vereint wissenschaftliche Arbeiten zu diesem Themenbereich. Sie beschreiben substanzielle Erkenntnisse auf hohem methodischen Niveau.

Oliver Alexy

Free Revealing How Firms Can Profit From Being Open

With a foreword by Prof. Dr. Joachim Henkel

GABLER EDITION WISSENSCHAFT

Bibliographic information published by the Deutsche Nationalbibliothek The Deutsche Nationalbibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data are available in the Internet at http://dnb.d-nb.de.

Dissertation Technische Universität München, 2008

1st Edition 2009 All rights reserved © Gabler | GWV Fachverlage GmbH, Wiesbaden 2009 Editorial Office: Frauke Schindler / Jutta Hinrichsen Gabler is part of the specialist publishing group Springer Science+Business Media. www.gabler.de No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the copyright holder. Registered and/or industrial names, trade names, trade descriptions etc. cited in this publication are part of the law for trade-mark protection and may not be used free in any form or by any means even if this is not specifically marked. Cover design: Regine Zimmer, Dipl.-Designerin, Frankfurt/Main Printed on acid-free paper Printed in Germany ISBN 978-3-8349-1475-0

V

Foreword Over the last decade, the commercial world has more and more embraced open source software such as the Linux operating system. What started out as an ideological movement for “Free Software” and as a hobbyists’ thing has largely turned into a mainstream part of the IT industry. By 2008, even the long-time open source critic Microsoft has created two open source licenses, and it comes as little surprise when Google releases the complete mobile operating system stack of its Android phone as open source. Yet, how exactly open source software and in particular the open source style of software development are integrated into commercial enterprises is far from being understood. Research into open source software and open innovation more broadly only just starts to address these issues. But these questions are of obvious importance for firms considering to launch or extend their open source engagement, and of academic interest to scholars studying open innovation processes. With this book, Oliver Alexy makes a significant contribution. Based on thorough empirical work and a deep understanding of the field, he addresses a number of key questions. How do firms decide if to launch an open source activity? Does the capital market reward or penalize open source engagements? How does opening up the software development process affect the various job functions involved, and how do individuals react to these changes? Finally, when mustering support by outside developers, would offering monetary rewards crowd out their intrinsic motivation? This book is Oliver Alexy’s doctoral thesis at Technische Universität München, and it marks the starting point of a promising academic career. With its insights being valuable for firms as well as for research, I strongly recommend it to practitioners and academics alike. Munich, October 2008 Prof. Dr. Joachim Henkel

VII

Preface I would like to take this opportunity to thank all those who have assisted me in creating this dissertation and, even more importantly, to get it done. First of all, I would especially like to thank Prof. Dr. Joachim Henkel, my thesis advisor, who has created a unique environment at his chair, enabling his team to conduct exciting, cutting-edge, interdisciplinary research in an international setting, and who has provided more support than I could have asked for. I am also indebted to him for coauthoring the paper that is underlying a large portion of the forth chapter of this thesis. I would further like to warmly thank my fellow PhD students, in particular Jörn Block and Simone Käs, for valuable input, thoughtful discussions, and encouraging comments which greatly helped me to stay focused and determined, and to move forward. For input from the “real world” of business, I would like to all my official and offthe-record interview partners. For giving me the wonderful opportunity of spending three months at the Massachusetts Institute of Technology and Harvard Business School, and for helping me become a better researcher, I would like to thank Professors Eric von Hippel and Karim Lakhani. For support in generating this thesis I would further like to thank Robert Simm, Josef Waltl, and Martin Leitner whose Diplom and Master’s Theses provided valuable input to parts of this thesis. In addition, I would like to thank all those who assisted me in improving this thesis, or parts of it, for example seminar participants of the TIME colloquium, participants of the 5th International Workshop on User Innovation, as well as all the others who have been such a great help. Finally, I want to thank my wife Margit, for all her support, and, sometimes, lenience. This thesis is dedicated to you.

—Oliver Alexy 22 October 2008 London, United Kingdom

IX

Table of Contents

FOREWORD...................................................................................................... V PREFACE ........................................................................................................ VII TABLE OF CONTENTS ................................................................................... IX DETAILED TABLE OF CONTENTS ................................................................ XI LIST OF FIGURES .......................................................................................... XV LIST OF TABLES .......................................................................................... XVII LIST OF EQUATIONS .................................................................................... XIX LIST OF ABBREVIATIONS............................................................................ XXI ZUSAMMENFASSUNG ................................................................................ XXIII ABSTRACT ...................................................................................................XXV 1

INTRODUCTION: COMMERCIAL OPEN SOURCE SOFTWARE .............. 1

2

OPEN SOURCE SOFTWARE: SOURCE OF INNOVATION? .................... 9

3

TOP-DOWN ADOPTION OF OSS ............................................................ 53

4

BOTTOM-UP ADOPTION OF OSS ........................................................... 92

5

MANAGING OSS-RELATED PROCESSES ........................................... 142

6

MOTIVATION AND INCENTIVIZING OF OSS DEVELOPERS .............. 162

7

SUMMARY AND OUTLOOK: OSS IN THE 21ST CENTURY .................. 191

BIBLIOGRAPHY ............................................................................................ 195

XI

Detailed Table of Contents

ZUSAMMENFASSUNG ................................................................................ XXIII ABSTRACT ...................................................................................................XXV 1

INTRODUCTION: COMMERCIAL OPEN SOURCE SOFTWARE .............. 1

1.1

Development of the Open Source Phenomenon ............................................................................. 1

1.2

Motivation ......................................................................................................................................... 3

1.3

Research Questions ........................................................................................................................... 4

1.4

Research Context .............................................................................................................................. 5

1.5

Structural Outline............................................................................................................................. 7

2

OPEN SOURCE SOFTWARE: SOURCE OF INNOVATION? .................... 9

2.1 Definition and History of OSS ......................................................................................................... 9 2.1.1 Definition .................................................................................................................................. 9 2.1.2 OSS Licenses .......................................................................................................................... 11 2.1.3 Some Core Principles of Open Source Software ..................................................................... 13 2.1.4 Summary ................................................................................................................................. 15 2.2 OSS as a Source of Innovation....................................................................................................... 16 2.2.1 Open Innovation ...................................................................................................................... 16 2.2.2 Collective Invention ................................................................................................................ 17 2.2.3 User Innovation ....................................................................................................................... 19 2.2.4 Private-collective Innovation .................................................................................................. 21 2.2.5 Summary ................................................................................................................................. 24 2.3 Advantages and Disadvantages for Commercial Firms .............................................................. 24 2.3.1 Advantages of Using OSS ....................................................................................................... 26 2.3.2 Disadvantages of Using OSS .................................................................................................. 29 2.3.3 From Using to Revealing ........................................................................................................ 31 2.3.4 Advantages of Contributing to Existing OSS Projects ............................................................ 33 2.3.5 Advantages of Releasing Proprietary Software as OSS .......................................................... 35 2.3.6 Disadvantages of Contributing and Releasing ........................................................................ 37 2.3.7 Means of Protecting IP When Releasing Software ................................................................. 39 2.4 Business Models around OSS ........................................................................................................ 41 2.4.1 Business Transformation ......................................................................................................... 42 2.4.2 Cost and Risk Reduction ......................................................................................................... 44 2.4.3 Dual Licensing ........................................................................................................................ 45 2.4.4 Sale of Complementary Services ............................................................................................ 46 2.4.5 Sale of Complementary Goods ............................................................................................... 48 2.5

Implications for the Corporation and its Employees ................................................................... 50

XII 3

TOP-DOWN ADOPTION OF OSS ............................................................ 53

3.1 Specifying the Potential of OSS Use for the Organization .......................................................... 53 3.1.1 Sample..................................................................................................................................... 55 3.1.2 Variables ................................................................................................................................. 55 3.1.3 Interview Results..................................................................................................................... 57 3.1.4 Survey Results......................................................................................................................... 58 3.1.5 Further Aspects ....................................................................................................................... 60 3.1.6 Conclusion .............................................................................................................................. 63 3.2 Capital Market Evaluation of Releasing Source Code ................................................................ 64 3.2.1 Hypotheses .............................................................................................................................. 66 3.2.2 Method and Data ..................................................................................................................... 73 3.2.3 Results ..................................................................................................................................... 80 3.2.4 Discussion and Implications.................................................................................................... 83 3.3

Conclusions ..................................................................................................................................... 90

4

BOTTOM-UP ADOPTION OF OSS ........................................................... 92

4.1

OSS vs. PCSS Development ........................................................................................................... 93

4.2

Research Design .............................................................................................................................. 95

4.3 Effects of Cooperate OSS Adoption on Employees ...................................................................... 98 4.3.1 Software Architects, Developers, and Testers ......................................................................... 99 4.3.2 Managers and Project Managers ........................................................................................... 101 4.3.3 Hypotheses ............................................................................................................................ 102 4.4 Data and Methods ......................................................................................................................... 103 4.4.1 Data Collection ..................................................................................................................... 103 4.4.2 Sample................................................................................................................................... 104 4.4.3 Dependent Variables ............................................................................................................. 104 4.4.4 Main Independent Variables ................................................................................................. 105 4.4.5 Control Variables .................................................................................................................. 105 4.5 Results ............................................................................................................................................ 110 4.5.1 Job Functions—Descriptive Analysis ................................................................................... 110 4.5.2 Job Functions—Multivariate Analysis .................................................................................. 114 4.5.3 Control Variables .................................................................................................................. 118 4.5.4 Further Results ...................................................................................................................... 120 4.6 Discussion and Implications ......................................................................................................... 123 4.6.1 Job Functions and OSS Adoption ......................................................................................... 124 4.6.2 Limitations and Possible Extensions ..................................................................................... 127 4.7 Exploratory Cluster Analysis ...................................................................................................... 127 4.7.1 Clustering Variables .............................................................................................................. 128 4.7.2 Method and Results ............................................................................................................... 130 4.7.3 Interpretation ......................................................................................................................... 131 4.7.4 Implications ........................................................................................................................... 134 4.8 Conclusions ................................................................................................................................... 134 4.8.1 Introduction of OSS to the Corporation ................................................................................ 135 4.8.2 Corporate Source................................................................................................................... 136 4.8.3 Need for Change Agents ....................................................................................................... 138 4.9

Summary: Top-down or Bottom-up ........................................................................................... 140

XIII 5

MANAGING OSS-RELATED PROCESSES ........................................... 142

5.1 Benchmark Study ......................................................................................................................... 142 5.1.1 Using Open Source Software ................................................................................................ 143 5.1.2 Contributing to Existing OSS Projects .................................................................................. 145 5.1.3 Releasing Proprietary Software as OSS ................................................................................ 146 5.2 Developing a Model Process for Releasing Source Code ........................................................... 148 5.2.1 General Preparations ............................................................................................................. 148 5.2.2 Business Preparations............................................................................................................ 149 5.2.3 Software Preparations ........................................................................................................... 152 5.3 Managing Company-Owned OSS Projects ................................................................................ 156 5.3.1 Getting Third Parties to Support the Project ......................................................................... 156 5.3.2 Governance ........................................................................................................................... 157 5.3.3 Source Code Management and Release Policy ..................................................................... 157 5.3.4 Documentation ...................................................................................................................... 158 5.3.5 Accepting Contributions ....................................................................................................... 159 5.3.6 Measuring Success ................................................................................................................ 159 5.4

Conclusion ..................................................................................................................................... 160

6

MOTIVATION AND INCENTIVIZING OF OSS DEVELOPERS .............. 162

6.1

Introduction .................................................................................................................................. 162

6.2 Theory and Hypotheses ................................................................................................................ 164 6.2.1 Intrinsic and Extrinsic Motivation ......................................................................................... 164 6.2.2 Crowding In and Crowding Out ............................................................................................ 165 6.2.3 Payment Norms ..................................................................................................................... 166 6.2.4 Developers’ Motivation ........................................................................................................ 167 6.2.5 Hypotheses ............................................................................................................................ 168 6.3 Data and Method .......................................................................................................................... 171 6.3.1 Method .................................................................................................................................. 171 6.3.2 Sample................................................................................................................................... 172 6.3.3 Dependent and Control Variables ......................................................................................... 174 6.4

Results ............................................................................................................................................ 179

6.5 Discussion and Implications ......................................................................................................... 183 6.5.1 Effects of Payment and Norms on Intrinsic Motivation ........................................................ 183 6.5.2 Effects of Payment and Norms on Total Motivation ............................................................. 187 6.5.3 Limitations ............................................................................................................................ 187 6.5.4 Implications for Theory and Practice .................................................................................... 189 6.6

Summary: Managing Corporate OSS Efforts ............................................................................ 190

7

SUMMARY AND OUTLOOK: OSS IN THE 21ST CENTURY .................. 191

7.1

Suggestions for Further Research ............................................................................................... 192

7.2

The Future of Commercial OSS .................................................................................................. 194

BIBLIOGRAPHY ............................................................................................ 195

XV

List of Figures Figure 1:

Development of rating criteria of OSS usage during evaluation process .... 62

Figure 2:

Time windows in event studies (based on MacKinlay (1997)) .................... 73

Figure 3:

Distribution of events over time ................................................................... 75

Figure 4:

Projected CARs using only time and time-squared ..................................... 84

Figure 5:

Market valuation of the business models over time ..................................... 88

Figure 6:

Proprietary closed source software (PCSS) development ............................ 93

Figure 7:

Open source software (OSS) development .................................................. 94

Figure 8:

OSS development cycle (Senyard & Michlmayr, 2004) .............................. 95

Figure 9:

Research model ............................................................................................ 96

Figure 10: Business preparation phase ........................................................................ 149 Figure 11: Software preparation phase ........................................................................ 153 Figure 12: Types of motivation depending on regulatory style (Ryan & Deci, 2000) .................................................................................. 164 Figure 13: Interaction effect of monetary reward and strong norm for payment (using the normalized index for self-reported interest) .............................. 181 Figure 14: Structural equation model to measure effect of payment on total motivation................................................................................................... 183

XVII

List of Tables Table 1:

Differences and similarities between OSS and open innovation (West & Gallagher, 2006b) ......................................................................................... 17

Table 2: Table 3:

Benefits and risks of free revealing for different actors (Henkel, 2004b) .... 32 MySQL Network—Support levels ............................................................... 48

Table 4: Table 5:

Using of OSS vs. PCSS components—Interview results............................. 57 Arguments named in favor and against using OSS components in

Table 6:

software development .................................................................................. 58 Reduction in development cost experienced by firms using or

Table 7: Table 8:

developing OSS (N=20) ............................................................................... 59 Comparative evaluation of arguments on OSS use and development ......... 61 Business models in OSS............................................................................... 69

Table 9: List of all events ........................................................................................... 77 Table 10: Event descriptions ........................................................................................ 78 Table 11: Descriptive statistics (N=38) ........................................................................ 79 Table 12: Correlation table ........................................................................................... 80 Table 13: Statistics of CARi by business model........................................................... 81 Table 14: Results of OLS regression of CARi ............................................................. 81 Table 15: Robustness check of time variables in different model specifications......... 82 Table 16: Effect of timing of the announcement on CAR............................................ 84 Table 17: Results of OLS regression on CAR including the interaction term time x “business transformation” ................................................................. 87 Table 18: Survey participants by job function ........................................................... 104 Table 19: Spearman rank correlation (displayed only for p 0.4 reported) ....... 176 Table 43: Descriptive statistics for the control variables ........................................... 177 Table 44: Correlations (only reported if p < 0.1) ....................................................... 177 Table 45: Descriptive statistics split by grouping variables (std. dev. in parentheses) ................................................................................................ 178 Table 46: Descriptive statistics according to 2x2 design (std. dev. in parentheses) .. 178 Table 47: Effect of treatment on self-reported interest .............................................. 179 Table 48: Effect of treatment and strong norm for payment ((M)ANOVA F-values) ..................................................................................................... 179 Table 49: Descriptive statistics for fun measure by groups ....................................... 180 Table 50: Descriptive statistics for enjoyment measure by groups ............................ 180 Table 51: Descriptive statistics for index on self-reported interest by groups ........... 180 Table 52: Results of OLS regression for self-reported interest .................................. 181 Table 53: Effect of monetary rewards on total motivation......................................... 182 Table 54: Results of OLS regression for total motivation .......................................... 182 Table 55: Extrinsic motivational factors depending on strong norm for payment ..... 184 Table 56: Motivational factors in past projects .......................................................... 185 Table 57: Extrinsic motivational factors of participants in “treatment * strong norm for payment” group vs. rest of sample .............................................. 186

XIX

List of Equations Equation 1: Calculation of expected returns ................................................................... 75 Equation 2: Calculation of abnormal returns .................................................................. 76 Equation 3: Calculation of cumulative abnormal returns for a security ......................... 76 Equation 4: Calculation of abnormal returns for all securities on one day ..................... 76 Equation 5: Calculation of average cumulative abnormal returns .................................. 76 Equation 6: Illustrating cluster differences ................................................................... 132

XXI

List of Abbreviations ANOVA API

Analysis of variance Application programming interface

AR BSD

Abnormal return Berkeley Software Distribution

bus. bzw.

Business beziehungsweise

CAR cf.

Cumulative abnormal return compare (also: consult)

CFI CIO DOI

(Bentler's) Comparative fit index Chief Information Officer Diffusion of Innovation

DrKW e.g.

Dresdner Kleinwort Wasserstein for example

F/OSS FAQs

Free and open source software (analogous: OSS/FS) Frequently asked questions

FLOSS FS

Free, libre, and open source software Free software

FSF GmbH

Free Software Foundation Gesellschaft mit beschränkter Haftung

GNU GPL H HTML

GNU's not UNIX (recursive acronym) GNU Public License Hypothesis Hypertext Markup Language

HTTP i.e.

Hypertext Transfer Protocol that is

IP IPO

Intellectual property Initial public offering

IS IT

Information systems Information technology

JSP KAI

Java Server Pages Kirton Adaption-innovation Inventory

KDE ln

K Desktop Environment Natural logarithm

LPGL MANOVA

GNU Library Public License (also: GNU "Lesser" Public License) Multivariate analysis of variance

Max

Maximum

XXII Mgrs.

Managers

Min MIT

Minimum Massachusetts Institute of Technology

Motiv. NCSA

Motivation National Center for Supercomputing Applications

NIH OLS

Not-invented-here Ordinary least squares

OS OSDL

Open source Open Source Development Labs

OSI OSS

Open Source Initiative Open source software

Paym. PBX PCSS

Payment Private branch exchange Proprietary closed source software

PHP R&D

Hypertext Preprocessor (programming language) Research & development

RISC RMSEA

Reduced instruction set computing Root mean square error of approximation

rpc S.D.

Remote procedure call Standard deviation

SDK Std. dev.

Software development kit Standard deviation

Std. err. SWOT

Standard error (also: Rob. std. err.: robust standard error) Strengths, weaknesses, opportunities, and threats

TAM TCO

Technology Acceptance Model Total cost of ownership

VC vs.

Venture capital, or: Venture capitalist versus

XML z.B.

Extensible Markup Language zum Beispiel

XXIII

Zusammenfassung Warum geben einige Firmen freiwillig ihr Wissen an ihre Wettbewerber weiter? Die aktuelle wissenschaftliche Diskussion zeigt auf, dass free revealing – also das bewusste Zulassen von Spillover-Effekten, welches gleichzeitig eine Aneignung möglicher Innovationsrenditen durch Patentierung oder Geheimhaltung unmöglich macht – in vielerlei Hinsicht vorteilhaft für eine Firma sein kann und gleichzeitig für viele Firmen in den verschiedensten Industrien anwendbar ist. Unklar ist jedoch, wie Firmen, die dem traditionellen privaten Innovationsmodell – d.h. privat in Innovation investieren, um auch selbst die Renditen abzuschöpfen – folgen, den Übergang zu einem offeneren Modell erfolgreich gestalten können. Unter diesem Gesichtspunkt soll diese Arbeit am Beispiel kommerziellen Open Source Software (OSS) Engagements, welches die Nutzung von OSS, Quellcodebeiträge zu existierenden OSS-Projekten und Quellcodefreigabe zur Neugründung eines durch die Firma geleiteten OSS-Projekts umfasst, versuchen, insbesondere zwei Fragen zu beantworten. Erstens, sieht die Firma selbst einen Vorteil in free revealing, so dass sie beabsichtigt, ein solches Verhalten auszuüben? Zweitens, wie können Firmen, die dies tun möchten, den Umstieg vom privaten zu einem offeneren Innovationsmodell vollziehen? Ein Blick auf die aktuelle wissenschaftliche Literatur, die sich mit solchen Innovationsmodellen befasst, zeigt, dass free revealing unter verschiedensten Umständen Wert für die Firma schaffen kann, was bedeutet, dass die Freigabe von geistigem Eigentum (IP) im Allgemeinen und kommerzielles OSS-Engagement im Speziellen vielfältige Vorteile für die Firma haben können. Für die Freigabe von eigenem Quellcode kann eine Firma diese Vorteile beispielsweise dadurch abschöpfen, dass sie eines von fünf Geschäftsmodellen (business transformation, cost or risk reduction, dual licensing, sale of complementary goods, sale of complementary services) wählt und gleichzeitig mögliche Nachteile, wie den ungewollten Abfluss von IP und den damit verbundenen möglichen Verlust von Wettbewerbsvorteilen, minimiert. Firmen, die aktuell dem privaten Innovationsmodell folgen, bzw., für den Rahmen dieser Arbeit, proprietäre Softwareentwicklung betreiben, können sich auf zwei Arten ein offeneres Innovationsmodell, wie z.B. kommerzielles OSS-Engagement, erschließen: top-down, also auf Initiative der Unternehmensleitung hin, oder bottom-up, also auf Initiative der Mitarbeiter. Offensichtlich ist jedoch in beiden Fällen die Unterstützung beider Gruppen nötig, damit die Firma den Übergang zu einem offeneren Innovationsmodell erfolgreich gestalten kann. Aus Sicht des Managements kann für alle drei Formen kommerziellen OSSEngagements – Nutzung, Mitarbeit an existierenden OSS-Projekten und Freigabe eigener proprietärer Software, um neue Projekte zu starten – eine Vorteilhaftigkeit gezeigt und somit Wert für das Unternehmen geschaffen werden. Wie in einer ersten empirischen Studie untersucht wird, beruht diese bei der Nutzung von OSS vor allem auf Kosteneinsparungen, jedoch auch auf einer möglichen Erhöhung von Qualität und Innovativität innerhalb der Firma. Bei der Freigabe eigener Software kann in einer weiteren Studie gezeigt werden, dass durch Kombination mit einem geeigneten Geschäftsmodell neues Umsatzpotenzial für die Firma erschlossen werden kann. Weiterhin wird festgestellt, dass das Management dieses Potenzial aktiv beeinflussen kann, indem es zum Einen das Geschäftsmodell, zum anderen aber auch den Anfangszeitpunkt einer solchen Initiative wählt.

XXIV Damit die Firma das Potenzial eines möglichen OSS-Engagements voll ausschöpfen kann, ist nicht nur die Bereitschaft des Managements, sondern insbesondere auch die der Angestellten notwendig. Jedoch beeinflusst ein intensiveres OSS-Engagement verschiedene Angestelltengruppen innerhalb einer Firma unterschiedlich. Daraus resultieren unterschiedliche Erwartungen und Anforderungen, die sich in einer entsprechend höheren oder geringeren Bereitschaft, das verstärkte OSS-Engagement der Firma zu tragen, äußern. In einer weiteren empirischen Studie wird herausgearbeitet, dass insbesondere Programmierer und Projektleiter, für die sich durch OSS große Prozessveränderungen in der Softwareentwicklung ergeben, im Vergleich zu anderen Gruppen skeptischer gegenüber OSS und OSS-Entwicklung gestimmt sind. Um ein erfolgreiches OSS-Engagement zu gewährleisten, werden verschiedene Maßnahmen aufgezeigt, auf welche Weise es der Firma gelingen könnte, durch eine schrittweise Einführung von OSS inklusive Fortbildungsmaßnahmen wie Schulungen, Verwendung von Promotoren und Schaffung geeigneter Rollen und Ansprechpartner, auch diese Gruppen für ein verstärktes OSS-Engagement zu gewinnen. Insgesamt lässt sich beobachten, dass eine Mehrheit der Mitarbeiter ein kommerzielles OSS-Engagement unterstützen würde. Die vorangehende Studie bestätigt die Vermutung, dass der Übergang von proprietärer Software zu OSS und von proprietärer Softwareentwicklung zu OSSEntwicklung die Firma vor erhebliche organisatorische Probleme stellt. In einer Benchmarkstudie, die mit mehreren etablierten IT-Firmen, die seit langem OSS und OSS-Entwicklung unterstützen, durchgeführt wurde, werden Prozesse abgeleitet, die für Firmen, für die ein solches Verhalten neu ist, als Wegweiser dienen können, um potenzielle Nachteile und Gefahren zu vermeiden. Insbesondere wird einen Modellprozess entwickelt, der für Firmen, die proprietären Quellcode als OSS freigeben möchten, als Leitfaden genutzt werden kann. Falls sich diese Firmen entschließen, ein solches Projekt aufzusetzen, müssen sie sich überlegen, wie sie es schaffen können, externe Entwickler dazu zu bringen, sich generell an dem Projekt zu beteiligen und idealerweise genau an jenen Aufgaben arbeiten, die für die Firma am kritischsten sind. Im Gegensatz zur Prinzipal-AgentenTheorie, die für so eine Situation das Anbieten von monetären Anreizen als Lösungsmöglichkeit vorschlüge, argumentiert die verhaltensökonomische und psychologische Literatur, dass dies durch eine Unterminierung der intrinsischen Motivation der externen Entwickler sogar einen nachteiligen Effekt ausüben könne. In einem Experiment mit über 200 Informatikstudenten wird jedoch festgestellt, dass letzteres nicht zutrifft, wenn der Entwickler, dem Geld angeboten wird, eine starke Norm für Bezahlung hat. Eine solche Norm existiert häufig im Bereich der OSSEntwicklung und so lange die Firma sicherstellt, dass dies in der Tat der Fall ist, bevor sie monetäre Anreize anbietet, können letztere sogar positiv wirken, indem sie der Firma helfen, externe Entwickler für das firmeneigene OSS-Projekt zu gewinnen. Insgesamt kann also gezeigt werden, dass beide Forschungsfragen positiv beantwortet werden können. Erstens ist häufig davon auszugehen, dass sowohl die Unternehmensführung, als auch die Mitarbeiter dem Beginn oder der Erhöhung eines kommerziellen OSS-Engagements wohl gesonnen sind, so dass die Firma als Ganzes bereit wäre, den Übergang vom privaten auf ein offeneres Innovationsmodell zu wagen, wenn dies für die Firma von Vorteil ist. Zweitens kann gezeigt werden, dass es Möglichkeiten gibt, diesen Weg erfolgreich zu beschreiten. Beispielsweise können die bewährten Prozesse von Firmen, die bereits jetzt im OSS-Umfeld aktiv sind, meist problemlos auf die eigene Firma übertragen werden. Zusätzlich sind traditionelle Methoden der Mitarbeiterführung und des Projektmanagements, z.B. die Vergabe monetärer Anreize, auch für OSS-Projekte weiterhin gültig.

XXV

Abstract Why do firms voluntarily give away knowledge to their competitors? The academic literature tells us that free revealing, that is, the company letting spillovers happen on purpose thereby giving up on appropriating future rents from this knowledge through patents or secrecy, may bring several advantages to a corporation and is likely to be applicable to many firms in different industries. What we do not yet know, however, is how firms following the traditional private model of innovation, that is, privately investing into innovation to privately appropriate the rents from it, can make the transition to such new behavior. In particular, this thesis will try to answer two questions. First, do firms perceive a benefit residing in freely revealing intellectual property (IP) so that they would intend to engage in such behavior? Second, assuming they indeed wanted to do so, how can a firm adhering to the private model of innovation make the transition to a more open one? Using the example of firm engagement in open source software (OSS), where engagement encompasses using OSS, contributing to existing public OSS projects, and releasing proprietary software to start a new OSS project, this thesis will try to answer these questions. First, looking at the academic literature on models other than the private model of innovation, there are several circumstances under which free revealing may potentially be beneficial to a firm, showing that the release of IP in general, and corporate OSS engagement in particular, can have numerous advantages. For example for releasing proprietary software as OSS, by choosing one of five available business models (business transformation, cost or risk reduction, dual licensing, sale of complementary goods, sale of complementary services) firms should be able to make use of these advantages, while minimizing potential downsides such as a loss of competitive advantage through a loss of IP. Looking at organizations following the private model of innovation, or, in this case, proprietary closed source software (PCSS) development, there are two ways in which a more open IP regime, such as corporate OSS engagement, may be introduced to the corporation: top-down, that is, initiated by top management and later adopted by the employees, or, vice versa, bottom-up. Eventually, in both cases, both groups need to support the firm’s move to the new IP regime in order for the firm to be able to successfully engage in it. Management is shown to potentially support all three forms of firm engagement in OSS. In two empirical studies, management is found to actually perceive the following advantages. First, using OSS is thought to enable the firm to reduce development costs, and also to increase product quality and innovativeness of the firm. Second, a positive reaction by the capital market to firms freely revealing their source code can be observed provided the firm chooses an adequate business model to do this. Furthermore, management can be shown to be able to actively influence this potential for value creation by choosing the respective business model and strategically placing the launch date of such an initiative into a phase of positive investor sentiment. To become a success for the firm, corporate OSS engagement does not only depend on the support of top-level management, but also on that of the regular members of the organization, its employees. When analyzing the traditional PCSS development process, it becomes obvious that increased corporate OSS engagement affects different job functions within the firm differently, leading to a higher or lower willingness of the respective groups to support the respective actions taken by management. In another empirical study, it will be shown that in particular programmers and project managers are exposed

XXVI to considerable organizational change in the software development process caused by OSS and are consequently more skeptical towards an increase in corporate OSS engagement. In order to enable a company to tap the full potential such an engagement might have to offer, several recommendations on how management might win over these groups are derived, such as through a step-by-step intensification of corporate OSS engagement, by offering training, or by identifying promotors. Still, overall, employees are favorable to an increase in corporate OSS engagement. As further confirmed in the last of the above studies, moving from PCSS to OSS and from PCSS to OSS development poses considerable organizational difficulties to the firm. In a benchmark study conducted with several corporations that have long been active in OSS and OSS development, processes are laid out for the different modes of OSS engagements that firms new to this might follow to counter potential disadvantages and threats. In particular, a model process of how PCSS firms might release proprietary software to start a new OSS project is developed. Having launched such a project, in order for it to become a success for the corporation, the firm will need to attract outside developers to work on the project and, ideally, in particular on those tasks that are most critical to the organization. Whereas agency theory would argue that this might easily be achieved by offering monetary rewards to potential project participants, psychology and behavioral economics literature contradict this opinion, saying that this may reduce the motivation of those people to contribute as the monetary reward would undermine their intrinsic motivation. In a scenario experiment with more than 200 students of computer science, the latter is found not to apply under certain circumstances, namely when the developer offered the monetary reward has a strong norm for payment. Such a norm can often be found in OSS development, and as long as the organization makes sure it exists before offering monetary rewards, those may even exhibit positive effects and help the organization attract external contributors. Overall, both research questions can be answered positively. First, both top management and the employees of the organization can often be expected to be positive towards initiating or increasing corporate OSS engagement, so that the organization as a whole should be willing to move away from the proprietary IP paradigm to a more open one when such a behavior is beneficial to the firm. Second, there are ways in which firms can successfully do so as both role models to follow and the processes those adhere to are available and, more importantly, because these processes should be transferable to many firms. Also, traditional methods of human resources management and project management, such as employee incentivizing, will similarly apply to closed IP regimes and more open ones.

Introduction: Commercial Open Source Software

1

1 Introduction: Commercial Open Source Software “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 certification mark testifying to its quality.” 1

1.1 Development of the Open Source Phenomenon Open Source and its use in companies have come a long way since April 8, 1998, the day when Open Source Software (OSS) was “invented” (Tiemann, 2006)2, that is, the term OSS was created to describe this special kind of software, the most prominent feature of which seems to be that it is free—gratis, that is. Since then, commercial use of OSS has passed through phases of curiosity, hype, and disillusionment before finally arriving at pragmatism (Driver et al., 2005). Although the once dazzling stock market valuations of companies such as Red Hat and VA Linux3 have settled at more sober levels, OSS has nevertheless gained a strong a foothold in commercial settings; OSS is becoming more and more widely adopted in a rapidly-changing software industry. When asked in 2002, one third of the top 25 software companies were using Open Source Software (OSS). 12% had some sort of minor OSS engagement going, whereas the majority of the 25 companies was not using OSS at all (Wichmann, 2002). From the top 25 software companies of 2002, many do not exist any more.4 Of the remaining firms, there is almost none left that has no engagement in OSS at all. Also, whereas cost cutting has often been found to be the single most important reason for companies to start using OSS in the past (LaMonica, 2004), quality and other factors are becoming more well-known and more respected. Consequently, OSS has become widely established—even to a degree so high that removing it would occasion the breakdown of many firms’ IT infrastructures (Driver & Weiss, 2005; Goulde, 2006), and even, for example in the electronics industry, of numerous products. OSS applications such as the operating system Linux or the web server Apache are only two examples of this.

1

2 3 4

Open Source Initiative (OSI) – Frequently Asked Questions, http://www.opensource.org/advocacy/faq.php, retrieved March 10, 2006. Also see Moody (2001, pp. 167-172). VA Linux is called SourceForge, Inc. (NASDAQ: LNUX) nowadays. For example, BEA has been acquired by Oracle, and Macromedia by Adobe Software.

2

Introduction: Commercial Open Source Software It is also interesting to note that many companies are now facing open source com-

petition, increasing pressure and pace in the industry even more. This concerns primarily IT products such as operating systems and web servers, however, OSS is moving both upwards in the software stack as well as “sideways” into industries where IT plays an integral but secondary role, such as telecommunications or electronics. With respect to the former, OSS has started to penetrate areas such as enterprise resource planning, project management, and office software. Regarding the latter, the example of Asterisk—an open source PBX softswitch5—shows that using OSS may enable small firms to compete with industry giants such as Lucent-Alcatel or Siemens. A $13.8 million investment made by well-known venture capitalist Matrix Partners in September 2006 shows that Asterisk should not be underestimated by the established players in this market (Kraeuter, 2006). However, it is not only the use of OSS that has increased. Over the last few years, we have seen an increase in firms participating in existing OSS projects. OSS organizations such as the Eclipse foundation, the Apache Foundation, or the Open Source Development Labs (OSDL) with its Mobile Linux initiative have constantly been growing in size over the last years—with most new members being commercial firms building on the platforms established in the joint OSS efforts. IBM, just for the Linux OSS operating system, is estimated to spend 100 million dollars annually—whereas it would cost about 500 million dollars per year to maintain a comparable proprietary system in-house (CED, 2006). Furthermore, even starting new OSS projects has become more popular amongst firms. For example, several worldwide IT players announced the release of their major development kits as OSS, with Adobe for its Flex Software Development Kit (SDK)— and later, even Adobe Flex itself (Adobe, 2007)—and Sun for its Java Development Kit (JDK)—and later, too, Java itself—, under OSS licenses (SUN, 2007). Other firms that have released the source code to some of their products and made them OSS include IBM, SAP, or Oracle. Moreover, Google launched its third “Summer of Code” in 2007 with over 900 accepted OSS projects sponsored by the search engine provider (Google, 2007). And even the most prominent global software firm known for its criticism on open source, Microsoft, is engaging in OSS: it has closed a deal with Novell by the end 5

In general, the PBX is private since it serves a user company that wants to have its own branch to save some money on, for example, internal calls. This is done by having the exchanging or switching of telephone calls done locally, inside the company. The PBX allows multiple lines inside the office to connect without each phone requiring a separate outside line. Because fax machines, modems, and many other communication devices can be connected to a PBX, extension developed to a generic term describing all devices connected to a PBX. The PBXs are connected to the outside world by a number of lines called trunk lines. The term “softswitch” indicates that the switching is done entirely software-based (Alexy, 2007).

Introduction: Commercial Open Source Software

3

of 2006, aiming to improve interaction between the Linux and Microsoft operating systems (Novell, 2006). What is more, Microsoft is now hosting websites on OSS at Microsoft in general, OSS projects for Microsoft platforms, and the original OSS interoperability lab “Port 25.” Also, Microsoft has entered its two shared source licenses into the Open Source Initiative (OSI) approval process; they became official OSS licenses after the OSI announced it had accepted them as such in October 2007.6

1.2 Motivation The last two points concerning firms contributing source code to public OSS projects and releasing proprietary software to start new OSS projects seem somewhat dazzling. Firms supposedly invest in R&D to generate private rents, the appropriability of which should be enhanced by legal mechanisms such as patenting or secrecy (Demsetz, 1967; Teece, 1986)—not by giving away the blue prints of the innovation. Still, as for example the firm engagement in OSS reported above suggests, conditions under which such behavior is beneficial to the firms are very likely to exist, that is, sometimes, companies seem to be able to gain more from freely giving away the innovation and the knowledge underlying it than they could have possibly received from keeping it to themselves. Whereas past research has indeed confirmed that such behavior can in fact be beneficial to a corporation (see, e.g., Allen, 1983; Harhoff, Henkel, & von Hippel, 2003; von Hippel & von Krogh, 2003), it has also shown that such behavior clearly contradicts established policies in many corporations, as those usually tend to focus on protecting intellectual property rather than releasing it into the open (Chesbrough, 2003, pp. 40-41 and 56-57). For most organizations, consequently, freely giving away their intellectual property would imply new behavior of which they now have to decide whether or not to engage in it. The outcome of this decision depends on two questions the organization needs to answer for itself: is it the right thing for us to do, and, if so, how can we do it right? The first question will be answered positively, if, overall, the firm can derive more benefit from freely giving away its knowledge than it can from protecting it. Whereas different advantages and disadvantages have been associated with this,7 suggesting a potential for value creation resulting from freely revealing one’s knowledge, the current

6 7

The respective licenses are the Microsoft Public License and the Microsoft Reciprocal License. These will be elaborated on in Chapter 2 of this thesis, which is why I have refrained from reciting them here.

4

Introduction: Commercial Open Source Software

literature is mostly silent about the costs that are associated with the change inherent in moving from a proprietary to a more open intellectual property regime.8 However, with respect to the decision of supporting such efforts when intended by the corporation, the consideration of these costs is of vital importance. For example, different firms and in particular their employees, that is, with regard to their job function or skill level, will evaluate these changes differently (Kotter & Schlesinger, 1979), which might strongly affect whether, and, if so, how, the organization as a whole is favorable towards migrating to the more open intellectual property regime. Regarding the second question, the current literature also fails to give a coherent account of how firms deciding in favor of making the move from a proprietary intellectual property regime to a more open one can potentially do so, let alone do so successfully.

1.3 Research Questions In this thesis, I will try to address the above issues using the example of corporate OSS engagement in OSS. Thus, when specifically looking at the adoption of OSS by corporations—where corporate adoption includes using OSS, contributing to existing public OSS projects, and releasing proprietary software to start a new public OSS project—two basic questions can be derived: “Why should corporations be doing this?” (Is it the right thing to do?) and—having answered the first questions positively “How can they do it?” (How to do it right?). With respect to the OSS phenomenon, many researchers have addressed the issues of OSS business models, collaboration between firms and the OSS community, and inter-firm OSS-based collaborative innovation processes, resulting in the pros and cons of commercial OSS engagement by now being quite well understood. Little, however, is yet known about how firms become OSS adopters and, afterwards, how they should manage their OSS efforts. In this context, several questions arise. In which fashion— top-down or bottom-up—is OSS introduced to the organization? How do OSS and OSS-based development practices spread within the firm? Who promotes OSS, and do particular job functions and personal characteristics favorably dispose individuals to lobbying for its adoption? Do the employees actually want to work with and on OSS and OSS projects, and, if so, under which conditions? Finally, how do firms manage

8

Exceptions to this are mainly to be found in the IT literature. For example, Senyard and Michlmayr (2004) analyze some of the differences between proprietary and OSS development. Goldman & Gabriel (2005), also with respect to OSS, give a practitioners’ account of how the role of the programmer changes from proprietary to OSS development.

Introduction: Commercial Open Source Software

5

their OSS efforts, and, in particular, how do proprietary software firms manage the transition to a paradigm more supportive of OSS?

1.4 Research Context Open Source Software has become a more and more important research topic since Eric Raymond’s famous and influential essay “The Cathedral and the Bazaar” was published in 1997, where the basic principles underlying of what was to become the OSS community were first explained to a general public. Raymond defined concepts such as “Linus’ Law” and the “plausible promise”9 that have remained essential to the research on OSS until today, including potential business models suggested by him. The first academic publication thereafter came from Frank Hecker (1999) who explained in which ways commercial firms might benefit from OSS. Since then, many scholars from various disciplines have complemented the research on OSS. Although there have been articles published on topics as diverse as business models around OSS (see, e.g., Bonaccorsi & Rossi, 2006; Dahlander, 2005; Feller & Fitzgerald, 2001; Grand, von Krogh, Leonard, & Swap, 2004; Hecker, 1999; Lerner & Tirole, 2002; Raymond, 2001a, 2001b; West, 2003; Wichmann, 2002), collaboration between firms and the open source community (see, e.g., Bessen, 2005; Bonaccorsi, Giannangeli, & Rossi, 2006; Dahlander & Magnusson, 2005; Dahlander & Wallin, 2006; Henkel, 2008; Shah, 2006), inter-firm collaborative innovation processes based on OSS (see, e.g., Henkel, 2006; Nuvolari, 2001b; West & Gallagher, 2006a), or the motivation of individual programmers to participate in public OSS projects (see, e.g., Hars & Ou, 2002; Lakhani & Wolf, 2005; Stewart & Gosain, 2006), none of those authors has coherently and satisfactory answered the research questions asked in the two preceding sections. Regarding the adoption of OSS and OSS development practices and the diffusion and management of these within the organization, only anecdotal evidence (Henkel, 2004b; Moody, 2001, 315; Raymond, 2001a, 131-132, 2001b, 23) emphasizing the importance of grassroots initiatives by developers exist. Whereas this is to some degree supported by survey results that find that software professionals tend to champion OSS (Henkel, 2008) systematic evidence is still lacking. Because active engagement in OSS might be vital to firms in terms of efficiency gains, standard setting, defining the rules of competition, and responding to competitive threats generated by OSS, IT profession9

Please see Section 2.1.3 for an explanation of some core principles of OSS.

6

Introduction: Commercial Open Source Software

als’ disposition towards and willingness to promote its adoption are highly relevant. Yet, understanding of the process of adoption, diffusion, and management of OSS and OSS development practices within firms remains largely a black box. Considering the management of corporate OSS efforts, several practitioner guidelines exist (see, e.g., Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn, Bretschneider, & Renk, 2004), however, they often miss some elements of the adoption process; they may focus on the corporation and neglect its environment or vice versa. They may as well lack scientific depth, or—often being one-time case examples without secondary sources—reliable data. Academic publications on the effects of organizational participation in public OSS projects or the management of corporate OSS efforts are rare, and issues coming with an organizational innovation have barely been tackled for OSS (for exceptions, see, e.g., Grand et al., 2004; Stewart, Ammeter, & Maruping, 2006). Consequently, no coherent and consistent guideline exists showing how firms following a proprietary software paradigm might open up to also (or better) allow for using OSS, contributing to existing public OSS projects, and releasing proprietary software as OSS. This work will try to close the gap in current academic research. There are several ways in which OSS and OSS development practices can be employed to bring benefit to the corporation. As will be shown, there are conditions under which all modes of corporate OSS engagement—that is, using existing OSS, contributing to existing public OSS projects, and releasing proprietary software under an OSS license to launch a new public project—discussed in this thesis may be advantageous to the corporation thinking about doing so. What is more, evidence will be given indicating that employees, on average, would like to engage in OSS at work—not for their own sake, but mainly for the sake of their employer. In this context, evidence will be provided that it is not necessarily only developers that drive the adoption and diffusion of OSS in corporations, but that employees with other job functions such as software testers or software architects are more favorably disposed to increasing corporate involvement in OSS activities. With respect to the processes to manage OSS projects, a benchmark study with several firms actively engaged in OSS will illustrate that and how OSS in firms can be managed both effectively and efficiently. It will also be shown that, despite the sometimes altruistic and money-despising public perception of OSS, in order to manage individuals—that is, both employees of the firm and external contributors—firms may well think about using both monetary and non-monetary rewards. As long as individuals perceive their task to be performed autonomously, monetary rewards might even have positive effects.

Introduction: Commercial Open Source Software

7

1.5 Structural Outline Following this introductory chapter, the remainder of this thesis is segmented into three parts, two of which contain multiple chapters. Part one consists of Chapter 2 and will provide important definitions for this work as well as an extensive overview of the current academic literature. After a definition of OSS, the basic underlying concepts will be introduced. Next, the various advantages and disadvantages that may result for a corporation when deciding to engage in OSS will be explained. Derived from this, five different business models companies may choose from when thinking about setting up a business around OSS will be presented. Finally, consequences of engaging in OSS both for the firm and its employees will be highlighted, which sets the stage for the next part of this thesis. Part two includes Chapters 3 and 4 and deals with organizational adoption of OSS. As will be shown, OSS may enter the organization either in a top-down or bottomup fashion but, ideally, should receive support from both directions. In Chapter 3, I will thus look at how top management and the capital market perceive OSS and its value to the corporation. First, management’s perception of the pros and cons of using OSS will be looked at. Then, in an event study using capital market data, I will analyze how and why contributing source code to existing OSS projects and releasing proprietary software as OSS may be valuable to the firm. Altogether, this will help explaining why management might decide in favor of an increased corporate OSS engagement. Chapter 4 will look at corporate OSS engagement through the eyes of the employees to find out who might support or resist OSS and why. Even though management decision on OSS might have been favorably, if employees resist it in day-to-day operations, any corporate OSS effort is doomed to fail. I will analyze how different groups of employees have distinctively different opinions towards and perceptions of OSS and what attitudes toward corporate OSS engagement result from this. Also, recommendations to overcome potential resistance are derived. Part three encompasses Chapters 5 and 6 and is about how organizations can manage OSS and the related processes. Chapter 5 will give the results of a benchmark study conducted with several firms long active in OSS showing how they manage the use of existing OSS, contributions of company-owned source code to existing OSS projects, and the release of proprietary software as OSS. For the latter, a model process is developed, and recommendations on how to generally manage the resulting corporate-sponsored OSS project are given. In Chapter 6, I will turn to the problem of direct-

8

Introduction: Commercial Open Source Software

ing contributors’ efforts in corporate-sponsored OSS projects and explain how corporations can manage their own employees as well as third-party contributors to work in a way that is best for the corporation. In this chapter, motivation and incentives, including possibly negative effects of monetary rewards on motivation, are analyzed. Finally, Chapter 7 summarizes the findings and contributions of this work and gives an outlook on potential future developments and research directions.

Open Source Software: Source of Innovation?

9

2 Open Source Software: Source of Innovation? In this chapter, first, a definition of the term Open Source Software (OSS) and an introduction to the basic ideas behind it will be given. Next, several concepts from economic and management literature that may help explain the OSS phenomenon will be reviewed. Thereafter, I will take a look at the advantages and disadvantages that may result for a firm from different modes of OSS engagement. From this, a set of business models a firm thinking about releasing proprietary software as OSS may choose from will be derived. Finally, I will reflect on the implications corporate OSS engagement may have both for the corporation itself as well as its employees, which will provide the theoretical basis for the next part of this thesis.

2.1 Definition and History of OSS Open Source Software (OSS) is seemingly a rather new phenomenon, as it was only “started” in 1998, when the term OSS was coined (Tiemann, 2006). Yet, current economics and management literature, reviewed in this and the following Section 2.2, shows that OSS is neither new nor are its ideas and underlying principles necessarily limited to the IT sector.

2.1.1 Definition When talking about OSS, first of all, the term itself needs to be clearly defined and separated from similar terms such as free software (FS), free and open software (F/OSS), or free/libre/open source software (FLOSS). Especially since “free software” and “open source software” have been used synonymously and interchangeably in the literature, it is important to note and understand the differences between them. “Free Software” is the oldest of the terms and has been coined by Richard Stallman in order to encourage a culture of information sharing he had both grown accustomed to and fond of during his work at the Artificial Intelligence Lab at the Massachusetts Institute of Technology (MIT). Stallman intended to create GNU, 10 a free operating system resembling UNIX which had become more and more locked in by proprietary vendors, that is, proprietary vendors had become less and less willing to share the source code of

10

GNU is a recursive acronym for “GNU’s not UNIX”.

10

Open Source Software: Source of Innovation?

their UNIX products. In 1984, Stallman formally started the project by working on a compiler and, later, an editor. In 1985, he founded the Free Software Foundation (FSF) to protect free access to software and its source code for all developers (Moody, 2001, pp. 14-23). The main goal of free software is, following Stallman’s definition, freedom of the software with respect to its source code: “Free software is a matter of liberty, not price. To understand the concept, you should think of free as in ‘free speech’, not as in ‘free beer’.” (FSF, 2007)

In order for a software to be really free, four “freedoms” have to be adhered to (FSF, 2007): -

The freedom to run the program, for any purpose.

-

The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this.

-

The freedom to redistribute copies so you can help your neighbor.

-

The freedom to improve the program, and release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition for this.

Stallman himself crafted the first free software licenses for his programs and later merged them to create the GNU General Public License (GPL). However, due to the restrictions the GPL imposed on the software,11 it was hard to use software under the GPL together with software offered under “proprietary” licenses, that is, software by vendors who did not give free access to their code. As a result, in early 1997, Bruce Perens drafted the Debian Software Guidelines (Moody, 2001, pp. 166-167). In 1998, in the course of Netscape Communications opening the source code of its Communicator Browser product, these guidelines were adopted by several figures spearheading the software development community. They felt that “free software” was scaring away companies whose participation in the software development and distribution process they reckoned to be of vital importance. After coining the term “open source” to reflect this, they founded the “Open Source Initiative” (OSI) as a governing body and defined open source software (OSS) to be software under an OSS license. OSS licenses could basically be created by everybody, but would have to adhere to the definition of the OSI to be allowed to be officially called an OSS license.12 Version 1.9 11 12

These restrictions will be described more closely in the following section. To officially be approved by the OSI, a license is submitted to the OSI by the author. Together with the authors and, to some degree, the general public, the OSI then discusses the license, focusing on its compatibility with the

Open Source Software: Source of Innovation?

11

of the definition of the OSI encompassed the following ten points derived from the Debian Software Guidelines (OSI, 2001): 1.

Free Redistribution of the Software

2.

(Availability of the) Source Code

3.

(Possibility to Make) Derived Works

4.

Integrity of The Author’s Source Code

5.

No Discrimination Against Persons or Groups

6.

No Discrimination Against Field of Endeavor

7.

Distribution of License

8.

License Must Not be Specific to a Product

9.

License Must Not Restrict Other Software

10. License Must Be Technology-Neutral

Whereas software under the GPL or similar licenses would both be considered OSS and FS, several OSS licenses did not guarantee as much “freedom” as to call the respective software “free software.” In particular, the Berkeley Software Distribution (BSD) license and its derivatives allowed for the source code to be integrated into proprietary applications without the obligation to release the source code, as long as a copyright note was included. The differences between these two groups of licenses shall now be scrutinized.

2.1.2 OSS Licenses Two basic kinds of OSS licenses exist. On the one hand, copyleft licenses such as the GPL forbid distributors to make changes to the licensing terms when distributing or modifying the software. Every copy of the software, even if changed, will be under the same license as the original program, and, as will be explaining in the following, software building on GPLed programs might also have to be put under the GPL itself, which is the reason for the so-called viral effect of copylefted software. As mentioned before, the GPL aims at securing the free (but not necessarily gratis) distribution of software including its source code. First, everyone distributing a program licensed under the GPL has to provide the users with the full source code to the program upon request. Second, derived works of software under the GPL have to be released under the GPL as well. According to the definition by the Free Software Foundation, derived work includes software that loads together with the existing GPLed code and OSS definition. If compatibility is found or achieved (i.e., the author(s) make(s) changes to the original licenses when requested by the OSI), approval is announced by the OSI and the license is added to its list.

12

Open Source Software: Source of Innovation? “depends both on the mechanism of communication (exec, pipes, rpc, [13] function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets, and command-line arguments are communication mechanisms normally used between two separate programs. Thus, when they are used for communication, the modules are usually separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program” (FSF, 2006).

However, please note that none of the criteria defining what a derived work exactly is have ever been confirmed or rebutted in court anywhere in the world (Contreras Jr., Juran, & Kummermehr, 2005). Programs that link statically to GPL libraries are also derived work, however, legal experts are undecided on dynamically linked GPL libraries. A way to circumvent this problem is to look for libraries under the GNU Library or “Lesser” General Public License (LGPL) that allows other programs to access the LGPLed software without forcing the LGPL on it. Furthermore, it is possible to get permission to link the GPLed library without having to put the software under the GPL from the copyright holders of the library who can provide users with a special exception. The same exception is also possible the other way round—that is, when programming GPLed software that requires a proprietary library or runtime environment, in which case “the source code distributed need not include anything that is normally distributed […] with the major components […] of the operating system on which the executable runs, unless that component itself accompanies the executable.” (FSF, 2006) Programs independent of GPLed software can be put under a license of choice and may well be kept proprietary. A mere aggregation of two or more programs on the same medium, such as a hard disk or CD-ROM, has no effect on this (FSF, 2006; St. Laurent, 2004, p. 40). Under German law, the GPL has been confirmed in court in 2004—except for the non-warranty and non-indemnity clauses (Landgericht München I, 2004). When including GPLed software in a package that is sold commercially, it is thus recommended to include respective clauses that are compliant to German law in the standard business conditions (Meets, 2006). Again, this does not include the above paragraphs on derived works, but just the general validity of the GPL as a license. 13

Exec: command that allows or enables executing another command or program. In this case, this would imply that the software executes the GPLed program or one or more of its subroutines. Pipe(line): in software engineering, this means that the output of one process is used as input of the next one. RPC: remote procedure call. In most cases, this means that a program located on one computer starts a computer program or one of its subroutines on another computer.

Open Source Software: Source of Innovation?

13

Apart from copyleft licenses, there are non-copyleft licenses, such as the BSD license. Whereas the original software is of course OSS, distributors and modifiers of the software are in this case allowed to change the license of the software and even to make proprietary copies of the software—in most cases even without changing the source code. Usually, only minor obligations exist, such as keeping a copyright note of the original authors. For example, some parts of Microsoft’s Internet Explorer 6 were based on BSD-licensed NCSA Mosaic, a web browser introduced by the National Center for Supercomputing Applications (NCSA) in 1993, and the copyright note of which was to be found at “Help Æ About.” It is logical that corporate customers that plan on integrating the OSS into their proprietary product would clearly favor such a non-copyleft license (Lerner & Tirole, 2005; St. Laurent, 2004). Still, choosing a BSD-style license is not necessarily the best option a corporation may choose when engaging in OSS as potential users and co-developers may feel that this choice of license contradicts the open spirit of FS/OSS or even fear that the company might later hijack the project, that is, exploit the programming skills of the OSS community to then develop a proprietary software program. Especially when the corporation is trying to set a standard—which implies getting as many users as possible (also see Section 2.4.1)—choosing a copyleft license might well be in the best interest of a corporation.

2.1.3 Some Core Principles of Open Source Software Having given a definition of OSS based on the license the software has been put under and having introduced the two most common forms of those, I will now turn to explain some of the core principles underlying OSS development. I will also comment on their generalizibility, that is, on their applicability beyond OSS. “Scratching an Itch”, “Plausible Promise”, and “Release early. Release often.” With his essay “The Cathedral and the Bazaar,” Eric Raymond (2001b) was the first who tried to identify the principles underlying of what was later to become known as OSS.14 In comparing the classic monolithic approach of software development (cathedral) to the distributed approach followed in OSS (bazaar), Raymond’s first observation was that “[e]very good work of software starts by scratching a developer’s personal itch.” Especially in OSS, we see that a majority of projects, rather than all projects, have been 14

Raymond’s first draft was published in 1997, when the term open source did not yet exist. However, Raymond was part of the group to coin the term for exactly that type of software development and provision he had described in his essay. He changed later versions of his essay to include the term “open source” (Raymond, 2002).

14

Open Source Software: Source of Innovation?

written by individual programmers who tried to solve an individual problem they encountered (Krishnamurthy, 2002). Ideally, if someone else had encountered a similar problem before, the individual could either use this solution to solve their issue or, if necessary, improve or adapt the existing software—otherwise, he or she would have to start from scratch. Now, if the problem the individual developer was trying to solve was of a more general nature, there may be many others facing similar problems. By making the source code to the solution publicly available—as had been tradition in hacker15 communities since the 1960s—and updating it frequently, that is, whenever a significant improvement has been made, interest might be stirred and other people will start using or even making contributions to what was initially planned to become a solution to an individual’s problem. In particular, with the spread of the Internet in the 1990s, the number of potential co-developers has grown exponentially (Moody, 2001; Raymond, 2001b). An important precondition to successfully attracting new users and developers is that the released software shows “plausible promise”, that is, (1) it compiles 16 and (2) it must be good enough to convince others that this project can evolve into a really good project in the near future, thereby solving the problem it was intended to to a satisfactory degree. “Linus’s Law”, “Broadcast Search”, and “Distributed Innovation.” Raymond’s most famous contribution to the OSS literature is what he has named “Linus’s Law,” phrased “Given enough eyeballs, all bugs are shallow.” In fact—apart from the false assumption that OSS comes necessarily for free, that is, gratis—, this is probably the most widely and publicly known advantage of OSS: if people use the software and can look at the source code, then they might be able to find errors and point them out the developers or even correct them themselves. More importantly, the more people are using the software, the more likely it is that such errors in the software—so-called bugs— are found and corrected. Although Raymond (2001b) explains this using similar argumentation as is underlying the idea of the “wisdom of crowds” (Surowiecki, 2004), that is, that the average opinion of a group is more reliable than that of a randomly selected individual, the concepts of “broadcast search” or “distributed innovation” (Lakhani &

15

16

Contrary to common usage, in IT terms, “hacker” is a positive term standing for “expert programmers or networking wizards” as opposed to “crackers,” a term that describes people breaking into computer systems. “The basic difference is this: hackers build things, crackers break them.” (Raymond, 2001c) A compiler is “a computer program that translates an entire set of instructions written in a higher-level symbolic language (as C) into machine language before the instructions can be executed.” (Merriam-Webster, 2008)

Open Source Software: Source of Innovation?

15

Jeppesen, 2007; Lakhani, Jeppesen, Lohse, & Panetta, 2007; Weber, 2004) seem more applicable as a theoretical foundation of Linus’s Law. In broadcast search, rather than looking for an average or consensus solution, one person spreads one very specific problem to a large group of people trying to reach individuals that have the knowledge to solve the problem readily at hand. Consequently, the person spreading the problem is looking for only one solution that solves his or her initial problem. This means, neither the total number of suggestions nor the average solution matter, as long as one suggested solution really solves the developer’s problem (Lakhani & Jeppesen, 2007; Lakhani et al., 2007). Still, if the total number of suggestions increases, the likelihood that one of those indeed suits the programmer’s needs will also increase (Raymond, 2001b). Weber (2004) identifies four underlying principles for such broadcast search or distributed innovation processes to work: -

empower people to experiment

-

enable bits of information to find each other

-

structure information so it can recombine with other pieces of information

-

create a governance system that sustains the process

and finds all of them can be applied for OSS. In turn, should there be other situations in which these four principles can be sustained, the OSS development methodology might well be applicable. Recent work by Lakhani and Jeppesen (Lakhani & Jeppesen, 2007; Lakhani et al., 2007) suggests that this may well be the case, showing the approach of distributed problem solving common in OSS can be transferred to other areas.

2.1.4 Summary Only at first glance, OSS seems to be a new, detached phenomenon pushed by a group of geeks. Whereas it may well have originated as such, it has become clear there is more to it. Especially the OSS development methodology seems to exhibit a large potential to improve the software development process in particular and, possibly, development processes in general. Both may bear considerable positive implications for individuals and firms alike. Existing theories may help us to understand the benefits OSS can bring to us. I have already introduced the concepts of distributed innovation and broadcast search. However, those are rather new to the academic literature, and have only been scarcely or partially tested so far. Yet, there is a large body of academic literature that can explain how

16

Open Source Software: Source of Innovation?

OSS works and how it can potentially be beneficially, as will be shown in the next section.

2.2 OSS as a Source of Innovation OSS, as opposed to proprietary closed source software (PCSS) development, resembles what has been described as collective invention or open, private-collective, or user innovation (Allen, 1983; Chesbrough, 2003; von Hippel, 1986, 1988; von Hippel & von Krogh, 2003; von Hippel, 2005) in both economics and management literature. That is, different authors have used these only partly overlapping concepts to explain the potential benefits of OSS. Whereas all of them to some degree explain why companies freely revealing information necessary for an innovation, that is, voluntarily allowing spillovers to happen, may benefit from such behavior, not all of them equally apply to OSS and OSS development. In the following, the existing literature will be reviewed to see to which extent these different concepts may assist us in better understanding the OSS phenomenon.

2.2.1 Open Innovation The concept of open innovation was first introduced by Henry Chesbrough (2003) who defined it somewhat limited as allowing external information derived from sources such as cooperations with universities or (corporate) venture capital efforts become part of the corporate innovation process. In this sense, “open” was thus referring to the corporation allowing external information to pass the boundaries of the firm from the outside to the inside only. Chesbrough’s main idea was that companies, no matter how many good engineers they had, needed to accept that there were more and maybe even smarter people not working for them outside the corporate boundaries. They should thus not rely entirely on their own R&D personnel, but rather try and tap those external sources through licensing arrangements, acquisitions, or venture capital. On the other hand, the firm should license out all inventions it is not using as part of its main business, the purpose of which, however, not being a sharing of information in the notion of collective invention (see below), but rather freeing up resources to focus on core competences and to acquire information relevant to those. The protection of intellectual property through patents plays a vital role in the original notion of open innovation. However, Chesbrough emphasizes that it is not the patent that brings profits to the innovator, but taking the patent to the market with a viable business model.

Open Source Software: Source of Innovation?

17

Since 2003, the concept of open innovation has been expanded by several authors, including Chesbrough himself (see, e.g., Chesbrough, Vanhaverbeke, & West, 2006), to better encompass the flow of information from within the company to the outside and also continuous exchanges of information of the firm and its environment. This also brings more closely together open innovation and OSS but does not make them equal as has been shown by West and Gallagher (2006b) (see Table 1).

Open Innovation? Yes Open Source Software?

Yes

No

Pooled R&D: Linux, Mozilla

No business model: GNU

Spinouts: Jikes, Eclipse, Beehive

project, AOL’s Mozilla exit

Complements: Apache, Darwin No

Wintel

Integration strategies

Table 1: Differences and similarities between OSS and open innovation (West & Gallagher, 2006b)

Looking at Table 1, it becomes clear that, although there are obvious similarities between the concepts of OSS and open innovation, the overall intersection between the two concepts is rather small. The concept of open innovation explains the OSS phenomenon only to a limited degree and, whereas the notions of business models and IP protection are certainly important for OSS as well, clearly has a different focus, which lies on the integration of outside ideas for new product development and the spin-out of ideas not related to the core competences of the organization. Co-creation and collaboration, however, are usually not part of the open innovation concept. Furthermore, in particular with OSS, it has to be noted that open innovation puts a high importance on patent-based licensing, whereas OSS (and especially FS) supporters are often highly dismissive of patents.

2.2.2 Collective Invention Allen (1983) was the first economist to describe a scenario where voluntary spillovers were consistent with a profit-maximizing strategy (Henkel, 2004b; Osterloh & Rota, 2007). He defined collective invention as a process under which technical information is freely exchanged between firms and individuals and for which no explicit allocation of R&D resources had happened upfront, the invention in fact rather being a by-product of day-to-day business. By studying the iron industry in the English Cleveland district dur-

18

Open Source Software: Source of Innovation?

ing the years 1850 to 1875, Allen identified three reasons why individuals and firms chose to disclose their inventions in iron furnaces rather than to keep them secret— patenting them would not have been possible—which can be summarized as reputational gains, an inability to keep the innovation secret due to high cost, and an increase in value of other firm-specific complementary assets. By freely revealing their invention, that is, voluntarily giving up all intellectual property rights to it and making it a public rather than a private good (Harhoff et al., 2003; von Hippel & von Krogh, 2006), the inventor might also enlarge the total market for the resulting innovation, an argument that has become particularly popular in IS literature (Varian & Shapiro, 1999), the validity of which, however, has been questioned (see, e.g., Aggarwal, Dai, & Walden, 2006).17 Henkel (2007) points out another important aspect of collective invention mentioned but rather neglected by Allen, namely the idea of reciprocity and continuous innovation. Considering that firms could only come up with their invention thanks to information they had previously freely received, they in turn were highly likely to share their invention, both because they might have felt morally obliged to and because they anticipated others to even further develop their to-be freely revealed invention. In a study on the further development of steam engines in mining in Cornwall, Nuvolari (2001a) described how James Watt actually opposed further development until patent protection expired in 1800. When, in 1811, a journal dedicated to the improvement of steam engines was initiated, even substantial improvements were publicized here, leading to a threefold improvement of overall efficiency until 1845. In another paper, Nuvolari (2001b) explicitly compares OSS to the concept of collective invention, showing that and how different OSS companies have benefited from voluntary spillovers. Summarizing, the concept of collective invention bears many similarities to the OSS phenomenon,18 giving plausible reasons why firms might freely reveal business-relevant information while maintaining profit-maximizing behavior. Yet, there is one important difference.19 As stated by Henkel (2006), Allen’s definition of collective invention (p.

17

18 19

In their event study comparing companies releasing proprietary vs. open XML standardizations, Aggarwal et al. (2006) argue that the market more favorably reacts to firms who secure a share of a potentially smaller market (proprietary XML specification) than to firms who try to catch an uncertain share of a potentially larger market (open XML specification). For a more detailed discussion of this, see e.g. Osterloh und Rota (2007). Osterloh and Rota (2007) observe another difference, namely that OSS has survived the emergence of a dominant design due to copyright-based OSS licenses and pro-socially motivated contributors, whereas in collective invention, when a technology moves from the exploration to the exploitation phase, the collective invention model is rarely sustained.

Open Source Software: Source of Innovation?

19

2) encompasses that “[c]ollective invention differs from R&D since the firms did not allocate resources to invention—the new technical knowledge was a byproduct of normal business operation.” In the case of OSS, however, this definition is only valid for innovations generated by users as there are firms that deliberately dedicate a significant amount of resources to OSS as part of their R&D strategy, which is also what this thesis is focusing on. This shows that, while the collective invention model provides an explanation for the OSS phenomenon, it only provides a partial fit. In particular, the role of the firm and its purposeful use of OSS as part of a corporate R&D strategy are not sufficiently addressed. The user innovation model and in particular the private-collective model of innovation, which will be introduced in the next two sections, seem better suited to deal with these issues, resulting in a superior explanation of the OSS phenomenon.

2.2.3 User Innovation As already illustrated in some of the examples given before, in some industries, a large share of innovations is done by users of a product, where users may encompass both individuals and firms. User innovations are typically, but not exclusively, developed by lead users who are different from the rest of the market in two dimensions: (1) they are at the leading edge of an important market trend, implying that they are already experiencing needs that the rest of the market will only do later and (2), they expect to obtain high benefits from a solution to their needs and are thus more likely to become innovators themselves (von Hippel, 1986, 1988). Firms that employ lead users to develop new product concepts—using the so-called lead user method (see, e.g., von Hippel, Thomke, & Sonnack, 1999)—may thus come up with more radical and more commercially successful products, resulting in better-satisfied customers (von Hippel, 2005). An important element in the concept of user innovation is the idea of sticky information (von Hippel, 1994): assuming that information about a customer’s problem is costly to transfer or non-transferable at all—for example, if the customer cannot articulate it or if the respective piece of information is tacit—even if the manufacturer knows where to look for this information, it can only obtain worse or less information about how to satisfy customers’ needs than the customers themselves have, that is, information asymmetries between users and manufacturers will exist. Also, the users themselves will have different levels of information and potential user innovators will use the

20

Open Source Software: Source of Innovation?

sticky information they already have to develop innovations themselves, since this creates the least cost for them (von Hippel, 1994). Freely giving away their solution is often the best option user innovators can choose. Protecting the user innovation would only make sense if other users cannot substitute the exclusive information of the user innovator and, in case other users have this information as well, if none of them would expect a gain from freely revealing it— even not expecting a loss might actually suffice (Allen, 1983; Harhoff et al., 2003; Lakhani & von Hippel, 2003; von Hippel, 2005). Harhoff, Henkel, and von Hippel (2003) develop a model confirming that users do in fact benefit from freely revealing their innovations to other users and manufacturers. It is consistent with a profit-maximizing strategy and should be considered a common phenomenon and thus the rule rather than the exception (Harhoff et al., 2003). Building on the concept of user innovation, OSS might consequently be described as an innovation community, that is, a community of users and manufacturers willing to freely reveal their innovations (von Hippel, 2005, pp. 97-103), the latter at least selectively (Henkel, 2005, 2006). An interesting extension to the concept of user innovation that might apply especially to the IT sector and related industries is Flowers’s (2006) idea of outlaw innovation. Outlaw innovators, as opposed to user innovators, are defined as “individual users who actively oppose or ignore the limitations imposed on them by proposed or established technical standards, products, systems, or legal frameworks.” Often, only highly technically-skilled people will be able to circumvent such limitations. However, these may, similarly to user innovators, both have high personal benefit from their solution and be the forerunners of a general trend—most likely a different trend than those pointed out by regular user innovators. Examples of past outlaw innovations include the hacking of gaming consoles (e.g., Linux on Xbox 360) or the hacking of broadband routers to make full use of their technical capabilities. Regarding the latter, the manufacturer had installed well-protected software on the device to cap the maximum strength of the broadcast signal. Outlaw innovators overcame this protection, increasing the signal strength to levels even illegal in some jurisdictions. However, in the course of this, they also developed many advanced features that were commonly found in routers costing ten times the price of this one. Because of this, eventually, the manufacturer adopted the outlaw innovation to some degree and was able to offer a high-class router at an affordable price (Weiss, 2005). With respect to the hacking of gaming consoles, Microsoft is still unwilling to allow the installation of Linux on its gaming device. However, Sony has been supporting Li-

Open Source Software: Source of Innovation?

21

nux on its gaming platform since the PlayStation 2, the installation of which made the gaming console become a full-fledged PC. Sony has officially been selling and supporting Linux on its PlayStation platform since 2002, one year after hacking efforts to port Linux to the Xbox had started. Due to its capability of running Linux and its parallel processing capabilities, Sony’s newest gaming console PlayStation 3 has also found appeal in new markets such as supercomputing (Engineering News, 2007).

2.2.4 Private-collective Innovation Von Hippel and von Krogh (2003) distinguish three types of innovation which they label as private, collective and private-collective. The private model is based on the assumption that firms and individuals will invest privately in innovations if they can privately appropriate the resulting rents (Demsetz, 1967). In order to allow the innovator to do this, society allows them to protect their innovation for example through patents or secrecy, which should help generate those private rents (Arrow, 1962; Dam, 1995; Liebeskind, 1996). As spillovers in this model will reduce the returns on innovators’ investments, consequently, they will try to avoid them. Similar to the example on James Watt given above, this may result in a loss to society compared to a scenario in which the innovation would have been freely revealed. However, in order for innovators to come up with the initial invention at all, that is, to sufficiently motivate them to make the necessary investments including the potential risks, society is willing to bear this loss (see, e.g., Nordhaus, 1969, 1972; Scherer, 1972). The collective model of innovation—which has to be separated from the model of collective invention presented before—is valid for public goods, that is, goods that are (1) non-excludable and (2) non-rivalous: (1) if anyone can consume the good, no one else can be barred from doing so and (2) the value of the good does not decrease through this multiple consumption (Olsen, 1967). The deadweight loss in the private model is overcome by inventors deliberately contributing their knowledge to a common pool. As this means that now anyone has access to the information required to produce the innovation, this also reduces—if not eliminates—inventors’ possibilities to recoup the investment they had to take to generate the knowledge initially. Even worse, because the contributions are public goods, individuals might just wait for someone else to contribute their knowledge and then make use of that without ever giving back, the socalled free-rider problem. In academic research, this is for example countered by a norm

22

Open Source Software: Source of Innovation?

of reciprocity and reputation-based rewards among scientists on the one hand and by the state funding basic research on the other (Stephan, 1996). Von Hippel and von Krogh (2003) find that OSS seems to offer the best of both worlds: while privately funded, the results are collectively shared. Yet, although in fact combining many elements of the other two modes of innovation, the resulting privatecollective model of innovation has some important differences. Using the example of OSS, von Hippel and von Krogh point out that, in contrast to the standard private investment model, in the private-collective model the innovator is often a user innovator (that can either be an individual or a firm). As shown in the preceding section, the user innovator will look for a recoupment of his or her private investment necessary to come up with the innovation in a different way than a regular innovator in the private investment model would do: in fact, the prospect of the mere availability of the solution might be sufficient for the user innovator to innovate, whereas the private investor would look for a profit on the innovation from selling it on the market. Furthermore, other user innovators will often freely reveal their enhancements of the original innovation—in the case of OSS, this implies further developments of the OSS—which, too, is contradictory to the private model of innovation. In particular, users have little to lose from freely revealing the innovation if they see low rivalry with potential adopters and expect some benefits from the increased diffusion of the software which free revealing will cause (von Hippel & von Krogh, 2003). Both arguments have been shown to hold for OSS (Hertel, Niedner, & Herrmann, 2003; Lakhani & Wolf, 2005). Comparing the private-collective and collective type of innovation, von Hippel and von Krogh (2003) find that OSS communities use none of the popular countermeasures against free-riding. Even further, OSS projects do not take any measures against it. Instead, von Hippel and von Krogh maintain that individuals participate in OSS projects because the benefit they can achieve from this is higher than from free-riding, since most benefit comes from actually working on OSS. This mainly includes learning and enjoyment of the task, but also peer-recognition and signaling (see, e.g., Lakhani & Wolf, 2005; Lerner & Tirole, 2002). Although many of these benefits might at first glance seem limited to individuals participating in OSS, they also apply to firms as will be shown in the following sections. Furthermore, although most OSS projects do not actively take measures against free-riding, the risk of this is reduced through the nature of many OSS licenses and the norm of reciprocity inherent and dominant in the OSS community (O'Mahony, 2003; Osterloh & Rota, 2007)

Open Source Software: Source of Innovation?

23

Building on Allen’s model of collective invention, von Hippel and von Krogh (2006) describe three conditions under which free revealing in the sense of the privatecollective model of innovation (von Hippel & von Krogh, 2003) is likely to take place as part of a larger R&D strategy. First, this is the case when others have knowledge close to that contained in the innovation so that, in fact, the decision of freely revealing lies with that individual or firm who has the least to lose from it—even if all others want to keep the information secret (Allen, 1983; Harhoff et al., 2003; von Hippel, 2005). With OSS, more often than not, problem-solving information resides with more than just one person (Lakhani & von Hippel, 2003). Even in cases when it is held by just one individual person or firm, others will be able to come up with the information in 12-18 months time (Allen, 1983; Mansfield, 1985). Second, assuming that the innovator indeed is the only one to have the necessary information for the innovation and there are no available substitutes for this information, there might still be reasons to prefer free revealing over intellectual property protection through patenting or secrecy. Benkler (2002) argues that OSS development—or, as he labels it, commons-based peer production—will take place when peering is more efficient than markets and hierarchies and, in addition, the implementation costs of a property system are higher than the opportunity costs. In the case of patenting—which, except for the chemical and pharmaceutical industry, is considered to be rather ineffective (Arundel, 2001; Cohen, Nelson, & Walsh, 2000; Levin, Klevorick, Nelson, & Winter, 1987)—individual innovators and small and medium-sized firms in particular may consider this impractical as they would have to bear relatively large costs and wait several years for the necessary approval (Harhoff et al., 2003; von Hippel & von Krogh, 2006). In these cases, copyright provides an innovator with an immediate, low-cost or even nocost mechanism of legal protection and should suffice when the specific implementation of a function rather than the underlying basic function itself is to be protected.20 Moreover, Blind, Edler, and Friedewald (2005) show that patenting is rather unpopular amongst a majority of firms in the IT industry, especially with firms whose primary business is software development, but also with those firms that need software development for their products, such as the electronics or telecommunications industry. Rather, both types of firms rely on secrecy and lead-time advantages, as they think the costs (direct financial cost and opportunity cost regarding the long application proce-

20

Whereas copyright still exists in OSS, it is often transferred from the author of a piece of source code to the respective OSS project, which, depending on the OSS license, can both occur on a voluntary or mandatory basis.

24

Open Source Software: Source of Innovation?

dure and its uncertain outcome) of patenting are too high and have doubts about the patentability of their inventions (Blind et al., 2005).21 Finally, there are situations in which incentives for free revealing are positive, that is, the benefits of free revealing are larger than the costs. Henkel (2005) has for example developed a model showing that when two firms voluntarily freely reveal further developments of complementary technologies, this may not only increase both firms’ profits, but can also lead to higher product quality. Whereas these and other advantages (and also disadvantages) of freely revealing for corporations have already been touched on above, Section 2.3 has been reserved for a detailed discussion of these.

2.2.5 Summary In this section, it has become clear that OSS bears resemblance to some familiar concepts from economics and management literature, most notably the concepts of collective invention and user innovation. The private-collective model of innovation being a derivate of the two specifically targeted at explaining phenomena such as OSS naturally explains it the best. Moreover, the discussion has shown that the ideas behind OSS—freely revealing solutions to problems—is neither irrational nor new, but has in fact been successfully practiced for centuries. Having generally discussed the phenomenon OSS in its historical and theoretical context, I will now turn to analyzing specifically in which ways OSS may influence a company—both positively and negatively. These advantages and disadvantages will be discussed in Section 2.3.

2.3 Advantages and Disadvantages for Commercial Firms So far, I have looked at OSS more from a macro-perspective, that is, I have reviewed existing economic models and concepts from management literature that help explaining the existence of the OSS phenomenon in general. This has also shown that freely revealing can be beneficial to an individual firm. I will now focus my attention more specifically on those benefits to highlight how individual firms are actually affected when engaging in OSS, which advantages and disadvantages result for them result from this, and what means of protecting their intellectual property (IP) remain.

21

Interestingly, large firms (i.e., firms with more than 500 employees) are somewhat overrepresented in the Blind et al. sample (see pp. 41-43) and these firms are just as skeptic about the benefits of patenting as the rest of the sample. Yet, looking at the examples of IBM, Microsoft, or Apple patenting is of high relevance to the IT and its adjacent industries. However, only a fraction of software patents is actually filed by software firms (see, e.g., Hall & MacGarvie, 2006).

Open Source Software: Source of Innovation?

25

Derived from the defining features of OSS (one is allowed to receive its source code with the software, modify it, and redistribute it), several potential ways in which a firm can draw benefit from OSS emerge. For this thesis, three different modes of commercial OSS engagement will be distinguised: -

Using OSS. A firm uses OSS as a tool for software development, unmodified or adopted, in its products or processes. This also includes the use of (largely) unmodified OSS components to build proprietary software products.

-

Participating in existing OSS projects. The company contributes modifications and extensions of a piece of OSS used in the corporation back to the OSS project.

-

Releasing proprietary software as OSS. The company opens the source code of an existing product developed in-house to start a new OSS project.

Existing OSS is widely used both within and outside the IT industry, and has often become an integral part of corporate software architectures and even commercial software offerings. Prominent examples include the Linux operating system, the Apache web server, and the Eclipse programming environment (Driver & Weiss, 2005; Goulde, 2006; Grand et al., 2004; Varian & Shapiro, 2003). In these cases, OSS is basically treated just as any other third-party software, mostly without or with only limited modifications.22 Only one-way interaction between the company and the environment takes place, such that clear boundaries between the two exist. Yet, there are instances in which corporations fix existing errors in the software or adapt the software to their needs, and contribute the modified source code back to the OSS project. The latter typically happens selectively, that is, modifications are contributed back only when this is deemed advantageous to the company (Henkel, 2006). Giving back conforms to the idea of reciprocity promoted by OSS and FS proponents (Bonaccorsi & Rossi, 2006; O'Mahony, 2003; Osterloh & Rota, 2007; Raymond, 2001b; Shah, 2006), but typically contradicts established corporate policies that dictate that intellectual property is to leave the corporation, if at all, only under a licensing contract. It is thus a significant step, especially for established firms, to move from using OSS to contributing to OSS projects. The greater the extent of such activities, the more blurred boundaries are likely to become between a company and its environment (Chesbrough, 2003, pp. 40-41 and 56-57; West & Gallagher, 2006a).

22

Franke and von Hippel (2003) found that only 19% in a sample of 131 Apache webmasters had modified the web server source code, even though they were likely to be expert users. In general, this percentage should be lower.

26

Open Source Software: Source of Innovation? Releasing proprietary software under an OSS license is an even more radical depar-

ture from established practice. Doing so to initiate co-development with the OSS community completes the transition from closed to open or, rather, private-collective innovation (Chesbrough, 2003; von Hippel & von Krogh, 2003), which have been described in the previous section. As the term co-development suggests, releasing proprietary software as OSS implies a process innovation: team organization, project management, and coding must be organized and executed differently than in the conventional mode of development (Grand et al., 2004; von Hippel & von Krogh, 2003; West & Gallagher, 2006a). Moreover, the full bidirectional interaction that follows is likely to blur or even erase boundaries between a corporation and its environment as relate to a project and the knowledge associated with it. Each of these three forms of OSS engagement comes with risks and benefits to the corporation and its employees, which will be taken a closer look at in the following.

2.3.1 Advantages of Using OSS From a cost perspective, the case for using OSS instead of PCSS—that is, either software developed by the firm or purchased from a third party, the latter both including commercial-of-the-shelf software and commissioned development—should be the easiest to make when using OSS is cheaper for the corporation, that is, has lower total cost of ownership (TCO). TCO include hardware costs (including purchase price and hardware maintenance), direct software costs (including purchase price and support and maintenance), indirect software costs (especially administration of licenses), staffing costs, support costs, and downtime and encompasses the entire life cycle of the software (Gartner, 2005); transaction costs are accounted for in these items. Apart from material costs such as those for CDs or DVDs or print-out manuals, there are rarely any purchasing costs associated with OSS. Providers of OSS are contrariwise enjoined from charging license fees for their product: they are allowed to charge money when selling their product, but they cannot bar their customers from giving away the software for free or even putting it on the web after the initial purchase (FSF, 2006; OSI, 2001; St. Laurent, 2004). Although most often being available gratis is certainly the best-known advantage of OSS, there are numerous other advantages that come with the use of OSS. As the purchasing process itself does not involve timely negations—one can simply download the software, install and configure it, then run it—transaction costs of software licensing

Open Source Software: Source of Innovation?

27

should not occur or at least be close to zero. However, as only a fraction of software purchasing cost actually consists of license fees (Banker, Datar, & Kemerer, 1991), basing one’s decision on replacing proprietary software with OSS based on lower license fees alone is both short-sighted and superficial. Focusing on monetary benefits, one might better look at the significant reduction in hardware costs that for example occurs when substituting Linux for UNIX (Wheeler, 2007).23 Still, most advocates of OSS argue that the benefits of using OSS come from nonmonetary advantages. First and foremost, they will state the fact that OSS is open, freely accessible, and can be updated and changed if needed. This reduces lock-in from proprietary software vendors and their update cycles and also enables developers to quickly create environments in which they can focus on developing and testing their programs. They can do so without having to provide commodity functionality, such as web server functionality provided by Apache or application server functionality provided by Tomcat. Not only do they save time doing so, they are using a high quality product including access to a large support community, and, if necessary, they can make adjustments to the software to make it run. Furthermore, the ability to access the source code may decrease maintenance cost for the firm using the software, (1) because the firm itself may fix bugs and (2) because others using the software will probably also do so and freely reveal those improvements (Lakhani & von Hippel, 2003). Moreover, firms in need of third-party support for maintaining OSS solutions will find that technical support is contestable, that is, multiple suppliers for the same service and the possibility to switch your service provider exist—leading to a significant decrease in maintenance cost (Wheeler, 2007). Also, with OSS, firms can decide which software to use with which specifications and when to change or upgrade it themselves rather than being dependent on the upgrade cycles and licensing policies of a particular supplier of PCSS. Not only does this include updates, that is, bugfixes, but also the fact that general support and maintenance for a program will only be provided for a certain period of time, and that support contracts for commercially licensed software might simply run out. After this period of time, even if the company is still allowed to use the software, no further development of the software and no vendor support are available any longer, quickly rendering the software a security risk for the corporation (Wheeler, 2007). In contrast, with OSS, both the company and other firms have the possibility of ensuring both timely updates and

23

For an overview of numerous TCO studies on OSS, please see Wheeler (2007).

28

Open Source Software: Source of Innovation?

the further development of the software as the source code of the product is still available and can be modified. An additional advantage for a company using OSS might come from learning and educational effects. As, by its meritocratic mode of development, the source code of successfully established OSS projects should be close to best practice, 24 company employees might be able to learn new or better coding techniques and routines, or state-ofthe-art ways to implement certain requirements. Of course, these learning effects will be greatly enhanced if the employees expose themselves to this development mode by engaging in OSS development. Furthermore, they will be forced to follow a certain design discipline when participating in OSS that could prove beneficial when also applied within the company (Goldman & Gabriel, 2005). Developing products based on OSS is the next logical step after using it. In doing so, the company is offering products that build on OSS or that consist of OSS to a large degree, but usually without changing (or having to change) the source code of the OSS parts. In such products, the OSS component will often provide basic services to the software, for example commodity services such as the Apache web server. Developing products based on OSS seamlessly connects to the mere use of OSS: having created a prototype using OSS, why spend additional money on replacing the OSS parts when everything is working fine already? Again, the advantages by OSS are not only monetary ones, as will be shown in the following. As developing products based OSS builds on using OSS, all advantages of the latter do also count towards the former: at no licensing cost, anyone can get access to proven solutions that can be tailored to one’s needs quickly (Wheeler, 2007) 25—and if one had trouble doing so, there would be a large community to help out. This way of adapting OSS to a company’s needs may well be easier to implement and come with less transaction cost than developing or modifying proprietary software. Consequently, a company may be able to do less expensive, more rapid and higher quality prototyping, and, thus, achieve quicker time-to-market. This quickness and flexibility is key to being competitive in rapidly changing environments (Hitt, Keats, & DeMarie, 1998).

24

25

However, this does not necessarily have to be the case. To further illustrate this point, and the meaning and importance of “successfully established,” please consider the following example: the Mozilla web browser project, one of the most successful and widely know OSS projects today, suffered from poor programming design in its beginnings and consequently failed to attract contributors to its further development (Hissam, Weinstock, Plakosh, & Asundi, 2001). Only after a major overhaul of the entire codebase, the Mozilla project took off (MacCormack, Rusnak, & Baldwin, 2006). To further support the statements made in this paragraph, an empirical study reported in Section 3.1 was conducted, lending strong support to the claims made here. It was further confirmed in numerous interviews conducted as part of the study reported in Chapter 4.

Open Source Software: Source of Innovation?

29

Furthermore, a software company that specializes in a certain layer of the software architecture might complete its offering by using OSS for the layers in which it does not provide value. In these cases, proven OSS commodity software is used to implement basic functionality at lower cost and higher quality than proprietary software (Raymond, 2001a, 2001b; West & Gallagher, 2006a). IBM has, for example, decided to completely abandon its own web server development and instead replaced it with the Apache web server; IBM also joined the Apache Foundation. Apache and its subprojects such as Tomcat are now part of the respective IBM products. Another example is Astaro offering a modified, security-hardened, no-hassle version of Linux as a basic component of their (hardware) firewall products. Especially when developer resources are scarce, using OSS as a basis for its products may help a company to produce high-quality software at significantly lower cost. Also, start-ups may overcome liabilities of newness and smallness by using OSS for layers of the software stack they have no core competence in (Gruber & Henkel, 2006). Moreover, releasing software as OSS could increase this effect by having others contribute source code or take over mundane tasks, such as user support. In both cases, the developers of the company will be able to focus more on what they are actually supposed to be doing—writing source code that will benefit the company, thereby again increasing the company’s flexibility and, thus, competitiveness (Goldman & Gabriel, 2005; Hitt et al., 1998; Lakhani & von Hippel, 2003).

2.3.2 Disadvantages of Using OSS Using OSS by itself comes with little risk and few downsides. The mere use of OSS does not create any obligations to open-source anything. For example, a program written in PHP or Perl26 or a proprietary application run on an Apache web server may well be kept closed source. The same goes for data that is stored in an open source database such as MySQL or PostgreSQL, or applications that are developed using Eclipse. However, as boundaries between using OSS and developing proprietary software based on or at least employing OSS are blurred, situations in which employees have to pay attention arise. They mostly deal with the so-called “derived work” aspects of the GPL27 and have been discussed in Section 2.1.2. In empirical field work (see Section 3.1 and Chapter 4), I have found through interview and survey results that only on rare occasions one OSS application is an exact so26 27

PHP and Perl are two OSS programming languages (i.e., both the languages themselves are OSS). Of course, this also applies to licenses similar to the GPL, see http://www.opensource.org and http://www.fsf.org.

30

Open Source Software: Source of Innovation?

lution to an existing problem. In many cases, there will be competing OSS alternatives, none of which is the ideal solution the company is looking for. In some cases, searching or screening costs may thus well be higher for OSS than for other kinds of software, as, oftentimes, customers themselves will have to choose from a whole variety of different products and configurations to find the one solution that optimally solves their problem. In some cases, however, software packages providing different functionalities, all of which are required by the corporation, might be incompatible to one another, and workarounds for this have to be found to make the OSS usable.28 In other cases, the customer might be the first to have a specific requirement so that no publicly available documentation or manuals exist. In such cases, it is important to judge whether the additional effort of identifying the most suitable OSS and customizing and tailoring it to the company’s specific needs still is favorable to doing-it-yourself, outsourcing, or buying commercial-off-the-shelf software.29 In other cases, compatibility issues may arise that rule out using an OSS solution from the beginning. For example, some businessrelevant applications have only been running on Microsoft Windows in the past, ruling out the usage of Linux in particular on the desktop. Also, switching costs to an OSS alternative may offset the monetary gains from cheaper hardware and software, mainly due to costly employee training (Wheeler, 2007). However, when including future maintenance cost and qualitative criteria such as vendor independence, that is, the independence from the update cycle and licensing policy of suppliers of proprietary software, a switch from PCSS to OSS may still be carried out even if short-term financial results are negative. A prominent example for this is the City of Munich that decided to switch to a Linux-based environment for long-term reasons, in particular vendor independence, rather than for short-term financial gains (Hoegner, Hofmann, & Schießl, 2006).30 As stated earlier, developing products based on OSS in most cases does not include changing any source code; consequently, an obligation to release any source code should not occur in this case. If, however, the company made (minor) changes to the OSS that are considered derived work and, thus, the source code of which needs to be provided to customers, most probably, these would not contain any information of particular value to the core business of the corporation. Linking the development of products based on OSS to its use in the company, a far greater danger becomes apparent. 28

29 30

For example, certain features of the OSS telephony software Asterisk are provided by add-ons which (1) are incompatible to one another and (2) only work with certain (and often different) telephones (Alexy, 2007). Of course, this is provided the fact that these alternatives solve the customer’s requirements. Florian Schießl is the deputy chief of the City of Munich’s Linux project.

Open Source Software: Source of Innovation?

31

Developing products based on OSS means that a company supplies the public with a product that contains OSS. Under an OSS license, the company is required to both label the product adequately and to provide the user with the source code of the respective parts of the product that are under an OSS license. But what happens now if the use of OSS was not documented properly? What if it is simply not known if, what kind of, or how much OSS is contained in the product? What if someone copied just a small piece of code or created a derived work?31 At worst, this may lead to a product that actually contains OSS while not being labeled and treated as such—this being unknown to company officials—and, thus, to an infringement of the OSS license. Findings from empirical research underlying this thesis (see Section 4) and several existing studies (see, e.g., Henkel, 2007; Henkel, 2008) strongly indicate that employees usually do not infringe on OSS licenses to deliberately harm their employer. However, people seem to be willing to “smuggle” OSS past their supervisors when they feel that the piece of OSS actually solves their problem and their supervisors would either not understand the programming details anyway or generally dismiss any use of OSS. Functionality and quality of the software are often valued higher than compliance with the license agreement. In many cases, the latter are not even read properly—if at all. A study by Madanmohan and De’ (2004) confirms this impression: here, a majority of the 13 interviewed companies first looked at the functionality of an OSS component and selected it based thereon. Only afterwards, a closer look at issues including licensing terms was taken. However, if the desired functionality was attainable, workarounds were tried to be found for this and all other issues.32

2.3.3 From Using to Revealing Revealing OSS is the next step after developing products building on OSS. Whereas in developing products based on OSS, the actual OSS component remains largely untouched—apart from slight modifications to provide the functionality needed for the main (and mostly proprietary) part of the software—freely revealing source code either implies modifications of existing OSS or the release of formerly proprietary software under an OSS license. Henkel (2004b) summarizes the advantages and disadvantages of revealing for different actors as follows (see Table 2).

31

32

Whereas this should be considered highly unlikely, one might also imagine that developers could do this maliciously to harm their employer (also see the next paragraph in the text). Interestingly, issues such as usability or costs were also only addressed after functionality had been shown, and, consequently, were of less importance in the selection decision.

32

Open Source Software: Source of Innovation?

All contributors

Benefits

Risks/downsides

improvement and further development by others

loss of intellectual property

standard setting reduced maintenance cost programming discipline attraction for programmers increased reputation technical skills (for high quality code) being a “good OS citizen” Users

integration of user developments into official version

cost of preparing code for release as OSS cost of maintaining OS project (for maintainer) forking infringement on patents can be detected more easily bad reputation (for code of low quality) loss of competitive advantage insights for competitors visibility of security flaws

Sellers of complements

increased sales of complementary goods pricing pressure on competitors

Software vendors support for older software can be terminated more easily

loss of competitive advantage insights for competitors visibility of security flaws licensing fees excluded

Table 2: Benefits and risks of free revealing for different actors (Henkel, 2004b)

Although both kinds of revealing share the same basic idea—a contribution of source code to the OSS community—there are some major differences between the two of them. The submission of bugfixes or the development of new features or modules for existing OSS projects are standard examples of contributions to existing public OSS projects. In the most likely case, the company (or some of its employees) has been involved with the software before. However, problems were encountered when using it, for example due to a bug in the software or a missing feature that the company needed. As permitted by the OSS license, in-house programmers tackled these issues and solved them. In the case of new modules—if not considered derived work—the company had the option of keeping the source code proprietary (and maybe even of selling it separately). The bugfix, also, did not have to be sent back to the authors of the original OSS project, but the underlying source code would have needed to be made available to the firm’s customers since the bugfix would be considered derived work. Nevertheless, revealing the source code can be advantageous in both cases, as will be shown hereafter.

Open Source Software: Source of Innovation?

33

Altogether, this mode of revealing OSS will have little public or business exposure and convey little risk. No lasting commitment or significant management resources are required. Releasing proprietary source code to start a new public OSS project is in itself independent from existing OSS projects—the company launches one by itself. Whereas it is necessary to evaluate such an action on a case-by-case basis, there are some general advantages that will be elaborated on. Proven business models already exist as will be shown in Section 2.4. Still, these require a lot of management attention and wellorganized processes which will be the topic of Chapter 5.

2.3.4 Advantages of Contributing to Existing OSS Projects Looking first at contributions to existing OSS projects, it is rather obvious that influencing the official version of some OSS program used by a firm means that later releases of this program will be of higher value to the firm: in case of improvements, such as bugfixes, the firm will be able to use future releases without having to re-do the improvement. In case of extensions or modifications, future releases will be better adapted to the firm’s specific needs. In any case, software engineering issues such as compatibility or interoperability will become less of a worry for the firm (Henkel, 2004b; Raymond, 2001b). In addition, the code revealed by the firm may be further improved by others. With any luck, the contribution to an OSS program might help to enhance credibility of the product and, thus, to influence an existing standard or even establish a new one (see below and in particular also Section 2.3.5 for more on this). Contributing to OSS projects also has a marketing aspect to it. In many cases, and especially for larger established proprietary software firms, tight press coverage on OSS will increase the company’s visibility and—because of the positive connotation attached to OSS—the company’s reputation in the developer community, including its current personnel. Appearing as a good open source player can thus be an option to increase the company’s overall reputation—both inside and outside the boundaries of the firm (Abreu, 2001; Raymond, 1999). Closely related to this, another point applies in particular to firms that are not necessarily renowned for developing software, whose products, however, contain a substantial amount of software and that, consequently, often need to recruit programming talent on the job market. Due to the increased visibility and, often, popularity coming with the release of OSS, such firms may use OSS to signal their technical competence to the job market and, thus, to attract skilled developers from the

34

Open Source Software: Source of Innovation?

outside (Henkel, 2004b). In addition, a company might be able to recruit new employees from OSS communities around their products—as for example Danish toy manufacturer Lego did with its Mindstorm toy robot (Seel, 2006). Also, as developing OSS is considered more enjoyable and more prestigious than ordinary work by many developers, the motivation of internal developers working on such projects is likely to increase (Lakhani & von Hippel, 2003; Lakhani & Wolf, 2005; Raymond, 2001b). Intel’s commitment to Linux is an interesting example for contributing to existing OSS projects. UNIX traditionally runs on proprietary RISC architectures as provided by HP or SUN—each one with their own UNIX derivate. Most if not all money is made by selling the hardware. By co-developing the Itanium and Itanium 2 with HP, Intel has gained some foothold in the RISC market but has not really been successful compared to its dominance of the desktop market. On the other hand, Linux has been designed for Intel’s x86 architecture from day one. As servers featuring clusters of Intel Pentium processors are way cheaper than RISC architectures with the same computing power, more and more companies have switched from UNIX to Linux to make use of the hardware savings. As each of these companies generates additional revenues for Intel it is not surprising to hear that Intel actually employs more Linux developers than Red Hat does (Hohndel, 2006). Another example is Sun’s JSP33 technology for the Apache web server (Goldman & Gabriel, 2005, p. 75). In this case, Sun wanted to make sure that its JSP technology would run properly on the world’s most-used web server, so that as many people as possible could and, in fact, would use it. Also, Sun had been worried that the Apache foundation might have thought about developing a similar competing technology. The further diffusion of Apache web servers running JSP technology increased both the adoption of JSP and its acceptance as a programming language for web applications. Moreover, Sun did not have to worry about interoperability with Apache any longer and is constantly receiving free feedback and improvements on their JSP technology. Additionally, Sun is making money by for example selling Java-specialized hardware, advanced development tools, and support (Goldman & Gabriel, 2005, pp. 105-106). Although the example of Sun might already be considered releasing proprietary software, one needs to consider that the project is being managed by the Apache Foundation, Sun only having limited influence on management and further development. Sun acted simi-

33

JSP is a technology that allows to integrate Java program code capable of dynamically generating HTML or XML output into otherwise static HTML content (HTML: the language in which Internet websites are written). Java is a programming language written by Sun.

Open Source Software: Source of Innovation?

35

larly when releasing its Netbeans architecture to increase sales for the corresponding “native” development environment Sun Java Studio Enterprise Edition (Goldman & Gabriel, 2005, pp. 105-106, 205).

2.3.5 Advantages of Releasing Proprietary Software as OSS Turning to the advantages that may come with releasing proprietary software as OSS, these include most of the advantages named before, and now to their fullest extent if the software is released successfully, that is, a community forms around the software. Looking at the advantages as listed in academic literature, first of all, the company can now benefit from external developers’ support and the latter can make improvements and further developments to the software. As many of these developers will be making adaptations for other companies, the feedback received is often direct user input34 to better tailor existing and future products to existing markets. In such cases in particular, it is highly likely that a piece software will develop faster than if kept proprietary (Dalle & Jullien, 2003; Henkel, 2004b; Lakhani & von Hippel, 2003). In addition to this, by having customers make further developments to a piece of software, the company might both be able to get a gratis stream of innovations to its product and 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 its core business that also do not generate any revenue (Goldman & Gabriel, 2005; Lakhani & von Hippel, 2003; Shah, 2006). Standard setting and compatibility issues also play important roles. As will be explained in the following, 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 stan34

“User” does not necessarily equal “end consumer,” but rather stands for another firm using the OSS program to build a product or support a process (also see von Hippel, 1988, pp. 3-4). For example, in the case of Embedded Linux (see, e.g., Henkel, 2007, pp. 91-152), the “user” most likely to provide feedback to Embedded Linux developers would be a manufacturer of embedded devices (who would be a user of Embedded Linux).

36

Open Source Software: Source of Innovation?

dard. 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 & Gabriel, 2005; Henkel, 2004b). Adobe has for example revealed the specifications of the PDF format. However, they have kept their method of actually converting documents into this specification proprietary. If one strong standard already exists, releasing a piece of software as OSS can make it part of this standard, or, as shown for contributing to existing OSS projects before, it will at least increase compatibility of the software to existing software and hardware offerings (Harhoff et al., 2003; Hecker, 1999; Henkel, 2004b; 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 et al., 2006; Farrell & Saloner, 1985; Farrell & Gallini, 1988; Harhoff et al., 2003; Henkel & von Hippel, 2005; Katz & Shapiro, 1985, 1986; Shepard, 1987). 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. For example, many of Microsoft’s competitors in the software industry have a hard time competing with their $6bn annual R&D budget.35 Also, due to Microsoft’s market dominance, even the most expensive projects—usually a new operating system—will pay for themselves after merely a short period of time. With its proprietary operating system running only on its own platform, Apple could never keep up by developing its own operating system.36 Instead, Apple decided to build its operating system Mac OS X on top of the FreeBSD5.0 and the Mach 3.0 microkernel, both of which are OSS. 37 Similarly, when Sun realized its StarOffice was constantly lagging behind Microsoft Office they released it into open source to improve quality, functionality, and diffusion. This led to the expected increase in quality and

35 36

37

The $6bn figure is taken from Gates (2006). In fact, the operating system—or more the cost of developing one—has been one of the biggest problems Apple has been facing throughout its history, cf. Harvard Business Cases “Apple Computer –2002” (9-702-469) and “Apple Computer, 2005” (9-705-469). Together, FreeBSD5.0 and the Mach 3.0 microkernel are the main components of Darwin, which in itself is already a fully-grown operating system entirely built from open source. Mac OS X uses Darwin as its core, but also includes proprietary components. Apple’s most current operating system Mac OS X 10.5 (“Leopard”) is for example built on Darwin 9. Darwin in itself is an open source operating system substituting a UNIX operating system, using the Mach microkernel as kernel (i.e., the core providing very basic functionality of the operating system, such as address space and thread management) and several components of FreeBSD5.0 providing additional operating system functionality, for example the network stack (see, e.g., Apple, 2007, and related websites).

Open Source Software: Source of Innovation?

37

functionality, and, more importantly, OpenOffice was able to attract public attention and market share to a degree StarOffice never achieved. A comparable move by a company to release an inferior product just to attack the market leader—who might well be a competitor in the company’s main business area— could be witnessed when SAP released its database MaxDB just to hurt Oracle. Usually, the main goal of such efforts can be described as to commoditize competition—mostly on single-vendor high-premium markets—and to shift the area of competition to a field in which the company releasing its software as OSS is strong (Goldman & Gabriel, 2005; Hecker, 1999; Raymond, 2001a; West, 2003). IBM, for example, excels at this strategy. With the increased level of commitment to OSS that is inherent in revealing corporate source code, positive marketing effects will also increase. For example, IBM was able to get rid of its negative standing in the software developing community by heavily committing to Linux and Apache and by releasing proprietary software such as Eclipse. Not only did this increase IBM’s reputation and, thus, attracted many skilled developers to work in the OSS communities, it also increased developer motivation at IBM who were now working for a “cool” company (Abreu, 2001). Similar effects could be observed after Novell’s purchase of SuSE. The release of proprietary software may also generate new sources of revenues for the company by selling complementary goods, such as services, consulting, and training as well as for complementary hardware and software. The resulting new business models a company might have a look at will be elaborated on in Section 2.4.

2.3.6 Disadvantages of Contributing and Releasing Whereas 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 & Gabriel, 2005; Hissam et al., 2001; MacCormack et al., 2006). 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, for example all inappropriate comments need to be removed, business logic ex-

38

Open Source Software: Source of Innovation?

tracted, and so on, which can bring a significant amount of start-up cost (Hecker, 1999; MacCormack et al., 2006). 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 will be able to quickly start working with many of the ideas contained in the product at little additional cost. However, a caveat is in order. Whereas 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, fixed bugs, and new sources of revenue—outweighs the losses as needs to be addressed by a preceding business case (Henkel, 2004b; West & Gallagher, 2006a). 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 and are allowed to freely redistribute it, they may see less of a reason to pay for it, especially when there might be someone else from whom they could receive a gratis copy. Indeed, with OSS it will no longer be possible to demand license fees for the product, so it is likely that 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).38 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. In these cases, none of the possible benefits of going OSS will be reaped (Goldman & Gabriel, 2005; Henkel, 2004b; MacCormack et al., 2006). If a company has managed to successfully establish an OSS project based on formerly proprietary software, the danger of forking remains:39 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 any OSS license (FSF, 2006; OSI, 2001). This is what happened to the content management system project Mambo. Almost the entire core developer team left the project when the Mambo Foundation was created to which all copyrights to the source code were supposed to be transferred. Unhappy with this step, the forkers took an existing stable version of Mambo and made it 38 39

See also Section 2.4 for business models in OSS. “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, 2007, formatting copied from original source)

Open Source Software: Source of Innovation?

39

Joomla 1.0.40 Although forking remains a possible if unlikely threat in any OSS project, there are ways to prevent it, as will be shown in Section 5.3.

2.3.7 Means of Protecting IP When Releasing Software With a loss of competitive edge being the biggest issue speaking against actively participating in OSS, I will now turn to several levers a company can pull to control this issue. First of all, the risk of losing competitive advantage is not the same for any software by any company in any market, but, as Henkel (2004b) has shown, instead depends on the intensity of competition, the relation of the software to the respective domain of competition, the availability of substitutes, and the specificity of the software to the firm (Harhoff et al., 2003; Henkel, 2004b; Schrader, 1991). Following Henkel (2004b), in general an OSS strategy should become more damaging when competition is stronger. However, should competition take place on a level of little to no relevance to the actual software, for example on quality, brand, or customer service, a loss of competitive advantage by making the software OSS is unlikely. This applies for example to tools and infrastructure software, where a release as OSS might also generate cost savings for reasons laid out earlier and, if desired, might help setting a standard (Hamel, Doz, & Prahalad, 1989; Henkel, 2004b). Moreover, drawing on the reasons given in Section 2.2.4 why companies might freely reveal their knowlegde, the company has nothing to lose from revealing if substitutes for this piece of information (or, in this case, source code) are readily available. Regarding competitors gaining insight into the corporation’s business processes, Henkel (2004b) identifies several reasons why this is unlikely to be the case. First, a competitor is unlikely to benefit from a piece of software that is indeed specific to another company. Second, even if the software, and, more importantly, the business processes it was built on, were not necessarily specific to the authoring firm, business and programming logic should be clearly separated in any kind of well-designed software, so that a release of the software would not equal revealing the underlying business process. Also, releasing the software might actually increase the security of the program (Hecker, 1999; Henkel, 2004b; Raymond, 2001b). Moreover, the software might be protected by so-called complementary assets, that is, assets that a company has—and that a competitor would also need or have to build up—and which are needed to appro40

See for example http://en.wikipedia.org/wiki/Joomla, retrieved April 04, 2006.

40

Open Source Software: Source of Innovation?

priate rents from the software itself (Teece, 1986). These may include a developer community (Dahlander & Wallin, 2006)—after all, developers are a scarce resource and can only work on a limited number of projects—, a brand name as seen especially in the cases of Apache or Linux, proprietary software that is specific to the OSS, or a piece of hardware that the OSS is tailored to specifically as is often seen in embedded devices (Behlendorf, 1999; Hecker, 1999; Henkel, 2004a, 2004b; Henkel & Tins, 2005; Henkel, 2006; Koenig, 2004; Raymond, 2001a). In addition to this, competitors should not be able to exploit the software right away: in case the source code is revealed on the launch date of the product, internal product development and the knowledge accumulated thereby should give the company a lead time of approximately 12 to 18 months (Allen, 1983; Mansfield, 1985). The terms of most OSS licenses including the GPL also allow for some protection of a piece of software. It is important to understand that once the software has become an OSS product, the company does not necessarily have to give away the source code to everybody freely on its website as has been wrongly described in many cases, for example in the media. Instead, all one has to do is give everyone who receives a valid copy of the software the opportunity to receive the source code for free or at a nominal fee. First, this implies that a firm will only have to reveal the product source code to its customers. Although they, again, might pass on the software to others, in many cases they will have little to no incentive to do so. Liebherr, a German conglomerate, for example uses embedded Linux as part of its cranes. It is easy to see that its customers from the contracting business have little to no incentive to look at the source code or to further distribute it. The source code, thus, stays more or less protected (Henkel & Tins, 2005). Second, a company is allowed to initially hold back the source code and to deliver it to customers only upon request. The third option would be to release the software as binary loadable modules only, that is, as machine code without the source code, which may apply, for example, to drivers. However, this might be counterproductive as it is rather disregarded by most members of the OSS community, and, thus, the number of developers willing to work on a respective project should significantly decrease (FSF, 2006; Henkel, 2006; Raymond, 2001a). In addition to these rights given to anyone by most OSS licenses, making up one’s own license or using a modified licensing model such as dual licensing can be advantageous in securing intellectual property. It is important to understand that most of the measures introduced above not only have upsides but may sometimes come with severe drawbacks and pitfalls as well. Find-

Open Source Software: Source of Innovation?

41

ing the right balance between protection and openness will be important for the success of an OSS project, an issue that will be addressed again in Chapter 5.

2.4 Business Models around OSS Summarizing the advantages and disadvantages from above, we see that using OSS may generate lower cost, reduced lock-in, higher quality and performance, and lower time-to market. Contributing to existing projects will make sense when it will help to set a standard, when the contributor thereby decreases maintenance cost of the separate codebase, or when further improvements can be expected. When summing up the advantages and disadvantages for releasing proprietary software as OSS, however, the resulting picture is much more complicated. Whereas the company may achieve considerable benefits, to do so, it will first need to create a running ecosystem around the OSS based on a business model that allows the company to both generate and appropriate value from its OSS efforts while minimizing potential downsides. Using the least common denominator found in the literature, for this thesis a business model shall be defined as the way in which the firm creates and delivers value for the customer and how the firm appropriates the rents from the business.41 The revenue model, that is, the way in which the company generates revenues with its business, consequently, is an important part of a business model (Amit & Zott, 2001; Chesbrough & Rosenbloom, 2002). Despite the advantages presented above, at first glance, it may still 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,42 and it is possible to build up a business around OSS. Indeed, it is explicitly allowed to demand money for the software, as was already stated in the introductory quote to this thesis. 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 of the program on the web (FSF, 2006). According to the rights 41

42

As said before, West and Gallagher (2006b) show that OSS and open innovation are synonymous in case OSS efforts follow a business model to appropriate value for the firm. Commissioned development resulting in a new OSS project would be an example for a direct revenue stream. Commissioned development based on an existing OSS project would be an indirect revenue stream and would fall into the category “sale of complementary services” presented later.

42

Open Source Software: Source of Innovation?

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 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. In the following, using case examples, five different but non-exclusive business models will be explained that companies thinking about releasing their proprietary software as OSS may choose based on the advantages of releasing proprietary source code presented above. Indeed, oftentimes, a combination of multiple ones seems more promising than choosing a single one. Usually, a service model or the selling of accessories will work. Depending on what a company wants to reveal and how much of it, the business focus and strategy of the respective department, the available resources, the knowledge and experience of the employees, etc. the company will have to pick and add other options accordingly and combine them into the final business model (please also see Sections 5.1.3 and 5.2 for more information on this subject).

2.4.1 Business Transformation As mentioned above, revealing one’s own proprietary software under an OSS license can have strategic reasons, that is, the motives behind the release are long-term oriented and probably also not primarily financially oriented. Even though the degree of commitment and involvement of the firm may vary in different cases, the common goal is usually to either commoditize a certain layer of the software stack that is of little or no value to the company, or to introduce or support a standard that brings some advantages to the company, or both. When the company has developed a new technology that it wants to be adopted rapidly, opening it up to users and competitors will increase the speed of diffusion. Additionally, the customers’ fear of being locked-in by a monopolistic supplier will decrease (Farrell & Gallini, 1988; Shepard, 1987). Still, as only the providing company knows all of the technology’s details, it should be able to keep an advantage over its competitors (Goldman & Gabriel, 2005; Henkel, 2004b). In the end, what the company might get is a smaller share of a larger market that is, in absolute terms, bigger than the larger share of a smaller market if it had kept the software proprietary (Farrell & Saloner, 1985; Farrell & Gallini, 1988; Katz & Shapiro, 1985, 1986; Shepard, 1987).43 43

As laid out earlier, the empirical validity of this statement has been questioned (Aggarwal et al., 2006).

Open Source Software: Source of Innovation?

43

In the case of Netscape Communications releasing its web browser product in 1998, the company revealed its software because a competitor had a firm grip—on the way to a monopoly—in a certain area that could not be battled against on the “regular” software market: after winning the “browser wars,” Microsoft was trying to lock up the Internet Protocol HTTP and the corresponding website markup language HTML. Although Netscape might not have been able to define a new standard, securing an open standard seemed better than a proprietary one led by Microsoft. This led Netscape to reveal its internet browser (Raymond, 2001a). Similarly, DEC funded the UNIX window system ‘X’ to prevent Sun Microsystems from getting a lock on the UNIX market with their graphical environment. “By funding X and lending it engineers, and by allying with many smaller vendors to establish X as a de-facto standard, DEC was able to neutralize advantages held by Sun and other competitors with more in-house expertise in graphics. This moved the focus of competition in the workstation market towards hardware, where DEC was historically strong.” (Raymond, 2001a) IBM made its decision to support Linux based on similar criteria: though it also provided a common set of APIs across IBM’s entire product line, it changed the area of competition so that IBM was able to show its traditional strengths in services, availability, and reliability (West, 2003). Comparably, with its Eclipse platform that targets all computing platforms, IBM is trying to replace for example Sun’s or Microsoft’s “native” software development products with a standard cross-development framework in which IBM can better integrate its Rational tools. To this day, Sun and Microsoft are the only major software companies that have not joined the Eclipse Foundation. Additionally, Eclipse—being at no cost—will spread out to a large developer community. Universities are also highly likely to use it for teaching purposes. Especially the latter will generate a group of people who will be highly receptive for products from IBM’s Rational software line of which Eclipse used to be a part of before its release as OSS (Koenig, 2004). Sponsors of Eclipse may later join the project for reasons already mentioned in Section 2.3.4, such as permanently integrating bug fixes or companyspecific requirements, influencing the standard (i.e., the architecture or development roadmap of Eclipse), receiving feedback on own ideas and source code, or marketing reasons. As going OSS usually causes much media stir and the promise of giving away the software for free should cause much interest and downloads, an OSS strategy is often said to build mindshare and make a reputation for the product or brand. In most cases,

44

Open Source Software: Source of Innovation?

this is what actually leads to breaking a competitor’s (quasi) monopoly as described in some of the above examples. In addition, money can then be made by selling complementary services or goods (Hecker, 1999; Raymond, 1999). Moreover, the additional attention coming with OSS might be used to promote the technology affiliation of a company. A prominent example for this is openadaptor released as OSS by investment bank Dresdner Kleinwort Wasserstein (DrKW) in January 2001, a system that connects different IT systems within the company as well as customers. One of the main reasons for going OSS was that in late 2000 “it was very difficult to employ competent developers, because everybody was interested in joining startups and getting their share options.” Making openadaptor an OSS project “acted as a kind of advert […] we are a bank but we do really cool stuff” (Henkel, 2004b). As DrKW received—and is still receiving—positive headlines, the move may well be called a success.

2.4.2 Cost and Risk Reduction Although this may not always be the case, there are many situations in which releasing software under an OSS license instead of keeping it proprietary brings immediate monetary benefits. The most obvious argument for OSS is to go for it when it is cheaper than doing proprietary software development. This will mainly be the case for components that provide basic functionality and little to no sales value, yet are highly critical. A good example would be a web server on which the actual software is run. In many cases, an OSS implementation of such a component might already exist. Contributing the proprietary source code related to this OSS project to improve it and then committing to this OSS project will often be cheaper than continuing with developing and maintaining a proprietary component in parallel. Not only will a company need fewer developers to maintain the code, it may also profit from improvements the OSS community makes to the project. Often, this can be coherent with the strategic use of OSS, as the example of IBM replacing its own web server with Apache shows (Hecker, 1999; Raymond, 2001b). Another situation in which OSS may be self-sustaining appears when the company has developed a piece of software that has little to no relation to its core business. In many cases, relevant knowlegde of the software will be concentrated on a select few developers. Should these now turn to different tasks and have no more time for administration or further development, or should they even leave the company, the software

Open Source Software: Source of Innovation?

45

may over time lose most if not all of its value to the company. This is for example the case when security issues are discovered but cannot be fixed, or when the company decides to migrate to a new operating system, but the software only works on the old one. Releasing the software as OSS helps by reducing the developers’ amount of work on the not business-relevant program and by securing a continuous stream of actualizations even if they have turned to other projects or left the company (Goldman & Gabriel, 2005; Henkel, 2004b; Raymond, 2001a). The problem occurred to Cisco after two employees had devised a clever solution to printer selection and management. The tool they programmed allowed any user to print at any printer in the entire Cisco network—no matter whether it was located on the same floor or on a different continent. In addition, the system guaranteed that in the event of a paper-out or toner-low condition the job would get rerouted to an alternate printer near the target. The system also reported such problems to a printer administrator. Cisco had no intention of ever selling the software, so they released it as OSS to ensure continuous availability and accessibility of the software, in particular in case the original developers would for some reason be unable to provide updates in the future. In 2005, one of the two developers had already left the company (Goldman & Gabriel, 2005; Henkel, 2004b; Raymond, 2001a).

2.4.3 Dual Licensing If the company owns the entire rights44 to the source code of a software product, there are several more options the company has when choosing its licensing model, also with OSS licenses. One of the most prominent examples of this practice is MySQL’s dual licensing model. Whereas MySQL is originally offering its database software under the GPL, one can also purchase the product “MySQL Network” and receive a commercial license at no additional cost instead. This is especially appealing to business customers planning to integrate MySQL into their proprietary products or to those who are afraid of or inexperienced with OSS and fear the potentially viral effects of the GPL. MySQL’s GPLed community edition is available for free to everyone and provides the basis for the enterprise-focused product (Henkel, 2004b; Raymond, 2001a). Moreover,

44

Releasing software as open source does not mean giving away copyright. Under the GPL, too, authors of a piece of code still have the copyrights to the parts they wrote. Copyrights are an important point in releasing software as OSS, as has been mentioned in Sections 2.1, 2.2.4, and 2.3.6 and will also be further elaborated on.

46

Open Source Software: Source of Innovation?

as MySQL owns the entire rights to the source code, it could release future version of the software under a different license than the GPL.45 Trolltech is following a similar approach with its Qt library. It is licensed under the GPL for use in KDE but is also available with a commercial license for companies that want to integrate it into their proprietary products (Goldman & Gabriel, 2005; Raymond, 2001b). Another option to use different licensing schemes to enter the OSS world is to release old versions of the software under an OSS license. Under this licensing model, a company keeps its state-of-the-art developments proprietary but reveals past versions of the software either after a certain period of time or after a major milestone has been completed. This way, intellectual property located in the newest function of the software is protected while the “settled” codebase—the features of which are known to customers and competitors alike—may be improved by an OSS community. However, the risk of forking is relatively high with this business model. Even more, as OSS developers know that the company is supplying them with an out-of-date product it may well be that either no community emerges at all or that—by forking—the OSS community develops a product that is a strong competitor if not superior substitute to the company’s product (Henkel, 2004b; Raymond, 2001a). E-merge GmbH has put an old version of its proprietary ACE-compression algorithm under the GPL. This version of the program—more widely known by the name “unace”—is not capable of handling files provided by WinACE version 2.0 and up. However, there seems to be no significant community working on unace at the moment. A more prominent example used to be GhostScript46 by Artifex Software, one of the most widely-used PostScript and PDF interpreters available (Goldman & Gabriel, 2005), which, however, is by now also available in a GPLed version.

2.4.4 Sale of Complementary Services The most common business model around OSS seems to be the sale of complementary services (Behlendorf, 1999; Hecker, 1999; Raymond, 2001a, 2001b). Indeed, licensing fees hardly ever make up more than 30% of PCSS software cost—the rest is after-sales services (Banker et al., 1991; Koenig, 2004). By switching from a one-timesale, piece-of-software-based model to a continuous stream of service or subscription45

46

This is what happened for example to anti-virus software “Nessus” by Tenable Networks that went from a GPLed version 2 of their software to a closed sourced version 3 (see http://mail.nessus.org/pipermail/nessusannounce/2005-October/msg00000.html, retrieved May 9, 2006). http://www.cs.wisc.edu/~ghost/, retrieved April 4, 2006.

Open Source Software: Source of Innovation?

47

based revenues, companies will receive a more constant and more predictable stream of revenues. Most of the business opportunities involving the sale of complementary services also apply to the sale of proprietary software. These include consulting, implementation, training, and subscription-based models. With OSS, a pure consulting company can offer its customers a wide range of solutions at no additional software cost, making the offer more attractive than a comparable one including licensing fees. More relevant for IT firms, enterprise customers that choose OSS are in most cases also looking for services around the offer. After setting up a prototype or lab version of the software in their company they may decide to go with the software and, usually, with corresponding services to secure, for example, availability. A potential bid or proposal may begin with offering certified versions of the OSS, that is, a stable release containing a combination of well-tested modules and guaranteed interoperability with certain hardware or software platforms. Next, there is the initial installation and configuration of the software at the customer site and its integration into the customer’s unique software landscape. The people to administer the software will need to go through training provided by the company to thoroughly get to know the software and to receive the respective certificate or diploma. Different levels of support (8/5, 24/7) may be agreed upon as well as a limitation on a number of service or support requests or a guaranteed maximum response time by the service team. Usually, all of this is sold together as a subscription-based package with a certain lifetime, generally one or two years. This business model is also well-suited to be combined with the dual licensing model, as the following example of MySQL shows. Enterprise customers of MySQL’s are encouraged to purchase the product “MySQL Network” that exists in four flavors—Basic, Silver, Gold, and Platinum—depending on the level of service the customer wants to have. In addition, MySQL also offers training—5-day database manager or developer trainings start at $165047—and consulting services—starting at around $2500 a day.48 User certification is an additional $200. Furthermore, MySQL offers indemnification at no additional cost for its Gold and Premium packages (see Table 3).49

47 48 49

https://shop.mysql.com/training/, retrieved March 10, 2006. Sites listed at http://www.mysql.com/consulting/packaged/, retrieved March 10, 2006. http://www.mysql.com/network/indemnification.html, retrieved March 10, 2006.

48

Open Source Software: Source of Innovation?

MySQL Network:

Basic

Silver

Gold

Platinum

MySQL Server

Pro

Pro

Pro

Pro

Certified, Optimized Software

Yes

Yes

Yes

Yes

Maintenance, Updates, Upgrades Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Number of Incidents

2

Unlimited

Unlimited

Unlimited

Web Access

Yes

Yes

Yes

Yes

8x5 (M-F)

24x7

24x7

4 hours

2 hours

30 min

30 min

30 min

Yes

Yes

Software

Self Help Support Knowledge Base Problem Resolution Support

Phone Access Max Initial Response Time

2 bus. days

Emergency Resp. Time Consultative Support Remote Troubleshooting Schema Review

Yes

Query Review

Yes

Performance Tuning

Yes

Price (per Server and Year)

$595

Table 3: MySQL Network—Support levels

$1995

$2995

$4995

50

2.4.5 Sale of Complementary Goods In the case of selling complementary goods, the company releasing the software does so to sell complementary proprietary software, hardware, and related gadgets. Gadgets, in this case, are not limited to tee-shirts or coffee mugs, but also include documentations or books on a certain piece of software, a business model made famous by O’Reilly & Associates. In case of releasing OSS in relation to a certain hardware product, the software itself is usually not a profit center. This includes for example drivers or other software that is necessary to make the hardware run. Even though this software is absolutely necessary to sell the hardware, it is just an expense factor for the hardware company which may neither have nor want to build up a specific competence in software development. In other cases, the hardware may well contain embedded software with business logic but 50

https://shop.mysql.com/network.html, retrieved March 10, 2006.

Open Source Software: Source of Innovation?

49

also “irrelevant” parts, such as a web server or a graphical user interface for user configuration management. In most cases the hardware company will reveal its software under an OSS license in order to get better drivers and develop interface tools more cheaply. Creative is for example providing support to the OSS community, the latter trying to make Creative hardware work with Linux (Hecker, 1999; Raymond, 2001a). When talking about releasing software as OSS and selling a complementary software program, most often, one will think about Netscape that gave away its browser for free while trying to make money selling its server product. Despite the fact that the company might still be able to make some, if little, money by selling complementary services or gadgets for the OSS product, the purpose of revealing the software is to increase revenues of the complementary software—the stronger the interconnection between the two, the better. Even if this model may not have worked too well for Netscape—people just used the gratis OSS Apache server—a modification of this model has appeared that seems to be very successful: instead of giving away an entire software product, the company keeps a proprietary core containing the most important functionalities of the software. The company then reveals that part of the source code that either enables or shows interaction with the proprietary core, that is, how to best make use of it. To make using the core even easier, the company might think about releasing a software development kit (SDK). Sometimes, such an SDK may already exist—the company itself might have used it to complete certain parts of product development, such as module design or programming add-ons or plug-ins. The most prominent example of this business model is Valve Inc.’s famous computer game Half-Life. Valve Inc. had developed a superior graphical engine for the game. By releasing much of the source code of the game into the open but keeping the engine proprietary, people were able to develop add-ons, so called mods, to Half-Life, but running these mods still required the user to own a copy of Half-Life. When the userinnovated mod Counter-Strike was introduced to the market, it immediately took off and became an enormous hit. Consequently, everyone who wanted to play CounterStrike was required to purchase a copy of Half-Life, leading to a huge financial success for Valve Inc. (Jeppesen & Molin, 2003). In addition, the engine was licensed to several other companies who developed their games based on Valve Inc.’s graphical engine, creating additional licensing revenue for Valve Inc.

50

Open Source Software: Source of Innovation?

2.5 Implications for the Corporation and its Employees As has been shown in this chapter, voluntary spillovers in general, and the engagement in OSS in particular may come with significant benefits for the cooperation if managed correctly. Organizations may profit from lower cost, quicker time-to-market, higher quality, standard setting, and new business opportunities when using OSS, contributing to existing OSS projects, and releasing proprietary software as OSS. Overall, this shows that there might be considerable potential benefits for corporations coming from an engagement in OSS, but raises the question whether, and, if so, how, corporations can tap this potential. Part two of this thesis will now look at whether corporations (and their employees) can (1) actually perceive the potential inherent in corporate OSS engagement and, if so, (2) should consequently want to realize it. To be able to do this, in this section, I will lay out the process in the course of which the organization evaluates a potential corporate OSS engagement and, eventually, decides about its adoption by the firm.51 Generally, an organization’s adoption of a new idea or behavior is called organizational innovation (Daft, 1978; Damanpour & Evan, 1984; Damanpour, 1991). The innovation process can be segmented into three distinct phases, namely initiation, adoption, and diffusion (Damanpour, 1991; Kwon & Zmud, 1987; Leonard-Barton & Deschamps, 1988; Rogers, 2003; Zmud, 1982). Usually triggered by an organizational need or new technology, the process is initiated by scanning the organization for opportunities or solutions to problems (Cooper & Zmud, 1990). Adoption is the favorable decision by management to commit the required resources to an identified solution, diffusion the dissemination and acceptance of that solution (i.e., the innovation) by members of the organization (Cooper & Zmud, 1990; Rogers, 2003). Following Daft (1978), organizational innovations can be classified as technical and administrative. Technical innovations “occur in the technical system of an organization and are directly related to the primary work activity of the organization. […] Administrative innovations are defined as those that occur in the social system of the organiza-

51

Organizational adoption (or organizational innovation), here, is of course not limited to the mere use of OSS, but also includes contributing to existing OSS projects and releasing proprietary software as OSS. The underlying rationale is that, as shown before in the introductory part of Section 2.3, OSS can both be a product and process innovation to be adopted by the organization. When speaking of a change in what the company produces, that is, the source codes and its “ingredients,” this is obviously a product innovation. This is primarily the case when talking about using OSS as a basis or part of new products. On the other hand, when releasing proprietary software as OSS, whereas this may also imply a product innovation, it is primarily a process innovation as the way in which the product would usually have been developed at the firm needs to be adjusted dramatically to fit the OSS development style (Alexy & Henkel, 2007; Senyard & Michlmayr, 2004).

Open Source Software: Source of Innovation?

51

tion” (Damanpour & Evan, 1984). Although more specific adaptations exist (e.g., Swanson, 1994), this general distinction is well suited to IT innovations (Zmud, 1982, 1984). How each type of innovation is introduced to an organization is a central issue in the present context. As organizational structure is set by management (Burgelman, 1983) and modified by means of administrative innovations, the latter are likely to be introduced in top-down fashion (Daft, 1978). Technical innovations, on the other hand, are more likely to be bottom-up initiatives because individuals disposed to adopting technical innovations often will do so even without management support (Leonard-Barton & Deschamps, 1988). Such activity might culminate in a bottom-up adoption process in which management only subsequently decides that the corporation as a whole should adopt the technology, long after its employees have decided to do so (Grover, 1997; Swanson, 1994). For both technical and administrative innovations, however, the most effective path of introduction has been found to be a two-step process that begins topdown, with management deciding on adopting an innovation overall, and employees then making their personal adoption decisions individually (Cooper & Zmud, 1990; Grover, 1997; Swanson, 1994; Zmud, 1982). Thus, whether adoption begins bottom-up or top-down, successful diffusion of an innovation ultimately relies on the individual adoption decisions of employees (Agarwal, 2000; Zmud, 1984).52 As will be elaborated later, OSS bears many characteristics that enable employees to initiate a bottom-up adoption of it throughout the entire organization. Moreover, I have laid out before several business models that may be introduced by upper management to make use of the advantages OSS has to offer, consequently rendering top-down adoption suitable for organizational adoption of OSS as well. Thus, there is reason to believe that there is a potential for organizational adoption (and its initiation) of corporate OSS engagement on both the micro and the macro-level. Still, we have not seen whether any of the two groups actually perceives this potential, that is, whether they in fact perceive the adoption of corporate OSS engagement as a sensible and likely beneficial activity (i.e., beneficial to them, the corporation, or both), and thus plan to do it or at least would be willing to support such activities. Part two of this thesis will try to answer this question. In Chapter 3, I will first look at how top management evaluates the advantages and disadvantages of corporate OSS engagement presented before to understand the reasons for a top-down initiation of the

52

One might similarly phrase this as adoption on the macro-level (firm) and the micro-level (individual).

52

Open Source Software: Source of Innovation?

adoption process. In Chapter 4, I will then look at OSS from the perspective of the individual employee in order to find out about the potential of bottom-up innovation and how diffusion of corporate OSS practices amongst employees might look like. To capture and adequately address the different effects of the different modes of OSS engagement, I will maintain the segmentation of corporate OSS engagement into using OSS, contributing to existing OSS projects, and releasing proprietary software as OSS throughout the rest of this work.

Top-Down Adoption of OSS

53

3 Top-Down Adoption of OSS53 In this chapter, the reasons why OSS might be introduced to the corporation in a top-down fashion will be looked at. For this, I will assume the role of top-management to understand its evaluation of OSS. Management can be expected to decide in favor of corporate OSS engagement and initiate its top-down adoption if they see that this would be beneficial to the corporation and against it when the downsides outweigh the advantages. In the course of this chapter, I will thus analyze if and under which conditions this decision can be expected to be in favor of OSS. Many organizations have already been using OSS for a long time, and many other firms that had once been faced with the question of whether to use OSS made a welleducated decision against it. Concerning the use of OSS in firms and its potential for top-down adoption, one can thus just ask top managers about their opinion on the use of OSS in firms to see which advantages or disadvantages are being perceived and whether the overall evaluation is negative or positive. This chapter will begin with such an evaluation in Section 3.1. In order to measure the potential benefits of revealing source code, that is, contributing to existing OSS projects and, in particular, releasing proprietary software as OSS, an event study was conducted to capture the value-creating potential such actions may have as measured by changes in the firm’s market valuation. The change in stock price may also provide a more objective measure of the impact of releasing OSS on firm value as opposed to the probably more subjective and biased results that for example a survey might render. The findings of this study are presented in Section 3.2.54

3.1 Specifying the Potential of OSS Use for the Organization To understand why firms eventually decide to adopt OSS, one first needs to understand how they evaluate OSS more specifically, that is, what they base their decision to adopt OSS on.

53

54

I am indebted to Robert Simm and Josef Waltl for their help in creating this part of my thesis. Section 3.1 employs the dataset Mr. Simm built in his Diplom thesis. Mr. Waltl’s Master’s thesis showed the general feasibility of an event study as shown by Section 3.2. The results presented herein are a substantial expansion of his work employing an updated and largely expanded dataset. I would further like to thank Jörn Block, Joachim Henkel, and Simone Käs for several helpful comments and Hans Zischka for valuable assistance in data collection. This method cannot be applied to “using OSS” since it is almost impossible to identify singular “using OSS” events as those would most often not be announced by the corporation.

54

Top-Down Adoption of OSS For most organizations, the first contact with OSS they have is using OSS. As said

in Section 2.3.1, this use can take two basic forms: (1) the firms may use OSS to support its processes (which may but do not have to include the software development process) and IS infrastructure and (2) the firm may develop a proprietary software product that builds on or extends existing OSS. Examples for (1) would be firms using popular desktop applications such as Open Office or Firefox, and also the software package Eclipse to deploy proprietary software; for (2), this could be an Internet application built on the Apache web server and the MySQL database.55 In this section, I will focus on the second aspect of OSS use, analyzing why software firms might use OSS or OSS-based components in developing proprietary applications. As already shown in Section 2.3.1, the use of OSS and its integration as part or basis of a product developed by the organization are most often attributed with lower cost and quicker time-to-market. Yet, these rather general arguments make the use of OSS to develop proprietary software a black box, as for example not all phases of the software development cycle benefit from these possible advantages to an equal extent. For example, time-to-market will be mainly reduced due to the fact that less programming needs to be done by the corporation—while there will probably be little to no change with respect to design or testing. In both popular and academic literature, the most prominent reasons for using OSS and developing products based on it are to a large extent equal to those in favor of reusing software in general. To some degree similar to economies of scale known from manufacturing industries, these advantages encompass performance and productivity increases including lower cost, reduced time-to market, and improved quality. With OSS, however, the potential to reduce cost is far greater than with regular software reuse as has been shown in Section 2.3.1; this argument is even more valid with regards to the ability to customize the software (Henry & Faller, 1995; Lim, 1994; Madanmohan & De', 2004). Eventually, this and the arguments presented in Sections 2.3.1 and 2.3.2, lead me to formulate the following three propositions on how management will evaluate using OSS:

Proposition 1: Compared with proprietary components, the use of OSS components may decrease cost, especially in the coding phase of software development.

55

Whereas this is not a necessity, most firms’ first contact with OSS will take a form as described in (1), only after which some of these firms will decide to move on to (2).

Top-Down Adoption of OSS

55

Proposition 2: Compared with proprietary components, the use of OSS components may improve the innovative performance of the company. Proposition 3: Compared with proprietary components, the use of OSS components should not decrease quality.

3.1.1 Sample In early 2006, I conducted 10 interviews with large software firms that had extensive experience in using OSS components. Based on these interviews and the theoretical arguments presented above, a questionnaire was developed to find out in more detail why firms commit to using OSS and developing products based on it. The questionnaire was then sent out to 264 software developing companies, 40 of which replied, equaling a response rate of around 15%. In the survey, firms were asked to compare OSS to PCSS components with respect to their effect on cost, quality, time-to-market, ability to generate innovations based on the software, strategic reasoning such as standard setting, and legal aspects. For some of these aspects, most notably cost, participants were also asked to split their ratings along the software development process, which was segmented into definition, design, coding, and testing & integration according to the still widely employed waterfall model (Cusumano, MacCormack, Kemerer, & Crandall, 2003; Jones, 2003; Royce, 1987). For the survey, three groups of participants were distinguished: first, group one included firms that were actively using OSS (21 participants), second, group two those who had seriously considered using OSS but eventually decided against (7), and, finally, group three included firms that had not even evaluated using OSS (12).

3.1.2 Variables In accordance with the propositions laid out earlier, the main part of the survey consisted of three blocks of questions concerning the effects of using OSS and developing products based on it with regards to cost, innovative performance, and quality. Cost. Regarding cost, I was especially interested in the effect the use of OSS would have on overall project cost which was specified to include development, licensing, hardware, and maintenance cost. Development costs were then further split up according to the four phases of the software development process specified above: definition, design, coding, and test & integration. Those firms that had at least completed an evaluation of OSS, that is, groups one and two, were asked to give estimations of the poten-

56

Top-Down Adoption of OSS

tial effect on project cost of using OSS and developing products based on it on a 7-point Likert scale ranging from much higher to much lower. Those participants that had in fact decided in favor of using OSS and developing products based on it (group one) should furthermore specify the numerical value of the cost reduction achieved. They were asked to select an answer from a range of values distributed over seven classes (50%) as interviews had indicated that participants would be unwilling to bring up figures themselves. Next, both groups one and two were asked to similarly estimate cost reduction effects on a 7-point Likert scale ranging from much higher to much lower for quality cost, overall development cost, and, separately, development cost for the phases of the software development process listed before. Participants that had decided in favor of OSS (group one) were asked to again numerically specify the observed change based on the above seven-class scheme (50%). Innovative Performance. The basic survey design asking for innovative performance was identical to that of cost. A question asking for a general evaluation was posed to groups one and two. They were additionally asked to share their estimate for the reduction in time-to-market on a 7-point Likert scale ranging from much higher to much lower. People that had decided in favor of OSS (group one) were then asked to further specify this figure and to indicate what share of innovative changes to the product that was using OSS had come from the OSS community, from the firm itself, or from the firm’s suppliers since the firm had decided to use OSS in its product. Quality. The design for quality also matched the above ones: first, a general question on the effect of using OSS and developing products based on it on product quality was posed to firms from groups one and two and answered using a 7-point Likert scale ranging from much higher to much lower. Furthermore, they were asked to evaluate the effects on downtime56 and code documentation (same scale). Firms that were using OSS components to develop proprietary products (group one) were further asked to denote all of these effects quantitatively, using the above seven-class scheme (50%). In addition, I asked them to specify the share of software-related problems they had experienced with the product in relation to the OSS share of the product’s source code.

56

Similarly to the criterion of the same name often used to measure hardware performance, downtime was defined as the share of non-availability of the functionality the software should provide after deployment of the software. This includes for example the time needed to develop bug fixes or to resolve hardware incompatibilities.

Top-Down Adoption of OSS

57

3.1.3 Interview Results Although the interviews were mainly intended to confirm initial assumptions and to improve the survey design, the involvement and commitment shown by the six of the interviewees exceeded expectations by far. I consequently decided to include the results of these interviews herein. Amongst those six firms, there was one hardware manufacturer (hereafter named C1), one company focusing on PCSS (C2)—the company actually planned to reduce its level of exposure to OSS—, one small company specializing in OSS (C3), one traditional PCSS company offering one OSS application (C4), and two larger OSS firms (C5 and C6). Usually, people in charge of distribution (who had a background in software development), product managers, or people in business development were contacted. As is seen Table 4, most interviews gave qualitative support to all three propositions.

Firm Proposition 1: Cost

Proposition 2: Innovative Performance

Proposition 3: Quality

C1

Comparable

---

---

C2

Additional expenditures because of screening etc.

Not enough for special applications

Not enough for special applications

C3

Tend to be lower

Tends to be higher

Mixed

C4

Definitely much lower

Higher

Comparable

C5

Lower despite additional expenditures for certification

Tends to be higher

At least acceptable

C6

Lower in 80% of cases

Development time shorter in majority of cases

At least equal

Table 4: Using of OSS vs. PCSS components—Interview results

In general, OSS was well accepted. PCSS was seen more favorably only for special applications that would be useful to only a certain industry—or company, even. When combining their arguments, it becomes rather clear that cost is the dominating argument why a firm would decide in favor of OSS. This was confirmed when explicitly asking for reasons why to adopt or not to adopt OSS. Here, cost again was the most frequently named item in favor of OSS—quality and innovative performance were also mentioned (see Table 5).

58

Top-Down Adoption of OSS

Firm Pro OSS

Con OSS

C1

Set standard (revealing own source to transform the business)

---

C2

---

Support for CSS is better Complete solution from one supplier demanded Lack of special applications

C3

C4

Technological advantage (esp. security)

Inconsistent development cycles

Follow OSS Hype

Too many forks/competing (derivative) projects in some fields

Market pressure: cost, standards

Indemnification No direct influence on development cycles

C5

Cost

Customers are afraid of patent risks

Open Standards

Too many forks/competing (derivative) projects in some fields

Technological advantages (esp. possibility to integrate into existing solutions) C6

Standards

Customer’s willingness to pay

Market Trend

Customers are afraid of licensing risks

Cost Time-To-Market Security

Table 5: Arguments named in favor and against using OSS components in software development

3.1.4 Survey Results Cost. In general, overall project cost of OSS components vs. PCSS was evaluated overwhelmingly positive: more than 75% of respondents out of groups one and two said that overall cost was lower, with an average value of 2.51. This equals a value right between “slightly less” (3) and “less” (2) compared to a neutral value of 4. Overall development costs are only evaluated to be “slightly less” than with PCSS at 2.85. All phases of the software development cycle received a rating less than the neutral value of 4 (definition phase: 3.73, design: 3.73, coding: 2.92, test & integration: 3.65). 57 The t-test for difference from the neutral value of 4 is significant on a 10% level for definition (p=0.065) and design (p=0.099), insignificant for test & integration (p=0.140), and highly significant for coding (p=0.000). The latter supports Proposition 1. 57

It is interesting to note that even though the respective figures given for definition and design differ amongst the respondents, the mean values are exactly the same. This, to some degree, confirms the tripartite split of the development process laid out in Section 4.1 that is also illustrated in Figure 6 and Figure 7.

Top-Down Adoption of OSS Development Phase

Cost reduction

Definition

3.5%

Design

5.0%

Coding

41.0%

Test & Integration

5.0%

59

Table 6: Reduction in development cost experienced by firms using or developing OSS (N=20)

These findings were confirmed when asking firms using OSS to develop products based on it (group one) to select a category indicating the range of cost reduction they were able to achieve through OSS in each of the four phases of software development. When taking category values, the median values were similar to the above ones (definition: 4, design: 4, coding: 2, test & integration: 4).58 Using a rank sum test shows that definition (p=0.047), design (p=0.015), and test & integration (p=0.051) offer cost reductions vs. PCSS develop that are, apart from the latter, all significant on a 5% level. The median value for coding again significantly differs from 4 (p=0.000). Assuming that the values within the categories are distributed on a linear scale, that is, using the category means as a value, I come up with the cost reductions experienced by the firms using or developing OSS depicted in Table 6. Regarding Proposition 1, it is important to see that out of the 21 firms that have been using OSS to develop products based on it, 18 report cost advantages versus PCSS—two say that OSS and PCSS result in the same costs for coding and one firm did not give an answer to the question. No firm sees OSS at a disadvantage. The average cost reduction in the coding phase of the software development process is estimated to be 41%. Innovative Performance. In a question posed only to people who had at least evaluated OSS (groups one and two), I asked whether they had found OSS to be advantageous with respect to the innovative performance of the firm’s software package containing the OSS application. Innovative performance was further specified to for example include number of new features, enhanced features, and time-to-market. The question received an average reply value of 2.56, suggesting the innovative performance had become “somewhat higher” (3) to “higher” (2) due to the OSS component. Most of this benefit is attributable to time-to-market, as was shown in the follow-up question to people who had used OSS to develop products based on it (group one). With an average 58

Median values and ranksum tests are used as this data is categorical, rendering the use of mean values and t-tests less appropriate (mean values: definition: 3.65, design: 3.5, coding: 2.3, test & integration: 3.5; t-tests vs. the neutral value of 4: definition: p=0.049, design: p=0.014, coding: p=0.000, test & integration: p=0.043).

60

Top-Down Adoption of OSS

value of 2.84, they claimed time-to-market was, on average, reduced by almost 25%. When used, OSS can thus significantly reduce time-to-market of the entire software package, bringing significant advantages to the firm. When asking the same group for the share of sources of innovations of the software, replies from 13 companies were received, stating that as much as 60% of all innovations—but also as little as 2%—originated from OSS components. On average, 22.9% of innovations related to the software package originated from the OSS components, compared to 62.5% from the company’s developers, and 14.6% of PCSS suppliers. Consequently, OSS has become an integral part of some companies’ innovation strategy, surpassing the importance of PCSS suppliers in selected cases. With regards to Proposition 2, we can conclude that the innovative performance of OSS components has at least not decreased the overall innovative performance of the software package provided by these firms, and may have even increased it. Quality. Asking those firms that had at least evaluated OSS (groups one and two) what effect the insertion of OSS code had had on total product quality, this showed a near-balance between OSS and PCSS. Although the overall effect on quality and the specific effect on downtime were evaluated slightly in favor of OSS (quality: 3.11, downtime: 3.33 equaling a 6.7% reduction), the quality of documentation and commentation of the source was rated in favor of PCSS (documentation: 4.50). Looking at the share of software bugs caused by OSS, firms using OSS to develop products based on it (group one) reported that whereas, on average, their software consisted of slightly above 40% OSS source code, this share was responsible for only 16% of all software flaws. This, combined with the results of the above paragraph, indicates that selected OSS components may improve total product quality—not that OSS is by definition of superior quality. Still, this outcome would support Proposition 3 that using OSS components does not decrease total product quality.59

3.1.5 Further Aspects The preceding sections have shown that there is well reason to believe that there are situations in which the use of OSS components may lead to lower cost, situations in 59

In addition, one should consider the possibility that the reported differences in the share of software flaws may result from the fact that the OSS components may be well-tested standard applications such as Linux or Apache, whereas the proprietary software could be an end-user application, as may for example be the case for industryspecific software. Most importantly, these two different kinds of software would reside in different layers of the software stack, and a comparison between the two would thus be inappropriate (I am indebted to Joachim Henkel for pointing this out). I have tried to address this concern in the construction of the respective survey questions by for example explicitly asking for downtime “in relation to comparable proprietary software.” Yet, such a relative comparison was not applicable to the question on the origin of software flaws in the final software package.

Top-Down Adoption of OSS

61

which it will lead to higher innovative performance, and situations in which it will not exhibit a negative effect on quality. In this section, I will try to put an order on the relative importance of these criteria, also with respect to the three different groups of firms in the survey, that is, firms that are using OSS (group one), firms that have decided against using OSS (group two), and firms that have not yet evaluated the use of OSS components (group three). Survey participants from all three groups were asked whether cost, innovative performance, quality, and, furthermore, the possibility to set standards, legal aspects, or other strategic or competitive reasons would speak against or in favor of using OSS components on a 5-point Likert scale ranging from “strongly in favor” (1) to “strongly against” (5) (see Table 7). As said above, the results of this should allow putting a relative importance on the different criteria. Moreover, ordering the three different groups in terms of their advancement with respect to their adoption decision of OSS usage (group three with no evaluation before groups one and two that have both made a decision), this might give insight into the firms’ adoption process of OSS use.

Variable

Median

Mean

Std. Dev.

Min

Max

Gr. 1

Gr. 2

Gr. 3

Cost

2

1.81

In. Perf.

2.5

2.18

0.81

1

4

1.52

2.33

2.10

0.95

1

4

1.95

2.57

2.40

Quality

2

2.68

1.12

1

5

2.33

2.86

3.30

Standard

2

2.08

1.04

1

4

1.86

2.14

2.56

Legal

4

3.55

1.03

1

5

3.19

3.57

4.30

Other

3

2.65

1.07

1

5

2.10

3.20

3.75

Table 7: Comparative evaluation of arguments on OSS use and development

Overall, the propositions from before seem to be confirmed: cost (mean: 1.81), innovative performance (mean: 2.18), and quality (mean: 2.68), are, in that order, evaluated more positively than the neutral value of 3. The difference is significant on a 0.1% level for both cost and innovative performance, and on a 5% level for quality (p=0.045). Whereas cost is also the single strongest argument in favor of OSS for groups one (users of OSS) and three (never evaluated OSS use), it is surpassed by the possibility to set standards in group two (evaluated OSS but decided against). Apart from “other strategic or competitive reasons” the difference between groups one and two is highest for the cost criterion.

62

Top-Down Adoption of OSS Looking at how the ratings of the different criteria changed during the evaluation

process, that is, comparing the scores of the two groups that evaluated OSS (groups one and two) to that group that did not (group three), renders the picture illustrated in Figure 1 (numbers also given in Table 7). Two things become obvious at first glance: (1) legal issues are clearly the most negatively evaluated criterion, and the only criterion valuated more negatively than the neutral value of 3. In fact, this difference is significant for group two (p=0.086). (2) While most criteria, including legal issues, are rated more positively by both groups after their evaluation of OSS as illustrated by a downward slope in the figure, for two criteria, their ratings change for the worse after their evaluation by group two: cost and innovative performance. In addition, the rating of the quality measure by group two is just barely below the neutral value of 3.

Figure 1: Development of rating criteria of OSS usage during evaluation process

Overall, this would suggest that, before the start of an eventual evaluation process (group three), firms are skeptical towards OSS especially for legal reasons. Even though this skepticism is reduced during the evaluation—an issue that was also repeatedly voiced during the interviews I conducted—, it remains the most prominent argument against using OSS components for both firms that decide (group one) and that do not decide (group two) to adopt OSS alike. However, the firms that decide in favor of OSS can reduce this level of skepticism to a level of indifference, while increasing their positive evaluation of all other criteria in the meantime. Those firms that decide against OSS also find benefits with respect to cost, standard setting, and innovative performance. However, both for cost and innovative performance, their respective ratings are not sig-

Top-Down Adoption of OSS

63

nificantly different from before their evaluation—on the contrary, they even show a negative trend. The resulting evaluation of these criteria will consequently not be positive enough to dispel the doubts the firm might have concerning the possible legal issues. Also, other strategic applications such as an increase in reputation in the developer community do not appeal to those firms.

3.1.6 Conclusion Three propositions have initially been phrased. First, using OSS to develop mainly proprietary products based on it may lead to cost reductions especially in the coding part of the development phase. Second, it may improve innovative performance and third, it should not decrease quality. I have found (at least some) support for all three propositions in a study conducted amongst 40 German software developing firms. The findings of this section also coincide with the arguments from theory presented before, and lend further support to the claims made there (see Section 2.3.1). While this study is of course not representative of the entire German or even worldwide software industry, it has highlighted arguments in favor of using OSS brought up by a selected number of firms that have decided to do so in the past. That is, this section has not shown that using OSS will generally lead to lower cost or higher innovative performance, but that specific situations exist in which this may well be the case. Thus, there is reason to believe that using OSS can be beneficial to a firm under certain circumstances. Provided these apply to an organization evaluating using OSS, one should expect management to encourage top-down adoption of this practice. Looking at the reasons why firms might potentially start using OSS to develop products based on it, cost seems to be the strongest supporting argument. More specifically, a large part of the cost savings coming from doing so will be accounted for by the coding phase of the software development process. This can be best explained by the reuse of existing components that are available to the company for free. Not only does this reduce expenditures for coding on average by more than 40%, it allows the firm to complete its product 25% more quickly.60 However, it also means an enormous change for the people involved in the process, as now, in the firm, less emphasis is put on in-house development. Especially for programmers who have become used to solely programming PCSS, this will imply signifi60

Of course, the reduction in development time is most likely the actual source for most of the reduction in expenditures for coding, as software developers will be paid on an hourly basis. However, (1), there are other savings, such as hardware or licensing cost. (2) Reduced time-to-market does not only mean less expenditure for coding but also constitutes a strategic advantage.

64

Top-Down Adoption of OSS

cant changes for their daily work. Although this change might not be that prominent for example for the mere use of OSS, it is likely to become more influential with increased exposure to OSS inherent in contributing to existing OSS projects or in releasing proprietary software under an OSS license. Consequently, it is important to understand the role of the developer in the diffusion of OSS and OSS practices in the firm. This will be looked at more closely in Chapter 4. Legal issues have been identified by the literature as one of the most widely recognized disadvantage of using OSS (see also Section 2.3.2). The study has confirmed this issue. Legal risks including indemnification or licensing issues seem to be what is keeping away many firms from using OSS to develop products based on it. As using OSS, however, may be seen as a prerequisite to further OSS exposure, these firms will most certainly never engage in either contributing to existing OSS projects or releasing proprietary software as OSS. However, many firms have decided to bear these legal risks and are successfully able to cope with them. Over time, those firms have accumulated distinctive knowledge on how to best make use of OSS. Other firms might learn and benefit from these experiences by understanding how to manage the risks inherent not only in using OSS and developing products based on it, but also in contributing to existing OSS projects and in releasing proprietary software as OSS. Consequently, a benchmark study with firms well experienced in OSS was conducted, the results of which will be presented in Section 5.1. In this section, I have shown that of the arguments for and against corporate OSS engagement, the positive ones in many cases outweigh the negative ones with respect to using OSS and developing mainly proprietary products based on it. After firms have decided to do so, some of them might be presented the opportunity to increase their engagement in OSS, that is, to contribute to existing OSS projects or even to release proprietary software as OSS. The potential benefit of these forms of corporate OSS engagement for the organization shall be analyzed next.

3.2 Capital Market Evaluation of Releasing Source Code As I have pointed out before, over the last years, researchers have put much effort into explaining the benefits of OSS, for example regarding its impact on the innovation process within and outside firms, the economic effects of open source strategies of commercial firms, and the effects of openness on the innovative performance on firms (e.g., Dahlander, 2005; Henkel, 2004b, 2005, 2006; Laursen & Salter, 2006; Stewart &

Top-Down Adoption of OSS

65

Gosain, 2006; von Hippel & von Krogh, 2003; West, 2003; West & Gallagher, 2006a). They found that, in many cases, patterns of releasing proprietary software as OSS are consistent with profit maximization, and increased corporate openness might lead to a stronger innovative performance. Still, the current research on OSS does not yet answer the question whether open source activities in general and releasing product source code in particular have an effect on the value of firms—and, more specifically, a positive effect. If managers then perceive this effect and, even better, if managers should be found to be able to influence it, this would again underline the potential for top-down adoption of corporate OSS engagement. In this section, 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, assuming that a positive market valuation will encourage management to initiate top-down adoption of corporate OSS engagement. Building on the set of business models explained before that firms may choose to generate and appropriate value from releasing proprietary software as OSS, namely business transformation, cost or risk reduction, dual licensing, and the sale of complementary goods or service,61 I analyze how the capital market reacts to firms announcing a release of proprietary software as OSS and which factors are influential to this. It will be shown 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, and both of these points can be influenced by management. The event study method is an appropriate 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 the knowledge of the author, no event study measuring the effect of OSS, or open or private-collective innovation efforts on the value of firms has been conducted up till now apart from one event study in the slightly related field of open vs. proprietary Extensible Markup Language (XML) standardization in which Aggarwal et al. (2006) discovered that capital markets react negatively on open XML standardizations in the years 1999 to 2003. During the time span from January 1, 1999, to April 30, 2007, a u-shaped trend in the market reaction to firms announcing the release of source code as OSS is found which can be ascribed to negative investor sentiment after the burst of the dot.com bubble. Furthermore, it turns out that the capital market specifically reacts to the choice of 61

Even though I have presented the sale of complementary goods and the sale of complementary services as two separate business models before, due to restrictions in the dataset, I have combined them in this section.

66

Top-Down Adoption of OSS

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 short-term revenue model. The rest of this section is organized as follows. Building on the findings of Chapter 2, first, the relevant literature on advantages and disadvantages of OSS for firms as well as business models they might choose when releasing their proprietary software will be summarized briefly. From this, the hypotheses for the event study will be deduced, also including the market and investor perspective. Next, data and methods are introduced, and, thereafter, the results of the event study are presented. Finally, the implications of the findings and limitations of the study are discussed and recommendations for future research are given.

3.2.1 Hypotheses Earlier in this thesis, I have listed several business models proprietary software firms might follow when releasing their software as OSS. As is shown in Table 8, which is a summary of the chapter on business models, there are important differences in the revenue models accompanying the four business models. It becomes obvious 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 (short-term vs. long-term focus) and appropriability (financial gain that is clearly attributable to OSS efforts). When thinking about investors valuating these four business models 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 expressed as an easy-to-understand business model, and a revenue model in particular, whereas the business transformation approach 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 announcing a release of proprietary software as OSS using the business transformation model will see this more negatively evaluated than firms choosing one of the three other strategies.

H1: Firms following the business transformation strategy will be evaluated less positively by investors than those firms releasing proprietary software as OSS using another business model.

Business transformation

Potential goals

Examples



preventing a competitor from establishing or keeping a dominant standard (“preventing a choke hold”)



Netscape releases source code of Navigator to prevent Microsoft from locking up HTTP and HTML (Raymond, 2001a)



setting a standard or tipping the standard race in favor of oneself



IBM releases Eclipse to replace Sun’s or Microsoft’s “native” software development products with its own standard cross-development framework (Koenig, 2004)



commoditizing a layer of the software stack that is of little to no value to the company



IBM’s support of Linux provided a common set of APIs across IBM’s entire product line, it changed the area of competition so that IBM was able to show its traditional strengths in services, availability, and reliability (West, 2003)



advertising oneself as softwaredeveloping company on the job market



Dresdner Kleinwort Wasserstein releases openadaptor in January 2001 because, in late 2000, “it was very difficult to employ competent developers, because everybody was interested in joining startups and getting their share options.” Making openadaptor an OSS project “acted as a kind of advert […] we are a bank but we do really cool stuff” (Henkel, 2004b).

Revenue source No direct source of income. Benefits will only become visible in the long run and may not be clearly attributable to the OSS release.

Top-Down Adoption of OSS

Business Model

67

Dual licensing

OSS is cheaper than doing proprietary software development for components that provide basic functionality and little to no sales value, yet are highly critical



IBM replaces its own web server development with Apache (Hecker, 1999; Raymond, 2001b)



Software is not related to the core business, yet further existence of the software is necessary. Releasing the software as OSS helps by reducing the developers’ amount of work on the non-business-relevant program and by securing a continuous stream of actualizations even if they have turned to other projects or left the company



Two employees at Cisco had devised a clever solution to printer selection and management in the late 1990s. Cisco had no intention of ever selling the software, so they released it into open source. By 2005, one of the two developers had already left the company (Goldman & Gabriel, 2005; Henkel, 2004b; Raymond, 2001a)



Company offers different licenses of the product to different customer groups, for example a free version to individuals and a commercial version under a company-friendly license to firms



MySQL offers its database for free to individual developers and offers companies the possibility to purchase commercial licenses that allow for easy integration even into proprietary software products (Goldman & Gabriel, 2005; Raymond, 2001b)

Usually, no source of income, but potential for cost reduction. Short-term to mid-term.

Licensing revenue. Short-term to mid-term.

Top-Down Adoption of OSS

Precondition: firms owns 100% of copyrights



68

Cost or risk reduction



Services such as consulting, implementation, training, and subscription-based models, as enterprise customers that choose OSS are in most cases also looking for services around the offer (most easily applicable model)



Most entirely OSS-based firms run this business model. OSS also allows start-ups to overcome entry barriers and liabilities of newness and smallness and they are typically faced with (Gruber & Henkel, 2006)



Goods such as software, hardware, documentation, books, or gadgets. In case of releasing OSS related to a certain hardware product, the software itself is usually not a profit center, for example drivers



Creative is providing support to the OSS developers trying to make Creative hardware work with Linux (Hecker, 1999; Raymond, 2001a).



Adapted model: instead of giving away an entire software product, the company keeps a proprietary core containing the most important functionalities of the software. The company then releases that part of the source code that either enables or shows interaction with the proprietary core, that is, how to best make use of it. To make using the core even easier, the company might think about releasing a software development kit (SDK)



Valve Inc. had developed a superior graphical engine for the game Half-Life. By revealing much of the source code of its game but keeping the engine proprietary, people were able to develop add-ons, so called mods, to Half-Life, but running these mods still required the user to own a copy of HalfLife. When the user-innovated mod Counter-Strike was introduced to the market, it immediately took off and became an enormous hit (Jeppesen & Molin, 2003).

Revenue stream from sale of complementary good or services. Shortterm to midterm.

Top-Down Adoption of OSS

Table 8: Business models in OSS

Sale of complementary goods or services

69

70

Top-Down Adoption of OSS Another factor influencing the valuation of IT investments in general that seems to

have been neglected in previous event studies on the impact of IT investments on the value of firms—and one that is particularly relevant to this area—is the assumption of rational investor behavior underlying event studies, that is, that investors treat similar investments equally. However, with the dot.com bubble and its burst at the beginning of this decade, the IT industry is one of the most prominent example of irrational investor behavior of our time: between 1999 and 2001, the NASDAQ saw an increase in value from around 2,200 points in early 1999, to more than 5,000 points in March 2000 (and a total price-to-earnings multiple of 165 taking all NASDAQ firms), and, after the burst of the bubble, back to less than 1,400 points in September 2001. In IT-related event studies, time, so far, has mainly been included to explain the delayed effect of IT investments on firm value and productivity (see, e.g., Im, Dow, & Grover, 2001). Yet, very few event studies have explicitly addressed the effect on market valuation attributable to the timing of the event, that is, the day on which it happened: the timing of an event may directly influence its valuation due to investor sentiment;62 with respect to the IT industry, this is of particular importance with respect to the dot.com bubble. In this section, I will thus also tackle the question of whether the timing of releasing proprietary software as OSS has an impact on its valuation by the capital market, and whether management might thus be able to impact the valuation of such an effort by deliberately influencing its timing. Past studies have shown which kinds of IT investments are valuated differently from one another, for example that innovative IT investments are valuated more positively than non-innovative ones (Dos Santos et al., 1993) and that the strategic importance of IT is related positively to the valuation of transformational IT investments (Dehning, Richardson, & Zmud, 2003). Moreover, Im et al. (2001) found that stock price and trading volume of firms announcing an IT investment were negatively related to firm size, and that the market reaction (independently of firm size) became more positive as time passed. The latter is in accordance with findings from related studies that the positive effects of IT investments only become visible over time (Brynjolfsson, 1993). Time, however, does not only play a role with respect to the effects, that is, the time horizon (short-term vs. long-term perspective) of the decision to go OSS, the timing of the announcement, too, might be of vital importance. The importance of this observation lies in the fact that, sometimes, investors on capital markets are not behaving ra62

Investor sentiment is an argument from the behavioral finance literature. For an introduction beyond the scope given later in this thesis, see e.g. Shiller (2005).

Top-Down Adoption of OSS

71

tionally. Instead, they, too, are subject to sentiment (De Long, Shleifer, Summers, & Waldmann, 1990; Lee, Shleifer, & Thaler, 1991). Following the definition of Baker and Wurgler (2007), investor sentiment “is a belief about future cash flows and investment risks that is not justified by the facts at hand.” Investors will value stocks more positively in a time of positive investor sentiment and more negatively in a time of negative investor sentiment. Shleifer and Vishny (1997) have furthermore shown that it is both costly and risky for investors to buy and sell against investor sentiment, leading to an inefficient market driven by herd behavior (Banerjee, 1992; Bikhchandani, Hirshleifer, & Welch, 1992) that may well result in a crash (Avery & Zemsky, 1998; Lee, 1998). Reinforcing this effect, managers seem to be able to react to investor sentiment, so that they for example time IPOs to happen during phases of positive investor sentiment (Baker & Wurgler, 2000; Lee et al., 1991). The rise and fall of Internet-related stocks in the dot.com boom and the eventual burst of the bubble is a prime example of the phenomenon of irrational investor behavior and investor sentiment. In the following, I will give the results of several studies that help illustrate the effect of the dot.com bubble on the market valuation of IT investments. 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 mid2000, whereas Cooper et al. (2005) show a positive effect caused by 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.63 OSS is strongly linked to the dot.com bubble as (1) the term “open source” was first publicly announced on April 8, 1998, right during the dot.com hype and in the course of the source code release of the Internet browser Netscape Navigator (Tiemann, 2006), (2) the spread of OSS and OSS development methodologies solely depended on the availability of cheap mass communication as provided by the Internet (Raymond, 2001b), and (3) the release of product source code is an IT-enabled strategic decision as it has a 63

Dehning et al. (2004) already observe an effect of time, that is, the timing of the announcement of an IT investment on its valuation by the capital market. Relating this to informational cascade and avalanche (Lee, 1998), Dehning et al. (2004) report that the timing of the announcement has an impact on the volatility of (abnormal) returns and that there is a higher volatility during the dot.com years. I, however, will argue that there is a causal and directed relationship, namely a u-shaped one, between the timing of the announcement and the observed abnormal returns.

72

Top-Down Adoption of OSS

long-term impact on the firm and its ability to generate and appropriate value (Dahlander, 2005; West & Gallagher, 2006a), and the software development process of the firm (Senyard & Michlmayr, 2004). Concerning previous studies on 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 on their market value between 1999 and 2003. They find an overall negative effect which they argue is due to the fact that the firm may obtain a small monopoly with the proprietary standard, which is supposed to be evaluated more highly by the capital market than the potential of getting a small share of a larger market through open XML standardization. Yet, in line with the above argumentation, the effect of the release of an open XML standard is most negative for the year 2001—right after the dot.com crash. Furthermore, they find a curvilinear trend in the number of releases: both total announcements and announcements of open standards increase until culminating in 2000 and steadily decrease afterwards. Following the above argumentation on investor sentiment, companies announcing a release of product source code as OSS should first, that is, in the early years of OSS after its inception in 1998, have received a premium on their stock price during the rise of the dot.com bubble. Other companies should have been able to observe this effect and follow suit. With the burst of the dot.com bubble in the second half of 2000, market valuation should then turn negative. The number of release announcements will become smaller, too. Over time, investor sentiment with respect to IT investments in general, and to the announcement of the release of (potential) commercial products under an OSS license in particular, should normalize; the fall in the number of investments and their valuation by the capital market should flatten and, thereafter, come to a hold (Baker & Wurgler, 2000; Cooper et al., 2005; Lee et al., 1991). Eventually, the number of announcements and their valuation by investors should again increase (Baker & Wurgler, 2007; Dehning et al., 2004). Valuation by the capital market might even become positive again, as would be the norm for strategic or innovative IT investments (Dehning et al., 2003; Dos Santos et al., 1993), as which, as said earlier, the release of proprietary software as OSS might be considered.

H2: In the period of time from 1998 to 2007, there will be a u-shaped development of the effect on stock price of firms announcing the release of proprietary software as OSS.

Top-Down Adoption of OSS

73

3.2.2 Method and Data Event Study Methodology. Event studies have been widely used in both management (McWilliams & Siegel, 1997) and IS literature (see, e.g., Dehning & Richardson, 2002; Dehning et al., 2003; Dos Santos et al., 1993; Im et al., 2001; Oh et al., 2006) but are new to the field of openness in general and OSS in particular. The research design used in this chapter is mainly based on the papers of Campbell, Lo, and MacKinlay (1997), MacKinlay (1997), McWilliams and Siegel (1997), and McWilliams and McWilliams (2000). In an event study, the stock market reactions on the public disclosure of specific information affecting a firm are investigated. According to the efficient market hypothesis (Fama, Fisher, Jensen, & Roll, 1969), the semi-strong form of which is underlying an event study, the market reacts to the announcement of new information. Basically all publicly available information goes into the stock price of firms. An event is anything that results in new relevant information which may have an impact on the future cash flows of a firm (McWilliams and Siegel 1997). Thus, when software or technology companies announce the release of source code to the public the information of releasing code can be expected to be included in the stock price shortly after the announcement (Dann, Mayers, Rafts, & Jr, 1977; Mitchell & Netter, 1989). An event study works with the daily returns of stocks in a time series. There are two time windows in this time series (see Figure 2). The estimation window W1 is the time slot prior to the event where the typical return of the stock is calculated. The event window W2 has an anticipation component prior to the event and a market reaction component after the event.

Figure 2: Time windows in event studies (based on MacKinlay (1997))

Event Definition and Selection. For this event study, an event is defined as follows. An event is the announcement of the release of proprietary source code—that could have been sold (or has been) as a product—under an OSI compliant license either to an existing public open source project or by setting up a new public OSS project.

Using Lexis Nexis, I searched the PR-Newswire, Business Wire, and Market Wire database using the search term “open source AND (contribute OR release OR reveal)

74

Top-Down Adoption of OSS

AND code” from January 1999 to April 2007. After checking whether the company that released code was listed on the AMEX, NYSE, or NASDAQ and whether the event fit to the event definition, 111 events by 58 distinctive firms were identified. It is interesting to see that the total number of release announcements, that is, taking both publicly listed and non-listed firms, for both 2005 and 2006 was higher than that of 2000 implying that OSS activity of those years has surpassed that before the burst of the dot.com bubble. However, during the search, a large number of firms engaging in OSS were found to be rather small, privately-owned companies, which were consequently not listed on a stock exchange. Furthermore, larger, more renowned OSS firms, though sometimes already VC-backed, are also often still far from an IPO stage and some of those few close to an IPO may well get acquired before they are ever publicly traded.64 Estimation Window, Event Window, and Check for Confounding Events. After creating a sample of events the time windows had to be specified. The length of the windows was strongly orientated on the window length found in the related literature (Brown & Warner, 1985; Campbell et al., 1997; MacKinlay, 1997; McWilliams & Siegel, 1997). The estimation window was defined as 125 trading days and the event window as two days including the event day and the day prior to the event. The inclusion of the day prior to the event was to take anticipation effects into account. I then checked for confounding events within this period of time. A confounding event was defined as an announcement within the event window that might have overshadowed the effect of the actual event on the stock price of the company. Confounding events were for example the announcement of new products, information about pending lawsuits, or the release of quarterly or annual reports. The check for confounding events eliminated 69 of the 111 events. A possible reason for the mass of confounding events may be that many software companies tend to publish information on new products, strategic partnerships, etc. in bundles on conferences and other mass events.65 In addition, four more events had to be removed from the sample; three events because the IPO of the respective firms had only happened recently, so that the available stock price data would not have sufficed for the 125-day estimation window, one event was removed because the respective firm was considered for delisting at the time of the event. A list of all remaining 38 events by 30 firms with no confounding events is given in Table 9. As is depicted in Figure 3, the u-shaped

64

65

For example, at the beginning of 2008, Sun Microsystems bought MySQL AB. Industry observers had anticipated the IPO of MySQL AB for 2008. An example of such a conference is the JavaOne conference organized by Sun Microsystems Inc. (SUN, 2007).

Top-Down Adoption of OSS

75

trend in the number of releases per year still holds for the final dataset. More detailed event descriptions can be found in Table 10.

Figure 3: Distribution of events over time

Calculation of Abnormal Returns. Abnormal returns are returns achieved by one stock that are significantly higher or lower than the returns of the market. To calculate them, first the expected return for each event i on day t is approximated and then the difference between the real returns of the market and the expected returns Rit leads to abnormal returns. The return of the market is estimated using the market model.66 The model shown in equation 1 includes αi as intercept, βi is the slope parameter and εi is the error term which is expected to be zero in case of no event-specific influence. The variable Rmt is the return on a comparable market on day t (McWilliams & Siegel, 1997).

Rit   i   i Rmt   it

Equation 1: Calculation of expected returns

From the market model the abnormal return ARit of event i is calculated. Equation 2 shows that ARit is the difference between the real day-to-day return Rit calculated from actual stock prices and the expected return ai + biRmt based on the market model prediction from equation 1 (MacKinlay, 1997). The parameters ai and bi are calculated with an ordinary least squares (OLS) regression of Rit on Rmt over the estimation window. As is done in most IT-related event studies, I used the NASDAQ Composite Index as compa-

66

A detailed description of the market model can be found in the paper of MacKinlay (1997). Binder (1998) shows that it has advantages compared to the capital asset pricing model, the mean adjusted returns model, and the market adjusted returns model. According to both Strong (1992) and Park (2004) the market model is the most popular model used in event studies.

76

Top-Down Adoption of OSS

rable market index.67 The time series data of the NASDAQ Composite Index and the securities were taken from Thompson Financial Datastream. It has to be noted that the time series data from Thompson Financial Datastream excludes all weekends but not the official holidays and other non-trading days (e.g. the days after September 11, 2001). These days were excluded manually from the dataset.

ARit  Rit ai  bi Rmt

Equation 2: Calculation of abnormal returns

To get evidence of the impact that a specific event has on the stock price the abnormal returns in the event window are aggregated. They can be aggregated over time and across several events (MacKinlay, 1997). In case the aggregation through time is carried out the abnormal returns ARit for a single security are aggregated across the event window. In equation 3, CARi is the cumulated abnormal return for a specific security and T2 the first and T4 the last day of the event window.68 This variable also was the dependent variable in the multivariate analysis.

T4

CARi   ARit

Equation 3: Calculation of cumulative abnormal returns for a security

t T2

For an aggregation across events the average return for each day t in the event window is calculated. ARt is the average abnormal return for one day t in the event window across all events N. The average cumulated abnormal return CAR for all events N shown in equation 5 is derived from equations 3 or 4.

ARt 

1 N

N

 AR

Equation 4: Calculation of abnormal returns for all securities on one day it

i 1

T4

CAR   ARt  t T2

67

68

1 N

N

 CAR

Equation 5: Calculation of average cumulative abnormal returns

i

i 1

Similar analyses were also conducted using the S&P 500 as comparable market index only to arrive at similar results. As I am only using a two-day event window in this study, T3 and T4 were in fact the same day (see also Figure 2). For the sake of consistency, I will refer to the end of the event window as T4.

Top-Down Adoption of OSS

77

ID Event

Date

CARi

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

1999-03-01 1999-03-02 1999-04-26 1999-07-27 2000-02-14 2000-02-15 2000-03-13 2000-06-15 2000-08-22 2000-09-11 2000-10-04 2000-11-06 2000-12-11 2001-01-30 2001-04-25 2001-08-07 2001-11-05 2002-05-30 2002-08-14 2002-09-25 2003-04-29 2003-07-07 2004-05-19 2004-11-01 2005-06-20 2005-06-21 2005-07-19 2005-08-09 2005-08-09 2005-08-15 2006-03-07 2006-07-31 2006-08-23 2006-10-02 2006-10-11 2006-11-07 2006-11-13 2007-04-26

0.86% 10.86% 4.18% 5.32% -0.57% -0.84% -3.92% -3.27% -1.80% 12.39% -3.79% 4.97% 0.02% 1.05% -8.38% 1.08% -1.36% -3.01% 1.12% -2.25% -7.57% -0.48% 1.26% 11.50% -1.09% -2.51% -2.97% 0.88% 0.61% 0.42% -1.04% 1.46% 3.21% 0.67% 4.92% 2.75% -2.09% 0.07%

3DFX INTERACTIVE APPLIX SILICON GRAPHICS VISIO SILICON GRAPHICS BINDVIEW DEV SUN MICROSYSTEMS INTEL SYBASE CADENCE DESIGN SYS. SAP SANCHEZ COMPUTER PROGRESS SOFTWARE ADAPTEC SUN MICROSYSTEMS ON2 TECHS. IBM OPENWAVE SYS. ORACLE APPLE COMMERCE ONE REALNETWORKS BEA SYSTEMS TIPPINGPOINT TECHS. IONA TECHNOLOGIES EBAY QUOVADX ORACLE IBM IBM AUTODESK WIND RIVER SYSTEMS SUN MICROSYSTEMS TIBCO SOFTWARE QUALCOMM ADOBE SYSTEMS SUN MICROSYSTEMS ADOBE SYSTEMS

Table 9: List of all events

Main OSS business model as stated Comp. goods/services Comp. goods/services Comp. goods/services Dual licensing Comp. goods/services Business transform. Comp. goods/services Comp. goods/services Cost/risk reduction Comp. goods/services Comp. goods/services Comp. goods/services Comp. goods/services Comp. goods/services Business transform. Business transform. Business transform. Comp. goods/services Comp. goods/services Business transform. Business transform. Dual licensing Comp. goods/services Comp. goods/services Business transform. Comp. goods/services Business transform. Comp. goods/services Comp. goods/services Business transform. Comp. goods/services Comp. goods/services Business transform. Dual licensing Cost/risk reduction Business transform. Business transform. Dual licensing

78

Top-Down Adoption of OSS

ID 1

Event (Title of Release Announcement) 3Dfx Interactive Enables Cross-Platform Development Through Linux Community Applix Launches Open Source Initiative With Applix SHELF; Embeddable, Graphical Programming Language Now Available for Applixware SGI Contributes Key Storage Area Network Media Management Software to Open Source Community Visio Announces Source Code Collaboration Initiative for IntelliCAD Technology SGI Demonstrates High-Performance Itanium Processor Compilers at Intel Forum; Technology to Enhance Linux Application Performance to Be Released to Open Source Community RAZOR Team Offers Free Utility to Put Zombies Back to Sleep Sun Microsystems Announces Plans to Release Cross-Platform Java(TM) Development Tool Code to Open Source Community Intel Software to Make Linux-Based Internet Access and Home Networking Devices Easier to Use Sybase to Open Source Watcom C/C++ and Fortran Compilers Cadence Offers Testbench Authoring Technology as Open Source Solution for Verification Challenges SAP Drives Open-Source Database Development Sanchez Offers GT.M Database as Open Source Freeware to GNU/Linux Users Progress Software Announces Open Source Availability of Its Application Development Environment Adaptec Embraces Open Source/Linux Community Sun Unveils Project JXTA On2 Technologies to Open Source VP3.2 Video Compression Technology; Full-Screen, HighQuality Video Technology Available to Software Community IBM Donates $40 Million of Software to Open Source Community Openwave Contributes Open Usability Interface to Open Source Community Oracle Announces New Clustered File System for Linux Apple 'Open Sources' Rendezvous Commerce One Releases Open Source, Royalty Free DocSOAP XML Developer Kit for Document Style SOAP RealNetworks Releases Industry Standard SMIL Source Code to Helix Community BEA Plans Open Source Project to Accelerate Java Adoption and Provide Universal Framework for Enterprise Java Applications TippingPoint Releases Open Source Code for First Intrusion Prevention Test Tool, Tomahawk IONA to Introduce Open Source Java Enterprise Service Bus eBay Introduces Community Codebase for Open Source Developers Rogue Wave Software Donates Programming Code for Enterprise Software Development to Open Source Community Oracle's Industry Leading Cluster File System Endorsed by Linux Community IBM Unveils Services and Contributes Management Console Code for Apache Software Foundation Geronimo Project IBM Contributes Open Source Code to Make FireFox Browser More Accessible Autodesk Announces Availability of MapGuide Open Source Web Mapping Software Through the Open Source Geospatial Foundation Wind River Contributes Over 300,000 Lines of Code to the Eclipse Foundation Sun Open Sources Java Mobile Edition Development Tool TIBCO to Open Source Best-Rated AJAX Rich Internet Application Toolkit QUALCOMM Launches Project in Collaboration With Mozilla Foundation to Develop Open Source Version of Eudora Email Program Adobe and Mozilla Foundation to Open Source Flash Player Scripting Engine Sun Open Sources Java Platform and Releases Source Code Under GPL License Via NetBeans and Java.net Communities Adobe to Open Source Flex

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

Table 10: Event descriptions

Top-Down Adoption of OSS

79

Independent Variables for Multivariate Analysis. The business model was coded based on the categories introduced before. In the press releases, I looked for information on which of the above business models the firm was primarily intending to follow. This was coded as a dummy variable with respect to whether the business transformation model had been chosen or not. In order to ensure reliability of this variable, multiple coders completed such a categorization independently of one another. Differences were resolved in discussions afterwards, and the final categorization was unanimously accepted. In order to measure the effect of investor sentiment with respect to the rise and fall of the dot.com bubble, I calculated the number of days that had passed since the press conference on April 8, 1998 (Tiemann, 2006), in which the term “open source” was coined and the day of the event. For ease of interpretation, this figure was divided by 365.25 to arrive at the number of years. To account for the assumed u-shaped relationship, a variable “time-squared” was included in the regression.69 Control Variables for Multivariate Analysis. Henkel (2006) found that small firms tend to release more code since they lack development resources and benefit from external development support.70 In addition, the firm’s R&D-to-sales and sales-peremployee ratio were included to account for research intensity of the firm and employee productivity. Sales per employee were transformed to $1 million sales per employees to ease interpretability of the results. Descriptive statistics on both dependent and control variables can be found in Table 11, correlations are given in Table 12.

CARi Time Time2 ln(Total Assets) (ln(Total Assets))2 R&D-to-sales Sales ($mn) per employee Business transformation

Median 0.00 4.41 19.43 14.40 207.26 0.16 0.28 0.00

Mean 0.01 4.86 30.96 14.37 212.91 0.22 2.30 0.32

Std. dev. 0.04 2.74 27.78 2.58 72.38 0.28 12.48

Min -0.08 0.90 0.80 8.28 68.49 0.06 0.00 0

Max 0.12 9.05 81.88 18.46 340.74 1.74 77.21 1

Table 11: Descriptive statistics (N=38) 71 69

70

71

Similarly, one may include dummy variables for the separate years (see, e.g., Aggarwal et al., 2006) which would also allow to more accurately analyze for different effects in the individual years. I refrained from doing so in this study and instead used the time and time-squared measures to reduce the number of variables in the regression because of the sample size. I have also conducted a regression using only time-dummy variables, dropping the singular event from 2007, arriving at similar results as those depicted herein. I used several measures to control for firm size, namely total assets, number of employees, and total sales. Joint insignificance is only observed when measuring firm size by the number of employees. In none of the two remaining specifications, firm size had any effect on the variables under consideration in this section (see also Table 15). The specification using total assets will be reported throughout the course of this section. Both median and mean CARi are positive: median value is 0.24%, mean value is 0.60%.

1 -0.56** 0.22 -0.04

1 0.02 1 0.28† -0.11

Business transformation

1 0.20 -0.07 0.10 0.22

Sales ($mn) per employee

1 -0.05 -0.12 -0.04 0.41* -0.34*

R&D-to-sales

ln(Total assets)

CARi Time ln (Total assets) R&D-to-sales ratio Sales ($mn) per employee Business transformation

Time

Top-Down Adoption of OSS

CARi

80

1

Table 12: Correlation table † * **

p < .10 p < .05 p < .01 (p-values are two-sided)

3.2.3 Results With respect to the first hypothesis, in a univariate analysis, the event sample is first split in two parts based on whether the firms chose the business transformation model or not. As is depicted in Table 13, firms following the business transformation model are evaluated significantly more negatively than their peers following a different business model (p-valueone-sided = 0.02). The evaluation of -1.6% is also significantly different from zero (p-valueone-sided = 0.07), as is the positive evaluation of +1.6% for the other business models (p-valueone-sided = 0.04). Firms using one of the business models cost or risk reduction, dual licensing, or sales of complementary goods or services specifically achieved abnormal returns of 1.7% on the event day, which is also significantly different from zero on a 5% level using the Corrado test (Corrado, 1989), whereas firms employing the business transformation model achieve negative returns on both days. 72 In the multivariate analysis, I take a look at factors influencing the CAR for the individual events. Conducting a regression analysis with CARi as dependent variable using the independent and control variables introduced before, I arrive at a model with an R2 of 44% (see Table 14). Regarding H1, the use of the business model “business transformation” is compared with the other three, that is, I included a dummy variable mea72

Looking at overall abnormal returns, it would come at no surprise if, over all events, I cannot find an average CAR significantly different from zero, due to the hypothesized u-shape of abnormal returns over time. The nonparametric rank test introduced by Corrado (1989) has been reviewed to be the most powerful test in the academic literature on event studies (Campbell & Wasley, 1993). In short, the test statistic of the Corrado test is the ratio of the mean deviation of the event day ranks to the estimated standard deviation of the mean abnormal rank over all events (Campbell & Wasley, 1993; Corrado, 1989). For the sample, the Corrado test results in a test statistic of -0.51 (p = 0.61), showing that, on average and over time, the firms in the sample did not achieve abnormal returns significantly different from zero.

Top-Down Adoption of OSS

81

suring whether the business model “business transformation” was chosen (value = 1) or not (value = 0) in the regression, thereby making the selection of any of the other three business models the reference group. The business model business transformation is indeed found to be valued more negatively on a 5% level of significance (p-valueone-sided = 0.03). As both a univariate and a multivariate analysis show this effect, H1 is, consequently, fully confirmed.

Business Model

Obs.

Mean

Std. Err

Business transf.

12

-1.60%

Other

26

1.61%

T-test

0.018**

Std. Dev.

Min

Max

0.010

0.035

-8.38%

3.21%

0.009

0.045

-3.92%

12.39%

(p-value, one-sided)

Table 13: Statistics of CARi by business model

Independent Variable Time 2

Time

ln(Total Assets) 2

(ln(Total Assets)) R&D-to-sales

Sales ($mn) per employee Business Model: Business transformation Constant Observations R2

Coefficient Value

Rob. Std. Err.

-0.030*

0.011

0.003*

0.001

-0.040

0.027

0.001

0.001

-0.029

0.025

0.002** -0.025†

0.012

0.379†

0.199

38 0.438

F-statistic

77.847**

Degrees of freedom

31

Table 14: Results of OLS regression of CARi † * **

p < .10 p < .05 p < .01 (p-values are two-sided)

0.000

82

Top-Down Adoption of OSS

Independent Variables Time Time2

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

-0.029* (0.014) 0.003* (0.001)

-0.028† (0.014) 0.003* (0.001) -0.001 (0.003)

-0.030* (0.014) 0.003* (0.001) -0.016 (0.019) 0.001 (0.001)

-0.028* (0.013) 0.003* (0.001) -0.030 (0.026) 0.001 (0.001)

-0.034** (0.012) 0.003** (0.001) -0.027 (0.025) 0.001 (0.001)

-0.030* (0.011) 0.003* (0.001) -0.040 (0.027) 0.001 (0.001)

-0.027* (0.011) 0.002* (0.001) -0.046† (0.025) 0.001 (0.001)

-0.026* (0.010) 0.002* (0.001)

ln(Total Assets) (ln(Total Assets))2 ln(Sales) (ln(Sales))

-0.031† (0.016) 0.001 (0.001)

2

R&D to Sales R&D to Total Assets Sales ($mn) per employee Bus. model: Bus. Transformation Time x business transformation Constant Observations R2 F-statistic Maximum likelihood Degrees of freedom

-0.025 (0.026)

-0.035 (0.026)

-0.029 (0.025)

-0.024 (0.025) -0.051 (0.033)

0.060† (0.030)

0.079 (0.051)

0.181 (0.137)

0.290 (0.199)

0.002** 0.002** 0.002** (0.000) (0.000) (0.000) -0.025† -0.069* (0.012) (0.030) 0.007† (0.004) 0.297 0.379† 0.419* (0.191) (0.199) (0.186)

0.002** (0.000) -0.063* (0.030) 0.008† (0.004)

38 0.107 2.249 67.275

38 0.11 1.470 67.425

38 0.12 1.281 67.587

38 0.132 1.123 67.814

38 0.385 84.727 74.351

38 0.44 77.847 76.050

38 0.469 129.901 77.133

38 0.492 89.542 77.991

36

35

34

33

32

31

30

30

0.319* (0.120)

Table 15: Robustness check of time variables in different model specifications † p < .10, * p < .05, ** p < .01

(p-values are two-sided), Robust standard error in parentheses.

With respect to the second hypothesis, as expected, descriptive statistics show a ushaped trend in the number of announcements over time (see Figure 3). Looking at how time influences CARi in the above regression analysis (see Table 14), both measures— years since the inception and OSS and years squared—carry the expected sign and are highly significant (pone-sided < 0.01 for both)73 resulting in the predicted u-shaped trend.74 This is further confirmed using different specifications of the original regression, in all of which the two variables are highly significant (pone-sided < 0.03 in all regressions) as is shown in Table 15. 73

74

While I have reported results of two-sided tests in my regression results (see Tables 14, Table 15, and 17), since my hypothesis are directed, I can actually use the results of a one-sided test to confirm those. With respect to the main variables of interest, I will report results of two-sided test in the tables showing the regression results while using the results of one-sided t-test in the text describing the remainder of this section. As is shown in Table 15 (specifications (7) and (8)) and Table 17, the u-shaped trend still holds when integrating an interaction term between time and the business transformation model to capture potential long-term effects of this business model. I will further elaborate on this in Section 3.2.4.

Top-Down Adoption of OSS

83

To control for possible autocorrelation effects between events, that is, events originating from the same firm biasing the outcomes of the study, in two additional regression, I reduced the sample to include only one event by one firm (N = 30) by using either only the first or only the last event by the respective firms. In both analyses, both the effect of time and the business model remain significant (using first event only: p time = 0.02, ptime-squared = 0.02, pbusiness model = 0.07; using last event only: ptime = 0.02 ptimesquared

= 0.02, pbusiness model < 0.01; all p-values from one-sided tests). Similar checks were

conducted for events having happened shortly after one another only to find identical results.

3.2.4 Discussion and Implications In this chapter, I have shown two drivers influencing the reaction of the capital market on firms announcing the release of source code to (potential) products as OSS, namely the time of the announcement and the underlying business model. Concerning time, I find that there is a u-shaped trend that is most likely explained by investor sentiment. Over the entire sample, a Corrado test showed that no significant abnormal returns occurred. However, this is due to the u-shape of CARs, averaging out times of positive and negative returns. Initially, that is, during the dot.com hype, a positive valuation of firms announcing the release of proprietary software as OSS by the capital market can be observed that, however, turns negative with the burst of the bubble. In fact, if I use the regression coefficients from Table 14 and insert mean values for all other variables but time (see Figure 4), the date value of the first root of the resulting quadratic equation turns out to be January 10, 2001, which is right after the dot.com crash. The second root is August 13, 2005, coming shortly before the NASDAQ price increased to and then stabilized around 2,300 points—the highest value since 2001—and during a series of source code releases in 2005. Furthermore, when the events are assigned to two groups based on whether they lie within or outside the resulting time interval, hypothesizing that firms within the period of supposedly negative investor sentiment from January 10, 2001, to August 13, 2005, were valuated significantly worse than those firms before and after this period of time, I find the expected effect (see Table 16). Moreover, comparing the CAR projections of Figure 4 to Figure 3 illustrating the number of events in the sample, there is a nearly identically shaped trend for both CAR and the number of announcements per

84

Top-Down Adoption of OSS

years, which indicates deliberate management action in response to investor sentiment.75 It is also interesting to see that Figure 4 shows a clear upwards trend even after a normalization of investor sentiment in 2005, with CAR reaching the level it had during the dot.com hype. This coincides with the rise of Web 2.0, a phenomenon that started in late 2004 and took off the year thereafter, and stock reactions to which bear similarities to those of the first Internet boom (Economist, 2005).

Figure 4: Projected CARs using only time and time-squared76

Date of

Obs.

Mean

1/10/01 – 08/13/05

16

0.76%

Other

22

1.58%

Announcement

T-test

Std.

Std. Dev.

Min

Max

0.011

0.044

-8.48%

11.50%

0.009

0.043

-3.92%

12.39%

Err.

0.054†

(p-value, one-sided)

Table 16: Effect of timing of the announcement on CAR

With respect to its external validity, the u-shaped relationship observed in this study may well hold for more segments of the IT sector and related industries. Henkel and Käs (2007) have for example observed that the number of firms releasing source code in several areas of embedded computing such as single-board computers has been steadily 75

76

Looking more closely at the similarities between the two figures, one sees for example that the level of both the number of releases and their valuation in 2001 was only again reached in 2005. With the sample of events ending in 2007 (and, furthermore, with only one event occurring in this year), the value for 2008 (and, to some degree, for 2007 as well) depicted in Figure 4 is of course a projected value based on the regression laid out earlier. The same applies to the 1998 value depicted in Figure 4 (no event in 1998).

Top-Down Adoption of OSS

85

increasing over the last years. I would assume market reaction to the respective announcements to follow a similar u-shape. What is more, I think that this has generally illustrated the effect that investor sentiment towards a certain action has on its valuation on the market and how investor sentiment and management reaction to it—as measured by the number of announcements per year—can change over time. First, during the time of the dot.com bubble, OSS—as probably any other Internet-related IT investment—was heartily embraced by the capital market and firms announcing they would release proprietary software as OSS saw their stock price increase abnormally. Managers observing and understanding this would consequently think about if and how their firms could also release product source code as OSS. With the bubble burst and investor sentiment turning negative, both the valuation and the number of firms announcing an OSS-based strategy decreased. When the stock market, in particular the NASDAQ, stabilized and began to again steadily increase in value, firms making OSS-related announcements could again achieve positive abnormal returns and, again, the number of firms doing so consequently increased. Generally, I would thus expect studies analyzing the effect of strategic decisions on stock price performance in the IT sector (and maybe also related industries such as telecommunications) to find an underlying u-shaped trend both with respect to market valuation—caused by investor sentiment—and with respect to the number of announcements per year—caused by managers’ deliberate reaction to the perceived investor sentiment.77 Maybe such a u-shaped trend can also be found in the datasets that have been analyzed in previous event studies on the effect of IT investments on the market value of the firm—indications for it can for example be found in the paper of Aggarwal et al. (2006), whose sample, however, only encompasses the years 1999 to 2003. The second factor influencing market valuation of firms deciding to release source code under an OSS license analyzed in this section has been the business model the firm chooses in doing so. Looking at this, I find that firms focusing on the business transformation model see a significantly worse investor reaction than those firms following one of the other three business models. I maintain that the reason behind this negative market reaction is that the business models cost or risk reduction, dual licensing, and sale of complementary goods or services are usually introduced together with a clear revenue model, which enables the company to appropriate value from its OSS engagement, and 77

An important aspect of this idea is the definition of “strategic IT investment” and the relation of this to the source or cause of investor sentiment. A stronger reaction of the capital market due to investor sentiment during the rise and fall of the NASDAQ should for example have occurred for new IT-based products rather than for investments in IT infrastructure.

86

Top-Down Adoption of OSS

that the capital market values this more highly than the usually uncertain long-term benefits of the business transformation model. The correlation table also hints in the direction that R&D-intensive firms tend to rather use the business transformation model, whereas firms with lower R&D-to-sales ratio rather choose the sale of complementary goods or services. This could again be an indication for the more long-term nature of the business transformation model as opposed to the other three. Should the business transformation model, however, turn out to have positive effects over the long run as argued before, this could be an indication of myopic investor behavior. An example for this could be IBM’s release of Eclipse that was evaluated negatively by the capital market at the time of the announcement (CAREvent 17 = -1.36%) yet is widely considered a success for IBM nowadays. With respect to another control variable in the regression, namely productivity as measured by sales per employee, this variable is found to be significant (p < 0.01) and to carry a positive sign. Seemingly, the capital market thinks that these firms are more likely to succeed at their OSS efforts because they are generally more productive and sales-oriented, indicating that they have already had considerable business success in the past. Again considering the idea that the business model business transformation has long-term positive effects, I controlled for an improvement of the market valuation of firms choosing this business model over time, with the underlying assumption that the market will come to understand the rationale behind and the positive effects of the initial decision, and consequently react more positively to similar future decisions. For this, an interaction term between the business model business transformation and time was included in the regression (see Table 17). Indeed, while all other factors keep or improve their level of significance, the interaction term is positive and significant (ponesided

= 0.05), indicating that the market, over time, has come to better appreciate this

business model, too. Another possible explanation might be that the business transformation model has evolved since the inception of OSS: firms have come to understand that the business transformation model as originally chosen was not sustainable—or at least not accordingly valuated by the capital market—and both the model in itself as well as the processes needed to realize it were consequently improved and refined over time.78

78

For example, there is a possibility that, of the four models comprising the business transformation category, some might create more value than others or might be easier to put into action, and that these models became more relevant to the business transformation category as a whole only over time. Due to restrictions in sample size, I could not control for such an effect.

Top-Down Adoption of OSS Independent Variable Business model: bus. transf.

87 Coefficient value

Rob. std. err.

-0.069*

0.030

0.007†

0.004

Time

-0.027*

0.011

Time2

0.002*

0.001

ln(Total assets)

-0.046†

0.025

ln(Total assets)2

0.001

0.001

-0.024

0.025

Time x business transformation

R&D-to-sales Sales ($mn) per employee

0.002**

0.000

Constant

0.419*

0.186

Observations R2

38 0.469

F-statistic Degrees of freedom

129.900** 30

Table 17: Results of OLS regression on CAR including the interaction term time x “business transformation” † * **

p < .10 p < .05 p < .01 (p-values are two-sided)

The findings show that value may well be created by firms deciding to open their knowledge in the form of OSS—under the condition that they have a business model for this that includes a clearly communicated revenue model. Firms announcing such initiatives are awarded an average premium on the stock price of 1.6% by the capital market, whereas firms that fail to include a revenue model into their announcement see a 1.6% decrease in their stock price. Looking at the two days of the event window separately, for firms using the business transformation model, those receive negative returns on each day ( AR t  1 = -0.9%, AR t 0 = -0.7%), whereas firms choosing any of the other business models achieve significantly positive returns on the event day ( AR t  1 = 0.1%, AR t 0 = 1.7%). Whereas these univariate observations might be biased because of potential investor sentiment during the rise and fall of the dot.com bubble, multivariate analysis confirms the validity of the findings, showing that firms choosing one of the business models cost or risk reduction, dual licensing, or sale of complementary goods or services achieved premiums on their stock price, in particular when compared to firms choosing the business transformation model to engage in OSS.

88

Top-Down Adoption of OSS Yet, the valuation of the latter revenue model has improved over time, either be-

cause the capital market has come to understand the potential long-term valuation of this business model, or because firms have refined the business transformation model and the processes needed to put it into action. As is also illustrated in Figure 5 (based on the regression coefficients from Table 17), whereas firms choosing the business transformation model have only been able to achieve positive abnormal returns when announcing a release of proprietary software as OSS since early 2006, firms choosing any of the other three business models cost or risk reduction, dual licensing, or sale of complementary goods or assets have almost constantly been able to achieve positive CAR, and only slightly negative CAR from mid 2002 to late 2004.

Figure 5: Market valuation of the business models over time

I think that these findings also contribute to the research on business models in general as they highlight that the capital market is able to distinguish between differences in the choice of business model and the consequences on value appropriation by the firm. Business models that include a clearly articulated and comprehensible—to the capital market, that is—revenue model indicating short-term appropriability of generated value are viewed more positively by investors than business models emphasizing more uncertain long-term effects—at least until the uncertainty has been reduced, that is. This line of research might be extended by further analyzing the differences between the other three revenue models—dual licensing, cost or risk reduction, and the sale of comple-

Top-Down Adoption of OSS

89

mentary goods and services, or other business models—where I would for example expect mere “outsourcing” deals falling in the cost or risk reduction category to be valuated less positively by the capital market than more innovative IT investments especially inherent in the sale of complementary goods and services category (Dehning et al., 2003; Dos Santos et al., 1993). Like any other event study this one faces some limitations. One limitation may be the rather small sample size. Limiting the event window to one day so that the confounding check eliminates fewer events might seem as a solution to this problem, however, as rather strong anticipation effects on the day preceding the event may be expected (e.g., Dehning & Richardson, 2002), this does not seem to be a wise choice.79 Rather, one might think about expanding the search terms and applying those to more and different data sources as the ones used in the study, or recomposing the study in a couple of years: since the number of qualified events has been steadily increasing over the past view years, redoing the study in a few years should produce a much larger sample size. In such a study, learning effects of firms over time might be analyzed, too, that is, such studies could look at whether the success or failure in previous efforts to release source code under an OSS license has an impact on the market valuation of similar future announcement. Moreover, event studies only take into account events for public companies. Thus, privately held companies are not in the sample. As indicated before, in this event study in particular, many events from private companies were excluded. Future research efforts—applying methods different to the one used here—might look at venture capital or corporate venture capital investments in such firms, OSS-based firm acquisitions by publicly-traded companies, or, potentially, at the IPO performance of OSS-based firms, since many of these events will probably rise in number in the future. For example, while not the main focus of his paper, Dahlander (2007) has collected data showing that the u-shaped relationship found in this thesis also holds with respect to the number and dollar amount of venture capital investments in OSS. This study has furthermore shown the effect of investor sentiment on the market valuation of Internet-related IT investments using the example of product source code releases as open source. I have shown that, over time, investors value similar investments differently just because of the timing of the announcement. Similarly, managers

79

Another way to describe the anticipation effect would be information leakage: some analysts or journalists may learn about the content of the announcement (or have actively been informed by the announcing firm) shortly before the actual event. For more information on this, please see the literature referenced in Section 3.2.2.

90

Top-Down Adoption of OSS

were able to react to this and increased or reduced the number of corresponding actions depending on investor sentiment. The timing of the announcement, consequently, is an important variable influencing market valuation, and must not be ignored in IT-related event studies in which the sample, or parts of it, may come from periods of time during which strong investor sentiment is to be expected. My analysis has emphasized the need for a view on the capital market in OSS and open standards research. Both have long become relevant to the business world—this chapter has shown that there is well reason to believe that this relevance will further increase in the future, as will the positive valuation of OSS by the capital market. Managers of proprietary software firms thinking about releasing some of their software as OSS thus need not fear a negative reaction of the capital market—that is, if they have carefully selected a business model that allows them to create value and that is also perceived as potentially doing so by the capital market. Although it is obvious that OSS is not the right choice for every firm in the IT industry, the results of this section clearly indicate that its overall importance will most likely increase further over the coming years. For many firms, thus, the interesting question will no longer be whether to actively engage in developing OSS, but rather how to do so. Consequently, the processes firms need to follow and implement when transforming from closed to open source will be the main topic of the third part of this thesis (see Chapters 5 and 6).

3.3 Conclusions In Sections 3.1 and 3.2, we have seen that all forms of corporate OSS engagement, that is, using OSS, contributing to existing OSS projects, and releasing proprietary software as OSS, may create value for the firm. For using OSS, potential advantages may include lower cost, higher innovative performance in particular with respect to time-to-market, and a potential for higher quality. Contributing to existing public OSS projects and releasing proprietary software are consistently valued positively by the capital market if those actions are accompanied by a business model that allows corporations to generate short-term benefits from their OSS efforts. Firms using their OSS engagement to transform the business they are competing in are negatively evaluated when compared to firms following one of the three more short-term oriented business models. Yet, there might be situations in which the business transformation model for OSS might be better, in the long run, than not doing OSS at all, and that the potential benefits from doing so are not necessarily foreseen by the

Top-Down Adoption of OSS

91

capital market initially. As an indication for this, Section 3.2 has shown that, over time, the capital market has come to appreciate this business model, too, and nowadays regards all four business models to release proprietary software as OSS favorably. Summarizing, I find that management often has well reason to believe in the valuecreating potential of OSS for the firm. In situations such as described above, in which the advantages of corporate OSS engagements clearly outweigh the benefits, a top-down introduction of corporate OSS efforts is thus to be expected—provided that management sees OSS as part of its solution space. If the latter is the case, OSS can follow the ideal two-step approach of organizational adoption (see Section 2.5); if not, two possibilities for organizational adoption not started by top-management remain: (1) employees may lobby for OSS until it becomes part of top managements’ solution space, or (2) employees on their own decide to adopt OSS until management, eventually, may acknowledge the fact that the corporation as a whole is engaging in OSS. In the latter case, OSS would have been introduced to the corporation in a bottom-up fashion. In Chapter 4, I will now turn to such a scenario in which no clear decision for or against OSS has been made by top management to analyze the lobbying and adoption behavior of employees.

92

Bottom-up Adoption of OSS

4 Bottom-up Adoption of OSS80 Having shown that management has reason to be favorable towards OSS, in this chapter, I now turn to the individual employee in the firm, knowing that successful corporate adoption needs a favorable vote by both management and employees. When looking at the level of the individual within the firm, the diffusion process of OSS remains largely a black box. Anecdotal evidence (Henkel, 2004b; Moody, 2001; Raymond, 2001a, 2001b) of the importance of grassroots initiatives by developers is supported by survey results that find that software professionals tend to champion OSS (Henkel, 2008), but systematic evidence is lacking. Because active engagement in OSS—as shown earlier—might be vital to firms in terms of efficiency gains, standard setting, defining the rules of competition, and responding to competitive threats generated by OSS and because such engagement will not be feasible if employees do not agree with it, IT professionals’ disposition towards OSS and willingness to promote its adoption are highly relevant. In the interest of understanding this phenomenon, in this chapter the question of who advocates OSS in commercial settings will be dissected distinguishing the three levels of engagement introduced earlier, that is, asking who advocates using existing OSS, who advocates contributing to existing OSS projects, and who advocates releasing proprietary software as OSS? Note that the levels of contributing and releasing amount to a process innovation in software development, which would imply that employees influence organizational structure and processes. In particular, it will be asked whether particular job functions and personal characteristics favorably incline an employee towards OSS. Answers to these questions were pursued over a period of a year and a half in the telecommunications department of a multinational corporation that is not among the early and outspoken corporate proponents of OSS (e.g., IBM). The company so far has no company-wide OSS policy and is in a relatively early phase of commercial adoption and diffusion of OSS. Thus, not being prejudiced by existing corporate strategy governing OSS, the company was well-suited to the study, which explored the role of em80

For the most part (apart from sections 4.5.3, 4.5.4, 4.7, 4.8, 4.9), this chapter builds on a joint working paper with Joachim Henkel to which minor adaptations have been made. I would also like to thank Martin Bichler, Linus Dahlander, Lars Frederiksen, Simone Käs, and Francesco Rullani as well as conference and seminar participants at Boston University, ETH Zürich, AoM, EURAM, Harvard Business School, and Technische Universität München for helpful comments.

Bottom-up Adoption of OSS

93

ployees in OSS adoption through interviews with 25 individuals and a survey involving 249 participants. Because I attempt to analyze through these questions the alleged grassroots aspect of corporate OSS adoption, OSS initiatives by top management were excluded in order to focus explicitly on the level of IT professionals. Guided by a framework based on the Technology Acceptance Model (TAM) (Davis, 1989; Davis, Bagozzi, & Warshaw, 1989) and concept of innovation diffusion (Rogers, 2003), a model is developed that links individuals’ attitudes towards commercial OSS adoption to their job functions. It will be shown that job function determines an individual’s tasks (and thus daily routines), and that different tasks are differentially affected by the introduction of OSS. Software professionals whose daily routines are more strongly or more negatively affected by its introduction are expected to be less favorably disposed to the adoption of OSS. These findings further suggest that the TAM and similar models be extended in the manner suggested by Venkatesh (2006) to take into account the adopter’s job function, or, more generally, the way in which the adopter interacts with the innovation at hand.

4.1 OSS vs. PCSS Development

Figure 6: Proprietary closed source software (PCSS) development

In programming PCSS, firms build almost exclusively on their employees’ knowledge. Developers write source code according to use-cases specified by software architects with only little interaction with the outside (see Figure 6). Before a product is released, product testing ascertains that it adheres to both initial requirements and compa-

94

Bottom-up Adoption of OSS

ny quality standards (Jones, 2003; Lehman, 1980; Royce, 1987; Senyard & Michlmayr, 2004). Outside influence is limited to the requirements articulated by the customers (which might be internal to the firm) at the beginning of the development process, licensed-in commercial third-party software, and beta testing towards the end of the development process. This description is clearly of the waterfall model of software development, which, although more advanced models are in use by many firms, continues to be widely employed by firms developing software (Cusumano et al., 2003; Jones, 2003) . In particular, it was the model of choice in the firm studied in this chapter.

Figure 7: Open source software (OSS) development

Boundaries between a firm and its environment become more permeable with OSS development (see Figure 7). Consider first the case of a firm that releases internally developed software as OSS in order to launch a public OSS project. The first release, usually done in the same way as in a PCSS environment, is typically a prototype that is good enough to solve the initial problem (Senyard & Michlmayr, 2004). But thereafter development changes significantly. Whereas PCSS would enter the maintenance phase, which frequently consumes more than half of all development resources (Banker et al., 1991), outsiders are now encouraged to report bugs, suggest new features, and contribute source code to further improve the software (see Figure 6). Additional source code that meets a project’s quality standards is made available to the community and included into subsequent releases. Substituting OSS for PCSS development has been

Bottom-up Adoption of OSS

95

shown to, at least potentially, reduce maintenance costs considerably (Lakhani & von Hippel, 2003; Senyard & Michlmayr, 2004; Wheeler, 2007), and significant changes in the development process are observed, particularly in the daily routines of developers, project managers, and managers (see Figure 7).

Figure 8: OSS development cycle (Senyard & Michlmayr, 2004)

The above describes a particular case of corporate OSS engagement. More generally, software development can embrace OSS and OSS practices to varying degrees. As done before in this thesis, three levels of corporate OSS activity are distinguished: using existing OSS, contributing to existing OSS projects, and releasing proprietary software under an OSS license.81

4.2 Research Design Because anecdotal evidence that associates OSS with grassroots adoption suggests an inherent potential for bottom-up organizational innovation (Henkel, 2004b; Moody, 2001, p. 315; Raymond, 2001b, p. 23), it is important to understand what motivates individual employees to support such adoption. As we have seen, employees can drive corporate OSS engagement in two ways, (1) by opting, themselves, for OSS in deci81

Grand et al. (2004) use a related classification distinguishing four levels: using existing OSS; adapting and extending OSS; acting as core OSS developers; and providing development and distribution services related to OSS projects (thus running an OSS compatible business model). The first levels in their paper and the classification in this chapter are identical. The second and third levels in their classification largely correspond to “contributing to existing OSS” in the classification in this chapter. The top levels differ because Grand et al. (2004) focus on “pure play” OSS firms, whereas this chapter focuses on established corporations.

96

Bottom-up Adoption of OSS

sions that are in their own discretion and (2) by lobbying for broader, organization-wide OSS engagement. However, individuals with different job functions will, in general, have different attitudes towards the adoption of new information technology (Agarwal & Prasad, 1999; Baldridge & Burnham, 1975), and in particular towards engagement in OSS. Specifically, employees’ attitudes will reflect their perception of how adoption will affect the daily routines associated with their role in the software development process. Two questions thus become vitally important, (1) who can be expected to lobby for greater corporate engagement in OSS, which is to say, where is adoption initiated and diffusion supported, and (2) who is likely to oppose engagement in OSS development and pose a bottleneck to its introduction? Given that OSS practices affect all steps in the software development process, the weakest link in this chain, that is, the least supportive job function, limits the overall effectiveness of OSS development.

Figure 9: Research model

To ensure that, in fact, the effect of individuals’ roles is measured, other elements that might influence their adoption decision are being controlled for. This study was conducted within one firm in order to create a constant environment by eliminating such external factors that strongly influence adoption as firm size, diversity, slack resources, IT application portfolio, specialization, and professionalism (Damanpour, 1991; Swan-

Bottom-up Adoption of OSS

97

son, 1994). Individuals’ attitude towards corporate OSS engagement are modeled as an antecedent to both their individual adoption decisions and their lobbying for OSS, using the two most widely accepted concepts in the IS literature (Gallivan, 2001), namely, TAM and DOI. The framework follows the approach suggested by Kwon and Zmud (1987) in using variables from TAM and DOI to represent characteristics of the individual, task, and organization;82 the resulting framework is as depicted in Figure 9. The primary interest of this chapter is in measuring the effect of individuals’ job functions on their attitudes towards their employers’ further engagement in OSS development. This largely corresponds to employing as the dependent variable the TAM’s “attitude towards using” (Davis, 1989; Davis et al., 1989). “Using” here refers to all three levels of OSS engagement (not just to “using existing OSS”), and is not restricted to (but comprises) using by the individual. “Attitude towards using” and not “intention to use” is deliberately employed as the dependent variable, since (1) the latter can not be extended to use by others and (2) is not really applicable to the third level of corporate OSS engagement, “releasing proprietary software as OSS.” Also, this chapter aims at analyzing drivers of both individual OSS adoption and lobbying for OSS, and “attitude towards using” seems more appropriate as a determinant of lobbying than “intention to use.”83 The two main factors that drive an individual’s attitude towards a new a technology, according to the TAM, are perceived usefulness and perceived ease of use. Attitude towards using a new technology affects the behavioral intent to use it, which, in turn, determines whether one becomes a user. Perceived usefulness is highly influential on both attitude towards using and behavioral intent to use. Perceived ease of use has an indirect effect on both through perceived usefulness: an individual perceives a new technology as more useful if it previously has been identified as easy to use (Davis, 1989; Davis et al., 1989). In the following section, the TAM is employed to derive perceived usefulness and perceived ease of use from job function (and some control variables). In the theoretical framework as well as the subsequent econometric analysis, perceived usefulness and 82

83

In an article summarizing past literature on this issue, Kwon and Zmud (1987) provide a list of factors potentially influencing corporate IS implementation that closely follows Rogers’ DOI. They extend the latter by integrating task and environmental characteristics. As described above, (external) environmental characteristics have deliberately been excluded from this chapter by focusing on one firm. Furthermore, this chapter differs from Kwon and Zmud’s work by capturing task-related characteristics by individuals’ job functions, by applying the framework to data, and most importantly by addressing the specific issue of OSS adoption. As an indicator for this, a respondent’s attitude towards releasing proprietary software as OSS is highly correlated (p < 0.01, rsp = 0.22) with the number of current software products of the corporation that this respondent suggested, in an open question, as potential candidates for a release as OSS. The act of suggesting constitutes lobbying for OSS, even if with a limited effort. Similarly, the attitude towards using OSS is highly correlated (p < 0.01, rsp = 0.23) with the extent to which the individual was currently trying to use OSS in corporate software projects.

98

Bottom-up Adoption of OSS

perceived ease of use are captured by the job function variables, such that the TAM items themselves do not appear as explanatory variables. Deviating in this way from the standard TAM approach allows directly juxtaposing the analysis of attitudes by job groups with a multivariate analysis controlling for other characteristics of the respondent. Following Rogers, the diffusion of an innovation is assumed to depend on the innovation itself, communication and communication channels, time, and social systems (Rogers, 2003). Rogers’ measures for the first of these dimensions, “innovation,” include relative advantage, compatibility, complexity, trialability, and observability. The greatest importance attaching to the first two measures (Rogers, 2003; Tornatzky & Klein, 1982), the other three are dropped, and because relative advantage refers to the adopter’s perception and is thus highly dependent on job function, relative advantage was not measured as an independent variable. Instead, it is argued that the latter is captured by an individual’s job function. Following the research framework laid out in this section, we will first take a look at the main independent variable, namely the individual’s job function, to understand why different job functions may lead to different evaluations of corporate OSS engagements. Control variables, that is, characteristics of the innovation, the individual, or the organization which might further influence an individual’s proneness towards corporate OSS engagement, will be discussed jointly with their operationalization in Section 4.4.5.

4.3 Effects of Cooperate OSS Adoption on Employees Generally speaking, Kotter and Schlesinger (1979) have identified four reasons why people might resist organizational change such as effected by the introduction of innovations to the company. These are (1) parochial self-interest, that is, that employees might rather be concerned with what change means for them, personally, than considering the implications of success for the company, (2) misunderstandings because of communication problems or inadequate information, (3) low tolerance to change, that is, people highly value stability, continuity, and security in their environment, and (4) a different assessment of the situation, that is, employees may have or see different reasons for the change and disagree on advantages and disadvantages of the change process. These arguments will be strongly influenced by the job function an individual fulfills in the organization.

Bottom-up Adoption of OSS

99

For purposes of this chapter, five job functions are distinguished in the software development process. Ordered (roughly) by their sequence in the waterfall model (also see Figures 6 and 7), these are software architects, developers, software testers, project managers, and (general) managers. Within the organization studied, these job titles are officially and consistently used to denote specific job roles, or functions. In the following, each of these roles is described, in particular with respect to how it would likely be affected by increased corporate engagement in OSS development.

4.3.1 Software Architects, Developers, and Testers Software architects translate user needs into a set of (high-level) software requirements and subdivide these into subsystems that are coded by developers (Bass, Clements, & Kazman, 2003; Royce, 1987). As their title implies, they determine product architecture, that is, the linkages among different (possibly modular) components of a software system (Baldwin & Clark, 2000; Henderson & Clark, 1990). Even in PCSS development, software architects interact with outsiders, receiving customer input and selecting and integrating third-party modules into the design of software systems. Perceived ease of use with regard to outside engagement in the OSS process should thus be high for this job function, which might be expected to view existing OSS as just another external source of building blocks. Perceived usefulness should also be high given that (1) the availability of OSS expands design choices, and (2) the suitability of OSS for a particular purpose can more easily be assessed owing to availability of the source code (Ajila & Wu, 2007; Madanmohan & De', 2004). Access to the source code also facilitates and reduces the cost of adaptations, and contributing code to influence the architecture of an OSS project (Goldman & Gabriel, 2005; Lakhani & von Hippel, 2003) could make the contributor party to the eventual establishment of an industry standard (Bonaccorsi et al., 2006; Henkel, 2004b). Software architects’ attitudes towards corporate OSS engagement can thus be expected to be rather positive. For the developers, whose job it is to code the subsystems that comprise a system design, the changes entailed by engagement in OSS are perhaps best described by the terms not-invented-here, OSS development style, and coding for reuse. First, the Not-Invented-Here (NIH) syndrome (DiBona, 2005, p. 23; Katz & Allen, 1982) may loom large when, instead of writing one’s own code, existing OSS is to be reused or external contributions are to be accepted to a corporate OSS project. Furthermore, the potential for internal development to be scaled down by using existing OSS

100

Bottom-up Adoption of OSS

might be perceived to put developers’ jobs in jeopardy. At least in the short run, however, the potential for using existing OSS to simplify and speed up their work should be viewed positively by developers. Second, the OSS development style, design principle, and meritocratic culture will, of course, be unfamiliar to developers inexperienced with OSS (Scacchi, 2004). The need to interact intensely with the outside world and to aggregate as well as write source code and, possibly, maintain it in a public project will be new territory even for developers who have used external components in PCSS development, as communication with the originators of the source code would likely not have been required. Because they occur concurrently, these activities demand a great deal of coordination. New responsibilities also accrue to developers, who become to varying degrees moderators and managers of users and contributors (Kogut & Metiu, 2001; Senyard & Michlmayr, 2004). Adapting to these changes takes considerable effort. Developers who cannot make the transition to this model (due either to a general lack of skills or to an inability to see how it relates to their existing knowledge) or who feel pressured to do so by outside forces will be inclined to evaluate negatively, and exhibit a negative attitude towards their employer’s engagement in, OSS use and development (Ryan & Deci, 2000). On the other hand, being able to communicate with outside experts might help to resolve problems their companies might be having difficulty solving on their own (Constant, Sproull, & Kiesler, 1996) or identify problems that might otherwise have been overlooked. Finally, coding for reuse and the importance of modularity are far greater in OSS than in PCSS development (Goldman & Gabriel, 2005, pp. 63, 257; Raymond, 2001b; Senyard & Michlmayr, 2004),84 and although engaging in OSS might generate positive signaling effects and enhance peer recognition (Lerner & Tirole, 2002; McLure Wasko & Faraj, 2005), it also exposes internally generated code to greater scrutiny by external as well as internal experts. Interviews revealed that especially less skilled developers fear losing face when mistakes are now more easily found and attributed. Thus, relative to software architects, developers are expected to exhibit a less positive attitude towards OSS overall and, in particular, a strongly negative attitude towards contributing to existing OSS projects and releasing proprietary software as OSS.

84

More modern software development methods such as the spiral model, extreme programming, and agile methodologies by their nature rely more heavily on modularization and coding for reuse than the classical waterfall model and V-model and, thus, are more “compatible” with OSS development (see, e.g., Goldman & Gabriel, 2005; Hang, Hohensohn, Mayr, & Wieland, 2004).

Bottom-up Adoption of OSS

101

Testing being a highly routinized task executed by technical specialists supported by dedicated software applications, its nature is not substantively different for OSS and PCSS development. In their role as end control, software testers test the source code against specifications trying to find defects, which they report then back to the developers (Royce, 1987). Even with PCSS development, external actors are engaged in socalled beta testing, whereby selected users are provided with a copy of a release candidate of a software program for testing purposes. That OSS development introduces for testers (as for software architects) no fundamentally new activities should translate into high perceived ease of use, and that it avails testers access to a community of developers and users and concomitant significant increase in frequency of testing and numbers of test designs should translate into high perceived usefulness. Moreover, incorporating OSS components that likely have been heavily scrutinized by the OSS community might be expected to reduce the number of bugs (Raymond, 2001b), and no appreciable degree of employee redundancy is indicated as final quality inspections will still need to be performed before a product is released. Testers are thus expected to generally exhibit positive attitudes towards their employers’ engagement in OSS.

4.3.2 Managers and Project Managers Project managers plan, execute, and monitor software projects, coordinate tasks and personnel, allocate resources, and set milestones (Kirsch, 2000). Both in PCSS and OSS development, they perform boundary-spanning tasks involving bringing together organization members with different backgrounds performing different tasks (Tushman, 1977; Tushman & Scanlan, 1981). That OSS development entails working with an additional, external boundary increases uncertainty in the coding realm (Goldman & Gabriel, 2005). How is a project manager who doesn’t even know who is working on it to set milestones for and allocate resources to a project? The “kindness of strangers” (Constant et al., 1996) might be helpful, but cannot be taken for granted. The resulting uncertainty introduces risk and a concomitant need for greater coordination, which increase the project manager’s workload (Kirsch, 2000). Interviews results further revealed that contributing source code to existing OSS and releasing proprietary software as OSS upon completion of a project adds work that yields no immediate and clearly visible benefits for the project manager or the project. Potential benefits will be extremely difficult to quantify and project managers will scarcely be evaluated on them. The transformation process for projects not planned as

102

Bottom-up Adoption of OSS

OSS from the outset, moreover, can be costly (Hecker, 1999; Henkel, 2004b). Perceived usefulness and perceived ease of use might thus be expected to be rather low, and attitude towards corporate engagement in OSS rather negative, for project managers. (General) managers define and enact corporate strategy. They decide which projects to pursue and allocate the requisite resources (Burgelman, 1983). Their attitude towards OSS development might thus be expected to be much the same (albeit less intense, not being directly responsible for meeting deadlines) as that of project managers. But the need of managers, “diversified” by oversight of a plurality of projects, to think beyond individual projects mitigates the effects of risk-aversion. Long-term benefits such as reuse of OSS adapted to local needs should thus offset negative short-term effects, and the benefits of releasing proprietary software as OSS, being generally strategic in nature, might be expected to be recognized by managers (Dahlander, 2005; Grand et al., 2004; Hecker, 1999; Raymond, 2001a, 2001b; West, 2003). They must nevertheless weigh such benefits against possible disadvantages such as loss of competitive advantage consequent to relinquishing intellectual property or the risk of forking. Managers’ attitudes towards corporate engagement in OSS might be expected to be more positive than project managers’ and less positive than software architects’ and testers’.

4.3.3 Hypotheses The effect of job function on attitude has been shown to depend to some extent on type of OSS engagement (i.e., using, contributing, or releasing), but no indication that ranking of job functions with respect to affinity for OSS should be contingent on the type of engagement. We thus arrive, for each type of engagement, at the following predictions regarding the impact of job function on attitude towards OSS: software architects and testers should be most favorably disposed to OSS, followed by managers and developers.85 Based on the theoretical discussion I am unable to predict whether and how the attitudes of software architects and testers, and managers and developers, might differ. Project managers, finally, should be least favorably disposed to OSS. These findings give rise to the following hypotheses (letters in square brackets indicate to which groups each hypothesis refers).

85

One could characterize a person’s job function on a more detailed level than what is defined by the job title, and thus arrive at more detailed predictions regarding OSS attitudes. For example, one could take the variables “hours per week spent programming”, “hours per week spent programming OSS” and the respondent’s field of education (major in computer science, electrical engineering, or other fields) into account. However, including them into the regression analysis (see Section 4.5.2) does not yield any significant effects. Consequently, for the purpose of this thesis, the job title provides a sufficiently detailed characterization of a person’s job function.

Bottom-up Adoption of OSS

103

H1[TM]: Testers’ attitudes towards OSS are more positive than managers’. H2[TD]: Testers’ attitudes towards OSS are more positive than developers’. H3[TP]: Testers’ attitudes towards OSS are more positive than project managers’. H4[AM]: Architects’ attitudes towards OSS are more positive than managers’. H5[AD]: Architects’ attitudes towards OSS are more positive than developers’. H6[AP]: Architects’ attitudes towards OSS are more positive than project managers’. H7[MP]: Managers’ attitudes towards OSS are more positive than project managers’. H8[DP]: Developers’ attitudes towards OSS are more positive than project managers’.

4.4 Data and Methods The study was conducted in the telecommunications department of a multinational electronics company in which software development plays a key role. Hence, most (if not all) employees were involved in some way with software development in the course of their everyday work. At the time of the study, the department had no officially communicated strategy regarding OSS. Rules and initiatives promoting the optimal use of OSS, despite widespread OSS adoption within the corporation, were known only to a minority of employees. Nor was there any general policy governing contributing to existing OSS projects or releasing proprietary software as OSS, although instances of both had occurred.

4.4.1 Data Collection Current involvement in and practices related to OSS were assessed in 25 interviews of 45 minutes average duration. These interviews, conducted with employees in different countries and at different hierarchical levels as well as with experts outside the company, were recorded, transcribed, and categorized using the text analysis software NVivo 7 (Mayring, 2004). A large-scale online survey was disseminated to the department’s IT employees in early 2006. Participants were asked to share their general opinion of, and current experience with and exposure to, OSS as well as their perceptions of their peers with respect to OSS. Additionally, a measure of personal innovativeness was included. Survey results were first subjected to factor analysis, before univariate and multivariate analyses were conducted. All computations were performed using the statistics and econometrics software package Stata 9.2.

104

Bottom-up Adoption of OSS

4.4.2 Sample The survey, in both English and German, was distributed at several of the corporation’s international sites. The validity of the survey and consistency of the translation were confirmed in pre-tests. Addressees were invited to participate during a three-week time span. Participants received from their respective superiors invitational e-mails containing text composed by the survey’s authors and a general user-password combination valid for all employees that protected the survey from unauthorized participation. The wording of the invitation and the fact that the questionnaire was hosted by a university ensured that potential participants were sure about the voluntary and anonymous nature of the survey. A reminder was sent out halfway through the three-week period to encourage additional participation. Approximately 800 people in five countries were contacted and 249 valid replies received, yielding a response rate of 31%.86 Response rates among sites varied from 24% to 80%. By job function, usable replies were received from 37 software testers, 23 software architects, 27 managers, 153 developers, and 9 project managers (see Table 18). This breakdown was nearly identical to the distribution of job functions in the company as a whole.

Job Function

Frequency

Percent

Architects

23

9.24

Developers

153

61.45

37

14.86

9

3.61

27

10.84

249

100.00

Testers Project Managers Managers Total

Table 18: Survey participants by job function

4.4.3 Dependent Variables Attitude towards engaging in OSS. The assessment of employee attitude distinguished among three levels of corporate OSS engagement: using existing OSS, contri86

Originally, 404 replies were received from approximately 1,100 people in seven countries (yielding a response rate of 37%). Legal restrictions, however, prevented the collection of demographic information in some countries thus reducing the number of usable observations. The data was analyzed for significant differences between the two groups (included vs. dropped observations), but none were found. Nor were any differences observed with respect to individuals from different countries in both groups. To avoid single source bias, survey results were also validated against the results of the interviews.

Bottom-up Adoption of OSS

105

buting to OSS projects, and releasing proprietary software as OSS.87 Respondents were asked to indicate their agreement, on a 5-point Likert scale ranging from 1 “strongly disagree” to 5 “strongly agree”, to the following statements. I think that [company department] could benefit from... using existing OSS more often contributing modified OSS back to the public making some of its own proprietary software public under an OSS license Note that whether individuals are able to correctly assess how OSS will affect their employer is irrelevant in the current context. It is their perception that determines their attitude towards corporate engagement in OSS, and consequently whether they adopt and lobby for OSS.

4.4.4 Main Independent Variables Job functions are coded by dummy variables. Testers were used as the reference group (1) because they are the most positive about OSS according to both the theoretical considerations and descriptive statistics (see Table 25), and (2) because they are a sufficiently large group, accounting for 14.9% of respondents (see Table 18). The categorization of job functions was provided by the company. The tasks carried out by people with the same job title were close to identical, also across different sites and projects, matching the descriptions of job functions given in Section 4.3.

4.4.5 Control Variables Most control variables are indices made up of items derived from theory and will be described in the following. Correlations between explanatory variables and descriptive statistics are provided in Tables Table 19 and 20. Factor items are given in Tables 21. Compatibility in the context of innovation diffusion might, but does not necessarily, imply compatibility in a technical sense. More important is that compatibility encompasses the degree to which an innovation is coherent with existing norms and premises (Rogers, 2003), which, in turn, at least in part, determines its perceived ease of use (Davis, 1989; Venkatesh, 2000). In this context, goals of the OSS community (e.g., freedom 87

In the section on theory, it was argued that attitude towards personal OSS engagement should be closely related to attitude towards corporate OSS engagement. This is confirmed empirically: agreement with the statement, “I would like to use more OSS in my job” is highly correlated with agreement with the statement, “[Company] could benefit from using OSS more often” (Spearman rank correlation: 0.51), and agreement with the statement, “I would like to develop more OSS in my job” is highly correlated with agreement with the statements, “[Company] could benefit from contributing modified OSS back to the public” (0.44) and “[Company] could benefit from making some of its own proprietary software public under an OSS license” (0.52).

106

Bottom-up Adoption of OSS

and reciprocity) constitute such norms and premises. Identification with these goals probably drives some, but not most, individuals’ engagement in OSS development (Hars & Ou, 2002; Lakhani & Wolf, 2005). For these individuals, the community’s norms represent unifying aspects that constitute the underlying philosophy of the OSS movement (Hertel et al., 2003; Stewart & Gosain, 2006); identification with this philosophy might motivate “giving back” to the community by contributing to an OSS project or releasing proprietary software as OSS (Venkatesh, 2000). Identification with the OSS community was measured with a single-item construct,88 reciprocity by degree of agreement with three statements that reflect the community’s give-and-take philosophy (see Table 21). These items were taken from existing studies and slightly adjusted (Henkel, 2006; Lakhani & Wolf, 2005). The three items that measure reciprocity load higher than 0.8 on a single factor, explaining 71% of the total variance. Cronbach’s α of

1)

1

2)

0.60

1

3)

0.50

0.62

1

0.13

0.23

4)

-0.13

6)

-0.11 -0.15 -0.11 -0.11

8) 0.46

0.43

10)

0.38

0.41

0.37

11) 0.20

0.21

0.11

13)

0.15

0.13

0.12

0.13

16) Age

15) KAI Conformity

14) KAI Efficiency

1 -0.17

1 0.50

1

0.18

0.14

1 -0.11

0.23

0.17

0.10 -0.14

1

0.14

1

14)

-0.34

15) 16)

13) KAI Originality

12) Did OSS

1 -0.24

0.17

12)

11) Organizational Factors

10) Reciprocity

9) Id. with OSS community

1

-0.11 0.45

8) Job Project Manager

1

-0.53 -0.40 -0.44

9)

7) Job Developer

1

5)

7)

6) Job Manager

5) Job Architect

4) Job Tester

3) Benefit of Releasing

2) Benefit of Contributing

1) Benefit of Using

the index is 0.79.

-0.20 -0.19 -0.22 -0.16

0.16

0.21 -0.14

-0.17

0.17

-0.13 -0.11

1 0.37 1 -0.12

1

Table 19: Spearman rank correlation (displayed only for p 0.4 reported)

0.87

Motivation and Incentivizing of OSS Developers

177

Of the 14 items, all but one (“My contribution to this project would enhance my reputation in the OSS community”) loaded higher that .4 on the hypothesized factor and less than 0.4 on any other. However, removing this item from the factor it was hypothesized to be a part of (“extrinsic motivation”) reduced factor reliability, which is why it was included it in the final factor. All four factors have very good to acceptable levels of reliability (self-determination: α = 0.76; reciprocity: α = 0.78; use need: α = 0.84; extrinsic motivation: α = 0.65) (Hair et al., 2005). Descriptive statistics of the factors are given in Table 43, correlations of all variables in Table 44. Descriptive statistics of all variables by grouping variables and according to the 2x2 design are given in Tables 45 and 46.

Variable

N Med. Mean Std. Min. Max.

Share

Dev.

≥4

Self-Determination

229 3.8

3.77

0.61 1.8

5

44.98%

Reciprocity

229 3.5

3.26

1.08 1

5

34.93%

Extrinsic Motivation

228 4

4.03

0.54 2

5

62.28%

Use Need

229 3

3.19

0.84 1

5

27.51%

Total Motivation Self-rep. Interest

0.66**

Self-Determination

0.30** 0.41**

Reciprocity

0.31** 0.27** 0.20**

Extrinsic Motiv.

0.44** 0.40** 0.43** 0.33**

Use Need

0.17*

Treatment

0.13†

0.24*

0.29** 0.32** 0.14*

Strong Norm for Payment Table 44: Correlations (only reported if p < 0.1) † p < .10, * p < .05, ** p < .01

0.15*

Strong Norm for Payment

Treatment

Use Need

Extrinsic Motivation

Reciprocity

Self-Determination

Self-rep. Interest

Total Motivation

Table 43: Descriptive statistics for the control variables

178

Motivation and Incentivizing of OSS Developers

Table 45: Descriptive statistics split by grouping variables (std. dev. in parentheses)

Table 46: Descriptive statistics according to 2x2 design (std. dev. in parentheses)

Motivation and Incentivizing of OSS Developers

179

6.4 Results Using Stata 9.2, t-tests, ANOVA, MANOVA, and regressions were run to measure between-subject effects, and regressions to control for external effects.141

Table 47: Effect of treatment on self-reported interest

Figures in T, N, and T x N column represent F-values of (M)ANOVA. Table 48: Effect of treatment and strong norm for payment ((M)ANOVA F-values) † * **

141

p < .10 p < .05 p < .01

T-tests were used when comparing two groups (i.e., one grouping variable), (M)ANOVA when comparing four groups (i.e., two grouping variables in a 2x2 design). OLS regressions were run to see whether results also held in multivariate analyses.

180

Motivation and Incentivizing of OSS Developers With respect to H1, whereas no negative effect of administrating the external reward

on the overall sample is found (see Table 47), when using “strong norm for payment” as a moderating variable in ANOVA and MANOVA, the hypothesized interaction effect is observed (see Table 48, and also Tables 49 to 51). The effect is significant for both variables singularly (ANOVA) and collectively (MANOVA), and for the resulting factor measuring self-reported interest (ANOVA) on a 5% level of significance, the fun measure and the index even at the 1%-level. As illustrated in Figure 13, self-reported interest increases if a developer is promised payment in the form of a completion-contingent reward and has a strong norm for payment; the opposite is true for individuals that do not have a strong norm for payment.

Motivation and Incentivizing of OSS Developers

181

Figure 13: Interaction effect of monetary reward and strong norm for payment (using the normalized index for self-reported interest)

While these findings already lend strong support to H1, an OLS regression was further conducted to see whether these findings hold in a multivariate analysis. As can be derived from Table 52 by calculating the change in coefficient value depending on the existence of a strong norm for payment (Norm = 1: Δ = +0.002; Norm = 0: Δ = -0.230), this is indeed the case, and H1 is consequently fully supported.142

Independent Variable Strong Norm for Payment x Treatment

Coefficient value 0.409**

Rob. Std. Err. 0.181

Strong Norm for Payment (1: Yes; 0: No)

-0.177

0.137

Treatment (1: Treatment, 0: Control)

-0.230*

0.111

Self-determination

0.419**

0.075

Reciprocity

0.140**

0.041

Constant

2.120**

0.314

Observations R

228

2

22.3%

F-statistic

12.81**

Table 52: Results of OLS regression for self-reported interest † * ** 142

p < .10 p < .05 p < .01

(p-values are two-sided)

Similar results were obtained when conducting an ordered probit regression.

182

Motivation and Incentivizing of OSS Developers

Table 53: Effect of monetary rewards on total motivation * **

p < .05 p < .01

(p-values are one-sided)

Table 54: Results of OLS regression for total motivation † * **

p < .10 p < .05 p < .01

(p-values are two-sided)

H2 addresses the effect of payment on total motivation. As shown in Table 53, for the entire sample total motivation significantly increases when introducing the monetary reward. Splitting the sample depending on the existence of a strong norm form payment, as hypothesized, a significantly positive effect is found for the group with a strong norm for payment and a positive but insignificant effect of the completion-contingent reward is observed for the “no strong norm for payment”-group. Univariate analysis thus lends support to H2, H2a, and H2b. To analyze H2 on a multivariate level, a regression on total motivation was run with the index for self-reported interest, the extrinsic motivation index (see Table 42), and

Motivation and Incentivizing of OSS Developers

183

the treatment and norm variables as regressors, showing that the administration of payment has a significantly positive effect (p = 0.01). As is shown in Table 54, this lends further support to H2. Since correlations between the regressors were high, a structured equation was modeled including the indices from Table 42 using the software AMOS 7.0. The model displayed in Figure 14 provided good fit with CFI above the threshold of 0.9 (CFI = 0.902), and RMSEA (RMSEA = 0.06)143 and the χ2-to-degrees-offreedom ratio (χ2/df = 1.91) clearly below their respective thresholds of 0.08 and 2.5 (Browne & Cudeck, 1993). The coefficient for the effect of administrating payment on total motivation in the model is positive and significant (p = 0.01).

Figure 14: Structural equation model to measure effect of payment on total motivation

6.5 Discussion and Implications 6.5.1 Effects of Payment and Norms on Intrinsic Motivation Previous studies on OSS developers’ motivation by Lakhani and Wolf (2005) and Roberts et al. (2006) could not find a crowding out effect on intrinsic motivation. In this study, I have asked whether the existence or non-existence of the crowding out effect depended on the existence of a strong norm for payment. The first hypothesis consequently analyzed the effect of both monetary reward and the existence of a strong norm for payment on developers’ self-reported interest to participate in a fictitious OSS projects. As hypothesized, an interaction effect is found between the two variables: people without a strong norm for payment show a decline in self-reported interest when offered a monetary reward, crowding out thus taking effect.144 143

144

The CFI is Bentler’s comparative fit index (Bentler, 1990), RMSEA is the root mean square error of approximation (Browne & Cudeck, 1993). This is also consistent with earlier considerations regarding OSS ideology: people strongly believing in ideological concepts around OSS will reject monetary rewards and perceive them as highly intrusive, negatively affecting the needs for autonomy and competence. This is also partly supported by findings by Ghosh (2005) who showed that people engaging in OSS with a political agenda such as ensuring freedom of software or beating large pro-

184

Motivation and Incentivizing of OSS Developers Looking at the strong norm for payment group, there are two possible explanations

why the reward may have been perceived as informational rather than controlling and thus not exerted a negative effect on intrinsic motivation: self-selection and meritocracy.

Full question texts are given in Table 42. Table 55: Extrinsic motivational factors depending on strong norm for payment † p < .10, * p < .05, ** p < .01

(p-values are one-sided)

prietary software firms reported having received significantly less monetary benefits through their OSS engagement compared to people motivated by monetary or career concerns.

Motivation and Incentivizing of OSS Developers

185

Concerning self-selection, when looking at extrinsic motivational factors (see Table 55), people with a strong norm for payment are significantly more motivated by “professional status enhancement” (p = 0.01) and “reputation enhancement” (p = 0.04). The existence of a strong norm for payment can thus be taken as a general indicator for high receptivity to external stimuli. Similarly, solely looking at the subsample of those survey participants who had already contributed to OSS projects in the past, we see that those individuals who had received payment for this reporting higher levels of extrinsic motivation than their peers (who had received no payment in any of their past OSS engagements) regarding “professional status enhancement” at a 10%-level—independent of the scenario experiment—(see Table 56). It thus seems safe to assume that developers with a strong norm for payment are more likely to join projects with an organizational sponsor than their peers, and they will do so partly for career concerns, that is, they specifically self-select into projects where they can signal their competence to the organizational sponsor of the project. For the group of developers with a strong norm for payment joining sponsored OSS projects, in the context of the meritocratic OSS culture, these people will more strongly see the external reward as an acknowledgement of their competence and a form of positive feedback. As an indicator for this, when comparing agreement of the respective group (treatment and strong norm for payment) with the rest of the sample (see Table 57) for the question “Participating in this project would give me a feeling of competence” in a t-test, a significant difference (p = 0.09) is observed. This is further confirmed when looking at the feedback measure (“If I engaged in this OS project, I think I would get objective feedback.”) which is also significantly higher (p = 0.03) for this group.

Question was analogous to full question texts are given in Table 42. Table 56: Motivational factors in past projects † p < .10, * p < .05, ** p < .01

(p-values are one-sided)

186

Motivation and Incentivizing of OSS Developers

Full question texts are given in Table 42. Table 57: Extrinsic motivational factors of participants in “treatment * strong norm for payment” group vs. rest of sample † * **

p < .10 p < .05 p < .01 (p-values are one-sided)

Motivation and Incentivizing of OSS Developers

187

This might even go as far as these people attributing the external reward with cue value characteristics (Harackiewicz, 1979; Harackiewicz, Manderlink, & Sansone, 1984). While cue value is usually associated with performance-contingent rewards, this may well apply in the general context of OSS: getting a piece of source code accepted requires individuals not only to finish a task but to do so in a way the community acknowledges to match certain performance requirements.

6.5.2 Effects of Payment and Norms on Total Motivation Looking at overall motivation, I find that the administration of a monetary reward has a positive effect on the sample. For the subsample without a strong norm for payment, there is no significant change whereas a significant increase in the level of overall motivation for the strong norm for payment group is observed. Overall, this shows the administration of a monetary reward will increase the likelihood that a random developer will join an OSS project if this project offers monetary compensation, the reason for this being that the positive effects of the external reward either outweigh the negative effects on intrinsic motivation as in the case of developers without a strong norm for payment, or, naturally, add to the potentially positive effects on satisfaction as in the case of developers with a strong norm for payment. We thus see that, under the condition of an existing strong norm for payment, there is no case in which the monetary incentive has a negative effect on total motivation of the overall sample. Still, while monetary rewards for tasks for which a norm for payment exists positively affect satisfaction at short-term, in the long run, the expected payment may lose its effect (Bénabou & Tirole, 2003).

6.5.3 Limitations Although sample size is by far large enough to guarantee statistical validity, the choice of sample population might have affected the outcomes of the study. Students might differ from “real” OSS developers and full-time programmers with respect to their experience with OSS, level of intrinsic and extrinsic motivation, their valuation of payment, and the importance of the payment norm. However, as Henkel (2006) stated, people in the academic or educational field are significantly more enthusiastic about OSS, and should thus be more intrinsically motivated than others. Furthermore, Amabile et al. (1994) showed that professionals who had worked several years in the same position are less motivated by the enjoyment they derive from their work. Yet, if intrin-

188

Motivation and Incentivizing of OSS Developers

sic motivation towards OSS is supposed to be stronger in the academic field than amongst professional software developers, crowding out should have therefore been observable all the more in this study when looking at the effect of a monetary reward on the sample (Frey, 1994), which is not the case (see also Table 47). Also concerning the sample, participants were mainly from one geographical area with rather homogeneous culture (Hofstede, 2001) which may have again influenced participants’ level of intrinsic and extrinsic motivation, their valuation of payment, and the importance of the existing payment norm. Furthermore, this study has focused merely on the administration of payment on motivation. We have seen that the administration of payment increases the likelihood that a random programmer will contribute to an OSS project. However, what cannot be measured is the effect on contribution quality, that is, both the skill level of the contributor and the quality of his or her contributions, which might also be affected.145 Future research may also tackle the question of whether payment may impact developers’ intent to contribute to an OSS project beyond monetary benefits and their direct impact on motivation, that is, the administration of a monetary reward might not only impact developers’ motivation to participate in the project, but also their valuation of other projects characteristics. For example, developers may assume that a project giving away financial rewards could have a higher survival rate than a non-paid one, and thus commit to a paid alternative for that reason rather than for being paid. 146 Whereas these effects would also have been captured by the total motivation variable in this study, it is debatable whether the direct or indirect effects of payment led to an increase in total motivation. While, in this study, the scope of the scenario project should have limited the impact of potential indirect effects, future research efforts might try to separate the indirect effects of payment from the direct ones, and to analyze their relative importance.147

145

146 147

If individuals can self-determine how to carry out tasks, no negative effect on creativity of the solutions is to be expected (Amabile, 1993). Yet, there are indications showing that people with a more hobbyist nature might more likely be a source of valuable innovation (Constant et al., 1996; Jeppesen & Frederiksen, 2006). Similarly, posting a higher wage for a vacancy in firms increases the probability of it being filled, whereas expected average quality of applicants declines because less motivated workers are induced to apply (Delfgaauw & Dur, 2007). I am indebted to Joachim Henkel for pointing this out to me. Regarding H1, no such effects were found for intrinsic motivation. However, with respect to H2 on total motivation to participate in the project, developers more strongly agreed to statements saying that they would receive more objective feedback (p = 0.03) and enhance their status in the OS community (p < 0.1) by participating in the fictional OSS project when they were offered payment, indicating that an indirect effect of payment may indeed have been present.

Motivation and Incentivizing of OSS Developers

189

6.5.4 Implications for Theory and Practice My results lead me to maintain that, given a strong norm for payment, an external reward will not be perceived as controlling but rather as informational and, thus, does not have to undermine intrinsic motivation and creativity. Two reasons underlying this phenomenon have been identified, (1) individuals with a strong norm for payment can—in accordance with their generally higher level of extrinsic motivation—self-select on projects that have organizational sponsors, and (2) the meritocratic OSS culture that may associate monetary rewards with cue value characteristics. On the other hand, individuals without a strong norm for payment who do not associate the monetary reward with cue value characteristic will try not to select themselves into projects with organizational sponsors. If they cannot freely choose not to work on such projects—for example, if monetary rewards are introduced to an existing project on which those individuals are already working—the intrinsic motivation of those individuals will decrease, and crowding out may well be observed. These findings confirm those of Staw et al. (1980), again showing the importance of existing norms when looking at the effect of external rewards on intrinsic motivation, and shed light on the coexistence of intrinsic and extrinsic motivational factors of OSS developers. More generally, I feel that, consequently, the effect of payment norms should always be taken into account when analyzing crowding out phenomena. Furthermore, while I have shown the effect of rewards and norms for completioncontingent rewards, these results should also hold for performance-contingent rewards, too, as those will act even more competence-enhancing under the precondition that individuals can decide how they carry out the tasks. By offering a monetary reward in a specific project, organizations that think about sponsoring OSS efforts may successfully attract skilled developers to work on their specific needs: while the data show that the attracted developers will be more strongly extrinsically motivated than their peers, no difference in intrinsic motivation, and no detrimental effect of reward on total motivation is observable. On the contrary, the likelihood that a developer will start working on this project—expressed by total motivation— significantly increases. Yet, organizations should refrain from sponsoring projects following ideologies opposing firm involvement in and commercialization of OSS, as the detrimental effects of rewards might easily outweigh their positive effects here.

190

Motivation and Incentivizing of OSS Developers From the viewpoint of management, it is interesting to see that arrangements such as

the Google Summer of Code148 may well succeed in attracting both intrinsically motivated developers who see the tasks presented as a challenge as well as extrinsically motivated ones who want to advertise their skills to Google as a potential employer.149 Such arrangement may consequently well be used for reputation-enhancing or recruiting purposes. Yet, while this study has shown that the administration of such rewards can make sense from a motivational point of view, organizational sponsors of OSS projects will need to evaluate whether the administration of rewards is also economically advantageous, in particular with respect to the quality of contributions by extrinsically motivated participants and, more generally, the skill level of these individuals.

6.6 Summary: Managing Corporate OSS Efforts In Chapters 5 and 6, it was shown, in general, that and how it is possible for firms to efficiently and effectively manage their OSS efforts. First, as implied in the benchmark study, because other firms have done so successfully and their approaches can be copied—in most cases directly, without any adjustments necessary to for example account for organizational factors such as corporate structure. Especially for the mere use of OSS, guidelines on this as well as best practice examples are both readily available and relatively easy to implement. Going one step further to participate in the OSS community will pose more difficulties to the corporation and its employees alike, but should be manageable by adhering to the processes explained. Second, despite the rumored “free culture” of OSS, conventional management practices will largely apply to corporate-sponsored OSS projects. In most cases, both monetary and non-monetary incentives can be used to steer voluntary participants’ effort to the optimal benefit of the company—without finding strong negative effects of monetary incentives on intrinsic motivation. Even more, the administration of monetary rewards might even have positive side effects with respect to for example recruiting new employees.

148

149

Participants in the Google Summer of Code receive $4,500 (prize money shared by one project team), the OSS project they work for receives an additional $500 (Google, 2007). Of course, some of the participants will also be motivated by the prospect of receiving the monetary reward. However, in this extreme case, the prospect of possibly being employed by Google may, over all participants, even weigh more strongly than the direct financial reward administered by Google to participants of the Summer of Code.

Summary and Outlook: OSS in the 21st Century

191

7 Summary and Outlook: OSS in the 21st Century Using the example of corporate OSS engagement, the purpose of this thesis has been to show if and how firms should engage in free revealing. Starting with a literature overview explaining the economics of OSS, it was shown that the ideas behind OSS are not necessarily new or unique to the software industry, but rather a derivate of existing models proliferated by the spread of cheap mass communication possibilities via the Internet. Resulting from those models and drawing on the existing literature on OSS, advantages and disadvantages of OSS for the different modes of corporate OSS engagement—using OSS, contributing to existing public OSS projects, and releasing proprietary software to start a new OSS project—were highlighted. It was shown that the biggest advantages reside in lower time-to-market, reduced cost, improved quality, and standard setting, whereas the single biggest disadvantage is a loss of IP. Still, an overall business case for OSS in general, and for releasing proprietary software as OSS in particular, can be positive when using other means to protect IP such as lead time or complementary assets, and by choosing a business model that makes optimal use of the potential advantages. Regarding the adoption process, there is reason to believe that top management, when having the necessary information to make an unbiased decision readily at hand, will often make a decision in favor of initiating or increasing corporate OSS engagement. I have given evidence that, when implemented correctly and with the goal of creating and appropriating value, all three modes of corporate OSS engagement should often be regarded favorably by top management, thus making a top-down adoption of OSS highly likely in these situations. With respect to bottom-up adoption, different job functions in the firm were shown to react differently to corporate OSS involvement or an increase thereof. Especially project managers and developers, the groups for which this would bring considerable change to their work routines, tend to view corporate OSS adoption less positively than their peers. Whereas the overall evaluation of OSS is still positive and enough people volunteering to work on commercially-sponsored OSS projects will be found, educating the members of the organization, communicating clearly about the companies’ OSS efforts, and establishing change agents should be considered to smoothen the transition. Finally, whereas these findings do not rule out a potential for bottom-up adoption, they highly reduce the likelihood of OSS becoming a grassroots movement to change the organizational structural from below. In particular,

Summary and Outlook: OSS in the 21st Century

192

it is highly unlikely that developers will unanimously support such a movement, quite the contrary to popular belief. Companies deciding to engage in OSS should establish clear guidelines describing how to do so to explain what is allowed and what is not. Again, this emphasizes the need for educating employees on the matter to further minimize potential disadvantages or even dangers to the corporation especially with respect to issues concerning licensing and the unintentional loss of intellectual property. When contributing to existing projects or even starting one on its own, the company should establish clear goals upfront to give those efforts a strategic direction. By doing this on the one hand and adhering to the basic principles of OSS and the OSS community on the other, the company should be able to gain the best of both worlds. Having launched a public OSS project, with respect to day-to-day management and the steering of individual efforts both by employees of the firm and external contributors, the company needs to make sure that all people working on the project are motivated to contribute in a way that is beneficial the company. People might be motivated both intrinsically and extrinsically and it is important to understand whether, in a given project, it will be socially acceptable to offer monetary rewards. Whichever the company chooses to do, it will need to understand that the choice of incentive mechanism may influence who will be participating in the project. Moreover, it should keep an eye on contribution quality when handing out monetary rewards.

7.1 Suggestions for Further Research Even though this thesis has been able to shed light on a considerable amount of questions in the field of OSS-related research, several new ones were discovered, thereby laying the path for the study of new and interesting issues. I will abstain from reciting those suggestions for further research that have been made previously in the text, but rather focus on two points not mentioned before that could become the focus of new and fruitful work. First, the idea of bottom-up adoption of OSS engagement in the organization was raised. Some indications were given that anecdotes about OSS being a grassroots phenomenon unanimously supported by developers need to be dismissed. Yet, this does not rule out the viability of it being a bottom-up adoption pushed either by another job function such as software testers or architects or by a coalition of individuals with different job functions who, however, have another characteristic in common, such as in-

Summary and Outlook: OSS in the 21st Century

193

novativeness, previous exposure to OSS, age, or education. Further studies on this phenomenon would not only improve our understanding about how the organization and its employees influence the adoption of OSS, but also, by studying the phenomenon over time, how the adoption and diffusion of OSS affects and, potentially, changes the organization. Fundamental concepts that need scrutiny in this context are communication, openness, trust, and salience; for example, a social identity theory perspective might also lead to considerable insight.150 Further extending this stream of research, such work would also allow for studying potential negative outcomes and consequences of OSS to explain why corporate OSS efforts might fail—especially in the light of competing commercial and non-commercial OSS projects—and why individuals in corporate OSS projects might exhibit harmful behavior such as secretly doing OSS or releasing code without proper authorization. On the positive side, the role of change agents in the adoption process of software development in an OSS-like fashion and, in particular, the role of the CIO, has received little attention yet. Especially the latter would allow for a more strategic understanding and, consequently, usage of the opportunities inherent in OSS and OSS development. Second, most-current research mainly by Lakhani and Jeppesen (Lakhani & Jeppesen, 2007; Lakhani et al., 2007) suggests that OSS itself might become the basis for a new theory on the invention and innovation process. They have named this concept “broadcast search;” it is based on the idea that for a problem that might seem really difficult for a specialist in one field, there might be an easily applicable solution from another. Among others, they quote the famous example of the longitude problem, that is, the search for a measure to determine an east-west position, which could not be solved by astronomers—including Newton and Galileo—despite a huge reward offered by the British parliament, until a clockmaker from the British countryside came up with the solution. Lakhani and Jeppesen find that many of the learnings that researchers have drawn from the work on OSS can be generalized to describe this phenomenon thereby extending the research on OSS to all of R&D. While they give an indication to why and how broadcast search may work, there is still much to learn in this area of research, such as what kind of problems an organization might think about putting into broadcast search and how to improve the likelihood of success of the process.

150

For an introduction to social identity theory, see for example Ashforth and Mael (1989) or Hogg and Terry (2000).

Summary and Outlook: OSS in the 21st Century

194

7.2 The Future of Commercial OSS No matter what its business, every firm active in software development needs to confront the questions of whether and how to engage in OSS. Blind et al. (2005) find in their survey that a majority of firms expect the biggest changes in software development to be coming from the area of OSS. In the event study on the release of proprietary software as OSS, a similar trend was uncovered showing that the importance of OSS in the IT industry has been increasing steadily since the aftermaths of the dot.com bubbleburst. It is striking to see that even Microsoft, a long-time opponent of OSS, supports OSS practices among licensees of Windows CE 6.0, granting them to access the full kernel source code and permitting them to modify it and share the modified code with other licensees.151 Furthermore, the OSI has approved two licenses by Microsoft as official OSS licenses. Indeed, this confirms findings by Henkel and Käs (2007) of an increased importance of openness, culminating in openness becoming a differentiator in the marketplace. Whereas all this gives considerable reason to believe in the growing future importance of OSS, among survey participants (from Chapter 4), OSS still failed to find support amongst a considerable share of developers and project managers who, confronted with immense change originating from the organizational adoption of OSS, showed classical signs of resistance to change. Several recommendations on how to overcome this problem have been presented. Also, in their own time, the nowadays common practices of software reuse and object oriented programming faced similar obstacles, but became widely adopted once their benefits came to be realized throughout the IT industry. Again, this lends further support to the belief that the question should no longer be whether firms should engage in OSS, but rather when, how, and to what extent. Attempts to answer these questions need to take into account the goals the firm wants to reach with its OSS efforts and the impact of OSS both on the firm’s software development processes and on the individuals involved. This work has been an attempt to shed light on these issues in order to enable a broader, more informed use of OSS and the OSS development style in an organizational context.

151

See http://msdn2.microsoft.com/en-us/embedded/aa714518.aspx (accessed May 23, 2007).

Bibliography

195

Bibliography Abreu, E. 2001. Behind the Big Blue Wall. http://www.postfix.org/standard.200101/0_1902_21395-0_00.html; retrieved April 21, 2006. Adobe. 2007 (April 26). Adobe to Open Source Flex. http://www.adobe.com/aboutadobe/pressroom/pressreleases/200704/042607Flex.ht ml; retrieved May 12, 2007. Agarwal, R. & Prasad, J. 1999. Are Individual Differences Germane to the Acceptance of New Information Technology? Decision Sciences, 30(2): 361-391. Agarwal, R. 2000. Individual Acceptance of Information Technologies. In R. W. Zmud (Ed.), Framing the Domains of IT Management: Project the Future ... ... Through the Past: 85-104. Cincinnati, OH: Pinnaflex. Aggarwal, N., Dai, Q., & Walden, E. A. 2006. Do Markets Prefer Open or Proprietary Standards for XML Standardization? An Event Study. International Journal of Electronic Commerce, 11(1): 117-136. Ajila, S. A. & Wu, D. 2007. Empirical Study of the Effects of Open Source Adoption on Software Development Economics. Journal of Systems and Software, 80(9): 1517-1529. Ajzen, I. 2005. Attitudes, Personality and Behavior (2nd ed.). Maidenhead, England: Open University Press. Alchian, A. A. & Demsetz, H. 1972. Production, Information Costs, and Economic Organization. American Economic Review, 62(5): 777-795. Alexy, O. 2007. Competition from the Commons? Siemens Enterprise Communications and Asterisk. Teaching Case Study, Technische Universität München. Alexy, O. & Henkel, J. 2007. Promoting the Penguin: Who is Advocating Open Source Software in Commercial Settings? In G. T. Solomon (Ed.), Proceedings of the SixtySixth Annual Meeting of the Academy of Management (CD). Allen, D., Baarda, T., Mous, F., Riddell, J., & Bastian, T. 2007 (May 10). People Behind KDE. http://www.behindkde.org/people (Overview of interviews conducted); retrieved May 12, 2007. Allen, R. C. 1983. Collective Invention. Journal of Economic Behavior & Organization, 4(1): 1-24. Amabile, T. M. 1983. The Social Psychology of Creativity. New York: Springer. Amabile, T. M. 1993. Motivational Synergy: Toward New Conceptualizations of Intrinsic and Extrinsic Motivation in the Workplace. Human Resource Management Review, 3(3): 185-201.

196

Bibliography

Amabile, T. M., Hill, K. G., Hennessey, A., & Tighe, E. M. 1994. The Work Preference Inventory: Assessing Intrinsic and Extrinsic Motivational Orientations. Journal of Personality and Social Psychology, 66(5): 950-967. Amit, R. & Zott, C. 2001. Value Creation in E-business. Strategic Management Journal, 22(6-7): 493-520. Apple. 2007 (November 28). Open Source Overview. http://developer.apple.com/opensource/overview.html; retrieved January 18, 2008. Arrow, K. J. 1962. Economic Welfare and the Allocation of Resources for Inventions. In R. R. Nelson (Ed.), The Rate and Direction of Inventive Activity: 609–625. Princeton, NJ: Princeton University Press. Arundel, A. 2001. The Relative Effectiveness of Patents and Secrecy for Appropriation. Research Policy, 30(4): 611-624. Ashforth, B. E. & Mael, F. 1989. Social Identity Theory and the Organization. Academy of Management Review, 14(1): 20-39. Avery, C. & Zemsky, P. 1998. Multidimensional Uncertainty and Herd Behavior in Financial Markets. American Economic Review, 88(4): 724. Baker, M. & Wurgler, J. 2000. The Equity Share in New Issues and Aggregate Stock Returns. Journal of Finance, 55(2219-2257). Baker, M. & Wurgler, J. 2007. Investor Sentiment in the Stock Market. Journal of Economic Perspectives, 21(2): 129-151. Baldridge, J. V. & Burnham, R. A. 1975. Organizational Innovation: Individual, Organizational, and Environmental Impacts. Administrative Sciences Quarterly, 20(2): 165-176. Baldwin, C. Y. & Clark, K. B. 1997. Managing in the Age of Modularity. Harvard Business Review, 75(5): 84-93. Baldwin, C. Y. & Clark, K. B. 2000. Design Rules: The Power of Modularity. Cambridge, MA: MIT Press. Banerjee, A. V. 1992. A Simple Model of Herd Behavior. Quarterly Journal of Economics, 107(3): 797-817. Banker, R. D., Datar, S. M., & Kemerer, C. F. 1991. A Model to Evaluate Variables Impacting the Productivity of Software Maintenance Projects. Management Science, 37(1): 1-18. Bass, L., Clements, P., & Kazman, R. 2003. Software Architecture in Practice (2nd ed.). Boston, MA: Addison-Wesley. Behlendorf, B. 1999. Open Source as a Business Strategy. In C. DiBona & S. Ockman & M. Stone (Eds.), Open Sources: Voices from the Open Source Revolution: 149170. Sebastopol u.a.: O'Reilly.

Bibliography

197

Bénabou, R. & Tirole, J. 2003. Intrinsic and Extrinsic Motivation. Review of Economic Studies, 70(244): 489-500. Benkler, Y. 2002. Coase's Penguin, or, Linux and The Nature of the Firm. The Yale Law Journal, 112(3): 369-446. Bentler, P. M. 1990. Comparative Fit Indexes in Structural Models. Psychological Bulletin, 107(2): 238-246. Bergs, S. 1981. Optimalität bei Clusteranalysen: Experiment zur Bewertung numerischer Klassifikationsverfahren. Unpublished PhD thesis, Westfälische Wilhelms-Universität, Münster. Bessen, J. 2005 (July). Open Source Software: Free Provision of Complex Public Goods. http://www.researchoninnovation.org/opensrc.pdf; retrieved December 01, 2006. Bikhchandani, S., Hirshleifer, D., & Welch, I. 1992. A Theory of Fads, Fashion, Custom, and Cultural Change as Informational Cascades. Journal of Political Economy, 100(5): 992. Binder, J. 1998. The Event Study Methodology since 1969. Review of Quantitative Finance and Accounting, 11(2): 111-137. Bitzer, J., Schrettl, W., & Schröder, P. J. H. 2007. Intrinsic Motivation in Open Source Software Development. Journal of Comparative Economics, 35(1): 160-169. Blind, K., Edler, J., & Friedewald, M. 2005. Software Patents: Economic Implications and Policy Implications. Cheltenham, UK: Edward Elgar. Bonaccorsi, A. & Rossi, C. 2003. Why Open Source Software Can Succeed. Research Policy, 32(7): 1243-1258. Bonaccorsi, A., Giannangeli, S., & Rossi, C. 2006. Entry Strategies under Competing Standards: Hybrid Business Models in the Open Source Software Industry. Management Science, 52(7): 1085-1098. Bonaccorsi, A. & Rossi, C. 2006. Comparing Motivations of Individual Programmers and Firms to Take Part in the Open Source Movement: From Community to Business. Knowledge, Technology, and Policy, 18(4): 40-64. Brown, S. J. & Warner, J. B. 1985. Using Daily Stock Returns: The Case of Event Studies. Journal of Financial Economics, 14(1): 3-31. Browne, M. W. & Cudeck, R. 1993. Alternative Ways of Assessing Equation Model Fit. In K. A. Bollen & J. S. Long (Eds.), Testing Structural Equation Models: 136162. Newbury Park: SAGE. Brynjolfsson, E. 1993. The Productivity Paradox of Information Technology. Communications of the ACM, 36(12): 66-77. Burgelman, R. A. 1983. A Model of the Interaction of Strategic Behavior, Corporate Context, and the Concept of Strategy. Academy of Management Review, 8(1): 61-70.

198

Bibliography

Business Week. 2004 (August 18). Linus Torvalds’ Benevolent Dictatorship. http://www.businessweek.com/technology/content/aug2004/tc20040818_1593.htm; retrieved January 7, 2008. Calinski, T. & Harabasz, J. 1974. A dendrite method for cluster analysis. Communications in Statistics, 3: 1-27. Campbell, C. J. & Wasley, C. E. 1993. Measuring Security Price Performance Using Daily NASDAQ Returns. Journal of Financial Economics, 33(1): 73-92. Campbell, J. Y., Lo, A. W., & MacKinlay, A. C. 1997. The Econometrics of Financial Markets. Princeton, NJ: Princeton University Press. CED. 2006 (April). Open Standards, Open Source, and Open Innovation: Harnessing the Benefits of Openness, Committee for Economic Development. http://www.ced.org/docs/report/report_ecom_openstandards.pdf; retrieved May 12, 2007. Chakrabarti, A. K. & O'Keefe, R. D. 1977. A Study of Key Communicators in Research and Development Laboratories. Group & Organization Management, 2(3): 336-346. Chesbrough, H. & Rosenbloom, R. S. 2002. The Role of the Business Model in Capturing Value from Innovation: Evidence from Xerox Corporation's Technology Spinoff Companies. Industrial and Corporate Change, 11(3): 529-555. Chesbrough, H. W. 2003. Open Innovation: The New Imperative for Creating and Profiting from Technology. Boston: Harvard Business School Press. Chesbrough, H. W., Vanhaverbeke, W., & West, J. (Eds.). 2006. Open Innovation: Researching a New Paradigm. Oxford: Oxford University Press. Cohen, W. M., Nelson, R. R., & Walsh, J. P. 2000 (February). Protecting Their Intellectual Assets: Appropriability Conditions and Why U.S. Manufacturing Firms Patent (or Not). http://www.nber.org/papers/w7552; retrieved April 7, 2006. Constant, D., Sproull, L., & Kiesler, S. 1996. The Kindness of Strangers: The Usefulness of Electronic Weak Ties for Technical Advance. Organization Science, 7(2): 119-135. Contreras Jr., J. L., Juran, B. M., & Kummermehr, M. J. 2005 (June 3). Second Injunction Enforcing GPL Issued in Germany. http://www.wilmerhale.com/publications/whPubsDetail.aspx?publication=346; retrieved May 10, 2006. Cooper, M. J., Dimitrov, O., & Rau, P. R. 2001. A Rose.com by Any Other Name. Journal of Finance, 56(6): 2371-2388. Cooper, M. J., Khorana, A., Osobov, I., Patel, A., & Rau, P. R. 2005. Managerial Actions in Response to a Market Downturn: Valuation Effects of Name Changes in the Dot.com Decline. Journal of Corporate Finance, 11(1-2): 319-335. Cooper, R. B. & Zmud, R. W. 1990. Information Technology Implementation Research: A Technological Diffusion Approach. Management Science, 36(2): 123-139.

Bibliography

199

Corrado, C. J. 1989. A Nonparametric Test for Abnormal Security-price Performance in Event Studies. Journal of Financial Economics, 23(2): 385-395. Csikszentmihalyi, M. 1975. Beyond Boredom and Anxiety: The Experience of Play in Work and Games. San Francisco, CA: Jossey-Bass. Csikszentmihalyi, M. 1990. Flow: The Psychology of Optimal Experience. New York, NY: Harper and Row. Cusumano, M., MacCormack, A., Kemerer, C. F., & Crandall, B. 2003. Software Development Worldwide: The State of the Practice. IEEE Software, 20(6): 28-34. Daft, R. L. 1978. A Dual-Core Model of Organizational Innovation. Academy of Management Journal, 21(2): 193-210. Dahlander, L. 2005. Appropriation and Appropriability in Open Source Software. International Journal of Innovation Management, 9(3): 259-285. Dahlander, L. & Magnusson, M. G. 2005. Relationships between Open Source Software Companies and Communities: Observations from Nordic Firms. Research Policy, 34(4): 481-493. Dahlander, L. & Wallin, M. W. 2006. A Man on the Inside: Unlocking Communities as Complementary Assets. Research Policy, 35(8): 1243-1259. Dahlander, L. 2007. Penguin in a New Suit: A Tale of how de novo Entrants Emerged to Harness Free and Open Source Software Communities. Industrial and Corporate Change, 16(5): 913-943. Dalle, J.-M. & Jullien, N. 2003. 'Libre' Software: Turning Fads into Institutions? Research Policy, 32(1): 1–11. Dam, K. W. 1995. Some Economic Considerations in the Intellectual Property Protection of Software. Journal of Legal Studies, 24(2): 321-377. Damanpour, F. & Evan, W. M. 1984. Organizational Innovation and Performance: The Problem of 'Organizational Lag'. Administrative Science Quarterly, 29(3): 392-409. Damanpour, F. 1991. Organizational Innovation: A Meta-Analysis of Effects of Determinants and Moderators. Academy of Management Journal, 34(3): 555-590. Dann, L. Y., Mayers, D., Rafts, R. J., & Jr. 1977. Trading Rules, Large Blocks and the Speed of Price Adjustment. Journal of Financial Economics, 4(1): 3-22. Davis, F. D. 1989. Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Quarterly, 13(3): 318-340. Davis, F. D., Bagozzi, R. P., & Warshaw, P. R. 1989. User Acceptance of Computer Technology: A Comparison of Two Theoretical Models. Management Science, 35(8): 982-1003. De Long, J. B., Shleifer, A., Summers, L. H., & Waldmann, R. J. 1990. Noise Trader Risk in Financial Markets. Journal of Political Economy, 98(4): 703-738.

200

Bibliography

Deci, E. L. & Ryan, R. M. 1985. Intrinsic Motivation and Self-Determination in Human Behaviour. New York: Plenum. Deci, E. L., Koestner, R., & Ryan, R. M. 1999. A Meta-Analytic Review of Experiments Examining the Effects of Extrinsic Rewards on Intrinsic Motivation. Psychological Bulletin, 125(6): 627-668. Dehning, B. & Richardson, V. J. 2002. Returns on Investments in Information Technology: A Research Synthesis. Journal of Information Systems, 16(1): 7-30. Dehning, B., Richardson, V. J., & Zmud, R. W. 2003. The Value Relevance of Announcements of Transformational Information Technology Investments. MIS Quarterly, 27(4): 637-656. Dehning, B., Richardson, V. J., Urbaczewski, A., & Wells, J. D. 2004. Reexamining the Value Relevance of E-Commerce Initiatives. Journal of Management Information Systems, 21(1): 55-82. Delfgaauw, J. & Dur, R. 2007. Signaling and Screening of Workers' Motivation. Journal of Economic Behavior & Organization, 62(4): 605-624. Demsetz, H. 1967. Toward a Theory of Property Rights. American Economic Review, 57(2): 347-359. DiBona, C. 2005. Open Source and Proprietary Software Development. In C. DiBona & D. Cooper & M. Stone (Eds.), Open Sources 2.0: The Continuing Evolution: 21-36. Sebastopol, CA: O'Reilly. Dinkelacker, J., Garg, P. K., Miller, R., & Nelson, D. 2001 (September 28). Progressive Open Source. http://www.hpl.hp.com/techreports/2001/HPL-2001-233.pdf; retrieved November 19, 2006. Dos Santos, B. L., Peffers, K., & Mauer, D. C. 1993. The Impact of Information Technology Investment Announcements on the Market Value of the Firm. Information Systems Research, 4(1): 1-23. Driver, M., Drakos, N., Weiss, G. J., Claunch, C., Govekar, M., Feinberg, D., Maio, A. D., Hostmann, B., Igou, B., Cantara, M., Phifer, G., Enck, J., Pescatore, J., Latham, L., Gilliland, M., Silver, M. A., Haight, C., Valdes, R., Girard, J., Perkins, E. L., Lee, M., Hafner, B., Natis, Y. V., & Cain, M. W. 2005 (July 20). Hype Cycle for Open-Source Software, 2005. http://www.gartner.com/DisplayDocument?id=483919; retrieved August 2, 2005. Driver, M. & Weiss, G. J. 2005 (November 28). Predicts 2006: The Effects of OpenSource Software on the IT Software Industry. http://www.gartner.com/DisplayDocument?doc_cd=136381; retrieved January 30, 2006. Duda, R. O. & Hart, P. E. 1973. Pattern Classification and Scene Analysis. New York: Wiley. Ebadi, Y. M. & Utterback, J. M. 1984. The Effects of Communication on Technological Innovation. Management Science, 30(5): 572-585.

Bibliography

201

Economist. 2005 (September 22). Fears of Another Internet Bubble. http://www.economist.com/business/displaystory.cfm?story_id=E1_QQNVDDS; retrieved January 12, 2007. Economist. 2006 (March 18). Open, but not as usual, The Economist: 65-67. Engineering News. 2007 (February 19). NC State Engineer Creates First Academic Playstation 3 Computing Cluster. http://moss.csc.ncsu.edu/~mueller/cluster/ps3/coe.html; retrieved January 17, 2008. Fama, E. F., Fisher, L., Jensen, M. C., & Roll, R. 1969. The Adjustment of Stock Prices to new Information. International Economic Review, 10(1): 1. Fama, E. F. & Jensen, M. C. 1983a. Separation of Ownership and Control. Journal of Law and Economics, 26(2): 301-325. Fama, E. F. & Jensen, M. C. 1983b. Agency Problems and Residual Claims. Journal of Law and Economics, 26(2): 327-349. Fan, B., Aitken, A., & Koenig, J. 2004 (November). Open Source Intellectual Property and Licensing Compliance: A Survey and Analysis of Industry Best Practices. http://www.osdl.org/docs/olliance___ip_and_licensing_best_practices.pdf; retrieved February 28, 2006. Farrell, J. & Saloner, G. 1985. Standardization, Compatibility, and Innovation. RAND Journal of Economics, 16(1): 70-83. Farrell, J. & Gallini, N. T. 1988. Second-sourcing as a Commitment: Monopoly Incentives to Attract Competition. Quarterly Journal of Economics, 103(4): 673-694. Fazio, R. H., Zanna, M. P., & Cooper, J. 1978. Direct Experience and Attitude-Behavior Consistency: An Information Processing Analysis. Personality and Social Psychology Bulletin, 4(1): 48-51. Fazio, R. H. & Zanna, M. P. 1981. Direct Experience and Attitude-Behavior Consistency. In L. Berkowitz (Ed.), Advances in Experimental Social Psychology: 161-202. New York, NY: Academic Press. Feller, J. & Fitzgerald, B. 2001. Open Source Software: Investigating the Software Engineering, Psychosocial and Economic Issues. Information Systems Journal, 11(4): 273-276. Fichman, R. G. & Kemerer, C. F. 1993. Adoption of Software Engineering Process Innovations: The Case of Object Orientation. Sloan Management Review, 34(2): 7-22. Fish, R. S., Kraut, R., E., Root, R., W., & Rice, R., E. 1993. Video as a Technology for Informal Communication. Communications of the ACM, 36(1): 48-61. Fleming, L. & Waguespack, D. 2005 (April 8). Penguins, Camels, and Other Birds of a Feather: Brokerage, Boundary Spanning, and Leadership in Open Innovation Communities. http://ssrn.com/abstract=710641; retrieved May 12, 2007.

202

Bibliography

Fleury, M. & Lindfors, J. 2001 (January 2). Enabling Component Architectures with JMX. http://www.onjava.com/pub/a/onjava/2001/02/01/jmx.html; retrieved April 6, 2006. Flowers, S. 2006 (April). Harnessing the Hackers: The Emergence and Exploitation of Outlaw Innovation. http://www.sussex.ac.uk/spru/documents/flowers-paper.pdf; retrieved September 17, 2007. Fogel, K. 2005. Producing Open Source Software: How to Run a Successful Free Software Project. Sebastopol, CA: O'Reilly. Foxall, G. R. & Hackett, P. M. W. 1992a. Cognitive Style and Extent of Computer Use in Organizations: Relevance of Sufficiency of Originality, Efficiency and RuleConformity. Perceptual and Motor Skills, 74(2): 491-497. Foxall, G. R. & Hackett, P. M. W. 1992b. The Factor Structure and Construct Validity of the Kirton Adaption-Innovation Inventory. Personality and Individual Differences, 13(9): 967-975. Franke, N. & von Hippel, E. 2003. Satisfying Heterogeneous User Needs via Innovation Toolkits: The Case of Apache Security Software. Research Policy, 32(7): 11991215. Frey, B. S. 1993. Does Monitoring Increase Work Effort? The Rivalry with Trust and Loyalty. Economic Inquiry, 31(4): 663-670. Frey, B. S. 1994. How Intrinsic Motivation Is Crowded Out and In. Rationality & Society, 6(3): 334-352. FSF. 2006 (May 4). Frequently Asked Questions about the GNU GPL. http://www.gnu.org/licenses/gpl-faq.html; retrieved May 10, 2006. FSF. 2007 (December 1). The Free Software Definition. http://www.gnu.org/philosophy/free-sw.html; retrieved January 16, 2008. Gallivan, M. J. 2001. Organizational Adoption and Assimilation of Complex Technological Innovations: Development and Application of a New Framework. SIGMIS Database, 32(3): 51-85. Gallivan, M. J. 2003. The Influence of Software Developers' Creative Style on Their Attitudes to and Assimilation of a Software Process Innovation. Information & Management, 40(5): 443-465. Gartner. 2005 (November 15). Gartner TCO. http://amt.gartner.com/TCO/MoreAboutTCO.htm; retrieved January 17, 2008. Gates, B. 2006. Enabling Innovation and Prosperity in a Connected World, Microsoft Government Leaders Forum Americas. Washington, D.C. Ghosh, R. A. 2005. Understanding Free Software Developers: Findings from the FLOSS Study. In J. Feller & B. Fitzgerald & S. Hissam & K. Lakhani (Eds.), Perspectives on Free and Open Source Software: 23-45. Cambridge, MA: MIT Press.

Bibliography

203

Ghosh, R. A. 2006 (November 20). Study on the Economic Impact of Open Source Software on Innovation and the Competitiveness of the Information and Communication Technologies (ICT) Sector in the EU. http://ec.europa.eu/enterprise/ict/policy/doc/2006-11-20-flossimpact.pdf; retrieved May 12, 2007. Goldman, R. & Gabriel, R. P. 2005. Open Source as Business Strategy: Innovation Happens Elsewhere. San Francisco, CA: Morgan Kaufmann. Google. 2007. Google Summer of Code. http://code.google.com/soc; retrieved May 12, 2007. Goulde, M. 2006 (September 11). Open Source Becoming Mission-Critical In North America And Europe. http://www.forrester.com/Research/Document/Excerpt/0,7211,38866,00.html; retrieved October 2, 2006. Grand, S., von Krogh, G., Leonard, D., & Swap, W. 2004. Resource Allocation Beyond Firm Boundaries: A Multi-Level Model for Open Source Innovation. Long Range Planning, 37(6): 591-610. Granovetter, M. S. 1973. The Strength of Weak Ties. American Journal of Sociology 78(6): 1360-1380. Granovetter, M. S. 1985. Economic Action and Social Structure: The Problem of Embeddedness. American Journal of Sociology, 91(3): 481-510. Grover, V. 1997. An Extension of the Tri-Core Model of Information Systems Innovation: Strategic and Technological Moderators. European Journal of Information Systems, 6(4): 232-242. Gruber, M. & Henkel, J. 2006. New Ventures Based on Open Innovation – an Empirical Analysis of Start-Up Firms in Embedded Linux. International Journal of Technology Management, 33(4): 356-372. Hair, J. F., Jr., Black, W. C., Babin, B. J., Anderson, R. E., & Tatham, R. L. 2005. Multivariate Data Analysis (6th ed.). Upper Saddle River, NJ: Prentice Hall. Hall, B. H. & MacGarvie, M. 2006 (September). The Private Value of Software Patents. http://elsa.berkeley.edu/~bhhall/papers/HallMacGarvie_Sept06.pdf; retrieved February 10, 2008. Hamel, G., Doz, Y. L., & Prahalad, C. K. 1989. Collaborate with Your Competitors and Win. Harvard Business Review, 67(1): 133-139. Hang, J., Hohensohn, H., Mayr, K., & Wieland, T. 2004. Benefits and Pitfalls of Open Source in Commercial Contexts. In S. Koch (Ed.), Free/Open Source Software Development: 222-241. Hershey, PA: Idea Group. Harackiewicz, J. M. 1979. The Effects of Reward Contingency and Performance Feedback on Intrinsic Motivation. Journal of Personality and Social Psychology, 37(8): 1352-1363.

204

Bibliography

Harackiewicz, J. M., Manderlink, G., & Sansone, C. 1984. Rewarding Pinball Wizardry: Effects of Evaluation and Cue Value on Intrinsic Interest. Journal of Personality and Social Psychology, 47(2): 287-300. Harhoff, D., Henkel, J., & von Hippel, E. 2003. Profiting from Voluntary Information Spillovers: How Users Benefit by Freely Revealing their Innovations. Research Policy, 32(10): 1753-1769. Hars, A. & Ou, S. 2002. Working for Free? Motivations for Participating in OpenSource Projects. International Journal of Electronic Commerce, 6(3): 25-39. Hauschildt, J. & Chakrabarti, A. K. 1989. The Division of Labour in Innovation Management. R&D Management, 19(2): 161-171. Hauschildt, J. & Kirchmann, E. 2001. Teamwork for Innovation - The 'Troika' of Promotors. R&D Management, 31(1): 41-49. Hecker, F. 1999. Setting Up Shop: The Business of Open-Source Software. IEEE Software, 16(1): 45-51. Henderson, R. M. & Clark, K. B. 1990. Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms. Administrative Science Quarterly, 35(1): 9-30. Henkel, J. 2004a (August). Patterns of Free Revealing – Balancing Code Sharing and Protection in Commercial Open Source Development. http://opensource.mit.edu/papers/henkel2.pdf; retrieved March 4, 2008. Henkel, J. 2004b. Open Source Software from Commercial Firms – Tools, Complements, and Collective Invention. ZfB-Ergänzungsheft, 74(4). Henkel, J. 2005 (October). The Jukebox Mode of Innovation: A Model of Commercial Open Source Development. http://www.tim.wi.tum.de/home/index.php?option=com_docman&task=doc_downl oad&gid=6&Itemid=27; retrieved Januar 17, 2008. Henkel, J. & Tins, M. 2005. Die industrielle Nutzung und Entwicklung von OpenSource-Software: Embedded Linux. In B. Lutterbeck & R. A. Gehring & M. Bärwolff (Eds.), Open Source Jahrbuch 2005. Zwischen Softwareentwicklung und Gesellschaftsmodell: 123-138. Berlin: Lehmanns Media. Henkel, J. & von Hippel, E. 2005. Welfare Implications of User Innovation. Journal of Technology Transfer, 30(1/2): 73-87. Henkel, J. 2006. Selective Revealing in Open Innovation Processes: The Case of Embedded Linux. Research Policy, 35(7): 953-969. Henkel, J. 2007. Offene Innovationsprozesse: Die kommerzielle Entwicklung von OpenSource-Software. Wiesbaden: Deutscher Universitäts-Verlag. Henkel, J. & Käs, S. 2007. Source Code Urgently Needed! How the Demand for Openness Redefines Competition, 5th International Workshop on User Innovation. Copenhagen Business School, Copenhagen, Denmark.

Bibliography

205

Henkel, J. 2008. Champions of Revealing - The Role of Open Source Developers in Commercial Firms. Industrial and Corporate Change, Accepted for Publication. Henry, E. & Faller, B. 1995. Large-Scale Industrial Reuse to Reduce Cost and Cycle Time. IEEE Software, 12(5): 47-53. Hertel, G., Niedner, S., & Herrmann, S. 2003. Motivation of software developers in Open Source projects: an internet-based survey of contributors to the Linux kernel. Research Policy, 32(7): 1159-1177. Hissam, S., Weinstock, C. B., Plakosh, D., & Asundi, J. 2001. Perspectives on Open Source Software. Pittsburgh PA: Software Engineering Institute, Carnegie Mellon University. Hitt, M. A., Keats, B. W., & DeMarie, S. M. 1998. Navigating in the New Competitive Landscape: Building Strategic Flexibility and Competitive Advantage in the 21st Century. Academy of Management Executive, 12(4): 22-42. Hoegner, W., Hofmann, P., & Schießl, F. 2006 (September 26). LiMux - Freie Software für München. http://www.ihkmuenchen.de/internet/mike/ihk_geschaeftsfelder/innovation/Anhaenge/4_LiMux_P OS_Regional_2006.pdf; retrieved January 17, 2008. Hofstede, G. 2001. Culture's Consequences: Comparing Values, Behaviors, Institutions, and Organization across Nations. Thousand Oaks, CA: Sage. Hogg, M. A. & Terry, D. J. 2000. Social Identity and Self-categorization Processes in Organizational Contexts. Academy of Management Review, 25(1): 121-140. Hohensohn, H., Bretschneider, U., & Renk, S. 2004. Open Source Software Release: Ein Ratgeber für die Veröffentlichung von Software unter dem Open Source-Status. C-LAB Report, 3(1). Hohndel, D. 2006. Die Bedeutung von Open Source für die Prozessorenentwicklung, Open Source Meets Business: Conference presentation given at conference "Open Source Meets Business". Nuremberg, Germany: Heise Zeitschriften Verlag. Howell, J. M. & Higgins, C. A. 1990. Champions of Technological Innovation. Administrative Science Quarterly, 35(2): 317-341. Howell, J. M. & Shea, C. M. 2001. Individual Differences, Environmental Scanning, Innovation Framing, and Champion Behavior: Key Predictors of Project Performance Journal of Product Innovation Management, 18(1): 15-27. Howell, J. M. & Boies, K. 2005. Champions of Technological Innovation: The Influence of Contextual Knowledge, Role Orientation, Idea Generation, and Idea Promotion on Champion Emergence. Leadership Quarterly, 15(1): 123–143. Howell, J. M., Shea, C. M., & Higgins, C. A. 2005. Champions of Product Innovations: Defining, Developing, and Validating a Measure of Champion Behavior. Journal of Business Venturing, 20(5): 641-661.

206

Bibliography

Howell, J. M. & Shea, C. M. 2006. Effects of Champion Behavior, Team Potency, and External Communication Activities on Predicting Team Performance. Group & Organization Management, 31(2): 180-211. Im, K. S., Dow, K. E., & Grover, V. 2001. Research Report: A Reexamination of IT Investment and the Market Value of the Firm--An Event Study Methodology. Information Systems Research, 12(1): 103-117. Jeppesen, L. B. & Molin, M. J. 2003. Consumers as Co-developers: Learning and Innovation Outside the Firm. Technology Analysis & Strategic Management, 15(3): 363383. Jeppesen, L. B. & Frederiksen, L. 2006. Why Do Users Contribute to Firm-hosted User Communities? The Case of Computer-controlled Music Instruments. Organization Science, 17(1): 45-63. Jones, C. 2003. Variations in Software Development Practices. IEEE Software, 20(6): 22-27. Kappel, T. A. 2001. Perspectives on Roadmaps: How Organizations Talk About the Future. Journal of Product Innovation Management, 18(1): 39-50. Katz, M. L. & Shapiro, C. 1985. On the Licensing of Innovations. RAND Journal of Economics, 16(4): 504-520. Katz, M. L. & Shapiro, C. 1986. Technology Adoption in the Presence of Network Externalities. Journal of Political Economy, 94(4): 822-841. Katz, R. & Allen, T. J. 1982. Investigating the Not Invented Here (NIH) Syndrome: A Look at the Performance, Tenure, and Communication Patterns of 50 R&D Project Groups. R&D Management, 12(1): 7-19. Katz, R. & Allen, T. J. 1985. Organizational Issues in the Introduction of New Technologies. In P. R. Kleindorfer (Ed.), The Management of Productivity and Technology in Manufacturing, 2 ed.: 275-300. New York: Plenum. Ketchen, D. J., Jr. & Shook, C. L. 1996. The Application of Cluster Analysis in Strategic Management Research: An Analysis and Critique. Strategic Management Journal, 17(6): 441-458. Kim, Y. & Stohr, E. A. 1998. Software Reuse: Survey and Research Directions. Journal of Management Information Systems, 14(4): 113-149. Kirsch, L. J. 2000. Software Project Management: An Integrated Perspective for an Emerging Paradigm. In R. W. Zmud (Ed.), Framing the Domains of IT Management: Project the Future ... ... Through the Past: 285-304. Cincinnati, OH: Pinnaflex. Kirton, M. J. 1976. Adaptors and Innovators: A Description and Measure. Journal of Applied Psychology, 61(5): 622-629. Kirton, M. J. 2003. Adaption-Innovation: In the Context of Diversity and Change. London and New York: Routledge.

Bibliography

207

Klevorick, A. K., Levin, R. C., Nelson, R. R., & Winter, S. G. 1995. On the Sources and Significance of Interindustry Differences in Technological Opportunities. Research Policy, 24(2): 185-205. Koenig, J. 2004 (May 14). Seven Open Source Business Strategies for Competitive Advantage. http://management.itmanagersjournal.com/article.pl?sid=04/05/10/2052216; retrieved November 30, 2005. Kogut, B. & Metiu, A. 2001. Open-Source Software Development and Distributed Innovation. Oxford Review of Economic Policy, 17(2): 248-264. Kotter, J. P. & Schlesinger, L. A. 1979. Choosing Strategies for Change. Harvard Business Review, 57(2): 106-114. Kraeuter, C. 2006 (August 9). Digium Gets Funding From Matrix http://www.forbes.com/technology/2006/08/08/digium-matrixtelecom_cx_ck_0809digium.html; retrieved March 21, 2007. Krishnamurthy, S. 2002 (May 31). Cave or Community? An Empirical Examination of 100 Mature Open Source Projects. http://firstmonday.org/issues/issue7_6/krishnamurthy/index.html; retrieved June 15, 2007. Kwon, T. H. & Zmud, R. W. 1987. Unifying the Fragmented Models of Information Systems Implementation. In R. J. Boland, Jr. & R. A. Hirschheim (Eds.), Critical Issues in Information Systems Research. New York: John Wiley & Sons. Lakhani, K. & von Hippel, E. 2003. How Open Source Software Works: 'Free' User-toUser Assistance. Research Policy, 32(7): 923-943. Lakhani, K. & Wolf, B. 2005. Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects. In J. Feller & B. Fitzgerald & S. Hissam & K. Lakhani (Eds.), Perspectives on Free and Open Source Software: MIT Press. Lakhani, K. R. & Jeppesen, L. B. 2007. Getting Unusual Suspects to Solve R&D Puzzles. Harvard Business Review, 85(5): 30-32. Lakhani, K. R., Jeppesen, L. B., Lohse, P. A., & Panetta, J. A. 2007 (February 7). The Value of Openness in Scientific Problem Solving. http://www.hbs.edu/research/pdf/07-050.pdf; retrieved March 20, 2007. LaMonica, M. 2004 (February 12). Pandora's Box for Open Source: Companies are facing a cannibalizing dilemma. http://news.com.com/Pandoras+box+for+open+source/2009-7344_35157470.html?tag=nl; retrieved May 17, 2006. Landgericht München I. 2004. Wirksamkeit der GNU General Public License (GPL): Az.: 21O6123/04.

208

Bibliography

Laursen, K. & Salter, A. 2006. Open for Innovation: The Role of Openness in Explaining Innovation Performance among U.K. Manufacturing Firms. Strategic Management Journal, 27(2): 131-150. Lee, C. M. C., Shleifer, A., & Thaler, R. H. 1991. Investor Sentiment and the ClosedEnd Fund Puzzle. Journal of Finance, 46(1): 75-109. Lee, I. H. 1998. Market Crashes and Informational Avalanches. Review of Economic Studies, 65(225): 741-759. Lee, P. M. 2001. What's in a Name.com?: The Effects of '.com' Name Changes on Stock Prices and Trading Activity. Strategic Management Journal, 22(8): 793-804. Lehman, M. M. 1980. Programs, Life Cycles, and Laws of Software Evolution. Proceedings of the IEEE, 68(9): 1060-1076. Leonard-Barton, D. & Deschamps, I. 1988. Managerial Influence in the Implementation of New Technology. Management Science, 34(10): 1252-1265. Lerner, J. & Tirole, J. 2002. Some Simple Economics of Open Source. Journal of Industrial Economics, 50(2): 197-234. Lerner, J. & Tirole, J. 2005. The Scope of Open Source Licensing. Journal of Law, Economics, and Organization, 21(1): 20-56. Levin, R. C., Klevorick, A. K., Nelson, R. R., & Winter, S. G. 1987. Appropriating the Returns from Industrial Research and Development. Brookings Papers on Economic Activity(3): 783. Liebeskind, J. P. 1996. Knowledge, Strategy, and the Theory of the Firm. Strategic Management Journal, 17(Winter96 Special Issue): 93-107. Lim, W. C. 1994. Effects of Reuse on Quality, Productivity, and Economics. IEEE Software, 11(5): 23-28. Lyytinen, K. & Rose, G. M. 2003. The Disruptive Nature of Information Technology Innovations: The Case of Internet Computing in Systems Development Organizations. MIS Quarterly, 27(4): 557-595. MacCormack, A. D., Rusnak, J., & Baldwin, C. Y. 2006. Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code. Management Science, 52(7): 1015-1030. MacKinlay, A. C. 1997. Event Studies in Economics and Finance. Journal of Economic Literature, 35(1): 13-39. Madanmohan, T. R. & De', R. 2004. Open Source Reuse in Commercial Firms. IEEE Software, 21(6): 62-69. Mansfield, E. 1985. How Rapidly Does New Industrial Technology Leak out? Journal of Industrial Economics, 34(2): 217-223.

Bibliography

209

Markham, S. K., Green, S. G., & Basu, R. 1991. Champions and Antagonists: Relationships with R&D Project Characteristics and Management. Journal of Engineering and Technology Management, 8(3-4): 217-242. Mayring, P. 2004. Qualitative Content Analysis. In U. Flick & E. von Kardoff & I. Steinke (Eds.), A Companion to Qualitative Research: 266-269. London: Sage. McLure Wasko, M. & Faraj, S. 2005. Why Should I Share? Examining Social Capital and Knowledge Contribution in Electronic Networks of Practice. MIS Quarterly, 29(1): 35-57. McWilliams, A. & Siegel, D. 1997. Event Studies in Management Research: Theoretical and Empirical Issues. Academy of Management Journal, 40(3): 626-657. McWilliams, T. P. & McWilliams, V. B. 2000. Another Look at Theoretical and Empirical Issues In Event Study Methodology. Journal of Applied Business Research, 16(3): 1-11. Meets, J. G. 2006. Haftung, Gewährleistung, Urheberrecht, Patente: Open Source und die wichtigsten Rechtsfragen, Open Source Meets Business. Nuremberg, Germany: Heise Zeitschriften Verlag. Merriam-Webster. 2008. Compiler. http://www.m-w.com/cgi-bin/dictionary/compiler; retrieved January 23, 2008. Merton, R. K. & Rossi, A. K. 1949. Contributions to the Theory of Reference Group Behavior. In R. K. Merton (Ed.), Social Theory and Social Structure: 225-275. New York: Free Press. Milligan, G. & Cooper, M. 1985. An Examination of Procedures for Determining the Number of Clusters in a Data Set. Psychometrika, 50(2): 159-179. Mitchell, M. L. & Netter, J. M. 1989. Triggering the 1987 Stock Market Crash: Antitakeover Provisions in the Proposed House Ways and Means Tax Bill? Journal of Financial Economics, 24(1): 37-68. Moody, G. 2001. Rebel Code - Inside Linux and the Open Source Revolution (1st ed.). Cambridge, MA: Perseus Publishing. Morrison, P. D., Roberts, J. H., & von Hippel, E. 2000. Determinants of User Innovation and Innovation Sharing in a Local Market. Management Science, 46(12): 15131527. Narduzzo, A. & Rossi, A. 2005. The Role of Modularity in Free/Open Source Software Development. In S. Koch (Ed.), Free/Open Source Software Development: 84-102. Hershey, PA: Idea Group. Nordhaus, W. D. 1969. Invention, Growth, and Welfare: A Theoretical Treatment of Technological Change. Cambridge, MA: MIT Press. Nordhaus, W. D. 1972. The Optimum Life of a Patent: Repy. American Economic Review, 62(3): 428-431.

210

Bibliography

Novell. 2006 (November 02). Microsoft and Novell Announce Broad Collaboration on Windows and Linux Interoperability and Support. http://www.novell.com/news/press/microsoft_and_novell_announce_broad_collabor ation_on_windows_and_linux_interoperability_and_support; retrieved May 15, 2007. Nuvolari, A. 2001a. Collective Invention During the British Industrial Revolution: The Case of the Cornish Pumping Engine. http://fp.tm.tue.nl/ecis/Working%20Papers/eciswp37.pdf; retrieved December 01, 2006. Nuvolari, A. 2001b. Open Source Software Development: Some Historical Perspectives. http://fp.tm.tue.nl/ecis/Working%20Papers/eciswp75.pdf; retrieved December 01, 2006. O'Mahony, S. 2003. Guarding the Commons: How Community Managed Software Projects Protect Their Work. Research Policy, 32(7): 1179-1198. Oh, W., Gallivan, M. J., & Kim, J. W. 2006. The Market's Perception of the Transactional Risks of Information Technology Outsourcing Announcements. Journal of Management Information Systems, 22(4): 271-303. Olsen, M. 1967. The Logic of Collective Action. Cambridge, MA: Harvard University Press. OSI. 2001 (October 19). The Open Source Definition (Version http://www.opensource.org/docs/definition.php; retrieved May 10, 2006.

1.9).

Osterloh, M. & Rota, S. 2007. Open Source Software Development–Just Another Case of Collective Invention? Research Policy, 36(2): 157-171. Park, N. K. 2004. A Guide to Using Event Study Methods in Multi-country Settings. Strategic Management Journal, 25(7): 655-668. Raymond, E. S. 1999. The Revenge of the Hackers. In C. DiBona & S. Ockman & M. Stone (Eds.), Opensources: Voices from the open source revolution: 207-219. Sebastopol: O'Reilly. Raymond, E. S. 2001a. The Magic Cauldron. In E. S. Raymond (Ed.), The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, 2nd ed.: 113-191. Sebastopol: O'Reilly. Raymond, E. S. 2001b. The Cathedral and the Bazaar. In E. S. Raymond (Ed.), The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, 2nd ed.: 19-63. Sebastopol: O'Reilly. Raymond, E. S. 2001c. How to Become a Hacker. In E. S. Raymond (Ed.), The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, 2nd ed.: 195-213. Sebastopol: O'Reilly. Raymond, E. S. 2002 (August 2). The Cathedral and the Bazaar. http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html; retrieved January 16, 2008.

Bibliography

211

Roberts, J. A., Il-Horn, H., & Slaughter, S. A. 2006. Understanding the Motivations, Participation, and Performance of Open Source Software Developers: A Longitudinal Study of the Apache Projects. Management Science, 52(7): 984-999. Rogers, E. M. 2003. Diffusion of Innovations (5th ed.). New York, NY: Free Press. Rothwell, R., Freeman, C., Horlsey, A., Jervis, V. T. P., Robertson, A. B., & Townsend, J. 1974. SAPPHO updated - Project SAPPHO phase II. Research Policy, 3(3): 258291. Royce, W. W. 1987. Managing the Development of Large Software Systems: Concepts and Techniques. Proceedings of the 9th International Conference on Software Engineering: 328-338. Ryan, R. M. 1982. Control and Information in the Intrapersonal Sphere: An Extension of Cognitive Evaluation Theory. Journal of Personality and Social Psychology, 43(3): 450-461. Ryan, R. M. & Deci, E. L. 2000. Self-Determination Theory and the Facilitation of Intrinsic Motivation, Social Development, and Well-Being. American Psychologist, 55(1): 68-78. Scacchi, W. 2004. Free and Open Source Development Practices in the Game Community. IEEE Software, 21(1): 59-66. Scherer, F. M. 1972. Nordhaus' Theory of Optimal Patent Life: A Geometric Reinterpretation. American Economic Review, 62(3): 422-427. Schrader, S. 1991. Informal Technology Transfer Between Firms: Cooperation through Information Trading. Research Policy, 20(2): 153-170 Seel, C. 2006 (March 9). Der Lego-Roboter geht jetzt auf seine Kunden zu. http://www.welt.de/data/2006/03/09/856928.html; retrieved March 10, 2006. Senyard, A. & Michlmayr, M. 2004. How to Have A Successful Free Software Project. 11th Asia-Pacific Software Engineering Conference (APSEC'04). Shah, S. 2006. Motivation, Governance, and the Viability of Hybrid Forms in Open Source Software Development. Management Science, 52(7): 1000-1014. Shane, S. A. 1994. Are Champions Different From Non-Champions? Journal of Business Venturing, 9(5): 397-421. Shepard, A. 1987. Licensing to Enhance Demand for New Technologies. RAND Journal of Economics, 18(3): 360-368. Sherif, K., Zmud, R. W., & Browne, G. J. 2006. Managing Peer-to-Peer Conflicts in Disruptive Information Technology Innovations: The Case of Software Reuse. MIS Quarterly, 30(2): 339-356. Shiller, R. J. 2005. Irrational Exuberance (2nd ed.). Princeton, NJ: Princeton University Press.

212

Bibliography

Shleifer, A. & Vishny, R. 1997. The Limits of Arbitrage. Journal of Finance, 52(1): 3555. St. Laurent, A. M. 2004. Understanding Open Source and Free Software Licensing. Sebastopol, CA: O'Reilly Media. Staw, B. M., Calder, B. J., Hess, R. K., & Sandelands, L. E. 1980. Intrinsic Motivation and Norms about Payment. Journal of Personality, 48(1): 1-14. Stephan, P. E. 1996. The Economics of Science. Journal of Economic Literature, 34(3): 1199. Stewart, K. J., Ammeter, A. P., & Maruping, L. M. 2006. Impacts of License Choice and Organizational Sponsorship on User Interest and Development Activity in Open Source Software Projects. Information Systems Research, 17(2): 126-144. Stewart, K. J. & Gosain, S. 2006. The Impact of Ideology on Effectiveness in Open Source Software Teams. MIS Quarterly, 30(2): 291-314. Strong, N. 1992. Modelling Abnormal Returns: A Review Article. Journal of Business Finance & Accounting, 19(4): 533-553. SUN. 2007. JavaOne Conference 2007 - OpenJDK: Now the Journey Starts for the Community. http://java.sun.com/javaone/sf/2007/articles/openjdk_sands.jsp; retrieved May 12, 2007. Surowiecki, J. 2004. The Wisdom of Crowds: Why the Many are Smarter than the Few and how Collective Wisdom Shapes Business, Economies, Societies and Nations. London, UK: Little, Brown. Swanson, E. B. 1994. Information Systems Innovation Among Organizations. Management Science, 40(9): 1069-1092. Taylor, W. G. K. 1989a. The Kirton Adaption-Innovation Inventory: Should the SubScales be Orthogonal? Personality and Individual Differences, 10(9): 921-929. Taylor, W. G. K. 1989b. The Kirton Adaption-Innovation Inventory: A Re-Examination of the Factor Structure. Journal of Organizational Behavior, 10(4): 297-307. Teece, D. J. 1986. Profiting from Technological Innovation: Implications for Integration, Collaboration, Licensing and Public Policy. Research Policy, 15: 285-305. Tiemann, M. 2006 (September 19). History of the OSI. http://www.opensource.org/history; retrieved August 20, 2007. Tornatzky, L. G. & Klein, K. J. 1982. Innovation Characteristics and Innovation Adoption-Implementation: A Meta-Analysis of Findings. IEEE Transactions on Engineering Management, 29(1): 28-45. Tushman, M. L. 1977. Special Boundary Roles in the Innovation Process. Administrative Science Quarterly, 22(4): 587-605.

Bibliography

213

Tushman, M. L. & Scanlan, T. J. 1981. Boundary Spanning Individuals: Their Role in Information Transfer and Their Antecedents. Academy of Management Journal, 24(2): 289-305. Unger, J. M. & Frese, M. 2005. Configuration of Small and Micro Businesses and Success: Strategies, Firm, and Environment, Academy of Management Conference. Honolulu, HI. Varian, H. R. & Shapiro, C. 1999. Information Rules: A Strategic Guide to the Network Economy. Boston, MA: Harvard Business School Press. Varian, H. R. & Shapiro, C. 2003. Linux Adoption in the Public Sector: An Economic Analysis. http://people.ischool.berkeley.edu/~hal/Papers/2004/linux-adoption-inthe-public-sector.pdf; retrieved August 3, 2005. Venkatesh, V. 2000. Determinants of Perceived Ease of Use: Integrating Control, Intrinsic Motivation, and Emotion into the Technology Acceptance Model. Information Systems Research, 11(4): 342-365. Venkatesh, V. & Davis, F. D. 2000. A Theoretical Extension of the Technology Acceptance Model: Four Longitudinal Field Studies. Management Science, 46(2): 186204. Venkatesh, V., Morris, M. G., Davis, G. B., & Davis, F. D. 2003. User Acceptance of Information Technology: Toward a Unified View. MIS Quarterly, 27(3): 425-478. Venkatesh, V. 2006. Where To Go From Here? Thoughts on Future Directions for Research on Individual-Level Technology Adoption with a Focus on Decision Making. Decision Sciences, 37(4): 497-518. von Hippel, E. 1986. Lead Users: A Source of Novel Product Concepts. Management Science, 32(7): 791-805. von Hippel, E. 1988. The Sources of Innovation. New York, NY: Oxford University Press. von Hippel, E. 1994. "Sticky Information" and the Locus of Problem Solving: Implications for Innovation. Management Science, 40(4): 429-439. von Hippel, E. 1998. Economics of Product Development by Users: The Impact of "Sticky" Local Information. Management Science, 44(5): 629-644. von Hippel, E., Thomke, S., & Sonnack, M. 1999. Creating Breakthroughs at 3M. Harvard Business Review, 77(5): 47-57. von Hippel, E. 2001. Innovation by User Communities: Learning from Open-Source Software. MIT Sloan Management Review, 42(4): 82-86. von Hippel, E. & von Krogh, G. 2003. Open Source Software and the 'PrivateCollective' Innovation Model: Issues for Organization Science. Organization Science, 14(2): 209-233. von Hippel, E. 2005. Democratizing Innovation. Cambridge, MA: MIT Press.

214

Bibliography

von Hippel, E. & von Krogh, G. 2006. Free Revealing and the Private-Collective Model for Innovation Incentives. R&D Management, 36(3): 295-306. Weber, S. 2004. The Success of Open Source. Cambridge, MA: Harvard University Press. Weiss, A. 2005 (November 8). The Open Source WRT54G Story. http://www.wifiplanet.com/tutorials/article.php/3562391; retrieved September 9, 2007. West, J. 2003. How Open is Open Enough? Melding Proprietary and Open Source Platform Strategies. Research Policy, 32(7): 1259–1285. West, J. & Gallagher, S. 2006a. Challenges of Open Innovation: The Paradox of Firm Investment in Open Source Software. R&D Management, 36(3): 319-331. West, J. & Gallagher, S. 2006b. Patterns of Open Innovation in Open Source Software. In H. W. Chesbrough & W. Vanhaverbeke & J. West (Eds.), Open Innovation: Researching a New Paradigm: 82-106. Oxford: Oxford University Press. Wheeler, D. A. 2007 (April 16). Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! http://www.dwheeler.com/oss_fs_why.html; retrieved January 17, 2008. Wheelwright, S. C. & Clark, K. B. 1994. Accelerating the Design-Build-Test Cycle for Effective New Product Development. International Marketing Review, 11(1): 32-46. Wichmann, T. 2002. Firms' Open Source Activities: Motivations and Policy Implications (Part 2), Free/Libre Open Source Software: Survey and Study. Berlin: Berlecon Research. Witte, E. 1973. Das Promotoren-Modell: Organisation für Innovationsentscheidungen. Wu, C.-G., Gerlach, J. H., & Young, C. E. 2007. An Empirical Analysis of Open Source Software Developers' Motivations and Continuance Intentions. Information & Management, 44(3): 253-262. Zmud, R. W. 1982. Diffusion of Modern Software Practices: Influence of Centralization and Formalization. Management Science, 28(12): 1421-1431. Zmud, R. W. 1984. An Examination of 'Push-Pull' Theory Applied to Process Innovation in Knowledge Work. Management Science, 30(6): 727-738.