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

Excerpts below are from the preprint version in fulltext.

Kerstin Balka has extra documentation here.

Abstract:

“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.”

This research paper has two particularly interesting aspects.

First, the case studies introduction gives a status update to a few of the projects; and second, it has an extensive section with a comparison of features that are shared to different degrees by the projects studied.

Review of the Cases:

(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.”

Characteristics of Open Design Projects:

1. 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.”

2. Modularity

“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

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.”

3. 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.”

4. 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.”