Open Source Product Development: The Meaning and Relevance of Openness

Kerstin Balka Open Source Product Development

GABLER RESEARCH Forschungs-/Entwicklungs-/InnovationsManagement Herausgegeben von Professor Dr. Hans Dietmar Bürgel (em.) Universität Stuttgart Professorin Dr. Diana Grosse, vorm. de Pay Technische Universität Bergakademie Freiberg Professor Dr. Cornelius Herstatt Technische Universität Hamburg-Harburg Professor Dr. Hans Koller Universität der Bundeswehr Hamburg Professor Dr. Martin G. Möhrle Universität Bremen

Die Reihe stellt aus integrierter Sicht von Betriebswirtschaft und Technik Arbeitsergebnisse auf den Gebieten Forschung, Entwicklung und Innovation vor. Die einzelnen Beiträge sollen dem wissenschaftlichen Fortschritt dienen und die Forderungen der Praxis auf Umsetzbarkeit erfüllen.

Kerstin Balka

Open Source Product Development The Meaning and Relevance of Openness With a foreword by Prof. Dr. Cornelius Herstatt

RESEARCH

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.

Doctoral thesis, Hamburg University of Technology Hamburg-Harburg, 2011

1st Edition 2011 All rights reserved © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011 Editorial Office: Marta Grabowski | Sabine Schöller Gabler Verlag is a brand of Springer Fachmedien. Springer Fachmedien is part of 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: KünkelLopka Medienentwicklung, Heidelberg Printed on acid-free paper Printed in Germany ISBN 978-3-8349-3153-5

Foreword Open source software development has received considerable scholarly attention, much of which is based on the presumption that the ‘open source model’ holds some lessons of broader applicability. Nonetheless, knowledge of its deployment outside the software industry is very limited. Until recently, limitations to the availability of successful empirical examples of this ‘new innovation model’ outside software may have been a key reason for this gap. Kerstin Balka’s dissertation focuses on the open source development of tangible objects, so-called open design. She proposes a generalized definition of open source development and a more careful treatment of the meaning of openness. Openness is often regarded as a dichotomous variable (open-source vs. closed-source) and it is assumed that online developer communities demand full opening of the product’s source. To explore the landscape of open source development in the world of atoms, this dissertation presents a comprehensive study of open design projects (n = 104) in order to analyze project characteristics, structures, and success, and to investigate similarities and dissimilarities to open source software development. Drawing on six comparative case studies, it subsequently analyzes the workings of open design in close detail. The following quantitative study aims to explore openness as a gradual and multi-dimensional concept. Kerstin Balka conducts an Internet survey (n = 309) among participants of 20 open design communities in the domain of IT hardware and consumer electronics. She finds that open design projects pursue complex strategies short of complete openness and that communities value openness of software more highly than openness of hardware. A multilevel statistical model shows how openness impacts developer’s satisfaction and their contribution. The findings of Kerstin Balka show that open source development can be successfully applied to physical objects as tangible products can be increasingly developed like digital products. They further suggest that open design companies can successfully implement strategies of partial openness to safeguard value capture without alienating their developer community.

VI This dissertation addresses both academics and practitioners and becomes a “must read” for everybody dealing with the phenomenon of Open Source Innovation in theory and practice.

Univ. Prof. Dr. Cornelius Herstatt

Preface This dissertation presents research on open design and openness that I conducted between 2008 and 2010 at the institute of Technology and Innovation Management at Hamburg University of Technology. Though only my name appears on the cover of this document, a great number of people have supported and inspired me throughout its development. I owe my gratitude to all those people who have made this dissertation possible and because of whom my dissertation experience has been so enjoyable and valuable. First and foremost I would like to thank my advisor, Prof. Dr. Cornelius Herstatt, for his time, support and insight. He continually encouraged me and his enthusiasm has always motivated me. I am also grateful to Prof. Dr. Thorsten Blecker for being my co-advisor and for leading and driving our joint research project on the transferability of open source to other industries. I am thankful for having had the opportunity to be part of a great team at the chair. I would especially like to thank Dr. Christina Raasch for her constant encouragement and support. She always found the time for helpful comments and continually challenged my thinking. Further I would like to thank the entire team for the exchange and support at our chair. This dissertation would not have been possible without the great support from the larger open source community. I would like to thank all contributors to open-innovation-projects.org, my interview partners, in particular Harald Welte, Dr. Michael Laurer, Dr. Adrian Bowyer, Zach Smith, and Erik de Bruijn, and all participants of my survey for their time and commitment. Most importantly, I am grateful to my family and friends. I thank my parents for their love and support in every stage of my live although my plans and ambitions often keep me away from home. I thank my boyfriend Simon for his encouragement of my research work. He technically supported openinnovation-projects.org and my survey. He also was one of the most critical reviewers of this dissertation and an important advisor with whom I could discuss and probe my thoughts. And I thank all my friends who encouraged me with their faith in me and who had helpful advices whenever needed. Kerstin Balka

Contents Contents

IX

List of Figures

XIII

List of Tables

XV

List of Abbreviations

I

XVII

Focus and scope

1

1 Introduction 1.1 Statement of the research problem and relevance . . . . . . . . 1.2 Research design and approach . . . . . . . . . . . . . . . . . . 1.3 Structure of the document . . . . . . . . . . . . . . . . . . . .

3 3 6 7

2 Definition of terms

9

II

Theoretical and methodological foundation

3 Perspectives from prior literature 3.1 The private and collective investment models . . . . . . . . . 3.2 The meaning of openness . . . . . . . . . . . . . . . . . . . . 3.2.1 Openness as a gradual concept . . . . . . . . . . . . . 3.2.2 Aspects of openness . . . . . . . . . . . . . . . . . . . 3.2.3 The community’s perspective . . . . . . . . . . . . . 3.3 Open source software versus hardware . . . . . . . . . . . . 3.3.1 Empirical studies of open source software . . . . . . . 3.3.2 Empirical relevance of open source beyond software . 3.3.3 Why is the situation different for digital and physical products? . . . . . . . . . . . . . . . . . . . . . . . .

11 . . . . . . . .

13 13 15 16 18 19 20 21 22

. 23

X

Contents 3.3.4 But, hardware is becoming much more like software . 3.4 Why do firms get involved? . . . . . . . . . . . . . . . . . . 3.4.1 The firm as a collection of productive resources and dynamic capabilities . . . . . . . . . . . . . . . . . . 3.4.2 Value creation and value capture . . . . . . . . . . . 3.4.3 Reasons for firms to freely reveal . . . . . . . . . . . 3.4.4 OS business models . . . . . . . . . . . . . . . . . . . 3.5 Conclusions and implications for this research . . . . . . . .

4 Research design and methodology 4.1 Open source innovation (OSI) . . . . . . . . . . . . . 4.1.1 A disambiguation of OSI . . . . . . . . . . . . 4.1.2 A conceptual framework for studying OSI . . 4.2 Detailed research questions and resultant propositions 4.3 Methodological research approach . . . . . . . . . . . 4.3.1 To discover the variety of open design . . . . . 4.3.2 To understand how open design works . . . . 4.3.3 To investigate the meaning of openness . . . .

III

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. 24 . 25 . . . . .

25 26 28 29 30

. . . . . . . .

33 33 33 34 35 42 44 47 48

On the variety of open design

49

5 Study 1: The open design landscape 51 5.1 The variety of open design . . . . . . . . . . . . . . . . . . . . 51 5.2 Multivariate analysis . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Discussion of outcomes and research propositions rethought . . 63 6 Study 2: Open design of tangible goods – A comparative case study 6.1 Overview of cases . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Case descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 How does open design work? . . . . . . . . . . . . . . . . . . . 6.3.1 Who drives open design projects? . . . . . . . . . . . . 6.3.2 What is being developed? . . . . . . . . . . . . . . . . 6.3.3 How are open designs developed and produced? . . . . 6.3.4 Is open design really open? . . . . . . . . . . . . . . . . 7 Intermediate conclusions and implications 7.1 Discussion of first findings . . . . . . . . . 7.2 Replicability as a third aspect of openness 7.3 Derivation of research hypotheses . . . . .

for . . . . . .

67 67 68 72 72 73 75 76

proceeding 79 . . . . . . . . . 79 . . . . . . . . . 81 . . . . . . . . . 83

Contents

XI

IV

87

On openness in open design

8 Survey approach 8.1 Questionnaire development 8.2 Selection of communities . 8.3 Data collection . . . . . . 8.4 The sample . . . . . . . . 8.5 Data preparation . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

89 89 91 91 92 93

9 Study 3: The meaning of openness is not trivial 101 9.1 Software is more open than hardware . . . . . . . . . . . . . . 102 9.2 Openness is important to open design communities . . . . . . 103 9.3 Openness of software components is more important than openness of hardware components . . . . . . . . . . . . . . . . . . 104 9.4 Highly active developers value openness more than less active developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 9.5 The duration of participation does not influence perceived importance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10 Study 4: How openness impacts developer’s satisfaction and their contribution 109 10.1 Ordinary linear regression models on satisfaction . . . . . . . . 109 10.2 Multilevel models on developer satisfaction . . . . . . . . . . . 111 10.3 Do expectations towards openness influence this relationship? 124 10.4 Effects on contributed working hours . . . . . . . . . . . . . . 125

V

Integration of findings

11 Discussion of findings 11.1 Summary of findings . . . . . . . . . . . . . . . . . . . . . . 11.2 Open source software versus hardware - revisited . . . . . . . 11.3 Scope of generalization and limitations . . . . . . . . . . . .

131 133 . 133 . 138 . 140

12 Conclusions 143 12.1 Implications for theory . . . . . . . . . . . . . . . . . . . . . . 143 12.2 Managerial implications . . . . . . . . . . . . . . . . . . . . . 145 12.3 Implications for future research . . . . . . . . . . . . . . . . . 147

XII

VI

Contents

Appendices

149

A Variable explanations

151

B Details – Case study 155 B.1 Interview guideline . . . . . . . . . . . . . . . . . . . . . . . . 155 B.2 List of interviews . . . . . . . . . . . . . . . . . . . . . . . . . 157 C Details – Survey 159 C.1 Questionnaire: How open is open source - software and beyond 159 C.2 Survey results . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 C.3 Stability tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 D Alternative models D.1 More ordinary linear models . . . . . D.2 Details for selected multilevel models D.3 Transformations to normality . . . . D.4 Models considering expectations . . . References

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

169 169 171 173 179 181

List of Figures 4.1 4.2 4.3

The open source innovation framework . . . . . . . . . . . . . 35 Unique human visitors from September, 2008 to March, 2010 . 45 Break down of approved projects on reasons for exclusion and selected cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1

Background of contributing actors and distribution of number of developers in projects . . . . . . . . . . . . . . . . . . . . 5.2 Typification and complexity of developed objects . . . . . . 5.3 Type of selected license and degree of openness . . . . . . . 5.4 Distribution of actors promoting and coordinating the development and of producing actors . . . . . . . . . . . . . . . . 5.5 Start year and activity across projects . . . . . . . . . . . . 5.6 Distribution of stages of advancement in projects . . . . . . 5.7 Intended audience and degree of innovativeness . . . . . . . 5.8 Distribution across industries . . . . . . . . . . . . . . . . . 5.9 Home countries and means of communication . . . . . . . . 5.10 Comparison of developer community size and activity against development status . . . . . . . . . . . . . . . . . . . . . . .

. 52 . 53 . 54 . . . . . .

56 57 57 58 59 60

. 61

6.1

Complexity and innovativeness of developed objects versus stage of advancement . . . . . . . . . . . . . . . . . . . . . . . 74

8.1

8.4

Histograms of self-reported weekly contributed working hours and duration of activity . . . . . . . . . . . . . . . . . . . . Hierarchical variable clustering of survey results for hardware and software . . . . . . . . . . . . . . . . . . . . . . . . . . . Scatter plot matrix of the five main constructs with univariate density estimates down the diagonal . . . . . . . . . . . . . . Histogram of transformed weekly contributed working hours

9.1 9.2

Histograms showing ratings of importance of openness . . . . 103 The importance of openness for software and hardware . . . . 105

8.2 8.3

. 93 . 94 . 96 . 100

XIV

List of Figures

10.1 Diagnostic plots of an ordinary linear regression model (Model 10.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Scatter plots of satisfaction vs. openness for 20 communities 10.3 Normal distribution checks for model 10.2 . . . . . . . . . . 10.4 Normal distribution checks for Model 10.3 . . . . . . . . . . 10.5 Normal distribution checks for Model 10.8 . . . . . . . . . . 10.6 How openness impacts satisfaction (Model 10.8) . . . . . . . 10.7 Modeling the influence of expectations . . . . . . . . . . . . 10.8 Check for normal distribution for Model 10.9 . . . . . . . . . 10.9 The relation of openness, satisfaction, and contributed working hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . .

110 112 115 117 121 123 125 127

. 128

D.1 Normal distribution checks for model 10.5 . . . . . . . . . . . 172

List of Tables 4.1

Summary of my methodological research approach . . . . . . . 44

5.1

Estimated correlations between selected variables . . . . . . . 62

6.1 6.2

Overview of selected cases . . . . . . . . . . . . . . . . . . . . 68 Examples of ‘open parts’ and ‘partly open’ strategies in open design projects . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1 8.2 8.3

List of surveyed communities . . . . . . . . Correlations between pairs of constructs . Main characteristics of constructs including missing data imputation . . . . . . . . . .

9.1 9.2 9.3

Degrees of openness for software and hardware components . Importance of openness to participants . . . . . . . . . . . . Differences in importance of openness between software and hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Perceived importance of openness across activity levels . . . P-values of differences across developers activity levels concerning importance of openness . . . . . . . . . . . . . . . . Perceived importance of openness across duration levels . . .

9.4 9.5 9.6

. . . . . . . . . . . . . . implications . . . . . . .

. . . . 91 . . . . 97 from . . . . 98 . 102 . 103 . 104 . 106 . 106 . 107

10.1 Comparison of multilevel models showing AICs and p-values from ANOVAs . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 10.2 Correlations between conformance to expectations and developer satisfaction or the respective constructs themselves . . . . 125 11.1 Five main research questions . . . . . . . . . . . . . . . . . . . 134 11.2 Overview of research propositions . . . . . . . . . . . . . . . . 135 11.3 Overview of research hypotheses . . . . . . . . . . . . . . . . . 136 B.1 List of interviews . . . . . . . . . . . . . . . . . . . . . . . . . 158 C.1 Exemplary results from stability tests . . . . . . . . . . . . . . 167

List of Abbreviations Content-specific abbreviations F/OSS OS OSS OSI OD IP IPR NDA GNU GPL BSD MIT CC

Free/Libre Open Source Software Open Source Open Source Software Open Source Innovation Open Design Intellectual Property Intellectual Property Rights Non-disclosure agreement GNU is not Unix GNU General Public License Berkeley Software Distribution Massachusetts Institute of Technology Creative Commons

Mathematical abbreviations ANOVA Analysis of variance AIC Akaike Information Criterion BIC Bayesian Information Criterion DF Degrees of freedom n Number of observations n.s. not significant NAs Missing values p p-value μ Arithmetic sample mean σ2 Sample variance ρ Correlation coefficient

XVIII

List of abbreviations

Abbreviations in modeling SW HW S O T A R C I

Software Hardware Satisfaction Openness Transparency Accessibility Replicability Complexity Innovativeness

Abbreviations of survey responses SD D N A SA

Strongly disagree (1) Disagree (2) Neutral (3) Agree (4) Strongly agree (5)

Indication of significance levels + * ** ***

p-value p-value p-value p-value

< 10% < 5% < 1% < 0.1%

General abbreviations cf. compare (confer) e.g. for example (exempli gratia) et al. and others (et alii) etc. et cetera i.e. that is (id est) p. page vs. versus R&D Research and development CEO Chief Executive Officer OEM Original Equipment Manufacturer

Part I Focus and scope

Chapter 1 Introduction 1.1

Statement of the research problem and relevance

A striking phenomenon in recent years has been the rise of open source software. Source codes are freely revealed via the Internet, allowing geographically distributed programmers to download and utilize the software, to suggest improvements to the community, or to make modifications themselves and to redistribute their modified code. A large number of successful examples of open source software programs have been developed and extensive research has been undertaken to analyze this phenomenon from different perspectives (von Krogh & von Hippel, 2006b). A natural initial question is, what open source software is. The term open source originates from the software industry. Roughly speaking, an open source software program grants access to the source code, and not only the object code (the sequence of 1’s and 0’s that computers actually use), and allows that the modifications made by its users are turned back to the community. The details vary with the license adopted for the program. Some of the key criteria included in the Open Source Definition1 are the free redistribution of the program, the release of the source code to everybody, the requirement that modifications may be distributed under the same terms as the license of the original software, and the constraint that the license must not discriminate against any person or specific field of endeavor (e.g. Lerner, 2005; Perens, 1999). 1

http://www.opensource.org/osd.html

K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

4

Chapter 1. Introduction

But, what does open source mean for tangible products? Open hardware is hardware that is developed in the same manner as open source software. Typically, these are projects in which the creators have decided to completely publish all the source code, schematics, firmware, software, bill of materials, parts list, drawings, board files, design files, recipes, instructions, etc. needed to access and recreate the product. Examples range from simple products as beverages or blinking lights to highly complex products as medical equipment, powering devices, and 3D printers. In contrast to the software industry, only little is known about open source development of tangible objects so far. Until recently, limitations to the availability of successful empirical examples of this ‘new innovation model’ outside software may have been a key reason for this gap. In the academic literature, the term ‘open design’ (Vallance, Kiani, & Nayfeh, 2001) provides a framework for sharing information stemming from IT hardware as well as other physical objects. This design has different effects on aesthetics, usability, manufacturing, quality, and so forth. Further, open source development is typically understood as open collaborative development, i.e. information is not only shared, but exploited to contribute to a common development (Shah, 2006; Osterloh & Rota, 2007). The development of digital and physical objects shows similarities as well as differences. Thus, the question arises whether the open source model of product development holds some lessons of broader applicability (Nuvolari & Rullani, 2007, p.227). Many researchers view the OS model as a system of communal production (Gl¨aser, 2007) for which software offers an advantageous, but by no means exclusive environment (von Krogh & von Hippel, 2003a; Shirky, 2005; Chesbrough & Appleyard, 2007). If, however, ‘open source beyond software’ is not an oxymoron, researchers should strive to extend their knowledge of the factors influencing the transferability of this development model to other domains. While research on OSS provides some insights for industries beyond software, Dahlander and Magnusson (2008) point out that “there is a wider need to understand how communities outside the hierarchical control of managers can be used in an effective manner” in other settings (p. 646). Physical, as opposed to purely digital, products are often regarded as less suited to the open source mode of product development as known from OSS (von Krogh & von Hippel, 2003a). Understanding the open source landscape beyond software forms one of two major goals of this dissertation. This involves two basic questions: first, what kind of open design projects emerged so far?; and second, how does

Chapter 1. Introduction

5

open design work in practical examples? The first question is particularly relevant to develop an understanding of the variety of open design projects and build a thorough empirical basis for further research. Up to now, only selected case studies have been conducted to investigate open source beyond software (e.g. Hope, 2005; K¨as, 2008). The second question addresses concerns frequently mentioned in the literature, that open source development might be less suitable for tangible products (e.g. G. K. Lee & Cole, 2003; Lerner & Tirole, 2004; Demil & Lecocq, 2005). My research aims to investigate the practical applicability of open source beyond software and to derive conclusions concerning differences and similarities of software and hardware in this realm. Traditionally the protection of intellectual property is regarded as a precondition for value capture. The rise of open source software and OS tangible products has challenged this understanding. Openness is typically regarded as a dichotomous variable (open-source vs. closed-source) and open source innovation is understood to be ‘extremely open’ (cf. Gassmann, 2006) since it requires information to be freely revealed to all. The innovator gives up the right to exclusive exploitation of her invention (Harhoff, Henkel, & von Hippel, 2003) - a strategy that must seem injurious to any degree of value capture. Accordingly, researchers have been puzzled by many inconsistencies of the open source model with the private investment model of innovation (Lerner & Tirole, 2001). Specifically, the motivations of supposedly rational individuals and companies to contribute to such projects and the seemingly self-contradictory notion of open-source business models have been a focus of research (Hecker, 1999; von Krogh et al., 2008). Only recently researchers start to question the dialectic structure of the concept of openness and find that firms decide to engage in open source activities selectively (Henkel, 2006). To gain advantages over their competitors, they may use openness strategically (Fosfuri, Giarratana, & Luzzi, 2008). West and O’Mahony (2008) and Henkel (2006) are among the very few who explore openness as a gradual and multi-dimensional concept and link intermediate levels of openness to value capture. However, despite proliferating research on open source innovation, the entire construct of openness has received too little attention to date, both theoretically and empirically. Up to now existing research in the realm of open source has focused on static perspectives of the phenomenon. The dynamics of openness have not yet been studied systematically. Yet this is an important area of research, as openness is becoming ever more important in today’s society and business. The second main goal of this dissertation is exploring the meaning of open-

6

Chapter 1. Introduction

ness in the context of open source, discovering aspects of openness, and systematically studying its impact on developer’s satisfaction and contribution. This includes another three main research questions: first, does the degree of openness matter to the communities?; second, does the meaning of openness differ between open source software and open design?; and third, how does openness impact developer’s satisfaction and their contributions? The first of these three questions aims to address the relevance of openness and thereby forms a prerequisite for more systematic research on the topic of openness. Previous literature treats openness as an essential characteristic of OSS (Nakakoji et al., 2002; West & O’Mahony, 2008). Thereby it leaves out two issues. First, do communities actually ask for openness, and second, is openness just a matter of course or does it have a sophisticated meaning to developers. A consistent analysis of the importance of openness of software and hardware follows with the second of these three research questions. For this purpose I propose to distinguish different aspects of openness and to systematically analyze importance of openness for each of its aspects. Finally, the last research question deals with the dynamics of openness and addresses its impact on the developers of a community.

1.2

Research design and approach

The research questions are studied empirically, analyzing open source projects outside software. A multimethod design linking qualitative and quantitative methods is used for the purpose of this research. Methodological triangulation, defined as “the combination of methodologies in the study of the same phenomenon” (Denzin, 1970, p.297) is supposed to improve the accuracy and validity of a study by relying on data from more than one method (Jick, 1979). The research approach should be influenced by the stage of the current literature (Edmondson & McManus, 2007) and subsequently by the type of research question (Yin, 2003). Due to the dearth of prior knowledge on the investigated topic, open-ended research questions have been formulated to attain the first goal of this dissertation. They require methods that allow data collected in the field to strongly shape the researcher’s developing understanding of the phenomenon. I therefore address the first main issue of this document via a broad field study to the phenomenon of interest and a comparative case study.

Chapter 1. Introduction

7

Subsequently I inductively develop clear-cut research hypotheses based on my previous findings to address the second main issue. As recommended for more focused questions and hypotheses relating constructs, I then conduct a survey to systematically obtain data from open source communities. In addition to methodological triangulation, I also use data triangulation to improve the validity of results. One strategy for data triangulation is to evaluate data from different sources. For my case study, I therefore conduct interviews, follow chat conversations and use archival data such as mailing lists, articles, forum posts, etc. to validate the results.

1.3

Structure of the document

This dissertation comprises five main parts divided into twelve chapters. The first part contains Chapter 1, the introduction with a concise outline of the research focus and approach, and a short Chapter 2 deriving and explaining the most important terms frequently used in this document. The second part starts with Chapter 3 providing perspectives of previous literature. More specifically, it reviews prior work on the meaning of openness and links existing concepts (3.2). Then it outlines prior empirical studies of open source software and hardware to arrive at potential differences and similarities between the two domains (3.3). Finally it discusses prior knowledge on reasons for firms to get involved and potential OS business models (3.4). Chapter 4 describes the empirical setting in more detail. It first explains the term ‘Open Source Innovation’ and presents a conceptual framework for studying this topic (4.1). Along this framework it presents more detailed research questions and proposes research propositions (4.2). It then outlines the methodological research approach, first concerning the entire setting, and then for the specific research methods used in this study (4.3). The third part treats the first of two main topics of this thesis, namely discovering and understanding the open source landscape beyond software. Chapter 5 starts with exploring the variety of open design along the OSI framework (5.1) analyzing project characteristics and structures. In a multivariate analysis it links the investigated artifacts (5.2) in order to arrive at conclusions for my research propositions investigating similarities and dissimilarities to open source software development (5.3). Chapter 6 presents a comparative case study analyzing the mechanisms of open design. Six projects stemming from different industries and back-

8

Chapter 1. Introduction

grounds are introduced (6.1 and 6.2) and then studied in close detail to investigate their workings (6.3). Chapter 7 links the first two empirical studies and derives intermediate conclusions (7.1). Then it extends existing theory on aspects of openness to account for settings beyond software (7.2) which have been discovered trough the presented qualitative research. Further based on my empirical findings it inductively derives clear-cut research hypotheses (7.3). The fourth part turns to the second main topic, namely the meaning of openness, which becomes investigated through a survey in open design communities. Chapter 8 outlines the survey approach. It presents the questionnaire (8.1), the surveyed communities (8.2), and the data collection process (8.3). Then the resulting sample is introduced (8.4) and the data is being checked and prepared for statistical tests and models (8.5). Chapter 9 addresses the meaning of openness. T-tests are performed to compare openness of software and hardware (9.1), to analyze respondents attitude towards the importance of openness and of its aspects (9.2), and to investigate differences between software and hardware in this regard (9.3). Perceptions of different degrees of openness are studied in relation to developers activity (9.4) and their duration of participation (9.5). Chapter 10 investigates the influence of openness on developer’s satisfaction and their contribution. It starts with an ordinary linear model of openness and satisfaction (10.1) and then turns to multilevel models linking satisfaction with openness and its aspects (10.2 and 10.3). Subsequently effects on developers contributed working hours are examined (10.4). The fifth part of this dissertation integrates my findings. Chapter 11 provides a summary revisiting research propositions and hypotheses (11.1). Thereafter it specifically outlines findings of my research on the differences and similarities of open source development of digital and tangible objects (11.2). Limitations of my work, delimitations, validity and the scope of generalization are discussed in the last section of this chapter (11.3). Finally Chapter 12 concludes. It discusses implications from this work for theory (12.1), for management practice (12.2) and for further research (12.3).

Chapter 2 Definition of terms Collaboration is a well-known attribute of online, multi-contributor projects such as open source software projects (Raymond, 1999a). A design is a set of instructions that specify how to produce a product or service (Suh, 1990; Baldwin & Clark, 2000). In the case of a physical product, these instructions can be interpreted as a recipe for conducting the physical production. The design needs to be converted into a physical form before it can be used. For products or services that themselves consist of information such as software, a design can be identical to the product itself or it needs to be converted into a digital product such as compiling source code to usable software. This design has different effects on aesthetics, usability, manufacturing, quality, and so forth. Manufacturers often use modular designs to organize complex products. A modular design is composed of modules that are in turn made up of components (Singhal & Singhal, 2002). Modularity is important for collaboration in design because separate modules can be worked on independently and in parallel (Baldwin & Clark, 2000). Free revealing of information means “that all existing and potential intellectual property rights to that information are voluntarily given up [...] and all interested parties are given access to it” (Harhoff et al., 2003, p. 1753). The information becomes a public good and is said to be open. The opposite of open information is termed proprietary or closed information. The knowledge is kept secretly and protected through intellectual property mechanisms, e.g., through copyright protection or patents. Open innovation is a paradigm that assumes that firms can and should use external ideas as well as internal ideas, and internal and external paths K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_2, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

10

Chapter 2. Definition of terms

to market, as they look to advance their technology (Chesbrough, Vanhaverbeeke, & West, 2006). The term Open source originates from the software industry and denotes the revelation of the source code, the human readable form of software. An actor grants “access [to his proprietary information] to all interested agents without imposition of any direct payment” (Harhoff et al., 2003, p. 1754). Open source development has been regarded has an “extreme version of open innovation” (Gassmann, 2006, p. 227) in which control of the development process is particularly low (Demil & Lecocq, 2005). According to Stallman (2007), “open source is a development methodology; free software is a social movement”. Since this research focuses on open source development aspects rather than on social aspects, the term open source will be used as umbrella term for free/libre and open source. Open source innovation is characterized by free revealing of information on a new design with the intention of collaborative development of a single design or a limited number of related designs for market or non-market exploitation (Raasch, Herstatt, & Balka, 2009). Within the phenomenon of open source innovation, a distinction has to be drawn between intangible and tangible objects of development: Open source software is a term for software published under licenses that do not give any private intellectual property rights to the developers (Osterloh & Rota, 2007). The software is available on the internet and anybody who is interested can download it for free. Users are not only allowed to use the functionalities of the software, but they are also permitted to view and change the source code of the programs. In the non-physical world beyond software, so-called open content is currently attracting considerable attention. Examples are the entire family of wikis (Peddibhotla & Sumbramani, 2007), open science (Hellstr¨om, 2003), educational materials (OECD, 2007), cultural goods such as music or films, geographic maps (the OpenStreetMap project), and other applications. Open design (Vallance et al., 2001) describes open hardware as well as other physical objects being developed in accordance with the open source model. A multitude of open design projects has constituted itself, ranging from bicycles to microchips and from MP3 players to manufacturing equipment.

Part II Theoretical and methodological foundation

Chapter 3 Perspectives from prior literature 3.1

The private and collective investment models

It is hard to imagine any topic more central to society than innovation. All change, whether revolutionary or evolutionary, requires innovation (Schumpeter, 1911, 1934). Economic theory tells us that firms generate innovations in order to reap economic rents. It also tells us that inventions require intellectual property protection in order for imitation competition to be prevented and thus for innovative firms to capture the value they created (Arrow, 1962). Intellectual property rights carry this assurance and thereby serve to incentivize firms to perform their innovating function in the economy. This is the private investment model of innovation, assuming that innovation is supported by private investment, and that private returns can be appropriated from such investments (Demsetz, 1967). Any free revealing or uncompensated ‘spillover’ of proprietary knowledge will reduce the innovating firm’s return from its innovation in this model (von Krogh & von Hippel, 2003a). Intellectual property rights have been created to encourage private investments in R & D and to incentivize firms to engage in innovations (Grandstrand, 1999). The contrary model is termed collective action model (cf. von Krogh & von Hippel, 2003a). It assumes that under conditions of market failure, innovators collaborate with others in order to produce a public good, a good that is non-rivalrous and non-excludable in consumption. Many examples K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_3, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

14

Chapter 3. Perspectives from prior literature

of collective invention have been noted in the historic literature. Michelangelo had a lot of voluntary helpers painting the Sistine Chapel. Thomas Edison led a group of 14 other people, who all contributed to his body of work, working with ideas adopted from other inventors. Although myth portrays Edison as a lone creative genius, he actually worked in collective (Hargadon, 2003). Iron-making companies in Britain’s Cleveland district willingly shared their innovations in blast furnace design in the second half of the 19th century(R. C. Allen, 1983). Other examples include the Western river steamboat (Hunter, 1949), the enhancement of the steam engine design after 1800 (Nuvolari & Rullani, 2007), and the search for a dominant design in the flat panel display industry (Spencer, 2003). Researchers over the last decade have directed a spotlight on open source innovation as the polar opposite of the private investment model of innovation, which has been termed closed-source innovation accordingly. Open source innovation is understood to be ‘extremely open’ (cf. Gassmann, 2006) since it requires information to be freely revealed to all. The innovator gives up the right to exclusive exploitation of her invention (Harhoff et al., 2003) - a strategy that must seem injurious to any degree of value capture. Accordingly, researchers have been puzzled by many inconsistencies of the open source model with the private investment model of innovation (Lerner & Tirole, 2001). Specifically, the motivations of supposedly rational individuals and companies to contribute to such projects and the seemingly self-contradictory notion of open-source business models have been a focus of prior research (Hecker, 1999; von Krogh et al., 2008). But, as Nelson (1989) points out, knowledge is neither completely private nor public. More recent examples show that the lines between the two models are becoming blurred. In 1998, Mozilla launched the first corporate founded open source project (West & O’Mahony, 2008) and many more projects have followed. Collective invention regimes usually ended when a dominant design emerged. This is not the case with OSS. Firms use their private resources to create new knowledge, but instead of claiming property rights on this knowledge, they offer it freely to everybody. In the scholarly literature, commercial open source software development beyond markets, hierarchies and strategic alliances (Osterloh & Rota, 2007), has been identified as an example of a ‘new innovation model’, which von Krogh and von Hippel (2003a) call the ‘private-collective model’. It has also been referred to as the ‘communitybased model’ (Shah, 2005), the ‘open source method’ (Osterloh & Rota, 2007), ‘opensourcing’ (Agerfalk & Fitzgerald, 2008), and one form of open technology (Nuvolari & Rullani, 2007). A related stream of literature has highlighted the growing importance of

Chapter 3. Perspectives from prior literature

15

contributions from users as sources of innovation (Franke & Shah, 2003). This research started with the observation that in many fields a sizable share of inventions origins from the user of a specific product and not from its manufacturer (von Hippel, 2005). Similar to the open source mode of development, inventions are frequently freely released to the public domain, and there are no attempts of exploiting them by means of exclusive property rights. However, user innovations are not generally characterized by collective development actions neither do they typically use open source licenses. Therefore they are not regarded strict open source. User innovations have been observed in fields as diverse as sports equipment (Franke & Shah, 2003), medical equipment technology (Lettl, Herstatt, & Gemuenden, 2006), and services (Skiba & Herstatt, 2009). “The act of taking a job traditionally performed by a designated agent (usually an employee) and outsourcing it to an undefined, generally large group of people in the form of an open call” is termed ‘Crowdsourcing’ (Howe, 2008). External actors are asked to contribute to specific tasks of an innovation process. In contrast to open source innovation, participants typically do not cooperate among each other, but develop stand-alone solutions, for example hoping for a price in an idea competition. Furthermore, open source innovation is often regarded closely related to open innovation, “a paradigm that assumes that firms can and should use external ideas as well as internal ideas, and internal and external paths to market, as they look to advance their technology” (Chesbrough et al., 2006, p.24). Both approaches share a strong attempt to use external input as a source of innovation, which makes the difference sometimes hard to identify. However only the open source mode of product development requires innovations developed by using external knowledge to be freely revealed. On the other hand, several scholars agree that open source innovation is only open innovation when some sort of profit-making business model is present (cf. West & Gallagher, 2006). Accordingly, an open source innovation approach may or may not classify as open innovation at the same time, and vice versa.

3.2

The meaning of openness

Prior research typically defines openness by various forms of relationship with external actors, but different types of openness are referred to in the literature (Dahlander & Gann, 2010). In the context of open innovation, Laursen and Salter (2004, p.1204) equate openness with “the number of different sources of external knowledge that [a] firm draws upon in its innovative activities”.

16

Chapter 3. Perspectives from prior literature

In the context of open source innovation, openness typically refers to the revealing of internal knowledge to the external environment, i.e. “the pooling of knowledge for innovative purposes where the contributors have access to the inputs of others and cannot exert exclusive rights over the resultant innovation. In its purest form, the value created through an open process would approach that of a public good” (Chesbrough & Appleyard, 2007, p.60). As noted earlier, the term ‘open source’ originates from the software industry and denotes the free revelation of the source code. Free revealing in this sense means that an actor grants “access [to his proprietary information] to all interested agents without imposition of any direct payment” (Harhoff et al., 2003, p. 1754). In this dissertation openness is used in the context of open source innovation. It denotes the extent of revelation of knowledge, where free revealing of information describes one extreme and traditional closed innovation lies at the other end of the spectrum. But openness also refers to the possibilities for external contributors to influence the development (cf. von Hippel, 2007; West & O’Mahony, 2008; Dahlander & Gann, 2010). A more precise meaning should become clear over the course of this section.

3.2.1

Openness as a gradual concept

When Harhoff et al. (2003, p. 1753) discuss free revealing of proprietary information, they mean “that all existing and potential intellectual property rights to that information are voluntarily given up [...] and all interested parties are given access to it.” In particular, this means that disclosure is voluntary (the information could have been kept secret), open (not restricted, all interested parties are given access to it) and free (not remunerated). Many researchers follow this strict definition and treat openness as a dichotomous variable - open source vs. closed source (e.g. Bitzer, 2004; Dahlander, 2005; D. Lee & Mendelson, 2008). Practitioners, however, believe that “hard-line approaches, whether open source or proprietary, don’t work [that well in the world of today]” (Thomas, 2008). Dahlander and Gann (2010) contend that “the idea behind openness needs to be placed on a continuum, ranging from closed to open and covering varying degrees of openness.” Bonaccorsi, Rossi, and Giannangeli (2006) and Henkel (2006) find that firms address this issue by revealing selectively, i.e. they carefully decide which parts to reveal and which to keep proprietary. Some researchers follow this thought: Colombo, Grilli, and Lamastra (2010)

Chapter 3. Perspectives from prior literature

17

define the degree of openness in the software context as “the weight of OS offering over the total firm’s offering”. Fosfuri et al. (2008) and CasadesusMasanell and Llanes (2009) propose strategies for firms with modular software, which guide them in their decisions which modules to open and which to keep proprietary and develop mixed source approaches. West (2003) moves the gradual concept of openness one step further by observing that many open source projects impose various limitations to openness. He proposes a distinction between ‘open parts’ and ‘partly open’. The ‘open parts’ strategy refers to the selective revealing of some components of a modular object. A project developing an open source embedded device could accordingly reveal their software components or their hardware components or both, and within their list of software (and hardware) components they can decide which components to reveal and which to keep proprietary. The ‘partly open’ strategy refers to the release of a design under restrictive terms. The open source project can for example restrict the permitted usage to non-commercial use or limit the group of people who get access to the revealed knowledge. K¨as (2008) distinguishes four major levels of openness with respect to the means of making driver code available: providing binaries only, providing source to customers, providing source code for public download, and managing the source code in publicly hosted open source projects. Also Shah (2006) investigated approaches towards partly openness by comparing open source and ‘gated source’ communities. A crucial aspect of the OS phenomenon is its novel form of licensing that explicitly grants users the rights to use, modify and redistribute a certain piece of information. The chosen type of license determines one aspect of a partly open strategy as it defines scope and limitations to the permitted usage. So far, most of these licenses apply mainly to open source software. One of the most far reaching is the GNU General Public License (GPL), created by Richard Stallman, founder of the Free Software Foundation. The Free Software Foundation works as nonprofit and promotes completely free software as outlined in the Free Software Definition1 . In contrast to conventional copyright, their license is also called ‘copyleft’. The distinctive characteristic of copyleft licenses is that they are ‘viral’, as they compel that every piece of software that contains a free software component has to be released as free software itself (Stallman, 2007). Licenses, that do not impose any burden of reciprocity and allow the greatest freedom of distribution, modification and license change, are called ‘permis1

http://www.fsf.org

18

Chapter 3. Perspectives from prior literature

sive’ licenses. Examples are the Berkeley Software Distribution, the MIT and Apache licenses. Commercial licenses show varying degrees of restrictiveness, but tend to impose some specific requirement, such as for instance the limitation to non-commercial use (cf. M. A. Rossi, 2006). Beyond software, Creative Commons licenses provide a range of protections and freedoms for copyright owners of digital content. Additionally, several new licenses have been proposed to address issues specific to hardware design. Equivalents to GNU’s GPL are for example the Open Hardware Public License and the TAPR (Tucson Amateur Packet Radio) Open Hardware License, both promoting complete hardware freedom.

3.2.2

Aspects of openness

In addition to the gradual approach to openness, West and O’Mahony (2008) distinguish two forms or aspects of openness: transparency and accessibility. While transparency offered potential contributors the ability to follow and understand a communitys efforts, accessibility determined the degree to which external contributors could influence the development. Regarding the way that the community conducts the development and production, the degree of transparency describes the amount and quality of available information, e.g., the ability to read code and observe or follow production processes. The degree of accessibility defines the ability to contribute to the development, e.g., to change code directly. Regarding the governance structure and the processes by which decisions are made within a community, transparency refers to a publicly visible governance, where observers can understand how decisions are made. The degree of accessibility denotes the ability to actively participate in decisions. Concerning the allocation of rights to use the community’s output and the chosen type of license, transparency describes the rights to access and use information. Accessibility refers to the right to reuse and modify information in the creation of derivative work (cf. West & O’Mahony, 2008). Coming back to the definition of openness, transparency denotes the revelation of knowledge in the original sense of open source code, whereas accessibility refers to the possibilities for external actors to actively participate in the development.

Chapter 3. Perspectives from prior literature

3.2.3

19

The community’s perspective

Initially the free software and open source movement described itself as a community of programmers, committed to software freedom, and working against established intellectual property owners (cf. Stallman, 2007). As Raymond (1999a, p.2) observes the “Linux community seems to resemble a great babbling bazaar of differing agendas and approaches.” Collaborative development within a community is an essential characteristic of OSS (Nakakoji et al., 2002), although a project may have a leader (often the one who initiates the project), the leader neither has a grand plan for the system at the beginning, nor dictates the evolution of the system. It is the whole OSS community that collaboratively drives, as both users and developers, the evolution of the system. Open source software development accordingly initially referred to software projects managed by grassroots communities in public forums, but recently the concept of community management has become decoupled from the concept of an open source project. OSS projects do not depend on a communitymanaged governance model; most successful projects have well developed approaches to not only software development, but to their overall governance (O’Mahony, 2003). With the emergence of open source business models the interests of the community and the commercial companies involved need to be balanced and firms need to manage the tension between control and openness (e.g., Mahony & Naughton, 2004). On the one hand firms want to maintain some degree of control over the project; on the other hand they want to benefit from external participation. According to Shah (2006) the “governance structure of the community dramatically affects the participation choices of volunteer software developers”. West and O’Mahony (2008) find that by restricting access to community processes, firms limit their community’s ability to attract new members and grow. Raasch et al. (2009, p. 389) observe an awareness that, “by deciding to ‘leave enough room to encourage private investment’, the community can improve its probability of success”. People in charge try to promote project success by carefully weighing community and commercial requirements. Empirical evidence on this topic is provided by Mayrhofer (2006) who find that contributors in successful communities perceive benefits to be equally distributed between the community and the firm. The common motivation behind all different aspects and degrees of openness appears to be the desire to balance the interests of the community and commercial companies involved, e.g. as suppliers or manufacturers. According to Dahlander and

20

Chapter 3. Perspectives from prior literature

Magnusson (2006), the relation firms engaging in OS activities may have with their communities is an important mechanism determining the possibility to create a sustainable business model and benefit from these activities.

3.3

Open source software versus hardware

A principal distinction in relation to open source innovation can be drawn between intangible and tangible objects of development. In the digital realm, open source software development has received considerable scholarly attention, which shall be outlined shortly in Section 3.3.1. Beyond software, so-called open content is currently proliferating and consequently attracting considerable attention. The free encyclopedia Wikipedia and the entire family of Wikis, that anyone can edit (Peddibhotla & Sumbramani, 2007), cultural goods such as music or films being co-developed, cofunded and shared freely, open science (Hellstr¨om, 2003), the development of educational materials (OECD, 2007), bioinformatics databases, geographic maps of the world (the OpenStreetMap project), and other applications have demonstrated the potential inherent in open content. They suggest that, in the digital realm at least, the open source model is viable beyond software and can offer business opportunities to companies. At least one qualification seems noteworthy, however: Open content platforms neither necessarily aspire to nor always deliver any substantial degree of innovativeness, and therefore do not form a strict subset of open source innovation (cf. Raasch et al., 2009). The second group, called open design (Vallance et al., 2001), describes open hardware as well as other physical objects being developed in accordance with the open source innovation model. The development and production of purely physical goods, however does not involve any source code in its inherent sense, but technical drawings and manufacturing specifications. While much of the development work in this group can be accomplished virtually, the ultimate purpose is the design and production of a physical artifact. Not least due to the success of OSS, open design is enjoying an upsurge (Hope, 2007). Mostly unheeded by scholarly research, a multitude of open design projects has constituted itself since approx. 2005, ranging from bicycles to microchips and from MP3 players to manufacturing equipment. While most of these projects are still in development, others have had marketed products for several years. A detailed overview on empirical studies of open design will be given in Section 3.3.2.

Chapter 3. Perspectives from prior literature

3.3.1

21

Empirical studies of open source software

A large number of successful examples of open source software programs has been developed and extensive research has been undertaken to analyze this phenomenon from different perspectives (von Krogh & von Hippel, 2006b). Large-scale descriptive statistics visualizing the variety of projects are provided by Weiss (2005), who used the “relatively easy accessibility of high volumes of information about open source software” from Sourceforge to perform a number of interesting statistics. Sourceforge is only one of several well-known repositories and is currently, i.e. as of April 2010, hosting more than 225.000 projects. Comino, Manenti, and Parisi (2007); Healy and Schussman (2003); Krishnamurthy (2002); Lerner (2005); and Subramaniam, Sen, and Nelson (2009), for example, use data obtained from Sourceforge to evaluate the relationship between the various characteristics of an OS project and its probability of success. To deepen the understanding of open source software development, a number of case studies has been performed, e.g., on the Linux kernel (Hertel, Niedner, & Herrmann, 2003; Moon & Sproull, 2000), on Gnome (German, 2005; Dahlander & Wallin, 2006), on company-founded projects like Apache and Mozilla (Mockus, Fielding, & Herbsleb, 2002), on companies like Red Hat which commercialize Linux (Lerner & Tirole, 2002), on MySQL, the provider of a FOSS database, (Garzarelli, 2003), and many more. One of the most compelling aspects of OSS projects is that they are predominantly based on voluntary contributions (Moon & Sproull, 2000). The motivation of contributors has been a special focus of the scholarly literature on OSS. Lerner and Tirole (2001) formulated a key research question: “Why would thousands of top-notch software developers contribute for free to the creation of a public good?” Researchers typically distinguish between intrinsically and extrinsically motivated participants. An activity is intrinsically motivated when the activity is done for the inherent interest or joy of performing said activity (Deci & Ryan, 1985). Four categories of intrinsic motivation are distinguished in the literature: ideology, altruism, kinship amity, and enjoyment. An activity is said to be extrinsically motivated, when it is done in order to obtain some outcome. Potential outcomes include reputation, reciprocity, learning, careers, and pay (e.g. M. A. Rossi, 2006). Large-scale empirical studies on the developers who participate and their motivations have been performed on the data from the 2003 FLOSS-US Survey and from the 2002 FLOSS-EU Survey. David and Shapiro (2008) find that heterogeneity of motivation is a key feature of open source communities and that community size plays a particular role in participants’ motivations. A

22

Chapter 3. Perspectives from prior literature

critical mass of user participation has to be reached for an online community to survive and be sustainable. A very common reason to contribute appears to be the personal need for applications and tools, which are not previously available with the desired functionality. As Raymond (1999a, p.32) notes: “Every good work of software starts by scratching a developer’s personal itch.” Lakhani and Wolf (2005) bring empirical evidence for this statement by reporting that 58% of their study’s respondents regard ‘user need’ as the most important reason for contributing to OSS projects. A detailed overview of the literature on participants’ motivations is given by C. Rossi and Bonaccorsi (2005); a more general review of previous research on open source software is, for example, provided by von Krogh and von Hippel (2003b, 2006b).

3.3.2

Empirical relevance of open source beyond software

In view of the sweeping success of this new model in the software industry, an increasing number of researchers and practitioners believe that other industries may also avail themselves of open source development processes in the future (e.g. Lerner & Tirole, 2004; Fleming & Waguespack, 2007). Open source software projects are a relatively well-developed and very successful form of Internet-based innovation communities. However, innovation communities are by no means restricted to software or even to information products, and they can play a major role in the development of physical products (von Hippel, 2005). Shah (2005) considers open source software development as “perhaps the most prominent example of the community-based model”, which extends well beyond the domain of software. As a confirmation they refer to a small number of existing projects, but only limited research has been conducted on the topic of open source beyond software. Vallance et al. (2001) coined the term ‘open design’ with their work on open manufacturing equipment. Over the past five years, practical examples from different industries have been addressed in the literature via case studies. Hope (2005) investigated open source biotechnology, M¨ uller-Seitz and Reger (2008) examined the development of an open source car, and K¨as (2008) studied openness in the embedded components industry. In areas more closely related to software development, Stuermer, Sp¨ath, and von Krogh (2009) examine the development of the Nokia Internet Tablet, which builds on both proprietary and open source software development for this device.

Chapter 3. Perspectives from prior literature

3.3.3

23

Why is the situation different for digital and physical products?

My research focuses on open design rather than open content, since it not only seems the less researched of the two fields, but also lies further from the original realm of software. In the domain of open design, the tangibility of the product may affect the form and degree of openness. So far, researchers have been sceptical about the potential to apply the concept of open source in the physical world due to a number of reasons which shall be outlined in the following. Tangible products do require actual physical production, an aspect often regarded as a significant challenge to open design (Maurer & Scotchmer, 2006). “Linux is a digital good where the cost of production is significantly lower than that of conventional product development. For products that require heavy production cost and relatively little development cost, [the OS] model may not apply” (G. K. Lee & Cole, 2003, p. 646). Demil and Lecocq (2005, p.18) find it “not surprising that both researches and practitioners find (or think) it difficult to generalize [open source principles] beyond the software industry” because they are considered to be recent and have gained recognition only in the last few years (as of 2005). They argue that “production of physical products that can benefit from economies of scale will be less efficient under a bazaar structure, which is characterized by distributed production capacities.” Programmers frequently write tools for themselves, additional users are nice, but not necessary in any sense (Shirky, 2005). von Krogh and von Hippel (2003a) add that software, or information products more generally, are particularly suited to OS development as users can carry out the entire innovation process. When commonly developing physical products, participants depend much more on each other until they have a final product. Moreover, in mass market industries users are numerous and typically rather unsophisticated (Lerner & Tirole, 2004). Further, according to Demil and Lecocq (2005) bazaar governance appears well suited for information goods when information can be codified enabling fine-grained modularity - the division into small components that suit the distributive development and skewed distribution that characterize contributions in a community. Other sectors are not theoretically excluded, but this governance structure might be a disadvantage compared to other structures. Beyond software, it may be impossible to break up large projects into small manageable and independent modules. “In many industries the development

24

Chapter 3. Perspectives from prior literature

of individual components requires large-scale teamwork and substantial capital cost, as opposed to individual contributions and no capital investment” in OSS (Lerner & Tirole, 2004, p.29). In addition, high cost for designing, testing, and seeking regulatory approval could hinder open source innovation in many fields. Furthermore, so far, open source innovation “has not been observed in cases where there is a disruptive innovation or technological breakthrough.” (G. K. Lee & Cole, 2003, p.646). The list of differences goes on, and has turned out to be enough to upend most attempts at open source production of physical products. In particular, open source methods work less well for the kinds of things that people wouldn’t make for themselves (Shirky, 2005).

3.3.4

But, hardware is becoming much more like software

It is important, however, to point out, that the distinction between open design and open content is not as stringent as it may appear, as “in a sense, hardware is becoming much more like software, up to the point where you actually fabricate an object” (von Hippel in Thompson, 2008). In addition, viewing the digital and physical realms as unrelated is inappropriate because software has increasingly permeated physical products and hardware functionality can be altered by installing modified or new software on electronic devices. Open source software is constituted by the sharing of instructions that will be interpreted by a computer. Similarly, open design is based on developing and sharing designs and instructions to create physical objects (Smith, 2008). According to Shirky (2007), “an increasing number of physical activities are becoming so data-centric that the physical aspects are simply executional steps at the end of a chain of digital manipulation”. With the emergence of cheap or free tools for chip making, 3-D modeling, rapid prototyping, and online collaboration, private individuals gain the chance to get deeply involved in the development of physical products. “That’s why you’re starting to see open source techniques in hardware” (Thompson, 2008). This suggests a possible reverse of any considerations about the transferability of the OSS model to other industries, like de Laat (2007), for example, poses the question which more general lessons can be drawn from experience with OSS as “voluntary innovation is not only to be observed for ’informational’ products, but also for physical products.” and similarly M¨ uller-Seitz and Reger (2009) study the applicability of OSS principles to non-software

Chapter 3. Perspectives from prior literature

25

related areas. But, “instead of asking ‘How can we apply open source methods to the rest of the world’ we can ask ‘How much of [the development work in] the rest of the world” can be performed like software development (Shirky, 2005, p.487).

3.4 3.4.1

Why do firms get involved? The firm as a collection of productive resources and dynamic capabilities

According to Penrose (1959), a firm is a collection of productive resources, where the use of these resources is determined by administrative decisions. Barney (1986) proposes that a firms’ resources can be sources of competitive advantage enabling a firm to implement strategies that improve efficiency and effectiveness. This approach is called resource-based theory, where resources are defined as the available factors that a firm owns and controls, and is widely accepted among researchers of strategic management (cf. Freiling, 2004). Resources can be tangible things, e.g., plants, equipment, land and natural resources, raw materials, semi-finished goods, waste products and by-products, and even unsold stocks of finished goods, or intangible, e.g., knowledge, brand names, and patents. Following this theory, a firms’ intention is to effectively use its resources by combining them into products and services to maximize return over time (Barney, 1986). Teece and Pisano (1994) argue that the competitive advantages of firms stem from dynamic capabilities rooted in high performance routines operating inside the firm. The theory on dynamic capabilities extends the resource-based view, observing that winners in the global market have been firms demonstrating timely responsiveness and rapid and flexible product innovation, together with the capability to effectively coordinate and redeploy internal and external competencies. Expanding this logic, Dyer and Singh (1998) suggest that a firms’ critical resources may span firm boundaries and Sanchez (2004) then distinguishes between a firms’ own ‘firm-specific’ resources and ‘firm-addressable’ resources outside the firm. Key firm-addressable resources include interfirm relationships, suppliers, distributors, consultants, customers, and communities. For example, von Hippel (1988) finds that in some industries more than twothirds of the innovations he studied could be traced back to a customers’

26

Chapter 3. Perspectives from prior literature

initial idea or suggestion. Dahlander and Wallin (2006) observe that a user community can be seen as firm-addressable asset and contributions from the community can be used in conjunction with firm-specific resources to develop competitive products and services. According to Sanchez (2004), firms that use only internalized resources to create new products, tend to have a narrower range of feasible product offers that they can bring to market, may take longer to assemble resource chains and may incur higher risks than firms that are able to draw on firm-addressable resources outside the firm. On the other hand, value created outside the firm, for example in a community, is more difficult to appropriate for the firm than value created inside the firm (Dahlander & Wallin, 2006). A particular characteristic of OSS is that important resources are not directly controlled by the firm, but reside within a community that co-exists with the firm. Nevertheless some firms explicitly try to utilize the resources within these communities in order to create and appropriate value (Dahlander & Magnusson, 2005). To leverage these valuable resources outside the firm, companies need specific capabilities. While traditional firms derive competitive advantage from the ownership or control of internal resources, OS firms at least partly draw upon the capability to control resources external to the firm in the form of communities. Hence, such capabilities are antecedents of successfully harnessing the creative potential of communities. Therefore I will now focus on topics of value creation and value capture in this context, before analyzing how firms in the realm of open design may successfully use communities as external firm-addressable resources.

3.4.2

Value creation and value capture

Porter (1985) contends that new value is created when firms invent new ways of doing things using new methods, new technologies and/or new forms of raw material. According to Nelson and Winter (1982) innovation involves change in routine and already Schumpeter (1911) identifies innovation with the “carrying out of new combinations”. Similar, individuals create value by developing novel tasks, services, products, processes, or other contributions perceived to be of value. Value creation is a central concept in the management and organization literature for both micro level and macro level research (cf. Lepak, Smith, & Taylor, 2007). Schewe (1994) finds that innovations’ success is, above all, determined by the capabilities of innovative firms. Following the resource-based theory, the ability to innovate is essential to a firms’ success (Freiling, 2004). Re-

Chapter 3. Perspectives from prior literature

27

searchers note further that the possibility to appropriate profits created by an innovation is key for innovation to happen. Value creation without appropriability is, therefore, not expected to be sustainable in the long run (e.g. Grandstrand, 1999). Value created by one party may be captured by another, a process called ‘value slippage’ (cf. Lepak et al., 2007). For example, value created by organizations may not be wholly captured by them but, instead, may spill over into society as a whole. As Teece (1986, p.285) notes: “It is quite common for innovators [...] to lament the fact that competitors/imitators have profited more than the firm first to commercialize it.” Pursuing the concept of ‘profiting from innovation’ an innovator’s ability to capture the value generated by an innovation is governed by the strength of the ‘appropriability regime’ (Teece, 1986). An appropriability regime is related to the features of the core knowledge in the innovation (i.e. ease of imitability) and the efficacy of legal mechanisms of protection (i.e. intellectual property rights such as patents and trade secrets). It is termed ‘weak’, when the innovation is hard to protect and ‘strong’ where it is relatively easy. Following Lepak et al. (2007, p.188), any knowledge, physical, or legal barrier that may prevent replication, is called an ‘isolating mechanism’. Examples are personal attributes, such as specialized knowledge and abilities, the place in a social network, relationships with others, and the use of resources with attributes that make them difficult to imitate. Patents as isolating mechanisms do not always grant good protection. Already Teece (1986) notes: “Rarely, if ever, do patents confer perfect appropriability.” Patents require disclosure, which allows others to ‘invent around’ at modest costs, or they provide little protection because the legal requirements for upholding their validity are high. Several empirical studies have shown that patents are considered a relatively ineffective means of protection in many industries (e.g. Mansfield, 1986; Arundel, 2001). As patents require the closure of parts, they are hardly compatible with OS development, however they could be applied on specific modules or components (Raasch & Herstatt, Forthcoming). Similar, information sharing can be restricted to a subset of components of the design, so-called selective revealing, as discussed in Section 3.2.1. Common reasons for selective revealing are strategic decisions for value capture. It enables the retention of some control over the design and hinders imitation.

28

3.4.3

Chapter 3. Perspectives from prior literature

Reasons for firms to freely reveal

For corporate contributors of open source projects value capture from their own contributions to the developed good, as well as from the project and its community more generally, is a principal spur to participation (Hecker, 1999). If avenues to value capture are systematically blocked, commercial actors are likely to invest less into the project (Dahlander, 2005). The question of why firms engage in OS activities when it is so hard to protect the innovation from being used and exploited by others is somewhat puzzling. Reasons for free revealing of commercial firms have been a recent focus in the scholarly literature on open source software. Incentives like external contributions for further development and new functionalities (e.g. Osterloh & Rota, 2007; Dahlander, 2005) and enhanced quality from testing and bug reporting (e.g. Raymond, 1999a) appear evident. Other economic reasons are probably less obvious, like the observation that an open source approach frequently grants free publicity and increased demand for complementary goods and services (Osterloh & Rota, 2007). Customers may be attracted and motivated through the ‘OS culture’ appearance (Lerner, 2005) and revealing high quality code further improves a company’s reputation (Henkel, 2006). A successful open source project may be able to weaken potential competitors and achieve independence from price and license policies (Wichmann, 2002), as well as profit from network externalities, i.e. new users choose the product due to the possibility of feedback from others (cf. Grewal, Lilien, & Mallapragada, 2006). Furthermore the own development becomes widely adopted faster and may emerge as dominant design (Henkel, 2006). Firms also frequently release code or information, which is not part of their core business (Hawkins, 2002). Maintaining an active community is additionally valuable to a company, for example because it grants access to information regarding user needs (von Hippel, 2007) and allows for an identification of potential employees (Wichmann, 2002). In addition to this comprehensive list of economic reasons, researchers also find social reasons, like the fight for software freedom (Feller & Fitzgerald, 2002) and the desire to conform to the values of the OS community in order to avoid betraying the trust of the developers and to sustain cooperation (Lerner & Tirole, 2002). C. Rossi and Bonaccorsi (2006) further suggest that some firms have inherited their community-oriented attitudes from founders that were previously involved in OS development at the individual level and have turned their passion into a profession. As technical reason the compatibility to other products, in particular to other open source products, is mentioned by Osterloh and Rota (2007) and

Chapter 3. Perspectives from prior literature

29

Wichmann (2002). The recent rise of available open source software may therefore cause an increasing demand also for compatible hardware. Above all, a firm may be forced by a license to reveal their development, e.g. if derived from work licensed under the GPL (Henkel, 2006). Beyond software, Thompson (2008) notes that, to a certain extent, hardware is already open. He observes: “Even when inventors try to keep the guts of their gadgets secret, they can’t.” and concludes that it makes most sense to open those designs and “profit from the inevitable”. To the advantage of inventors and manufacturers, open hardware is still hard to copy in many cases as skills, experience and support might be needed (Rowe, 2008). Furthermore, the increasing use of open source software causes an increasing demand for open hardware, or at least for open interfaces between software and hardware, to ensure compatibility of new products to existing solutions (Henkel, 2004; Wichmann, 2002).

3.4.4

OS business models

In this document, the term ‘business model’ is used in the following sense: “At its heart, a business model performs two important functions: value creation and value capture. First, it defines a series of activities, from procuring raw materials to satisfying the final consumer, which will yield a new product or service in such a way that there is net value created throughout the various activities. [...] Second, a business model captures value from a portion of those activities for the firm developing and operating it” (Chesbrough, 2007). Based on theory explaining traditional business strategies, Chesbrough and Appleyard (2007) examine the increasing adoption of more open approaches to innovation. They develop a new approach, which they call ‘open strategy’ to explain business models of open innovation. Likewise, business models among firms engaging in open source software activities have received an increasing amount of attention among researchers (e.g. Perr, Sullivan, & Appleyard, 2006), as it is a great ambiguity of how to appropriate returns from OSS. In contrast, open-source based business models in the field of open design have received comparatively little attention (Raymond, 1999b; Dahlander, 2005; Raasch & Herstatt, Forthcoming). Open source opponents argue that significant risks are attached to opening up a products design. The

30

Chapter 3. Perspectives from prior literature

developed product could be hijacked by competitors as well as the open source project itself may become an immediate competition (Wichmann, 2002). The most frequently found mechanism for value capture from OSS rests on a demand externality, specifically the increase of demand for complementary products and services, which justifies a cross-subsidy. While the open design (the code) cannot be commercially exploited per se because it is free to download for everyone, incentives for companies to engage in OS development stem from opportunities for commercializing other related goods (Lerner & Tirole, 2004; Henkel, 2004). Common business models include component suppliers, contract manufacturers, distributors, and service suppliers. Value capture from an open source software product itself appears rather difficult. In open design, however, it seems possible to act as a focal company and generate revenues from selling the product to developers and other customers (cf. Raasch & Herstatt, Forthcoming).

3.5

Conclusions and implications for this research

Through the entire literature dealing with the phenomenon of open source it appears that researchers mainly focus on open source software. Only a very limited amount of research has been conducted in the realm of tangible products. With respect to empirical work, this discrepancy gets even more pronounced. To date, I am not aware of any studies adhering to investigate the open design landscape in its entirety. Questions like ‘What kind of open source design have emerged so far?’, ‘What characterizes them?’, ‘In which industries do they emerge?’, ‘Who contributes to those projects under which circumstances?’, ‘Who drives the project?’, etc. mainly appear ignored from the research on open source so far. A more structured approach to detailed research questions will be developed in the following chapter (Chapter 4) in order to build a basis for a thorough empirical investigation of open design projects. However two main research questions become already clear and form the first of two main issues treated in this document: Q1: What kind of open design projects emerged so far? Q2: How does open design work in practical examples?

Chapter 3. Perspectives from prior literature

31

Independent of the physicality of the developed object, researchers recently started to loosen their dichotomous view on openness and to think of openness as a gradual concept incorporating different forms and aspects. However, existing research has its limitations relating to a lack of empirical data and analysis. At the present time, the researcher is only aware of three studies that consequently analyze a gradual concept of openness in an open source setting using empirical data. West and O’Mahony (2008) illustrate how the tension between growth and control affects OS communities examining 12 open source software projects. K¨as (2008) surveyed 74 manufacturers of embedded components that develop Linux drivers for their hardware components investigating reasons for increased revealing over time. von Krogh et al. (2009a) investigate how the perceived level of information revealed by the sponsoring firm affects participant motivation in two cases of mobile consumer devices. A further empirical investigation of the meaning of openness for the community and accordingly their willingness to collaborate as well as the meaning of different aspects of openness for the community seems clearly required. In particular, no prior research could be identified, which analyzes differences and similarities in the meaning of openness with respect to the development of digital and physical objects. Therefore, I arrive at another three research questions forming the second main matter of research of this thesis: Q3: Does the degree of openness matter to the communities? Q4: Does the meaning of openness differ between open source software and open design? Q5: How does openness impact developer’s satisfaction and their contributions?

Chapter 4 Research design and methodology In the following chapter I attempt to clarify what will be studied throughout this thesis and how the data will be collected and analyzed. The term ‘Open Source Innovation’ will be defined and a conceptual framework for studying this topic will be presented. Along this framework I develop a more detailed set of questions for my research and propose resulting propositions to connect questions to data. In the last section my combination of research methodologies to best approach these questions and study the phenomenon of open source innovation will be explained.

4.1 4.1.1

Open source innovation (OSI) A disambiguation of OSI

To generalize the ‘OS model’ to a non-industry-specific level, I use the following concept called ‘Open Source Innovation’: OSI is characterized by free revealing of information on a new design with the intention of collaborative development of a single design or a limited number of related designs for market or non-market exploitation. This definition contains four critical aspects: (1) OSI is characterized by a non-market, non-contractual transfer of knowledge among the actors involved in invention and between those actors and those involved in exploitation. Actors share some ideas, designs, and other relevant information with a nondefinite set of other actors without any immediate recompense or expectation K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_4, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

34

Chapter 4. Research design and methodology

thereof. An open license may establish rules of knowledge sharing and reusage. The actors engaging in such activity are often called volunteers, in the sense that the activity is voluntary at the level of the individual and of the contributing corporation, but not necessarily at the level of each member of such a company. (2) Actors share their ideas with the clear purpose of contributing to the joint development of (3) a single, integrated design or a small number of interrelated designs. Put reversely, OSI does not refer to design information being revealed by actors without the understanding that this design is a part of a larger design task carried out in collaborative fashion by a group of actors. (4) The design thus developed is exploited in the sense that it is produced and sold on a market, integrated into other products that are marketed, or deployed during the development of such products. Exploitation can be either for-profit or not-for-profit or both. This model builds on and intersects with several of the models of collaborative development proposed in the literature (cf. Raasch et al., 2008). The theoretical foundation supporting OSI is laid by the private-collective model (von Krogh & von Hippel, 2003a, 2006a) and the resource-based and dynamic capabilities theory. Actors invest private resources towards the production of a public good, as discussed in Section 3.1, while at the same time drawing on a community as external resource, as discussed in Section 3.4. Building on this disambiguation of the expression ‘Open Source Innovation’, I will further in this document also use the term ‘Open Design’ in the sense of OSI in conjunction with physical products.

4.1.2

A conceptual framework for studying OSI

For my empirical exploration, I will rely on a comprehensive conceptual framework. Its encompassing approach is most suited to grant a clear structure to my analysis guiding me through the various characteristics of open source innovation projects. According to this framework (Figure 4.1), actors, in a broader sense, including investors, manufacturers, etc., collaborate within a development process. They work towards a design of an object and finally come up with an innovative solution. A suitable governance structure framing the development is devised and possibly adapted across the evolution of the development to organize collaboration and provide required institutional arrangements. The object, given its inherent characteristics, can pose requirements to actors, development process and governance structure, whereas the latter are in turn actively shaped by the actors. The constitution of the governance structure

Chapter 4. Research design and methodology

35

Figure 4.1: The open source innovation framework

can back-propagate to the group of actors, causing self-selection and affecting their effort, and to the development process, influencing its evolution and efficiency. Finally each project operates within a technical, social, economical and legal setting surrounding the development.

4.2

Detailed research questions and resultant propositions

Numerous authors discuss structural components of this framework in an OSS setting. According to the scope of this dissertation, I concentrate on contributions with explicit reference to industries beyond software and suggestions on conditions for the broader applicability of the OS model. Only few aspects have received attention from researchers beyond hypothetical predictions yet, and even fewer can claim detailed findings grounded in theory and empirical analysis. This situation suggests several interesting research questions. Despite the high number of OSS projects listed and the comparatively large amount of research conducted in the software realm, only little research has been carried out, which empirically analyzes factors determining project success. Not even a clear-cut definition of success of OSS projects appears available from the literature, but different approaches to measure factors related to success have been proposed. S.-Y. T. Lee et al. (2009) apply OSS use as a possible measure of success, Weiss (2005) refers to a projects popularity, Fershtman and Gandal (2004) measure the output per contributor, whereas

36

Chapter 4. Research design and methodology

Stewart, Ammeter, and Maruping (2006) rely on the number of subscribers associated to a project and their activity. Comino et al. (2007) measure project success in terms of the development stage that it has reached. For my research I decide to follow this approach as project advancement provides a reasonable measure for achievements of the project and is thereby applicable to both software and hardware development. I distinguish five different development stages: open design projects typically begin with a planning and digital development phase (Stage 1); they start prototyping (Stage 2); over time they (hopefully) arrive at the ability to produce fully working prototypes (Stage 3); in the next step they may establish a stable production and have their product permanently available on the market (Stage 4). If the project entirely completes the development and refrains from further work on it, it is said to be mature and thereby reaches the latest possible stage (Stage 5). On the basis of the findings still available, I will deductively compile 5 research propositions referring to the constituents of the open source innovation framework and relating them to project advancement as a measure of success. The propositions will be used to compare previous findings from OSS to my own empirical findings in the area of open design. Thereby I will address my first two research questions on the mechanisms of open design development. Due to the enormous breadth of this topic, I cannot cover all aspects in detail and need to focus on certain characteristics. More precisely, I will focus on aspects, which previously have been investigated in empirical studies on OSS.

(1) Actors While a sufficient number of contributing developers (Shah, 2005; J. M. Garcia & Steinm¨ uller, 2003), their diversity (Carr, 2007, p.3) and skills (Lerner & Tirole, 2004, p. 29) are each mentioned in the literature as a precondition for OSI to be feasible in industries other than software, more research has been undertaken on actors motivations to participate in a development effort as adumbrated in Section 3.3.1. For example, von Krogh and von Hippel (2006a) point to selective benefits of project participation and information revelation as an important precondition. In analogy to OSS settings, corporate contributors may be motivated by business opportunities in primary or secondary markets (Hope, 2005). Compared to OSS, such opportunities are reinforced by the fact that customers who find building the object themselves inconvenient, need to buy a physical copy, instead of downloading it.

Chapter 4. Research design and methodology

37

Thus the question of ‘Who participates in open design projects?’ arises. Do contributors rather stem from commercial, research, or private background? How many would typically contribute to a project and does the size of the community impact project advancement? Already Hiltz and Turoff (1978) note that, a critical mass of user participation has to be reached for an online community to survive and be sustainable. For OSS, Raymond (1999a, p.8) observes: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone” This statement became prominently known as ‘Linus’s Law’ under the less formal expression “Given enough eyeballs, all bugs are shallow”. Contradictory to Linus’s Law is ‘Brook’s Law’ saying: “Adding more programmers to a late project makes it later” because complexity and communication cost of a project rise with the square of the number of developers, while work done only rises linearly (p.9-10). However OSS developers typically work on separable parallel subtasks and interact with each other very little, accordingly Brook’s Law is not always appropriate. Comino et al. (2007) prove empirically that the size of the community has a positive impact on project development status. Concerning the type of actors, Healy and Schussman (2003) observe that “successful OSS projects are most often staffed by professional software developers” and “are (more often than not) run by professionals” (p.18). For industries other than software a sufficient number of contributing developers with the required skills is likewise described as a precondition for open development to be feasible (e.g., Shah, 2005). With regard to the actors involved in open design, I thus arrive at two propositions: P1: The size of the community is positively correlated with project advancement. P2: The participation of commercial contributors is positively correlated with project advancement.

(2) Object As outlined in Section 3.3.3, many researchers agree that the open source mode of product development today is more easily applied to the development of information goods rather than tangible objects. Other artifactual characteristics that have been found to be relevant to OSI are modularity (Lerner & Tirole, 2004; Baldwin, 2008), complexity (Gehring, 2006; Bessen, 2006), uncertainty (Osterloh & Rota, 2007), and the cost of development

38

Chapter 4. Research design and methodology

(Maurer & Scotchmer, 2006). Hope (2005) emphasizes that the object as well as its technology need to be modular: Distributed development is impeded by modifications to one part interacting in unforeseen ways with the remainder of the design. Interestingly, there is no consensus whether lowor high-complexity and high- or low-uncertainty objects are best suited to OSI processes of development. A low-cost situation of contributing is usually deemed vital (Osterloh & Rota, 2007, p.169), with relative costs rather than absolute costs as the relevant variable. As noted earlier, viewing the tangible and digital realms as unrelated topics is inappropriate because software has increasingly permeated physical products. Frequently, products are a combination of both hardware and software. Hardware functionality can be altered by installing modified or new software on electronic devices. I therefore adhere to investigate what kind of objects are being developed by open design communities, in the sense of the type and amount of digital versus physical parts incorporated in the object. Further, different object characteristics shall be analyzed and likewise related to project characteristics, as project advancement, for example. Due to the dissimilarity of the objects and its characteristics, one can hardly directly apply findings from OSS to open design. Hence I refrain from formulating research propositions for this constituent and will rather focus on examining the degree of similarity between physical and digital objects of development in this regard.

(3) Governance structure A couple of studies focus on the institutional and organizational structures governing open source projects. The institutional structure governing innovation processes is usually understood to be highly relevant to the development and commercialization of new technologies (Lynn, Mohan Reddy, & Aram, 1996). Still, despite numerous empirical studies of OSS and the explicit or implicit assumption that at least some elements of the OS model are applicable on a broader scale, few researchers have tried to conceptionalize this model as “a generic structure regulating transactions which could be employed in different industries” (Demil & Lecocq, 2005, p. 1448). Gehring (2006) regards OS as a new organizational form that “offers [...] a complete set of alternative institutions [...] that, under specific circumstances, enables superior performance” in development (p. 59). Among the principal institutions shaping the OS model are licensing and a specific allocation of IP. Gehring finds that “in the open source approach, traditional

Chapter 4. Research design and methodology

39

institutions of capitalism - property rights, contracts, norms - are modified so as to minimize information and transaction costs” (p. 60). Both Demil and Lecocq (2005) and Gl¨aser (2007) regard the generic structure regulating ex-change in the OS model - Gl¨aser calls it communal production - as a fourth governance structure beside markets, hierarchies, and networks. This strand of literature pursues a comparative institutional approach, grounded in sociology and the theory of transaction cost economics (Williamson, 1985, 1991; Powell, 1990). A governance structure can be regarded as original if it features, first, a specific (explicit or implicit) contractual arrangement and, second, mechanisms of ensuring coordination of actions through a distinctive configuration of incentives and control (Williamson, 1991; Demil & Lecocq, 2005). Demil and Lecocq (2005) start from the observation that the OS model of software development is constituted by a specific contractual framework, i.e. an open license agreement, and thus a specific IP regime (cf. Bonaccorsi & Rossi, 2003). The license contract underpins a governance framework, which they call “bazaar governance”, referring to Raymond (1999a). Based on empirical studies from OSS, they describe it as combining weak incentives and weak control, as opposed to markets (high incentives/weak control), hierarchies (weak incentives/high control), and networks (intermediate on both dimensions). Although bazaar governance can be supported by “administrative rules”, “no formal fiat can enforce decisions within the bazaar” (p. 1454), distinguishing it from hierarchy. In contrast to market transactions, bazaar exchanges are not mediated by the price mechanism. And unlike networks, which are characterized by access restrictions, strong personal relationships, reciprocity and mutual dependence, as well as a usually longerterm engagement (Powell, 1990), bazaar governance features open membership (cf. G. K. Lee & Cole, 2003), anonymity, and the chance to free-ride or leave at any time (cf. von Krogh & von Hippel, 2006a). The question arises, whether bazaar governance is suitable to the development of physical goods and whether it is being applied in open design projects. To investigate this topic, I want to analyze the projects’ approaches towards incentives, control, and contractual frameworks. A special focus will be the IP regime, both regarding the employed licenses as well as regarding strategies towards selective revealing of private knowledge. As noted earlier, OSS licenses are usually classified according to the restrictions they impose on derivative works (e.g. Bonaccorsi et al., 2006). The choice of a specific licensing model may affect a project and its potential contributors. Restrictive licenses limit what people can do with the software.

40

Chapter 4. Research design and methodology

For example, they might constrain commercialization and thereby reduce the perceived usefulness of the software for those seeking to advance commercial interest. Restrictive licenses also limit abilities to employ the code in conjunction with software distributed under less restrictive terms and thereby reduce compatibility with other applications. Investigating the implications of the choice of a licensing model, Comino et al. (2007) show that OSS projects distributing their software under highly restrictive regulations are less likely to reach an advanced stage of development. Similarly Stewart et al. (2006) find that projects that use a nonrestrictive license attract greater interest among potential contributors over time than those that use a restrictive license. It could be assumed that these relations also hold for open design projects, as the licensing models are very similar and many projects use open source software licenses: P3: Highly restrictive licenses are negatively correlated with project advancement.

(4) Development process Since many open design projects are still in an early stage, research on the flow of the process, its efficiency, and comparative duration (time to market) is still in its infancy. The efficiency of OSI processes is assumed to be high, if uncertainty regarding the formulation of the problem and required solutions is high (Gl¨aser, 2007); if the project scope is large (Thompson 2002), but composed of “routine or narrowly defined tasks” (Carr, 2007, p.3); if economies of scale in production are weak (Demil & Lecocq, 2005); and if projects are situated in “cumulative innovation environments” (Maurer & Scotchmer, 2006, p.30). In this realm, a study focus on responsibilities for development and production processes appears to make most sense. Who drives and coordinates the project? Who takes care of producing the product? And how does the intensity of cooperation relate to other project characteristics? In particular we miss empirical studies on OSS development processes based on which to draw comparisons to open design. In one study Crowston and Scozzi (2002) find that OSS projects with higher activity are in a more advanced stage of development. Therefore, I restrain my proposition in this category to the intensity of the co-operation and propose for open design: P4: Developer activity is positively correlated with project advancement.

Chapter 4. Research design and methodology

41

(5) Innovative outcome It has been widely acknowledged that OSI is a disruptive process innovation affecting the mode of product development (e.g. von Krogh & von Hippel, 2003a). Concerning product innovativeness of developed outcomes, perceptions of the degree of innovativeness (R. Garcia & Calantone, 2002) of OSS and OSI solutions differ substantially among researchers (Lamastra, 2009; Economist, 2004), ranging from OSI often spawning radically innovative solutions (Osterloh & Rota, 2007) to its mostly generating incremental innovations, if any (Carr, 2007). I therefore adhere to empirically investigate different degrees of innovativeness among open design projects and again relate this characteristic to other project characteristics. According to the nature of the final product, target users may either be typical end users, more advanced users, or the developers themselves. In an OSS setting, researchers found the selection of a specific target audience to be highly relevant. Studies show that relevant reasons for contributing to an OS project are related to the desire of learning and performance improvement (e.g. M. A. Rossi, 2006). Sophisticated applications targeted towards an advanced audience may on average offer more learning opportunities to the individual contributor than projects addressing end users directly. Accordingly they may have a higher likelihood of receiving substantial contributions from developers. For instance, Healy and Schussman (2003) observe that while end user applications are the most downloaded OS software, developers rather focus on more advanced and sophisticated applications, like programming applications providing basic functionalities to an operating system. In the field of OSS, also Comino et al. (2007) show that applications targeted towards more advanced users and developers are indeed more likely to reach an advanced stage of development. Therefore, I will study for open design whether: P5: Addressing an advanced audience is positively correlated with project advancement.

(6) Environment Several environmental factors have been found to support or hinder the organization of non-software development projects according to the OSI model. The existence of strong supporting tools that are easily accessible to the developer community is usually deemed a critical foundation (J. M. Garcia & Steinm¨ uller, 2003; Thomke, 2006). Clearly, the Internet is one such crucial

42

Chapter 4. Research design and methodology

tool (e.g. Hope, 2005). Additionally, the existence of a common language between developers, i.e. a codified mode of exchanging information, is a sine qua non (Partha & David, 1994). This precludes OSI-type development in fields with high reliance on tacit knowledge (G. K. Lee & Cole, 2003). Other factors mentioned in the literature are the network embeddedness of projects as a supporting factor (Grewal et al., 2006), communication and knowledge exchange across projects (M´endez-Dur´on & Garc´ıa, 2009), object-related regulation (Lerner & Tirole, 2004), and the configuration of institutions protecting IP (Modica, 2008). In this regard, Maurer and Scotchmer (2006, p.30) “expect open source projects to arise in markets where traditional IP incentives are weak”. To shed light on the topic of projects’ environments, I will investigate the geographic and industry background of such projects as well as the use of supporting tools as means of communication. However due to the wide scope of environmental factors and the lack of suitable systematic empirical studies, I will not phrase an explicit proposition relating environmental factors to project success.

4.3

Methodological research approach

The aim of this dissertation is to explore the landscape of open design and to investigate the topic of openness in open design. For this purpose I empirically study research questions following a multimethod research design. This approach incorporates both qualitative and quantitative strategies in the study of the same phenomenon (cf. Johnson & Onwuegbuzie, 2004). The use of a variety of methods to examine a topic is generally considered to result in a more robust and generalizable set of findings, because it ensures that the variance reflects that of the trait and not of the method. The application of multiple techniques may also uncover some variance which otherwise may have been neglected by single methods (Jick, 1979). I decide to employ qualitative field-work and a quantitative survey to allow for methodological triangulation, i.e. the combination of methodologies in a single study. Increased triangulation of methods improves the possibilities to draw conclusions (e.g. Warwick, 1975; Scandura & Williams, 2000; Shah & Corley, 2006) and thereby improves external validity. Due to the dearth of previous studies on open source innovation of physical goods, my research begins with a very open, exploratory approach. Accordingly my first two main research questions, Q1 and Q2, are formulated

Chapter 4. Research design and methodology

43

as open-ended questions. Following the archetypes of methodological fit in field research by Edmondson and McManus (2007), the state of prior research could be classified as intermediate. I therefore combine formulating open-ended questions with prosing relationships between new and established constructs (Eisenhardt, 1989). Propositions are developed deductively based on existing theories and concepts from the literature on open source software (Section 4.2) prior to my empirical work and then related to open design in my research. Integrating qualitative and quantitative approaches is particularly recommended for intermediate theory research to help establish the external and construct validity trough triangulation (Edmondson & McManus, 2007). Due to the explorative nature of my research and the open research questions, I start with the qualitative research approach as, e.g., recommended by Yin (2003). A broad field study on the variety of open design thereby offers high generalizability and high contextual realism, but suffers from low detailed examinations. My study in Chapter 5 outlines the variety of open design and investigates implications for my research propositions. Based on those findings the focus will subsequently be on the question of how open design works. For this purpose a multiple case study appears to be the most suitable approach and will be conducted in Chapter 6. The comparative case study allows for highly detailed investigations and understanding of causality, but instead lacks on generalizability and reliability (e.g. McClintock, Brannon, & Maynard-Moody, 1979). Building on the results from my first two empirical studies, I finally arrive at the topic of openness in open design. From the collected data, I inductively derive a set of clear-cut research hypotheses regarding the meaning of openness in open source as, e.g., recommended by Garson (2002). A large-scale empirical study surveying contributors in open design communities and investigating these hypotheses finally compensates potential drawbacks from my qualitative work. It offers great external validity and provides possibilities for statistical analyses together with high reliability and facilitated replication (e.g. Johnson & Onwuegbuzie, 2004). In the following, statistical tests are performed (Chapter 9) and explanatory models are developed (Chapter 10) to investigate implications for my hypotheses and to complete my research on openness in open design. Thereby I attempt to treat the second research focus as identified in Section 3.5 and answer the main research questions Q3, Q4, and Q5. Table 4.1 attempts to provide an overview of my research approach. Details

44

Chapter 4. Research design and methodology

Study Topic 1 The variety of open design 2 Mechanisms of open design 3 The meaning of openness

4

Research Question Q1: What kind of open design projects emerged so far? Q2: How does open design work in practical examples? Q3: Does the degree of openness matter to the communities? Q4: Does the meaning of openness differ between open source software and open design? The impact of Q5: How does openness imopenness pact developer’s satisfaction and their contributions?

Method Broad field study (n = 104) Multiple case study (n = 6) Large-scale survey (n = 309), descriptive analysis Model-based analysis of survey results

Table 4.1: Summary of my methodological research approach concerning the three concrete empirical methodological research approaches to investigate the variety of open design, to deeply analyze how projects work and to systematically explore the topic of openness in the realm of open source will be given in the following three subsections.

4.3.1

To discover the variety of open design

In order to investigate the variety of open design, I have compiled a pool of open design projects, based on thorough research of secondary data and suggestions by industry experts in spring 2008. To continually advance this data source and to further collect data concerning practical applications, I launched a community-based directory of open design projects on 26 August 2008. Registration is for free and participants are encouraged to contribute by entering new projects as well as by maintaining all the existing information up-to-date. The platform has been quickly embraced by the larger open source community. After one year, I counted already 66 registered members, as of 1 April 2010, exactly 100 participants registered. Furthermore, I observe fairly satisfactory numbers of visitors, exhibited in Figure 4.2. The chart shows the number of unique human visitors per month and visualizes a fluctuating, but obvious increase of attention. To my knowledge, my site (http://open-innovation-projects.org) contains the largest existing online directory collecting and providing informa-

45

2500

Chapter 4. Research design and methodology

2000

1864

1500

1649 1378

1000

1145 976 987 994

1151 1111 1073 973

1441 1436 1307 1224 1217

404 375

0

500

Number of unique visitors

2153

09/08 10 11 12 01/09 02 03 04 05 06 07 08 09 10 11 12 01/10 02 03

Figure 4.2: Unique human visitors from September, 2008 to March, 2010

tion about open design projects. Since its inception, 163 project entries have been created, of which I needed to exclude 22 due to complete inappropriateness, e.g. because they where pure spam entries. Accordingly I arrive at 141 relevant projects entries. Projects are characterized along more than 20 characteristics. Every entry is carefully checked and only approved information is visible online and integrated into the database. The quality check not only eliminates spam entries; it primarily avoids that information is purely based on declarations of the project administrators rather than on objective measures. This is particularly important for attributes as complexity or innovativeness, where I have to take care to apply the same scale to all projects. Missing data is filled as far as the respective information on projects is available. In some cases project representatives have been contacted and asked to provide specific details. In a second step, I analyze each entry to check project conformity with the definition of open design as outlined in the beginning of this chapter (Section 4.1.1). 104 projects have currently been identified as such, while 37 projects have been excluded due to the following reasons (cf. Figure 4.3): • In 18 approved projects I could only observe pure revealing of information without the intention for collective development required by the definition of open source innovation. Examples are communities of

46

Chapter 4. Research design and methodology

141 18 4 8

Approved projects

Collaboration

Revealing

Hardware

7

104

Setup unclear

Classified as OD

Figure 4.3: Break down of approved projects on reasons for exclusion and selected cases

hobbyists exchanging their ideas and instructions on sewing patterns, IT hardware components, or similar. • 4 projects are abandoned, because they do not freely reveal relevant information. Those projects could be tagged “Open Innovation” according to Chesbrough et al. (2006). In these projects companies solicit ideas from the community, but do not share their knowledge for open co-development. • Another 8 cases have been excluded due to my focus on physical goods. Those cases include projects as, for example OpenStreetMap and Open Source Cookbook, which should be considered open content rather than open design. • 7 entries could not yet be classified, because their approaches towards collaboration and free-revealing are not yet clear.

Chapter 4. Research design and methodology

4.3.2

47

To understand how open design works

The dearth of secure knowledge on open design necessitates another exploratory approach. I choose a multiple case study approach, believing this avenue to be the most appropriate and promising method at this stage of my work to proceed. Case study research is generally chosen when ‘why’ or ‘how’ questions are being posed on current events over which the investigator has little control (Yin, 2003). It is particularly suited to research into contemporary phenomena with the purpose of advancing theory (Eisenhardt, 1989; Gillham, 2000). Multiple case analysis is generally regarded as being more robust than single case studies (Yin, 2003). As recommended by Pettigrew (1990), I therefore select cases to “fill theoretical categories and provide examples of polar types” (Eisenhardt, 1989, p.537). Based on previous research results, two dimensions of categorization appear particularly relevant: artifactual characteristics (complexity, modularity, industry) and characteristics of the developer community (individual developers only, joint community-company projects). For each category I strive to have at least two cases in order to allow findings to be replicated (Yin, 2003). As an auxiliary condition I demand that all projects be well established, attracting a reasonable number of contributors and demonstrating some development progress across time. This criterion is not tantamount to selecting only successful projects, but serves to exclude very early-stage projects with yet unclear organizing structures and very little interaction. The final selection is based on the following four criteria: • Cases span different industries. • The objects being developed are characterized by different levels of complexity, ranging from very simple to very complex. • All projects are well established, attracting a reasonable number of contributors and demonstrating some progression in development across time. • The projects are in different stages of advancement Cases for in-depth analysis are selected from my database of open design projects, pursuing a multi-stage filtering process to optimize for these criteria. Purposeful sampling of information-rich cases is chosen as the most appropriate approach. In particular, I seek to mirror the diversity of projects in my case pool by selecting mutually dissimilar projects. During the filtering process, a considerable number of projects were rejected on conditions 3

48

Chapter 4. Research design and methodology

and 4, as they were in very early stages of development and did not have a strong base of contributors. In the end, this approach resulted in a choice of six open design projects. During data collection for each case, multiple sources of evidence have been used: First, documentations and archives written by the developer communities themselves or other authors were studied extensively. Second, I closely observed each community over a ten-week period, reading and triggering mailing list discussions, chat conversations, and forum entries. Third, 3-6 in-depth expert interviews per case were conducted using a semi-structured interview guideline (cf. Appendix B). Experts were mostly interviewed via telephone, but some preferred chat room conversations. Remaining questions were resolved in follow-up telephone calls, chats, or emails. My interview partners were chiefly either the project coordinators or company CEOs respectively or members of the project core team. For data triangulation, I compiled and then compared the information gathered during different interviews as well as a large amount of secondary data. Within-method triangulation is essential to check for internal validity, consistency and reliability (cf. Yin, 2003). Remaining questions or incongruities were addressed to my interview partners for clarification. Finally, the case study results were reviewed by some of my expert interviewees.

4.3.3

To investigate the meaning of openness

A web-based questionnaire survey among active participants of 20 open design communities has been conducted in order to systematically explore the relevance of openness and empirically test my research hypotheses. The questionnaire strongly builds upon findings from my first two empirical studies. Therefore, details concerning my survey approach are outlined after the required foundation has been built in Chapter 8.

Part III On the variety of open design

Chapter 5 Study 1: The open design landscape Until recently, limitations to the availability of successful empirical examples of open design projects have caused a noticeable gap in the scientific literature. In the following chapter I provide a quantitative study (n = 104) of relevant projects. My goal is to explore the landscape of open source development in the world of atoms, to analyze project characteristics, structures, and success, and to investigate similarities and dissimilarities to open source software development. Presented data in the following has been obtained from the online directory of open-innovation-projects.org as of 1 April 2010. For detailed explanations of variables please refer to Appendix A.

5.1

The variety of open design

In accordance with the selection criteria discussed in the previous chapter (Section 4.3.1), I examine 104 open design projects along the OSI framework (as presented in Section 4.1.2), linking (1) actors, (2) artifacts, (3) governance structure, (4) development process, (5) innovative outcome, and (6) project environment. Each of these encompasses multi-faceted issues, which could reach beyond a reasonable scope for this work. In order to provide an exploratory overview, I will analyze all six parts, but focus on some aspects of particular relevance. I present univariate statistics using barcharts, which show the number of projects per respective category. Due to data availability constraints not all K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_5, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

52

Chapter 5. Study 1

data fields could be filled for some projects, which is why most plots do not sum to 104.

(1) Actors: Background and number of contributors

32

22 19 16

0

5

20

27

10 15 20 25 30 35

40

57

Number of projects

60

80

95

0

Number of projects

100

Contributing actors stem from different backgrounds as shown on the left side of Figure 5.1. The chart illustrates the number of projects with active developers from the respective background. Different types of actors can contribute to the same project, hence the categories are not disjoint and multiple answers are possible. The data set contains 18 projects receiving substantial contributions from all three examined parties, 52 projects from a combination of user and commercial actors, 23 projects from user and research and 20 projects from commercial and research. Due to potentially divergent desires, the collaboration between those groups of actors is not always free of conflicts, but a number of projects manage to align differing interests and work towards a common goal (cf. Raasch, Schweisfurth, & Herstatt, 2010).

User

Research Background

Commercial

1

2−10

11−100

>100

Number of developers in a project

Figure 5.1: Background of contributing actors and distribution of number of developers in projects

Open design projects vary considerably in terms of community size and, more particularly, the number of developers. The right part of Figure 5.1 shows how the number of projects is distributed on the number of active contributors. While obviously a number of project leaders did not manage to attract any further contributors, other projects have to deal with the coordination of hundreds of, in some cases even more than 1.000, participating developers. As in similar analyses in the field of OSS, the distribution of participants appears left-skewed.

Chapter 5. Study 1

53

(2) Object: Type of products and complexity

56

40 30 20

10

9

7

0

0

Number of projects

18

34

10

30

20

30

40

50

43

10

Number of projects

60

50

In all considered cases, the artifact being developed is a tangible object, but information on the artifact is frequently digitalized for exchange during product development. Many projects incorporate written software code as a substantial part. I therefore categorize projects according to the type and amount of code that has to be developed (Figure 5.2, left).

Extensible trough software

Includes programmed components

Pure hardware

Low

Low−Medium

Medium

Medium−High

High

Degree of complexity

Figure 5.2: Typification and complexity of developed objects

The first category ‘Extensible through software’ includes all products whose functionality can be extended through software applications, e.g., laptops, mobile phones, and programmable robots. The second category ‘Includes programmed components’ contains products which require software to fulfill their intended functionality1 , but whose functionality cannot be extended through software applications, e.g., printers, cars, and medical prosthetics. A laptop, for example, can gain entirely new functionalities if new software programs are installed, whereas a printer, for example, will only be able to print and its functionality cannot be extended through adding software applications. ‘Pure hardware’, the third category, includes all products, which do not need a single line of code, e.g., beverages or most basic commodities. With 30 projects in the first category, about one third of the examined projects bear particular resemblance to OSS projects: The product might supply, for example, a software development kit (SDK) allowing developers to create suitable applications. However one can observe important differences to pure software development, as, for example, contributors need access to detailed hardware information in order to extend a product’s functionality. 1

covering microprocessors, digital signal processors (DSPs), and programmable logical devices, like field-programmable gate arrays (FPGAs), requiring written source code in a programming or description language to fulfill their intended functionality

54

Chapter 5. Study 1

More than half of the cases belong to the second category, where hardware development plays the major role and software development fades into the background, but remains important to control functionality. Both information on hardware, e.g. in the form of descriptions, specifications, schematics, etc., and software code are exchanged. In the third category the digitization of information happens, for instance, in terms of construction manuals, sewing instructions or recipes. The right part of Figure 5.2 shows the distribution of different complexity levels ranging from as simple as beer and lights to as complex as cars and intricate machines. The plot visualizes that all levels of complexity are being tackled by open design projects, but lower levels of complexity can be observed more frequently than higher degrees of complexity.

67 (85)

8

7

Copyleft Permissive Creative license license Commons

No Other Commercial license license open license

39 (68)

40

60

62 (104)

0

10

20

22 17

Number of projects

30

34

62 (63)

20

40

72 (81) 41

0

Number of projects

50

80

(3) Governance structure: Protection of intellectual property

Software

Interfaces

Schematics

Case Design

All

Figure 5.3: Type of selected license and degree of openness

As Figure 5.3 (left) illustrates many open design communities make use of an open license. Some of them use different license models for different parts of their released knowledge, multiple answers are therefore possible. As noted earlier, the two major categories of free software licenses are copyleft and permissive or non-copyleft. While copyleft licenses such as the GNU General Public License (GPL) are highly restrictive and insist that modified versions of the program must be free software as well, permissive licenses such as the Berkeley Software Distribution (BSD) license are less restrictive and allow modifications to remain closed-source. Beyond software, Creative Commons provides a menu of free licenses that copyright owners can use when releasing their work. These licenses delimit certain rights to the use of the work and differ in their restrictiveness, depending on the chosen type of license.

Chapter 5. Study 1

55

I observe that more than 50 percent of the projects make use of software licenses, mostly for software components. Some projects also use software licenses for hardware components instead of concerning themselves with the typically more complicated and less straightforward application of open hardware licenses. About 30 percent use Creative Commons licenses. In approximately 20 percent of the cases intellectual property is released without any license. In addition 31 cases (∼ 30%) decided to protect their name by registering a trademark. This strategy is not always free of conflicts, as in the case of Arduino, for example, whose international trademark registration was accepted in many countries, but refused in the US, based on the fact that Arduino is primarily merely a surname.

I further observe that many projects carefully select which knowledge to keep secret and which parts to release. The right chart of Figure 5.3 shows the number of projects revealing information across four categories - software, interfaces, schematics, and case design, and summarizes these categories in the last stack, which presents projects laying open all relevant information across all four categories.

The numbers in brackets indicate the total number of projects for which this category is relevant. By relevant I mean that the respective artifact includes parts of this category and development work on those parts has already started such that the question of revelation thus arises.

This analysis shows that it is common across all examined projects, which include software development to open at least parts of their software. Almost 90 percent reveal information on hardware interfaces, thereby allowing participants to access their hardware without necessarily publishing all details concerning it. About 80 percent publish schematics or similar information containing particulars about hardware components. Only slightly more than half of the relevant projects decided to release their case design. Assuming that the revelation of knowledge is based on conscious decisions, one might conclude that projects typically derive more advantage from publishing software source code than from publishing other parts of their design. In total I observe that in almost 60 percent of my cases it has been decided to reveal all relevant information. Reversing this argument, that means that about 40 percent of the examined projects pursue strategies short of complete openness.

40 30

22

20

Number of projects

20

19

47

17

18

Project leader

Core team

10

32

30

30

40

35

10

Number of projects

50

Chapter 5. Study 1 50

56

5

4

Out− sourced

Un− clear

Core team

Com− Related munity company Coordinating actor

0

0

2

Project leader

Other

Com− Related munity comp. Producing actor

Figure 5.4: Distribution of actors promoting and coordinating the development and of producing actors

(4) Development process: Responsibility for development and production, age and activity of projects At this early stage it is hard to capture process evolution and efficiency on a quantitative basis. With Figure 5.4, illustrating which group of actors is mainly driving a project (left) and which takes the role of the producer (right), one gains first insights into different configurations of development and production processes. Projects which have not yet started the production of prototypes or final products are tagged ‘Unclear’ in the right chart. As different groups of actors might drive a project together as well as the product could get produced by different actors, multiple answers appear frequently. The chart visualizes that for a large proportion of examined projects the development is driven by a focal company (20−30%), and even more products are marketed and produced by a focal or related company (∼ 45%), even though the project might be community-driven. Correspondingly the plot shows that in 70 − 80 percent of the projects the product development is driven by private contributors, i.e. by the project leader, the core team or even the larger community without a dedicated authority. In about half of the respective cases this group also acts as producer, the second half interacts with a company supporting production and marketing. Furthermore the data set contains 5 projects outsourcing the production of the entire product to an external manufacturer who is not associated to the project or its community. Figure 5.5 displays the years projects have been started (left) and their recent activity (right). It can be observed that most projects (∼ 70%) have been initiated in 2005 or later. Only about 15 percent of the registered projects are older than ten years. The right graph shows that activity levels are distributed almost equally across the examined cases.

57

15

40

Chapter 5. Study 1

6

6

4

4

4 3

34

Low

Medium

High

30

34

20 0

2

0

2

Number of projects

10

10

35

10

12

5

Number of projects

13 11

<98 99

00

01

02

03

04

05

06

07

08

09 Activity

Figure 5.5: Start year and activity across projects

(5) Innovative outcome: Development stage, target group, and innovativeness

30 20

28

17 13

10

Number of projects

40

41

0

5

1

2

3

4

5

Development status

Figure 5.6: Distribution of stages of advancement in projects

Figure 5.6 shows that most projects have not entirely completed development, but about 50 percent have reached a stable production stage and are marketing their products. 13 projects have only started planning and virtual development (Stage 1); 17 have started prototyping (Stage 2). 28 of my examined cases manage to produce fully working prototypes (Stage 3); 41 have established a stable production and have their product permanently available on the market (Stage 4); and 5 projects entirely completed the development and refrain from further work on it (Stage 5). One could argue that this distribution is skewed due to the fact that my database is fairly new and I started by entering projects known to me or other experts I talked to. This approach naturally leads to larger and more advanced projects. However, one could also argue the other way around as new and small projects profit more from my directory and have accordingly

37

30

21

20

Number of projects

28

9

8

0

10

20

25

10

30

35

0

Number of projects

37

40

Chapter 5. Study 1 40

58

End user

Advanced user Intended audience

Developer

Imitative

Incremental Discontinous Really new

Radical

Degree of innovativeness

Figure 5.7: Intended audience and degree of innovativeness

a higher incentive to enter information. On balance, I strongly believe that the database is representative and comprehensive. As development success is hard to evaluate across projects in different stages of advancement, the rest of this section remains limited to some preliminary findings on the intended audience (Figure 5.7, left) and the degree of innovativeness (Figure 5.7, right). The distribution of projects across target customers is quite uniform, which leads to the assumption that open design products are generally suitable for end users, advanced users, and developers. For the categorization of innovativeness, I follow R. Garcia and Calantone (2002) and evaluate the degree of innovativeness in five categories. My cases reveal that open design is applied to the whole spectrum from the generation of incremental to radical innovations with a higher proportion striving for incremental or intermediate degrees of innovativeness.

(6) Environment: Industry and tool support The project environment spans a wide range of topics, from technologies and tools to the legal and social framing. Figure 5.8 illustrates the variety of industry backgrounds of my examined projects, visualizing that open design is already being applied in a number of different industries ranging from very traditional industries such as ‘Food and Beverages’ or ‘Energy and Utilities’ to industries such as ‘Consumer Electronics’ and ‘Telecommunications’. From the distribution across industries, the researcher becomes once more reminded that the phenomenon of open development arises from the software domain. Most communities are either developing consumer electronics (∼ 30%) or IT hardware (∼ 25%), which are the industries where product development of physical goods is typically closest to software development. For machinery (∼ 10%) and automotive (∼ 8%) one can assume that products tend to be more complex and more different from pure software, compared

Chapter 5. Study 1

59

35 31

30

20 15 11

10

3

3

2

2

Construction

4

Entertainment

Consumer Goods

Energy and Utilities

Machinery

Automotive

IT Hardware

Consumer Electronics

0

4

Food and Beverages

5

Telecommunications

5

5

Education and Research

8

Pharma and Healthcare

Number of projects

26

25

Figure 5.8: Distribution across industries

to the two previously names industries. Less technical domains as consumer goods (∼ 5%), energy and utilities (∼ 5%), and pharma and healthcare (∼ 4%) lie even further from the original realm of OSS. The left side of Figure 5.9 shows the distribution of countries from which the examined projects originate. 41 of my collected examples stem from the United States, 12 from Germany and 9 from the United Kingdom. I further investigate 6 cases from Canada, 3 from Taiwan and 2 from Australia, Denmark, and Italy respectively. Beyond a couple of countries appear with just one project, in total about 15 countries have been named. However developers in the respective communities typically stem from different countries and the development is conducted largely distributed. Hence, another point worth investigating is the use of various tools for communication, development and archiving (Figure 5.9, right) allowing distributed participants to overcome constraints on communication and to access shared digital resources. Projects are typically communicating via the Internet, most common means of communication are mailing lists, chats and discussion boards, where most projects make use of more than one mean of communication. In the last stack ‘Other’ I summarize mostly newer communication technologies. It includes wikis and shared workspaces facilitating the co-creation

Chapter 5. Study 1

6 2

2

2

AU

DK

IT

40 30 0

3

TW

0

DE

GB

CA

39

41

39

24

10

10

9

50

60 12

US

61

20

20

27

Number of projects

41

30

40

50

70

60

Other

Face to face

Mailing− list Chat Board Means of communication

Other

Figure 5.9: Home countries and means of communication

of content across large, distributed sets of participants, blogs and podcasts offering individuals a way of sharing information with a broad set of other individuals, and social networks or hosting providers such as Sourceforge, offering contact management and access to hosting services. As different actors seem to prefer different communication tools, most projects make use of more than one tool. My data set contains 3 projects using tools from all 5 categories, 11 projects from 4 categories, 18 projects from 3 categories and 19 projects from 2 categories. Most communities are geographically dispersed and highly profit from the variety of communication tools accessible via the Internet. My observation of projects during the data collection period further reveals that participants constantly increase their effort to communicate with a large audience and rapidly pick up new means of communication.

5.2

Multivariate analysis

To gain first insights on relationships between variables, I examine correlation coefficients and conduct multivariate comparisons using relative measures as illustrated in Figure 5.10, where the diagrams are scaled to 100 percent to show trends in the data set. Correlations (ρ) are calculated as Pearson product-moment correlation coefficients giving a value between −1 and +1 inclusive. Significance levels of estimated correlations are obtained via analysis of p-values of two-sided tests for association between paired variables in order to confirm or reject the hypothesis that the underlying correlation is not equal to zero. In case of missing data, the respective pairs are excluded from the calculation. The left chart of Figure 5.10 visualizes the positive correlation between the number of active developers and stages of advancement of ρ = 0.4 confirmed

Chapter 5. Study 1

61

Community size vs. Development status

Activity vs. Development status

100

100

80

Percentage of projects

Percentage of projects

80

5 4 3 2 1

60

40

20

60

40

20

0

0 1

2−10

11−100

Number of developers

>100

Low

Medium

High Activity

Figure 5.10: Comparison of developer community size and activity against development status

by a p-value below 0.1 percent. One could conclude that larger projects reach higher stages of advancement or, vice versa, that projects grow while maturing. The right chart exemplifies the positive correlation between developer activity, measured by the frequency of their communication interactions and distinguishing between low, medium and high, and stages of advancement of ρ = 0.5 with a p-value below 0.1 percent. Higher activity appears to positively impact a projects’ development status. Not surprisingly I also find a significant positive correlation between the number of contributors and their activity (ρ = 0.4 with p-value < 0.1%). It appears reasonable to observe that more developers generate more activity. More details on correlations between selected attributes are summarized in Table 5.1. Exhibited are pairs of variables with absolute correlation values above 0.25 and high significance, i.e. p-values below five percent, which point to relationships between different constituents of the underlying framework. Strong correlations between different variables of the same aspect, as it would be the case for open interfaces and open schematics, for example, shall not be the focus of this analysis. Due to space constraints in the table they are only partly exhibited. Remarkable is the strong positive relationship between development status, the presence of commercial contributors and a registered trademark. Commercial actors seem to favor to protect their work by registering the projects name, which is less often the case for private or research actors. Furthermore commercial contributions seem to have a positive impact on stages of

62

Chapter 5. Study 1

(1) (1) (2) (3) (3) (3) (4) (5) (5)

Commercial Com. size Complexity No license Reg. trademark Entirely open Activity Dev. status Innovativeness

Comm. 1 0.5∗∗∗ 0.1 -0.1 0.5∗∗∗ −0.4∗∗∗ 0.3∗∗ 0.3∗∗∗ 0

C.s.

Comp.

No l.

R.tr.

E.o.

Act.

D.st.

In.

1 0.1 −0.3∗∗ 0.5∗∗∗ −0.4∗∗∗ 0.5∗∗∗ 0.6∗∗∗ 0

1 -0.1 0.1 0 0.1 -0.1 0.4∗∗∗

1 −0.3∗∗ 0.2∗ −0.2∗ −0.3∗∗ 0.2+

1 −0.4∗∗∗ 0.3∗∗ 0.4∗∗∗ -0.1

1 −0.2∗ −0.2∗ 0.2+

1 0.5∗∗∗ 0.1

1 0

1

Table 5.1: Estimated correlations between selected variables advancement, a correlation that clearly has to be examined more carefully because the relationship might also be due to companies joining projects in later stages or projects founding companies in order to market their products. The correlation between late stages of advancement and registered trademarks may be easily explained as it might make more sense to protect a project’s name if success is augured. One observes strong negative correlations between entirely open projects and the presence of commercial contributors as well as registered trademarks and between the size of the community and the absence of licenses as well as complete openness. Both the absence of licenses and complete openness might reflect a general absence of IP strategies, which seems to negatively affect the size of the community and is rarely observed if commercial actors are involved. The data shows a positive correlation between the degrees of complexity and innovativeness. This relationship could arise from biased entries as both categories may be subject to biased perception of the person entering the data. However to avoid this type of bias I carefully checked every entry made by external contributors, and only approved entries are being considered in my analysis. Accordingly I arrive at the observation that projects developing highly complex products seem to or at least plan to achieve more innovative outcomes. Innovativeness also shows slightly positive correlations to entirely open projects and the absence of licenses. Furthermore one may observe high positive correlations between the size of the developer community and commercial actors and registered trademarks, as well as between activity and registered trademarks, and a high negative correlation between community size and complete openness. These correlations are closely connected to the relations discussed earlier in this section and hint to high interrelations between the different variables. Closer investigation of dependencies among variables appears required in order to arrive at secure evidence about actual relationships among the constituents of the open source innovation framework as presented in Figure 4.1.

Chapter 5. Study 1

5.3

63

Discussion of outcomes and research propositions rethought

Open source development appears to be feasible for tangible products. More and more physical products are being designed collaboratively via the Internet, but it is mostly early days to evaluate success. There are several promising precedents, which have entered the market, though. In this section I discuss first implications of my findings for the propositions proposed in Section 4.2 and point out anchors for my following research. (1) Actors Quite a few open design projects manage to attract a sufficiently high number of active contributors, both from private and commercial backgrounds, to build a developer community and to achieve progress in terms of project advancement. Compared to OSS repositories such as Sourceforge, my sample does not contain the large proportion of projects with just one developer, no discussion and no interest from the larger community. Healy and Schussman (2003), for example, arrive at the conclusion that for every successful OSS project there are thousands of unsuccessful ones. I am not claiming that this might be different for open design; however, I have so far not observed as many of those projects. This might partly have its seed in the definition of open source innovation, requiring the intention of collaborative development, and partly arise from the fact that the open design phenomenon and more particularly my directory is fairly new and accordingly the number of failed and inactive projects is low compared to large and longer established OSS repositories. My multivariate analysis supports my first research proposition P1 for tangible products, showing a strong positive correlation between the size of the developer community and project advancement. As discussed in the previous section this might arise from different factors. On the one hand one might guess that projects tend to grow over time and that it could be easier for successful projects to attract considerable attention from the broader developer community; on the other hand a larger community might push ahead development. In the software realm, Krishnamurthy (2002) found no relationship between the release date and the number of developers associated. Based on my sample it appears that this finding holds for open design, as no significant correlation can be determined between the age of a project and the size of

64

Chapter 5. Study 1

its developer community. Following this thinking one gets a first indication that indeed a larger community positively influences project advancement. The second proposition P2 is likewise supported from my analysis revealing a positive correlation between commercial actors and project advancement. Taking both observations together, I find that projects with a large community, which includes commercial actors or is even organized by professionals, have a high likelihood of reaching advanced stages of development. Due to potentially divergent desires, the collaboration between those groups of actors is not always free of conflicts, but apparently a large number of projects manage to align differing interests and work towards a common goal.

(2) Object Although the comparison of object characteristics between open design and open source software is only meaningful to a certain extent, I want to highlight three particular aspects - the complexity of the object, its modularity and its digitization. All levels of complexity can be observed across the examined artifacts and no strong evidence could be found pointing out that low- or high-complexity products are more suitable for open source development. I further observe that complex objects frequently are modularized into manageable pieces and developed separately. This observation reveals similarities to OSS development, where this finding has been reported by Baldwin and Clark (2006). My third observation is that participants make a large effort to enable digital design and development as far as possible. In addition, the development of comparably cheap 3D printers, CNC cutters and similar tools for home use increasingly enables developers to produce their own designs independently of a central production. With the emergence of communities around the necessary equipment to share expenses and ease access, decentralized production becomes increasingly accessible. Thus a focal producer providing the products is no longer a necessity, and open development of physical products becomes yet more similar to OSS development. Further examination of all three aspects mentioned appears clearly required in order to assess the potential to reach a larger audience and estimate the impact on open source development beyond software.

Chapter 5. Study 1

65

(3) Governance structure Open design projects generally tend to make use of an open license, but licensing is less straightforward than for OSS. The research proposition P3, proposing that projects distributed under highly restrictive terms are less likely to reach an advanced stage of development, is not reflected in my data set. I rather observe a positive correlation between trademark protection and late stages of advancement, and an interrelation between license-free release of information and small projects in early development stages. As discussed this might reflect the general existence or absence of IP strategies and their influence on project success. However, I could not determine a clear-cut relationship between sophisticated strategies towards revealing of certain components under certain rights and development status.

(4) Development process Across my case database, I observe different groups of actors being responsible for the creation of a product concept, the actual development work, and the final production, but find no formally distinguishable patterns. Detailed further analysis is required in order to arrive at statements about process design, evolution, and efficiency. I do find a strong correlation between the intensity of developer activity and development stage, supporting my proposition P4. As a result I conclude that both OSS and open design projects with higher activity tend to be in more advanced stages of development. However, in both fields further research is required in order to arrive at conclusions about the impact of process design on project success. A major difference between software and tangible products obviously lies in the necessity of physical production prior to marketing a product. My observation that many projects buy parts in addition and some even decide to outsource production of the entire product requires projects to thoroughly consider strategies towards market transactions. The tradeoff between increased efficiency through adding readily available components and increased freedom of design, in particular towards openness as external parts are frequently non-open source, seems to be an important topic within many communities.

66

Chapter 5. Study 1

(5) Innovative outcome Open design projects tackle both incremental improvements and radically new designs. For both extremes my data provides examples, which have reached fairly high development statuses. I observe projects, which are in late stages of advancement, either addressing developers or advanced users or developing products suitable for end users. My last research proposition P5 proposing that applications for sophisticated users are more likely than others to reach advanced stages of development is not supported by my investigation. Given that Comino et al. (2007) derived their hypothesis from findings on the motivation of participants, this observation could hint to differences in the reasons for contributing between open source software and tangible goods. Clearly further investigation is required prior to deriving conclusions on this topic. Particularly the impact of innovativeness of the intended outcome on participants, their motivation, and subsequently their contribution appears to be an interesting subject for my further research. (6) Environment My examples stem from a variety of different industries with a large subset in consumer electronics and IT Hardware. The development of these products does not only typically involve a large amount of software development, but many of these products are also shapeable through software. This characteristic makes them very attractive for open source software enthusiasts. For instance, by changing a mobile phone’s software users can add new functionalities and customize their device to a high degree; and through access to hardware interfaces developers can modify the purpose of a chip. Both examples illustrate potential reasons for the desire to gain access to relevant information. This may explain the rise of open development activity in those industries. A precondition for the feasibility of the OSS phenomenon is the existence of strong supporting tools, in particular the Internet, that are easily accessible to the developer community. For open design, especially in the technical domain, new suitable tools seem to be of particular importance to enable digital development of tangible artifacts. I encountered, for example, free or cheap design software, platforms for the exchange of designs, and open source equipment for prototype production. In other cases I also observed how the absence of required tools decelerates the entire development work.

Chapter 6 Study 2: Open design of tangible goods – A comparative case study At this early stage of research on the open design phenomenon keeping an encompassing view seems advantageous as discussed in Chapter 4. Drawing on six comparative case studies, I analyze the workings of open design in the following chapter. The presented case study has mainly been conducted from April to July 2008. Project descriptions have been updated until February 2010, however analyses of project setups remain as of 2008.

6.1

Overview of cases

In accordance with the selection criteria discussed in the Section 4.3.2, I examine cases from very different industries, including automotive, consumer electronics, mobile communication, and beverages, for example. The cases vary in terms of the complexity of the object being developed, ranging from as simple as beer to as complex as cars. Most of the projects attract several hundred contributors. Two projects already resulted in fully functional products offered in the market (Free Beer and Neuros OSD). Two cases (Openmoko and RepRap) spawned test versions or components available for sale. While the OSGV (Open Source Green Vehicle) project had plans to build a prototype in 2009, OScar is still in early development. Table 6.1 provides an overview of the selected cases. K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_6, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

68

Chapter 6. Study 2

OScar

Start 1999

Industry Automotive

RepRap

2004

Rapid prototyping

Free Beer OSGV

2005

Beverages

2005

Automotive

Openmoko

2006

Mobile communication

Neuros OSD

2003

Home entertainment equipment

Object ‘World car’ with sustainable mobility concept Self-replicating 3D-printer for home use Beer 7-passenger sports utility vehicle with various fuel options Mobile telephone

Linux-based, embedded media center

Coordinator Markus Merz, Monocom, DE

Size ∼ 3, 000

Dr. Adrian Bowyer, Bath University, UK Rasmus Nielsen, Superflex, DK David W. Lee, SSM, USA

∼ 100

Sean Moss-Pultz, Openmoko Inc., Taiwan Joe Born, Neuros Technology Inc., USA

∼ 2, 000

∼ 15 ∼ 250

∼ 30, 000

Table 6.1: Overview of selected cases

6.2

Case descriptions

In this section, I will provide a short overview of each project for later reference, starting with community-driven projects.

OScar The OScar project was initiated by Markus Merz, a German former marketing manager of BMW and CEO of a small consulting firm designing ebusiness strategies for the automotive industry, in 1999. His aim was to find radically new ways in which automotive companies could use the Internet for developing and building cars (Blankman et al., 2000). He planned to complete a car design by virtual collaboration and then offer it to OEMs and suppliers for production. Merz started by writing a ‘manifesto’ and building a website to rally supporters to the project. Free access, public ownership of designs, and democratic decision processes with himself simply as an orchestrator were the principal tenets of his plan. The initial goal to complete a design within 36 months soon appeared to be too optimistic; two factors slowing the project down were the shortcomings of the website in attracting developers and the lack of focus and direction that came with the entirely decentralized approach.

Chapter 6. Study 2

69

After a relaunch of the project in 2005 and a redesign of the website with the help of two new core team members’ expertise, OScar began to attract thousands of readers and co-developers. Merz provided some development guidelines for OScar 0.2, but otherwise the design evolves from discussions in the community forums. The car is meant to be simple and cheap to produce (a ‘world car’) as well as economical in terms of fuel consumption. To date, the project is still in early design phase.

RepRap The RepRap project was initiated by Dr. Adrian Bowyer, a senior lecturer at the University of Bath, in 2004. In an article on the Internet and a press release he announced his goal to make a self-replicating machine, i.e. a 3Dprinter that is able to produce most of the parts needed to assemble another such machine. Today a commercial 3D-printer costs approx. USD 20,000, whereas the price target of RepRap lies below USD 400. In the beginning people just volunteered and where welcomed to the team. As the community grew, a core team was formed to drive and coordinate development, while maintaining a decentralized, mostly non-hierarchical structure. Tasks are mostly self-selected by developers instead of assigned; decisions are taken by voting. Both development and production of the 3Dprinter are decentralized, being accomplished by geographically dispersed project members communicating only in the virtual world. The first fully functional, self-replicated copy of RepRap v1.0 (called ‘Darwin’) was completed in June 2008 and celebrated as a great success. The next goals are the reduction of incorporated third-party components, the improvement of the printing technology, and the expansion of the community. As the development progressed, several spin-offs emerged from the RepRap project. Makerbot, for example, is trying to develop a desktop fabricator, which shall be more precise than the original RepRap, but on the other hand will be more complex in production.

Free Beer Free Beer, previously known as Vores Øl (Danish for Our Beer), is commonly regarded as the first open source beer. It was originally created by students in a class on copyright issues at the IT-University of Copenhagen together with Superflex, a Copenhagen-based artist group. They set out to illustrate

70

Chapter 6. Study 2

how concepts of the free software movement could be applied outside the digital world. They first brewed about 100 bottles of Vores Øl 1.0, a beer based on classic ale brewing traditions, but with added Guarana, in the school cafeteria in 2005. The amount of feedback and media attention they received came as a surprise. People started to discuss the recipe, and thus the project emerged although there was initially no intention to continue beyond a one-off experiment. Superflex then took the idea further and has since released several new, revised versions based on feedback from testers. By now Free Beer is brewed on a large number of different occasions ranging from student parties and conferences in Germany to exhibitions in Brazil. The original team is still guiding the development. In addition, Project21, a Swiss student organization for sustainable development, created a spin-off under the Free Beer trademark in 2007. They developed a new recipe and first brewed 1,000 liters in a local brewery. Again they received unexpectedly strong feedback, hence decided to continue, and found a sponsor. Within one year, they sold approx. 5,000 liters of Free Beer. Today, Free Beer is produced and marketed by two breweries in Copenhagen and Zurich.

OSGV The OSGV (Open Source Green Vehicle) project was initiated by David W. Lee, who is still project manager; it is run by the SSM (Society for Sustainable Mobility), a non-profit automotive engineering group set up in late 2005. The project goal is to employ open design to contribute to solving environmental issues, particularly to promote sustainable mobility (cf. D. W. Lee, 2008). Following market analysis and lengthy discussions on the project forums, Lee decided that the design should be a seven-passenger SUV. The design should allow easy swapping of the power generating unit and thus fuel type (gasoline, biodiesel, hydrogen fuel cell, ethanol, natural gas). A core developer team then defined open specifications on the system, sub-system and interface level. Based on this set of tightly controlled specifications, a community of about 250 members completed a preliminary design in early 2008. Further development and the building of a prototype are to be accomplished by 2009. To achieve this goal, SSM has licensed the design to a venturecapital backed start-up company, which will finish development and take on production. However, as of early 2010, it appears that no further activity has happened since late 2008.

Chapter 6. Study 2

71

OpenMoko In early 2006, Sean Moss-Pultz assembled a group of four core developers to run an open source software project for a Windows-Smartphone on behalf of FIC (First International Computer, Taiwan), a producer of hardware. In answer to strong media and industry interest in the project, FIC put their Windows plans on hold and increased resources for developing a Linux-based Smartphone. In late 2006, they announced the development of an open mobile telephone, in which openness would include software and hardware. Two years later, the time I conducted most of this study, thousands of community members participate in the development of both hardware and software, shaping the result to a large extent. Openmoko, Inc., founded as a subsidiary of FIC in early 2008, employs approx. 70 geographically dispersed developers to improve the current design into a mobile phone suitable for the mass market. In addition, thousands of community members are contributing to the development of both hardware and software, shaping the result to a large extent. The first 5.000 prototypes were put on the market in July 2007 and sold out within one month; in July 2008, the second generation was launched with similar success. In May 2009, Openmoko Inc. decided to layoff at Openmoko and to commit the project to the community. All the design information of the previous development has been handed over to the community along with all of openmoko.org. Openmoko Inc. announced to continue to act as a sponsor funding all necessary server infrastructure and support, in areas where corporate help is needed.

Neuros OSD Born as a spin-off of Digital Innovations, Neuros Technology, a Chicagobased company with approx. 35 employees, sells audio and video devices, among them the Neuros OSD (open source device). The Neuros OSD is an open source, Linux-based, embedded media center, i.e. a device to record digital content from various sources and to store and output this content in a standardized format used by most digital devices, from MP3 players to mobile telephones. Faced with three problems, the need to innovate, the need to obtain very detailed customer feedback on application features, and the need for speed in the fast-moving video space, Neuros CEO Joe Born decided to continuously integrate users into product development. Thus, Neuros successively

72

Chapter 6. Study 2

laid open its design specifications and development process to a growing community of Neuros OSD users for feedback, bug tracking, documentation, and co-development. Still, some parts of the design, e.g. components delivered by third party vendors, as well as corporate decision processes remain closed to the public. As of 2008, a new generation of Neuros OSD is being developed. While most of the work is done in-house, user solutions are integrated as available. Additionally, contract-based development assignments to users and the shipping of testing versions (either for free or with costs, depending on development stage) to user developers support their involvement.

6.3

How does open design work?

6.3.1

Who drives open design projects?

Mirroring findings from my study of the open design landscape and from OSS, I identify community-driven (OScar, Free Beer) and company-driven (Neuros OSD, OpenMoko, OSGV) open design projects as well as projects led by members of research institutions (RepRap). In the Neuros OSD case, one company directs the development process and delivers most of the work, laying open its designs for a community to co-develop. OScar, by contrast, is entirely community-driven, similar to the RepRap project in which a community is guided by a university researcher combining project and academic work. In between lie Free Beer, which unites a community of users with commercial contributors and producers, OSGV, which set out with a community of individual contributors and researchers led by a non-profit organization, but has been largely taken over by a start-up company, and OpenMoko, which has initially been driven by a company, but has lately been successfully handed over to the community. “I am very impressed by the community’s energy and motivation to carry on, even though the manufacturer has stopped support” (Openmoko) Some scholars of collaborative development have suggested that developers active in open design must possess strong and specialized skills, and that this necessity poses a substantial impediment to open design (Lerner & Tirole, 2004). My case studies mostly corroborate this proposition. In all cases I studied, apart from Free Beer, developers with special skills are required,

Chapter 6. Study 2

73

e.g. engineering, informatics, or electronics. In addition to depth of expertise, open design projects also tend to require developers from a considerable diversity of backgrounds. RepRap developers believe their group to be more multi-disciplinary than observed in most software projects. Similarly, the completion of a functional car design necessitates mechanical engineers and automotive engineers as well specialist disciplines such as high-power electronics, fuel efficiency, safety, etc. Prior experience with OSS development is not typically deemed an important prerequisite for participation in open design, and indeed many developers do not possess any. Still, an OSS background instills a knowledge of a “totally different development culture and an appreciation of openness, of the fact that open or free standards are preferable to some proprietary solution for the design process” (OpenMoko). Developers with prior experience in OSS projects may thus be particularly likely to subscribe to the goals pursued in open design.

6.3.2

What is being developed?

In all my cases except one (Free Beer), the artifact being developed is modular. Perhaps even more importantly, these open design projects make a particular effort to develop the artifact in a modular way. Thus, the open design even of very complex objects is considered feasible, as long as they can be modularized. These findings are in accordance with studies on modularity in the field of OSS (MacCormack, Rusnak, & Baldwin, 2006; Baldwin & Clark, 2006). In the Free Beer project, in which an integral product is developed, the low level of complexity of the object enables collaborative and dislocated task completion despite the lack of task granularity. This suggests that the feasibility of open design depends jointly on the degree of modularity and the degree of complexity of the artifact. High complexity necessitates a modular architecture, while simple objects may be amenable to open design despite modularity being low. My cases reveal that development tasks of considerable complexity are tackled within open design settings. One important strategy to manage this complexity is outsourcing. Allowing for outsourcing to third-party suppliers, the fact that a mobile phone, for instance, includes a large number of sophisticated technical components, which would probably be beyond the OpenMoko community to develop afresh, does not preclude success within an open design set-up. This is illustrated by the following quotation:

74

Chapter 6. Study 2 “At a certain point in time someone has to make the boards [...] and things of that nature. But the thing that we’re working on, the open source, is the design. [...] nobody has time to assemble the boards.” (RepRap)

This strategy shifts complexity to a different level, i.e. specifications, interfaces, and documentation. However, across my cases, I also observe that projects developing more complex objects, tend to have reached less advanced stages of development so far (Figure 6.1, left).   

 

  

!
"



!
#$

 

 

! %

 

&!
'

()




!
"#



$

%
&



'(


          

   

(

"    "


       

 

'!  !

Figure 6.1: Complexity and innovativeness of developed objects versus stage of advancement Comparably, also the degree of innovativeness of the (intended) outcome seems to vary: Objects of low or high innovativeness are being developed in open design projects (Figure 6.1, right; cf. Section 5.1). According to several interview partners, open design is not by nature more appropriate to either high or low innovativeness. Rather, the degree of innovativeness of the developed design is commonly believed to depend on the vision of the coordinator and his core team. What seems noteworthy, however, is that, at least in this case selection, all highly innovative new designs are still in comparably early stages of development. Whether this holds any lessons for open design and innovativeness, I could as yet only speculate. Summarizing first findings on the characteristics of the artifacts developed in open design I find that, first, modular objects and simple objects seem particularly well suited to open design, second, feasibility seems to depend jointly on modularity, complexity, and innovativeness, and third, more complex, but modular designs can be completed with the help of third-party suppliers.

Chapter 6. Study 2

6.3.3

75

How are open designs developed and produced?

In my case study, I identify three different loci of production: with external manufacturers, with the community, or with the focal organization coordinating the project. OSGV and OScar plan to take the first route, once they get to this stage; RepRap takes the second approach, and Neuros OSD and OpenMoko the third. Free Beer is brewed both by the community and by large commercial breweries. Production by companies external to the project is typically chosen in open design projects, which do not have an OEM as their coordinator, such as OScar or OSGV. Besides the cost of testing and building physical objects and the potential of exploiting economies of scale in manufacturing, product safety and liability issues are important considerations. The RepRap 3-D printing machine is typically assembled by each developer from standard parts commonly available for sale and parts printed by another RepRap according to the project design files. Alternatively pre-assembled parts can be purchased from different vendors associated with the project to ease production. Hence, assembly allows for some choices, depending on the developers’ personal requirements and willingness to pay. Development tasks are performed by the community on their own machines, which are in various stages of completion. If an improvement is voted to be integrated into the official project design, they must either update their machines or stay with the older version. “If changes are made to the hardware, then everybody that’s got hardware already built has to start again or modify it. There’s some cost associated to this, which would not occur with software. They can just download it and they got it.” (RepRap) “Because every [component] is necessarily seen and assembled by someone that builds a RepRap, there’s a very complete peer review going on.” (RepRap) As these quotations illustrate, there is no clear-cut separation between design, prototyping, and production in the community production regime employed by RepRap, at least not at this stage. Once the design is finalized, the option of involving an external manufacturer for mass-production may be considered - although this does not seem a likely avenue at present. An amalgamation of development and production stages can also be identified in my two cases, which feature production by the company coordinating

76

Chapter 6. Study 2

the project. Both OpenMoko and Neuros OSD rely on “release procedures [which] are deliberately very soft” (Neuros OSD), whereby different test versions are produced and released to the community, either for free or at a cost, for testing and improvement. The target group for this co-development and co-testing process is successively expanded; advanced test versions are offered for general sale. Thus one version is sold in the market, while the follow-on improved version is being developed based on community feedback. What seems noteworthy in this context is a considerable fault tolerance among the community: Their eagerness to buy ‘bug-ridden’ beta versions or ‘developer samples’ for co-development took supplying companies by surprise. “This is our version of ‘release early, release often’. Developers decide whether they want to buy (or get for free) an earlier version full of bugs or a later version.” (Neuros OSD) “Gamma is a ‘white box’ pre-production product stage especially geared for hackers and hard-core early adopters. Gamma is the next stage after Beta, it’s the first pre-production run, and we make it available to the public. Central to Neuros’ strategy is releasing products to the market quickly to get early feedback from hard core users as well as to give hackers a head start. In recognition of the fact that such products often change quickly and are not fully field tested, we offer an extended no questions asked return policy on such products. In addition, we also often offer compensation for participation in feedback surveys and focus groups, etc.” (Neuros Technology 2008)

6.3.4

Is open design really open?

The sharing of design information was seen as the fundamental norm of open design by all interviewees, and many took pride in advancing a design of a physical product in an open environment. “The basic premise is: Everything that does not absolutely have to be kept internal, is public.” (OpenMoko) However, counter to the common understanding of (entirely) ‘open’ design, five of my six cases actually reveal some limitations to openness, according to either one or both elements of West’s conceptual dyad of ‘open parts’ and ‘partly open’ as discussed in Section 3.2.1. They rely on trade secrecy,

Chapter 6. Study 2

Rights retained by focal organization

Rights retained by supplier

‘Open parts’ “In order to establish a suitable level ‘proprietary’ position to attract investments, the ownership of [...] the intellectual properties should be maintained by a non-profit / forprofit corporation instead of allowing them to flow into the public domain (free-for-all).” (OSGV)

“Some parts of our system are not Open Source Software. We are forced to distribute them as binaries due to agreements with the vendor. It was deemed a reasonable tradeoff to bring the product to market at all. Some parts may be rewritten cleanly as OSS, but others are quite hard to get rid of.” (Neuros OSD)

77 ‘Partly open’ “For those interested in modifying the Neuros at the hardware level, we will do our best to release any and all relevant documentation regarding the technical specifications of the device as soon as we can. While market pressures may inhibit the amount of information we can share, we will share everything we can at the earliest possible time.” (Social Contract, Neuros OSD) “Open specifications are crucial. [...] Open circuit diagrams could be really useful for software developers, but board layouts are only needed by someone who wants to copy the product 1:1. For the sake of peaceful co-existence, the developer community should not ask too much in terms of openness.” (OpenMoko)

Table 6.2: Examples of ‘open parts’ and ‘partly open’ strategies in open design projects trademarks, and in some cases even patents. Limitations to the scope (‘open parts’) or the degree (‘partly open’) of openness are sought either by the suppliers of components or by the focal company or core team of the project. In several cases (e.g. OSGV, Openmoko), I identify limitations to openness in both degree and scope, i.e. the IP regime varies among the components. In other words, these designs included entirely open parts, partly open parts, and closed parts. Table 6.2 provides some case-based examples of these two strategies. The common denominator behind all these examples appears to be the endeavor to balance the interests of the designer community and commercial companies involved, e.g., as suppliers or manufacturers. In several of my cases, there is an awareness that, by deciding to ”leave enough room to encourage private investment” (OSGV), the community can improve its probability of success. The major exception among my cases is the OScar project core team who consciously reject this avenue: According to founder Markus Merz, adherence to OS principles, particularly openness, takes precedence over bringing the car to market. OScar is primarily intended to prove the feasibility of an open car design, which is why actual production is deemed secondary.

78

Chapter 6. Study 2

In all other cases decision makers try to promote project success by carefully weighing community and commercial requirements. Some findings, particularly from the OpenMoko and OSGV projects, suggest that this trade-off is actually accepted by community members, as long as the balance is perceived to be fair. One of the OpenMoko core team members describes a give-and-take negotiation process. “On the part of technical developers, there is a desire to have completely open circuit diagrams; but there is also an understanding for the magnitude of the concession this would be for the investor. The compromise is: Circuit diagrams are revealed under a special NDA in order to facilitate the development of the software by programmers not working within the walls of the company.” (OpenMoko) One could speculate that developer culture in open design projects tends to be more lenient compared to OSS with regard to limitations to openness for the purpose of earning private rents. It is well understood that many designs are hard to produce by users themselves and therefore need to be manufactured commercially – if they are to be available to the community at all. While conclusions based solely on these results would appear premature, a comparison to OSS environments might yield interesting differences in community attitudes and behavior. This shall become a major focus of my research following throughout the next chapters.

Chapter 7 Intermediate conclusions and implications for proceeding 7.1

Discussion of first findings

The potential of external volunteers for product (co-)development was demonstrated starkly by the success of OSS development in recent years. In view of this phenomenon, many experts from academia and practice suggest that the ‘open source model’ may be applicable to other industries. This assumption notwithstanding, little is known about the preconditions, opportunities and barriers of OS development in other domains, especially concerning the open design of physical products (Lerner & Tirole, 2002). My first two empirical studies aim to point out the recent upsurge of practical cases (Chapter 5 treating research question 1) and to derive first tentative findings on the mechanism of the open design model of new product development (Chapter 6 treating research question 2). In Chapter 5, I investigate a comprehensive data base of open design projects, with the intention of exploring the landscape of open source development in the world of atoms, analyzing project characteristics, structures, and success, and studying similarities and dissimilarities to open source software development. Cases have been identified according to the definitions of open source innovation and open design derived in Chapter 4 and carefully maintained during data collection. Along the open source innovation framework, I present a number of statistics describing common patterns among examples. A principal finding is that open design is already being implemented in a substantial variety of projects. Open source development of tangible goods is not a new, but a rapidly K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_7, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

80

Chapter 7. Intermediate conclusions and implications for proceeding

evolving field, and more and more physical products are being designed collaboratively via the Internet. Contributors from private and commercial backgrounds form communities with sizes varying from 1 to several hundred developers and tackle the development of products across all degrees of complexity and innovativeness. The considered projects stem from various industries and show diverse contextual backgrounds. Their current development stages range from the evolvement of first rough ideas to mature and successfully marketed products. The largest proportion of projects already has fully functional products permanently available on the market, but is still working on further development. Research propositions derived from the literature on open source software are tested in the context of open design using my data set. I find strong relationships between the stage of advancement of the development and the size of the developer community, the presence of commercial contributors, and the intensity of co-operation, respectively. My analysis in Chapter 6 sheds light on patterns and options in project setup of open design projects and highlights their heterogeneity. Comparisons to OSS as well as traditional NPD point to similarities as well as substantial differences. My results rest on six in-depth case studies and are confirmed by findings of similar patterns, which I observed during case screening and selection based on my findings from my first study. Nonetheless, further theoretical and empirical study is clearly warranted to validate my results. Open design is still very far from new product development practice for most companies today, and is likely to remain so for the foreseeable future. In fact, the idea of deriving profit from open and therefore easily imitable design seems counter-intuitive to many industry experts. Nevertheless, latest developments suggest that the translation of the OS model of product development to the physical world will be subject to increasing experimentation. “Linux succeeded, likewise Wikipedia – why shouldn’t it be possible to develop top-quality tangible products like an iPhone or an iPad purely based on free and open knowledge and market them successfully?” (Wolfgang Spraul, Openmoko) The interdependence of collaboration of communities of individual developers and profit-oriented corporate entities within (semi-)open design and production environment poses many questions. As previously highlighted, the meaning of openness appears to be of particular relevance in this regard. My findings suggest that strategies towards selective revealing abound in several open design projects.

Chapter 7. Intermediate conclusions and implications for proceeding

81

Project responsibles carefully decide which parts they publish and which parts they keep proprietary, frequently on a component by component basis. In order to enable a focal producer to capture some value from his development, a suitable level of IP ownership appears often to be required. Parts from third-party-components suppliers might need to remain closed due to agreements with the vendor. On the other hand external contributors require open specifications and other critical pieces of knowledge concerning all components where they actively participate in the development. Across my examined cases, community members typically ask for increased openness, but accept trade-offs if a company provides good reasons for disclosure of critical parts and the balance is perceived to be fair. My findings suggest that fully open solutions frequently are neither optimal nor feasible. At the same time they show that and how solutions in-between fully closed and fully open are already implemented successfully in practice. However, details on strategies towards openness remain yet as unclear in many cases as the reactions from the communities. As also Dahlander and Gann (2010) recommend in their recent paper, further research on advantages, disadvantages, and potential combinations of openness seems clearly warranted. Does openness indeed play an important role to developers or is it just a matter of course to ask for more and more openness? How does the degree of openness impact developer’s satisfaction and their contributions? Which aspects of openness are important? Can we observe differences between software and hardware in this regard? The following two empirical studies aim to address these questions on the meaning of openness in more detail.

7.2

Replicability as a third aspect of openness

As G. K. Lee and Cole (2003) point out, in the realm of open design, the tangibility of the product may affect the form and degree of openness. On the one hand, physical production may be conducted by a manufacturer in a closed environment, on the other hand one can hardly keep people entirely from copying physical products, as hardware is always open to a certain extent (cf. Section 3.4.3). The selection of released information determines possibilities for external contributors to actively participate in the development, but at the same time determines their ability to replicate components or even copy the entire prod-

82

Chapter 7. Intermediate conclusions and implications for proceeding

uct. My case study research delivers a first indication of how profit seeking sponsors of open design projects can carefully decide about the potential usage of released information, by imposing legal barriers and by selectively revealing only the appropriate knowledge. This shows how firms, who develop products drawing on external resources in a community, can potentially impose isolating mechanisms to allow for value capture from the commonly developed good. As pointed out in Table 6.2, for example, board layouts are only needed for someone who wants to replicate the product, while open specifications are crucial for everybody who wants to contribute to the development. This topic clearly calls for a closer investigation. In order to deeply analyze strategies towards selective revealing of both software and hardware components and their implications, I extend a framework proposed by West and O’Mahony (2008) to account for settings beyond software. While the original authors distinguish between transparency and accessibility (as discussed in Section 3.2.2), I add replicability as a third aspect of openness: • Transparency refers to the quantity and quality of information, which is freely revealed to developers. Information in that sense could for example be software source code or hardware schematics and design files. • Accessibility denotes the possibility for community members to actively participate in product development. This participation may happen through open discussions only or contributions could be directly taken up into official product releases. • Replicability denotes the availability of individual components and thus the possibility for the self-assembly of the product. Objects including closed components could be copied if those components are obtainable; conversely objects which are entirely open source might not easily be copied if some components are difficult to produce and not obtainable from external suppliers. West and O’Mahony (2008) assume that it might be easier for sponsoring firms to provide outsiders with visibility than with some authority over control of the project, but suppose that degrees of openness are correlated. My first two empirical studies point into the same direction, but without largescale empirical validation I cannot draw explicit conclusions on this topic. Concerning replicability my investigations indicate that this aspect of openness might be even more difficult to grant and sensitive to value-seeking sponsors than accessibility.

Chapter 7. Intermediate conclusions and implications for proceeding

7.3

83

Derivation of research hypotheses

After the identification of research gaps to address in my thesis (Section 3.5), I deductively derived five propositions from previous theory in Section 4.2 and investigated them in close detail in two qualitative studies. Mainly based on my empirical findings, but still relying on established theory – as far as there is some already available – I now want to inductively derive five sets of research hypotheses on aspects of openness plus two single hypotheses. In total I arrive at 17 research hypotheses. In contrast to pure software, physical products need to be produced prior to being marketed. As noted earlier, this production phase may be closed and left in the hands of a manufacturer reserving certain rights and appropriating (some portion of the) created value. Unless community members produce the good themselves, a clear strategy towards selective revealing may be required in order to create sufficient incentives for both suppliers or manufacturers and the developer community (cf. Chapter 6). In Chapter 5, I observe that it is common across all cases, which include software development to open at least parts of their software. By contrast, about three quarters publish schematics or similar information and only less than half of the relevant projects decided to release their case design. Therefore I propose that open design products, which include both hardware and software components select differing degrees of openness for tangible and non-tangible parts of their design. I suggest that across all three aspects of openness software components are more likely to be open source than hardware components. The following research hypotheses obtain: • H1-T: In open design software components are more transparent than hardware components, i.e. software source code is more frequently and more easily available than hardware documentation. • H1-A: Software is more accessible than hardware, i.e. the community can exert more influence on software development than on hardware development. • H1-R: Software components are more replicable than hardware components, i.e. software parts are more often available for self-assembly of the product than hardware components. As discussed in Section 3.2.3 prior research suggests that communities prefer openness to closeness. In his ‘Maker’s Bill of Rights’, Jalopy (2005) declared: “If you cant open it, you dont own it.”, asserting that an individual should

84

Chapter 7. Intermediate conclusions and implications for proceeding

be able to open, repair and modify the products that he buys. Many practitioners favoring open products agree. Still some ambiguity remains in this regard. On the one hand openness is a basic requirement for open source activities; closed or gated approaches have hence been found to “limit cumulative development and overall value creation” (Shah, 2006, p.1010). On the other hand openness can entail drawbacks, e.g. quality issues, lower ease of product use, less standardization, etc. (cf. Baldwin, Hienerth, & von Hippel, 2006). This ambivalence shall be investigated in my second set of hypotheses discussing the importance of openness and its aspects: • H2-T: Transparency is important to open design communities, i.e. participants value the amount and quality of available information. • H2-A: Accessibility is important to open design communities, i.e. developers aim to actively participate and influence the development. • H2-R: Replicability is important to open design communities, i.e. community members appreciate the possibility for self-assembly of the product. Taking my two sets of hypotheses together, I assume that software in general is more open than hardware in open design projects and that communities value openness. Looking at the vast number of software projects compared to the relatively small number of hardware projects (cf. Section 3.3), I further conjecture that openness of software components is more important to communities than openness of hardware components: • H3-T: Transparency of software components is more important to open design communities than transparency of hardware components. • H3-A: Accessibility of software components is more important to open design communities than accessibility of hardware components. • H3-R: Replicability of software components is more important to open design communities than replicability of hardware components. Postulating that openness is indeed important to developer communities, the question arises whether it actually and significantly affects participants’ behavior. On the basis of their case study on Openmoko and the Nokia Internet Tablet Maemo, von Krogh et al. (2009a) disagree, showing that openness does not have a direct impact on the motivation of contributors. According

Chapter 7. Intermediate conclusions and implications for proceeding

85

to their study, only “corporate creditability matters”, but “openness doesn’t matter”. In Chapter 5, I likewise observe that a high degree of openness is negatively correlated with the community size and the advancement of the development across my examined projects. However, my findings in Chapter 6 and several additional expert interviews point to a different direction: “Every time we chose openness over internal control, we have been rewarded.” (Sean Moss-Pultz, Openmoko, CEO) “[In the past] there have been a couple of partly open microcontroller projects. But today, Arduino is everything, because they decided to [...] share everything.” (Jimmie Rodgers, Open design expert) “I think the possibility to contribute to software parts plays the major role. Since a majority of people join projects usually after the hardware has been finalized, they won’t have ever thought they could have influenced the hardware” (Neuros, Developer) To shed light onto this contradiction, I propose a fourth and fifth set of hypotheses, relating the degree of openness in a project to the satisfaction of developers in the corresponding community: • H4-T: The degree of transparency has a positive impact on developer satisfaction. • H4-A: The degree of accessibility has a positive impact on developer satisfaction. • H4-R: The degree of replicability has a positive impact on developer satisfaction. • H5-T: The degree of transparency of software components has a stronger positive effect on developer satisfaction than the degree of transparency of hardware components. • H5-A: The degree of accessibility of software components has a stronger positive effect on developer satisfaction than the degree of accessibility of hardware components. • H5-R: The degree of replicability of software components has a stronger positive effect on developer satisfaction than the degree of replicability of hardware components.

86

Chapter 7. Intermediate conclusions and implications for proceeding

From this fifth block of research hypotheses, the question emerges, why openness of software should play a more important role than openness of hardware. One possible explanation arises from the observation that people are more used to open source software than open design, or, as pointed out in the above statement from a Neuros community member, they might not even think about open source approaches for tangible components. On the one hand, they might expect software to be more open than hardware, on the other hand these expectations might influence their general attitude towards openness. In the context of information systems, Bhattacherjee (2001) find that user satisfaction is influenced by the confirmation of expectation from prior experience. This relationship may also be applicable within the OS context. Hence, my sixth research hypothesis is formulated to investigate the impact of expectations towards openness: • H6: The individual expectation towards openness and its aspects influences the relationship between openness and developer satisfaction, i.e. if an individual’s expectation increases, the (supposedly positive) relationship between openness and developer satisfaction will be strengthened. According to expectation-confirmation theory customers form a satisfaction, captured as positive (satisfied), indifferent, or negative (dissatisfied) feeling. Those users who feel satisfied continue to use (Bhattacherjee, 2001). The relationship between user satisfaction and information system usage has received wide conceptual and empirical support in the literature (e.g. Bolton & Lemon, 1999). In the context of open source, S.-Y. T. Lee et al. (2009) likewise observe a positive effect of user satisfaction on OSS use. To investigate this relationship in the field of open design, I propose to analyze the impact of developer satisfaction on their activity within a project: • H7: The satisfaction of a developer with his project positively influences the extent of his contribution.

Part IV On openness in open design

Chapter 8 Survey approach To investigate the meaning and importance of openness from a community’s perspective, I need to approach open design projects. I hence decided to conduct a web-based questionnaire survey in 20 communities associated with projects developing physical products following an open source development methodology. The focus of this research is to explore the relevance of openness and its aspects and to draw conclusions on developer satisfaction. Particularly the difference between software and hardware components shall be investigated in close detail.

8.1

Questionnaire development

Building on my consolidated findings from my first two empirical studies, I compiled a questionnaire in order to survey open design communities. The full questionnaire is printed in Appendix C. The survey consisted of six steps, five containing content questions plus one introductory step where the open design community of the respective respondent is indicated. One respondent can only be attached to one project. A person filling out the survey twice for two different projects is treated equally to two different respondents. In the second step, i.e. after the introductory step, the interviewee has been asked about his relation to the community and his involvement in the project. The corresponding items have been built based on comparable studies from N. J. Allen and Meyer (1990), Mowday, Steers, and Porter (1979), Westbrook and Oliver (1981), and von Krogh et al. (2009a). K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_8, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

90

Chapter 8. Survey approach

Steps three to six include questions concerning the openness of the project, examining one aspect of openness per step respectively. Transparency has been treated in the third section, which focused on the amount and quality of available information. This construct is founded on the work done by West and O’Mahony (2008), items have been refined based on my previous research work. Accessibility has been addressed in the fourth step trough questions on the possibilities to participate and actively influence the development. Similar to transparency, this construct is built upon findings from West and O’Mahony (2008) and my previous empirical studies. Replicability has been investigated in the fifth part, which asked about possibilities to self-produce the product. Due to the lack of prior empirical research on the topic of replicability, items have been developed inductively, based on findings from my own previous work. The last two questions of steps three, four, and five evaluate importance ratings and expectations concerning the respective aspect of openness in each case. Participants are asked for their assessments of the importance of openness and for conformity of the actual degree of openness to the respondent’s individual expectation. As, e.g., recommended by Manski (2004), self-reported expectations are measured via subjective probabilities. This approach ensures responses to be interpersonally comparable and enables conclusions about the correspondence between subjective expectations and objective realities. The sixth step covered general demographic questions on age, gender and the respondent’s highest educational degree. The open source software ‘Limesurvey’ was used to execute the survey webbased. The questionnaire included both multiple-choice and free-text questions and items were to be completed either by selecting answer options or by entering free text. All items relating to the degree of openness were to be answered on 5-point Likert scales from “strongly disagree” (1) to “strongly agree” (5). The option “No answer” was available for every question. A pre-test with 37 respondents delivering 22 full answers was conducted in August 2009 to ensure the validity of the items and to see how respondents react to the questionnaire (e.g., Garson, 2002). Since overlong internet questionnaires are often not completed (e.g. Batinic & Bosnjak, 2000, p.308), I planned a completion time of about 5-7 minutes.

Chapter 8. Survey approach

8.2

91

Selection of communities

The selection of communities to survey was a critical task. Possibly due to the novelty of the phenomenon, there is no complete compilation of open design projects. For my case selection I therefore used my directory of ‘Open Innovation Projects’, as presented in Chapter 5. I have carefully chosen communities based on three criteria: I have selected projects (i) with more than 10 active participants developing (ii) objects which include both software and hardware components. Additionally, (iii) the development must have reached a stage in which first prototypes are available. This approach ensures a sufficiently large number of potential respondents and increases the availability of secondary information about the projects. Criterion (ii) is essential to allow for comparison of software and hardware components. The resulting list of the surveyed communities is shown in Table 8.1. Openmoko OpenEEG Bug Labs Gumstix Mikrokopter

Always Innovating Touch Book Fab@home Gp2x One laptop per child Chumby RepRap Neuros OSD & Link OpenServo Balloon Beagle Board Open WRT SquidBee BitsFromBytes MakerBot Arduino Table 8.1: List of surveyed communities

8.3

Data collection

Data collection started on 2 September and lasted till 31 October 2009. The survey was announced on project mailing-lists and posted in forums and blogs. Moreover, a web-page was installed on which the goals of my research were explained. In order to increase the acceptability of the study, I strove to adhere to open source values by announcing that aggregated results of the study would be published on the Internet directly after completion. Intermediary results including data collected between 2 September and 5 October have been published on 13 October. During data collection, I counted 812 unique visitors on the entry page, whereof 544 started the survey. 309 answers are sufficiently complete to be considered for further analysis, i.e. respondents finished at least two out of five sections from the survey. This results in a response rate of 38% when

92

Chapter 8. Survey approach

taking the number of visitors as target population (cf. Batinic & Bosnjak, 2000, p. 296). Compared to similar studies (e.g. Roberts et al., 2006; Mayrhofer, 2006; von Krogh et al., 2009b) this share appears satisfying. However, the number of answers per question varies between 216 and 308. The number of observations (n) therefore fluctuates. This is particularly the case for statistical analyses requiring pairs of observations to be complete.

8.4

The sample

309 participants are included in the analysis. Thereof the sample contains 3% females and 97% males. Respondent’s mean age is 32 years, ranging from 14 to 70 years. Their educational backgrounds show 6% who reached PhD or doctorate degree, 32% who have a master’s or diploma degree, 47% with a bachelor degree or some college, and 15% who only finished high school or less. A potential self-selection bias has been investigated by comparing the demographics of the respondents of my survey to similar studies (e.g., von Krogh et al., 2009b). This did not yield significant differences. Concerning a potential non-response bias, evidence from social studies suggests that the length of time taken to respond to a survey is a source of variation in response. I therefore compare early, average, and late responses in my data to test for robustness of answers. For some variables mean responses tend to increase with increasing time to respond. However, at large no significant differences could be determined. Figure 8.1 (left graph) visualizes the number of self-reported working hours per week. 303 of 309 respondents reported the required number. One surveyparticipant, who reported 1520 hours, had to be excluded from the analysis. The remaining 302 data points appear plausible with a mean of 8.4 hours per week and a standard deviation of 10.8. Comparable studies report similar but slightly lower numbers (von Krogh et al., 2009b). On average the participants are involved in their projects for about 16 months (range: less than 1 month to 7 years). The right histogram in Figure 8.1 shows the distribution of reported month of participation for 304 respondents who indicated the correspondent data. Survey respondents’ positions in the project are 3% project leaders, 9% core team members, 54% developers and 34% users. As before, data has been analyzed using the statistical software R (R Development Core Team, 2005). Descriptive statistics about questionnaire items

Chapter 8. Survey approach

93

Histogram of duration of participation

100 80

Frequency

60

60 0

0

20

20

40

40

Frequency

80

120

100

140

Histogram of reported hours

0

10

20

30

40

50

60

70

Reported working hours

0

20

40

60

80

Reported months

Figure 8.1: Histograms of self-reported weekly contributed working hours and duration of activity

are presented by their means (μ) and frequency tables or variances (σ 2 ) and standard deviations (σ) respectively. As can be seen from the list of variables in Appendix C.2, inspections for accuracy of input do not cause any further concerns. Means and distributions of values appear plausible for all variables, no particular outliers can be determined.

8.5

Data preparation

In Chapter 9 hypotheses tests shall be conducted to derive conclusions about the hypotheses blocks H1, H2, and H3. The remaining blocks H4, H5, H6, and H7 shall be treated in Chapter 10 by looking at different models of underlying relationships in the data. In this section, I will prepare the data as necessary for this purpose and validate required modeling assumptions.

Building constructs from questionnaire items on openness and satisfaction Before being able to conduct tests on research hypotheses, constructs need to be derived properly from the questionnaire items. Per aspect of openness I intend to build one construct for software and hardware respectively. In addition I expect to be able to build a construct on developer satisfaction and an overall construct on openness.

94

Chapter 8. Survey approach

Software

Q3.2_SW

Q3.1_SW Q2.3_SW

Q2.1_SW

Q2.2_SW

Q1.3_SW

Q1.2_SW Q4.1

Q4.0

Q1.1b_SW

Q1.1a_SW

Q4.3 Q1.4_SW

0.2 Q4.2

0.3

Spearman ρ2

0.1 Q2.3_HW

0.4

Q1.3_HW

Q1.2_HW

Q1.1a_HW Q3.2_HW

Q3.1_HW Q2.1_HW Q2.2_HW

Q4.1

Q4.0

Q1.1b_HW

Q1.4_HW

Q4.2

0.3 0.5

0.4

Spearman ρ2

0.2

Q4.3

0.1

0.0

0.0

Hardware

Figure 8.2: Hierarchical variable clustering of survey results for hardware and software

Figure 8.2 shows hierarchical variable clusterings using Spearman ρ2 as a similarity measure for all pairs of variables to visualize structures in the data. The graph reveals almost exactly the expected clusters: For hardware (left plot), the variables Q4.0, Q4.1, and Q4.2 on satisfaction (S) form one cluster, strongly disconnected from the remaining variables. Q1.1a, Q1.1b, Q1.2, and Q1.3 form a cluster on transparency (T), Q2.1, Q2.2, and Q2.3 form a cluster on accessibility (A), and Q3.1 and Q3.2 form a cluster on replicability (R). Taking those three clusters together, I can build a construct on openness (O). Only the variables Q4.3 and Q1.4, which have been asked reversely, appear separated from their intended groups. For software (right plot), the graph shows the same cluster for satisfaction grouping variables Q4.0, Q4.1, and Q4.2, again variable Q4.3 is less connected. The cluster on transparency is less clear as Q1.1a and Q1.1b are disconnected, instead Q1.4 appears together with Q1.2, and Q1.3. The variables Q2.1, Q2.2, and Q2.3 form a clear cluster on accessibility, as well as Q3.1 and Q3.2 on replicability. This analysis gives a strong indication that the data sufficiently represents its intended structure. I further looked at correlation matrices, which confirmed the desired topology in the data set. In addition maximum likelihood factor analyses have been conducted, on software and hardware respectively, to assess whether all questionnaire items pertain to the intended latent construct. 4 factors have been revealed as expected. Following common practice (e.g. Hoegl & Gemuenden, 2001; Klink & Smith,

Chapter 8. Survey approach

95

2001), I finally build the constructs by calculating arithmetic means of the corresponding questionnaire items1 :

S= T.SW = A.SW = R.SW = T.HW = A.HW = R.HW = O.SW = O.HW = T = A= R= O=

Q4.0 + Q4.1 + Q4.2 + Q4.3 3 Q1.1a.SW + Q1.1b.SW + Q1.2.SW + Q1.3.SW + Q1.4.SW 5 Q2.1.SW + Q2.2.SW + Q2.3.SW 3 Q3.1.SW + Q3.2.SW 2 Q1.1a.HW + Q1.1b.HW + Q1.2.HW + Q1.3.HW + Q1.4.HW 5 Q2.1.HW + Q2.2.HW + Q2.3.HW 3 Q3.1.HW + Q3.2.HW 2 T.SW + A.SW + R.SW 3 T.HW + A.HW + R.HW 3 T.SW + T.HW 2 A.SW + A.HW 2 R.SW + R.HW 2 O.SW + O.HW 2

Figure 8.3 visualizes the calculated constructs satisfaction, openness, transparency, accessibility, and replicability without distinguishing between software and hardware. The plots down the diagonal show univariate density estimates for the 5 constructs. One can observe that all variables show distributions, which are close to normal distributions, but are slightly right-skewed. The remaining graphs show scatter plots between the five constructs including robust regression lines. Relationships appear to be close to linear relations in most cases. 1 The reverse items Q4.3, Q1.4 SW, and Q1.4 HW have been transformed by multiplying with (−1) and adding +6 to adjust them with all un-reverse items

96

Chapter 8. Survey approach

3

4

5

2.0

3.0

4.0

5.0 5

2

2

3

4

S

5

| | | || | | | |||| | || | |||| | |||| |

2

3

4

O

5

| | ||| |||||||||||||||||||||||||||||| ||||||||||| |||||||||||| ||||||||| ||||||| |||||||||||||||||

1

2

3

4

T

5.0

| |||| ||| ||||||||||||| |||||||||||||||||||||||||||||||||| | |||| |

2.0

3.0

4.0

A

5

| | | | | | | | | | | ||||||||| |||||||||||||| |

||||||||||||||||| 2

3

4

5

1

2

3

4

5

1

2

3

4

1

2

3

4

R

5

Figure 8.3: Scatter plot matrix of the five main constructs with univariate density estimates down the diagonal

Table 8.2 shows all correlations between pairs of constructs. The correlation between openness and satisfaction is with 0.4 fairly high, correlations between constructs representing aspects of openness and satisfaction are between 0.2 and 0.4. Similar correlations between aspects of openness among each other lie between 0.3 and 0.4 for software and between 0.3 and 0.5 for hardware.

Missing data imputation To arrive at conclusions about my hypotheses, I am interested in making inferences about the entire target population, rather than the portion of the target population that would provide responses on all relevant variables in the analysis. Therefore I decided to impute missing values by conditional mean imputation. The dependent variables of the model I intent to develop in Chapter 10, will be the constructs O, T, A, and R, directly, and for software and hardware

Chapter 8. Survey approach

S O O.SW O.HW T A R T.SW A.SW R.SW T.HW A.HW R.HW

S 1.0 0.4 0.4 0.2 0.3 0.3 0.3 0.3 0.3 0.3 0.2 0.2 0.2

O 0.4 1.0 0.9 0.9 0.8 0.7 0.8 0.7 0.7 0.7 0.7 0.7 0.7

O.SW 0.4 0.9 1.0 0.6 0.7 0.7 0.7 0.7 0.7 0.8 0.5 0.5 0.4

O.HW 0.2 0.9 0.6 1.0 0.7 0.6 0.7 0.5 0.4 0.4 0.8 0.7 0.8

T 0.3 0.8 0.7 0.7 1.0 0.4 0.4 0.9 0.3 0.4 0.9 0.4 0.4

97 A 0.3 0.7 0.7 0.6 0.4 1.0 0.4 0.3 0.9 0.4 0.4 0.9 0.3

R 0.3 0.8 0.7 0.7 0.4 0.4 1.0 0.3 0.3 0.8 0.4 0.3 0.9

T.SW 0.3 0.7 0.7 0.5 0.9 0.3 0.3 1.0 0.3 0.3 0.5 0.3 0.3

A.SW 0.3 0.7 0.7 0.4 0.3 0.9 0.3 0.3 1.0 0.4 0.3 0.7 0.2

R.SW 0.3 0.7 0.8 0.4 0.4 0.4 0.8 0.3 0.4 1.0 0.3 0.3 0.5

T.HW 0.2 0.7 0.5 0.8 0.9 0.4 0.4 0.5 0.3 0.3 1.0 0.5 0.5

A.HW 0.2 0.7 0.5 0.7 0.4 0.9 0.3 0.3 0.7 0.3 0.5 1.0 0.3

R.HW 0.2 0.7 0.4 0.8 0.4 0.3 0.9 0.3 0.2 0.5 0.5 0.3 1.0

Table 8.2: Correlations between pairs of constructs respectively. They relate to different aspects of openness of the products concerning the entire community. One can assume that perceptions of openness are similar among developers of the same community. Therefore I impute means with adjustment cells where project communities represent weighting classes and impute the respondent mean for nonrespondents in the same class (cf. Little & Rubin, 2002). The amount of missing values varies between 0% for O and T, and 15% for R.HW. Table 8.3 summarizes main characteristics of the constructs and the number of missing values as well as implications from the data imputation. Fortunately there is no data missing from my independent variable satisfaction (S). Further, I refrain from imputing missing data on variables measuring the importance of openness to the respondents as well as their expectations towards openness, because these items represent personal opinions and one cannot necessarily assume similar opinions among developers of the same community. The number of available observations will therefor be indicated in all coming analyses if it differs from 309. The issue of nonresponse bias has been treated carefully, by comparing patterns among respondents and nonrespondents, which did not show significant differences. Estimation of imputation uncertainty has been deemed less important by Little and Rubin (2002), however I compared variances of original and imputed data on a per question basis to ensure that my imputation technique does not bias my data set. F-tests on the ratio of the two variances did not reveal significant differences.

Linearity and homoscedasticity Looking at the scatter plots in Figure 8.3 delivers a first indication that linear regression models might be the best choice to model this data set. Although

98

Chapter 8. Survey approach

S O O.SW O.HW T A R T.SW A.SW R.SW T.HW A.HW R.HW

Mean 4.0 3.7 3.7 3.6 3.2 4.2 3.8 2.7 4.4 4.2 3.7 4.0 3.4

Before imputation Variance NAs 0.43 0 0.41 0 0.46 2 (0.6%) 0.61 6 (1.9%) 0.55 0 0.53 15 (4.9%) 0.82 23 (7.4%) 0.71 3 (1.0%) 0.48 17 (5.5%) 0.80 27 (8.7%) 0.65 12 (3.9%) 0.80 38 (12.3%) 1.41 48 (15.5%)

After imputation Mean Variance Skewness −0.9 −0.8 3.7 0.46 −0.9 3.6 0.62 −0.7 −0.6 4.2 0.51 −1.0 3.8 0.77 −0.6 2.7 0.70 −0.1 4.4 0.46 −1.4 4.2 0.73 −1.1 3.6 0.64 −0.9 3.9 0.86 −1.0 3.3 1.25 −0.2

Table 8.3: Main characteristics of constructs including implications from missing data imputation the relations are not strictly linear in every case, they appear closer to linear relations than to any other possible relationship. The shape of the plots in Figure 8.3 further indicates that heteroscedasticity will not be a major issue among the variables of this data set. Therefore I feel confident to assume homoscedasticity, which simplifies the following analyses.

Normal distribution of constructs When building linear regression models, one basic requirement is that the variables included should follow a normal distribution. Therefore the distribution of each construct needs to be investigated prior to proceeding with linear modeling approaches. From the plots along the diagonal in Figure 8.3 one can observe that the estimated distributions of each construct are close to normal distributions, but none of the constructs is exactly normally distributed, because they all show a bias to the right. The very last column of Table 8.3 includes the skewness of each variable. There are several different definitions of skewness.

Chapter 8. Survey approach

99

In this document, I use the most common measure of skewness, which is  (xi − x¯)3 Skewness = n(σ(x)3 ) A variable shows a skewness of 0 if it is perfectly normally distributed. With every value for skewness between -1 and 1 the distribution can be considered to be sufficiently close to a normal distribution to allow for building linear regression models (e.g. Wright & London, 2009). As I have to confess that not all constructs meet this requirement, I decided to approach this issue by transforming S, O, T, A, and R, and for software and hardware respectively, using Box-Cox transformations (Box & Cox, 1964). The transformations worked well and the resulting models confirmed that all requirements on normal distributions are met. However interpreting models from transformed variables is way more complicated than from untransformed variables. Therefore, and because the results were highly similar, I finally decided to use models built from untransformed variables. For the reader’s reference, transformations to normality and the resulting models are shown in Appendix D.3.

Multicollinearity Multicollinearity is a high degree of correlation among two or more explanatory variables in a multiple regression model. A researcher faces perfect multicollinearity if the correlation between two independent variables in his data set is equal to 1 or -1. In this case the matrix of independent variables would not be fully ranked and ordinary least squares regression becomes impossible. According to Tabachnick and Fidell (2006) multicollinearity will not be a severe issue as long as two-way correlation coefficients remain under 0.9. As the largest correlation coefficient between two possible explanatory variables in my data is 0.7 for A.SW and A.HW (cf. Table 8.2), I do not have reservations that my matrix of independent variables might becoming close to singularity. However the researcher has to be aware that the different aspects of openness transparency, accessibility, and replicability as well as the degrees of openness of software versus hardware are strongly correlated. A multiple regression model with correlated predictors can indicate how well the entire bundle predicts the outcome variable, but it may not give valid results about individual predictors, or about which predictors are redundant with others.

100

Chapter 8. Survey approach

Transformation of data on contributed working hours Figure 8.1 visualizes the number of self-reported working hours per week from 302 survey respondents. The comparison of indicated hours with respondents’ positions in the projects reveals a strong interrelation, i.e. project leaders and core team members report higher numbers than community members, which again report higher activity than end user. For their study, von Krogh et al. (2009a) verified the validity of this measure by comparing self-reported hours of bug reporting from two surveyed communities to the actual measured number of filed bugs and found a sufficient correlation. On this account I feel confident to use this variable without additional validation. The skewness of self-reporting working hours from my survey is with 2.7 too high to treat the variable as if it would follow a normal distribution. Therefore the following Box-Cox transformation, reducing skewness to 0.0, seems required prior to include this measure in linear modeling approaches Transformed hours = Reported hours0.275 The resulting transformed variable is shown in Figure 8.4.

60 0

20

40

Frequency

80

100

Histogram of working hours (transformed)

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

Transformed working hours

Figure 8.4: Histogram of transformed weekly contributed working hours

Chapter 9 Study 3: The meaning of openness is not trivial In the following chapter one- and two-sample t-tests are performed to support or reject my research hypotheses blocks H1, H2, and H3 based on my survey results. I aim to analyze respondent’s attitude towards the importance of openness and its aspects and differences in these regards between software and hardware. In addition general perceptions of different degrees of openness shall be investigated. All conducted tests are one-sided. I am aware that t-tests require normally distributed, independent samples, a requirement which is not fully met by my data set. Nevertheless and because most distributions are close to normal distributions, it can be assumed that t-tests provide reasonable results due to the large sample size. Welch approximation to the degrees of freedom is used to treat the variances as being unequal. To support my findings I have additionally conducted one- and two-sample Wilcoxon tests (the latter is also known as ‘Mann-Whitney’ test) to prove my results by non-parametric statistical methods. In every case the p-values from non-parametric tests are of the same magnitude as those from parametric tests. In order to assess the stability of the findings I repeat all tests in different sub-samples. The respondents of one community, respectively, are excluded to check whether the results depend on the answers from single projects. All stability tests confirm my findings showing p-values below 1%; only the pvalue for H3-T rose to about 7% when excluding the community “Openmoko” from the sample. Exemplary results are shown in Appendix C.3 (Table C.1); therein, I successively exclude the three projects with the greatest number K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_9, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

102

Chapter 9. Study 3

of respondents from my sample and show that my findings are not driven by a specific community.

9.1

Software is more open than hardware

In my questionnaire 9 questions have been included to analyze the degree of openness of software and hardware components respectively. The participants have been asked to answer each question separately for software and hardware, therefore every question has been included twice. 4 questions measure transparency, 3 evaluate accessibility, and 2 relate to the replicability of the product or the components of the product. In Chapter 8 constructs have been derived and calculated representing the degree of openness and of its aspects (cf. construct building mechanisms in Section 8.5). For my hypotheses H1-T, H1-A, and H1-R, I am interested in differences between software and hardware components concerning the constructs transparency, accessibility, and replicability. Table 9.1 shows means and variances for these 3 aspects and for openness in general. Following my first block of research hypotheses, I expect the means for openness of software to be higher than for hardware.

Question T A R O

Software Hardware μ σ2 μ σ2 3.8 0.5 3.6 0.6 4.4 0.5 3.9 0.9 4.2 0.7 3.3 1.2 4.2 0.4 3.6 0.6

Difference p < 0.001 p < 0.001 p < 0.001 p < 0.001

Table 9.1: Degrees of openness for software and hardware components

T-tests show significant differences at 0.1%-significance levels across all constructs. I hence conclude that software components in open design products are indeed more transparent, more accessible, more replicable, and in general more open than hardware components, supporting all three hypotheses of the first block.

Chapter 9. Study 3

103

SD D

N

A

SA

0

50

100

150 0

50

100

150 100 50 0

Frequency

Replicability 150

Accessibility

Transparency

SD D

N

A

SA

SD D

N

A

SA

Figure 9.1: Histograms showing ratings of importance of openness

9.2

Openness is important to open design communities

To analyze the importance of openness three questions have been included in my survey, i.e. one per construct, again measuring this variable for software and hardware respectively. As I do not distinguish between software and hardware components in H2-T, H2-A, and H2-R, the respective results are merged through using their means for the analysis of this set of hypotheses. Similar the general importance of openness corresponds to the pooled importance of its three aspects. Importance of Transparency Accessibility Replicability Openness

μ σ 2 T-test: μ > 3 T-test: μ > 4 4.5 0.4 p < 0.001 p < 0.001 4.5 0.4 p < 0.001 p < 0.001 3.9 1.0 p < 0.001 n.s. 4.3 0.3 p < 0.001 p < 0.001

n 298 292 289 308

Table 9.2: Importance of openness to participants The histograms in Figure 9.1 show a strongly right-skewed distribution of answers. For every question a clear majority of participants states that openness is indeed important to them. To evaluate my hypotheses statistically, I calculate t-tests, testing for item means to be significantly higher than “Neutral” (3). As summarized in Table 9.2 I find all three hypotheses of the second set to be strongly supported at significance levels below 0.1%. To better understand the respondents’ view of the importance of openness

104

Chapter 9. Study 3

I repeated this procedure testing for item means to be significantly higher than “Agree” (4). For the constructs transparency and accessibility I still observe significant results, only the construct replicability does not show a mean significantly higher than 4. Therefore I conclude that the availability of information and the opportunity to actively participate is indeed very important to open design communities. The possibility for self-assembly is also deemed important. Openness in general is likewise perceived to be very important. One can further observe that levels of perceived importance of openness differ among constructs. Both transparency and accessibility are significantly more important than replicability at significance levels below 0.1%. Between transparency and accessibility no significant difference can be determined.

9.3

Openness of software components is more important than openness of hardware components

The third set of research hypotheses - H3-T, H3-A, and H3-R - is analyzed by handling the questionnaire items relating to the importance of openness separately for software and hardware. As summarized in Table 9.3 t-tests indicate significantly higher means for software compared to hardware at significance levels below 1%. Regarding transparency, the difference between software and hardware is small (∼ 0.12) but still significant, because sample size is large and variance is small in those variables. Software Importance of μ σ2 Transparency 4.5 0.4 Accessibility 4.6 0.4 Replicability 4.2 1.0 Openness 4.4 0.3

Hardware μ σ2 4.4 0.6 4.4 0.5 3.5 1.6 4.1 0.6

Difference n p < 0.01 273 p < 0.001 266 p < 0.001 267 p < 0.001 294

Table 9.3: Differences in importance of openness between software and hardware For a graphical presentation of the shift in answers between software and hardware, Figure 9.2 shows 100%-bar charts of the importance ratings of

Chapter 9. Study 3

105

100

Importance of openness: Software vs. Hardware

0

20

40

Percentage

60

80

SD D N A SA

T: SW T: HW

A: SW A: HW

R: SW R: HW

Figure 9.2: The importance of openness for software and hardware

respondents. Despite the sometimes small differences in means, the graph clearly shows how openness of software is systematically rated more important than openness of hardware. Accordingly my findings support all three hypotheses of the third block and I hence conclude that transparency, accessibility, and replicability of software components are indeed more important to community members than the same aspects of openness of hardware components. Again this result is also confirmed by the overlying construct, showing that openness of software is significantly more important than openness of hardware.

9.4

Highly active developers value openness more than less active developers

My analyses in Section 9.2 and 9.3 disclose that contributors consider openness to be very important across open design projects. However, the assessment of importance of openness is not trivial. Openness of software is perceived to be more important than openness of hardware. Transparency

106

Chapter 9. Study 3

and accessibility are deemed more important than replicability. The question arises whether different people also value openness differently following specific patterns. To address this topic, I group my survey respondents into three, as far as possible equal-sized groups, according to their activity level: lowly-active participants working less than two hours per week (101 respondents), mediumactive contributors working more than two hours but less than eight hours per week (105 respondents), and highly-active developers working more than eight hours per week (103 respondents). Then, assessments of openness are calculated based on the same items referred to in Section 9.2. Construct Transparency Accessibility Replicability Openness

μ 4.40 4.40 3.90 4.20

≤ 2h σ2 0.5 0.5 1.1 0.4

n 96 92 92 103

μ 4.44 4.58 3.95 4.33

≤ 8h σ2 0.4 0.4 1.0 0.3

n 102 102 100 105

μ 4.57 4.54 3.87 4.34

> 8h σ2 0.3 0.3 0.9 0.2

n 100 98 97 102

Table 9.4: Perceived importance of openness across activity levels Table 9.4 summarizes indicated importance ratings across activity levels. Concerning transparency, accessibility, as well as openness in general, the analysis indicates that more active participants declare higher importance ratings than less active respondents. The p-values in Table 9.5 confirm this observation at least partly. At significance levels between 5 and 10% one can observe significant differences between answers from lowly- and highly-active developers regarding transparency, between lowly- and medium-active participants concerning accessibility, and again between answer from lowly- and highly-active respondents regarding openness in general. Only for replicability the ratings appear approximately equal across the three groups. Construct Transparency Accessibility Replicability Openness

≤ 2h vs. ≤ 8h n.s. p ∼ 0.052 n.s. n.s.

≤ 8h vs. > 8h ≤ 2h vs. > 8h n.s. p ∼ 0.059 n.s. n.s. n.s. n.s. n.s. p ∼ 0.078

Table 9.5: P-values of differences across developers activity levels concerning importance of openness

Chapter 9. Study 3

9.5

107

The duration of participation does not influence perceived importance

The last analysis reveals that survey respondents declaring to be highly active in their project tend to rank the importance of openness higher than less active respondents. To further disclose patterns in the evaluation of importance of openness, I conduct a similar analysis based on durations of participation in open design projects. Survey respondents are now grouped according to their durations of membership: relatively new participants being involved for seven months or less (99 respondents), established developers being involved for more than seven and up to 15 months (105 respondents), and long-term contributors being involved for more than 15 months (100 respondents). Again, assessments of openness are calculated based on the same items referred to in Section 9.2.

Construct Transparency Accessibility Replicability Openness

≤7 μ 4.46 4.52 3.95 4.31

months σ2 n 0.5 97 0.4 95 1.0 95 0.4 99

≤ 15 months μ σ2 n 4.53 0.3 100 4.59 0.3 98 3.85 0.9 99 4.32 0.3 104

> 15 months μ σ2 n 4.45 0.4 196 4.41 0.4 94 3.92 1.0 91 4.24 0.2 100

Table 9.6: Perceived importance of openness across duration levels Table 9.6 summarizes indicated importance ratings across durations of participation. In contrast to the previous analysis (Section 9.4), no significant or at least identifiable differences could be determined between the three groups. Hence I conclude that a respondent’s length of membership in a project does not influence his attitude towards the importance of openness. This observation points to the presumption that the duration of a person’s activity in open source development does not impact the perceived importance of openness. However purely based on this study, one cannot entirely arrive at secure conclusions concerning the general context.

Chapter 10 Study 4: How openness impacts developer’s satisfaction and their contribution My third empirical study strikingly reveals that openness is important to developer communities and that this is not just a matter of course. Openness of software components is more important than openness of hardware components. Replicability is perceived less important than accessibility and transparency. Highly active developers indicate higher importance ratings than less active developers, while the duration of participation does not influence the indicated importance. In my last empirical study of this thesis, I aim to develop different statistical models in order to systematically investigate the impact of the degree of openness, of its aspects, and of individual expectations towards it on developer satisfaction. Based on statistical models I attempt to draw conclusions on my remaining sets of research hypothesis H4, H5, H6, and H7. In addition effects on contributed working hours of respondents to their projects shall be investigated to develop an understanding of the broader picture of the examined variables and their effects.

10.1

Ordinary linear regression models on satisfaction

To explore structures in the underlying data, I start with the simplest ordinary linear regression model with one response or dependent variable, satisK. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_10, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

110

Chapter 10. Study 4

faction (S), and one prediction or independent variable, openness (O): E(S|O) = β0 + β1 O or S = β0 + β1 O + 

(10.1)

where β0 and β1 denote unknown regression parameters, and  denotes the residuals. A general linear regression model obtained via QR-decomposition using the R-function lm returns: Residuals: Min 1Q -2.66881 -0.35468

Median 0.05025

3Q 0.42419

Max 1.15152

Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept) 2.56511 0.22621 11.340 < 2e-16 *** O 0.37199 0.05738 6.483 3.58e-10 *** Residual standard error: 0.614 on 307 degrees of freedom Multiple R-squared: 0.1204, Adjusted R-squared: 0.1176 F-statistic: 42.03 on 1 and 307 DF, p-value: 3.584e-10

Satisfaction vs. Openness Normal Q−Q

0 −1 −2

Standardized residuals

−1

Residuals

3

−3

−2

2

O

0

4

1

1

2

5

Residuals vs Fitted

162

−4

93 232

162 93 232

−3

1 1

2

3 S

4

5

3.2

3.4

3.6

3.8

4.0

4.2

4.4

−3

−2

Fitted values lm(S ~ O)

−1

0

1

2

3

Theoretical Quantiles lm(S ~ O)

Figure 10.1: Diagnostic plots of an ordinary linear regression model (Model 10.1)

The estimates for the parameters have been calculated as βˆ0 = 2.57∗∗∗ ,

βˆ1 = 0.37∗∗∗

The model reveals a significant positive impact from openness on satisfaction (p-value < 0.1%). The R2 of 11.8% points to an existing degree of explanation, but it also makes obvious that other factors beyond openness impact satisfaction.

Chapter 10. Study 4

111

To have confidence that the estimates are efficient, certain assumptions must be validated: (1) the residuals should have no systematic trend in central ˆ (2) the residuals tendency against any predictor or against the fitted values S; ˆ should have the same dispersion for all levels of S and of T, A, and R; and (3) the residuals should have a normal distribution (e.g. Harrell, 2001). Figure 10.1 shows a plot of satisfaction vs. openness including the linear regression line (left), a plot of the residuals vs. the fitted values (middle), and a check for normal distribution of residuals using a quantile-quantile plot (right). The graphical representation indicates, that a linear model might indeed be the best choice. The residuals show no systematic trends in central tendency against the fitted values and appear to have to same dispersion for all levels. Plots against T, A, and R are not shown, but have been checked as well and deliver similar results. The only observed issue is that the check for normal distribution of residuals does not result in a straight line. As discussed in Chapter 8 (Section 8.5) this issue was to be expected and a transformation of the variables might help to handle it. More ordinary linear regression models are summarized in Appendix D.1, models from transformed variables are printed in Appendix D.3.

10.2

Multilevel models on developer satisfaction

Multilevel or hierarchical models, also commonly known as mixed-effects models, formalize the sensible idea that an individual’s pattern of responses is likely to depend on many characteristics, including some that are unobserved (e.g. Everitt & Hothorn, 2006; Gelman & Hill, 2007). In my particular example, respondents stem from different communities, causing non-independence in the data due to the data being clustered. Multilevel modeling takes the clustering into account and allows modeling to be conducted simultaneously at the level of the cluster and at the level of the individual (Wright & London, 2009). Ignoring the group structure, as in Model 10.1, could lead to overestimating the residuals when predicting the outcome of a new respondent in an existing group and to underestimate the residuals when predicting the outcome of a respondent in a new group. Furthermore any analysis that pretends the observations are independent is likely to overstate the significance of the results (Faraway, 2006). The researcher could aggregate the data across communities but thereby she would lose most information. Therefore it makes most sense to model com-

112

Chapter 10. Study 4

2

Balloon

3

4

5

Arduino

2

BitsFromBytes

3

4

5

Makerbot Always Innovatin 5 4 3 2

Gumstix

Beagle Board

Open WRT

Open Servo

SquidBee

Neuros

Mikrokopter

OpenEEG

Bug Labs

Open Pandora

5 4

Satisfaction

3 2

5 4 3 2

Openmoko

OLPC

Fab@home

Chumby

RepRap

5 4 3 2 2

3

4

5

2

3

4

5

2

3

4

5

Openness

Figure 10.2: Scatter plots of satisfaction vs. openness for 20 communities

munity effects as random effects. A random effect is a random variable, which cannot be estimated directly in a meaningful way. Instead, the parameters that describe the distribution of this random effect, will be estimated. It appears reasonable to treat the surveyed communities as being randomly selected from a larger collection of communities whose characteristics I aspire to model. In addition, I am not only interested in these specific projects, but in the whole population of open design projects. A random effects approach to modeling is more ambitious in the sense that it attempts to say something about the wider population beyond the particular sample (Faraway, 2006). In contrast, a fixed effect is an unknown constant that is tried to be estimated directly from the data. Fixed effects are commonly used in linear models as conducted in Section 10.1. Multilevel models taking into account group structures in the data, form a rather new type of statistical models as they only became feasible with increased computational power for conducting the calculation (cf. Wright & London, 2009). As of today methods to handle linear mixed-effects models are well established, but still some ambiguity remains concerning which method has to be preferred and how the resulting models can be evaluated. In particular the calculation of p-values is deemed difficult and critical across

Chapter 10. Study 4

113

researchers (e.g. Bates, Forthcoming). For my analysis I follow recent recommendations from the available literature on multilevel models, but the gentle reader has to be aware that assessments on the validity of models and resulting p-values have to be treated with increased care. Nevertheless, given the underlying structure of my data, I strongly believe that multilevel models are worth the increased effort they require and provide the most suitable approach for my investigation.

The impact of openness I will start this multilevel approach with a model of the form: Satisfaction =

Openness effect Community effect + (random) (fixed)

or more formally: Sij = β0 + β1 Oij + bi + ij ,

i = 1, ..., 20,

j = 1, ..., ni

(10.2)

where Sij is the observed satisfaction for respondent j in community i. The intercepts vary randomly for each community and are denoted by β0i = β0 +bi where the bi are independent and normally distributed for the communities. The bi are residuals but at the cluster level for i = 1, ..., 20 communities, and are also called random effects. ij denotes the common regression residuals for j = 1, ..., ni respondents, where ni is the number of respondents from community i. The total number of observations is N = 20 i=1 ni = 309. The variances are denoted σb2 for the bi , or “between-community” variability, and σ2 for the ij , or “within-community” variability. That is, bi ∼ N(0, σb2 ),

ij ∼ N(0, σ 2 )

For notation purpose, I mainly follow Pinheiro and Bates (2000). Figure 10.2 includes a visualization of the relation between satisfaction and openness on a community level. Similar to Figure 8.3 for the non-grouped data, the graph confirms the positive correlation of the two constructs. In most communities higher satisfaction appears to come along with a higher degree of openness. To calculate the above specified model I use the function lme from the package nlme (Pinheiro et al., 2009). I choose to set method=’ML’ for maximum likelihood, i.e. the log-likelihood is maximized. The alternative would be to

114

Chapter 10. Study 4

use the method REML and fit the model by maximizing the restricted loglikelihood. There are disagreements about which method is to be preferred, but I use the ML-method due to its advantages when comparing models with ANOVA. Models with different fixed effects could otherwise not be compared, because the linear combinations would be different and the obtained maximum likelihoods would not be comparable (Wright & London, 2009; Faraway, 2006). Hence I obtain: > summary(model1 <- lme(S ~ O, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 574.4826 589.416 -283.2413 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.2155173 0.5869509 Fixed effects: S ~ O Value Std.Error DF t-value p-value (Intercept) 2.5714465 0.23368177 288 11.004053 0 O 0.3729546 0.05798322 288 6.432112 0 Standardized Within-Group Residuals: Min Q1 Med Q3 -4.18680505 -0.56801820 0.08857195 0.62858053

Max 2.08453694

The estimates for the parameters have been calculated as βˆ0 = 2.57∗∗∗ ,

βˆ1 = 0.37∗∗∗

With an ANOVA, one can test the underlying hypothesis for this model H0 : β0 = β1 = 0 The p-values from conditional t-tests are shown in the very right column of the output for fixed effects above. They test the marginal significance of each fixed effect coefficient when all other fixed effects are present in the model (cf. Pinheiro & Bates, 2000). This analysis reveals that both β0 and β1 are significantly deviant from 0 and I can reject H0 . Not rejecting the hypothesis H0 would completely eliminate the fixed-effect parameters from the model, i.e. the mean response across the

Chapter 10. Study 4

115

1 −2

−1

0

Estimates residuals

1 0 −1 −2

Estimated random intercepts

2

Residuals

2

Random intercepts

−3

−2

−1

0

1

2

Theoretical Quantiles

3

−3

−2

−1

0

1

2

3

Theoretical Quantiles

Figure 10.3: Normal distribution checks for model 10.2

population would be zero, which is not meaningful for β0 in our case. But, the result for β1 is meaningful and reveals a significant impact of openness on satisfaction. The model characteristics and residuals as printed in the calculation output above appear to be reasonable. Figure 10.3 shows quantile-quantile plots to check for normal distributions of random intercepts bi (left) and residuals ij (right). This reveals that the distributions of both the random intercepts as well as the remaining regression residuals are close to normal distributions. When comparing this model to the corresponding model without consideration of the group structure (the model in equation 10.1), one observes that the estimate for β1 is with 0.373 very similar to the estimate from Model 10.1 with 0.372. The model fit slightly increased as the AIC1 decreased from 579 to 574. The residuals increased as expected. Overall it appears that an ordinary linear approach to modeling already delivered meaningful outcomes, but taking into account the community affiliation of respondents increases the suitability of the resulting model to explain the data. Hence I arrive at a first indication supporting my hypothesis block H4. A more detailed model is however required to address the particular research 1

Akaike’s information criterion is a measure of the goodness of fit of an estimated statistical model. It is grounded in the concept of entropy, in effect offering a relative measure of the information lost when a given model is used to describe reality and can be said to describe the tradeoff between bias and variance in model construction, or loosely speaking that of precision and complexity of the model. The preferred model is the one with the lowest AIC value, the AIC methodology attempts to find the model that best explains the data with a minimum of free parameters (cf. Sheather, 2009).

116

Chapter 10. Study 4

hypotheses from Chapter 7. But before analyzing aspects of openness, I now want to expand the previous model in order to investigate the impact of openness of software and hardware separately.

The influence of openness of software and hardware Sij = β0 + βSW O.SWij + βHW O.HWij + bi + ij ,

i = 1, ..., 20,

j = 1, ..., ni (10.3)

> summary(model1a <- lme(S ~ O.SW + O.HW, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 569.7126 588.3793 -279.8563 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.1976640 0.5821734 Fixed effects: S ~ O.SW + O.HW Value Std.Error DF t-value p-value (Intercept) 2.4122918 0.24225588 287 9.957619 0.0000 O.SW 0.4183302 0.07236914 287 5.780506 0.0000 O.HW -0.0254814 0.05919377 287 -0.430475 0.6672 Standardized Within-Group Residuals: Min Q1 Med Q3 -4.27484522 -0.52444865 0.08072427 0.62880927

Max 2.18191307

The estimates for the parameters are βˆ0 = 2.41∗∗∗ ,

βˆSW = 0.42∗∗∗ ,

βˆHW = −0.03

Again, the model characteristics and residuals appear reasonable. Figure 10.4 shows the quantile-quantile plots for Model 10.3 to check for normal distributions of random intercepts bi (left) and residuals ij (right). Similar to before, this reveals that the distributions of both the random intercepts as well as the remaining regression residuals are close to normal distributions.

Chapter 10. Study 4

117

1 −2

−1

0

Estimates residuals

1 0 −1 −2

Estimated random intercepts

2

Residuals

2

Random intercepts

−3

−2

−1

0

1

2

3

Theoretical Quantiles

−3

−2

−1

0

1

2

3

Theoretical Quantiles

Figure 10.4: Normal distribution checks for Model 10.3

Comparing Model 10.2 and 10.3, one observes that the AIC decreased with expanding the model from 574 to 570. An ANOVA confirms that Model 10.3 does provide a significantly better fit than Model 10.2 at a p-value of ∼ 0.9% (cf. Table 10.1). Across the surveyed communities openness of software has a significant impact on satisfaction, whereas the model does not show significant results for the influence of openness of hardware. A t-test on the parameter estimates confirms that the influence of openness of software is significantly higher than for hardware. Remembering my previous finding that openness of software is more important to developers than openness of hardware, this observation appears entirely reasonable and delivers a first indication supporting the hypotheses block H5. While the difference in perceived importance of openness between software and hardware turned out to be significant but small (Chapter 9), I now cannot observe any influence from openness of hardware on developers’ satisfaction. This might arise from the joint modeling with software and the high correlation between openness of software and openness of hardware. Separate models shall therefore be investigated later in this chapter.

Modeling aspects of openness As I gained confidence that openness does indeed impact satisfaction, I want to deepen my analysis by splitting openness into its three aspects trans-

118

Chapter 10. Study 4

parency, accessibility, and replicability. The model receives the form: Sij = β0 + βT Tij + βA Aij + βR Rij + bi + i

(10.4)

> summary(model2 <- lme(S ~ T + A + R, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 575.9397 598.3398 -281.9699 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.1941604 0.5866805 Fixed effects: S ~ T + A + R Value Std.Error (Intercept) 2.4121361 0.25031684 T 0.1381534 0.06146915 A 0.1956132 0.05665770 R 0.0748317 0.04569727

DF 286 286 286 286

t-value p-value 9.636332 0.0000 2.247525 0.0254 3.452545 0.0006 1.637552 0.1026

Standardized Within-Group Residuals: Min Q1 Med Q3 -4.4251041 -0.5663871 0.0986253 0.6388497

Max 2.0634982

The estimates for the parameters are βˆ0 = 2.41∗∗∗,

βˆT = 0.14∗ ,

βˆA = 0.20∗∗∗ ,

βˆR = 0.07

From the marginal t-tests on all fixed effects, one can see that transparency (p-value ∼ 2.5%) and accessibility (p-value < 0.1%) significantly impact satisfaction in this model. Only the influence of replicability is low and does not significantly differ from 0 (p-value ∼ 10%). The researcher hence finds support for the hypotheses H4-T and H4-A, whereas H4-R appears not to be reflected in the data set. When comparing Model 10.4 to Model 10.2, one observes an increase in AIC. Accordingly an ANOVA does not show a significant increase in model fit trough splitting openness into its three aspects (cf. Table 10.1). In the next step, I want to investigate the influence of the three constructs separated for software and hardware by building three more models, one

Chapter 10. Study 4

119

with the constructs on software, one with the constructs on hardware, and one including all six constructs. For software, the model receives the form: Sij = β0 + βT.SW T.SWij + βA.SW A.SWij + βR.SW R.SWij + bi + i

(10.5)

The estimates for the parameters are βˆ0 = 2.17∗∗∗ ,

βˆT.SW = 0.14∗ ,

βˆA.SW = 0.22∗∗∗ ,

βˆR.SW = 0.09+

Quantile-quantile plots to check for normal distributions of random intercepts bi (left) and residuals ij are shown together with the calculation output in Appendix D.2. For Model 10.5 marginal t-tests reveal a significant impact of all three constructs on satisfaction. Transparency and accessibility are likewise to the general constructs in Model 10.4 significant at p-values below 5% and 0.1% respectively. Replicability of software components shows a small effect at a p-value of about 6%. The AIC decreased to 569, indicating a comparably high goodness of fit. For hardware, I build: Sij = β0 + βT.HW T.HWij + βA.HW A.HWij + βR.HW R.HWij + bi + i (10.6) The parameters are estimated to βˆ0 = 3.17∗∗∗ ,

βˆT.HW = 0.09,

βˆA.T W = 0.08+ ,

βˆR.HW = 0.05

A detailed calculation output is again printed in Appendix D.2. T-tests show a weakly significant effect of accessibility (p-value ∼ 8%) and no significant impact from transparency and replicability on satisfaction (p-value > 10%). Compared to previous models, Model 10.6 is worse explaining the underlying structure in the data as its AIC rose to 601. From Model 10.6 one observes that indeed the influence of openness of hardware on satisfaction is rather weak. Hence, the small influence in joint models with software is not caused by the correlation of the constructs as previously contemplated. Extending the model to include all software and hardware constructs results in: Sij = β0 + βT.SW T.SWij + βA.SW A.SWij + βR.SW R.SWij + βT.HW T.HWij + βA.HW A.HWij + βR.HW R.HWij + bi + i

(10.7)

120

Chapter 10. Study 4

The estimates for the parameters are βˆ0 = 2.17∗∗∗ , βˆT.SW = 0.14∗ , βˆA.SW = 0.25∗∗∗ , βˆR.SW = 0.08, βˆT.HW = 0.00, βˆA.T W = −0.03, βˆR.HW = 0.00 A detailed output of the calculation is likewise shown in Appendix D.2. Constructs representing transparency and accessibility of software show a significant impact on satisfaction, constructs representing replicability of software and openness of hardware do not show any relevant influence. The estimated parameters of the investigated model (Model 10.7) and their significance levels obtained from marginal t-tests appear to support the hypotheses H5-T and H5-A, revealing significant effects from transparency and accessibility of software components, while not showing any significant impact from openness of hardware or its aspects. However to derive secure conclusions concerning H5, an additional analysis is required testing for significant differences in impact of the aspects of openness between software and hardware. I therefore conduct t-tests, one for each aspect of openness, testing the hypothesis that the slope of the aspect is equal for software and hardware. Based on Model 10.7, I find that I can only reject this hypothesis for accessibility at a p-value ∼ 1%. Concerning transparency and replicability the tests do not show significant differences in slope between software and hardware. This finding supports the research hypothesis H5-A, but questions H5-T and H5-R. The AIC for Model 10.7 has been computed to 574, i.e. including the three hardware constructs to Model 10.5 resulted in a weaker output. I therefore consider to model openness of hardware with only one variable and build: Sij = β0 + βT.SW T.SWij + βA.SW A.SWij + βR.SW R.SWij + βO.HW O.HWij + bi + i > summary(model3 <- lme(S ~ T.SW + A.SW + R.SW + O.HW, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 570.2701 596.4035 -278.1351 Random effects: Formula: ~1 | Community (Intercept) Residual

(10.8)

Chapter 10. Study 4 StdDev:

121

0.1769865 0.5810093

Fixed effects: S ~ T.SW + A.SW + R.SW + O.HW Value Std.Error DF t-value p-value (Intercept) 2.1804770 0.26248138 285 8.307168 0.0000 T.SW 0.1522559 0.06101505 285 2.495382 0.0131 A.SW 0.2320811 0.06289700 285 3.689860 0.0003 R.SW 0.0911348 0.04681631 285 1.946646 0.0526 O.HW -0.0326110 0.05882454 285 -0.554378 0.5798 Standardized Within-Group Residuals: Min Q1 Med Q3 -4.43723963 -0.53370415 0.09293781 0.61801252

1 −2

−1

0

Estimates residuals

1 0 −1 −2

Estimated random intercepts

2

Residuals

2

Random intercepts

Max 2.12385544

−3

−2

−1

0

1

2

Theoretical Quantiles

3

−3

−2

−1

0

1

2

3

Theoretical Quantiles

Figure 10.5: Normal distribution checks for Model 10.8

The AIC of Model 10.8 has been calculated to 570. Quantile-quantile plots to check for normal distributions of random intercepts bi (left) and residuals ij are shown in Figure 10.5. Similar to previous models, all model characteristics appear reasonable. Estimates for the model parameters result in: βˆ0 = 2.18∗∗∗ , βˆT.SW = 0.15∗ , βˆA.SW = 0.23∗∗∗ , βˆR.SW = 0.09+ , βˆO.HW = −0.03 Marginal t-tests reveal a strongly significant impact from accessibility of software (p-value < 0.1%) and a significant impact from transparency of software (p-value ∼ 1%) on developer satisfaction. Also replicability of software

122

Model AIC 10.3 10.2 - O 574 0.009 10.3 - O.SW,O.HW 570 * 10.4 - T,A,R 576 * 10.5 - T,A,R .SW 569 * 10.6 - T,A,R .HW 601 * 10.7 - T,A,R .S/HW 574 * 10.8 - T,A,R .SW,O.HW 570 * * not applicable, - not meaningful

Chapter 10. Study 4

10.4 0.280 0.044 * * * * *

p-value 10.5 10.6 0.007 < .001 0.077 < .001 * * * * * * *

10.7 0.068 0.479 0.052 0.948 < .001 * 0.975

10.8 0.017 0.179 0.006 0.576 * -

Table 10.1: Comparison of multilevel models showing AICs and p-values from ANOVAs appears to have an effect, but at a low significant level (p-value ∼ 6%). Concerning openness of hardware no significant impact could be determined, as before in Model 10.3 and 10.7. Hypotheses tests for equality of slopes between the parameters for software and hardware have again been conducted based on Model 10.8. I find that transparency of software has an impact significantly higher than openness of hardware at a p-value ∼ 6%. Similar to the analysis above the test also reveals a significant difference for accessibility (p-value < 1%) and no significant result concerning replicability. Taking the observations together, I hence conclude that hypothesis H5 for transparency is only slightly reflected in the data. H5-A receives strong support from this analysis. In contrast, my results do not provide any support for H5 concerning replicability.

Evaluation of modeling approaches Table 10.1 summarizes the results from ANOVAs between two models respectively for the seven multi-level models. To evaluate the different modeling approaches conducted, I want to compare the models on the basis of AIC and p-values as printed in the table. The simplest model (Model 10.2) starts with an AIC of 574. The AIC of 570 for Model 10.3 and the p-value of 0.009 between the Models 10.2 and 10.3 confirms that splitting openness into software and hardware does significantly increase the model fit. By contrast, purely splitting openness into its

Chapter 10. Study 4

123


    

    

   

   !

     

"



 

Figure 10.6: How openness impacts satisfaction (Model 10.8)

constructs transparency, accessibility, and replicability does not improve the model fit (compare Model 10.2 to 10.4). Model 10.5, investigating the impact of the three constructs for software, shows a significant increase in fit compared to Model 10.2, confirmed by a p-value of 0.7%. Similar Model 10.6, investigating the impact of the three constructs for hardware, significantly outperforms Model 10.2 when looking at the p-value, but it does not show a lower AIC. Expanding the modeling approach to include both software and hardware constructs, as done with Model 10.7, improves the model performance compared to Model 10.6 (hardware only), but not compared to Model 10.5 (software only). Based on the AIC and the p-values, Model 10.5 would accordingly be the model of choice. However, this would not allow me to draw conclusions about the impact of openness of hardware on satisfaction. Therefore I expand the latter one to Model 10.8 and accept a small increase in AIC from 569 to 570 substitutional for a higher explanatory power. The final model of choice, i.e. the model assumed to best explain the investigated relationship between openness and satisfaction, is visualized in Figure 10.6. To ensure stability for my findings, and in particular for my conclusions concerning my research hypotheses, let me take a look at Appendix D.3 summarizing the models obtained after transformation of the variables to normality. The resulting models verify the significant influence of openness on satisfaction, as well as the observed results when splitting openness into software and hardware. Investigating Model 10.4, one observes a significant impact on satisfaction from transparency and accessibility, but no significant influence from replicability. This reconfirms my previous findings concerning the research hypotheses block H4. Building Model 10.7 from transformed variables results in the same signifi-

124

Chapter 10. Study 4

cance indications from marginal t-tests as with the original data, reconfirming my earlier conclusions for the hypotheses block H5. Further t-tests on the significance of differences between software and hardware do not deliver meaningful results for the single aspects, but support that indeed openness of software components has a stronger positive effect on developer satisfaction than openness of hardware components. For the final model (Model 10.8), the results from transformed variables confirm a strongly significant impact from transparency and accessibility of software on developer satisfaction. However, the impact of replicability of software looses its significance as the corresponding p-value rises from ∼ 5% to ∼ 10%. For openness of hardware one cannot observe a significant influence likewise to the model before transformation to normality.

10.3

Do expectations towards openness influence this relationship?

To address hypothesis H6, I investigate correlations between individual expectations towards openness and the respective constructs themselves as well as their influence on the relationship modeled in the previous two sections. Following the same approach as in Section 8.5, constructs have been built to represent respondents’ expectations (cf. Appendix D.4). These will be used to update Model 10.8 with the appropriate two-way coefficients in order to build the model visualized in Figure 10.7. Individual expectations are modeled as moderator variables to properly investigate their effect on the relation between openness and satisfaction. The formal resulting multi-level model is printed together with the calculation output in Appendix D.4. From those results, one cannot observe significant effects from individual expectations, apart from replicability of software showing a weakly significant impact at a p-value ∼ 8%. Irritatingly the model does not show any significant effects from transparency and replicability of software on developer satisfaction. The AIC increased compared to Model 10.8, indicating that considering developers expectations resulted in a weaker model. As summarized in Table 10.2, the underlying data contains fairly high correlations between satisfaction and the conformance to expectations towards openness (left column). On the one hand these correlations support my research hypothesis H6. On the other hand, correlations between the four constructs and the respective conformance to expectations towards them show

Chapter 10. Study 4

125


    

   


  



   



 

     



     

Figure 10.7: Modeling the influence of expectations

very high values themselves (right column). This keeps me from building a reliable model and causes the unclarity about the impact from the different constructs observed above. Therefore I cannot draw conclusions about the impact of developers’ expectations on the relationship between their perceived openness and their satisfaction.

Expectation towards Transparency (SW) Accessibility (SW) Replicability (SW) Openness (HW)

Correlation against Satisfaction The construct itself 0.21∗∗∗ 0.51∗∗∗ + 0.10 0.45∗∗∗ ∗∗∗ 0.26 0.49∗∗∗ + 0.09 0.55∗∗∗

Table 10.2: Correlations between conformance to expectations and developer satisfaction or the respective constructs themselves

10.4

Effects on contributed working hours

In Chapter 9 I discuss that highly active developers value openness more than less active developers. Thus the question arises whether openness not only affects developer’s satisfaction with a project, but also their contribution. In this section I aim to investigate this relationship and to analyze potential other factors impacting contributed working hours. Hypothesis H7, i.e. the relationship between satisfaction of developers and their contribution, will be researched.

126

Chapter 10. Study 4

To systematically examine effects on contributed working hours different multilevel models shall be tested. In the first step, I want to investigate the impact of satisfaction (S) on the transformed number of working hours (h) (see Section 8.5 for details concerning the transformation of the variable to meet the condition on normal distribution of variables for linear models): hij = β0 + βS Sij + bi + ij

(10.9)

Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 492.8543 507.696 -242.4271 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.1504762 0.5280157 Fixed effects: h ~ S Value Std.Error DF t-value p-value (Intercept) 0.6876114 0.2000243 281 3.437639 7e-04 S 0.2281531 0.0482383 281 4.729708 0e+00 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.13681964 -0.57360628 -0.06541413 0.57237353

Max 2.95661801

The parameter estimates have been calculated to βˆ0 = 0.69∗∗∗ ,

βˆS = 0.23∗∗∗

Marginal t-tests on Model 10.9 reveal a strong impact from the satisfaction of a developer with a project on the number of hours he or she is contributing to this project (p-value < 0.1%). The model characteristics appear reasonable. Figure 10.8 shows checks for normal distribution of random intercepts bi (left) and residuals ij (right). One can see that the requirement of normal distribution seems to be fulfilled sufficiently (after transforming the variable measuring working hours as discussed). Hence I find strong support for my research hypothesis H7, postulating that developer satisfaction positively influences the extent of individual contribution. In the next step I attempt to include openness into the model: hij = β0 + βS Sij + βO Oij + bi + ij

(10.10)

Chapter 10. Study 4

127

1 −2

−1

0

Estimates residuals

1 0 −1 −2

Estimated random intercepts

2

Residuals

2

Random intercepts

−3

−2

−1

0

1

2

Theoretical Quantiles

3

−3

−2

−1

0

1

2

3

Theoretical Quantiles

Figure 10.8: Check for normal distribution for Model 10.9

Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 494.7042 513.2564 -242.3521 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.1564863 0.5272281 Fixed effects: h ~ S + O Value Std.Error DF t-value p-value (Intercept) 0.6327228 0.24755548 280 2.555883 0.0111 S 0.2204199 0.05160697 280 4.271127 0.0000 O 0.0223365 0.05610459 280 0.398122 0.6908 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.12537937 -0.57886283 -0.06185313 0.56680547

Max 2.96749659

The parameters with significances as indicated from marginal t-tests are estimated to βˆ0 = 0.63∗∗∗ , βˆS = 0.22∗∗∗ , βˆO = 0.02 In contrast to satisfaction (p-value < 0.1%), openness does not show a direct impact on the number of working hours. Including openness does accordingly not enhance the model, a finding that can also be derived from the raise in AIC from 493 to 495. Similar including openness of software and hardware

128

Chapter 10. Study 4


    

    

   

   !

     



#  $   %&  $

"



 

Figure 10.9: The relation of openness, satisfaction, and contributed working hours

separately does not show significant effects on the response variable, the AIC would increase to 496 for this model. Including transparency, accessibility, and replicability would increase the model’s AIC to 498, and does not show significant regression coefficients for the constructs representing the three aspects of openness. I hence conclude that neither openness nor any of its aspects have a direct impact on the number of contributed working hours. However openness significantly influences satisfaction, which in turn impacts the reported hours. The entire interrelation is visualized in Figure 10.9. Furthermore, one would expect to find plenty of other factors influencing the amount of contribution from a single developer. In this work, I cannot measure all possible effects, but I can expand my model to account for some of them. My case study in Chapter 6 revealed that complexity and innovativeness are two attributes of particular importance to open design projects (cf. Section 6.3.2). I observed that projects developing comparatively simple objects with a rather low degree of innovativeness tend to be closer to the completion of a design. Therefore I attempt to model the impact of complexity and innovativeness of the developed product together with satisfaction on the contributed weekly working hours by participants. Both complexity (C) and innovativeness (I) are measured at the community level. The model receives the form: hij = β0 + βS Sij + βC Ci + βI Ii + bi + ij Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 485.3724 507.6349 -236.6862

(10.11)

Chapter 10. Study 4

129

Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.0562462 0.5272672 Fixed effects: h ~ S + Complexity + Innovativeness Value Std.Error DF t-value p-value (Intercept) 1.1695311 0.26867044 281 4.353032 0.0000 S 0.2330259 0.04714575 281 4.942670 0.0000 Complexity -0.2531331 0.06852964 17 -3.693776 0.0018 Innovativeness 0.0767005 0.03996875 17 1.919011 0.0719 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.19831504 -0.55178862 -0.03963711 0.56172432

Max 3.12451538

The parameters have been calculated to βˆ0 = 1.17∗∗∗ ,

βˆS = 0.23∗∗∗ ,

βˆC = −0.25∗∗ ,

βˆI = 0.08+

Compared to Model 10.9 one observes an enhanced goodness of fit, as the AIC decreases from 493 to 485. The estimated impact for satisfaction remains similar. The complexity of the object shows a strongly significant negative impact on contributed working hours (p-value ∼ 0.2%). The degree of innovativeness of the developed outcome has a slightly significant positive impact (p-value ∼ 7.2%). Checks for normal distribution of residuals deliver similar results as for Model 10.9 (Figure 10.8). The correlation between complexity and innovativeness among the surveyed communities has been estimated to ∼ 0.4, similar to the comprehensive database investigated in Chapter 5 (cf. Table 5.1). No correlation has been determined between satisfaction and complexity or innovativeness. This analysis supports previous assumptions that highly complex objects might be less suitable for open source development approaches. Detailed conclusions bringing my findings together will now follow in the last part of my work.

Part V Integration of findings

Chapter 11 Discussion of findings 11.1

Summary of findings

In this thesis I argue that open source development does indeed seem feasible for tangible products and that open design is a rapidly evolving field holding a lot of opportunities. From a theoretical point of view, little is known about open source outside software, while OSS itself has received considerable scholarly attention in recent years. In Chapter 3 I discuss arguments why the circumstances are different for digital and tangible products and which issues may prohibit open development of physical goods. But I also point out that, in a sense, hardware is becoming much like software, allowing hardware development to be conducted increasingly like software development. In the realm of open source and open innovation, openness is a multi-faceted topic. I use a gradual approach towards openness, ranging from closed to open and covering various degrees of openness, also referred to as ‘selective revealing’ or ‘open parts’ in the literature. Further, I distinguish three aspects of openness: transparency, accessibility, and replicability, and allow differing degrees of openness for all three aspects. Transparency refers to the revelation of knowledge, accessibility offers external contributors possibilities to actively influence the development and make contributions, and replicability denotes the possibility to self-assemble the product. The latter one becomes particularly important outside the domain of software development. Business opportunities from OSS development have received an increasing amount of attention among researchers, as it is a great ambiguity of how to appropriate returns. Beyond software new opportunities arise to leverage K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_11, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

134

Chapter 11. Discussion of findings Q1 Q2 Q3 Q4 Q5

What kind of open design projects emerged so far? How does open design work in practical examples? Does the degree of openness matter to the communities? Does the meaning of openness differ between open source software and open design? How does openness impact developer’s satisfaction and their contributions? Table 11.1: Five main research questions

communities as external resources because open hardware is still difficult to copy, and, to a certain extent, hardware is already open by its nature. In contrast to pure software, it appears possible to capture value from marketing a commonly developed physical product. In Chapter 4 I develop a clear-cut definition of open source innovation and a comprehensive framework for studying the landscape of open source development in the world of atoms. Detailed research questions and resulting propositions are derived from theory and proposed along this framework. My main research questions are summarized in Table 11.1. To address the first question ‘What kind of open design projects emerged so far?’ and to investigate the variety of open design, I have compiled a pool of projects meeting the required definition. A thorough analysis of cases reveals project characteristics, structures, and success in Chapter 5. Contributors from commercial and private backgrounds build communities of one to several hundred developers. They develop products across all degrees of complexity and innovativeness and for all types of intended audience. Many objects include programmed components and software, but some also consist of pure hardware. The considered projects stem from various industries and countries, their current development stages range from the evolvement of first rough ideas to mature and successfully marketed products. I observe different strategies towards the IP regime ranging from selective revealing of components under sophisticated licenses to the free release of all related information to the public domain. The sample includes both approaches sponsored and driven by commercial companies marketing the product as well as purely user and community driven projects. Research propositions are tested to draw comparisons between OSS and open design and are summarized in Table 11.2. Comparable to prior findings from the software industry, I observe significant positive correlations between the size of the community, the involvement of commercial contributors, and

Chapter 11. Discussion of findings

135

The size of the community is positively correlated with project  advancement P2 The participation of commercial contributors is positively cor-  related with project advancement P3 Highly restrictive licenses are negatively correlated with X project advancement P4 Developer activity is positively correlated with project ad-  vancement P5 Addressing an advanced audience is positively correlated with X project advancement P1

Table 11.2: Overview of research propositions project advancement. However in contrast to pure software development, my cases do not show correlations between the chosen type of license and the audience addressed to project advancement respectively. In Chapter 6 I conduct six in-depth case studies investigating projects’ different organizational and institutional structures. After a short overview and description of cases, mechanisms of open design projects are the focus of this chapter to deal with my second main research question ‘How does open design work in practical examples?’. My cases reveal that developers in open design tend to be more multi-disciplinary than in OSS, accordingly participants not necessarily have prior experiences from OSS. However contributors with prior connections to open source are particularly likely to subscribe to the goals pursued in open design. I observe both community- and company-driven open design projects successfully managing the development process. Concerning the characteristics of the artifacts developed, I find that modular and simple objects appear particularly well suited to open design and that feasibility seems to depend jointly on modularity, complexity, and innovativeness. Objects are being produced in three different loci of production: with external manufacturers, with the community, or with the focal organization coordinating the project. In every case the trade-off between benefits for the community, e.g., in the form of revealed information, and for the focal company is accepted as long as the balance is perceived to be fair. In Chapter 7, based on the findings and observations summarized above, I extend and build a conceptional framework distinguishing three aspects of openness, namely transparency, accessibility, and replicability. This allows a sophisticated examination of the manifold variable openness particularly in areas beyond software. Then I inductively develop seven blocks of research

136

H1-T H1-A H1-R H2-T H2-A H2-R H3-T H3-A H3-R H4-T H4-A H4-R H5-T

H5-A

H5-R

H6

H7

Chapter 11. Discussion of findings

Software components are more transparent than hardware  components Software is more accessible than hardware  Software components are more replicable than hardware com-  ponents Transparency is important to open design communities  Accessibility is important to open design communities  Replicability is important to open design communities () Transparency of software components is more important than  transparency of hardware components Accessibility of software components is more important than  accessibility of hardware components Replicability of software components is more important than  replicability of hardware components The degree of transparency has a positive impact on developer  satisfaction The degree of accessibility has a positive impact on developer  satisfaction The degree of replicability has a positive impact on developer X satisfaction Transparency of software components has a stronger positive () effect on developer satisfaction than transparency of hardware components Accessibility of software components has a stronger positive  effect on developer satisfaction than accessibility of hardware components Replicability of software components has a stronger positive X effect on developer satisfaction than replicability of hardware components The individual expectation towards openness and its aspects X influences the relationship between openness and developer satisfaction The satisfaction of a developer with his project positively in-  fluences the extent of his contribution Table 11.3: Overview of research hypotheses

Chapter 11. Discussion of findings

137

hypotheses and conduct a web-based questionnaire survey in 20 open design communities with 309 valid responses to address them. Table 11.3 summarizes my research hypotheses and shows how the study has contributed to the understanding of the perception and relevance of openness among members of open source communities. My findings in Chapter 9 validate the existence and relevance of the three aspects of openness and suggest that open parts strategies are crafted at the component level, rather than the level of the entire design. Some parts of a design can be entirely closed, whereas others are opened up. In particular the degree of openness differs significantly between software and hardware components, in the sense that software is more transparent, accessible, and replicable than hardware. My study strikingly reveals that openness indeed matters to community members and is not self-evident. The response to my third main research question ‘Does the degree of openness matter to the communities?’ is clearly yes. For all three aspects (transparency, accessibility, and replicability), respondents declare that the degree of openness is important to them, albeit to different degrees. Again my results show significant differences between software and hardware components in this regard, answering also to my fourth main research question ‘Does the meaning of openness differ between open source software and open design communities?’ in the affirmative. The analysis discloses that openness of software is significantly more important to community members than openness of hardware. Furthermore I observe that highly active developers declare higher importance ratings than less active developers. However the perceived importance of openness does not vary with participants’ durations of engagement in a project. In Chapter 10 I develop sophisticated statistical models to explain the impact of openness on developer communities in order to address my fifth main research question ‘How does openness impact developers satisfaction and their contributions?’. I find that a higher degree of openness does indeed show a significant positive influence on developer satisfaction and that openness of software is more relevant in this regard than openness of hardware. My models reveal that the degree of accessibility has the strongest impact on satisfaction, followed by transparency. Replicability of the product or its components is deemed least important and does not show a significant impact on developer satisfaction. Comparing the particular influence of each aspect of openness between software and hardware shows significant differences

138

Chapter 11. Discussion of findings

with regard to accessibility and non-significant but still apparent differences concerning transparency. An influence of expectations towards openness on these relationships could not be determined. The degree of openness impacts satisfaction, which in turn significantly impacts the contributions from developers as shown in the last section on modeling. Although openness does not show a direct effect on developer’s contribution in an expanded model, the influence becomes evident from the separated modeling approaches and supported by several quotes: “Every time we chose openness over internal control, we have been rewarded.” (Sean Moss-Pultz, Openmoko, CEO) “I would not have invested as much time in the Makerbot if it were not as open and collaborative as it is.” (Makerbot, Community member) In line with my previous findings an adopted model further reveals a negative influence from high degrees of complexity together with a positive influence from high degrees of innovativeness. This observation confirms that the right balance between the two attributes is particularly important to inspire developers to contribute and to achieve advanced stages of project development.

11.2

Open source software versus hardware revisited

Software is a very special produce and to distribute easy to make variations in collaborative development, of existent OSS projects.

good with special characteristics. It is fast to at almost no cost. Its digital nature makes it it. Therefore it appears particularly suitable for a conclusion strongly proven by the vast amount

Physical objects typically do not possess these special characteristics, but my study shows how hardware is becoming much like software. I indicate that, in open design communities, tangible objects can be developed in very similar fashion to software; one could even say that people treat a design as source code to a physical object and change the object via changing the source. Finally, the tangible product itself is, in a sense, only software converted to hardware, as its purpose becomes reduced to the realization of a product idea.

Chapter 11. Discussion of findings

139

“One of the things that the RepRap project seems to have done right is to make the design of the hardware as much like a piece of software as possible.” (Adrian Bowyer, RepRap, Project leader) Comparing characteristics of open design projects to previous findings in the software realm, I find both similarities as well as differences. As in the software world a large number of developers, high activity, and the participation of commercial contributors appear advantageous for project advancement. In contrast to software the choice of the licensing model does not show an impact on project success. This observation could remind the researcher of the unclarity about the appropriateness of licenses in the hardware realm. “Legal concepts that work well for software, such as copyright and copyleft, don’t neatly fit when dealing with hardware products and the documentation used to create them.” (TARP Open Hardware License) Above and beyond these findings, I further observe that circumstances facilitating open and collaborative development are normally given for software running on standardized hardware like in the PC industry. For mobile phones and other embedded devices, device makers typically do not publish sufficient documentation to enable third-party developers to write their own software. If someone wants to write software for such a device, he would either need to reverse engineer existing hardware or build his own hardware (Welte, 2009). The reasoning seems likely that people who favor open source software and who want to be able to highly customize and control their device increasingly demand openness of hardware. For these products incorporating both software and hardware development, my study indicates that both openness of software and hardware is perceived to be of particular importance to developers. However, my analysis further shows that openness of software is assessed to be of higher importance than openness of hardware and that openness of software significantly impacts developer satisfaction in contrast to openness of hardware. I hence observe that despite developers rate openness of hardware as almost as important as openness of software, openness of hardware does not significantly influence their satisfaction. Critics may respond that the subject is not that openness in software is generally more valued relative to openness in hardware, but that each respondent values the type of openness that he can actually exploit given his expertise.

140

Chapter 11. Discussion of findings

They could argue that software experts do not care much about hardware openness, because they cannot get much value out of it. However, my data does not reveal any relationship between a respondent’s duration of activity in a project and his rating of importance of openness. Further, one cannot observe a significant influence of respondents’ expectations towards the degree of openness on the relation between openness and satisfaction, neither for software nor for hardware. This indicates that longer affiliation to such projects, does not generally enhance the assessment of the importance of openness. I therefore conjecture that a developer’s perception of the importance of openness of software and hardware, is disconnected from his prior experience with software and hardware development in the majority of cases. Additional examination of this topic appears required to arrive at secure evidence concerning the relation between developer’s prior expertise and their assessment of the importance of openness.

11.3

Scope of generalization and limitations

Before closing, I want to mention three important limitations of the present study: First, although I have thus established a reasonably large directory with 104 open design projects, 104 is a small number compared to about 225.000 OSS projects hosted at Sourceforge, for example. Since there is no corresponding platform for open design, a comprehensive database of all existing projects is difficult to generate. Based on my research and additional expert interviews, I feel confident to include the majority of open design projects, but I still have to be careful when generalizing results. Concerning the actual data, it has to be noted that my data base is not fully filled and that some information is missing which could not be obtained from secondary sources. My quality checks allow for adjustments based on an objective assessment, but critically depend on the availability of accurate secondary data. Since the directory is fairly young, I only started to get input from the broader open source community. These caveats notwithstanding, I already reveal a striking variety of projects and gain fairly deep knowledge about project and product details from this source. Albeit the number of studied examples is small compared to similar studies in the software realm, I am firmly convinced of the generalizability of my results from my first empirical study. During my work on this theses, the statistics presented in Chapter 5 have been calculated three times while the

Chapter 11. Discussion of findings

141

data collection evolved, with 76, 85, and 104 cases respectively. Neither the shape of distributions nor the correlations among the different variables changed significantly when increasing the number of considered projects. I therefore strongly expect my findings to remain stable if the sample would become further enlarged. Second, throughout my quantitative research I focus on openness in development and production processes. I distinguish three aspects of openness in this realm and develop measures on available information, possibilities to influence the development and abilities to reproduce the outcome. It certainly would be desirable to replicate the presented study focusing on openness in organization and governance of open design projects. The considered aspects of openness would almost directly be applicable in this domain. Transparency would refer to a publicly visible governance and the ability to follow decision-making processes. Accessibility would denote the possibility to actively participate in governance and the ability to take part in decision making. Replicability would refer to an active release of authority and the encouragement to build copies and side projects. My qualitative research reveals different approaches towards project organization and governance structures across the studied communities. A quantitative investigation of the relation between openness in governance and developer’s satisfaction and contribution could shed additional light on the meaning of openness in the respective communities. Third, for my survey, I consciously chose projects in similar fields to meet the requirement that they include both software and hardware components. On the one hand this approach enables sophisticated comparisons of openness of software and hardware. On the other hand it does not allow me to derive and compare findings about openness in different industries. My first empirical study provides an overview of the different industries where open design is already being applied and shows the distribution of projects across industries. Most projects stem from consumer electronics or IT hardware, i.e. the domains where I conducted my empirical survey. However more research on differences across industries and particular characteristics of openness in specific industries seems warranted in this area.

Chapter 12 Conclusions 12.1

Implications for theory

This research is grounded in the theory on productive resources and dynamic capabilities. Following Sanchez (2004), for example, firm-addressable resources outside a firm can and should be used to complement internal resources and capabilities. Chesbrough et al. (2006) were one of the first who systematically emphasized that firms can and should use external ideals and internal ideas, and internal and external paths to market, as they look to advance their technology. A concept, which they named open innovation and which today is widely accepted in theory and practice. Broadly speaking, firms engaging in open innovation activities may profit from firm-addressable resources and capabilities outside the firm, while, in most cases, still maintaining control and ownership over the created intellectual property. Firms engaging in open source activities typically go one step further and actively release parts of their knowledge to the public or to a designated community. Hence, important resources are not directly controlled and owned by these firms, but reside within communities associated to these firms. The boundaries between internal and external resources become blurred. In this realm open source software development has received considerable scholarly attention, much of which is based on the presumption that the open source model holds some lessons of broader applicability. Nonetheless, knowledge of its deployment outside the software industry was very limited when I started to work on this thesis. Beyond that I experienced a surprising lack of theoretical research on the meaning of openness. To address these issues, the presented work delivers a comprehensive overview of practical K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1_12, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

144

Chapter 12. Conclusions

examples on open design and contributes to a better understanding of the relevance of openness and on different perceptions of openness. I derive the concept of open source innovation as a generalization of the open source model of software development. My definition centers on the collaboration of volunteers and the free revelation of knowledge among actors. Since OSI exhibits important differences to several related concepts in the literature, I conclude that it is an innovation model in its own right, deserving more attention and research. I proceed to identify characteristics affecting the application of the OSI model in industry practice and present a conceptual framework to study them. Based on the results from my field studies, I find that the applicability of OSI is primarily determined by the characteristics of, first, the innovation object and, second, the group of contributors, rather than the industrial sector. The interdependence of collaboration of sponsoring firms and voluntary contributors proves to be of high relevance. My findings further suggest that the meaning of openness is of particular importance in this regard. To address this topic, I follow a gradual approach towards openness and investigate strategies of open parts and partly openness. I extend a conceptional framework by West and O’Mahony (2008) to better account for non-digital innovation objects. It distinguishes between three aspects of openness, i.e. transparency, accessibility, and replicability. I empirically validate the existence and relevance of those aspects and highlight significant differences in perceptions of openness of hardware and software across these three aspects. Openness is shown to be a multi-faceted, gradual, and context-dependent variable. “Communities can be a valuable resource that a firm can leverage if it has relational capabilities.” (Dahlander & Magnusson, 2006, p.126). Relationships with OS communities can create a huge benefit for firms in their attempt to reduce costs, set standards, accelerate technological development, and so forth. Previous studies have shown that OS firms have different approaches to handle these relationships to their communities. With this research I add to this discussion by disclosing the important role of openness in this context. My model shows the significant influence of openness on satisfaction in the community, but I also observe a common understanding for partial openness as long as the balance is perceived to be fair. Thus my findings call for a more careful treatment of the construct of openness in future empirical work.

Chapter 12. Conclusions

12.2

145

Managerial implications

Open design products have been developed successfully and are now exploited commercially. My findings reveal a large variety of examples across many different industries. Both incremental improvements and highly innovative new designs are being tackled in open environments. Many projects have been started by private individuals and over time developed fully marketable products. In other cases, I observe how firms actively initiate open design projects in order to complement their internal resources and capabilities with a community of volunteers sharing their innovations with others. My observations indicate that firms may benefit from their activities in open design through creating and maintaining relationships with these communities. As yet, it is still early days to evaluate the long-term success of open design in NPD, especially in comparisons to alternative modes of development. Nonetheless, the recent emergence of successful business models incorporating open design suggests that this development model may indeed offer advantages over more traditional models of product development. These advantages are likely to derive from efficiencies in transaction and production costs, a large number of contributors compared to in-house development, early access to research results, detailed insights to customer needs, and possibly the cumulative effects arising from the viral nature of open design. “I strongly believe that open source, community developed software and [...] hardware will replace a lot of expensive, off the shelf products, because they will be far more specific, tailored and therefore useful to their intended users.” (GP2X, Community member) “I make many of my purchasing decisions based on openness of design and function.” (Makerbot, End user) For these reasons, the incorporation of open design in their NPD processes may enable companies to gain a competitive advantage in terms of quality, differentiation, cost, or time to market. Moreover, it may facilitate the formation of a community of co-developers with high product loyalty. Recent developments suggest that open product development in the physical world will be subject to increasing experimentation, some of which will be successful. “Open project evolution is somewhat Darwinian. Many fall by the wayside and are abandoned, some fork into newer and bet-

146

Chapter 12. Conclusions ter projects leaving the parent behind, some just keep on going successfully.” (RepRap, Community member)

The rapid growth of collaborative innovation is being supported by technologies that enhance the capabilities of individual developers and simplify distributed open design projects. These technologies include: powerful personal computers, the digitization of design information, easy-to-use tools for digital development, modular design architectures, low cost communication via the Internet, and the increasing availability of equipment for distributed production as cheap 3D printers, for example. Technological trends suggest that both communication costs and design costs will be further reduced over time (Baldwin & von Hippel, 2009). Nevertheless, the idea of deriving profit from open and therefore easily imitable design seems counter-intuitive to many experts. However, in practice, openness is not a dichotomous product characteristic, but shows many different shadings and aspects. My findings suggest that open parts strategies in open design are crafted at the component level, rather than the level of the entire design. Some parts of a design may remain entirely closed, whereas others are opened up. In particular the degree of openness differs significantly between software and hardware components, in the sense that software is more transparent, accessible, and replicable than hardware. I also observe that openness indeed matters to community members. For all three aspects (transparency, accessibility, and replicability), respondents declare that the degree of openness is important to them, albeit to different degrees. Again my results show significant differences between software and hardware in this regard. Openness of software significantly impacts developer’s satisfaction, whereas openness of hardware does not show a significant effect. Across aspects of openness, only transparency and accessibility significantly influence developer’s satisfaction. Replicability is deemed least important and shows the weakest effect. “I do not care about the hardware being easily reproduced. As long as decent design decisions are made, I am usually quite happy.” (Neuros OSD, Community member) This suggests that companies working in open source settings can pursue differentiated strategies short of complete openness without alienating their developer communities. Every product whose design requires software and hardware development seems particularly suitable to this approach. Companies may accordingly involve communities into their software and parts

Chapter 12. Conclusions

147

of their hardware development and profit from the advantages of an open source approach, ranging from contributions from outside to increased publicity (cf. Bonaccorsi & Rossi, 2004). At the same time they can safeguard their position as manufacturers selling their product both to the community and the market. Firms in industries such as consumer electronics, telecommunication and IT hardware in particular may face opportunities for value capture from incorporating open source business models. Potentially they possess even more opportunities than firms in IT software as one might suspect. In this point, I agree with Shah (2005, p.12) that “building a business model around freely-revealed user innovations is more straightforward when the product is physical rather than virtual”. The different aspects and degrees of openness yield a complex strategy space in which companies can position them. Thus they retain means of value capture and differentiation from competitors. “This is just a matter of time. Electronics will follow the way PCs took 25 years ago over the next couple of years. [...] Hardware specialists who cannot afford huge investment in software will build standard-compliant hardware.” (Neuros OSD, Core team member)

12.3

Implications for future research

During my study I experienced a lack of theoretical research on openness, which leaves opportunities for future research. In addition my broad empirical research at the beginning of my work led to a number of assumptions, indications, and questions. Many of them have been treated in more detail later, but some of them are still uncovered and show the need and potential for further research after this very early work on the topic of open design. In my first empirical study, I investigate a wide-ranging database of open design projects, with the goal of exploring the landscape of open source development in the world of atoms, analyzing project characteristics, structures, and success, and revealing similarities and dissimilarities to open source software development. This comprehensive overview of practical examples points out the recent upsurge of cases and may function as a thorough empirical base for further research. In coming years, if and when practical applications of open design proliferate, quantitative empirical study will be facilitated. For the purpose of this study I treat openness as a product characteristic, but one could also argue that openness should be treated as a process char-

148

Chapter 12. Conclusions

acteristic. The open source mode of product development has been identified as a disruptive process innovation (e.g. von Krogh & von Hippel, 2003a). A sophisticated examination of the context of openness as a process characteristic, its dimensions and aspects, as well as its relevance for communities, seems strongly desirable in my view. In my work, I only slightly treat topics concerning environmental factors, as the industries and countries projects stem from. Obviously the meaning of openness might show different facets across industries and cultural backgrounds might influence perceptions of openness. In addition, available tools for communication and (co-)development further could have an impact on potential strategies towards open parts and party open solutions. Further research in this area might lead to additional insights on openness and appears therefore highly warranted. I hope that my work helps to disclose business opportunities in the realm of open design and to stimulate further research on openness in this context.

Part VI Appendices

Appendix A Variable explanations (1) Contributing actors • User Contribution - Specifies whether private persons are actively involved in the development • Commercial Contribution - Specifies whether commercial companies are actively involved • Research contribution - Specifies whether research institutions are actively involved (1) Developers The approximate number of developers actively contributing to this project. (2) Product complexity The estimated degree of complexity for the developed product ranging from low complexity, e.g. a simple wooden chair, to high complexity, as for example an aircraft or a nuclear power plant. (3) License Indicates if the project is using an open license and specifies the type, including a mark whether they have a registered trademark. (3) Degree of openness • Software - Software and other non-physical, i.e. content parts, are open source. K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

152

Appendix A. Variable explanations

• Interfaces - Hardware specifications and interfaces are laid open. • Schematics - Mechanical parts, descriptions, PCBs, etc. are freely available. • Case design - If applicable the case design is available, e.g. as CAD for download. • Entirely open - The project is revealing all relevant information. (4) Development driver Specifies the main drivers of the development, i.e. the group(s) of people pushing forward the project. Related company or association refers to a company closely related to the project, for example the investing company. (4) Production Specifies the group(s) of people responsible for producing the product. Related company or association refers to a company closely related to the project or a company with an exclusive production mandate. “Outsourced” is checked whenever an external party is paid for taking over the production. (4) Activity The activity level in the community or developer group from low (up to one interaction per month on average) to high (daily interaction). (5) Development status • 1 - Planning/Virtual development - Ideas and digital development evolving • 2 - Prototyping started - First physical prototypes assembled, testing phase • 3 - First working prototypes - Working prototypes available, release to community, further development needed • 4 - Production stable - Fully functional product permanently available on market, further development possible • 5 - Mature - Final development stage reached, no further development necessary

Appendix A. Variable explanations

153

(5) Intended audience • End user - Everybody from school kids to your grandmother. • Advanced end user - Product will target end users, but usage may require specific knowledge. • Developer - No intention to reach end users, high specific knowledge necessary. (5) Product innovativeness • Radical innovation - a new technology that results in a new market infrastructure, e.g., an innovation which does not address a recognized demand but instead creates a demand previously unrecognized by the consumer • Really new innovation - a really new product results in a market discontinuity or a technological discontinuity but will not incorporate both, e.g., new product lines, product line extensions with new technology, or new markets with existing technology • Discontinuous innovations - new technologies that don’t lead to discontinuity in existing markets • Incremental innovations - products that provide new features, benefits, or improvements to the existing technology in the existing market • Imitative innovations - imitative products are frequently new to the firm, but not new to the market (6) Means of communication • Face-to-face - Participants frequently interact in person • Mailing lists - At least one mailing list is used frequently • Chat - The community has at least one active chat • Board - A board/discussion forum is used • Other - Other communication channels as wikis, blogs, etc. have been established

Appendix B Details – Case study B.1

Interview guideline

Introduction: Our research on OSI Coordination: Hierarchization of the bazaar? Different roles within the project • From your experience in this project, do you think is it important to have one leader driving the OSI project? If so, which roles and activities should he perform? • Which roles do the other members of the core team of your project typically play? Do core team members mostly choose the activities/roles they want to perform, or are they usually assigned tasks/roles/responsibilities? If the latter, how (e.g. based on specific competencies or inclination)? • Have you observed tendencies and/or elements of hierarchical decision making in your OSI project? If so, in which contexts in particular? What decision authority does the project leader have, compared to the core team and to other members? • Why, in your opinion, are such hierarchical elements being introduced and used? How does this compare to OS software projects? Are there systematic differences related to the fact that you are developing a physical object? • Are there other important roles, functions, or activities carried out by one specific member? K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

156

Appendix B. Details – Case study

Process management • Looking at your project, has a pre-defined project timeline been installed? If so, who developed it and how (mutual agreement or given)? • Do you manage to stick to this plan? How? • How do you decide to freeze a design and start production? • Do you think the management of the development process of your project differs significantly from OSS projects? Why/ why not?

Coordination: Network elements • How was the core team formed? Did core team members mostly know each other personally at the outset of the project, or did they ‘meet’ in the virtual world? How does this affect their collaboration during the project? • Are there fundamental premises or norms on which the core-team bases all their decisions, particularly premises or norms closely related to the identities of the team members? • Has the organization (e.g. task distribution, roles, decision making process) of the core team changed significantly over time? If yes, why and how? • Is it necessary or advisable for the core team (or even for all principal contributors) to meet in person? If so, at which stages of development and for what major purpose?

Coordination: Market elements • Do you outsource some parts of development? Of production? How? • If applicable, which measures are required specifically to meet investors’ expectations? (Who bears the cost of development and production? Why?) • How do you use licenses and/or patents to attract contributors to the project while also protecting the interests of investors?

Appendix B. Details – Case study

157

Result • On a scale from 1 to 5, how complex is your design? (1: very simple, 5: very complex) What is the nature of the complexity in your case? • If you think of the final product you develop, how innovative is it compared to existing solutions? • Do the goals that were defined at the outset of the project still stand, or were they revised over the course of the project? If the latter, in what way?

Optional • Which were the main challenges you faced up until now? • Which specific problems do you encounter during this development process due to the fact that you are developing a tangible product, not ”merely” code?

Closing Thanks etc.

B.2

List of interviews

158

Openmoko (1) (2) (3) (4) (5) (6) RepRap (1) (2) (3) (4) (5) (6) Neuros (1) (2) (3) (4) (5) OSGV (1) (2) (3) (4) OScar (1) (2) (3) FreeBeer (1) (2) (3)

Appendix B. Details – Case study

Interview type

Length

Chat Chat Chat Chat Phone Phone

2h 30min 1h 30min 1h 10min 40min 45min 40min

Forum Chat Email Phone Phone Phone

Project founder

Project leader

Core team

Developer X X

X X X X

X X X

45min 20min 20min 30min

X X X X X

Chat Email Phone Phone Forum

35min

Phone Phone Phone Email

1h 1h 10min 45min

Phone Phone Phone

34min 1h 10min 35min

X

Phone Phone Phone

20min 30min 20min

X X

X X X

50min 1h 20min

X

X

X

X

X X

X X

X

X X X X X

Table B.1: List of interviews

X X X

Appendix C Details – Survey C.1

Questionnaire: How open is open source - software and beyond

Questionnaire for online survey among developers in open design communities, comments in italic. Except otherwise as noted, the employed scale was a 5-point Likert scale with the categories: Strongly disagree, Disagree, Neutral, Agree, Strongly agree, and No answer A progress bar was shown on every page.

Welcome to my survey and thank you for your interest! I’m Kerstin Balka and conducting this survey as part of my research project (link) and The OSI project (link) at TUHH, Hamburg University of Technology. We sincerely thank you for participating in this survey and thereby helping us to research the meaning and importance of openness in the area of open source software and beyond software. Please base all answers on your personal point of view and your concrete experience in one particular open source project, which you specify at the beginning of the survey. Please answer as many questions here as possible. There are 27 questions in this survey, pre-tests showed that filling the survey takes approx. 5-7 minutes. All data will be collected anonymously. K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

160

Appendix C. Details – Survey

Your project All answers shall be based on your personal point of view and your concrete experience in one particular open source project. • Q0: Please name the project for which you’re filling out this survey. Drop down menu and notify option for missing projects

Your involvement in the project This section contains questions about your personal relation to the project or the community. Source: Bruner, James, and Hensel (2005); N. J. Allen and Meyer (1990); Mowday et al. (1979); Westbrook and Oliver (1981); von Krogh et al. (2008) • Q4.0: I enjoy being part of this community. • Q4.1: My involvement in the community has a special meaning to me. • Q4.2: I really care about the fate of the project. • Q4.3: Sometimes I have mixed feelings about continuing with my contributions. (reverse) • Q4.4: On average how many hours per week are you currently active in the project community? • Q4.5: How long have you been active in the project? (please specify number of months) • Q4.6: How would you describe your position in the project? Scale: Project leader, Core team, Community, End user, Other

Availability of information The questions on this page are about the amount and quality of available information, e.g., source code, hardware schematics, etc. Construct: Transparency Source: West and O’Mahony (2008); Interviews • Q1.1a: I have complete access to the projects’ internal documentation. Remark: Please fill out for software and hardware. Software (source code)

Appendix C. Details – Survey

161

Hardware (interfaces, schematics, etc.) Helptext: This question is about the availability of information developed in the community, by the core team, or by the hosting firm. • Q1.1b: I have complete access to third parties’ documentation. Software (source code) Hardware (interfaces, schematics, etc.) Helptext: This question is about the availability of information about components from external parties, e.g., a supplier of components. • Q1.2: It is easy to gain access to the available information. Software source code Hardware documentation Helptext: Strongly agree could mean “available on a public website”, strongly disagree would be “very painful to gain access” • Q1.3: The provided information is useful. Software source code easy-to-read Hardware documentation well written • Q1.4: It is sometimes difficult to contribute due to missing information. (reverse) Software Hardware • Q1.5: The amount of available information and its quality is important to me. Software Hardware • Q1.6: Based on your previous experience, to what extent does the amount and quality of available information meet your expectations? Scale: 0 − 25%, 25 − 50%, 50 − 75%, 75 − 100%, > 100%, No answer Software Hardware Helptext: If the reality exceeds your expectations, please pick > 100%.

162

Appendix C. Details – Survey

Possibility of participating and exerting influence This section is about the role of the community concerning their possibility to contribute and actively influence the development. Construct: Accessibility Source: West and O’Mahony (2008); Interviews • Q2.1: Community members can publish patches or suggest small changes. Software Hardware • Q2.2: The community can significantly influence the development. Software Hardware • Q2.3: Contributions from the developer community are highly welcome to be included in official releases. Software Hardware • Q2.4: It is important to me that the developer community can actively participate and influence the development. Software Hardware • Q2.5: If you think of the extent to which you can participate and influence the development, to what degree does this meet your expectations? Scale: 0 − 100%, Exceeds expectations, No answer Software Hardware Helptext: If the reality exceeds your expectations, please pick > 100%.

Possibility for self-assembly This page contains questions about the possibility to self-produce the product. Construct: Replicability Source: Interviews

Appendix C. Details – Survey

163

• Q3.1: One can self-assemble and -produce all open components of the product. Software components Hardware components • Q3.2: One can obtain all closed components of the product. Software components Hardware components Helptext: e.g., they are available for download or purchase • Q3.4: The possibility for self-assembly is important to me. Software Hardware • Q3.5: Based on your personal experience, to what degree does the possibility for self-assembly meet your expectations? Scale: 0 − 100%, Exceeds expectations, No answer Software Hardware Helptext: If the reality exceeds your expectations, please pick > 100%.

General questions The core questionnaire is done now, however we would be very grateful if you could tell us some more facts about yourself. • Q5.1: How old are you? • Q5.2: Your gender is Female Male • Q5.3: Highest educational degree High school or less Bachelor degree or some college Master’s or diploma degree PhD degree or doctorate • Q5.4: Space to enter comments, feedback, and additional information

164

Appendix C. Details – Survey

Thank you for your participation! For questions or feedback, please contact me here (Link).

C.2

Survey results

4 variables on satisfaction, 10 variables on openness for software and hardware respectively Q4.0 n 308

Missing 1

1 Frequency 9 % 3

Q4.1 n 305

Unique 4

Mean 4.38

2 3 4 5 0 20 115 164 0 6 37 53

Missing 4

Unique 5

n 305

Missing 4

Unique 5

Mean 3.925

n 293

Missing 16

Unique 5

Mean 4.446

n 290

Missing 19

Unique 5

Mean 2.724

n 261

Missing 48

Unique 5

1 2 3 4 5 Frequency 22 48 77 79 35 % 8 18 30 30 13

Mean 3.934

Q1.3 HW n 244

Missing 65

Unique 5

Mean 3.906

Q1.4 HW n 234

Missing 75

Unique 5

Mean 3.009

Q2.1 HW n 259

Missing 50

Unique 5

Mean 4.012

1 2 3 4 5 Frequency 11 11 38 103 96 % 4 4 15 40 37

Mean 4.186

1 2 3 4 5 Frequency 9 20 30 80 151 % 3 7 10 28 52

Q1.1b HW

Unique 5

1 2 3 4 5 Frequency 12 67 76 65 14 % 5 29 32 28 6

1 2 3 4 5 Frequency 34 103 81 60 15 % 12 35 28 20 5

Q1.1a HW

Missing 20

1 2 3 4 5 Frequency 5 10 55 107 67 % 2 4 23 44 27

1 2 3 4 5 Frequency 5 2 18 107 173 % 2 1 6 35 57

Q4.3

n 289

1 2 3 4 5 Frequency 18 13 43 111 104 % 6 4 15 38 36

1 2 3 4 5 Frequency 5 12 72 128 88 % 2 4 24 42 29

Q4.2

Q1.2 HW

Q2.2 HW n 266

Missing 43

Unique 5

Mean 3.959

1 2 3 4 5 Frequency 4 22 57 81 102 % 2 8 21 30 38

Mean 3.218

Q2.3 HW n 235

Missing 74

Unique 5

1 2 3 4 5 Frequency 8 11 58 80 78 % 3 5 25 34 33

Mean 3.889

Appendix C. Details – Survey Q3.1 HW n 254

Missing 55

Unique 5

Mean 3.323

1 2 3 4 5 Frequency 35 43 51 55 70 % 14 17 20 22 28

Q3.2 HW n 220

Missing 89

Unique 5

n 303

Missing 6

Unique 5

Mean 3.418

n 271

Missing 38

Unique 5

Mean 4.419

n 302

Missing 7

Unique 5

Mean 3.513

n 271

Missing 38

Unique 5

Unique 5

Mean 2.989

Q2.1 SW n 289

Missing 20

Unique 5

Mean 4.478

Q2.2 SW n 290

Missing 19

Unique 5

Mean 4.41

Q2.3 SW n 276

Missing 33

Unique 5

Mean 4.359

1 2 3 4 5 Frequency 2 9 23 96 146 % 1 3 8 35 53

Mean 4.152

Q3.1 SW n 280

Missing 29

Unique 5

Mean 4.396

1 2 3 4 5 Frequency 3 10 23 81 163 % 1 4 8 29 58

1 2 3 4 5 Frequency 9 14 33 112 134 % 3 5 11 37 44

Q1.3 SW

Missing 33

1 2 3 4 5 Frequency 3 8 28 79 172 % 1 3 10 27 59

1 2 3 4 5 Frequency 14 39 68 94 56 % 5 14 25 35 21

Q1.2 SW

n 276

1 2 3 4 5 Frequency 2 4 18 95 170 % 1 1 6 33 59

1 2 3 4 5 Frequency 5 12 19 82 185 % 2 4 6 27 61

Q1.1b SW

Q1.4 SW

1 2 3 4 5 Frequency 19 81 71 94 11 % 7 29 26 34 4

1 2 3 4 5 Frequency 23 38 42 58 59 % 10 17 19 26 27

Q1.1a SW

165

Mean 3.934

Q3.2 SW n 216

Missing 93

Unique 5

Mean 3.852

1 2 3 4 5 Frequency 12 24 35 58 87 % 6 11 16 27 40

1 2 3 4 5 Frequency 3 12 52 137 67 % 1 4 19 51 25

3 variables on importance, 3 variables on expectations Q1.5 - T.HW.Importance

Q2.4 - A.HW.Importance

1 2 3 4 5 Frequency 2 2 22 85 128 % 1 1 9 36 54

1 2 3 4 5 Frequency 1 4 19 91 116 % 0 2 8 39 50

n 239

Missing 31

Unique 5

Mean 4.402

n 231

Missing 39

Unique 5

Mean 4.372

Q1.6 - T.HW.Expect

Q2.5 - A.HW.Expect

1 2 3 4 5 Frequency 4 18 52 112 29 % 2 8 24 52 13

1 2 3 4 5 Frequency 14 20 42 85 32 % 7 10 22 44 17

n 215

Missing 55

Unique 5

Mean 3.67

n 193

Missing 77

Unique 5

Mean 3.523

166

Appendix C. Details – Survey

Q3.4 - R.HW.Importance

Q2.4 - A.SW.Importance

1 2 3 4 5 Frequency 18 38 54 57 70 % 8 16 23 24 30

1 2 3 4 5 Frequency 1 2 10 75 165 % 0 1 4 30 65

n 237

Missing 33

Unique 5

Mean 3.519

n 253

Missing 17

Unique 5

Mean 4.585

Q3.5 - R.HW.Expect

Q2.5 - A.SW.Expect

1 2 3 4 5 Frequency 14 23 39 93 30 % 7 12 20 47 15

1 2 3 4 5 Frequency 7 9 42 130 41 % 3 4 18 57 18

n 199

Missing 71

Unique 5

Mean 3.513

n 229

Missing 41

Unique 5

Mean 3.825

Q1.5 - T.SW.Importance

Q3.4 - R.SW.Importance

1 Frequency 0 % 0

1 2 3 4 5 Frequency 5 12 35 73 125 % 2 5 14 29 50

n 259

Missing 11

Unique 4

Mean 4.525

2 3 4 5 1 16 88 154 0 6 34 59

Q1.6 - T.SW.Expect n 245

Missing 25

Unique 5

Mean 3.629

1 2 3 4 5 Frequency 4 16 67 138 20 % 2 7 27 56 8

n 250

Missing 20

Unique 5

Mean 4.204

Q3.5 - R.SW.Expect n 230

Missing 40

Unique 5

Mean 3.878

1 2 3 4 5 Frequency 5 13 41 117 54 % 2 6 18 51 23

3 variables on participation, 3 demographical variables Q4.4 - Weekly activity n 302 Min 0

Missing Mean Standard dev. 7 8.443 10.77 Q1 Median Q3 Max 2 5 10 70

Q4.5 - Duration of activity n 304 Min 0

Missing Mean Standard dev. 5 14.89 13.58 Q1 Median Q3 Max 6 12 18 84

Q5.1 - Age n 290 Min 14

Missing Mean Standard dev. 19 32.34 10.58 Q1 Median Q3 Max 25 29 39 70

Q5.2 - Gender n Missing 286 23 Female: 8, 3% Male: 278, 97%

Q4.6 - Position

Q5.3 - Education

n Missing 296 13 Project leader: 9, 3% Core team: 25, 9% Community: 161, 54% End user: 101, 34%

n Missing 284 25 High school or less: 43, 15% Bachelor degree or some college: 133, 47% Master’s or diploma degree: 91, 32% PhD degree or doctorate: 17, 6%

C.3

Stability tests

Table C.1 shows exemplary results from stability tests on the hypotheses H1, H2, and H3, conducted via successively excluding the three projects with the greatest number of respondents from my sample. For H1 and H3, I present means of differences between software and hardware together with their significance rating; for H2, I present means of differences to “Neutral” (3).

Appendix C. Details – Survey

H1

H2

H3

T A R T A R T A R

Total sample 0.18∗∗∗ 0.51∗∗∗ 0.88∗∗∗ 1.47∗∗∗ 1.51∗∗∗ 0.91∗∗∗ 0.12∗∗ 0.22∗∗∗ 0.67∗∗∗

167

Excluded community Openmoko Gp2x RepRap 0.17∗∗∗ 0.18∗∗∗ 0.20∗∗∗ ∗∗∗ 0.52 0.51∗∗∗ 0.55∗∗∗ ∗∗∗ 0.66 0.88∗∗∗ 0.93∗∗∗ ∗∗∗ 1.46 1.46∗∗∗ 1.46∗∗∗ ∗∗∗ 1.47 1.51∗∗∗ 1.51∗∗∗ ∗∗∗ 0.95 0.88∗∗∗ 0.82∗∗∗ + 0.07 0.12∗∗ 0.15∗∗∗ ∗∗∗ ∗∗∗ 0.19 0.22 0.24∗∗∗ ∗∗∗ ∗∗∗ 0.42 0.67 0.75∗∗∗

Table C.1: Exemplary results from stability tests

Appendix D Alternative models D.1

More ordinary linear models

The impact of openness on satisfaction for software and hardware Expanding model 10.1 to include both openness of software and hardware results in: S = β0 + βSW O.SW + βHW O.HW +  Residuals: Min 1Q -2.63038 -0.30854

Median 0.01644

3Q 0.43236

(D.1)

Max 1.24331

Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept) 2.36725 0.24036 9.849 < 2e-16 *** O.SW 0.41242 0.07141 5.775 1.89e-08 *** O.HW -0.01445 0.05488 -0.263 0.793 Residual standard error: 0.6089 on 306 degrees of freedom Multiple R-squared: 0.1377, Adjusted R-squared: 0.1321 F-statistic: 24.44 on 2 and 306 DF, p-value: 1.427e-10

This model shows a strongly significant positive impact of openness of software on satisfaction, but it does not show an impact of openness of hardware. Plots of residuals look similar to Figure 10.1. K. Balka, Open Source Product Development, DOI 10.1007/978-3-8349-6949-1, © Gabler Verlag | Springer Fachmedien Wiesbaden GmbH 2011

170

Appendix D. Alternative models

How do transparency, accessibility, and replicability impact satisfaction? To further investigate the impact of openness on satisfaction, I want to look at the influence of the constructs transparency, accessibility, and replicability by forming the model: S = β0 + βT T + βA A + βR R + 

(D.2)

Estimating the coefficients results in: Residuals: Min 1Q -2.74701 -0.34569

Median 0.04644

3Q 0.44713

Max 1.18305

Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept) 2.38639 0.24385 9.786 < 2e-16 *** T 0.12084 0.06013 2.010 0.045350 * A 0.20788 0.05497 3.782 0.000187 *** R 0.08039 0.04533 1.773 0.077155 . Residual standard error: 0.6122 on 305 degrees of freedom Multiple R-squared: 0.1314, Adjusted R-squared: 0.1228 F-statistic: 15.38 on 3 and 305 DF, p-value: 2.432e-09 All three constructs show a positive impact on satisfaction - βT = 0.13, βA = 0.21, and βR = 0.08 - at fairly high significance levels. The model fit R2 is with 14.3% satisfactory as well as the F-statistic with 15.6 both indicating high goodness of fit. Again all diagnostic plots reveal satisfactory results apart from the same indication as before that the residuals are not entirely normally distributed. In addition I want to examine the influence of the constructs separated for hardware and software and obtain for software: S = β0 + βT T.SW + βA A.SW + βR R.SW +  Residuals: Min 1Q -2.65465 -0.33019

Median 0.04017

3Q 0.39864

Max 1.26637

Coefficients: Estimate Std. Error t value Pr(>|t|)

(D.3)

Appendix D. Alternative models (Intercept) T.SW A.SW R.SW

2.13990 0.13512 0.21229 0.10063

0.26039 0.05676 0.05874 0.04677

171 8.218 2.381 3.614 2.152

5.98e-15 0.017897 0.000352 0.032197

*** * *** *

Residual standard error: 0.6059 on 305 degrees of freedom Multiple R-squared: 0.149, Adjusted R-squared: 0.1406 F-statistic: 17.8 on 3 and 305 DF, p-value: 1.128e-10 And for hardware: S = β0 + βT T.HW + βA A.HW + βR R.HW +  Residuals: Min 1Q -2.6779 -0.3482

Median 0.0446

3Q 0.4304

(D.4)

Max 1.1819

Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept) 3.28441 0.19201 17.105 <2e-16 *** T.HW 0.08231 0.05587 1.473 0.1417 A.HW 0.07431 0.04481 1.659 0.0982 . R.HW 0.04227 0.03682 1.148 0.2518 Residual standard error: 0.641 on 305 degrees of freedom Multiple R-squared: 0.04776, Adjusted R-squared: 0.03839 F-statistic: 5.099 on 3 and 305 DF, p-value: 0.001859

D.2

Details for selected multilevel models

Calculation output for model 10.5: > summary(model2a <- lme(S ~ T.SW + A.SW + R.SW, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 568.5823 590.9823 -278.2911 Random effects: Formula: ~1 | Community (Intercept) Residual

172 StdDev:

Appendix D. Alternative models 0.1777928 0.5812267

Fixed effects: S ~ T.SW + A.SW + Value Std.Error (Intercept) 2.1705650 0.26155311 T.SW 0.1399038 0.05671322 A.SW 0.2223854 0.06037804 R.SW 0.0862619 0.04594307

R.SW DF t-value p-value 286 8.298754 0.0000 286 2.466864 0.0142 286 3.683216 0.0003 286 1.877582 0.0615

Standardized Within-Group Residuals: Min Q1 Med Q3 -4.44062857 -0.53915885 0.08641088 0.60175301

1 −2

−1

0

Estimates residuals

1 0 −1 −2

Estimated random intercepts

2

Residuals

2

Random intercepts

Max 2.12966065

−3

−2

−1

0

1

2

Theoretical Quantiles

3

−3

−2

−1

0

1

2

3

Theoretical Quantiles

Figure D.1: Normal distribution checks for model 10.5

Calculation output for model 10.6: > summary(model2b <- lme(S ~ T.HW + A.HW + R.HW, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 600.7785 623.1786 -294.3893 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.2630100 0.6045033

Appendix D. Alternative models

173

Fixed effects: S ~ T.HW + A.HW + R.HW Value Std.Error DF t-value p-value (Intercept) 3.167714 0.21919625 286 14.451495 0.0000 T.HW 0.092747 0.05787879 286 1.602436 0.1102 A.HW 0.083945 0.04746818 286 1.768441 0.0781 R.HW 0.054881 0.03946643 286 1.390578 0.1654 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.98513906 -0.56390973 0.09873817 0.67373540

Max 1.97868287

Calculation output for model 10.7: > summary(model2c <- lme(S ~ T.SW + A.SW + R.SW + T.HW + A.HW + R.HW, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 574.22 607.82 -278.11 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.1727955 0.5814064 Fixed effects: S ~ T.SW + A.SW + R.SW + T.HW + A.HW + R.HW Value Std.Error DF t-value p-value (Intercept) 2.1708489 0.26712172 283 8.126815 0.0000 T.SW 0.1417149 0.06824183 283 2.076658 0.0387 A.SW 0.2459459 0.07207051 283 3.412573 0.0007 R.SW 0.0820970 0.05208901 283 1.576090 0.1161 T.HW 0.0028650 0.06504501 283 0.044046 0.9649 A.HW -0.0307746 0.05289298 283 -0.581827 0.5611 R.HW 0.0040502 0.04197826 283 0.096483 0.9232 Standardized Within-Group Residuals: Min Q1 Med Q3 -4.4246281 -0.5423348 0.0927420 0.6175399

D.3

Max 2.1291867

Transformations to normality

In this section I transform both the response variable and the predictor variables using the Box-Cox method, which aims to find a transformation that makes the transformed variable close to normally distributed (Box & Cox,

174

Appendix D. Alternative models

1964; Sheather, 2009). For this purpose, I use the R function bctrans. Subsequent I build linear multilevel models from the transformed data using lme in the same manner is in Section 10.2. > summary(tranxy <- bctrans(~ S + O)) box.cox Transformations to Multinormality Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.5202 0.2729 9.2338 5.5700 2.6785 0.3066 8.7361 5.4746 LRT df p.value LR test, all lambda equal 0 221.51513 2 0.000000e+00 LR test, all lambda equal 1 72.01999 2 2.220446e-16 S O

> summary(model.t1 <- lme(S ~ O, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1829.698 1844.632 -910.8492 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 1.679891 4.47015 Fixed effects: S ~ O Value Std.Error DF t-value p-value (Intercept) 9.028203 0.8666801 288 10.41700 0 O 0.307839 0.0490839 288 6.27169 0 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.01000428 -0.69640423 0.01691708 0.63320295

Max 2.27151297

> summary(tranxy <- bctrans(~ S + O.SW + O.HW)) box.cox Transformations to Multinormality Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.5193 0.2731 9.2251 5.5634 2.9226 0.3243 9.0122 5.9285 1.9142 0.2146 8.9211 4.2606 LRT df p.value LR test, all lambda equal 0 339.73160 3 0 S O.SW O.HW

Appendix D. Alternative models LR test, all lambda equal 1

97.66406

175 3

0

> summary(model.t1a <- lme(S ~ O.SW + O.HW, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1825.274 1843.941 -907.637 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 1.636564 4.4266 Fixed effects: S ~ O.SW + O.HW Value Std.Error DF t-value p-value (Intercept) 8.880312 0.9134480 287 9.721748 0.0000 O.SW 0.218425 0.0403142 287 5.418079 0.0000 O.HW -0.012934 0.1474643 287 -0.087706 0.9302 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.23532890 -0.65906062 -0.03954721 0.64538184

Max 2.35444483

> summary(tranxy <- bctrans(~ S + T + A + R)) box.cox Transformations to Multinormality Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.5211 0.2735 9.2189 5.5621 2.2420 0.2360 9.5009 5.2633 2.7077 0.3022 8.9611 5.6516 1.7599 0.2021 8.7098 3.7609 LRT df p.value LR test, all lambda equal 0 442.8980 4 0 LR test, all lambda equal 1 120.2971 4 0 S T A R

> summary(model.t2 <- lme(S ~ T + A + R, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1829.708 1852.108 -908.8538 Random effects:

176

Appendix D. Alternative models

Formula: ~1 | Community (Intercept) Residual StdDev: 1.546036 4.454156 Fixed effects: S ~ T Value (Intercept) 7.726045 T 0.274918 A 0.141588 R 0.163405

+ A + R Std.Error 1.0046172 0.0967102 0.0405020 0.1318245

DF 286 286 286 286

t-value p-value 7.690536 0.0000 2.842701 0.0048 3.495813 0.0005 1.239568 0.2162

Standardized Within-Group Residuals: Min Q1 Med Q3 -3.22534581 -0.69102850 -0.02234616 0.66824307

Max 2.41447554

> summary(tranxy <- bctrans(~ S + T.SW + A.SW + R.SW)) box.cox Transformations to Multinormality Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.4972 0.2712 9.2098 5.5218 1.8342 0.1765 10.3935 4.7269 3.8506 0.3945 9.7613 7.2263 2.8308 0.2683 10.5514 6.8241 LRT df p.value LR test, all lambda equal 0 1139.8845 4 0 LR test, all lambda equal 1 207.9367 4 0 S T.SW A.SW R.SW

> summary(model.t2a <- lme(S ~ T.SW + A.SW + R.SW, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1803.313 1825.713 -895.6565 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 1.517215 4.264184 Fixed effects: S ~ T.SW + A.SW Value Std.Error (Intercept) 7.474810 0.9373741 T.SW 0.417090 0.1388562 A.SW 0.028193 0.0077128

+ R.SW DF t-value p-value 286 7.974202 0.0000 286 3.003754 0.0029 286 3.655380 0.0003

Appendix D. Alternative models R.SW

177

0.044869 0.0281434 286 1.594286

0.1120

Standardized Within-Group Residuals: Min Q1 Med Q3 -3.18291849 -0.62562585 -0.04212311 0.59450759

Max 2.36009061

> summary(tranxy <- bctrans(~ S + T.HW + A.HW + R.HW)) box.cox Transformations to Multinormality Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.5293 0.2781 9.0962 5.4999 2.1400 0.1993 10.7392 5.7209 2.0318 0.1897 10.7118 5.4397 1.1735 0.1348 8.7048 1.2872 LRT df p.value LR test, all lambda equal 0 551.1723 4 0 LR test, all lambda equal 1 113.4204 4 0 S T.HW A.HW R.HW

> summary(model.t2b <- lme(S ~ T.HW + A.HW + R.HW, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1860.141 1882.541 -924.0707 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 1.906674 4.649941 Fixed effects: S ~ T.HW + A.HW Value Std.Error (Intercept) 9.826506 1.0395560 T.HW 0.207533 0.1105182 A.HW 0.194203 0.0950904 R.HW 0.276325 0.2504817

+ R.HW DF t-value p-value 286 9.452599 0.0000 286 1.877815 0.0614 286 2.042301 0.0420 286 1.103174 0.2709

Standardized Within-Group Residuals: Min Q1 Med Q3 -2.80313975 -0.68450839 -0.01496897 0.66664477

Max 2.34000670

> summary(tranxy <- bctrans(~ S + T.SW + A.SW + R.SW + T.HW + A.HW + R.HW)) box.cox Transformations to Multinormality

178

Appendix D. Alternative models

Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.5027 0.2716 9.2131 5.5319 1.8472 0.1619 11.4127 5.2343 4.0955 0.3679 11.1331 8.4148 2.6324 0.2581 10.2000 6.3252 2.1346 0.1917 11.1344 5.9182 2.2431 0.1788 12.5431 6.9513 1.2183 0.1300 9.3735 1.6795 LRT df p.value LR test, all lambda equal 0 1729.2181 7 0 LR test, all lambda equal 1 328.2211 7 0 S T.SW A.SW R.SW T.HW A.HW R.HW

> summary(model.t2c <- lme(S ~ T.SW + A.SW + R.SW + T.HW + A.HW + R.HW, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1813.849 1847.449 -897.9243 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 1.520902 4.296376 Fixed effects: S ~ T.SW + A.SW + R.SW + T.HW + A.HW + R.HW Value Std.Error DF t-value p-value (Intercept) 7.608262 1.0129274 283 7.511162 0.0000 T.SW 0.405948 0.1624690 283 2.498616 0.0130 A.SW 0.021244 0.0069889 283 3.039726 0.0026 R.SW 0.057345 0.0423713 283 1.353382 0.1770 T.HW 0.013071 0.1201747 283 0.108769 0.9135 A.HW -0.028084 0.0843048 283 -0.333127 0.7393 R.HW 0.018841 0.2458292 283 0.076644 0.9390 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.23272611 -0.63615432 -0.01456647 0.59634450

Max 2.37087116

> summary(tranxy <- bctrans(~ S + T.SW + A.SW + R.SW + O.HW)) box.cox Transformations to Multinormality

S

Est.Power Std.Err. Wald(Power=0) Wald(Power=1) 2.4964 0.2711 9.2084 5.5196

Appendix D. Alternative models T.SW A.SW R.SW O.HW

1.8105 3.8271 2.8214 1.8346

179

0.1697 0.3909 0.2676 0.2152

10.6689 4.7760 9.7896 7.2316 10.5415 6.8053 8.5251 3.8782 LRT df p.value LR test, all lambda equal 0 1259.4157 5 0 LR test, all lambda equal 1 222.9906 5 0 > summary(model.t3 <- lme(S ~ T.SW + A.SW + R.SW + O.HW, random = ~1|Community, method=’ML’, data=trans)) Linear mixed-effects model fit by maximum likelihood Data: trans AIC BIC logLik 1804.384 1830.517 -895.192 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 1.515081 4.257765 Fixed effects: S ~ T.SW + A.SW + R.SW + O.HW Value Std.Error DF t-value p-value (Intercept) 7.536220 0.9740406 285 7.737070 0.0000 T.SW 0.449154 0.1513036 285 2.968560 0.0032 A.SW 0.030177 0.0084041 285 3.590801 0.0004 R.SW 0.047947 0.0292435 285 1.639593 0.1022 O.HW -0.062629 0.1573332 285 -0.398069 0.6909 Standardized Within-Group Residuals: Min Q1 Med Q3 -3.18824526 -0.62668275 -0.04348871 0.62031113

D.4

Max 2.35522966

Models considering expectations

Additional constructs have been calculated as arithmetic means: T.SW.Expect + A.SW.Expect + R.SW.Expect 3 T.HW.Expect + A.HW.Expect + R.HW.Expect O.HW.Expect = 3 (D.5) O.SW.Expect =

180

Appendix D. Alternative models

More formally, the model discussed in Section 10.3 is designed as: Sij = β0 + βT.SW T.SWij + βA.SW A.SWij + βR.SW R.SWij + βO.HW O.HWij + βT.SW.E T.SWij ∗ T.SW.Expect + βA.SW.E A.SWij ∗ A.SW.Expect + βR.SW.E R.SWij ∗ R.SW.Expect + βO.HW.E O.HWij ∗ O.HW.Expect + bi + i (D.6) Calculation results in: > summary(model.e <- update(model3, .~.+ T.SW:T.SW.Expect + A.SW:A.SW.Expect + R.SW:R.SW.Expect + O.HW:O.HW.Expect, random = ~1|Community, method=’ML’)) Linear mixed-effects model fit by maximum likelihood AIC BIC logLik 571.4198 612.4866 -274.7099 Random effects: Formula: ~1 | Community (Intercept) Residual StdDev: 0.1841279 0.5736404 Fixed effects: S ~ T.SW + A.SW + R.SW + O.HW + T.SW:T.SW.Expect + A.SW:A.SW.Expect + R.SW:R.SW.Expect + O.HW:O.HW.Expect Value Std.Error DF t-value p-value (Intercept) 2.2063302 0.31517463 281 7.000342 0.0000 T.SW 0.0670572 0.09800636 281 0.684213 0.4944 A.SW 0.2997026 0.08680482 281 3.452604 0.0006 R.SW -0.0106726 0.07581602 281 -0.140769 0.8882 O.HW 0.0734267 0.09410020 281 0.780303 0.4359 T.SW:T.SW.Expect 0.0159828 0.01540228 281 1.037692 0.3003 A.SW:A.SW.Expect -0.0150712 0.01194453 281 -1.261767 0.2081 R.SW:R.SW.Expect 0.0211887 0.01203333 281 1.760837 0.0794 O.HW:O.HW.Expect -0.0207340 0.01546884 281 -1.340369 0.1812 Standardized Within-Group Residuals: Min Q1 Med Q3 -4.3138994 -0.5615524 0.1184453 0.6354691

Max 2.0938240

References Agerfalk, P. J., & Fitzgerald, B. (2008). Opensourcing to an unknown workforce: Exploring opensourcing as a global sourcing strategy. MIS Quarterly, 32 (2), 385-409. Allen, N. J., & Meyer, J. P. (1990). The measurement and antecedents of affective, continuance, and normative commitment to the organization. Journal of Occupational Psychology, 63 , 1-18. Allen, R. C. (1983). Collective invention. Journal of Economic Behavior and Organization, 4 , 1-24. Arrow, K. (1962). Economic welfare and the allocation of resources for inventions. In R. Nelson (Ed.), The rate and direction of economic activity. Princeton, NJ: Princeton University Press. Arundel, A. (2001). The relative effectiveness of patents and secrecy for appropriation. Research Policy, 30 (4), 611-624. Baldwin, C. Y. (2008). Where do transactions come from? Modularity, transactions, and the boundaries of firms. Industrial and Corporate Change, 17 (1), 155-195. Baldwin, C. Y., & Clark, K. B. (2000). Design rules, vol. 1: The power of modularity. Cambridge, MA: MIT Press. Baldwin, C. Y., & Clark, K. B. (2006). The architecture of participation: Does code architecture mitigate free riding in the open source development model? Management Science, 52 (7), 1116-1127. Baldwin, C. Y., Hienerth, C., & von Hippel, E. (2006). How user innovations become commercial products: A theoretical investigation and case study. Research Policy, 35 (9), 1291-1313.

182

References

Baldwin, C. Y., & von Hippel, E. (2009). Modeling a paradigm shift: From producer innovation to user and open collaborative innovation. Harvard Business School Working Paper , 10-038 . Barney, J. B. (1986). Strategic factor markets: Expectations, luck, and business strategy. Management Science, 32 (10), 1231-1241. Bates, D. M. Springer.

(Forthcoming).

lme4: Mixed-effects modeling with R.

Batinic, B., & Bosnjak, M. (2000). Fragebogenuntersuchungen im Internet. In Internet for psychologists (p. 287-317). Hogrefe. Bessen, J. (2006). Open source software: Free provision of complex public goods. In J. Bitzer & P. J. Schr¨oder (Eds.), The economics of open source software development (p. 57-81). Amsterdam, The Netherlands: Elsevier. Bhattacherjee, A. (2001). Understanding information systems continuance: An expectation-confirmation model. MIS Quarterly, 25 (3), 351-370. Bitzer, J. (2004). Commercial versus open source software: The role of product heterogeneity in competition. Economic Systems, 28 (4), 369-381. Blankman, E., Escousse, S., Schillak, A., Schmidt, L., & Slotnick, M. (2000). Oscar - the open source car project. NYU Stern. Bolton, R. N., & Lemon, K. N. (1999). A dynamic model of customers usage of services: Usage as an antecedent and consequence of satisfaction. Journal of Marketing Research, 36 , 171-186. Bonaccorsi, A., & Rossi, C. (2003). Why open source software can succeed. Research Policy, 32 (7), 1243-1258. Bonaccorsi, A., & Rossi, C. (2004). Altruistic individuals, selfish firms? The structure of motivation in open source software. First Monday, 9 (1). Bonaccorsi, A., Rossi, C., & Giannangeli, S. (2006). Adaptive entry strategies under dominant standards: Hybrid business models in the open source software industry. Management Science, 52 , 1085 - 1098. Box, G. E. P., & Cox, D. R. (1964). An analysis of transformations. Journal of the Royal Statistical Society. Series B (Methodological), 26 (2), 211–252. Bruner, G. C., James, K. E., & Hensel, P. j. (2005). Marketing scales handbook: A compilation of multi-item measures (Vol. 3).

References

183

Carr, N. (2007). The ignorance of crowds. Strategy & Business, 47 . Casadesus-Masanell, R., & Llanes, G. (2009). Mixed source. Harvard Business School Working Paper , 10-022 . Chesbrough, H. (2007). Business model innovation: It’s not just about technology anymore. Strategy & Leadership, 35 (6), 12-17. Chesbrough, H., & Appleyard, M. M. (2007). Open innovation and strategy. California Management Review , 50 (1), 57 - 76. Chesbrough, H., Vanhaverbeeke, W., & West, J. (2006). Open innovation - researching a new paradigm. Oxford: Oxford University Press. Colombo, S., Grilli, L., & Lamastra, C. R. (2010). On the determinants of the degree of openness of open source firms: An entry model. Universita Cattolica del Sacro Cuore, Dipartimenti e Istituti di Scienze Economiche (DISCE). Retrieved 19 April 2010, from http://ideas.repec.org/p/ctc/serie3/ief0088.html Comino, S., Manenti, F. M., & Parisi, M. L. (2007). From planning to mature: On the success of open source projects. Research Policy, 36 (10), 1575-1586. Crowston, K., & Scozzi, B. (2002). Open source software projects as virtual organizations: Competency rallying for software development. IEE Proceedings Software, 149 (1). Dahlander, L. (2005). Appropriation and appropriability in open source software. International Journal of Innovation Management, 9 (3), 259-285. Dahlander, L., & Gann, D. M. (2010). How open is innovation? Research Policy. Dahlander, L., & Magnusson, M. G. (2005). Relationships between open source software companies and communities: Observations from Nordic firms. Research Policy, 34 , 481-493. Dahlander, L., & Magnusson, M. G. (2006). Business models and community relationships of open source software firms. In J. Bitzer & P. J. Schr¨oder (Eds.), The economics of open source software development (p. 111 - 130). Amsterdam, The Netherlands: Elsevier. Dahlander, L., & Magnusson, M. G. (2008). How do firms make use of open source communities. Long Range Planning, 41 , 629-649.

184

References

Dahlander, L., & Wallin, M. W. (2006). A man on the inside: Unlocking communities as complementary assets. Research policy, 35 , 1243-1259. David, P. A., & Shapiro, J. S. (2008). Community-based production of opensource software: What do we know about the developers who participate? Information Economics and Policy, 20 (4), 364-398. Deci, E. L., & Ryan, R. M. (1985). Intrinisic motivation and selfdetermination in human behaviour. Plenum. de Laat, P. B. (2007). Governance of open source software: State of the art. Journal of management and governance, 11 , 165-177. Demil, B., & Lecocq, X. (2005). Neither market nor hierarchy or network: The emerging bazaar governance. Demsetz, H. (1967). Toward a theory of property rights. American Economic Review , 57 (2), 347-359. Denzin, N. K. (1970). The research act: A theoretical introduction to sociological methods. New York: Aldine. Dyer, J. H., & Singh, H. (1998). The relational view: Cooperative strategy and sources of interorganizational competitive advantage. Academy of Management Review , 23 (4), 660-679. Economist. (2004). An open source shot in the arm? The economist, June 10th. Edmondson, A. C., & McManus, S. E. (2007). Methodological fit in management field research. Academy of Management Review , 32 (4), 1155-1179. Eisenhardt, K. M. (1989). Building theories from case study research. Academy of Management Review , 14 (4), 532-550. Everitt, B., & Hothorn, T. (2006). A handbook of statistical analyses using R. Boca Raton, FL: Chapman & Hall/CRC. Faraway, J. J. (2006). Extending the linear model with R. Boca Raton, FL: Chapman & Hall/CRC. Feller, & Fitzgerald. (2002). Understanding open source software development. Boston: AddisonWesley.

References

185

Fershtman, C., & Gandal, N. (2004). The determinants of output per contributor in open source projects: An empirical examination. CEPR Discussion Papers(4329). Fleming, L., & Waguespack, D. M. (2007). Brokerage, boundary spanning, and leadership in open innovation communities. Organization Science, 18 (2), 165-180. Fosfuri, A., Giarratana, M. S., & Luzzi, A. (2008). The penguin has entered the building: The commercialization of open source software products. Organization Science, 19 (2), 292-305. Franke, N., & Shah, S. (2003). How communities support innovative activities: An exploration of assistance and sharing among end-users. Research policy, 32 (1), 157-178. Freiling, J. (2004). Competence-based view der unternehmung. Die Unternehmung, 58 (1), 5-25. Garcia, J. M., & Steinm¨ uller, W. E. (2003). Applying the open source development model to knowledge work (Tech. Rep.). University of Sussex, SPRU - Science and Technology Policy Research. Retrieved 9 August 2010, from http://ideas.repec.org/p/sru/ssewps/94.html Garcia, R., & Calantone, R. (2002). A critical look at technological innovation typology and innovativeness terminology: A literature review. Journal of Product Innovation Management, 19 , 110-132. Garson, D. G. (2002). Guide to writing empirical papers, thesis, and dissertations. New York: Marcel Dekker, Inc. Garzarelli, G. (2003). Open source software and the economics of organization. In J. Birner & P. Garrouste (Eds.), Markets, information and communication: Austrian perspectives on the internet economy (p. 47-62). London, UK: Routledge. Gassmann, O. (2006). Opening up the innovation process: Towards an agenda. R&D Management, 36 (3), 223-228. Gehring, R. A. (2006). The institutionalization of open source. Poiesis and Praxis, 4 , 54-73. Gelman, A., & Hill, J. (2007). Data Analysis Using Regression and Multilevel/Hierarchical Models. Cambridge University Press.

186

References

German, D. M. (2005). Software engineering practices in the GNOME project. In J. Feller, B. Fitzgerald, S. A. Hissam, & K. R. Lakhani (Eds.), Perspectives on free and open source software. Cambridge, MA: MIT Press. Gillham, B. (2000). Case study research methods. London, UK: Continuum. Gl¨aser, J. (2007). The social order of open source software production. In K. St.Amant & B. Still (Eds.), Handbook of research on open source software: Technological, economic, and social perspectives (p. 168-180). Hershey, New York: Information Science Reference. Grandstrand, O. (1999). The economics and management of intellectual property. London, UK: Edward Elgar Publishing. Grewal, R., Lilien, G. L., & Mallapragada, G. (2006). Location, location, location: How network embeddedness affects project success in open source systems. Management Science, 52 (7), 1043-1056. Hargadon, A. B. (2003). How breakthroughs happen: The surprising truth about how companies innovate. Boston, MA: Harvard Business School Publishing Corporation. Harhoff, D., Henkel, J., & von Hippel, E. (2003). Profiting from voluntary information spillovers: How users benefit by freely revealing their innovations. Research Policy, 32 , 1753-1769. Harrell, F. E. (2001). Regression modeling strategies: With applications to linear models, logistic regression and survival analysis. New York: Springer Series in Statistics. Hawkins, R. E. (2002). The economics of open source software for a competive firm. Kluwer Academic Publishers. Healy, K., & Schussman, A. (2003). The ecology of open-source software development (Tech. Rep.). Department of Sociology. University of Arizona. Hecker, F. (1999). Setting up shop: The business of open-source software. IEEE Software, 16 (1), 45-51. Hellstr¨om, T. (2003). Governing the virtual academic commons. Research Policy, 32 (2), 391-401. Henkel, J. (2004). Open source software from commercial firms - tools, complements, and collective invention. Zeitschrift f¨ ur Betriebswirtschaft, Erg¨ anzungsheft 4/2004 , 1-23.

References

187

Henkel, J. (2006). Selective revealing in open innovation processes: The case of embedded linux. Research Policy, 35 (7), 953-969. Hertel, G., Niedner, S., & Herrmann, S. (2003). Motivation of software developers in open-source projects: An internet-based survey of contributors of the linux kernel. Research Policy, 32 (7), 1159-1178. Hiltz, S. R., & Turoff, M. (1978). The network nation: Human communication via computer. London, UK: Addison-Wesley Publishing Company, Inc. Hoegl, M., & Gemuenden, H. G. (2001). Teamwork quality and the success of innovative projects: A theoretical concept and empirical evidence. Organization science, 12 (4), 435-449. Hope, J. (2005). Open source biotechnology. Canberra: Research School of Social Sciences and Faculty of Law. Hope, J. (2007). Pharmaforschung mit Open Source-Methoden. In B. Lutterbeck, M. B¨arwolff, & R. A. Gehring (Eds.), Open Source Jahrbuch 2007 - Zwischen freier Software und Gesellschaftsmodell. Berlin: Lehmanns Media. Howe, J. (2008). Crowdsourcing: How the power of the crowd is driving the future of business. London, UK: RH Business Books. Hunter, L. C. (1949). Steamboats on the western rivers: An economic and technological history. Cambridge, Mass.: Harvard U.P. Jalopy, M. (2005). Owner’s manifesto. Makezine, 4 , 154. Retrieved 5 March 2010, from http://makezine.com/04/ownyourown/ Jick, T. D. (1979). Mixing qualitative and quantitative methods: Triangulation in action. Administrative Science Quarterly, 24 . Johnson, R. B., & Onwuegbuzie, A. J. (2004). Mixed methods research: A research paradigm whose time has come. Educational Researcher , 33 (7), 14-26. K¨as, S. (2008). Rethinking industry practice: The emergence of openness in the embedded component industry. Berlin, Germany: Pro BUSINESS GmbH. Klink, R. R., & Smith, D. C. (2001). Threats to external validity of brand extension research. Journal of marketing research, 38 , 326-335.

188

References

Krishnamurthy, S. (2002). Cave or community? An empirical examination of 100 mature open source projects. Lakhani, K. R., & Wolf, R. G. (2005). Why hackers do what the do: Understanding motivation and effort in free/open source software projects. In J. Feller, B. Fitzgerald, S. A. Hissam, & K. R. Lakhani (Eds.), Perspectives on free and open source software. Cambridge, MA: MIT Press. Lamastra, C. R. (2009). Software innovativeness: A comparison between proprietary and free/open source solutions offered by Italian SMEs. R & D Management, 39 (2), 153-169. Laursen, K., & Salter, A. (2004). Searching high and low: What types of firms use universities as a source of innovation? Research Policy, 33 (8), 1201-1215. Lee, D., & Mendelson, H. (2008). Divide and conquer: Competing with free technology under network effects. Production and Operations Management, 17 (1), 12-28. Lee, D. W. (2008). Good car-ma, bad car-ma: What you and your conscience should know before buying the next car. Scotts Valley, CA: Create Space. Lee, G. K., & Cole, R. E. (2003). From a firm-based to a community-based model of knowledge creation: The case of the linux kernel development. Organization Science, 14 (6), 633-649. Lee, S.-Y. T., Kim, H.-W., & Gupta, S. (2009). Measuring open source software success. Omega, 37 (2), 426-438. Lepak, D. P., Smith, K. G., & Taylor, M. S. (2007). Value creation and value capture: A multi-level perspective. Academy of Management Review , 32 (1), 180–194. Lerner, J. (2005). The scope of open source licensing. Journal of Law, Economics and Organization, 21 (1), 20-56. Lerner, J., & Tirole, J. (2001). The open source movement: Key research questions. European Economic Review , 45 (4-6), 819-826. Lerner, J., & Tirole, J. (2002). Some simple economics of open source. Journal of Industrial Economics, 50 (2), 197-234.

References

189

Lerner, J., & Tirole, J. (2004). The economics of technology sharing: Open source and beyond. Harvard NOM Working Paper No. 04-35 . Retrieved 9 August 2010, from http://ssrn.com/abstract=620904 Lettl, C., Herstatt, C., & Gemuenden, H. G. (2006). Users’ contributions to radical innovation: Evidence from four cases in the field of medical equipment technology. R & D Management, 36 (3), 251-271. Little, R. J., & Rubin, D. B. (2002). Statistical analysis with missing data (Second ed.). New Jersey: Wiley series in probability and statistics. Lynn, L. H., Mohan Reddy, N., & Aram, J. D. (1996). Linking technology and institutions: The innovation community framework. Research Policy, 25 (1), 91-106. MacCormack, A., 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. Mahony, I. G., & Naughton, E. J. (2004). Open source software monetized: Out of the bazaar and into big business. Computer and Internet Lawyer , 21 (10), 1-17. Mansfield, E. (1986). Patents and innovation: An empirical study. Management Science, 32 (2), 173-181. Manski, C. F. (2004). Measuring expectations. Econometrica, 72 (5), 13291376. Maurer, S. M., & Scotchmer, S. (2006). Open source software: The new intellectual property paradigm. NBER Working Paper Series. Mayrhofer, P. (2006). Motives and perception of fairness in commercial user communities. In E.-M. Kern, H.-G. Hegering, & B. Br¨ ugge (Eds.), Managing development and application of digital technologies. Berlin Heidelberg: Springer. McClintock, C. C., Brannon, D., & Maynard-Moody, S. (1979). Applying the logic of sample surveys to qualitative case studies: The case cluster method. Administrative Science Quarterly, 24 . M´endez-Dur´on, R., & Garc´ıa, C. E. (2009). Returns from social capital in open source software networks. Journal of Evolutionary Economics, 19 (2), 277-295.

190

References

Mockus, A., Fielding, R. T., & Herbsleb, J. D. (2002). Two case studies of open source software development: Apache and Mozilla. Modica, S. (2008). Notes on the economic history of linux. Retrieved 2 March 2010, from http://www.unipa.it/∼modica/out-app.pdf Moon, J. Y., & Sproull, L. (2000). Essence of distributed work: The case of the linux kernel. First Monday, 5 (11). Mowday, R. T., Steers, R. M., & Porter, L. W. (1979). The measurement of organizational commitment. Journal of vocational behavior , 14 , 224 - 247. M¨ uller-Seitz, G., & Reger, G. (2008). Open beyond the source code? An explorative examination of the development of an open source car. In Proceedings of the EIASM IPDM Conference. M¨ uller-Seitz, G., & Reger, G. (2009). Is open source software living up to its promises? Insights for open innovation management from two open source software-inspired projects. R & D Management, 39 (4), 372-381. Nakakoji, K., Yamamoto, Y., Nishinaka, Y., Kishida, K., & Ye, Y. (2002). Evolution patterns of open-source software systems and communities. In Proceedings of the international workshop on Principles of software evolution, 76-85. Nelson, R. R. (1989). What is private and what is public about technology? Science, Technology, & Human Values, 14 (3), 229-241. Nelson, R. R., & Winter, S. G. (1982). An evolutionary theory of economic change. Cambridge, Mass.: Harvard University Press. Nuvolari, A., & Rullani, F. (2007). Curious exceptions? Open source software and open technology. In K. St.Amant & B. Still (Eds.), Handbook of research on open source software: Technological, economic, and social perspectives (p. 227-236). Hershey, New York: Information Science Reference. OECD. (2007). Giving knowledge for free: The emergence of open educational resources. O’Mahony, S. (2003). Guarding the commons: How community managed software projects protect their work. Research Policy, 32 , 1179-1198. Osterloh, M., & Rota, S. (2007). Open source software development - Just another case of collective invention? Research Policy, 36 , 157-171.

References

191

Partha, D., & David, P. A. (1994). Toward a new economics of science. Research Policy, 23 (5), 487-521. Peddibhotla, N. B., & Sumbramani, M. R. (2007). Contributing to public document repositories: A critical mass theory perspective. Organization Studies, 28 (3), 327-346. Penrose, E. T. (1959). The theory of the growth of the firm. New York: John Wiley & Sons. Perens, B. (1999). The open source definition. In C. DiBona, S. Ockman, & M. Stone (Eds.), Open sources: Voices from the open source revolution (p. 171-188). Cambridge, Mass.: O’Reilly. Perr, J., Sullivan, P., & Appleyard, M. M. (2006). Open for business: Emerging business models for open source software companies. Lab2Market Working Paper . Pettigrew, A. M. (1990). Longitudinal field research on change: Theory and practice. Organization Science, 1 (3), 267-292. Pinheiro, J. C., & Bates, D. M. (2000). Mixed-effects models in S and S-Plus. Springer. Pinheiro, J. C., Bates, D. M., DebRoy, S., Sarkar, D., & the R Core team. (2009). nlme: Linear and nonlinear mixed effects models [Computer software manual]. (R package version 3.1-93) Porter, M. E. (1985). Competitive advantage: Creating and sustaining superior performance. New York: Free Press. Powell, W. W. (1990). Neither market nor hierarchy: Network forms of organization. Research in Organizational Behavior , 12 , 295-336. R Development Core Team. (2005). R: A language and environment for statistical computing [Computer software manual]. Vienna, Austria. Retrieved 6 February 2009, from http://www.R-project.org Raasch, C., & Herstatt, C. (Forthcoming). How companies capture value from open design. Int. J. Information and Decision Sciences. Raasch, C., Herstatt, C., & Balka, K. (2009). On the open design of tangible goods. R&D Management, 39 (4), 382 - 393.

192

References

Raasch, C., Herstatt, C., Blecker, T., & Abdelkafi, N. (2008). The open source innovation - out of software? In Proceedings of the EIASM IPDM conference 2008 . Raasch, C., Schweisfurth, T., & Herstatt, C. (2010). The dynamics of community-backed entrepreneurship: A case study and model. TUHH TIM Working Paper . Raymond, E. (1999a). The cathedral and the bazaar. Knowledge, Technology, and Policy, 12 (3), 23-49. Retrieved 22 February 2010, from http://www.catb.org/∼esr/writings/cathedral-bazaar/ Raymond, E. (1999b). The magic cauldron. Retrieved 22 February 2010, from http://www.catb.org/∼esr/writings/magic-cauldron/ Roberts, J. A., Hann, I.-H., & Slaughter, S. A. (2006). Understanding the motivations, participation, and performance of open source software developers: A longitudinal study of apache projects. Management Science, 52 (7), 984-999. Rossi, C., & Bonaccorsi, A. (2005). Intrinsic vs. extrinsic incentives in profitoriented firms supplying open source products and services. First Monday, 10 (5). Rossi, C., & Bonaccorsi, A. (2006). Intrinsic motivations and profit-oriented firms in open source software: Do firms practise what they preach. In J. Bitzer & P. J. Schr¨oder (Eds.), The economics of open source software development (p. 83 - 109). Amsterdam, The Netherlands: Elsevier. Rossi, M. A. (2006). Decoding the free/open source software puzzle: A survey of theoretical and empirical contributions. In J. Bitzer & P. J. Schr¨oder (Eds.), The economics of open source software development (p. 15-55). Amsterdam, The Netherlands: Elsevier. Rowe, D. (2008). Open hardware 3 years on. Retrieved 2 March 2010, from http://www.rowetel.com/blog/?p=75 Sanchez, R. (2004). Understanding competence-based management: Identifying and managing five modes of competence. Journal of Business Research, 57 , 518-532. Scandura, T. A., & Williams, E. A. (2000). Research methodology in management: Current practices, trends, and implications for future research. Academy of Management Journal, 43 (6), 1248-1264.

References

193

Schewe, G. (1994). Successful innovation management: An integrative perspective. Journal of Engineering and Technology Management, 11 , 2553. Schumpeter, J. A. (1911). Theorie der wirtschaftlichen Entwicklung. Berlin, Germany. Schumpeter, J. A. (1934). The theory of economic development: An inquiry into profits, capital, credit, interest and the business cycle. Cambridge, Mass.: Harvard University Press. Shah, S. K. (2005). Open beyond software. In D. Cooper, C. DiBona, & M. Stone (Eds.), Open sources 2. Sebastopol, CA: O’Reilly Media. Shah, S. K. (2006). Motivation, governance, and the viability of hybrid forms in open source software development. Management Science, 52 (7), 1000-1014. Shah, S. K., & Corley, K. G. (2006). Building better theory by bridging the quantitative-qualitative divide. Journal of Management Studies, 43 (8), 1821-1835. Sheather, S. J. (2009). A modern approach to regression with R. Springer Texts in Statistics. Shirky, C. (2005). Epilogue: Open source outside the domain of software. In J. Feller, B. Fitzgerald, S. A. Hissam, & K. R. Lakhani (Eds.), Perspectives on free and open source software. Cambridge, MA: MIT Press. Shirky, C. (2007). Generalizing peer production into the physical world. Retrieved 5 October 2009, from http://finance.groups.yahoo.com/group/ decentralization/message/6967 Singhal, J., & Singhal, K. (2002). Supply chains and compatibility among components in product design. Journal of Operations Management, 20 , 289 - 302. Skiba, F., & Herstatt, C. (2009). Users as sources for radical service innovations: Opportunities from collaboration with service lead users. International Journal of Services Technology and Management, 12 (3), 317-337. Smith, Z. (2008). Objects as software: The coming revolution. 25th Chaos Communication Congress. Retrieved 15 April 2010, from http://events.ccc.de/ congress/2008/Fahrplan/events/2781.en.html

194

References

Spencer, J. (2003). Firms’ knowledge-sharing strategies in the global innovation system: Empirical evidence from the flat panel display industry. Strategic management journal , 24 (3), 217-223. Stallman, R. (2007). Why open source misses the point of free software. Retrieved 5 October 2009, from http://www.gnu.org/philosophy/ open-source-misses-the-point.html Stewart, K. J., Ammeter, A. P., & Maruping, L. M. (2006). Impacts of license choice and organizational sponsorship on success in open source software development projects. Information Systems Research, 17 (2), 126144. Stuermer, M., Sp¨ath, S., & von Krogh, G. (2009). Extending privatecollective innovation: A case study. R&D Management, 39 (2), 170-191. Subramaniam, C., Sen, R., & Nelson, M. L. (2009). Determinants of open source software projects success: A longitudinal study. Decision Support Systems, 46 , 576-585. Suh, N. P. (1990). The principles of design. Oxford, UK: Oxford University Press. Tabachnick, B. G., & Fidell, L. S. (2006). Using multivariate statistics (5th ed.). Needham Heights, MA: Allyn & Bacon, Inc. Teece, D. J. (1986). Profiting from technological innovation: Implications for integration, collaboration, licensing and public policy. Research Policy, 15 , 285-305. Teece, D. J., & Pisano, G. (1994). The dynamic capabilities of firms: an introduction. Industrial and Corporate Change, 3 (3), 537-556. Thomas, G. (2008). Microsoft and mixed source software. Retrieved 5 October 2009, from http://www.mylemonadestand.net/weblog/archives/12 Thomke, S. H. (2006). Capturing the real value of innovation tools. Management Review , 47 (2), 24-32. Thompson, C. (2008). Build it. Share it. Profit. Can open source hardware work? Wired Magazine. Retrieved 9 August 2010, from http://www.wired.com/print/ techbiz/startups/magazine/16-11/ff openmanufacturing

References

195

Vallance, R., Kiani, S., & Nayfeh, S. (2001). Open design of manufacturing equipment. von Hippel, E. (1988). The sources of innovation. New York: Oxford University Press. von Hippel, E. (2005). Democratizing innovation. Cambridge, Mass.: MIT Press. von Hippel, E. (2007). Horizontal innovation networks - by and for users. Industrial and Corporate Change, 16 (2), 293-315. von Krogh, G., Sp¨ath, S., H¨afliger, S., & Wallin, M. (2008). Open source software: What we know (and do not know) about motives to contribute. Dynamics of Institutions and Markets in Europe (DIME) working papers on intellectual property rights. Retrieved 5 October 2009, from http://www.dime-eu.org/files/active/0/WP38 vonKroghSpaeth HaefligerWallin IPROSS.pdf von Krogh, G., Sp¨ath, S., St¨ urmer, M., & Hertel, G. (2009a). The credible sponsor: Participant motivation and firm attributed in collaborative innovation. In Proceedings of the User and Open Innovation Workshop 2009 . von Krogh, G., Sp¨ath, S., St¨ urmer, M., & Hertel, G. (2009b). Results of maemo and openmoko community survey. Retrieved 6 October 2009, from http://public.smi.ethz.ch/files/MaemoOpenmoko/ PublicDescriptiveStatistics.html von Krogh, G., & von Hippel, E. (2003a). Open source software and the “private-collective” innovation model: Issues for organization science. Organization Science, 14 (2), 208-223. von Krogh, G., & von Hippel, E. (2003b). Special issue on open source software development. Research Policy, 32 , 1149-1157. von Krogh, G., & von Hippel, E. (2006a). Free revealing and the privatecollective model for innovation incentives. R&D Management, 36 (3), 295306. von Krogh, G., & von Hippel, E. (2006b). The promise of research on open source software. Management Science, 52 (7), 975-983. Warwick, D. P. (1975). A theory of public bureaucracy: Politics, personality, and organization in the state department. Cambridge, MA: Harvard University Press.

196

References

Weiss, D. (2005). A large crawl and quantitative analysis of open source projects hosted on sourceforge (Research Report RA-001/05). Institute of Computing Science, Pozna´ n University of Technology, Poland. Welte, H. (2009). Using OpenBSC for fuzzing of GSM handsets. 26th Chaos Communication Congress. Retrieved 15 April 2010, from http://events.ccc.de/ congress/2009/Fahrplan/events/3535.en.html West, J. (2003). How open is open enough? Melding proprietary and open source platform strategies. Research Policy, 32 , 1259-1285. West, J., & Gallagher, S. (2006). Patterns of open innovation in open source software. In H. Chesbrough, W. Vanhaverbeeke, & J. West (Eds.), Open innovation - researching a new paradigm. Oxford: Oxford University Press. West, J., & O’Mahony, S. (2008). The role of participation architecture in growing sponsored open source communities. Industry and Innovation, 15 (2), 145-168. Westbrook, R. A., & Oliver, R. L. (1981). Developing better measures of consumer satisfaction: Some preliminary results. Advances in Consumer Research, 8 (3), 94-99. Wichmann, T. (2002). Firms open source activities: Motivations and policy implications, free/libre open source software: Survey and study. International Institute of Infonomics, Berlecom Research GmbH . Williamson, O. E. (1985). The economic institutions of capitalism. A Division of Macmillan, Inc.: The Free Press. Williamson, O. E. (1991). Comparative economic organization: The analysis of discreme structural alternatives. Administrative Science Quarterly, 36 , 269-296. Wright, D. B., & London, K. (2009). Modern regression techniques using R: A practical guide. London, UK: SAGE. Yin, R. K. (2003). Case study research: Design and methods. Thousand Oaks, CA: Sage Publications Inc.

GABLER RESEARCH „Forschungs-/Entwicklungs-/Innovations-Management“ Herausgeber: Prof. Dr. Hans Dietmar Bürgel, Prof. Dr. Diana Grosse, Prof. Dr. Cornelius Herstatt, Prof. Dr. Hans Koller und Prof. Dr. Martin G. Möhrle zuletzt erschienen: Kerstin Balka Open Source Product Development The Meaning and Relevance of Openness 2011. XVIII, 196 S., 30 Abb., 20 Tab., Br. € 59,95 ISBN 978-3-8349-3153-5 Isumo Bergmann Patentverletzungen in der Biotechnologie Einsatz semantischer Patentanalysen 2011. XVIII, 164 S., 49 Abb., 18 Tab., Br. € 49,95 ISBN 978-3-8349-2898-6

Markus Grote Management geschäftsbereichsübergreifender Innovationsvorhaben 2010. XVI, 262 S., 28 Abb., 31 Tab., Br. € 49,95 ISBN 978-3-8349-2519-0

Katharina Kalogerakis Innovative Analogien in der Praxis der Produktentwicklung 2010. 198 S., 15 Abb., 13 Tab., Br. € 39,95 ISBN 978-3-8349-2387-5

Änderungen vorbehalten. Stand: Juli 2011. Erhältlich im Buchhandel oder beim Verlag. Gabler Verlag . Abraham-Lincoln-Str. 46 . 65189 Wiesbaden . www.gabler.de