On the Open Design of Tangible Goods
Article: On the Open Design of Tangible Goods. By Christina Raasch, Cornelius Herstatt and Kerstin Balka. R&D Management. Volume 39 Issue 4, Pages 382 - 393
"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, our knowledge of its deployment outside the software industry is very limited. This paper focuses on the open source development of tangible objects, the so-called open design. We propose a generalised definition of open source development. Drawing on 27 exploratory interviews and six comparative case studies selected from a pool of more than 75 projects, we analyse the workings of open design. The analysis reveals that open design is already being implemented in a substantial variety of projects with different organisational and institutional structures."
(from the preprint version)
"Yet, “what does it mean to apply the term ‘open source’ in fields outside software development, which do not use ‘source code’ as a term of art? […] It seems the time has come to devise a new, broader term” (Economist 2004). To generalise the ‘OS model’ to a non-industry-specific level, we propose the following model, which we call Open Source Innovation (OSI): OSI is characterised 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 characterised by a non-market, noncontractual 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 non-definite set of other actors without any immediate recompense or expectation thereof. An open licence may establish rules of knowledge sharing and re-usage. 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.
Our model builds on and intersects with several of the models of collaborative development proposed in the literature (cf. Raasch/Herstatt et al. 2008). The theoretical foundation supporting OSI is laid by the private-collective model (von Hippel/von Krogh 2003; von Hippel/von Krogh 2006), whereby actors invest private resources towards the production of a public good. Within this model, OSI focuses on a collaborative development process involving several contributing actors and therefore requiring organisational mechanisms to co-ordinate the efforts expended by different actors.
OSI also needs to be related to user innovation networks or communities (von Hippel 2005; von Hippel 2007; Füller/Jawecki et al. 2007). OSI can be generated by commercial or private contributors or a mixture of both. If commercial companies participate in OSI, they may profit from using the product being developed, but may also have different objectives, e.g. an increase in sales of complementary products (Henkel 2006). The user-innovation model, by contrast, is based on “open, voluntary, and collaborative efforts of users” (Shah 2005, p. 1), meaning private or commercial, but still users. Additionally, OSI refers to collaborative development efforts on an integrated design (or a number of closely related designs or design variants), a condition that does not necessarily hold for user communities (Lüthje/Herstatt et al. 2005)."
(1) OScar: In 1999, the OScar project was initiated by Markus Merz, CEO of a small consulting firm designing e-business strategies for the automotive industry. He planned to complete a car design by virtual collaboration and then offer it to OEMs and suppliers for production. Merz set out 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 too optimistic; two factors slowing the project down were the absence of cheap or free CAD programs meeting the project’s requirements and a lack of focus and direction that accompanied the entirely decentralised approach.
After a relaunch of the project in 2005 and a redesign of the website, 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; completion is assumed to take another five to ten years.
(2) 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 create a self-replicating machine, i.e. a 3D-printer that is able to produce most of the parts needed to assemble another such machine. A commercial 3D-printer currently costs approx. US $20,000, whereas the price target of RapRap lies below US$400.
The project relies on decentralised development and production accomplished by geographically dispersed project members. Initially new members simply volunteered and were welcomed to the team. As the community grew, a core team was formed to drive and coordinate development, while maintaining a decentralised, mostly non-hierarchical structure. The first fully functional, self-replicated RepRap v1.0 (called "Darwin") was completed in June 2008 and celebrated as a great success. Next steps are the reduction of included thirdparty components, the advancement of the printing technology, and the recruiting of new community members.
(3) Free Beer: Free Beer, previously known as Vores Øl, is commonly regarded as the first open source beer. It was originally created by students in a class on copyright law at the IT University of Copenhagen together with Superflex, a Copenhagen-based artist group. They set out to illustrate how concepts of the free software movement could be applied outside the digital world. In 2005, they brewed about 100 bottles of Vores Øl 1.0 in the school cafeteria.
The subsequent amount of media attention and feedback they received came as a surprise. From these discussions of the recipe and the experiment itself, the project emerged. Superflex then took the idea further and has since released several new, revised versions based on feedback from testers. By now Free Beer has been brewed on a large number of different occasions ranging from student parties and conferences in Germany to exhibitions in Brazil. 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 and hence decided to continue and find 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.
(4) 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 nonprofit 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. 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, subsystem 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 venture-capital backed start-up company which will finish development and take on production.
(5) Open Moko: 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. Today, two years later, 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. 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.
(6) Neuros OSD: Neuros Technology, a Chicago-based spin-off of Digital Innovations (DI) 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 standardised format used by most digital devices, from MP3 players to mobile telephones and televisions.
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 successively laid open its design specifications and development process to a growing community for feedback, bug tracking, documentation, and co-development. Some parts of the design, e.g. components delivered by third party vendors, as well as corporate decision processes, remain closed to the public."
Who drives open design projects?
Mirroring findings from OSS, we 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 OpenMoko, rather closer to, but not as extreme as the Neuros OSD case, Free Beer, which unites a community of users with commercial contributors and producers, and OSGV, which set out with a community of individual contributors and researchers led by a non-profit organisation, but has been largely taken over by a start-up company.
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). Our case studies mostly corroborate this proposition. In all cases we studied, apart from Free Beer, developers with special skills are required, 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, 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."
"In all our cases except one (Free Beer), the artefact being developed is modular. Perhaps even more importantly, these open design projects make a particular effort to develop the artefact in a modular way. Thus, the open design even of very complex objects is considered feasible, as long as they can be modularised. These findings are in accordance with studies on modularity in the field of OSS (MacCormack/Rusnak et al. 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 artefact. High complexity necessitates a modular architecture, while simple objects may be amenable to open design despite modularity being low.
Our 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:
“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) However, this strategy shifts complexity to a different level, i.e. specifications, interfaces, and documentation.
Summarising first findings on the characteristics of the artefacts developed in open design we find that, first, modular objects and simple objects seem particularly well suited to open design, second, feasibility seems to depend jointly on modularity and complexity, and third, more complex, but modular designs can be completed with the help of third-party suppliers."
Loci of Production
"In our case studies, we identify three different loci of production: with external manufacturers, with the community, or with the focal organisation 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 assembled by each developer from standard parts commonly available for sale and parts printed by another RepRap according to the project design files. 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 be RepRap, at least not at this stage. Once the design is finalised, the option of involving an external manufacturer for massproduction 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 our two cases which feature production by the company coordinating 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."
Degrees of Openness
"To think of open design as entirely open, however, would be over-simplistic. In order to paint a more fine-grained picture, we draw on a distinction proposed by West (2003) between “open parts” and “partly open”. According to the ‘open parts’ strategy, the project coordinator “grant[s] all rights to a subset [of the design]”, whereas “partly open” refers to the release of a design “under restrictive terms” (West 2003, p. 1277).
Counter to the common understanding of ‘open’ design, five of our six case studies actually reveal some limitations to openness, according to either one or both elements of West’s conceptual dyad. They rely on trade secrecy, trademarks, and in some cases even patents (for OSS cf. Dahlander and Magnusson 2005). 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) we identified limitations to openness in both degree and scope, the regime varying among the components.
In other words, these designs included entirely open parts, partly open parts, and closed parts.
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 our 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 our 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 open car design, which is why actual production is deemed secondary. 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."
- Agerfalk, P. J., Fitzgerald, B. (2008) Opensourcing to an unknown workforce: Exploring
opensourcing as a global sourcing strategy. MIS Quarterly, 32(2), 385-410.
- 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.
- Chesbrough, H., Appleyard, M. M. (2007) Open innovation and strategy. California
Management Review, 50(1), 57-76.
- Dahlander, L., Magnusson, M. G. (2005) Relationships between open source software
companies and communities: Observations from Nordic firms. Research Policy 34(4), 481- 493.
- Gläser, J. (2007) The social order of open source software production. In: St.Amant, Kirk and
Still, Brian (eds.), Handbook of research on open source software: Technological, economic, and social perspectives. Hershey, New York: Information Science Reference. Hellström, T. (2003) Governing the virtual academic commons. Research Policy, 32(2), 391- 401.
- Henkel, J. (2006) Selective revealing in open innovation processes: The case of embedded
Linux. Research Policy, 35(7), 953-969.
- Müller-Seitz, G., Reger, G. (2008) Open beyond the software code? - An explorative
examination of the development of an open source car. Proceedings of the EIASM IPDM Conference 2008, Hamburg.
- Raasch, C., Herstatt, C., Blecker, T., Abdelkafi, N. (2008) Open Source Innovation - Out of
software? Proceedings of the EIASM IPDM Conference 2008, Hamburg.
- Shah, S. K. (2005) Open beyond software. In: Cooper, Danese, DiBona, Chris and Stone,
Mark (eds.), Open Sources 2. Sebastopol, CA: O'Reilly Media.
- Shirky, C. (2005) Epilogue: Open Source outside the domain of software. In: Feller, Joseph,
Fitzgerald, Brian, Hissam, Scott A. and Lakhani, Karim R. (eds.), Perspectives on Free and Open Source Software. Cambridge, MA et al.: MIT Press.
- Shirky, C. (2007) Generalizing peer production into the physical world.
- Thompson, C. (2008) Build it. Share it. Profit. Can Open Source hardware work? Wired
- Vallance, R., Kiani, S., Nayfeh, S. (2001) Open design of manufacturing equipment.
Proceedings of the CHIRP 1st International Conference on Agile, Reconfigurable Manufacturing. http://www.opendesign.org/CHIRP_Open_Design_Mfg_Equipment.pdf.