On the viability of the open source development model for the design of

physical objects

Lessons learned from the RepRap project

Erik de Bruijn e.debruijn@uvt.nl

Dept. of Information Management Faculty of Economics and Business

University of Tilburg, The Netherlands

Thesis for the degree of Master of Science Supervised by: Prof. R. O’Callaghan

09/06/10

Abstract

While open source software development has been studied extensively, relatively little is know about the viability of the same development pattern for physical objects. The present research reviews the literature on open source and user innovation communities followed by a case study and survey of the RepRap community in which both software and physical objects are collaboratively designed and freely revealed. Patterns observed in the RepRap community provide insight into how the distributed development of physical objects could become a more general phenomenon. Several important trends are identified, such as the increased digitization of design and manufacturing processes and availability of more affordable development and prototyping tools.

Keywords: Open source development model, open design, distributed innovation

Contents

1 Introduction  3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Problem statement and research questions . . . . . . . . . . . . . 4
1.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Theoretical foundation . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Literature review . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Case study  12
2.1 The RepRap Community: an introduction . . . . . . . . . . . . . 12
2.2 RepRap as an open source community . . . . . . . . . . . . . . . 12
2.3 Unique characteristics and adoption . . . . . . . . . . . . . . . . 13
2.4 Participants / Founders and governance . . . . . . . . . . . . . . 13
2.5 Technological innovations . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Distribution and diffusion of innovations . . . . . . . . . . . . . 14
2.7 Motivations to participate . . . . . . . . . . . . . . . . . . . . . . 15
2.8 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Survey  18
3.1 Overview of the results . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Innovating the software versus hardware . . . . . . . . . . . . . 19
4 Confronting theory with practice  22
4.1 Tools of production and distribution . . . . . . . . . . . . . . . . 22
5 Conclusions  24
Bibliography  24

Chapter 1

Introduction

1.1 Motivation

Our information and communication infrastructures are evolving rapidly. As observed by Shapiro and Varian (1999), even if information is produced at a high fixed cost, it can be reproduced to high fidelity at negligible incremental cost. This hints at an enormous potential diffusion of valuable works. It stresses the importance of a better understanding of the provisioning and distribution of information based goods in society. With the costs of communication falling, new forms of collaboration are emerging. One of these forms, called open source development, typically involves a large set of individuals and/or organizations to share the workload (Haefliger et al. , 2008) while the public good properties of the outcome are preserved Osterloh and Rota (2007).

Open source software development has attracted significant scholarly attention (Spaeth et al., 2008). A lot of research is devoted to explaining the characteristics of open source software development as being different from a traditional, more top-down development paradigm. The successes of projects like Linux, Apache and Firefox not only highlight the merit of the development methodology but also its real-world significance, robust functioning in the marketplace and its value creation potential (von Krogh and von Hippel , 2003). The non-exclusive nature of the output of the open source development process is associated with value spill-overs and at the same time enabling organizations and individuals to innovate faster and at a lower cost.

Studying the viability of the open source development methodology is specifically relevant because it has been shown that it addresses several important issues concerning creation of public goods (Benkler, 2006, p. 119), and does so in a sustainable way (Osterloh and Rota, 2007). Software and other information products can be considered non-rival, because distribution typically does not involve a loss of the sender. Distribution, because if its digital encoding is virtually free.

In the literature, open source development of physical objects, so called open design, is hardly touched upon. In open design, information such as schematics, bills of materials and assembly instructions are freely revealed. Prevalence of open source in physical design projects with some degree of visibility is still very modest when compared with software. Data collection on open design projects by Balka et al.(2009) resulted in 85 listed projects by August 2009, which is a relatively small number when compared to over 380,000 open source software projects on SourceForge ^{1} in the same year. In principle, open design predates open source software by centuries (e.g. Allen, 1983; Nuvolari , 2004). Yet the distributed nature of open source development has not emerged in open design as it has in software. The low number of hardware related projects leads observers to think that it is not a viable domain for open source production. Viability of any mode of production is determined by the way work is organized. Through an in-depth study of the RepRap project, in which both software and hardware development are present, this thesis will help remedy this knowledge deficit. This thesis will investigate what influences the viability of this mode of development for physical designs. This will be done through a study of the RepRap community, a community that develops an open design of a machine that can fabricate physical copies of digital designs.

Benkler (2006, p. 121) remarks that “[t]he highly distributed capital structure of contemporary communications and computation systems is largely responsible for this increased salience of social sharing as a modality of economic production in that environment. By lowering the capital costs required for effective individual action, these technologies have allowed various provisioning problems to be structured in forms amenable to decentralized production based on social relations, rather than through markets or hierarchies.”

The RepRap community is encompassed by an ecosystem of user-founded businesses, manufacturing service providers and user innovators. The high growth rate of the community and its surrounding ecosystem and the rapid diffusion of distributed production resources provide the primary means for distributed physical prototyping and production. It is of high importance to investigate the implications of the availability of low-cost physical production resources and which role they play to extend social production beyond the virtual world.

1.2 Problem statement and research questions

Because the development model of open source software apparently can produce highly successful output, it is very important to see if this model can be applied to a wider range of problems. Weber (2004) also emphasizes the importance of this question, stating that ”[t]he open source process has generalizable characteristics, it is a generic production process, and it can and will spread to other kinds of production. The question becomes, are there knowledge domains that are structured similarly to the software problem?” He goes on to say that: ”The key concepts of the argument - user-driven innovation that takes place in a parallel distributed setting, distinct forms and mechanisms of cooperative behavior regulated by norms and governance structures, and the economic logic of ”antirival” goods that recasts the ”problem” of free riding – are generic enough to suggest that software is not the only place where the open source process could flourish.”

1SourceForge is a popular open source project hosting solution. In February 2009 there were 380,000 projects listed. From: http://sourceforge.net/about

Open source software development has been studied quite extensively for various reasons (Spaeth and von Krogh , 2007). However, by comparison, very few studies of open source development outside of software have been done. The literature on user innovation communities includes studies of highly distributed communities producing software. It also includes studies of such communities developing and exchanging physical resources. Yet, these communities mostly lack the spacial distribution and frequent interactions that characterizes many software projects. This appears to be a result of the logistics of physical items and the resulting difficulties in transferring physically embodied knowledge. Based on the existing studies, is not evident whether this type distributed development is viable at all. This study of the RepRap project, not only provides a strong indication that it is viable, it also tries to identify factors that influence viability and discusses the generality of these findings.

The stated problem will be addressed by answering the following research question:

To what extent is the open source development model also viable for the design of physical objects?

I will start addressing this question by referring to research that explains the viability of open collaborative innovation projects in general. This mode of development is not specific to software or physical products (von Hippel , 2005b). I will show that the conditions for viability are met for the specific case of the RepRap community. In the case description I will also show that while the tangible dimension is relatively unique, RepRap has many things in common with typical OSS community.

Question 0: What is open source?

Before addressing the actual research problem, it needs to be clear what I mean when we use the words ”open source”. This question will be answered through a review of the literature on open source. After defining it in the literature review in chapter 2, the two main research questions will be addressed. After having described open source which Open Source Software and open design have in common, the first research question focuses on differences between the two and their impact.

Question 1: What are differences between open source software development and open development of physical objects?

This question will first be addressed mostly from a theoretical perspective. Differences with respect to lifetime, modularity, supply chains, replication, cost structure and patent law were highlighted by Abdelkafi et al. (2009). To further explore the differences the creation, transfer and diffusion of innovations in each area will be compared statistically through the survey.

Question 2: How are drawbacks of the physical nature of open design addressed in the RepRap project?

Because frequent exchanges of physical innovation are common among members of the RepRap community, these will qualitatively be examined. In particular, we will identify resources and cultural factors that facilitate these interactions. These resources include knowledge, infrastructural tools, software tools and physical equipment. Cultural aspects have to do with norms and rules present in the community and the way in which feedback is given. The case study will reveal how the tools and culture, taken together, enable distributed physical prototyping.

1.3 Methodology

1.3.1 Research Models

For any detailed comparison between two modes in which open source development is practiced, it is valuable to adopt an analytical framework that generalizes from features that are unique to either of the models. Through the literature review, three frameworks are found to be appropriate. These frameworks will be evaluated in the literature review.

The context for addressing the research problem will be provided by both the literature on open source software and the more general research models applicable to open source innovation. I will draw from the latter research models because they have proven to be applicable to software development without being limited to software alone. They have frequently been used to study collaborative development of physical products too.

To restrict the areas in which I will find differences, I will look into a single community which develops both software and hardware to solve the same problem. The emphasis is not on differences between distinct OSS and OD communities. For an overview of various OD communities and their differences see Balka et al.(2009)

Using a single community has an important research benefit. With regards to the product this will limit variations such as whether it’s a functionality or aesthetics is dominant; the RepRap project’s main product is a functional design of a machine employing both software and physical designs. On the other hand, differences that result from whether parts of the product design pertain to a software module or a physical part become more salient when these other parameters are constrained.

It also restricts producer variations. Among other things, I will learn whether individual participants have different perceptions and motivations, employs different methods and encounter different problems while dealing with either software or hardware.

1.3.2 Case study

To understand how open source development can function outside of the more familiar context, a case study helps answer the ”how” and ”why” questions (Lather, 1992; Robottom and Hart, 1993; Ellis and Levy, 2008; Yin, 2002). In this case it will be used to better the understanding of participants’ actions and the context of their behavior.

Since the interest is in understanding something more general than the case, adoption of an instrumental case study methodology is deemed appropriate. The case, as an instance of the studied phenomenon, plays merely a supportive role to understanding the phenomenon. The case is looked at in depth, its context scrutinized, its ordinary activities detailed, and because it helps the researcher pursue the external interest. The case may or may not be seen as typical of other cases. (Stake, 1995)

Because the choice between an instrumental or intrinsic case study is not obvious, this deserves some clarification. Stake (Ibid.) uses the term intrinsic and suggests that researchers who have a genuine interest in the case should use this approach when the intent is to better understand the case. It is not undertaken primarily because the case represents other cases or because it illustrates a particular trait or problem, but because in all its particularity and ordinariness, the case itself is of interest. The purpose is not to come to understand some abstract construct or generic phenomenon (Baxter and Jack, 2008, pp. 548-549).

The case is very unique and interesting in itself for several reasons: the fact that open source development is being applied beyond its familiar scope, the physically embedded nature of the exchanged innovations, the frequency of these exchanges, the rapid growth of the community and, finally, the individual members’ access to resources that even few firms have. On the face of it, the generality of the findings from such a case study seem to be very limited. After a more in depth review of the literature, however, it appears that the theory even predicts the activity that is observed. Given the good fit with the already well-established analytical framework, it seems a mistake to consider it as sui generis, an isolated case that does not fit into a broader encompassing framework. That this particular case has properties that are salient does not imply that the properties are fundamentally new. Recent developments, however, allow a much larger group of individuals to participate in this extended scope of open source development.

1.3.3 Survey

The survey will provide insight into adoption, creation, transfer and diffusion of both software and hardware innovations and the importance of location and infrastructure for diffusion of innovations. Under the conditions that hold for the RepRap community, there will be a certain impact of tangibility of hardware (having to do with the embodiment and logistics). I will use this empirical data to determine the nature and significance of these effects.

Empirical data was gathered by administering a survey among users and developers in the community. Participation was limited to only those who build and/or operate open source 3D printers. This excludes a potentially larger group of people that does interact with the community but isn’t building their own machines, however it allows more in depth questions pertaining to the use of the machines. Invitations to participate were posted on various blogs, forums and social media platforms that community members frequently access.

1.4 Outline

This thesis is structured as follows (depicted in figure 1.1). The current chapter introduces the research problem and explains how it is addressed. Chapter 2 serves as the theoretical foundation by defining open source and by reviewing the relevant literature. Concepts most important to address the research problem at hand will be identified here. The case study of the RepRap community and its development process is provided in chapter 3. Following an introduction of the community, an emphasis will be placed on the concepts that were identified in the literature review. Chapter 4 will contain a qualitative analysis of the RepRap contributors to determine differences between the software and hardware with respect to creation and diffusion of innovations. Chapter 6 concludes this thesis with a discussion of both the theoretical and empirical findings and suggestions for further research.

Figure 1.1: Outline of this thesis

1.5 Theoretical foundation

For a proper analysis of the cases, a good definition of concepts like open source, open source communities and projects is pertinent. In addition, to meaningfully contribute to the existing body of literature, it needs to be clear how it aligns with the existing theory and research frameworks. This will be done, respectively, in the first and second paragraphs. The findings, with respect to which research framework will be most appropriate are summarized in the third and final paragraph of this chapter.

1.5.1 Terminology and definitions

For this analysis it is important to clearly define what open source is. Open source has several distinct but related meanings. It is used to denote a practice regarding the licencing of intellectual property of software and other creative works. In addition, it is often referred to as a development methodology and in some cases as a collaborative strategy between users and user-firms. Moreover, open source communities are examples where these collaborative strategies and the development methodology are being practiced. This section elaborates on these meanings.

Defining open source

Formally, for software to be called open source its license has to conform to the Open Source Definition (OSD) as outlined by the Open Source Initiative ^{2}. Most notably, the OSD implies that software has a license that permits modification, and must requires free redistribution of the software under the same license. The licenses compatible with the Open Source Definition are mostly based in copyright law since this type of intellectual property law is most applicable to software, which is the area where free and open source practices emerged.

Perhaps the most important function of the open source licenses is to ensure non-exclusive access to the intellectual property. This inverted application of intellectual property law has many implications. From the perspective of the individual developer, it helps to prevent that their work is appropriated. Moreover, reuse and improvement of open sourced products can be carried out without needing to ask for permission. This somewhat reduces transaction costs, reduces the barriers to contribute and reduces duplication of effort. Moreover, potential benefits encourage a more modular approach, which is often considered a good development practice for maintaining high quality standards even for systems with a high complexity.

It should be noted that the OSD does not lend itself well to also cover physical product licenses, as these may need to also draw on other legal domains. Copyright law can only be used to protect implementations of ideas, and not the ideas themselves. In this way, the license will apply to copies of design documents and design files, but the design itself is not copyrighted. Moreover, the non-exclusive nature of the design files does not preclude the existence of patents that impose limitations to the use of the files to manufacture it, however the same could be said for software patents. It is difficult to assess the impact of interactions between these legal domains and it is further complicated by the fact that there are legal differences between the various different regions. Most of these issues are still unresolved, however some new development are underway.

Recently a version of the Open Source Hardware (OSHW) Definition was drafted. Yet it is in a very early and volatile state and mostly borrows from the OSD. Some open source licenses that pertain to hardware have been developed, but none of them are very mature. Moreover, the lack of litigation makes it unclear whether they will properly perform their function. Lacking maturity introduces the risk of appropriation which in turn could reduce incentives to contribute.

2See http://www.opensource.org/docs/osd

The meaning of open source as a development methodology has been given thorough attention by scholars such as Raymond, von Krogh, von Hippel and Benkler. However, it is important to note that the collaborative practices that are observed in open source development do not require a certified open source license. Several ways of freely revealing innovation outcomes would, at least to some degree, enable others to provided feedback, test and improve that work. These development patterns have been studied extensively and are so closely related to open source development that generalization is justified. Any description that covers more of what goes on in a typical open source community would have to acknowledge that legal tools are only a part of the norms and culture that affect the community’s behavior. In that sense, legal tools are just another mechanism that is used because of its good alignment with the practice of collaboration. Other norms, formal or informal and the community’s culture also determine to a large degree the behavior of its participants. Norms other than those that are legally binding can be effective at stimulating developers to share their work that builds on shared work. Reciprocity and a shared understanding of fairness can be strong social mechanisms, and these are commonly present in open source communities. The reuse of modules can be encouraged without non-legal norms, moreover even without active encouragement it can still be done without permission. Duplication of effort is still reduced and few transaction costs are involved.

User innovation communities

Those communities that encourage these beneficial behaviors are likely to be more successful. A community can be described as a ”network of interpersonal ties that provide sociability, support, information, a sense of belonging and a social identity” (Franke and Shah, 2003)

1.6 Literature review

There are several research models applicable to open source development that are not limited to software development. We will introduce three of them that appear to be appropriate, briefly compare them and, finally, further review their suitability for the purpose of this research.

1.6.1 User innovation

User innovation, by definition is an innovation process in which users are the focal actors. As such, the networks can innovate independently of manufacturers. Such a network can flourish when (1) at least some users have sufficient incentive to innovate, (2) at least some users have an incentive to voluntarily reveal information sufficient to enable others to reproduce their innovations, and (3) user self-production can compete with commercial production and distribution. In case only the first two conditions hold, the innovation process itself still concentrates around users, yet manufacturers focus on their more favorable returns to scale. (von Hippel , 2007)

Various researchers have documented the development of physical products by users and user communities. Examples include sports equipment (Lüthje et al., 2002; Franke and Shah, 2003; Lüthje and Herstatt, 2006; ?), scientific instruments (von Hippel and Riggs , 1994; von Hippel , 1976), medical instruments (Lüthje, 2003) and industrial process equipment (von Hippel , 1988) and products (von Hippel and Finkelstein , 1979; Herstatt and von Hippel , 1992; Nuvolari , 2004), Morrison et al. (2002), mass production of steel and the personal computer by Meyer (2003). These communities are by no means restricted to the development of information products like software. They also are active in the development of physical products, and in very similar ways (von Hippel , 2005a, p. 103).

Case study

One of the more ambitious open design projects is the RepRap project. Its goal is to collaboratively develop a low-cost fabrication device that can to a large extent produce a physical copy of itself. The RepRap machine is often described as a 3D printer, one that creates strong, tangible objects of arbitrary shape. Based on digital design files that are openly shared, the machine can be used to fabricate physical objects of value to the user. Users share and use design files of physical objects. One of these collaboratively developed designs is the RepRap machine itself. Users of RepRaps have the tools to fabricate modification for the machine that they operate.

This chapter starts by looking into this user innovation process by seeing who is innovating and how they are motivated.

2.1 The RepRap Community: an introduction

This chapter starts with how the project was initiated. We will identify properties that enable the form of collaboration that is observed in the RepRap project, which a result of the replication aspect and the fact it materializes digital input. You cannot fully understand an instance of innovation or collaborative processes unless you know who is doing it. The survey in chapter 4 will go into much more detail on the participant’s motivations, functional relationship to the invention and innovation assets. Here we will show how work is coordinated. Project governance and the technical infrastructure play an important role. I will describe how the architecture can affect coordination.

2.2 RepRap as an open source community

In 2004 Adrian Bowyer, a professor at the University of Bath, proposed the idea of creating a rapid prototyping machine that could make a significant fraction of its own parts. His goal was to make this technology accessible to anyone who wanted it. Bowyer mentions three important qualities of his envisioned machine were (1) that the number of them and the wealth they create could grow exponentially, (2) the machine becomes subject to evolution by artificial selection and (3) that it creates wealth with minimal dependence on industrial manufacturing^{1}.

Rapid Prototyping machines have existed for over 20 years, but never at a price point attractive for domestic and hobbyist use . The so called Additive Manufacturing (AM) industry is introducing lower costs AM machines, but so far most of them are above 10,000 euros. The RepRap is designed to be built for less than 500 euros, which has allowed a wider set of people to experiment with the technology and improve it.

2.3 Unique characteristics and adoption

For diffusion of the invention to occur, those adopting it have to have reasons to have such a machine and the means to obtain it. Most of the practical reasons for adopting the machine result from its wide range of applications, low switching cost of between different production jobs and the benefits of using digital designs as input. Within the build volume of the machine, there are few restrictions on the shape of the object that it fabricates. This is relatively unique and is a result of layer based technology used. Moreover, the specific object that it fabricates depends on the digital design file that is selected. Very significant is the ease with which designs can be distributed, since a large fraction of the design and fabrication information is codified into the digital file. A resulting attractive feature is that physical upgrades and variations can be fabricated with the machine, and that these variations can be shared digitally with relative ease. This enables the artificial selection (ad 2), carried out by relatively independent individuals and organizations (ad 3).

2.4 Participants / Founders and governance

After Dr. Bowyer’s initial proposal to build a RepRap in 2004, experiments at Bath University were conducted of which the results were shared online. This captured the interest of a widely distributed audience who joined the experimentation and pooled their knowledge. In the first year, less than 10 people were involved. Most notably, Vik Oliver, an open source enthusiast from New Zealand developed and built several of the early prototype machines^{2}. Zach Smith, a web-developer based in New York City, designed circuit boards and started selling kits through a foundation that he set up in conjunction with the core team.

Within the RepRap community, you can distinguish between the core and peripheral community (with regards to level of involvement). When more people volunteered, a core team was assembled which included most of the people who were involved early on. Over time, more people from the community were included in the core team. They are voted on board by unanimous vote. The core team can be considered a non-hierarchical group.

Dahlander and O’Mahony (2008) argue that progression can be achieved in project-based organizations that reward people with greater authority over collective work even though they do not gain authority over other individuals. New core members are invited based on their merit. If you engage more heavily in problem solving in the community, you’re more likely to progress to the center. Moreover, the core members take some level of responsibility of coordinating work, yet for many issues the whole community is consulted. Historically, the core team has taken decisions regarding the architecture of designs and infrastructure for collaboration. Because there is no formal authority over persons, everyone in the community is free to disagree with decisions and implement things in a different way. This way they can prove the value of a different approach. Most individual innovators are in control of their own budgets and decide themselves what to spend their time on.

1From http://www.bath.ac.uk/ ensab/rapid-prototyping/ retrieved 3 January 2005, via The Web Archive

2Oliver, V. Construction of Rapid Prototyping Testbeds Using Meccano. May 2005

2.5 Technological innovations

Adopters of RepRap technology have an valuable set of prototyping tools at their disposal that also allows them to improve the technology itself. Moreover, those benefiting from its use will have an incentive to improving it. Improvements can include added functionality, improved existing functionality, increased ease of assembly and use, lower cost, more suitable (e.g. easier-to-acquire) components, specialization towards a certain application, extending auxiliary tools, interoperability with other systems, improved design architecture and developing or refining operating techniques. In addition, several layers of the stack of technologies used can be discerned. These include, physical/mechanical, electromechanical, microcontroller firmware, etc. A sustainable innovation process relies on radical and incremental innovations. In other words, the viability of communal development of designs of physical objects relies on the ability to generate both types of innovation^{3}.

The diversity of community members, with respect to motivations and innovation assets held, may reflect on the aspects being given attention.

2.6 Distribution and diffusion of innovations

Depending on the architecture and level of modularization, a change in a digital design can be made and communicated at a certain cost. The cost of making changes depends on the tools used, their interoperability with the informationstructures used. The cost of communicating the design change depend on the sender and recipient. Codification and stickiness of information are important issues. The cost of integrating this change. Several motives for free revealing of improvements. Compliance with formal/informal communal norms and licenses. Both users and manufacturers can benefit from others investing in developments that build on theirs, since they have a high absorptive capacity in these areas (Osterloh and Rota, 2007).

If designed objects can be automatically fabricated, this has important consequences. Whereas physical objects take up space and can only be in one place at the same time, storage and distribution of design information is greatly facilitated by our digital communications infrastructures. The means to obtain it are facilitated by the partial replication capability. Additionally, the choice for an open source license (the GNU General Public License) was made to ensure inclusive access to the design files and to encourage collaboration. Since the inception of the project, several thousands of people have built RepRap or derivative machines. Some project participants have started businesses in selling parts and kits. As the project advances, more people are capable of printing out the machine parts for which there is a large demand. Some individuals RepRap members have reported to have printed more than a dozen sets of parts for others.

3See Riggs and von Hippel (1994), “Incentives to innovate and the sources of innovation: The case of scientific instruments,” Research Policy, for an analysis showing how novel functionality emerges from users.

2.7 Motivations to participate

In interviews with many members of the RepRap community three basic motivations seemed to be responsible for people to choose to participate in the project. Autonomy, the desire for competence and purpose appear to be important motivators.

2.7.1 Autonomy

As mentioned in section 2.4 about governance, and like in any open source community, there is no formal authority over members in the community. The members are autonomous in that they can themselves decide what they want to work on. Consequently, they will in general not work on aspects that they do not enjoy working on. This enjoyment can be rooted in pleasure from learning something new and gaining competence, or a sense of fulfillment from being able to utilize their talent to solve challenging problems.

Most members of the community are not paid or formally rewarded for their participation in the project. Research suggests that this might actually be beneficial for sustaining creativity and innovation. Amabile (1998, p. 79) states that extrinsic motivation is to be seen mostly as a potential source of creativity problems. In the same paper she suggests that intrinsic motivation is a key determinant for creativity.

A meta-analysis of several psychological studies by Deci et al. (2001) shows that extrinsic rewards can crowd out intrinsic motivations. Because of the dominance of activities that are enjoyed and the absence of external stimuli, most members can be considered to be intrinsically motivated. When a person is intrinsically motivated, he or she enjoys the process over specific results. Amabile calls this the Intrinsic Motivation Principle of Creativity: people will be most creative when they feel motivated primarily by the interest, satisfaction, and challenge of the work itself, and not by external pressures (Amabile, 1998, P. 79). Because of this, creative, explorative behavior can be expected to be more salient.

Everyone who works in the RepRap project mostly manages his or her own budgets, because it usually is their own money that they are spending, in contrast to organizational spending. For example, use of a company resource such an money may require approval in advance. Spending it unwisely in the eyes of your colleagues or superiors might be a source of tension or even conflict. By contrast, in the RepRap community there is no need to convince people of the value of a costly experiment for the sake of approval. This means that even if an approach may not seem like a viable alternative to most people in the community, it can and will still be tried as long as at least one person is motivated do so.

The autonomy is not to be mistaken for independence. The people that work on the RepRap have a good sense of the value that other have brought to the table and that they could never have done all of the work by themselves. Also, most people acknowledge that the social component that is present in the community is important to them.

The positive and rewarding properties that a individual attributes to the participation in the project are beneficial to the project because it is responsible for attracting new participants. In addition, the participants who are attracted are not only highly motivated, but also creative and can autonomously decide to experiment and innovate as much as they like.

With the completion of their RepRap 3D printer a person acquires both a powerful tool and the skills to create new physical objects. The people in the RepRap community tend to be inclined to work creatively on challenging problems. Apart from improvements related to the machine itself, a lot of additional innovations are likely to be created. For some people, being able to work on other, non-RepRap related innovations may be an important reason to build such a machine.

2.7.2 Striving for competence

Studies have shown that it is common in open source software projects that enjoyment-based intrinsic motivation is the strongest and most pervasive driver (Lakhani and Wolf , 2005). Also, intellectual stimulation and gaining competence are provided as top motivators for participation. The observation that open source projects often attract new participants based on their intellectual challenging aspects is explained by psychologists as a natural inclination. Ryan and Deci (2000) state that “the construct of intrinsic motivation describes this natural inclination toward assimilation, mastery, spontaneous interest, and exploration that is so essential to cognitive and social development and that represents a principal source of enjoyment and vitality throughout life”.

Lakhani and Wolf (2005) also note that in their sample of open source projects, a participants’ high rating of the creativity of their involvement was the strongest determinant of the number of hours that were weekly spent in the project. The multi-project sample revealed that the sense of creativity is endogenous to the people within the projects, and not just a property of the project.

2.7.3 Meaning

The work done in the RepRap community is by its members generally perceived to be meaningful. Moreover, building a RepRap and improving it is a process of gaining competence.

Ariely et al. (2008) have found important differences in motivation between work that was perceived as meaningful and work that seemed meaningless. In the survey, participants frequently stated reasons such as “to participate in the future”, “because I think RepRap will be extremely important”. Others mentioned it was to make sure everyone can have a personal factory at home.

The meaning that the project has for these people makes them highly motivated.

2.8 Findings

The case study explores the operation of the open source development process in the RepRap and directly related communities. Many of the community members possess a relatively unique fabrication capability. Special attention is given to the role of this capability and its effect on collaboration. It affects the cost of development, production, reproduction and distribution of physically embodied innovations. Due to artifact embodied tacit knowledge it affects the locus of innovation. Practically it affects the fraction of the project’s modules that can be developed through the open source development process, such as the dependence on external parties for manufacturing off-the-shelf components. It also has implications for the architecture and incentives (you can scratch your own itch). In particular, the diffusion of innovations with artifact-embodied information is first addressed theoretically, identified in the case study and tested quantitatively through the survey.

While these are currently unique capabilities, this doesn’t mean that this necessarily remains the same for long. The fact that the technology is rapidly becoming more affordable, able to produce higher quality objects, that libraries of designs already exist and have rapidly increasing growth rates indicates that widespread adoption is not just plausible but almost inevitable. Therefor, as new cohorts adopt the technology they will increasingly demand further maturization of technologies.

Industrial product development and engineering are generally regarded as activities that require payments and career incentives to induce effort. When compared to adopting a piece of software, acquiring and assembling a RepRapkit entails considerable effort and even money.

Within the RepRap project extrinsic motivation such as payment is a modest/negative predictor of effort. The primary motivations within the RepRap community are consistent with the most important motivation that were identified in studies of open source software communities. The community appears to consist of highly motivated, creative and innovative individuals. Considerable effort is invested in the project while the results are made available to anyone.

Survey

The survey was available from 25 February to 18 March 2010. At that time the total community is roughly estimated to have between 2000 and 3000 members, based on sales data of various kit builders. The survey is quite extensive (up to 72 questions when applicable) and on average took between 13 minutes and 28 seconds to complete. . 386 complete responses were received.

The survey was divided in the following sections:

A Type of user

B Adopting the machine C Innovating the software D Innovating the hardware E Thingiverse F Demography and general questions

The survey tracks the entire process from adoption of the platform, to development of innovations and, where applicable, their free revealing and their diffusion.

3.1 Overview of the results

As shown in figure 3.1, most of the people who get involved the project and that adopt the technology have done so fairly recently. The adoption rate increases so fast that new adopters outnumber all previous adopters that had joined more than 6 months ago. Since a significant proportion of the whole community is sampled (estimated between 10 to 20%), it is probably representative. It also hold another powerful message. An attempt to measure the size of the community is prone to be outdated when analysis of the collected data is completed. Yet, especially in the long run, the precise size is far less important than its growth rate. What this figure also shows is that the community can attract new participants. Obviously this type of growth creates the challenge to integrate the efforts of a growing amount of individuals.

Because of the rapid exponential growth, a logarithmic scale is more appropriate (figure 3.1(b)).

A non-linear least squares fit (using Levenberg-Marquardt nonlinear regression) yields a duplication of the community every 6.03 months and a 10 fold growth every 20 months. If this growth rate would continue unabated this means that there would be 10 million operators by 2016 and over 1 billion operators in the course of 2019. Obviously, extrapolating this far out of the data assumes that there are no fundamental changes to growth characteristics.

Not only do RepRaps spread to more individuals, the individual operators of working machines have the capability to make more of them. The respondents were invited to list the machines they had. 52% of the people have at least one working machine. The average operator has 1.52 machines (working or being constructed). More than half of the respondents had two or more distinct types of machines (table 3.1). They possibly have several instances of each distinct type of machine they own.

Table 3.1: Distinct number of machines per operator

No. of distinct

types of machines Frequency
1  237
2  108
3  28
4  9
5  2

It is common not to make another copy of the same machine if a later version can be adopted. While there are some substitution effects, some more commonly taken upgrade paths can be identified. So called ”bootstrap machines” can be constructed from ubiquitous parts available in hardware stores, or kits are available from various suppliers. These machines can be used to make the parts for a RepRap, that can in fact make its own parts.

Because most RepRap models are not finished products that are bought but rather parts that one acquires from one or more sources, many people are in the stage of building a machine. The proportion that is still building a machine is higher because of the high ratio of recent adopters, as seen in figure 3.1.

3.2 Innovating the software versus hardware

The level of innovation in either software or hardware depends on several variables. These variables include: (1) inherent properties of respectively the immaterial and material product (2) the result of the availability and quality of development tools. (3) the skills and resources available to the innovator, such as time, money, knowledge, equipment, reusable modules, etc. (4) the incentives, perceptions and motivation of the innovators. (5) the ability to collaborate and integrate work and the scalability of such collaborations.

20 CHAPTER 3. SURVEY Table 3.2: Software versus hardware innovation in the RepRap community

Software Hardware Sample size(s)
Level of innovation 101 26% 189 49% 384

Types of innovation

New functionality^{a}  50 50%  69 37%  101, 189
Convenience  77 76% 123 65%  101, 189
Performance  41 41% 100 53%  101, 189
Novelty  33 33%  42 22%  101, 189
Level of collaboration  26 26%  62 33%  101, 189
Free revealing  62 61% 121 64%  101, 189
No exclusion / non selective  45 73%  98 81%  62, 121

Diffusion of innovations

Expected diffusion  30 30%  42 22%  101, 189
Local diffusion only  0 0%  3 18%  12, 17
Ease of adoption  11 11%  49 26%  101, 189

Adoption blockers

Too specific to user need  40 40%  30 16%  101, 189
Too experimental  57 56%  88 47%  101, 189
Benefits not apparent  3 3%  17 9%  101, 189
Long time to implement  5 5%  24 13%  101, 189
Sticky information  5 5%  7 4%  101, 189
Expensive  1 1%  6 3%  101, 189
Difficult to integrate  7 7%  11 6%  101, 189

(a) The cumlative amount of sampled operators involved.

(b) Depicted on a 10-log scale.

Figure 3.1: The cumlative amount of sampled operators involved.

∗ Note that the actual number of operators is higher, depending on the ratio between population and sample size. This ratio is rougly estimated to be 5:1 or higher.

Confronting theory with practice

Clearly, the prevalence of open modes of production depends on access to the required tools and informational resources and incentives to participate. As it usually is a product of the interactions between many individuals, the cost and incentive structures are essential to understanding their behavior. Open source production is facilitated by three major factors. Firstly, an individual participant’s low fixed and incremental costs to production and integration of that which is produced. Secondly, incentives that justifies the incurring said costs, if applicable. Thirdly, open collaboration as a means to spread the workload and have access to the much larger collective assets that help achieve the individual goals. In this chapter we will go over each of these factors, as they relate to software production and production of physical objects.

4.1 Tools of production and distribution

The tools required for software production are widely available and cheap, as pointed out, among others, by Lakhani and Panetta (2007, p. 106). This is consistent with the observation that a lot of development tools have been created by open source communities, often because it helped the participants in their daily work. Of the more than 230,000 projects listed on SourceForge, a popular site where open source projects can be hosted, 34,000 fall in the category ”Software development”. It contains many examples of tools that are of high quality and that gained significant prominence even in the presence of the large commercial and initially proprietary market. Moreover, all of the open source tools can, by definition, be distributed at no charge. Clearly, the availability of affordable, high quality development tools helps lower the barriers to production of software.

After initiation of a project, collaborative production requires replication of the current state of a project and distributing the locally made changes back to the project’s source code repository. Distribution and testing of the whole software product can be done at a close-to-zero costs and no third party needs to be involved to fix a bug (Ibid., von Hippel and von Krogh , 2006, p. 22).

The private transaction costs can be low enough to justify the private benefits derived (a better product). Sharing the modification for the public benefit of others often involves minimal effort and often has some private benefits.

The design process for physical objects is increasingly digitized, thanks to increasingly powerful and affordable computer aided design (CAD) software. This results in further codification of designs and low transaction costs for replicating the results and sharing the workload. A web page with some CADfiles and instructions can suffice to enable others to replicate a result and build on it.

Potential users of an innovation collectively already hold a major knowledge assets that are required to create the innovations, because of their access to need-related and context-of-use information (Shah, 2005). Another major component is solution information, which can be acquired through trial-and-error experimentation and which can be shared in a community (proved viable by Wikipedia). What is missing are access to prototyping tools and resources and the ability to distribute private prototyping costs among participants.

Chapter 5 Conclusions

24

Bibliography

Abdelkafi, N., Blecker, T., and Raasch, C. (2009). From Open Source in the Digital to the Physical World: A Smooth Transfer?

Allen, R. (1983). Collective invention. Journal of Economic Behavior and Organization, 4(1):1–24.

Amabile, T. M. (1998). How to kill creativity. Harvard Business Review, 76(5):76– 88.

Ariely, D., Kamenica, E., and Prelec, D. (2008). Man’s search for meaning: The case of legos. Journal of Economic Behavior & Organization, 67(3-4):671–677.

Balka, K., Raasch, C., and Herstatt, C. (2009). Open source enters the world of atoms: A statistical analysis of open design. First Monday, 14(11).

Baxter, P. and Jack, S. (2008). Qualitative Case Study Methodology : Study Design and Implementation for Novice Researchers. The Qualitative Report, 13(4):544–559.

Benkler, Y. (2006). The Wealth of Networks: How Social Production Transforms Markets And. Yale University Press.

Dahlander, L. and O’Mahony, S. (2008). Progressing to the Center: The Antecedents and Consequences of Lateral Authority.

Deci, E. L., Koestner, R., and Ryan, R. M. (Spring 2001). Extrinsic Rewards and Intrinsic Motivation in Education: Reconsidered Once Again. Review of Educational Research, 71(1):1–27.

Ellis, T. J. and Levy, Y. (2008). Framework of Problem-Based Research : A Guide for Novice Researchers on the Development of a Research-Worthy Problem. Informing Science, 11.

Franke, N. and Shah, S. (2003). How Communities Support Innovative Activities: An Exploration of Assistance and Sharing among End-Users. Research Policy, 32(1):157–178.

Haefliger, S., von Krogh, G., and Spaeth, S. (2008). Code Reuse in Open Source Software. Management Science, 54(1):180–193.

Herstatt, C. and von Hippel, E. (1992). Developing New Product Concepts Via the Lead User Method: A Case Study in a ”Low Tech” Field. Journal of Product Innovation Management, 9:213–221.

Lakhani, K. R. and Panetta, J. A. (2007). The Principles of Distributed Innovation. Innovations: Technology, Governance, Globalization, 2(3):97–112.

Lakhani, K. R. and Wolf, B. (2005). Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects in Perspectives on Free and Open Source Software. MIT Press, Boston, MA.

Lather, P. (1992). Critical Inquiry in Qualitative Research: Feminist and Poststructural Perspectives: Science “After Truth”. Theory into Practice, XXXI.

Lüthje, C. (2003). Customers as Co-Inventors: An Empirical Analysis of the Antecedents of Customer-Driven Innovations in the Field of Medical Equipment. In Proceedings from the 32th EMAC Conference, Glasgow.

Lüthje, C. and Herstatt, C. (2006). User-innovators and “local” information: The case of mountain biking. Research Policy, 34(6):951–965.

Lüthje, C., Herstatt, C., and von Hippel, E. (2002). The Dominant Role of ”Local” Information in the User Innovation The Case of Mountain Biking. SSRN Electronic Journal, pages 1–32.

Meyer, P. B. (2003). Episodes of Collective Invention.

Nuvolari, A. (2004). Collective invention during the British industrial revolution: the case of the Cornish pumping engine. Cambridge Journal of Economics, 28(3):99–119.

Osterloh, M. and Rota, S. (2007). Open source software development - Just another case of collective invention? Research Policy, 36(2):157–171.

Robottom, I. and Hart, P. (1993). Research in environmental education: Engaging the Debate. Deakin University Press.

Ryan, R. M. and Deci, E. L. (2000). Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being. The American psychologist, 55(1):68–78.

Shah, S. (2005). Open Beyond Software. O’Reilly Media, Sebastopol, CA.

Spaeth, S., Haefliger, S., and Wallin, M. (2008). Open Source Software: What we know (and do not know) about motives to contribute.

Spaeth, S. and von Krogh, G. (2007). The open source software phenomenon: Characteristics that promote research. Journal of Strategic Information Systems, 16:236–253.

Stake, R. E. (1995). The art of case study research. Sage., Thousand Oaks, CA.

von Hippel, E. (1976). The dominant role of users in the scientific instrument innovation process. Research Policy, 5:212–239.

von Hippel, E. (1988). The sources of innovation. Oxford University Press, New York.

von Hippel, E. (2005a). Democratizing Innovation. MIT Press, Cambridge. von Hippel, E. (2005b). Introduction and overview, volume 44, chapter 1, pages

1–17. MIT Press, Cambridge.

von Hippel, E. (2007). Horizontal innovation networks–by and for users. Industrial and Corporate Change, 16(2):293–315.

von Hippel, E. and Finkelstein, S. (1979). Analysis of Innovation in Automated Clinical Chemistry Analyzers. Science & Public Policy, 6(1):24– 37.

von Hippel, E. and Riggs, W. (1994). The Impact of Scientific and Commercial Values on the Sources of Scientific Instrument Innovation. Research Policy, 23(July):459–469.

von Hippel, E. and von Krogh, G. (2006). Free revealing and the privatecollective model for innovation incentives. R and D Management, 36(3):295– 306.

von Krogh, G. and von Hippel, E. (2003). Special issue on open source software development. Research Policy, 32:1149–1157.

Weber, S. (2004). The success of open source. Harvard University Press, Boston.

Yin, R. K. (2002). Case study research : design and methods. Sage Publications, Inc, Thousand Oaks ; London ; New Delhi : Sage, ., 3rd edition.