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.1) .............................. 106 Table 20: Mean values, standard deviations, and medians of independent variables by job function ............................................................................ 107 Table 21: Questions underlying factor constructs ...................................................... 109 Table 22: Means of OSS- and programming-related characteristics, by job function....................................................................................................... 111 Table 23: Descriptive statistics of OSS- and programming-related characteristics ... 112 Table 24: Descriptive statistics of dependent variables ............................................. 113 Table 25: Mean values of the dependent variables by job function ........................... 114 Table 26: Mann-Whitney test on differences in medians (one-sided p-values) ......... 115 Table 27: Results of the ordered probit regressions ................................................... 116 Table 28: Ordered probit post-estimation: test of equality of coefficients (one-sided p-values) ................................................................................... 117 Table 29: Descriptive statistics for suggestions made ................................................ 121

XVIII Table 30: Mann-Whitney test on differences in medians (one-sided p-values) for suggestions made........................................................................................ 121 Table 31: Results of the probit regression (suggestions made) .................................. 122 Table 32: Probit post-estimation: test of equality of coefficients (one-sided p-values) ..................................................................................................... 122 Table 33: Questions underlying factors in cluster analysis ........................................ 129 Table 34: Cluster summary (ordered by average rank of the two benefit measures) . 130 Table 35: Analysis of motivations in favor of OSS in the clusters ............................ 132 Table 36: Benchmark results: Using OSS .................................................................. 144 Table 37: Benchmark results: Contributing to existing OSS projects ........................ 145 Table 38: Benchmark results: Releasing proprietary software as OSS ...................... 147 Table 39: Scenario text ............................................................................................... 172 Table 40: Sample split according to grouping variables ............................................ 174 Table 41: Descriptive statistics for the dependent variables ...................................... 175 Table 42: Factor analysis after varimax rotation (only loadings > 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%, -50 to -20%, -20% to 0, 0, 0 to +20%, +20 to 50%, >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%, -50 to -20%, -20% to 0, 0, 0 to +20%, +20 to 50%, >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%, -50 to -20%, -20% to 0, 0, 0 to +20%, +20 to 50%, >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.1)

88

The respective survey question asked to what degree the participant agreed with the statement, “I identify with the OSS community.”

Bottom-up Adoption of OSS

107

Table 20: Mean values, standard deviations, and medians of independent variables by job function

Organizational characteristics. It having been shown that people who belong to a group are likely to take actions based on a frame of reference created by the group (Merton & Rossi, 1949), innovation diffusion might be expected to be influenced by embeddedness in social systems (Granovetter, 1985; Rogers, 2003). Whether individuals are favorably or unfavorably disposed to OSS engagement tends to be influenced by their immediate environment. Such influence is also important in the context of interaction and knowledge exchange with others both within and outside an organization (Gra-

108

Bottom-up Adoption of OSS

novetter, 1973, 1985; Katz & Allen, 1982, 1985; Rogers, 2003). Network externalities and the related critical mass phenomenon are a specific instance of such influence (e.g., Fish, Kraut, Root, & Rice, 1993). In this chapter, social systems and communication— as a mediator of social influence, a means to bridge gaps in compatibility, and a valuable source of innovation in itself (Chakrabarti & O'Keefe, 1977; Ebadi & Utterback, 1984; Katz & Allen, 1985)— are combined to measure the influence of organizational factors on individuals’ attitudes towards corporate OSS engagement using seven questions based on statements collected in the interviews: These items capture how respondents’ peers and supervisors think about, and the degree to which they are familiar with, OSS. The items were distributed throughout the questionnaire to minimize social desirability bias. All items load higher than 0.5 on one factor with eigenvalue larger than one, which explains 44% of the total variance(see Table 21). Cronbach’s α of the index (Organizational Factors) is 0.77. Individual characteristics were split into previous OSS exposure and personal innovativeness. Individuals who have previously been engaged in OSS are expected to view increased corporate engagement in OSS more favorably (Davis, 1989; Davis et al., 1989). To account for the effect of previous exposure to OSS, a dummy variable (“Did OSS”) for whether a participant had worked on OSS code before was included. Kirton proposed an Adaption-Innovation inventory (KAI) to measure creative style or innovativeness, which he maintains is an important determinant of how a person copes with change (Kirton, 1976, 2003). Using OSS, contributing to existing OSS projects, and releasing proprietary software as OSS, because they involve considerable change, should be more likely to be viewed favorably by individuals who score higher on the index. A number of studies have demonstrated the KAI inventory’s relevance to IT and IT adoption (Foxall & Hackett, 1992b; Gallivan, 2003). Its items load on three factors. The first factor, originality, describes how well a person can deal with new ideas, the second, efficiency, a person’s need for efficient processes and desire to execute tasks in great detail, and the third, conformity, a person’s adherence to rules and authorities. Because the items loading on the efficiency and conformity scales must be scored in reverse, the resulting indices correspond to inefficiency and non-conformity, and higher scores in fact indicate higher innovativeness (Kirton, 1976, 2003). Because the factor structure of the original 32-item scale has been disputed, the 13-item version of the KAI was used

Bottom-up Adoption of OSS

109

(Foxall & Hackett, 1992a; Taylor, 1989a, 1989b), each item ranging from 1 (“very adapter-like”) to 5 (“very innovator-like”). Principal component analysis retains three factors with eigenvalues larger than 1, explaining 58% of the total variance. After varimax rotation, all items load higher than 0.64 on the respective factor predicted by the KAI model and lower than 0.21 on any other. Cronbach’s α for the factors originality, (in-)efficiency, and (non-) conformity are 0.82, 0.79, and 0.68, respectively.

Reciprocity (α=0.79)

Factor Loadings

[FIRM] has an obligation of giving back to the OSS community

0.807

I would release code because I consider it fair to give back to the

0.882

community, since the company benefits from it I would release code because in the long run, you only get some-

0.823

thing when you gave something before

Popularity of OSS among Co-Workers (α=0.77)

Factor Loadings

(Organizational Factors) Management promotes the use of existing OSS

0.7

Which of the following factors do you consider supportive of or an

0.727

impediment to the wider use of OSS within [FIRM]? My supervisor Which of the following factors do you consider supportive of or an

0.601

impediment to the wider use of OSS within [FIRM]? My colleagues My supervisor is familiar with OSS

0.701

Most programmers at [FIRM] are familiar with OSS

0.638

In case I had questions on OSS, I would know someone at [FIRM] I

0.577

could turn to Management sees the benefit of OSS

0.64

Table 21: Questions underlying factor constructs

Further individual characteristics. Participant age was solicited and this variable included in the regressions. In line with the findings of Agarwal and Prasad (Agarwal & Prasad, 1999), highest level of education attained, country in which the degree was awarded, and major were checked for as well. It was also recorded at which site an indi-

110

Bottom-up Adoption of OSS

vidual was working. In no specification did any of the latter control variables show significance (either individually or jointly), so only specifications without these variables will be reported.

4.5 Results 4.5.1 Job Functions—Descriptive Analysis Respondents’ attitudes towards corporate OSS engagement must be viewed in light of their OSS experience. Table 22 displays the means of various OSS-related characteristics. For comparison, variables that describe respondents’ general programming activity are also displayed; further details on these variables are provided in Table 23. Taking into account both use and development, architects and developers are found to qualify as most experienced in OSS.89 In particular, developers have the highest share of respondents who have worked on OSS code. These facts are important for the following analysis. As will be shown below, developers are significantly less positive than software testers and architects about corporate OSS engagement. The data on OSS experience reported above allows ruling out a simple explanation of this finding based on lack of OSS-related experience. I now turn to this chapter’s main question of analyzing employee attitudes towards corporate OSS engagement. As Table 24 shows, respondents, on average, exhibit a “somewhat positive” attitude towards increased corporate engagement in OSS. Probing deeper by distinguishing the type of OSS engagement, a richer picture emerges. Using a scale from 1 (“strongly disagree”) to 5 (“strongly agree”), a mean value of 4.25 for using OSS, decreasing to 3.90 for contributing to OSS projects and to 3.53 for releasing proprietary software as OSS is obtained. The share of respondents that ticked “strongly agree” or “somewhat agree” yields an even clearer picture, declining from 85.1% (using) to 69.9% (contributing) to 56.2% (releasing).

89

The most experienced OSS users, in terms of both number of applications used and years working on OSS code, are software architects. Developers follow. In terms of share of respondents who have worked on OSS code, developers clearly lead (48%) architects (39%). In terms of hours spent per week writing and testing OSS code (at work and at home), project managers (5.6h/w) lead testers and developers (each 3.1h/w).

Bottom-up Adoption of OSS

111

Variable

Testers Architects Managers Developers Project Mgrs.

N

37

Number of OSS Appli-

23

27

153

9

2.486

3.652

2.741

3.046

2.444

2.297

3.478

2.556

2.627

2.444

1.541

2.391

1.815

2.373

0.889

0.297

0.391

0.259

0.484

0.333

Hours per week spent on 16.784

7.043

5.852

27.193

13.389

5.270

4.130

3.296

4.412

2.222

2.514

0.696

0.593

2.601

5.611

0.622

0.783

0.074

0.471

0.000

4.344

3.909

4.043

3.979

3.333

4.069

3.864

3.632

3.806

2.833

cations used (in total) Number of OSS Applications used (out of 6 suggestions) Years working on OSS source code Has worked on OSS code (1: Yes, 0:No)

programming at work (incl. testing, documentation) Hours per week spent on programming at home Hours per week spent on programming OSS at work (incl. testing, documentation) Hours per week spent on programming OSS at home I would like to use more OSS at [FIRM] I would like to develop more OSS at [FIRM] Bold: largest and second largest value in each line. Table 22: Means of OSS- and programming-related characteristics, by job function

112

Bottom-up Adoption of OSS

Variable

Me- Mean Std. Min Max dian Dev. Number of OSS Applications 2 2.96 2.68 0 15 used (in total) Number of OSS Applications 2 2.64 1.87 0 6 used (out of 6 suggestions) Years working on OSS source 0 2.14 3.65 0 21 code Has worked on OSS code 0 0.42 0.49 0 1 (1: Yes, 0:No) Hours per week spent on pro- 24 20.97 16.03 0 60 gramming at work (incl. testing, documentation) Hours per week spent on pro2 4.31 5.87 0 30 gramming at home

Share >0 Share 4 & 5 (mean)* (mean)* 89.96% --(3.29) 89.96% --(2.94) 29.37% --(5.22) 29.37% --(1) 78.31% --(26.78) 60.24% (7.16)

---

Hours per week spent on programming OSS at work (incl. testing, documentation) Hours per week spent on programming OSS at home I would like to use more OSS at [FIRM] I would like to develop more OSS at [FIRM] *

0

2.3

7.1

0

45

18.47% (12.47)

---

0

0.46

1.63

0

10

---

4

4.01

0.84

1

5

10.84% (4.26) ---

4

3.8

0.94

1

5

---

72.25% (4.01) 62.73% (3.80)

Mean value of respective group (i.e. value of respective variable >0 or >3, respectively

Table 23: Descriptive statistics of OSS- and programming-related characteristics

Note also that the standard deviation monotonically increases from using OSS to contributing to OSS projects to releasing proprietary software as OSS. This finding holds both for the pooled sample and for each of the five job functions independently (see Tables 24 and 25). This larger variation in the level of agreement, going hand in hand with the decrease in its mean, reflects the fact that the higher-involvement forms of corporate OSS engagement are yet unknown to employees and, hence, attended by higher uncertainty and higher perceived risk. Regarding the influence of respondents’ job functions, both the descriptive analysis presented here and the multivariate analysis in the following section matter. On the one hand, we need to know how testers, architects, developers, project managers, and managers, taken as groups, behave with respect to, and think about, OSS, which are analyzed using univariate analysis. On the other hand, we want to isolate the effect of the job function net of other respondent characteristics with which it might be correlated.

Bottom-up Adoption of OSS

113

As predicted, the level of support for OSS engagement is found to be highest for the group consisting of testers and architects, followed by the group made up of managers and developers (see Table 25). Project managers are the least positive about OSS. This finding is consistent across all three levels of OSS engagement, as is the ranking of attitude towards OSS by job function: testers, architects, managers, developers, and project managers (the only exception being that developers are more positive than managers with respect to releasing). The number of respondents being large (153) only for developers, it should come as no surprise that a Mann-Whitney test on the equality of medians fails to reject the Null hypothesis in a number of cases. Table 26 shows the results of this test.90 Using OSS receives similar (high) levels of agreement from all job functions. Nonetheless, four out of eight hypotheses are supported (H2[TD], H3[TP], H6[AP], and H7[MP]). For contributing to public OSS projects, significant differences between testers/architects and developers (H2[TD] and H5[AD]), and between testers/architects and project managers (H3[TP] and H6[AP]) are found. The largest, most significant differences between job functions are found in attitude towards releasing proprietary software as OSS, H1[TM], H2[TD], H3[TP], H4[AM], H6[AP], and H8[DP] being supported. Summarizing, the majority of hypotheses (14 out of 24) are supported. In particular, the difference between developers and the “leading” groups, testers and architects, is significant four times out of six.

Variable

N

Me-

Mean Std. Min Max

dian Corporation could benefit from

Dev.

Share 4&5

249

4

4.25

0.85

1

5

85.14%

249

4

3.90

0.98

1

5

69.88%

249

4

3.53

1.14

1

5

56.22%

using existing OSS more often Corporation could benefit from contributing to existing OSS projects Corporation could benefit from releasing proprietary software as OSS Table 24: Descriptive statistics of dependent variables

90

Given that the dependent variable is ordinal (not interval) scaled, a t-test on the equality of means would be inappropriate. The Mann-Whitney test has the additional advantage of being non-parametric (i.e., of not presuming a particular distribution of the data) which also applies to this situation (cf. Table 24).

114

Bottom-up Adoption of OSS

Variable

Testers

Archi-

Man-

Devel-

Project

tects

agers

opers

Mgrs.

Corporation could benefit from

4.46

4.30

4.30

4.20

4.00

using existing OSS more often

(0.73)

(0.82)

(0.95)

(0.88)

(0.5)

Corporation could benefit from contributing to existing OSS projects

4.22

4.17

3.89

3.80

3.56

(0.75)

(0.83)

(1.01)

(1.05)

(0.53)

Corporation could benefit from

4.14

3.74

3.15

3.46

2.89

releasing proprietary software as

(0.92)

(0.92)

(1.29)

(1.14)

(1.05)

OSS Bold: largest and second largest value in each line. Standard deviation in parentheses. Table 25: Mean values of the dependent variables by job function

4.5.2 Job Functions—Multivariate Analysis The results presented above are informative about the attitudes of the five groups. But although understanding their attitudes towards OSS is relevant for managing these groups of IT professionals, the univariate results might be due not so much to the respondents’ job functions as to other characteristics that, for whatever reason, are correlated with the task a person performs. To separate these intertwined effects, multivariate analysis, specifically, ordered probit regression, is employed to account for the ordinal nature of the dependent variables. Table 27 shows the regression results, using level of agreement with the three statements above as dependent variables.91 The first four lines of Table 27 show the estimation coefficients of the dummy variables coding respondents’ job functions, with testers as the reference group (i.e., their coefficient is implicitly set to zero). Coefficients thus indicate differences between the attitudes of testers and the respective other group. Post-estimation analyses run to compare the displayed coefficients with each other yielded the results reported in Table 28. Note that significance levels here refer to the hypotheses, which are directed (as opposed to the undirected significance levels given in Table 27). Table 28 resembles Table 26, with the important difference that (due to the multivariate regression) the influence of control variables on the respondent’s attitude levels is taken into account.

91

To assure that multicollinearity was not an issue, I also ran regressions dropping one of the more strongly correlated explanatory variables (“Identification with OSS community”) and obtained results largely identical to those presented. I also controlled for the influence of tenure at the company, but dropped the variable due to its high correlation (r = 0.84) with age. Using tenure with the corporation instead of age does not have an effect on the sign or level of significance of the other explanatory variables. Tenure itself is insignificant for the first two regressions (using, contributing) and significantly negative (p < 0.05) for the third regression (releasing).

Bottom-up Adoption of OSS Using

Testers

115 Architects

Managers

Developers

Project Managers

Mean

4.46

4.30

4.30

4.20

4.00

Median

5

4

5

4

4

Testers

---

Architects

0.227

Managers

0.332

0.403

Developers

0.049**

0.313

0.210

Project Mgrs

0.014**

0.073*

0.061*

Contributing

Testers

---

Architects

---

Managers

--0.102 Developers

--Project Managers

Mean

4.22

4.17

3.89

3.80

3.56

Median

4

4

4

4

4

Testers

---

Architects

0.460

Managers

0.111

0.169

Developers

0.018**

0.060*

0.370

Project Mgrs

0.005***

0.014**

0.125

Releasing

Testers

---

Architects

---

Managers

--0.135 Developers

--Project Managers

Mean

4.14

3.74

3.15

3.46

2.89

Median

4

4

3

4

5

Testers

-----

Architects

0.039**

Managers

0.001***

0.049**

Developers

0.000***

0.172

0.112

Project Mgrs

0.001***

0.025**

0.306

----0.066*

* significant at 10%; ** significant at 5%; *** significant at 1%. Table 26: Mann-Whitney test on differences in medians (one-sided p-values)

---

116

Bottom-up Adoption of OSS Corporation could benefit from… (1-5 scale, ordered probit) … using

Job Architect Job Manager Job Developer Job Project Manager Identification with OSS community

-0.015

-0.572*

(0.348)

(0.278)

(0.308)

-0.194

-0.268

-1.002***

(0.351)

(0.291)

(0.329)

-0.404

-0.511**

-0.752***

(0.249)

(0.208)

(0.214)

-0.307

-0.456

-0.920**

(0.298)

(0.314)

(0.395)

0.561***

Reciprocity

Did OSS

KAI Efficiency KAI Conformity Age

Observations Pseudo-R

2

Pseudo Likelihood Wald's chi-squared Degrees of freedom

0.284*** (0.097) 0.432***

0.325*** (0.093) 0.373***

(0.119)

(0.119)

0.077

-0.011

0.006

(0.124)

(0.117)

(0.117)

0.439***

KAI Originality

… releasing

-0.516

(0.085)

Organizational factors

… contrib.

0.401***

0.094

(0.154)

(0.147)

(0.141)

0.181

0.091

0.171

(0.142)

(0.133)

(0.130)

-0.101

-0.120

-0.149

(0.142)

(0.126)

(0.114)

-0.165

-0.058

0.095

(0.152)

(0.123)

(0.121)

-0.003

-0.019**

-0.019**

(0.008)

(0.008)

(0.008)

249 0.14 -240.862 73.694 238

249 0.13 -285.031 62.806 237

249 0.13 -320.875 88.274 237

* significant at 10%; ** significant at 5%; *** significant at 1%; robust standard errors in parentheses Table 27: Results of the ordered probit regressions

Bottom-up Adoption of OSS Using

Testers

117 Architects

Managers Developers

Project Managers

Coefficient Value Testers

0

-0.516*

-0.194

-0.404*

-0.307

-----

Architects

0.069*

Managers

0.291

0.175

Developers

0.053*

0.345

0.356

Project Managers

0.151

0.247

0.356

0.321

Contributing

Testers

Architects

Managers

Developers

-------

Project Managers

Coefficient Value Testers

0

-0.015

-0.268

-0.511**

-0.456*

---

Architects

0.479

---

Managers

0.179

0.195

Developers

0.007***

0.019**

0.163

Project Managers

0.073*

0.092*

0.289

Releasing

Testers

Architects

---

Managers

--0.42

Developers

---

Project Managers

Coefficient Value Testers

0

-0.572**

-1.002***

-0.752***

-0.920**

-----

Architects

0.032**

Managers

0.001***

0.093*

Developers

0.000***

0.229

0.174

Project Managers

0.01**

0.198

0.423

----0.319

---

* significant at 10%; ** significant at 5%; *** significant at 1% Table 28: Ordered probit post-estimation: test of equality of coefficients (one-sided p-values)

The first box of Table 28, regarding attitudes towards using OSS, shows significant differences between testers and developers (H2[TD]), but no support for other hypo-

118

Bottom-up Adoption of OSS

theses, indicating that the differences found to be significant in Table 26 are mostly accounted for by characteristics other than job function. For contributing to public OSS projects, significant differences are found between the job functions of developer/project manager and architect/tester, which supports H2[TD] and H5[AD] as well as H3[TP] and H6[AP]. This finding is consistent with the univariate analysis presented above. In addition, the coefficient describing the difference to testers is larger for developers than for any other group. Hence, performing the job function of developer has, ceteris paribus (i.e., after correcting for characteristics potentially correlated with it), an even more negative effect on attitude towards contributing than is suggested by the univariate analysis. For releasing software as OSS, there are significant differences between testers on the one hand and managers, developers, and project managers on the other, providing support for H1[TM], H2[TD], and H3[TD]. Significant difference can also be observed between architects and managers (H4[AM]). Thus, the differences in attitudes towards corporate OSS engagement are found between the five groups defined by job function can be explained only partly by other characteristics of the respondents. In particular, in four out of six pairwise comparisons the job function of developer implies, ceteris paribus, significantly lower support for corporate OSS engagement than the job function of architect or tester.

4.5.3 Control Variables Compatibility. Both variables indicating compatibility are highly significant in all regressions. I find that identification with the OSS community is especially influential for using OSS, where it actually carries the highest coefficient value of all variables. The variable is also strongly significant in the other two regressions. This high relative importance of compatibility can be interpreted in two ways: (1) as a measure of trust in the solutions offered by the OSS community and their quality based on factual experience with OSS and the OSS community, which will especially apply to using OSS. (2) In particular with respect to releasing proprietary software as OSS, this might also be considered a statement of allegiance to the hacker92 community, that is, individuals see themselves as members of the hacker community rather than as members of the organization they are working for.93 92 93

For a definition of “hacker,” please see Footnote 15. As an indication for this, including a composite variable measuring individuals’ identification with their employer and current project group in the regression on releasing proprietary software as OSS, this variable is strongly significant (p=0.02) and the coefficient carries a negative sign. The coefficient for identification with the OSS community remains positive and significant in the same regression.

Bottom-up Adoption of OSS

119

As using OSS is already being done in the company analyzed, I think that the first interpretation is the more relevant one. Individuals having positive experiences with for example support provided by the OSS community will show a higher level of identification with the OSS community while still acting in their employers’ best interest (Henkel, 2008). With continuous interaction, identification with the OSS community is likely to further increase, but this will happen in addition to, not instead of, individuals’ identification with their employer (e.g., Ashforth & Mael, 1989; Hogg & Terry, 2000). The second point, however, must not be neglected, as it might suggest that some individuals actually want to become OSS developers for themselves. While this is further indication that a selected pool of individuals would readily self-select into corporate OSS efforts, the company will have to ensure that those individuals will continue to work in the best interest of the firm. Those individuals who do not want to engage in OSS efforts themselves, too, are influenced by compatibility as well, may it be in a more ethical sense: reciprocity, defined here as the moral obligation of the corporation to give back to the OSS community after having received so much from it, is a positive and strongly significant driver of people’s attitude towards corporate OSS engagement. That is, even if people themselves do not want to work on projects in which proprietary software is released to the public, they might feel that the corporation is morally obliged to do so, indicating that those individuals might be supportive of the company’s OSS efforts as long as they do not have to actively participate in them. Organizational characteristics. Surprisingly, organizational factors do not seem to exhibit an effect on people’s attitude towards OSS engagement. Even when separating the individual items comprising this factor, no significant effects can be found. There may be two reasons for this. First of all, the interviews showed that, so far, it is mainly an individual decision whether to work with OSS or not, and the environment might not exhibit any significant effect on this. Second—and more likely—the normative information whether an individuals’ peers or supervisor are supportive of OSS or not is less important to the individual than the effect OSS has on the individual and his or her job function within the firm. The latter, in particular, would again confirm the decision to deviate from the original TAM. Individual characteristics. As expected, individuals who have previously worked on OSS are found to be more favorably disposed towards further corporate engagement. Yet, a positive effect is only seen for using and contributing, but no effect for releasing is found. Again, a likely explanation is that the advantages perceived in using and contributing are perceived and further reinforced when employees themselves have been

120

Bottom-up Adoption of OSS

working on OSS. For releasing, too, they may have learned about the advantages but they also have a better understanding of the organizational change inherent in this mode of corporate OSS engagement, that is, only for this mode they perceive significant personal disadvantages, rendering the overall effect insignificant. Age has a strongly significant and negative effect in the regressions for contributing and revealing. There is no effect for using OSS most likely because it is already widely done in the corporation and because it is to some degree similar to regular software (component) re-use, something that workers of all age should be familiar with in a software developing firm. Freely revealing your own knowledge, however, as is done both with contributing and releasing, is a rather new phenomenon in software development. The finding that younger persons are more likely to perceive such behavior to be beneficial to the firm is in line with interviewees’ statements that university training in IT used to value conventional PCSS model of software development much higher, and only in the last decade or two, development styles heavily relying on sharing source code have begun to spread. Of course, this comes as no surprise, as both Linux and the OSS movement were only initiated in the early and late 1990s, respectively, and younger employees will have “grown up” together with them. Older developers, however, will be more likely to be unfamiliar with these phenomena, and, thus, more likely to resist the change exhibited by them (Kotter & Schlesinger, 1979). Somewhat surprisingly, the constructs derived from the KAI index matter little; even joint insignificance cannot be rejected for any of the three regressions. Even though the coefficients carry the expected sign, this is not enough to deduce that innovativeness or its respective subscales have an impact on the attitude towards corporate OSS engagement. However, the explanation as to why there is no significant impact may reside in the selection of the dependent variable from the TAM: personal innovativeness might have less of an impact on the attitude towards the behavior, but rather towards the actual behavior, that is, it acts a multiplicator of attitude, not as an influence factor. This seems indeed to be the case, as is indicated in the next section.

4.5.4 Further Results Complementing the questions on attitudes towards corporate OSS engagement, participants were prompted to name up to three current products or projects of the company as candidates for a release as OSS, specify their level of familiarity with the product, and indicate why and how they thought that revealing would bring value to the compa-

Bottom-up Adoption of OSS

121

ny. Since respondents were aware that these suggestions were of real interest to the corporation, naming release candidates constitutes an act of lobbying for OSS engagement. Even if it is a small step, it goes beyond indicating one’s attitude. In these answers, I would then again look for differences based on the individual’s job function by testing whether the hypotheses from 4.3.3 would also hold with respect to naming release candidates. Overall, 52 out of the 249 respondents (20.9%) made suggestions, architects being overrepresented and project managers and developers underrepresented (see Table 29). In fact, the Mann-Whitney test shows that on a univariate basis, architects made significantly more suggestions than all other groups while developers made significantly fewer suggestions than all other groups but project managers (see Table 30).

Variable

Testers

Made Suggestion of Pro-

27.0%

Archi-

Man-

Deve-

Project

tects

agers

lopers

Mgrs.

47.8%

25.9%

15.0%

11.1%

Overall

27.0%

prietary Software Product to be Released as OSS (1: Yes, 0: No) Table 29: Descriptive statistics for suggestions made

Suggestions Made

Testers

Architects

Managers Developers

Project Managers

Mean

27.0%

Testers

---

47.8%

25.9%

15.0%

11.1%

---

Architects

0.052*

Managers

0.461

0.056*

Developers

0.042**

0.000***

0.081*

Project Mgrs

0.16

0.029**

0.181

----0.374

---

* significant at 10%; ** significant at 5%; *** significant at 1%. Table 30: Mann-Whitney test on differences in medians (one-sided p-values) for suggestions made

122

Bottom-up Adoption of OSS Suggestions made (1: Yes, 0: No)

Job Architect

0.272

(0.376)

Job Manager

-0.157

(0.382)

Job Developer

-0.541**

(0.266)

Job Project Manager

-0.544

(0.633)

Identification with OSS community

0.130

(0.140)

Reciprocity

0.400**

(0.168)

Organizational factors

0.008

(0.151)

Did OSS

-0.010

(0.198)

KAI Originality

0.274

(0.167)

KAI Efficiency

-0.070

(0.164)

KAI Conformity

0.362**

(0.168)

Age

0.007

(0.011)

Constant

-4.581***

Observations Pseudo-R

(1.307)

249

2

0.14

Pseudo Likelihood

-109.802

Wald's chi-squared

29.540

Degrees of freedom

237

* significant at 10%; ** significant at 5%; *** significant at 1%; robust standard errors in parentheses Table 31: Results of the probit regression (suggestions made)

Suggestions Made

Testers

Architects

Managers

Developers

Project Managers

Coefficient Value Testers

0

0.272

-0.157

-0.541**

-0.544

---

Architects

0.235

---

Managers

0.341

0.141

Developers

0.021**

0.006***

0.118

Project Managers

0.195

0.113

0.278

----0.498

* significant at 10%; ** significant at 5%; *** significant at 1% Table 32: Probit post-estimation: test of equality of coefficients (one-sided p-values)

---

Bottom-up Adoption of OSS

123

When conducting a probit analysis under the same constraints as for respondents’ attitude towards corporate engagement in OSS, I find that some of the differences found in the univariate analysis still hold, while others are explained by other factors (see Tables 31, 32). Most notably, developers suggest significantly fewer candidates for revealing than testers and architects. The differences between developers and managers and architects and projects managers just fail to meet the 10% level of significance. Being a developer leads, ceteris paribus, to a significantly lower likelihood that this person makes suggestions for revealing proprietary software than being an architect or a tester. Regarding the other variables influencing whether a survey participant made suggestion for software suitable to be released under an OSS license, reciprocity is again found to be a major driver, confirming the impressions from the previous section. More importantly, however, the KAI has a significant impact on the number of suggestions made. Joint insignificance is clearly rejected (p=0.07), and, individually, the originality scale just misses the 10% level of significance (p=0.10), whereas the conformity scale is significant on the 5% level (p=0.03).94 This may be taken as another indicator in favor of an earlier comment stating that innovativeness would have a stronger effect on behavior than attitude. Additionally, the significance—or almost-significance—of these two KAI inventories might suggest that those people who made suggestions would also be both willing and well-suited to act as process promotors or champions (see also Section 4.8.3) for corporate OSS efforts: both the ability to work with new ideas (originality) and the willingness to go against organizational structures and hierarchies (conformity) are key characteristics needed to become a successful process promotor or champion (Howell & Higgins, 1990; Howell & Shea, 2006; Kirton, 1976, 2003; Witte, 1973).

4.6 Discussion and Implications The main findings of this chapter regarding the impact of respondents’ job functions are consistent with theoretical considerations, yet still rather surprising. Among developers, software testers, software architects, project managers, and managers, software testers are generally most favorably disposed to increasing corporate involvement in OSS activities, followed by software architects and managers. Excepting the (small)

94

P-values reported in this sentence are two-sided, as no hypotheses were set up to measure the effect of the KAI inventories. Had hypotheses been set up, these would have projected a positive effect of the KAI conformity and the KAI originality scale (see also Section 4.4.5).

124

Bottom-up Adoption of OSS

group of project managers, developers, despite having the most experience with OSS, were the least favorably disposed to greater corporate engagement. Since developers represent both the basic level of software development and the largest of the studied groups, the results challenge anecdotal evidence that OSS adoption, at least when it goes beyond the use of existing OSS, is generally driven by a broadly supported grassroots movement. This finding has consequences for companies’ management of OSS engagement. Given a 46% probability that a randomly selected developer from the sample is neutral (26%) or even unfavorably disposed (20%) towards releasing proprietary software as OSS, developers should probably be given the opportunity to self-select into OSS-related projects. I can make the same recommendation for project managers and, more generally, that in the context of corporate OSS engagement, the job function-related incentives of each affected individual need to be considered. IT professionals are nevertheless, on average, “somewhat” positive about their employer increasing its OSS activities. Differentiating by type of activity, “using existing OSS more often” is found to be most strongly supported, followed by “contributing to OSS projects” and “releasing proprietary software as OSS.” A favorable disposition to all types of OSS activity is strongly dependent on, apart from an individual’s job function, prior exposure to OSS, identification with the OSS community, acceptance of reciprocity norms, and age.

4.6.1 Job Functions and OSS Adoption In this chapter, a model linking individuals’ attitudes towards commercial OSS adoption, for various types of OSS engagement, to their job function was tested and developed. On an aggregate level, corporate OSS engagement was found to be viewed at least “somewhat” positively by most of the people in the company studied. With respect to type of OSS engagement, I find that using existing OSS more often is seen by a majority of respondents (85% agreed “somewhat” or “strongly”) as potentially beneficial to the company. For more intense types of engagement, agreement decreases: contributing to OSS projects is seen as advantageous by 70% of respondents, releasing proprietary software as OSS by only 56%. At the same time, the variance of the agreement level goes up, reflecting the higher perceived uncertainty and risk associated with more intense types of OSS engagement.

Bottom-up Adoption of OSS

125

To understand how OSS fits into corporate software development processes, however, an even more differentiated view is required that takes into account, in addition to the type of OSS engagement, an individual’s job function. Attitudes towards OSS are influenced by the fact that engaging in OSS projects and releasing proprietary software as OSS represent, to varying degrees for different job functions, a significant deviation from ingrained routine. Guided by the theoretical frameworks of TAM and DOI and based on an analysis of the advantages and drawbacks of OSS engagement for each job function, the theoretical framework presented in this chapter predicts that testers and architects would be the most favorably disposed to OSS, managers and developers less so, and project managers the least. The empirically revealed differences between job functions are in line with the hypotheses, and turn out to be significant in half of all pairwise comparisons. In particular, developers were found, in 8 out of 12 cases, both accounting and not accounting for other individual characteristics, to be significantly less favorably disposed to OSS than either architects or testers. For developers, OSS seems to approximate what Lyytinen and Rose (2003) term a “disruptive IT innovation.” The inherent organizational change thus disposes developers, on average, to react less than enthusiastically to increased corporate commitment to OSS.95 Generally, the more OSS development differs from the current development model and the less skilled developers consider themselves to be,96 the less supportive they will be. Three quotes from the interviews I conducted illustrate the changes OSS engagement occasions, in particular, for developers. “Yes, I think documentation is an important prerequisite [for making software public as OSS] that we are currently not yet meeting.” (Translated from German by the author) “Following the license is somewhat hard […]. That takes a lot of effort and people don’t really know what to do.” “[Among developers] there is a not-invented-here syndrome, you know, that people feel they need to build on [their] own developments.” (Translated from German by the author)

The findings described in this chapter seem at odds with anecdotal evidence of developers’ supposedly positive attitude towards OSS. Most likely, this evidence relates to individual developers who advocated or perhaps even launched isolated OSS efforts in their firms. Although such efforts do affect corporate OSS adoption, serious corporate 95

96

This finding must be seen in light of the given corporate environment, in which OSS does not play a central role. Henkel (2008), in contrast, studies firms, many of which are rather small and young, active in or even dedicated to the development of embedded Linux. In his sample of 197 commercial OSS developers, 49.7% of respondents stated that they either make suggestions to their supervisor as to what code could be released or even that this decision is within their own discretion. Interviewees consistently indicated the share of developers with the necessary skills (programming, social, and management) to work in a corporate OSS project to be around 25%.

126

Bottom-up Adoption of OSS

engagement relies on championing and sponsoring efforts (Chakrabarti & O'Keefe, 1977; Hauschildt & Chakrabarti, 1989; Hauschildt & Kirchmann, 2001; Howell & Higgins, 1990; Markham, Green, & Basu, 1991; Rothwell, Freeman, Horlsey, Jervis, Robertson, & Townsend, 1974). The project managers who would seem, due to their boundary-spanning role, to be ideally suited to act as champions turn out to be the least favorably disposed towards OSS. Based on the analysis of the job-specific pros and cons of OSS, solutions to this dilemma are suggested below. This chapter shows parallels to findings by Sherif et al. (2006) that similar conflicts arise for developers in software reuse, for which they suggest as a solution management intervention. Fichman and Kemerer’s (1993) earlier reported slow adoption of software reuse practices by developers was later found by Kim and Stohr (1998) to be caused by lack of (mandatory) organizational support (including required resources, training, and rewards) and difficulty measuring economic impact. This chapter has shown that similar issues arise with OSS. However, only “using existing OSS” is closely related to software reuse. Higher levels of corporate OSS engagement differ qualitatively inasmuch as they imply active co-development beyond firm boundaries, interaction with a community lacking clear hierarchies and line authority, and organizational change within the focal firm. I further suggest that the results of this chapter are not limited to the context of OSS, that they have broader implications. The segmentation of roles according to a designbuild-test cycle is not unique to the software development industry (Wheelwright & Clark, 1994). Comparable open and distributed innovation efforts in other industries (Chesbrough, 2003) are thus likely to face similar challenges and even resistance from the respective counterparts of developers and project managers. Finally, the results of this chapter suggest an extension of existing theory and avenues for further research. As Venkatesh (2006) has suggested, models that predict the adoption of IT innovations should take into account an individual’s job function, or, phrased more generally, the way in which the adopter interacts with the innovation at hand. Job function will strongly influence an individual’s perception of and attitude towards an innovation, and will be an important, even decisive, factor in an individual’s adoption decision. Especially in cases in which innovations significantly affect existing processes, the moderating effect of job function cannot be ignored. Recent extensions of the TAM and similar models (Venkatesh & Davis, 2000; Venkatesh, Morris, Davis, & Davis, 2003) include items that measure the job relevance of an innovation; extending

Bottom-up Adoption of OSS

127

the extensions by explicitly including job function could further increase their applicability.

4.6.2 Limitations and Possible Extensions Some limitations of this study need to be mentioned. First, it was conducted within a single firm. This has the advantage of simplifying comparisons between respondents because firm-specific effects are kept constant. But the level of support for OSS engagement might be higher or lower in other corporations depending on corporate culture, previous exposure to OSS, industry (Klevorick, Levin, Nelson, & Winter, 1995), and home country. Differences in attitudes towards OSS among testers, developers, and others, however, result from the professional activities of these groups, which should be largely independent of firm or location. Hence, I am confident that the findings regarding the impact of job function reported herein generally hold. As the respondents were located in seven countries, I was able to check for national idiosyncrasies, but found no significant differences between countries. Still, conducting a similar study in different countries, in one or more other firms, possibly in different industries, could provide valuable insights. Finally, the firm’s software development method might have influenced the results. At the time of the survey, the firm studied was still relying heavily on the waterfall model. Agile software development had been introduced early in 2005, but was not yet being widely used. Consequently, OSS represents to developers in this firm an entirely new model of software development. Developers in firms that have experience in extreme programming, agile methodologies, or the spiral model should thus be more favorably disposed towards OSS development.

4.7 Exploratory Cluster Analysis In addition to regression analysis, I also conducted exploratory cluster analysis to confirm the validity of the above findings and to potentially identify additional structures in the data that were not reflected in the hypotheses. For this, I clustered the data based on the factors reciprocity, relative advantage, perceived personal benefits, and perceived corporate benefits. I then analyzed the individual clusters and the differences between them with respect to the questions whether clusters where at all attainable, how different job functions would spread over the different clusters, whether innovators

128

Bottom-up Adoption of OSS

and laggards could be identified (Rogers, 2003), what kind of influence other variables had, and what could be said about promoting behavior.

4.7.1 Clustering Variables Clustering was done based on four factors.97 The factor reciprocity was identical to the three-item one used in the regressions. In the following, the three new clustering variables will be introduced. Table 33 lists all questions underlying the four factors. Perceived Corporate Benefits. Perceived corporate benefits encompass the advantages an employee expects to result for the corporation from increased engagement in OSS. For use of OSS, this will mainly be reduced vendor lock-in, shorter time-tomarket, and higher quality and performance (Goldman & Gabriel, 2005; Hecker, 1999; Raymond, 2001b). Contributing code to existing projects may bring benefit to the company from both a technical and a marketing point of view. Technically, the company may influence the standard version of the software, thereby eliminating the need to redo the changes for each update of the OSS and take into account possible incompatibilities, new security issues, etc. Furthermore, this may lead to others making improvements to the company’s contribution, culminating in the software becoming a standard. From a marketing point of view, contributing to the OSS world will increase the company’s reputation and visibility as a software developing company—an issue that is especially important to companies whose core business is not software development but who nevertheless need skilled developers (Behlendorf, 1999; Hecker, 1999; Henkel, 2004b; Koenig, 2004; Raymond, 2001a, 2001b; Seel, 2006). Releasing proprietary software as OSS increases the advantages already possible in contributing (Goldman & Gabriel, 2005; Lakhani & von Hippel, 2003; Shah, 2006). Furthermore, the company may increase its competitiveness by engaging in new business models, such as the sale of complementary goods or services, or by commoditizing a certain layer of the software architecture to shift competition to another area where the company is stronger (Raymond, 2001a; West, 2003).

97

This section only addresses the variables used for cluster analysis. The method is described in the next section.

Bottom-up Adoption of OSS

129

Perceived Corporate Benefits I think [FIRM] could benefit from revealing because … … others develop the code further and reveal their developments in turn … other developers make bugfixes and reveal them … our own development should fast become the standard (i.e. be widely adopted) … this way, our products stay compatible to other products … it reduces our maintenance effort when the code becomes part of the standard distribution (e.g. Tomcat) … others add functionality that we did not anticipate Perceived Personal Benefits I would reveal code because … … I get feedback on my code, which improves my personal skills … I get feedback on my code, which improves my performance at my current job … I get recognition in the open source community for my contributions … it demonstrates my skills Relative Advantage The source code of OSS is usually more aesthetic than that of proprietary software Users of software should have the right to see the source code Open Source development is the most efficient way to develop software

Reciprocity [FIRM] has an obligation of giving back to the OSS community I would release code because I consider it fair to give back to the community, since the company benefits from it I would release code because in the long run, you only get something when you gave something before Table 33: Questions underlying factors in cluster analysis

130

Bottom-up Adoption of OSS Perceived Personal Benefits. People should have more a positive view of engaging

in OSS when they feel that this will improve their work performance at work (Davis, 1989). Also the promise of external rewards may motivate individuals to contribute to OSS. By writing good source code, they could advertise themselves on the job market. Their ego might also play a role: by showing their superior programming solutions to the public they might hope for fame and peer recognition in the OSS community. Many individual contributors will also be looking for feedback on their source code, thereby improving their programming skills (Hars & Ou, 2002; Lakhani & Wolf, 2005; Lerner & Tirole, 2002). Relative advantage. When directly compared to proprietary closed source software and proprietary closed source software development, OSS has often been claimed to be more aesthetic and OSS development to be more efficient (Bonaccorsi & Rossi, 2003). While this issue will not be debated here, individuals who agree to this point of view should also have a more positive view on the usefulness of OSS in general. Also, the possibility given by OSS to modify the source code should positively affect this view.

Age 1, 2

KAI Originality1, 3

Relative Adv. 1

4.40

4.17

36.5

9.5

63.9%

3.88

3.58 3.81

4.20

3.76

35.1

9.9

37.4%

3.93

G3 44

10.9%

3.60 3.78

3.18

3.07

37.5

12.5

38.0%

4.06

G2 98

24.3%

3.45 3.31

3.91

3.33

42.5

15.0

27.1%

3.80

G1 112 27.7%

2.98 3.30

3.46

3.00

42.4

14.3

33.8%

3.75

G4 23

2.40 2.61

2.27

2.00

42.7

17.2

29.0%

3.77

5.7%

Clustering criteria 1

2

mean value for respective cluster in years Highest value per column bolded, lowest in italics

Tenure 1, 2

Reciprocity1

3.96 4.04

15.1%

Pers. Benefits1

Corp. Benefits1

16.3%

G6 61

N

G5 66

Cluster ID

% of Sample Pop.

Shared w. outsider

4.7.2 Method and Results

Resulting cluster characteristics 3

1-5 scale

Table 34: Cluster summary (ordered by average rank of the two benefit measures)

Multicollinearity was avoided by subjecting the 16 items to factor analysis and using the factor scores after rotation. All items loaded more strongly than 0.57 on the hy-

Bottom-up Adoption of OSS

131

pothesized factor, and lower than 0.37 on any other (Hair, Black, Babin, Anderson, & Tatham, 2005). Confirmatory factor analysis was further applied to validate the structure of the factors (Ketchen & Shook, 1996). Ward’s method has been reviewed to produce the most reliable results in hierarchical cluster analysis (Bergs, 1981; Calinski & Harabasz, 1974; Ketchen & Shook, 1996; Milligan & Cooper, 1985). Stopping rules by Calinski and Harabasz (1974) and Duda and Hart (1973) suggested the existence of six clusters. Sorting the resulting six clusters by the personal and corporate benefit measures (summed score of “corporate benefits” and “personal benefits” cluster scores) rendered the order depicted in Table 34. Results of cluster analysis were confirmed through a partitioning clustering method, split sample validation, and discriminant analysis.98 H-statistics99 showed significant differences for the view on personal and corporate benefits of OSS, relative advantage, familiarity with OSS, identification with OSS vs. the firm or the current project, age, and tenure between the clusters.

4.7.3 Interpretation In order to be able to compare the outcomes of the cluster analysis to that of the regression analyses, the clusters were sorted in descending order by their aggregate rating of the personal and corporate benefits of OSS, assuming that this would correspond to innovator-like and laggard-like behavior with respect to OSS adoption. Conducting an ordered probit regression, results indicate that more exchange with the outside (p=0.027) and a higher KAI originality score (p=0.007) have a significant effect on people moving towards the more innovator-like clusters, whereas people from more laggard-like clusters are significantly older (p=0.000). Taking a quick glance at the clusters at the top and the bottom of the ranking, interestingly, people in cluster G5 had shared information on a programming problem with someone outside the company almost twice as often as people from any other cluster. People in cluster G4 were, on average, the only group to consistently value all aspects of OSS negatively. KAI scores were consistently but not significantly lower than those 98

99

In addition to the hierarchical cluster analysis, a program was written that compared the outcome of the hierarchical cluster analysis to that of 1,000 partitioning cluster analyses (the latter of course set to identify six clusters). Cohen’s kappa was highly significant (Z=0.00) suggesting that the results from hierarchical cluster analysis and portioning cluster analysis are similar, and that this similarity is not occurring by chance. Similar tests were conducted by splitting the sample in half and comparing the results of a hierarchical cluster analysis conducted as described in the text to the results of the other half, of the total sample, and of partitioning cluster analysis. For discriminant analysis, Wilk’s lambda was significant on a 0.1% level indicating clear differences between the clusters with respect to the clustering variables. Kruskal-Wallis equality-of-populations rank test was used.

132

Bottom-up Adoption of OSS

of the other groups. Also, the rate of college graduates was significantly lower in this cluster. This, taken together with the observation on the negative effect of a higher age and its connection to changes in computer science syllabi reported earlier, relates to my previous statement on more advanced skill or additional training being required for work on and with OSS, indicating that people falling into cluster G4 might value OSS negatively because they lack precisely these skills. Applying a technique from marketing practice (for academic use, see e.g., Unger & Frese, 2005) to the results of cluster analysis illustrates the differences between the six distinct groups of people with respect to their attitude towards OSS. For this, for each clustering variable i, the difference of the cluster mean for cluster j x ij minus the sample mean x i is divided by 0.5 times the standard deviation i of clustering variable i: The truncated result gij is replaced by the corresponding number of pluses if positive, or minuses if negative. From this, an illustrative name is derived to describe the unique characteristics of each cluster. 100 Table 35 again clearly indicates that the clusters significantly differ with respect to the clustering variables.

 x xi   g ij  truncate  ij  0.5  σ i   

ID

Corporate Personal benefit

for variable i, cluster j

Reciprocity Relative

benefit

Equation 6: Illustrating cluster differences

Cluster Title101

Advantage

G5 ++

+

++

++

Innovators

G6 o

+

+

+

Early Adopters #1

G3 +

+

-

o

Early Adopters #2

G2 o

-

o

o

Early Majority

G1 --

o

-

-

Late Majority

G4 ---

---

---

---

Laggards

N times +/- symbolizes that cluster mean lies n times 0.5 standard deviations above/below sample mean Table 35: Analysis of motivations in favor of OSS in the clusters

100

101

Usually, this method is applied to identify and characterize significantly different consumer groups in a market. The method used here is identical to the approach used by TNS Infratest, amongst others. Cluster titles were chosen to mirror the adopter groups identified by Rogers (2003) to describe expected adoption behavior towards corporate OSS engagement.

Bottom-up Adoption of OSS

133

To look for similarities and differences between regression and cluster analysis and to learn more about the potential existence of promotors of corporate OSS efforts, I then looked into which job functions would be overrepresented or underrepresented in the different clusters. For cluster G5, all factors are above average as would be expected of innovators according to the definition of Rogers (2003). Testers are slightly overrepresented in this group (t-test: p=0.099). Early Adopters #1 share the positive view on OSS from a personal point of view. They also more than average agree with the idea of reciprocity and the relative advantage of OSS over PCSS. However, they do not have a more positive view than the mean on potential corporate benefits of OSS. Overall, members of this group might be expected to already be active in OSS, but rather privately than as part of their job. Managers are significantly underrepresented in this cluster (t-test: p=0.054). Early Adopters #2 see both above average corporate and personal benefit in OSS. However, they see below average reason to adhere to the norm of reciprocity. This could indicate that members of this group want to benefit from OSS both privately and as a member of the organization, but without actively giving back to the OSS community. Managers are significantly overrepresented in this cluster (t-test: p=0.024). Members of the Early Majority are mostly neutral towards OSS, and only differ from their peers in that they see less personal benefits coming from OSS. No overrepresentations or underrepresentations are to be found in this cluster. The fifth group, the Late Majority, yet feels that OSS, the corresponding development method, and the associated reciprocity norm do not fit into a corporate environment and consequently value all respective attributes more negatively than their peers. No overrepresentations or underrepresentations are to be found in this cluster. Laggards at the other end of the scale share a consistently negative view of OSS. Both project managers (t-test: p=0.073) and, surprisingly, programmers (t-test: p=0.080) are overrepresented while testers (t-test: p=0.076) and software architects (t-test: p=0.081) are underrepresented in this group. Looking at the distribution of job functions over the six clusters, there are obvious similarities to the regression results, which had stated testers and architects to be more positive towards corporate OSS engagement than managers, who were again more positive than project managers and programmers. In particular, testers are overrepresented in the Innovator cluster, whereas project managers and programmers are overrepresented in the Laggard cluster.

134

Bottom-up Adoption of OSS Regarding promoting behavior, t-tests suggested that managers and project manag-

ers were more likely to fall into clusters closer to the laggard-like end of the scale. Interview results confirmed these findings: especially for project management, OSS in the first place means additional work—to be completed on top of the usual tasks without additional resources and adhering to the existing time constraints. Together with the fact that people from the Innovator cluster G5 were amongst the youngest and, in addition, many of the individuals in this group worked at peripheral sites with little relationship to the strategic decision-making of the organization, this may be considered an indication for a lack of power promotors, that is, people in middle or higher management that back OSS and OSS-related projects and help to commit resources to these efforts. A lack of power and, as found in Section 4.6.1, process promotors, however, inhibits the further diffusion of this new way of software development.

4.7.4 Implications The exploratory cluster analysis suggests the existence of six distinct clusters that are structured similarly to the ranking found in the regression analysis with respect to the representation of different job functions amongst the clusters. Most importantly, the only group found to outright rejecting OSS, G4, is also the smallest one, making up less than 6% of the total sample. The largest group of the sample, G1, is yet undecided about the commercial advantages of OSS; together with G4, those two groups make up approximately one third of the sample. The remaining groups are positive in their absolute valuation of the corporate benefits and at least neutral with respect to the other categories. One exception is G3 the group which shows a below-average valuation of reciprocity. This effect is most likely explained by the fact that managers are overrepresented in this group. Overall, the exploratory cluster analysis has shed some more light on the details of the differences between the individual groups. New important findings significantly extending those of the multivariate analysis, however, could not be made.

4.8 Conclusions When employees do not know about the possible benefits OSS might have, they will not be able to process information on business opportunities optimally and consequently undervalue the potential OSS might have for the corporation. Yet, in order for them to support management efforts to introduce or increase corporate OSS engagement, or to

Bottom-up Adoption of OSS

135

lobby for such actions, they should have an understanding of the advantages that come with OSS and how the firm might benefit from those while avoiding to fall victim to possible downsides. The ability to reap personal or corporate benefits of increased OSS commitment of their employer will then most likely decide whether employees resist or support a top-down management initiative, and whether they may actively promote and advance or oppose corporate OSS engagement in a bottom-up fashion.

4.8.1 Introduction of OSS to the Corporation As shown in previous chapters, the advantages of OSS can easily outweigh the disadvantages. However, this analysis mainly focused on technical and business issues, and might not have paid enough attention to social issues. Many if not most employees will be new to OSS development and consequently unfamiliar with its development method.102 Introducing OSS and OSS development implies changes, in particular for developers and project managers, precisely the groups that turned out to be least favorably disposed to OSS. Possible steps towards solving this dilemma include training and stepby-step introduction of corporate OSS engagement, that is, generally speaking, education and communication (Kotter & Schlesinger, 1979). Training programs should be established for new hires and advanced training programs for developers, managers, and IP and legal staff. One might also consider brownbag seminars for developers, incorporating the open source policy in employee handbooks, and online seminars or training (Fan, Aitken, & Koenig, 2004). This is explained in more detail in the benchmark on OSS processes in Section 5.1. Training and increasing their OSS exposure step-by-step could help in teaching employees to work with OSS. Joining an existing OSS project should also provide a great learning experience. But considering that some people might be resistant or at least skeptical towards OSS development or even OSS in general, this way of teaching might simply overstrain their willingness to learn and adopt. A viable alternative—and one that has been suggested or even demanded by many survey and interview participants— could be the introduction of a “corporate source program” (Dinkelacker, Garg, Miller, & Nelson, 2001). Corporate source initiatives that mimic the OSS development style within the boundaries of an organization might be a good way to familiarize staff with the OSS development style while minimizing risks with respect to loss of intellectual

102

An indication for this might be the following: 59% of survey participants had never worked on OSS source code before. The majority of these people said that this was due to time constraints and lack of training.

136

Bottom-up Adoption of OSS

property and sociological issues such as the not-invented-here syndrome. The corporate source approach will be briefly explained in the next section. Finally, individuals should be given the opportunity to self-select into OSS-related activities. Even among project managers, the most skeptical group towards OSS, one third of the respondents considered an OSS engagement on all three levels as “somewhat” beneficial for the corporation. Hence, it should well be possible to staff pilot OSS projects, in all job functions that are required, with OSS supporters. A way to identify these people could be to identify those employees who have made suggestions as to which proprietary software might be released as OSS. These people could also take the position of change agents for OSS who would further reduce organizational resistance, as will be explained in Section 4.8.3.

4.8.2 Corporate Source Corporate source is the application of the OSS development method within corporate boundaries—without any users or contributors from outside the company. The goal of this approach is to bring the advantages of the OSS model as described above to the company while minimizing or eliminating the downsides such as the loss of intellectual property. From a sociological point of view, it is also a means to acquaint people with OSS in a safe environment which should help a lot to reduce skepticism. If successful, this step might be followed by starting to do “real” OSS. The main disadvantage of the corporate source approach is that one purposefully puts a limit on the number of possible users of and contributors to the software, namely the number of programmers working for the company. The larger the company is, however, the more the corporate source approach will resemble “real” OSS and the greater the possible benefits will be. For example, in a multinational corporation with several large divisions, it is not unlikely that coding standards may differ or that two or more divisions might be working on similar problems, the solutions to which might well be reusable. With corporate source, developers have a central code repository where they can check whether the functionality they need has already been implemented before. Not only that, they can also contact the authors of the software easily to coordinate bugfixes, additions, and further development. Using a corporate source approach will consequently increase interoperability and compatibility and free up resources for other

Bottom-up Adoption of OSS

137

tasks, thus decreasing development costs while increasing overall product quality (Dinkelacker et al., 2001; Goldman & Gabriel, 2005). It is also worth noting that individuals’ motivation to participate in a corporate source model might, but does not necessarily have to differ from that in OSS development. By setting it up properly so that participation is more or less required to reach development, project, and business goals, adoption of and participation in a corporate source environment can be maximized. Furthermore, training on different topics of shared development, including tools for collaborative development, but also community development, should be offered and their use encouraged to all employees, programmers and managers alike (Dinkelacker et al., 2001). Another alternative to corporate source and OSS has become well-known through Microsoft’s Shared Source program. This can be considered an intermediate step between corporate source and OSS: it is corporate source plus a selected few outside contributors—in the case of Microsoft, those are universities and key software and hardware suppliers. Just as with corporate source, shared source efforts try to reap the benefits of the OSS development methodology while still selling a closed-source product in most cases. Since Shared Source, Microsoft has expanded its OSS engagement as can be seen by the release of the Windows CE 6.0 source code to licensees, 103 the Microsoft Linux/OSS lab,104 CodePlex (Microsoft’s community development website),105 and Microsoft’s newly launched open source website.106 In addition, two shared source licenses now meet the standards of both FSF and OSI, and have been entered into the OSI approval process to officially become OSS licenses. They have been accepted by the OSI in October 2007. Removing the limitation on the number of potential contributors but retaining tight control over the source code, the resulting approach a firm might follow has been described as “gated source” or “gated community” (Shah, 2006). The resulting projects are fully-fledged OSS projects, but only the corporation leading the project has a say in what becomes part of the source code and what not. This restriction, as well as the fact that the source code is actually owned by a corporation rather than a community, might, however, exhibit negative effects on participants’ motivation to contribute (Shah, 2006). The gated source approach might be a prerequisite for companies that plan on releasing 103

104 105 106

Licensees of Windows CE 6.0 are granted access to the full kernel source code and permitted to modify it and share the modified code with other licensees See http://msdn2.microsoft.com/en-us/embedded/aa714518.aspx, retrieved May 23, 2007. http://port25.technet.com, retrieved July 7, 2006. http://www.codeplex.com, retrieved July 7, 2006. http://www.microsoft.com/opensource, retrieved October 8, 2007.

138

Bottom-up Adoption of OSS

the software using a dual licensing model (see also Section 2.4.3), as actual code ownership is often a central requirement for firms following this business model.

4.8.3 Need for Change Agents “In most cases the middle management does not have the luxury of being innovative or bright— they just need to get the products out. The middle management is under heavy workload, with unrealistic release schedules, managing primadonna engineers. These middle managers never initiate change or generate new ideas because they are too busy running arons. So the change never starts from the middle. So I’ve come to the conclusion that you need crazy executives and religious developers to get things changed and new things started. And you need stubborn and boring middle managers to get things eventually done.” Ari Jaaksi, head of OSS operations at Nokia 107

As we have seen, the resistance to change seems to be one of the strongest hurdles to be overcome for a successful diffusion of OSS in corporations. Change agents or promotors can help in increasing acceptance of an innovation by breaking organizational resistance naturally residing in social systems, thereby increasing the perceived ease of use of the innovation (Rogers, 2003). Hauschildt and Chakrabarti (1989) show in a review of the preceding literature that innovation in large corporations can be supported by three different types of promotors: the technology promotor, the power promotor, and the process promotor.108 The technology promotor is the person with the necessary technological insight who is able to identify the potential of the technology. In some cases, the technology promotor might even be the inventor herself. The power promotor is the person that can decide whether or not to commit resources on a project. Usually up in the hierarchy, the power promotor can be understood as a sponsor or executive champion. It is the task of the process promotor to connect the other two, to spread the word of the innovation throughout the organization, and to get people involved. Process promotors can be characterized as product or project champions, corresponding to the term ‘champion’ in management literature (Chakrabarti & O'Keefe, 1977; Hauschildt & Chakrabarti, 1989; Markham et al., 1991; Witte, 1973). Close cooperation of the three different types of promotors, including regular and open communication is key to successful diffusion of the innovation within the company (Ebadi & Utterback, 1984; Hauschildt & Chakrabarti, 1989; Hauschildt & Kirchmann, 2001).

107

108

This quote is taken from Ari Jaaksi’s blog (http://jaaksi.blogspot.com/2007/06/middle-managementsandwich.html) retrieved August 30, 2007. Ari Jaaksi sees himself as a middle manager. The term promotor has originally been coined by Witte (1973).

Bottom-up Adoption of OSS

139

Hauschildt and Kirchmann (2001) show, however, that, in most cases, only a technology promotor appears, and that an accumulation of roles in one person rarely happens. Furthermore, in the same study, power promotors were shown to never exist alone. The existence of process promotors in addition to the other two categories of promotors resulted in the innovations being most successful (Hauschildt & Kirchmann, 2001). Their importance may vary in different industries, nevertheless, their existence is crucial to the diffusion of a new technology within an organization (Howell & Shea, 2001; Rothwell et al., 1974). In order to fulfill their task, process promotors are expected to be extremely favorable to the innovation, generally innovative, open to new ideas, and willing to break with organizational traditions and norms (Howell & Higgins, 1990; Howell & Boies, 2005; Howell, Shea, & Higgins, 2005; Howell & Shea, 2006; Markham et al., 1991; Shane, 1994). Organizations that plan to engage in OSS efforts need to identify power and process promotors if they want their efforts to take off and, eventually, to succeed. The exploratory cluster analysis (see Section 4.7) has suggested a lack of power promotors; interview and survey results show that process promoters will most likely exist and—when offered some organizational support—will act accordingly. From my interviews, I learned that those people willing to act as process promotors for corporate OSS engagement most often cannot do so because they are too tied up in their day-to-day work. Reducing their work load thereby allowing them to dedicate some of their work time to the promotion of OSS in the corporation could greatly enhance its diffusion. Interview results suggested that in particular younger middle managers seem well-suited to fill the job as many of those will both be familiar with OSS in itself as well as ready and willing to work with it in a commercial environment. The odds of success for corporate OSS efforts might further be increased by establishing power promotors. Even though this might be of more symbolic value, in most cases it should suffice to identify a high-level executive favorable of OSS and make this person the organizational sponsor of OSS—the “Open Source Officer” or “Open Source Evangelist” of the organization—and, of course, to make this decision widely known to the company’s employees. Employees could then turn to the power promotor to seek help for their ideas and efforts regarding corporate OSS engagement, and the power promotor could provide the higher-up backing necessary to provide these initiatives with adequate resources.

140

Bottom-up Adoption of OSS

4.9 Summary: Top-down or Bottom-up On average, employees, no matter what their job function, are somewhat positive towards corporation OSS engagement. Whereas there are differences in the level of agreement between the job functions, nevertheless, there should be enough support in the organization to guarantee successful diffusion of OSS. Still, the corporation should strive not to lose out on those employees who are resisting the introduction of or an increase in corporate OSS involvement, as those individuals may well be very valuable to the corporation and might have sensible reasons to be skeptical about OSS. We have seen that there are several means of increasing employee acceptance. For the most part, those target at educating employees to be able to understand and exploit the potential inherent in OSS. These measures include training, a stepwise introduction of OSS to the organization, the ability to self-select into OSS efforts, and the use of change agents. Combining the findings of this chapter with those of Chapter 3, it is clear that there is reason to believe that corporate adoption of OSS and OSS-based development processes can take place in many situations since both top management and the employees will often have an at least somewhat positive view on corporate OSS engagement. Moreover, in most cases, it will matter little who initiated the adoption process, as long as both sides are convinced that the outcome of the adoption process, that is, the desired form of corporate OSS engagement, will be potentially beneficial to the firm. Whereas, as was suggested in many of the interviews, the initial adoption of OSS in general and OSS use in particular was largely driven by employees in the past, this does not necessarily imply that (1) management is against OSS or views it less favorably than the employees do or (2), in the future, the number of corporate OSS initiatives launched by top management should not increase. On the contrary, survey results have shown that management, on average, even tends to evaluate certain forms of corporate OSS engagement more positively than developers. Eventually, these findings indicate that corporate OSS engagement has a potential for both bottom-up and top-down adoption with consensus on the potential benefits by top management and employees. More generally, this further implies that firms will try to and, by and large, should be able to adopt OSS and OSS-based development methods, as, in many situations, a sufficient level of support can be expected both among top management and employees as both parties can benefit from it.

Bottom-up Adoption of OSS

141

Having said that, the next question that arises is how firms can best do this, that is, how firms can best manage the introduction of corporate OSS efforts and, afterwards, day-to-day operations. The third part of this thesis will address these questions. In the next chapter, results of a benchmark study will be presented showing how companies that have long been active in OSS and OSS development manage their corporate processes around it. Chapter 6 will address another important aspect of corporate engagement in OSS, namely the issue of managing and incentivizing employees and outside volunteers participating in the firm’s OSS efforts to complete work that is in the best interest of the company, that is, trying to direct supposedly voluntary efforts so that the company will benefit from them.

142

Managing OSS-related Processes

5 Managing OSS-related Processes So far, we have seen that (1) OSS can potentially bring many advantages to firms and (2) that both management and employees may perceive those. In this chapter, I thus turn to the question how the company can ensure that it is able to reap those potential benefits. To do this, in mid 2006, a benchmark study was conducted with established corporations that have significant OSS exposure to see how some of the larger companies are managing their OSS activities. As I was interested in the processes those firms use to manage OSS, more than a dozen companies active in OSS were contacted, most of which were known for their long-time commitment to and engagement in OSS. Elaborate responses were received from four companies; these were Adobe, SGI, Siemens,109 and Symbian. Apart from Siemens, which has mainly been a user of OSS, these firms have been actively contributing source code to existing OSS projects since the early 2000s as well as starting some on their own. In addition, publicly available information on Optaros, an international consulting company,110 was included in the benchmark. Chapter 5 will be segmented into three parts. In section 5.1, the results of the benchmark will be presented, mainly focusing on processes around using OSS and contributing to existing projects. Based on the benchmark results and selected literature, a model process describing how firms might release proprietary software as OSS will be developed in Section 5.2. Finally, recommendations will be given on how the resulting projects can be managed in Section 5.3.

5.1 Benchmark Study For the benchmark study, several interviews were conducted with members of the participating organizations who were furthermore asked to complete a short questionnaire.111 The questionnaire, an identical version of which was sent to all firms, asked for a brief description of the company’s history with respect to its OSS engagement in general, and in particular for the processes it had in place with respect to contributing to

109

110 111

Two departments at Siemens were included in the study: Siemens Communications, at that time the largest of all Siemens departments, and Siemens Corporate Technology. For more information, please see http://www.optaros.com/en/optaros_free_and_open_source_software_policy. As mentioned before, no employee of Optaros was interviewed or sent a questionnaire.

Managing OSS-related Processes

143

existing OSS projects and releasing proprietary software as OSS. Interviews were semistructured and followed the same topics as the questionnaire.

5.1.1 Using Open Source Software On the one hand, using OSS offers many potential advantages to a company. These may include lower licensing costs, lower hardware costs, reduced lock-in, higher quality and performance, and less expensive, more rapid prototyping. On the other hand, using OSS the wrong way may create pitfalls for the organization. OSS must not be regarded as mere gratis software but as software delivered by a third party including license terms to be adhered to. Understanding and adhering to OSS licenses thus plays an important role in order to be able to successfully use OSS in corporations (also see Sections 2.3.1, 2.3.2, and 3.1). On this topic, Fan, Aitken, and Koenig (2004) from Olliance Group have published a benchmark, built on information by HP, Microsoft, and Charles Schwab, in which the authors try to identify best practices on how to use OSS. While the choice of benchmark participants, as in this study, will certainly have affected its results, Fan et al. (2004) derive some recommendations around using OSS that seem to hold beyond their sample as many of the issues they raise were also voiced by benchmark participants in this study. Their main findings will thus be briefly summarized in the following. Following Fan, Aitken, and Koenig (2004), firms need to first become aware of whether, and if so, what kind of and how much OSS they are currently using by auditing current OSS installations and use. Building on the results of this and the goals the firm wants to achieve with its OSS use, the company should set up a policy on using OSS. The latter should clearly define in which situations and, potentially, under which restrictions OSS may be used in the company, how approval processes might look like, how OSS used by the firm is managed and maintained, whether it is acceptable to modify used OSS, and, if so, organizational processes the latter would need to follow. Moreover, employees need to be educated about theses policies; trainings should also be offered to new hires, managers, and legal and IP staff. Additional tasks include reviewing special cases and issues that arise around OSS usage, maintaining the workflow and correspondence of OSS activities, keeping up-to-date with new and modified OSS licenses and ensuring they are being complied with, and monitoring major OSS developments. Moreover, an electronic database keeping track of OSS in use should be set up so that the users of the software (i.e., the respective projects) can be contacted when-

144

Managing OSS-related Processes

new versions or critical updates of the OSS package are published, and to ensure harmonization of the version of the OSS in use throughout the entire firm (Fan et al.,

Siemens

2004).

Siemens Communications: -

Initiated its OSS Clearing House, a joint project founded by technical, legal, and IP-related sections of Siemens Communications

-

OSS Clearing House for example maintains o Whitelist of all OSS that has been approved for use by the department (may thus be used without further request for approval); also contains projects currently employing the respective OSS packages o Blacklist including all OSS applications Siemens Communications programmers are enjoined from using112 o Both lists are updated when a programmer requests to use an OSS application not to be found on any of the lists after evaluating the application

-

Furthermore maintained: o A set of OSS product release blueprints and a checklist for open source package approval o List of links to useful websites on the topic of OSS and a list of FAQs

Symbian

around the correct use of OSS at Siemens focusing on license adherence -

Very similar to the Fan, Aitken, and Koenig (2004) study described before

-

Company-wide audit undertaken to arrive at inventory of all OSS in use Defined policy on how to deal with OSS Verified current use against policy

Table 36: Benchmark results: Using OSS

Regarding the procurement process for OSS, interviewees agreed that, to ensure manageability of the procurement process for software in general, OSS should be selected based on mostly the same evaluation criteria that are used to rate proprietary software.113 The criteria, of course, need to incorporate the various unique characteristics of OSS.114 If the license that comes with the OSS permitted all necessary activi-

112

113 114

Most of the items on the blacklist are OSS projects that Siemens Communications programmers may not use to build products (i.e., the OSS project would become part of a commercial project), as they are in some way incompatible to proprietary Siemens code, which may include both legal and technical incompatibility. Identical results were also found in the interviews reported in Section 3.1. In any case, the decision to use existing OSS should not only consider the direct monetary gross benefit coming from it, but also potential expenses required for customization requirements as well as the component characteristics—including functionality, effectiveness, flexibility, stability, reliability and auditability—, licensing issues, and available maintenance and support. Fit with existing platforms, of course, also needs to be evaluated (Madanmohan & De', 2004). Also see sections 2.3.1 and 2.3.2.

Managing OSS-related Processes

145

ties115 and a business case was favorable, benchmark participants reported they would then select the OSS alternative. Examples of how benchmark participants have organized for OSS use are given in Table 36.

Adobe

5.1.2 Contributing to Existing OSS Projects -

Supervisor’s approval is asked for by the developer who wants to reveal a piece of source code

-

A technical and an IP expert make sure that no intellectual property that is supposed to remain proprietary is being released accidentally Corporate approval is sought for; the more important (which usually implies “the larger”) the to-be contribution is, the higher up the O.K. to proceed has to

-

-

come from; engineering council reviews major contributions Revealing process can take from a couple of minutes to several months—

Siemens

Siemens Corporate Technology: -

Process mostly similar to that of Adobe In addition to a (middle-tier) project manager, another manager from upper

Optaros

depending on the strategic importance of the revealing decision and the availability and interest of management

-

As specified by their OSS policy, Optaros consultants are expected to spend at

management has to indicate his or her support for the project

-

None of the other companies participating in the benchmark has a set rule on the amount of time an employee may or must spend on OSS: the respective employees work on OSS as part of their projects

SGI

-

Established an “Open Source Review Board” to support its processes around

Symbian

least 10% (but no more than 20%) of their working time participating in relevant OSS communities

-

Check whether revealing changes to the public is compulsory according to type of OSS license coming with original software (e.g., GPLed software) Should there be a choice in whether or how to reveal the software, firm tries to

-

find best place to release software (e.g., release to main source tree of OSS project, start own source tree as part of OSS project, keep separate) Receiving management O.K. takes same amount of time as at other companies

releasing source code

Table 37: Benchmark results: Contributing to existing OSS projects

115

Whereas licensing issues were not the primary topic of the benchmark, one of these activities shall be named here. If a company has for example selected an OSS library that is to be linked statically to the software, it needs to make sure this library is not licensed under the GPL, or else the software would be considered derived work and would also have to be placed under the GPL (also see Section 2.1.2).

146

Managing OSS-related Processes Should the company decide not only to use OSS, but to even join the project provid-

ing it, there are several issues to be considered upfront. Depending on the goals set for its OSS efforts, the company has to decide whether to just make some minor additions like bugfixes to the project, or whether to become a large-scale contributor. As already stated in Sections 2.3.4 and 2.3.5, contributing to existing OSS projects may have several reasons, many of which also apply to releasing of proprietary software as OSS (and, there, probably to an even larger extent). Reasons named by the benchmark participants to contribute to OSS projects included knowlegde exchange with the outside world, ensuring interoperability, driving and influencing standards, reducing the amount of resources (developers, support, etc.) to spend on non-core activities, and to commoditize layers in the software architecture in which the company had no primary business. Most of the companies talked to use some kind of review process before deciding to contribute source code to existing OSS projects. The respective processes are summarized in Table 37.

5.1.3 Releasing Proprietary Software as OSS Excluding Optaros, all firms had developed a process for releasing proprietary software as OSS, as this had happened in all of the firms at least on an individual basis. The respective release processes of the benchmark participants are described in Table 38. Most notably, one Siemens department has developed a comparatively sophisticated process, which was composed in a publicly funded research project with the cooperation of two Siemens business units, two universities, and one independent company. This process is obviously not specifically targeted at Siemens and may well be transferred to other companies.116 In the case of Siemens, however, it is the process by Siemens Corporate Technology (see Tables 37 and 38) that is used in most cases.

116

The full process description (96 pages – German only) is available at http://www.c-lab.de/fileadmin/redactors/ data/Services_Downloads/C-LAB_Reports/1_C-LAB-TR-2004-1-Open-Source-Software-Release.pdf.

Adobe

Siemens Corporate Technology:

Symbian

SGI

-

Siemens

Managing OSS-related Processes

147

Same process as for contributing to existing OSS projects (see Table 37)

- Same process as for contributing to existing OSS projects (see Table 37) Siemens Communications: 11-step process -

Decision pro OSS: SWOT analysis, map strategic alternatives, decide for best alternative; requires upper management involvement

-

Clarify legal situation: ownership of software/copyright, control existing licenses, look at existing liability and indemnity clauses

-

Set goals: derive goals from (firm/business unit/project) strategy Set up business model: market, resources needed, revenue model, culture

-

Set up licensing model: choose/modify existing license or create a new one Format software: sanitize source code, provide documentation

-

Lay out foundations for distribution and project (only with self-distributing): create website, forums, publish information on project, install CVS

-

Release of the software: publish software using selected distribution channel Found community: lay out community structure and culture, provide incentives to participate, create interfaces between corporation and community

-

“Open Source Review Board” makes the basic decision on whether to release

-

the source code based on the impact on customers and SGI itself Decision of which license to choose is based on the motivation of going open source: for example, the GPL is typically used to attain rapid volume adoption

Decide on mode of distribution: self or third-party Final check of the software: from technical, legal, and business perspective

Process for contributing to existing OSS projects is taken and slightly extended: - Strategic goals for the to-be-revealed technology are the “driving force behind the process;” ongoing basic compatibility of OSS efforts with product strategy is ensured not to unintentionally weaken competitive position by releasing IP that would have better been kept proprietary -

Potential community interest and support also included in the initial decision whether to go open source

-

Depending on project size, revealing process may take between a few weeks and a couple of months as all potential stakeholders need to be in agreement

Table 38: Benchmark results: Releasing proprietary software as OSS

148

Managing OSS-related Processes

5.2 Developing a Model Process for Releasing Source Code Based on the results of the benchmark study and several other sources, a model process was developed for companies thinking about releasing proprietary software as OSS.117 Its structure built on a synthesis of the benchmark results, the process is split up into three phases: in the general preparations phase, the environment of the project is set up and management educated about the potential benefits of a release. The business preparations phase starts with the decision to evaluate a potential release and analyzes the potential economic effects, resulting in a business case. If the latter is positive, the software preparation phase starts in which necessary modifications to the source code are carried out and the community infrastructure is set up, culminating in the launch the OSS project by releasing the software.118

5.2.1 General Preparations Releasing software under an OSS license does not just mean putting some source code online but is a rather complex process that requires thorough planning and execution. Instead of just jumping in at the deep end, a potential OSS project manager and the people intended to work on his or her project should first educate themselves about OSS and its culture. Joining an existing OSS project, working on its source code, participating in its discussions, etc. would be an ideal preparation. In this learning-by-doing fashion they could acclimatize to OSS culture and project management style; they will also get to know what it is like to be an “outsider” in an OSS project and, thus, be able to better understand external contributors in their own OSS project (Benchmark; Fogel, 2005; Goldman & Gabriel, 2005; Hang et al., 2004; Hohensohn et al., 2004). Whereas it may not be necessary or feasible due to time or resource constraints to actually join and actively participate in an existing OSS project, management of an OSS project will definitely have to make sure that every team member of the OSS project knows what OSS and OSS development are about. Conducting a workshop about issues such as the history of the OSS community, OSS culture, and motivations of OSS developers as well as advantages and disadvantages of OSS development, the method of OSS development, and OSS licenses should greatly help ensuring this. To clear up potential 117

118

In the course of Section 5.2, information derived from the Benchmark study presented in Section 5.1 shall be marked with (Benchmark). Whereas the model process described hereafter also suggests a certain order for the tasks to be performed as part of the business and software preparation phases, some firms may find that adapting the model process to their organization by for example changing the order of certain steps or inserting more iterative loops could improve the odds of success of their OSS efforts.

Managing OSS-related Processes

149

misunderstandings and misconceptions about OSS, it might be a good idea to invite management (especially the direct supervisor(s)), opinion leaders of the organization, and people that the project team will likely be confronted with over the course of the release process. It is important to introduce management to the OSS development mode and business models and to show them how the project will benefit from becoming OSS (Benchmark). Having won their support or at least stirred their interest, the software can now officially enter the revealing process.

5.2.2 Business Preparations

Figure 10: Business preparation phase

Defining the OSS project and its goals The first step in releasing proprietary OSS is officially setting up a project, which requires several questions to be answered up-front. Most importantly, also regarding the findings of Section 4, are the members of the project, including both managers and developers willing to and capable of working in such a way (Alexy & Henkel, 2007; Goldman & Gabriel, 2005; Hohensohn et al., 2004)? In addition to this, project goals need to be defined to set the direction of the OSS project. Potential goals of the OSS efforts may include for example increasing diffusion,

150

Managing OSS-related Processes

setting a standard, getting additional development resources, or fostering a new stream of innovations (see also Section 2.3.5); potential success measures would include number of downloads or registered users, market share, percentage of code contributions done by outsiders, number of active outside developers, and so on. Of course, it has to be ensured that the goals of the OSS project connect to the company’s long-term goals and product strategy (Benchmark). Some thought might also be spent on whether and, if so, how much the team intends to open up the project with respect to what kinds of contributors (individuals, companies, and even competitors) will be allowed to join the project and the amount of control the company is willing to give away during the course of the project (Goldman & Gabriel, 2005; Hohensohn et al., 2004). At this point at the latest, the team needs to get management’s commitment to the project. The team might not be granted approval to release the software as OSS in this stage already—this is what the business case and final review phases are for—but they should try to get management’s O.K. or at least a power promotor way up in the hierarchy before going on in the release process (see also Section 4.8.3).

Evaluating legal risks In order to be able to release source code, the company either has to own copyrights to the entire source code or get permission to release the software from third parties whose source code is part of the product. If the latter is the case, the company might think about acquiring the respective property rights, receiving permission to reveal the source code, or replacing the respective parts of the source code (Fogel, 2005; Goldman & Gabriel, 2005; Hecker, 1999; Hohensohn et al., 2004; Moody, 2001). Should the company not be able to replace the respective parts of the software or should it make no sense or be outright impossible to reveal the source code without the respective parts, the OSS efforts have to end here. Indemnification is another point that has to be paid attention to in corporate environments. If other companies willing to adopt the software will also be looking for protection against potential legal issues caused by it, the firm may account for this in its business model, and potentially even make money from this (see Section 2.4.4). Another facet of indemnification is illustrated as follows: a supplier might have provided the company with a piece of source code that violates a patent or an OSS license of another person or firm, and the owner of the respective intellectual property right may sue if the company publishes this work as part of its OSS project. Whereas companies may al-

Managing OSS-related Processes

151

ready hedge against this risk when originally procuring the respective source code,119 some risks remain, in particular considering software patents.

SWOT Analysis In this phase, the firm needs to evaluate the current and future advantages and disadvantages of releasing the software, including both monetary and non-monetary aspects (see Section 2.3). This evaluation will also need to include developers’ and (potential) users’ opinion on what they think of making the respective piece of software OSS, potential reactions by the market and competition, and the likelihood that the software will be accepted by the community. If the project and an existing one show significant overlap, a joint effort may be a suitable approach. In case the search reveals unsuccessful or abandoned OSS projects, the firm has to try to find out the reasons why these failed in order to avoid repeating the same mistakes (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004).

Choosing a business model Looking at the business models presented in Section 2.4 the project team should define the business model based on one—or a combination of several ones—in a way to maximize the trade-off between strengths and opportunities on the one hand, and weaknesses and threats on the other hand. The project team might be limited in the choice of business model by legal conditions identified in step 2 as well—for example, dual licensing might be impossible.

Choosing an OSS license Although it is both perfectly legal and legitimate to create a new license for the OSS project—either by modifying an existing OSS license or by writing a new one from scratch—the first choice should be to go with one of the existing OSS licenses. Not only will people be reluctant to read and understand an additional OSS license—when so many are already out there—(see also Section 2.3.2), even worse, it might decrease trust in the company’s OSS project.120 Also, a newly created license would first have to

119

120

Firms interviewed for Section 3.1, as well as benchmark participants from Section 5.1 said they did so through contract design. Goldman and Gabriel (2005, pp. 187-205) provide several examples of positive and negative effects on potential users and contributors caused by the choice of license. Similar to these examples, Stewart, Ammeter and Maruping (2006) find in a sample of 138 OSS projects taken from freshmeat.net that OSS projects not under the GPL attracted more user interest over time. However, contradictory to the examples by Goldman and Gabriel, they find no indication that projects under the GPL attract greater developer activity.

152

Managing OSS-related Processes

complete the OSI’s approval process before it could officially be called an OSS license (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004; OSI, 2001).

Putting up a business case The decision to release proprietary software as OSS should rest on a business case (Henkel, 2004b; West & Gallagher, 2006a).121 A sound business case is key to communicate the OSS engagement to management. Many managers might either not understand or dislike OSS for different reasons; by showing them that OSS is indeed beneficial using the same evaluation methodology that is used for “common” projects, the project team should be able to overcome this resistance, and management should decide in favor of the OSS efforts. However, in case the team has come up with an inconclusive or negative business case, or management still decides against the project, the OSS efforts have to end here.

5.2.3 Software Preparations Sanitizing the software Already having checked for third-party software contained in the software, now is the time to make sure that the parts programmed by the company are actually ready to be released. Parts that are patent-protected or otherwise not allowed to be released need to be replaced. The project team also has to ensure that other developers will be able to work with the source code. Modularity is a must—modules need to be re-formatted to be easy to understand and work with (Fleury & Lindfors, 2001; MacCormack et al., 2006; Narduzzo & Rossi, 2005). It is important that the software represents a complete and running entity—the community will not create a program but refine, improve, and further develop an existing one (Raymond, 2001b). Further considerations include versioning and naming conventions the project should adhere to, using a widely-adopted programming language, and removing inappropriate comments or any other kind of information that is not intended for the public from the source code. To ease the initial adoption of the software, the project team should create corresponding documentations,

121

It has to be noted that whereas various authors have tried to analyze the pecuniary benefits of OSS—may it be for the mere use of OSS in most cases (for an overview, see, e.g., Wheeler, 2007)—the results are inconclusive. Thus, it might be easier to compare OSS relative to the best alternative proprietary activity (outsourcing, buying off-the-shelf software, or doing-it-yourself) rather than trying to put an absolute number to it. Furthermore, even though money should be an important factor in the evaluation, strategic reasons (see Sections 2.4.1 and 3.2) might also play a role in the decision and could in some cases even outweigh the monetary ones.

Managing OSS-related Processes

153

manuals, how-tos, FAQs, etc. as well as basic instructions for installation and configuration (Hecker 1999; Hohensohn et al. 2004; Fogel 2005; Goldman and Gabriel 2005).

Figure 11: Software preparation phase

Setting up the community infrastructure While the project team is sanitizing the software, the task of setting up the community infrastructure can be tackled. It is important to understand that a community will not miraculously arise by itself. The project will still need project management, face-toface meetings, etc., and the company should spend serious thought on how to organize the community and how the firms sees community development over time before it releases the software out into the open (Goldman & Gabriel, 2005; Stewart et al., 2006). Summing up, personnel and budget that have to be committed to the project include resources for infrastructure support, code maintenance, bug database maintenance, documentation, web site management (including an editor-in-chief regularly posting project news), an evangelist or marketing campaign manager, and, of course, a community manager (Behlendorf 1999; Goldman and Gabriel 2005). Whereas some of these roles might be acted out by one and the same person, the firm should expect to need at least three full-time employees to work on the project (Behlendorf 1999).

154

Managing OSS-related Processes In accordance with the company’s goals and the selected OSS business model, the

company will have to decide on how software distribution is going to look like, that is, whether it will distribute the software by itself or it will rely on third-party services. Regarding further development as well as ongoing maintenance, initially, probably all developers with committing rights122 will be members of the company’s project team or, at least, employees of the company. Over time—depending on how much control the firm is willing to give away—external developers will be awarded committing rights as well. Active outside contributors might also take over roles of subproject managers or forum administrators. In case the company plans on keeping the committing rights to the software, its employees will have to earn their merits as well to be accepted by the community (Benchmark; Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004).

Laying out the software development roadmap In order to give users of and contributors to the software an idea of how it is going to evolve over time, the project team needs to create and publish—partly, at least—a development plan (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004). In many ways, this can be considered a detailed project roadmap (Kappel, 2001). Publishing the roadmap should help improve the quantity and quality of outside contributions, as it shows people how they can contribute and lets them know what is needed to be done. It should furthermore specify the software architecture, how the modules work together, and how new modules can be added to the program (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004). The development roadmap will also contain the release cycle. This is not only important for the users and contributors, but to the company itself as well. Other departments in the company might work with the software or use it as a part of their projects. They will be especially interested in compatibility or security issues; of course, this applies to users of the project as well. Marketing and sales also need the information to brief (paying) customers and set up or modify campaigns. Last but not least, the development roadmap is also a quasi project plan for the team of programmers working on the project (Fogel, 2005; Goldman & Gabriel, 2005).

122

“Committing” implies accepting a suggested change or addition to a piece of software, thus making it permanent. Technically, participants in an OSS project can only suggest modifications or additions (i.e., patches, bug fixes, new modules, etc.) to the OSS project if they do not have committing rights.

Managing OSS-related Processes

155

Creating a marketing plan Marketing the to-be OSS project aims at familiarizing the organization, its customers, and potential users and contributors with the firm’s OSS efforts. Issues that need to be addressed include naming and branding the project as well as preparing information on the project and distributing this information to the different stakeholders. Apart from its plans for start-up marketing, the company also needs to think about how to continuously spread the news around the project. In addition to posting project news on the project website, the project team should try to publicize community meetings and significant milestones in relevant media (Fogel 2005; Goldman and Gabriel 2005). Regarding the potential benefits of OSS inside of the company, internal marketing to involve larger parts of the organization as early as possible in the course of the OSS project will help to break resistance and to tackle organizational and personal issues (Katz & Allen, 1982; Kotter & Schlesinger, 1979) and to reap potentially beneficial effects on employee motivation and identification with the firm (Abreu 2001).

Final checks Before releasing the software, the project team needs to make sure that it is still on track with respects to the business-level evaluation and that no major issues have arisen during the software preparation phase. When the following questions can be given a positive answer, the firm will be able to release the software (Benchmark; Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004; Raymond, 2001b): -

Legal aspects: Have all legal threats been removed? During the process, have

-

Business aspects: Does the project that is about to be released still correspond to

any new legal issues appeared that have not been addressed yet? the goals set initially? Does the project setup still match the business model and the business case? -

Software aspects: Has code sanitization resulted in a piece of software that is suitable for release? Does the code really work, that is, does it compile and run afterwards? Have all corresponding documents—FAQs, read-mes, etc.—been created? Is the distribution platform up and running?

-

Management aspects: Is management up-to-date and still on board? Have all responsibilities for the further course of the project been established? Have all necessary resources been committed? Is the marketing plan ready and sound?

156

Managing OSS-related Processes

5.3 Managing Company-Owned OSS Projects After the OSS project has been launched, the project team is faced with managing day-to-day operations such as motivating outsiders to contribute to the project, project governance, source code management and release policy, documentation, accepting outside contributions, and measuring success. These issues will be taken a closer look at in the following.

5.3.1 Getting Third Parties to Support the Project Whereas stirring public interest in the software might not be an easy task in itself, the difficult part is getting and keeping contributors. Only a fraction of the overall users will actively contribute to the project and even less people will commit to the project for a longer period of time. Experts, too, are likely to leave after a period of twelve to fifteen months (Shah, 2006). Understanding the motivation of outside contributors to assist the project might help to increase the number and intensity of people working on the project. Different types of users will be joining the project for different reasons. Firms will most likely be looking for a way to derive benefit from their engagement as was described in Section 2.3.4. Individuals contributing to the project might have diverse motivations to contribute. By writing good source code, they could advertise themselves on the job market, both to the corporate sponsor of the project as well as to other firms. Their ego might also play a role: by showing their superior programming solutions to the public they might hope for fame and peer recognition in the OSS community. Many individual contributors will also be looking for feedback on their source code, thereby improving their programming skills (Hars & Ou, 2002; Lakhani & Wolf, 2005; Lerner & Tirole, 2002).123 However, whereas all these reasons might encourage certain individuals to join a company-sponsored OSS project for a limited period of time, only two things will turn hobbyist participants into long-term contributors. (1) They need to have fun working on the project and (2) they need to trust the company. Both these points can be addressed during community setup and management by encouraging open and mannered discussion, getting outside developers involved in project management, and actively removing obstacles for their participation (Fogel, 2005; Goldman & Gabriel,

123

For more on why individuals would want to join a corporate OSS projects and how the corporation might ensure that those individuals perform tasks that are in the best interest of the corporation, please see Chapter 6.

Managing OSS-related Processes

157

2005; Hars & Ou, 2002; Hecker, 1999; Hohensohn et al., 2004; Lakhani & Wolf, 2005; Stewart et al., 2006).

5.3.2 Governance OSS is developed in a meritocratic way and leadership is usually assigned similarly (Raymond, 2001b; Scacchi, 2004). A corporation engaging in OSS will probably have to somehow reward those who regularly make important contributions to make sure that those people do not become bored with the project or start feeling exploited. Having their name in the source code or on the website might be enough for these people in the beginning. With increasing involvement in and commitment to the project, they may also demand a say in project governance, to which the company might respond for example by including heavily involved outside developers in the governing body of the OSS project. Another option would be the foundation of subprojects, where firms or individuals that have contributed a largely independent building block to the project become leaders of a subordinate project that will mostly operate on its own (Fogel, 2005; Goldman & Gabriel, 2005; Moody, 2001; Raymond, 2001b). Generally, with increasing size of the OSS project, it is highly likely that not a single person will be responsible for the source code, but that there will be a module owner for each of the different parts of the program and its related projects.124 The company will further have to ensure that its own developers working on the project are able to make the transition from PCSS to OSS development. Moreover, it needs to pay attention that the developers in project management do not hijack the project, that is, make it a piece of software by developers for developers, and, thus, inappropriate for use by a large share of potential users (Fogel, 2005; Goldman & Gabriel, 2005; Raymond, 2001a, 2001b).

5.3.3 Source Code Management and Release Policy Source code management builds on the development roadmap created. Its goal is to ensure that the further development of the source code is organized in a way to maximize value for the corporate sponsor, the users, and the contributors.

124

Related projects might be translations, ports to other operating systems, documentation, etc. In case of even bigger projects or modules, there might as well be several module owners or assistant (cf. the “lieutenants” of the Linux kernel who have (almost) as much a say in the further development of Linux as has Linus Torvalds himself).

158

Managing OSS-related Processes As opposed to “common” software development, OSS—in accordance with the

“Release early. Release often.” principle—means releasing new versions of the software very often (Raymond, 2001b). However, corporate users of the OSS project, in particular if they offer a product or service of their own that builds on the OSS or if they are using the software to fulfill business-critical tasks, would rather prefer a stable and welltested application. Consequently, explicitly labeled stable versions of the software that guarantee a certain level of functionality and interoperability with other programs and applications should regularly be published (Fogel, 2005; Goldman & Gabriel, 2005; Hecker, 1999; Raymond, 2001a). As illustrated in Chapter 4, members of the project team in general and in particular developers and project managers might also have issues with this way of software development that need to be overcome. A potential threat to the success of the project is the danger of forking (see Section 2.3.6). Past case examples show that forking may happen because a group of external programmers is disappointed with project strategy (see the Joomla-Mambo example described in Section 2.3.6) or because of technical issues or release policy.125 Integrating developers into the respective decision making processes from the start and giving them a voice or at least hearing them on important decisions (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004) as well as strong leadership by the corporate sponsor (Fleming & Waguespack, 2005) should reduce the risk of forking to a minimum. The existence of complementary assets (Teece, 1986) to the software (e.g., proprietary software or hardware specific to the software or a strong brand) should also reduce the risk of forking to appear or, at least, to succeed.

5.3.4 Documentation The importance of documentation may well be higher for OSS projects than it is for commercial software development. People with little time and effort available to contribute to the project need to be able to easily and quickly understand it. In order to be able to use the OSS and make adjustments and improvements to have it better suit their needs, they can only rely on project documentation and comments in the source code. Developers should thus be highly encouraged to extensively comment the source code they provide. In addition, there may be people working solely on writing documenta125

An example for a technical issue would be the small Linux kernel developed by Linus Torvalds as opposed to the HURD kernel favored by the FSF (see, e.g., http://www.gnu.org/software/hurd/hurd-and-linux.html, retrieved March 30, 2008). Also, failure to provide running versions of the code, or bad code design and documentation may lead to developer discontent, and, thus, possibly to forking. Regarding release policy, the XEmacs fork of the GNU Emacs text editor was launched because of reoccurring delays in publishing updates or new versions of the original GNU Emacs text editor (see, e.g., http://www.jwz.org/doc/lemacs.html, retrieved March 30, 2008).

Managing OSS-related Processes

159

tions, FAQs, or providing user support, that is, as a forum or mailing list moderator or administrator (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004). The sponsor will probably have to have people from the company provide this kind of support in the beginning, but people from the community will take over much of the work over the course of the project (Lakhani & von Hippel, 2003).

5.3.5 Accepting Contributions Every contribution to an OSS project, no matter what license was chosen, is protected by copyright law. To be more specific, after programming a piece of software, the respective authors also hold the copyright to it (Meets, 2006; St. Laurent, 2004). Whereas a transfer of copyright to the organizational sponsor is not necessarily mandatory for the success of the OSS project, by either integrating a respective passage into the license for the OSS project or by providing a mandatory form to be completed before the submission of source code, contributors can be asked or even forced to transfer their copyright to the sponsor or to a third party consigned to manage all intellectual property rights of the project (Fogel, 2005; Goldman & Gabriel, 2005; Hohensohn et al., 2004). For example, several large OSS projects have set up foundations to do this. More importantly, potential contributors should sign a form saying that they in fact are allowed to reveal the software they are willing to add to the OSS project: as many of the developers will be working for other companies, this will help to protect the sponsor from erroneous or malicious contributions of copyright-protected code into the project. It is thus not surprising that all major OSS projects have implemented rigid procedures to attest the origin of code contributions (Benchmark; Economist, 2006).

5.3.6 Measuring Success How can the company measure whether its OSS project is successful or not? Success depends on whether or not the goals set up for the project are reached. This includes meeting the monetary targets as set in the business case, but also qualitative aspects such as diffusion, standards development, appeal to community, number of contributions and contributors to the project, quality and functionality of the software, etc. Both the objectives and their rate of completion have to be re-evaluated regularly. Should no positive effects be observable after a certain period of time,126 there are some

126

For example, Hohensohn et al. (2004) state that for successful projects, they would expect to find some positive results six to twelve months after the release of the software at the latest.

160

Managing OSS-related Processes

possible causes for this. The software might be too specialized so that there are not enough people who see their itch being scratched (Raymond, 2001b). The source code could be monolithic, unorganized, badly programmed, or just hard to understand (Hissam et al., 2001; Raymond, 2001b). People might not want to contribute to the project because they are unhappy with the license chosen or the way they are being treated (Goldman & Gabriel, 2005; Hohensohn et al., 2004; Stewart et al., 2006). Further reasons could be the existence of a competing OSS project that had been overlooked during the release preparation, a clearly superior, well-proven proprietary product, or just general lack of visibility of the project in the public (Goldman & Gabriel, 2005). After the issue has been identified, the company should easily be able to come up with possible solutions. Before implementing them, however, a small business case needs to be set up to check whether the additional resources needed to keep the project running will not consume all or even more than the potential benefits.

5.4 Conclusion In this chapter, the processes that corporations can follow for their OSS engagement have been taken a closer look at. A benchmark study showed how firms can organize for OSS in general as well as for the three different modes of OSS engagement in particular. Built on the findings of the benchmark and existing literature, a model process for firms intending to release proprietary software as OSS was developed. Selected elements of how to manage the resulting corporate-sponsored OSS project were also highlighted. All companies participating in the benchmark study stress that they are positive towards their OSS processes. They emphasize that they have an efficient process that has received positive feedback and evaluation results from both customers and the engineering department. Areas of future improvement include the evaluation process and the marketing of OSS efforts within the respective organization to reduce skepticism and increase employee participation. Although the degree of formality between the individual processes may differ, all companies feel that have been able to successfully steer their OSS efforts. The key to success seems to be finding the balance between bureaucratically managing OSS and just letting OSS happen. The benchmark has shown the levers a company can pull to find that balance in accordance with its organizational design and the desired level of OSS engagement.

Managing OSS-related Processes

161

For companies planning to release some of their proprietary software as OSS, a process distinguishing general, business, and software preparations was developed that should help these organizations to successfully launch a new OSS project. The model process was extended by recommendations on how to manage the resulting project, for example with respect to project governance, source code management, and getting third parties to contribute to the project. With respect to the latter, one issue that might not yet have been sufficiently addressed is the question of steering the project in a way that developers, that is, both corporate employees and, in particular, outside contributors, do day-to-day work that is in the best interest of the company. Contrary to PCSS development, in OSS development, corporations should encounter substantial difficulties in setting and enforcing priorities as well as in ensuring that resources are directed toward unmet needs (Weber, 2004, pp. 126-127). Whereas the ability of developers to select the tasks they want to work on may be considered an advantage in some respects (see, e.g., Sections 2.3.5 and 6.2.4), potentially, this may also result in critical work being left undone.127 How can developers be motivated or incentivized to complete the tasks the company would like them to? The following chapter shall provide an answer to this question.

127

For example, with respect to the further development of the Linux operating system, Linus Torvalds himself sometimes has to point out areas that need more developer attention or may even have to even initiate and lead new projects until they become self-sustaining (Business Week, 2004).

162

Motivation and Incentivizing of OSS Developers

6 Motivation and Incentivizing of OSS Developers128 Assuming the corporation has found employees that are willing to work on a corporate OSS project and, thereafter, successfully launched it, the company is now faced with two problems. First, the company needs to manage the newly-found “freedom” of its own employees who can now (potentially) perform work with outside experts that they find to be a lot of fun—and that unfortunately may have little to do with what the corporation initially expected. Second, if the company successfully managed to attract third-party developers to work on their project, how can the company get them to do work that is in its best interest? In order to be able to answer these questions, we need to understand how developers in OSS projects are motivated, how this motivation can generally be influenced, and how the latter can be done by the corporation.

6.1 Introduction One way of increasing developer motivation to start working on a certain OSS project or to direct volunteer effort to certain areas of such a project could be the administration of rewards—which, however, may also cause undesirable side effects. Agency theory argues that when people are paid for engaging in activities they perform because they feel intrinsically motivated to do, this introduces a disciplining effect and should make them pursue those activities all the more (e.g. Alchian & Demsetz, 1972; Fama & Jensen, 1983a, 1983b).129 Psychology and behavioral economics literature, however, clearly state that certain kinds of incentives usually have detrimental effects on intrinsic motivation. Especially rewards offered for completing a task (completion-contingent rewards) or rewards paid for a certain level of performance at a task (performance-contingent rewards) should undermine or “crowd out” intrinsic motivation (Deci, Koestner, & Ryan, 1999; Frey, 1994). In the context of community-based open source software (OSS), crowding out should have a particularly strong effect, intrinsic motivation being a main driver of the contribution of individuals (Hars & Ou,

128

129

This chapter is the substantially revised version of a working paper that I have co-authored with Martin Leitner which is based on the dataset he collected in his Master’s thesis. Further, I would like to thank Jörn Block, Mako Hall, Joachim Henkel, Karim Lakhani, Christian Lüthje, Francesco Rullani, and participants of the 5th International Workshop on User Innovation for several helpful comments. Cf. e.g. Frey (1993) for a discussion on this.

Motivation and Incentivizing of OSS Developers

163

2002; Lakhani & Wolf, 2005) and a crucial factor in determining OSS project success (Stewart et al., 2006). Monetary rewards, an external stimulus highly likely to induce crowding out (Deci et al., 1999), have been introduced into the domain of OSS mostly through engagement by commercial firms. According to Ghosh (2006, p. 9), two thirds of all OSS software is still written by individuals in their spare time and only 15 percent is contributed directly by firms. Yet, sponsorships and OSS source code releases by major corporations have seen a constant increase over the last years. Commercial firms spent an estimated cumulative 1.2 billion Euros for OSS development up till 2006, both indirectly by allowing or even encouraging their employees to work on public OSS projects and by directly supporting existing OSS (Ghosh, 2006). The latter can happen in various ways, for example through provision of technical equipment or direct financial support. Businesses pay open-source developers intending to make them better address the firm’s particular needs inside projects; Wichmann (2002) found that this may affect one third of all OSS contributors.130 Surprisingly, monetary rewards have previously been found not to crowd out intrinsic motivation in OSS (Hars & Ou, 2002; Lakhani & Wolf, 2005; Roberts, Il-Horn, & Slaughter, 2006). Yet, no consistent and convincing argumentation for this phenomenon has so far been presented. Analogous to Staw et al. (1980), I argue that it is the existence (or non-existence) of a strong norm for payment which will determine whether crowding out will happen or not. In order to measure the effect of offering a (completion-contingent) monetary reward on OSS developers’ intrinsic motivation, a scenario experiment with 229 students of computer science was conducted. The findings show that intrinsic motivation is not affected by offering such a monetary reward, while total motivation even increases for the payment treatment group. Indications for crowding out of intrinsic motivation are found when looking at the effect of the existence of a strong norm for payment: a decline in self-reported interest when offered a completion-contingent monetary reward is only observed for the group that does not have a strong norm for payment, while selfreported interest increases for the group with a strong norm for payment. The latter is in accordance with individuals’ ability to self-select the projects they want to participate in and the meritocratic culture of the OSS community, both inducing that many developers will not perceive a shift in the locus of control—one of the main reasons for the crowd130

The reasons for which commercial firms might (financially) support OSS projects and OSS development have been widely addressed by the academic literature (see Chapters 2 and 3).

164

Motivation and Incentivizing of OSS Developers

ing out effect to happen—when money is introduced into their domain. As long as they perceive their task to be performed autonomously, monetary rewards might even have positive effects on developer motivation. Under certain conditions, corporations may thus well think about employing them as incentive mechanisms. The remainder of this chapter is organized as follows: first, I review the literature to explain the concepts of intrinsic and extrinsic motivation, and the nature of the crowding out effect. Next, I look at the importance of intrinsic motivation for OSS development. A description of data and methods follows. After the presentation of the results, I derive implications for theory and practice and discuss limitations of my analysis.

6.2 Theory and Hypotheses 6.2.1 Intrinsic and Extrinsic Motivation Motivation is the energization and direction of behavior, where energy describes the needs of the individual and direction the processes and structures that relate those needs to behavior (Deci & Ryan, 1985). Motivation consequently comprises several factors that may explain each individual’s overall motivation towards specific tasks (Amabile, 1983; Deci & Ryan, 1985). According to Deci and Ryan’s (1985) self-determination theory, three main types of motivation exist: intrinsic motivation, extrinsic motivation, and amotivation. Intrinsic motivation is doing an activity just because of the satisfaction derived from it, whereas extrinsic motivation is performing a task as a means to an end or due to an obligation. Amotivation results from the dislike of accomplishing an activity or the feeling of being unable to carry it out.

Figure 12: Types of motivation depending on regulatory style (Ryan & Deci, 2000)

Motivation and Incentivizing of OSS Developers

165

Figure 12 gives an overview about Deci and Ryan’s motivation continuum, which depends on self-determination and regulatory styles. While more intrinsically motivated people are satisfied through the exploring, challenging, playful, novel, spontaneous, or creative nature of the task itself, individuals who are getting tangible or intangible benefits through external intervention in order to achieve a certain outcome are said to be more extrinsically motivated (Deci & Ryan, 1985; Frey, 1994). However, an individual is not either solely motivated intrinsically or solely motivated extrinsically. As Amabile (1983) states, factors from both dimensions may be present at the same time for a particular task one is working on. In their cognitive evaluation theory, a subtheory of self-determination theory, Deci and Ryan (1985) explain factors affecting intrinsic motivation. Underlying psychological needs—the need for competence, autonomy, and relatedness—are shown to determine intrinsic motivation. Thus, any external factor affecting one or more of these needs may either undermine or enhance intrinsic motivation.

6.2.2 Crowding In and Crowding Out In the business world, external influence factors such as incentives are expected to boost effort and performance of workers, that is, reinforce motivation. Conversely, in psychology and behavioral economics, external influence has been observed to often exhibit an opposite effect on motivation. In particular, external intervention in the form of a reward or a regulation is expected to “crowd out,” that is, diminish, intrinsic motivation, leading to reduced effort in the corresponding activity (Deci et al., 1999; Frey, 1994). Regarding the underlying psychological needs, in particular self-confidence, which comprises the needs for autonomy and competence, is compromised (Bénabou & Tirole, 2003). Not every external influence necessarily undermines intrinsic motivation: the nature and way of presentation of a reward also influences its effect on intrinsic motivation (Deci & Ryan, 1985; Deci et al., 1999; Staw et al., 1980). An external reward conceived as purely informational (as opposed to controlling) by the individual may positively influence motivation.

Moreover, positive (verbal) performance feedback can boost

people’s feeling of competence and thus enhance their intrinsic motivation, while, in contrast, expected performance-contingent rewards, such as performance-based bonuses, may undermine their intrinsic motivation (Deci et al., 1999).

166

Motivation and Incentivizing of OSS Developers Task-contingent rewards, for example paying someone for successfully finishing a

task (“completion-contingent”) or even just for performing a certain task (“engagementcontingent”), may undermine intrinsic motivation. This is due to the fact that those rewards are more likely to be perceived as controlling rather than informational (Deci et al., 1999). In such a cases, the perceived locus of control shifts to outside oneself, that is, individuals feel that their behavior is controlled externally (Deci et al., 1999; Frey, 1994). An important prerequisite for applying Deci and Ryan’s cognitive evaluation theory is the intrinsic interest of an activity (Deci & Ryan, 1985). For uninteresting tasks, cognitive evaluation theory cannot be applied and a task-contingent reward may well increase performance on a task (“crowding in”) while, however, the total level of intrinsic motivation remains small (Bénabou & Tirole, 2003). The more interesting an action is perceived to be, the more external intervention is supposed to crowd out intrinsic motivation (Frey, 1994). Summarizing, if the individual perceives the outside reward as controlling, it can be expected to undermine intrinsic motivation whereas rewards perceived as an indicator of competence are likely not to exhibit such a negative effect (Deci et al., 1999).

6.2.3 Payment Norms Specifically looking at monetary rewards, an inhibitory effect on intrinsic motivation also depends on the normative information whether one should be paid for a certain task or not, the norm about payment. In case a commonly accepted, strong norm for payment exists, Staw et al. (1980) have shown that intrinsic motivation should usually not be inhibited by monetary rewards. Instead, even a positive reinforcement effect may take place as the monetary reward will be perceived as being of informational rather than controlling nature; people with a strong norm for payment might thus interpret the monetary reward analogously to positive verbal feedback (i.e., competence-enhancing). Deci and Ryan (1985) criticized that the crowding-in effect measured by Staw et al. when administrating the reward is that of fulfillment of the expectation (i.e., satisfaction) of the monetary reward, rather than an increase in intrinsic motivation. The effect captured by Staw et al. should thus be regarded as only comprising self-reported interest in the task, which is the self-report measure for intrinsic motivation (i.e., a self-reported

Motivation and Incentivizing of OSS Developers

167

measure on fun and enjoyment derived from fulfilling the task) rather than intrinsic motivation as a whole (Ryan, 1982).131 Although it is not easy to pre-determine norms towards specific tasks, an inhibitory effect of payment is to be expected for voluntary activities for which it is socially unacceptable to be paid for (Staw et al., 1980). For example, in an extensive series of interviews with community members of the open source project KDE, Allen et al. (2007) show that the respective community does not have a norm for payment and external rewards can be expected to crowd out intrinsic motivation. However, contrary to popular belief, a strong norm for payment may exist in selected areas of the OSS world. For example, Henkel (2006) demonstrates that most contributors in the field of embedded Linux are salaried or contract developers working for commercial firms; amongst those developers, a strong norm for payment is likely to exist.

6.2.4 Developers’ Motivation Previous studies have found OSS developers to both be intrinsically and extrinsically motivated to contribute to OSS projects. Intrinsic motivation. Lakhani and Wolf (2005) found that enjoyment-based intrinsic motivation is the strongest driver for OSS contributors (also see, e.g., Hars & Ou, 2002). Most often, the inherent interest in programming OSS lets people join such projects. While coding, they experience a “flow state” (Csikszentmihalyi, 1975, 1990), which is a mixture of joy, creativity and challenge. One may experience such a state through selecting projects that match one’s skill level with task difficulty (Lakhani & Wolf, 2005). A form of self-organization exists that is based on the concept “meritocracy:” the more a member has already contributed to a particular project the more he or she will have a say in what features are to be built into the application in the future, thus influencing the direction of the project (Roberts et al., 2006). Additionally, a desire to help other people (“altruism”) may be another intrinsic factor to join a project without any apparent benefit for oneself (Hars & Ou, 2002). Likewise, OSS ideology may play a strong role for the participant, that is, keeping software source code open and providing it for free to everyone (Hertel et al., 2003; Stewart & Gosain, 2006). Closely related to this is this give-and-take attitude of the OSS community (“reciprocity”) (Raymond, 131

The full intrinsic motivation inventory would further include scales on perceived competence, effort/importance, pressure/tension, perceived choice, value/usefulness, and relatedness (see http://www.psych.rochester.edu/SDT/measures/word/IMIfull.doc, retrieved April 2, 2008).

168

Motivation and Incentivizing of OSS Developers

2001b). In this sense, strong OSS ideologists may also view their contribution as a gift to the community (“gift benefit”) which they feel obliged to give since they both use OSS themselves and benefit from the extensions others did to the software (Bitzer, Schrettl, & Schröder, 2007; Wu, Gerlach, & Young, 2007). Extrinsic motivation. Hars and Ou (2002) show that—besides intrinsic interest in the activity—OSS contributors may also be extrinsically motivated (also see, e.g., Lakhani & Wolf, 2005; Lerner & Tirole, 2002): for example, one may need a fix to an existing bug or to include a missing feature or an add-on in a piece of existing software (“use need”). Sharing code and knowledge with the community may also result in others being more easily willing to give something in return (CED, 2006, p. 23). “Signaling incentives” may be another reason for participating in a specific OSS project (Hars & Ou, 2002; Lerner & Tirole, 2002): developers may be driven by gaining reputation inside the OSS community (“peer recognition”) or the ability to demonstrate their talent to possible employers by their contributions, thus using the contribution to boost their future career development (“professional status enhancement”). Coders may also enhance their programming expertise (“skill enhancement”) through receiving constructive feedback from the community by peer reviews on their contributions (Lakhani & Wolf, 2005). To avoid wasting effort, extrinsically motivated developers will thus only select to participate in OSS projects that they think will provide any benefit for them either immediately or in the future (Lerner & Tirole, 2002; Stewart & Gosain, 2006).

6.2.5 Hypotheses The OSS phenomenon is well-suited to fulfill the afore-mentioned requirements to measure the effect of payment on intrinsic motivation. In OSS projects, collaboration is usually done on a voluntary basis without receiving direct payment (Ghosh, 2006; Hars & Ou, 2002; Hertel et al., 2003; Wichmann, 2002), which would indicate that, in most cases, no strong norm for payment exists (Allen et al., 2007; Staw et al., 1980); yet there are instances in which monetary compensation for participating in OSS projects is happening. Two research questions arise from this, namely (1) is there an effect of payment on developers’ motivation, and (2) what is the role of an existing strong norm for payment in this context? Effects of payment on intrinsic motivation. Following self-determination theory, monetary intervention should crowd out intrinsic motivation (Deci & Ryan, 1985; Deci et al., 1999). However, as Frey (1994) states, extrinsic motivation should grow and, as-

Motivation and Incentivizing of OSS Developers

169

suming the level of crowded-out intrinsic motivation is compensated by a higher level of extrinsic motivation, those who are paid for their OSS contribution may even show a higher level of total motivation than their unpaid counterparts. Furthermore, another effect that cannot be clearly separated from the first one exists: OSS developers can select the projects in which they participate. Consequently, OSS developers who are more extrinsically motivated (i.e., looking for direct monetary benefits, career advancement prospects, or status or reputation enhancement) to begin with will join communities in which these needs are likely to be satisfied (Lerner & Tirole, 2002; Stewart & Gosain, 2006):132 for example, in a study on firm-hosted user communities, Jeppesen and Frederiksen (2006) show that one of the main drivers of individuals to join such communities is the desire to be recognized by the firm hosting the community. Some of the external factors presented above, such as use need, reputation enhancement, or signaling, may have been partially internalized by the individual (Roberts et al., 2006) and thus cannot be clearly identified as intrinsically or extrinsically motivating (Amabile, 1983). However, when choosing payment as a completion-contingent reward there should be a distinguishable and measurable inhibitory effect on intrinsic motivation: according to self-determination theory and cognitive evaluation theory, offering a monetary reward for completing the task should undermine intrinsic motivation (Deci & Ryan, 1985; Deci et al., 1999). Moderating effect of norms about payment. Yet, following Staw et al. (1980), the existing payment norm may moderate the effect of an external reward on intrinsic motivation. Thus, when a completion-contingent reward is offered to OSS developers, there should be different levels of intrinsic motivation measurable for each group, depending on the existence of a strong norm for payment, and the application of a monetary reward.133 Hars and Ou (2002) found salaried and contract programmers to be more strongly motivated by self-determination and personal need. Although the higher level of selfdetermination was unexpected for the paid group regarding motivation crowding theory, being a salaried or contract programmer also correlated negatively with effort, which would acknowledge motivation crowding theory. Stewart, Ammeter, and Maruping (2006) in their study on organizational sponsorship showed that, in contrast, organizational sponsorship increased interest in the respective OSS projects. Moreover, in a 132 133

And vice versa for more intrinsically motivated developers. Addressing the afore-mentioned criticism by Deci and Ryan on the Staw et al. study, I will use the term selfreported interest for my hypothesis to describe that part of intrinsic motivation that can actually be measured in the experiment generation.

170

Motivation and Incentivizing of OSS Developers

study by Lakhani and Wolf (2005), developers reported that being paid motivated them to spend more time working on OSS than their peers—second only to the level of intrinsic motivation. In the same study, being paid showed no negative impact on developers’ intrinsic motivation, meaning that no crowding out happened. The authors argued that project contributors may have already “internalized” extrinsic motivation and that interplay between extrinsic and intrinsic motivation hindered dominant motives from crowding out each other.134 Another survey from Roberts et al. (2006) found no crowding out of intrinsic but of internalized extrinsic motivation—such as use need, reputation, and signaling incentives—and thus suggests OSS communities to be open for commercial sponsors. However, it was also recommended to further examine the various effects by an experiment. In this chapter, I will conduct such an experiment based on the research of Staw et al. (1980), who showed that an important moderating factor on the effect of a monetary reward of intrinsic motivation is the existence of a norm with respect to the administration of payment. Following their findings, I do not expect developers who perceive receiving payment for working on an OSS project as fully acceptable to report lower levels of intrinsic motivation—as measured by self-reported interest—when they are presented a completion-contingent reward. In fact, even an increase in self-reported interest may be observable. An inhibitory effect of the completion-contingent reward on selfreported interest, however, is expected for the group that is not fully convinced that receiving payment for working on an OSS project is acceptable, or that even outright rejects it. Thus comparing individuals who receive a monetary reward with a control group, self-reported interest should decrease for developers not having a strong norm for payment.

H1: When offered a completion-contingent reward for working on an OSS project, self-reported interest of developers will only decrease when they do not have a strong norm for payment. Effects on total motivation. Frey (1994), in his explanation of the outcomes of external intervention, states that two effects, a disciplining effect and a crowding effect of the reward, may determine how overall motivation looks like. If crowding out caused by an 134

A caveat may be in order. As Lakhani and Wolf (2005) do not distinguish between different types of payment in their paper, we do not know whether the participants in their study were actually confronted with a type of reward that, following self-determination theory and cognitive evaluation theory, should have led to crowding out. I am indebted to Joachim Henkel for pointing this out to me.

Motivation and Incentivizing of OSS Developers

171

external reward is greater than the disciplining effect, overall motivation is reduced to a level even smaller than its initial level. If crowding out is smaller than the disciplining effect, or even follows the direction of the disciplining effect and adds to intrinsic motivation (“crowding in”), overall motivation increases. Depending on the existence of a strong norm for payment, receiving completioncontingent payment should negatively (no strong norm for payment group) or not negatively (strong norm for payment group) affect an individual’s intrinsic motivation while exerting a positive effect on their extrinsic motivation. As past studies (see H1) have not shown a significantly negative effect of payment on intrinsic motivation, we can assume that the overall effect of the administration of payment on total motivation is significantly positive. More specifically, I expect to see a positive and significant effect for the group with a strong norm for payment. For the other group, theory does not give a clear indication of the direction of the effect; an explorative hypothesis assuming the external reward should at least offset the negative effects on intrinsic motivation will be tested.

H2: Total motivation of developers will increase when they are offered a completion-contingent reward for working on an OSS project.

H2a: Total motivation of developers with a strong norm for payment will increase when they are offered a completion-contingent reward for working on an OSS project.

H2b: Total motivation of developers without a strong norm for payment will not decrease when they are offered a completion-contingent reward for working on an OSS project.

6.3 Data and Method 6.3.1 Method In this chapter, an online survey was combined with a scenario experiment, that is, participants completed an online questionnaire of which the scenario experiment was part. They were further asked for demographic information as well as general and motivational questions about previous and current OSS projects and experience.

172

Motivation and Incentivizing of OSS Developers To realize the experiment, participants were randomly assigned to one of two ver-

sions of the survey which differed in only one question presenting the scenario. Pretests had been carried out with a rather generic OSS scenario but participants indicated that a more specific scenario design was necessary which was then again pretested and found to be valid. The final scenario described a fictional Voice over IP (VoIP) OSS project, for which interest was assumed to be high among the participants, making cognitive evaluation theory applicable. The two scenarios in the two versions of the survey contained the same basic description, but only in one were participants offered a payment upon successful project completion (completion-contingent reward). The exact wording is displayed in Table 39. Additionally, I controlled for the existence of a strong norm for payment for each participant (see below). Combining treatment and existence of a strong norm for payment resulted in a 2 x 2 design similar to the one used by Staw et al. (1980), which allowed for analyzing between-subject effects and, in particular, the interaction effect between the existence of a strong norm for payment and the administration of payment. Imagine the following situation: Standard Scenario Text

You have received an email of the project leader of a newly created OSS project in the area of Voice over IP (VoIP). As VoIP is something you have been interested in for a long time, you know that no competing OSS project exists. The project leader is inviting you to participate in the project. In his mail, he describes a set of tasks that would most likely be assigned to you in case you accepted. He also estimates that the project will be completed in six months time. After reading the list of tasks, you realize that those tasks are challenging but feasible with your level of programming skill. They would require you to spend an average of 5 hours per week on the project (No matter your current situation, please imagine you could easily spend this much time on the project).

Treatment Supple-

Additionally, the project manager tells you that all project team members who complete their tasks within the six month timeframe will be awarded $2,500. The money is provided by an organizational sponsor of the project.

Table 39: Scenario text

6.3.2 Sample The survey was conducted between February 5 and March 6 2007 and resulted in 229 valid responses. Computer science departments of several technical universities in Austria, Germany, and Switzerland were requested to forward or post an invitation email for the OSS survey on their students’ mailing list or newsgroup. Out of the 229 respondents, 90 had previously engaged in OSS projects and the remaining 139 were

Motivation and Incentivizing of OSS Developers

173

strongly familiar with the topic. To minimize social desirability and selection bias with respect to the research questions, the survey was advertised to be about programmer’s experiences with OSS and not about experiences with or attitudes towards payment in OSS. Those who chose to answer the survey were randomly assigned to either the treatment or the control group. Whereas a problem of self-selection inherent to this type of survey remains, comparing the sample with that of previous studies showed no significant differences.135 Furthermore, two informal interviews were conducted with industry experts who confirmed the validity of the scenario, sample, and the design of the payment norm. Treatment and control group. As described above, individuals were randomly assigned to either the treatment or the control group. The fictional OSS project was presented to both groups, however, individuals assigned to the treatment group were also promised a financial reward upon completion of the scenario project. Strong norm for payment. The operationalization of the strong norm for payment depended on whether individuals had previously engaged in OSS projects or not.136 For people who had previously engaged in OSS projects, they were asked how often they had received any kind of monetary compensation for this. If this number was larger than zero, a strong norm for payment was assumed to exist, that is, that those people would fully agree that it was acceptable to receive a monetary reward for working on OSS. Those people who had participated in OSS projects without receiving monetary compensation were assumed not to have a strong norm for payment. In both cases, a dummy variable measuring the existence of a “strong norm for payment” was set accordingly.137

135

136

137

In the samples by Hertel et al. and Lakhani and Wolf approximately 40 percent of the contributors were paid to participate in a particular OSS project. In my sample, 38 percent of the 90 contributors had received payment for their contributions. The average age was 30 years in all three studies of Hars and Ou, Hertel et al. and Lakhani and Wolf, thus compared to the present sample’s mean of 26 years, those participants were four years older on average. This is attributable to the fact that the main target group in this survey was students. Results for gender are similar: compared to 89 percent male participants in this sample, in previous studies 95 percent (Hars and Ou, Hertel et al.) and 98 percent (Lakhani and Wolf) were male. Controlling for differences between the two groups (worked on OSS project before, never worked on OSS projects before), I found that people who had not worked on OSS projects before showed slightly higher scores on the enjoyment measure, which is consistent with previous studies (Hertel et al., 2003). When including a dummy variable measuring whether people had previously participated in OSS projects in the regression reported later, (1) the variable itself is insignificant and (2) all other coefficients keep their sign and level of significance. At first glance, the classification of individuals who worked on OSS projects in the past might be problematic. For example, while most people will have deliberately self-selected on a project if they had a strong norm for payment, some of the people who have not yet worked on paid projects might just not yet have had the opportunity to do so, but still had a strong norm for payment initially. However, by working on a non-paid project, that is, a project without a strong norm for payment (or even one against payment), those individuals will come in contact with others and their different predominant norm, which will in turn influence their normative beliefs and weaken their strong norm for payment (Ajzen, 2005; Ashforth & Mael, 1989; Fazio, Zanna, & Cooper, 1978; Fazio & Zanna, 1981; Hogg & Terry, 2000).

174

Motivation and Incentivizing of OSS Developers For people who had not previously participated in OSS projects, the fictional project

presented to them would logically have been their first contribution to an OSS project ever. Their participation in past work can thus obviously not reveal whether they have a strong norm for payment or not; their respective norm should rest on their knowledge and perception of OSS, OSS communities, and the OSS culture. Comparable to the creation of a norm by Staw et al. (1980), the existence of a strong norm for payment was consequently operationalized based on the reply to the statement “I think it is OK if people get paid for working on OSS projects” which was coded on a 1 (strongly disagree) to 5 (strongly agree) Likert scale.138 To be able to combine both groups of developers (i.e., those who had and those who had not developed OSS previously), this variable also needed to be transformed to a dummy variable: a strong norm for payment was assumed for people who strongly agreed to this statement, the opposite norm for all others.139 The sample split according to the grouping variables is shown in Table 40.

Sample Split

Treatment Control Total

Strong Norm for Payment

58

47

105

No Strong Norm for Payment

57

67

124

Total

115

114

229

Table 40: Sample split according to grouping variables

6.3.3 Dependent and Control Variables After presenting the fictional OSS project to all survey participants, they were asked to indicate their agreement to several statements measuring their motivation operationalized on 1 (strongly disagree) to 5 (strongly agree) Likert scales. The focus of this study lay on the measurement of intrinsic motivation through self-reported interest consistent with self-determination theory and the Intrinsic Motivation Index (Ryan, 1982) and of total motivation. For self-reported interest, this was achieved through the respective items “I would have fun working on this project” and “Participating in this OSS project would be enjoyable.” For total motivation, too, two items were included to measure the 138

139

Descriptive statistics of this variable are as follows: Median = 5, Mean = 4.3, Standard Deviation = 0.83, Minimum = 1, Maximum = 5. Splitting the “strong norm for payment” at the value of five implies that people who “somewhat agree” to the question on whether they think that the administration of monetary rewards in OSS projects is acceptable are assigned to the “no strong norm for payment” group. This is consistent with the idea that the administration of payment may only have positive effects on self-reported interest for people with a strong norm for payment. Yet, it may seem less plausible to argue that these people would negatively react to the administration of payment, as was predicted for people without a strong norm for payment. Following this argumentation, all calculations were also conducted dropping the group from the sample. As results remained largely unchanged, the specification including this group is reported.

Motivation and Incentivizing of OSS Developers

175

general willingness (“I could imagine working for this project”) and eagerness (“I would rate my participation in this project as an important activity to myself”) to participate in the fictional OSS project. To minimize social desirability, all statements were randomly ordered and mixed with those measuring the control variables. Descriptive statistics on the dependent variables are given in Table 41. Factor analysis (principal component analysis was used; see, e.g., Hair et al., 2005) confirmed the reliability of the two resulting factors (self-reported interest: α = 0.81; total motivation: α = 0.70).140 Regarding control variables, based on the literature analysis, I selected statements from past studies (Amabile, Hill, Hennessey, & Tighe, 1994; Hars & Ou, 2002; Lakhani & Wolf, 2005; Ryan, 1982) on motivation in general, and on motivation in OSS contexts in particular, to measure self-determination, reciprocity, use need, and extrinsic motivation, the latter being required for the measurements of the effects of total motivation, and adapted them accordingly. Factor analysis using the Kaiser criterion (Hair et al., 2005) rendered a four-factor model explaining 60% of total variance. The variables and their rotated factor loadings are shown in Table 42.

Variable

N Med. Mean Std. Min. Max. Dev.

Share 4&5

I would have fun working on this project (Fun)

227

4

4.07

0.77 1

5

80.18%

Participating in this OSS project would be enjoyable (Enjoy)

229

4

4.04

0.8

5

78.60%

Index Self-Reported Interest (Fun, Enjoy)

229

4

4.06

0.73 1.5

5

73.36%

I could imagine working for this

229

5

4.34

0.84 2

5

88.21%

228

4

3.97

0.97 1

5

71.49%

229

4.5

4.15

0.78 2

5

73.80%

2

project (Willingness) I would rate my participation in this project as an important activity to myself (Eagerness) Index Total Motivation (Willingness, Eagerness)

Table 41: Descriptive statistics for the dependent variables

140

Stata 9.2 was employed for the factor analyses reported in this chapter.

176

Motivation and Incentivizing of OSS Developers

Item

Self de-

Reci-

Extrinsic

ter-

procity

motivation need

Use

mination I think I could set my own goals in this

0.71

project. This OS project would allow me to be

0.58

creative and realize new ideas. I think I could select tasks that match my 0.73 abilities in this project. I think I could freely choose my tasks

0.72

necessary in this project. I believe I could bring in my ideas into

0.69

this project. I feel a personal obligation to contribute

0.89

to this project since I use OS software. For me, my contribution to the OS

0.85

project would be a kind of a gift back to the OS community. Engaging in this OS project would en-

0.76

hance my skill base. My contribution to this project would

0.77

enhance my professional status. If I engaged in this OS project, I think I

0.42

would get objective feedback. Participating in this project would give

0.55

me a feeling of competence. My contribution to this project would

0.41

0.42

enhance my reputation in the OS software community. My contribution to this project would

0.90

create specific functionality in the code needed for my work life. My contribution to this project would create specific functionality in the code needed for non-work life. Table 42: Factor analysis after varimax rotation (only loadings > 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.