Seven observations and research questions about Open Design and Open Source Hardware

Abstract

‘Openness’ is one of the key concepts brought forward by postindustrial narratives questioning the modern repartition of roles between industries and customers. In these narratives, citizen participation in design and intellectual property management based on open source principles are the promise of more sustainable production models. In this context, openness in product design and development has been the object of growing interest and experimentation from academia, businesses and grassroots communities. As a result, numerous concepts emerged that attempt to grasp the essence of this phenomenon, unfortunately leading to overlapping, conflicting or speculative depictions. In this article, we share the understanding we gained throughout 6 years of research on Open Design and Open Source Hardware and attempt to make the difference between myths and facts. We depict an enthusiastic but realistic picture of Open Design and Open Source Hardware practices as we could observe them and deliver a structured framework to situate concepts and their differences. From this, we share seven observations leading to seven corresponding research questions and establish a research agenda to stimulate further investigations into this socially relevant and potentially ground-breaking phenomenon.

1. Introduction

Recent trends in technology and society supported the emergence of alternative narratives challenging the central role traditionally played by the firm in product creation and innovation. Grassroots initiatives challenge the separation of tasks institutionalised by the industrial revolutions and reclaim their rights over product development and production. Businesses are increasingly inclined to trust ‘the crowd’ in making valuable and constructive contributions to their own design processes. Together, these trends sketch the contours of practices characterised by some form of citizen involvement in product and technology development often referred to as Open Design. Many commentators praised the potential of these practices in social, environmental and economic terms, naming benefits such as democratisation of production, localised production as well as higher innovation rates (see e.g., Hamalainen & Karjalainen 2017; Troxler & Wolf 2017; Hamalainen, Mohajeri, & Nyberg 2018).

However, far from depicting a clearly identified and precise phenomenon, the term Open Design covers a rich landscape of heterogeneous practices. Although these practices are not necessarily new as such – some of them can be understood as a re-contextualisation of preindustrial practices enhanced by contemporary technology – the recent attention they drew led to the emergence of a profusion of concepts and partly competing denominations. The term Open Design imposed itself as the greatest common denominator, however, at the expense of explicative power. Some commentators qualified the term as a ‘catchall term for various on- and offline design and making activities’ (Tooze et al. 2014) or ‘an umbrella term for a wide range of approaches to design and creativity where professional design is challenged’ (Cruickshank & Atkinson 2014). Indeed, the scope of practices scholars and practitioners have considered to fit in ‘Open Design’ nearly exhausts the range of possible interpretations allowed by the combination of the rather vague terms ‘Open’ and ‘Design’. This term partly embraces practices that have some form of openness in common but diverge in several fundamental aspects, such as Open Source Hardware and crowdsourcing.

The profusion of competing terms and their broadness makes it difficult for practice and academic communities to grasp the essence of widely commented and idealised phenomena. This article intends to contribute to the establishment of common understanding and shared practices by confronting partly romanticised definitions with the current state of empirical observation. Leaning on the understanding we acquired throughout 6 years of collaboration within European research projects on this topic, we attempt to deliver a picture of Open Design that makes the difference between myths and realities and deliver an enthusiastic but realistic picture of a phenomenon whose fate is still to be written. From this, we intend to shed light on aspects of Open Design that require further investigation, either to better understand practices or to alleviate barriers to their further development. Especially interesting in the context of the Design Science Journal and the thematic collection ‘Open Design and Open Source Hardware Product Development’ the authors are co-editing is the question, how far new design practices gathered under the label Open Design challenge available descriptive theories of design and established prescriptive design methods. We approach these challenges by focussing on the crossroads between Open Design and Open Source Hardware, a phenomenon we term in this article Open Source Product Development and define as the development of Open Source Hardware products performed in a collective process allowing the participation of any interested person.

In the first part of this article, we discuss the relation between existing definitions of Open Design and affiliated practices and deliver a structured framework allowing to situate concepts and their differences. In the second part, we share seven observations about Open Design and especially Open Source Product Development. We use these observations as hooks to bring to the foreground open issues in Open Design that cover three essential questions (as illustrated in Figure 1): What do we refer to exactly when we refer to Open Design? How does Open Design work and how different is it from ‘closed’ design? When is Open Design a successful practice? From these open issues, we formulate seven research questions aimed at showing directions for future research. In a concluding and more looking-forward discussion, we establish a catalogue of recommendations for research and policy making to support the further development of Open Design practices.

Figure 1. Seven open issues addressed in the research programme discussed in this article.

2. Coining the term ‘Open Design’

This section aims at delivering a consistent picture of Open Design as encountered in practice and literature. We first deliver a lexical analysis of the expression ‘Open Design’ covering the maximal scope of practices embraced by this concept. This provides the necessary framework to situate individual definitions, appreciate their differences, and relate the concept of Open Design with partly competing or overlapping concepts. This allows us to specify the perspective this article adopts on Open Design in more precise terms.

2.1. About design(s)

The word ‘design’ may either refer to a process or to the outcome of a process (Heskett 2001) like in the sentence ‘I designed this machine’ and ‘have a look at my design’. Similarly, the attribute ‘open’ in ‘open design’ can either apply to a product or a process. This is reflected by Huizingh (2011) who introduced the concepts of ‘process openness’ and ‘product openness’ in an effort to refine the concept of Open Innovation as defined by Chesbrough (2012). Process openness is a matter of reaching out for interaction with external people – these people being eventually customers, citizens or employees of other companies. In contrast to this, product openness is a matter of information and intellectual property management applied to the intermediary objects (Boujut & Blanco 2003) and the outcomes of a design process. Here, the focus is less about what contributors can do within the common design process with the information they accessed from this process, but more about what they can do outside this process with this information at hand (i.e., replicate the product and sell it for their own account).

The dichotomy between product and process openness brings Huizingh (2011) to define three cases of Open Design they name ‘public innovation’, ‘private open innovation’ and ‘open source innovation’. Public innovation, alternatively called downloadable design by Boisseau, Omhover, & Bouchard (2018) refers to the free revealing of product-related information after completion of a closed product development process. This concept applies to development projects casually referred to by Stirling & Bowman (2020) as ‘open-when-ready’, that is, development projects whose results are published as open source once they reached a maturity level that is deemed as satisfactory by the authors. Private open innovation, alternatively called crowdsourcing or social product development by Peterson & Schaefer (2014) and Wu et al. (2015), refers to an open development process that is centralised around a formal organisation (company or institution) and whose outcomes are protected. Open source innovation is defined by Raasch, Herstatt, & Balka (2009)) as the ‘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 nonmarket exploitation’. Geyer et al. (2012) further distinguishes between community or company-driven approaches to open source innovation. The company-driven perspective on process openness implies leading co-design activities involving external people, hence soliciting external personal resources to take on and push forward previously internal processes. The community-driven perspective implies a process that does not belong to an individual company but to a community¹ of people whose ownership towards the project is not bound to their affiliation to one or another organisation.

It is worth noting that the design process is not a monolithic entity but includes a network of related activities performed in parallel or in sequence, as illustrated by design process models like Pahl et al. (2007). This aspect is acknowledged by Aitamurto & Hussain (2015) who discuss the appropriateness of different forms of Open Design for each phase of the product development process. For example, they suggest that crowdsourcing – as an approach potentially yielding novel solutions whose feasibility needs to be checked by experts – may be particularly helpful in the need-finding phases of the development process. In contrast, adopting product openness may be more useful in later phases of the development process like prototyping and testing. Therefore, it would be more accurate to talk about open processes than an open process.

2.2. About openness

The word ‘open’ implies the idea of interaction between an inside and an outside, as in the concept of Open Innovation used in innovation management (Chesbrough 2012). Huizingh (2011) further distinguishes between two forms of interaction in this context: inbound and outbound flows of information. Inbound interaction refers to internal use of external knowledge and outbound interaction refers to external use of internal knowledge. From there, there is a large area of possible interpretations of what these interactions could look like. As Avital (2011) notes, ‘“openness” is a recurring and increasingly frequent theme in recent buzzwords that populate the discourse on the forefront of technology’. For Pomerantz & Peek (2016), ‘the word “open” has been applied to a wide variety of words to create new terms, some of which make sense, and some not so much’. Similarly, what openness means applied to physical products can be interpreted in different ways. Openness appears to be a gradual and multidimensional concept (Balka, Raasch, & Herstatt 2010; Bonvoisin & Mies 2018) hiding more or less precise requirements. The most cited factors of openness across literature are the trichotomy introduced by Balka et al. (2014): transparency, accessibility and replicability (see definitions in Table 1). While this trichotomy provides a useful framework to coin the concept of openness, it remains itself for a large part fuzzy, multifactorial, and there is no concrete evidence that it represents what is lived in practice. For instance, while replicability includes ‘the right of the community to produce instantiations of (parts of) the design’, it remains unclear what the ‘community’ is. Is it made of a controlled set of selected external people interacting on a secured platform or is information shared with the general public through publicly accessible online platforms? Also, it does not tell whether the distribution or commercialisation of the produced ‘instantiations of (parts of) the design’ is granted to this community.

Table 1. Openness factors introduced by Balka, Raasch, & Herstatt (2014).

The prevalent, if not only, school of thought that delivered a narrowed down definition of openness applied to products is the Open Source Hardware community. The Open Source Hardware Statement of Principles 1.0 maintained by the Open Source Hardware Association (OSHWA) defines Open Source Hardware as ‘hardware whose design is made publicly available so that anyone can study, modify, distribute, make and sell the design or hardware based on that design’ (Open Source Hardware Association 2016). While this definition addresses product openness only, it delivers precise principles as preconditions to it. Among these are four fundamental rights (DIN 2020) – the right to study, to modify, to make and to distribute the documentation of a piece of hardware or the piece of hardware itself – as well as core principles of the Open Source Definition such as nondiscrimination against persons or groups and nondiscrimination against fields of endeavour (Open Source Initiative 2007).

2.3. Ambiguities of term usage

Another key to understanding Open Design as reported in literature is to consider the difference between definitions stricto sensu and the way they are used. For instance, Aitamurto & Hussain (2015) define Open Design as ‘public access to participation in the design process and to the product resulting from that process, as well as the data created in the design process, including technical details and other data and content gathered or generated during the process’. Therewith, they define Open Design as a practice combining process and product openness altogether, hence matching with the definition of open source innovation we mentioned earlier as one category of practices among the family of Open Design. However, in the same article, Open Design is used to refer to the whole family of practices, including crowdsourcing. While they define Open Design as a combination of process openness and product openness, the way they used the term indicates that they mean to define Open Design as the presence of product or process openness.

Similarly, while the term Open Source Hardware as defined by the Open Source Hardware Association (2020) solely refers to product openness, the very concept of open source is generally understood as an enabler of participative development processes, if not as a product development approach itself. For Serrano (2017), Open Source Hardware ‘naturally induces collaboration’, and for Balka et al. (2010), the concept of Open Source Hardware goes hand in hand with the idea of developer community. For Moritz, Redlich, & Wulfsberg (2018), Open Source Hardware is a ‘decentralised and collaborative model of value creation’ where ‘people jointly develop and freely share designs’. In the context of Open Source Software, Gacek & Arief (2004) stated that ‘the term open source has been widely used to describe a software development process’. This is clear in the Best Practice Criteria for Free/Libre and Open Source Software (FLOSS) maintained by the Linux Foundation Core Infrastructure Initiative (Core Infrastructure Initiative of the Linux Foundation 2020): best in class FLOSS projects are those who, among others, set up the necessary infrastructure for external people to contribute to functionality development and testing.

In that sense, the maximal scope of activities depicted under the umbrella Open Source Hardware compares those depicted under the umbrella of Open Design. The coexistence of these competing terms can be partly explained by their different contexts of emergence. For example, neither Huizingh’s nor Balka’s definitions of open source innovation mention the Open Source Definition or the Open Source Hardware definitions. While Open Design is a term created by scholars to comment on new forms of product development, Open Source Hardware is a term that emerged from practice and has been coined by hardware developers willing to flag the compliance of their practices with the ethos of the open source movement. The low adoption of the term Open Source Hardware in mechanical engineering, engineering design and design science may be due to the term ‘hardware’ itself, used as a synonym of ‘physical product’. The reason underlying the use of this rather unfamiliar term is historical: while Open Source Hardware is a phenomenon that touches upon a large range product categories, it first started with electronic hardware (as discussed in Bonvoisin et al. 2020). At the time where the term Open Source Hardware emerged, ‘hardware’ meant the electronic hardware on which open source software would run. Over time, practices evolved to integrate other kinds of hardware, like mechanical hardware, while the terminology remained.

In order to avoid these ambiguities, some authors looked for substitutes and preferred the term ‘Open Source Product Development’ (OSPD; Balka 2011; Bonvoisin et al. 2017), a term that explicitly refers to both process and product openness, makes reference to the open source school of thought, and draws a parallel with the term ‘Open Source Software Development’ (OSSD) used for example by Gacek & Arief (2004). Other authors used the terms ‘open source development’ or ‘open source design’ (Buitenhuis & Pearce 2012; Fjeldsted et al. 2012; Macul & Rozenfeld 2015; Zhang & Li 2017). The use of these terms remained limited to these authors and cannot be considered as terminus technicus so far.

2.4. Descriptive framework for Open Design practices

From the above, it appears sensible to base a characterisation of Open Design practices on the framework introduced by Huizingh (2011) in the context of open innovation. This framework characterises open innovation practices using two binary dimensions: whether the product and the process are open. We adapted this framework in Figure 2 to characterise the concepts introduced so far. In this article, we refer to Open Design as a general field of practices involving either product or process openness. We term OSPD the more specific practices implying both product and process openness. We also differentiate between proprietary hardware and Open Source Hardware on one side, and closed innovation and public innovation on the other side. Closed and Open Source Hardware refer to IP management strategies regardless of any development process. Closed innovation and public innovation refer to the (closed) process of developing either proprietary or Open Source Hardware. In the remainder of this article, we choose to name ‘conventional product development’ all processes that neither adopt process nor product openness.

Figure 2. Field of concepts in Open Design. Cell background shading indicates how far the depicted practices are under the focus of this article (dark: primary focus and light: peripheral practices). Terms in brackets are alternative terms to those used in this article.

It should be noted that the multifactorial nature of the concept of openness makes it difficult in practice to draw a clear line between a process or product that is open and another that is not, and therewith to classify products and projects into the one or the other cell of the framework depicted in Figure 2. Consequently, the relevant question from a design science perspective is less to identify whether products or processes are open, but more to characterise how open they are, and how this openness affects design practices. In line with this, Open Design as a field of practices is best represented either along two continuous openness dimensions as suggested by Boisseau et al. (2018) or along cumulative openness factors as suggested by Bonvoisin & Mies (2018). Nonetheless, the dimensions as defined in these contributions remain vague and arbitrary, meaning they offer large room for subjective evaluation and have not been backed-up by practice or academia yet.

The interplay of OSPD, Open Source Hardware and public innovation is further illustrated in the Open Source Hardware Life Cycle in Figure 3. Public innovation reveals Open Source Hardware documentation at the end of a development process performed in a private setting. In contrast, OSPD is a community-based product development process where working documents are shared publicly to encourage external contributions, according to the motto ‘release often, release early’ (referring to Raymond 1999, p. 38). In both cases, the resulting Open Source Hardware product can be the start of a new iteration of the life cycle, that is, be redesigned either in a private or in a community-based setting. This interplay allows for an evolutionary design process where different versions of a product may be developed in sequence or in parallel by different teams, either in closed or open settings. This evolutionary development process is well illustrated by the RepRap community who issued between 2006 and 2012 more than 400 versions of the original design introduced by Jones et al. (2011).²

Figure 3. The Open Source Hardware Life Cycle introduced in Mies, Bonvoisin, & Jochem (2018).

2.5. Open Design in context

As any other sociocultural phenomenon, Open Design cannot be considered in isolation but takes place in a network of intertwined concepts and contemporary movements with common motives and practices. Open Design plays a role in postindustrial visions inspired by digitalisation and the increased capacity of individuals to access fabrication capabilities. Among these visions, we can cite ‘commons-based peer production’ (Benkler & Nissenbaum 2006), ‘personal fabrication’ (Kohtala 2014), ‘direct digital manufacturing’ (Chen et al. 2015), ‘bottom-up economy’ (Redlich, Moritz, & Wulfsberg 2019), ‘distributed economy’ (Johansson, Kisch, & Mirata 2005), ‘open manufacturing’ (Gasparotto 2020) and the motto ‘design global, manufacture local’ (Kostakis et al. 2015). In opposition to the dominant modes of industrial production and consumption and motivated by the necessity to invent more sustainable alternatives, these visions praise the use of regional resources (as opposed to globalisation) and small-scale production units (as opposed to capitalistic concentration). They assert scenarios in which production responds to local needs in a flexible way and is performed close to the end-user, if not by the end-user themselves, either on their own or supported by the local makerspace. In this context, advances in information technology plays a critical role in making the difference between retrograde movement towards preindustrial era and socio-technical progress: with information shared more easily, product design and production knowledge can be pooled to increase the efficiency of small-scale production facilities.

Open Design is hardly dissociable from a renaissance of Do-It-Yourself (DIY) and from its recent reincarnation in the so-called ‘maker movement’ (see e.g., Panori et al. 2020). While not all openly designed products are meant for DIY production and not all DIY products are open source, both the open source and maker movement share a common ideal of citizen empowerment through technical proficiency and a certain form of criticism against established value creation chains (Wolf & Troxler 2016). Participation of laypeople in product creation as a means of distributed manufacturing implies a limited access to means of production and calls for the use of low-tech, a concept that has been put forward as a basis for a resilient and sustainable society (Bihouix 2020). Closely related to the above is the concept of appropriate technology, whose kinship with Open Design is mirrored by the concept of OSAT (open source appropriate technology) popularised by Pearce (2012).

Against this context, Open Design and more specifically Open Source Hardware can be seen as part of a more general movement that aims to deliver postmodern narratives to the current, unsustainable, growth-driven society and to question the modern repartition of roles between industries and customers. As such, it is rooted into values such as economic sustainability, local autonomy and human-centricity. This is reflected in some iconic Open Source Hardware projects such as Open Source Ecology’s endeavour to design a ‘Global Village Construction Set’, a ‘set of 50 open source industrial machines allowing one to “build a small civilisation with modern comforts”’ (Thomson & Jakubowski 2012). However, the same way Open Design covers a rich landscape of heterogeneous practices that come in different shades of openness (as depicted in Figure 2), Open Design practices come in different shades of ideological commitment. In that sense, Open Design does not differ from FLOSS, in which ideologically driven initiatives cohabit with more practical approaches.

At the same time, Open Design takes place in a general movement from industry away from mass production and monolithic organisational structures. By switching their attention from large scale effects to focus on higher product customisation and even market-of-one, manufacturing industries operate a transfer of some design activities from the designer to the user. While the role of a customer in mass production is limited to product choice, mass customisation and product individualisation require involving customers in product configuration and final product design steps (Koren et al. 2015). This coincides with an increased openness of firms towards multi party collaboration and experimentation with new forms of organisation (Fjeldstad et al. 2012) such as those publicised by the concept of open innovation emphasising the role of the permeability of firms’ boundaries to ideas, resources and individuals in supporting innovation (Dahlander & Gann 2010). In this context, Open Design sits at the crossroads between the new inclination of firms towards external collaboration and the appetite of individuals for technical empowerment – two motivations that converge into emerging forms of product creation.

2.6. Focus of this article

The present article focusses on the subset of Open Design practices referred to as OSPD in the framework above. It is the form of Open Design that departs the most from industrial mainstream practice and is therefore especially interesting from a design science perspective. Because it implies both process and product openness, it bears challenges today’s businesses are not familiar with and requires novel approaches in business and design practices. This means as well that it is a phenomenon that struggles to grow out of its infancy, although it is widely speculated upon in literature and actively sought after in practice communities.

At the same time, OSPD offers a publicly available empirical basis accessible through the Internet. As per the concept of OSPD, processes are conducted and documented publicly online, and outcomes are shared freely as well. Therewith, each OSPD project contributes to extend an online available corpus of product documentation and product development activity traces. These data allow studying the phenomenon to an extent that other forms of Open Design cannot offer because of their partial openness. Crowdsourcing initiatives are short windows of openness that close again once the desired result is achieved and therefore leave little trace on the Internet. While public innovation initiatives deliver public content, they per definition give no insights on the underlying development processes.

Moreover, OSPD is instantiated in the concept of Open Source Hardware which in turn offers a decent history of practices as well as sprouts of sectoral organisation (Herrera 2020; Redwine & Weinberg 2020). Recent standardisation initiatives contribute to further codification of shared practices and referencing databases allow browsing into the corpus of available projects and their outcomes³ (Bonvoisin et al. 2020). As a result, available Open Source Hardware data provides an anchor for studying OSPD practices via an empirical approach, away from speculative or programmatic research contributions spreading the literature on Open Design. Mining development project data repositories is a research method that has been widely used to study Open Source Software (see e.g., Chaturvedi, Sing, & Singh 2013; Kalliamvakou et al. 2016). Design Science Journal hosted some attempts to apply similar approaches in engineering design, either on fictional data (Ball & Lewis 2018), closed PLM databases (Gopsill, Snider, & Hicks 2019) or publicly available Open Source Hardware repositories (Bonvoisin et al. 2018). As a contribution to engineering design, a discipline with particularly deep roots in mechanical engineering, we are specifically interested in the transfer of open source development practices originating from software over electronic engineering into mechanical engineering.

To summarise, OSPD is at the same time particularly interesting from an academic perspective and challenging from a practice perspective. It opens new perspectives for the design science community to use the growing corpus of publicly available data and support their research interests.

3. Seven observations and research questions

In the following, we review salient issues the authors encountered in their research. We crystalise these issues in the form of seven ‘observations’ that are used as anchors for seven research questions that we believe to constitute an agenda for further research. These observations reflect the knowledge the authors gained throughout 6 years of research on Open Design and Open Source Hardware and is, in our opinion, worth sharing with the engineering design research community in this article. The word observation is here meant as a ‘thesis’, that is a statement our experience in the field allows us to put forward, but which remains to be investigated. These observations are put forward to prompt reflections on uncertainties about the current or future state of OSPD practices and therefore to stimulate new research.

3.1. Is there an open process or are there open processes?

A lot of what we know from OSPD is made of assumed analogies with what we know about OSSD. Because Open Source Hardware extends concepts born from Open Source Software, it appears natural to hypothesise an ‘isomorphism’ (Raasch & Herstatt 2011) between FLOSS and Open Source Hardware development practices. Nonetheless, commentators of OSPD highlighted certain limitations to this isomorphism (Müller-Seitz & Reger 2010; Raasch & Herstatt 2011; Powell 2012). One of them is the magnitude of resources required to go through a development-test-feedback loop. ‘Building’ and testing software requires no more material than those required to use the software. Any new nearly functional version of the code can be quickly installed and tested, making it easy for users to give feedback and eventually to take part in the maintenance and further development. Therewith, in theory, an OSSD project can start with very little and gather a community of developers building up an alpha version into a full-fledged software product, module per module. Building hardware generally requires more physical resources. It requires tools whose price rapidly explodes with growing expected manufacturing accuracy. Consequently, the hurdle for end-users to go through build, test and improvement loops is significantly higher. This poses a practical limitation to the possibility for an ad hoc community to develop hardware products from scratch and peu à peu the way OSSD projects can do.

And indeed, to the knowledge of the authors:

Observation #1: There is to date no example of a product development project that fully demonstrated the feasibility of OSPD from early elicitation of product requirements to the release of manufacture-ready product documentation.

The idea of community-led ‘mass collaborative product development’ projects (Panchal 2009) putting Linus’s Law⁴ into practice and providing communities with high end products, seems to be more a projected ideal than a contemporary reality. Nonetheless, literature does provide sporadic examples of development projects showing evidence of OSPD activity (Malinen et al. 2010; Müller-Seitz & Reger 2010; Macul & Rozenfeld 2015). A previous study by the authors also brought more large scale evidence of OSPD practices in the sense of product design activity that is (i) performed publicly, (ii) distributed in noncentralised networks and (iii) uses data management tools enabling any interested person to participate (Bonvoisin et al. 2018). The authors analysed the number of file changes observable in the shared repositories of 105 Open Source Hardware projects hosted on GitHub⁵ selected for representing the high end of product and process openness as well as product complexity. The distribution of file changes across project contributors over time confirmed the existence of collaborative development activity while highlighting different community governance structures, from centralised projects to loosely connected decentral networks. Nonetheless, the numbers reported by the authors do not demonstrate the existence of massively distributed development projects adopting an OSPD process from the first idea to a commercialised product. The maximum number of CAD file changes observed for each project over their complete lifetime⁶ was 7522, with a median value of 123 and average value of 509 (Bonvoisin et al. 2018). These numbers are relatively low compared with what could be expected from industrial standards. As a matter of comparison, in the automotive industry, it is common practice to have development teams recording tens of thousands CAD file changes per month. Analysing the file versioning history of a student formula car development project, Gopsill et al. (2019) reported over 10,000 changes events performed on 1400 CAD files over a formula season.

Evidence rather shows that development projects tend to limit the adoption of OSPD practices to some phases of the product development process and the product life cycle. For example, some projects may focus on feasibility assessment through the establishment of first functional prototypes (e.g., Open Source Ecology⁷, Apertus Axiom⁸ and Echopen⁹), while some others concentrate on the maintenance and improvement of an already published piece of hardware (e.g., Circular Knitic¹⁰ and Lulzbot TAZ¹¹). In other words, it seems that in the current state of OSPD practices, it would be more accurate to comment on local open processes than to expect consistent openness throughout the product development process. This observation fits with (Aitamurto & Hussain 2015) who suggests that different forms of openness may be used at different times in a same product development project. As well, because the different phases of the product development process may focus on different intermediary objects (Boujut & Blanco 2003; Vinck 2011; Affonso & Amaral 2015) and therefore require different supporting IT tools, it may not be possible to sustain an OSPD process within one tool from the beginning to the end. For example, numerous Open Source Hardware projects adopting some sort of OSPD practice use the distributed version control systems (DVCS) service GitHub as a project data repository. As a data versioning system augmented with an issue tracking system, this tool is well suited to support later design phases or formal processes like engineering change management. It is less clear whether this tool offers appropriate support for early ideation phases that require higher interaction rates and sketching mechanisms. Therewith, the possibility to adopt OSPD in a certain phase of the product development process may be bound to the availability of online supporting tools and consequently more of a transient problem faced by emerging practices than a fundamental impossibility.

This leads us to the

Research question #1: There is evidence of some form of OSPD practices but no evidence of the feasibility of OSPD all the way through the development process. Is this a transient or structural issue? That is, are the issues on the way to the adoption of an OSPD approach across the whole product development process about to be resolved? Or is it fundamentally more sensible to seek for openness for specific design activities throughout the product development process? In other words, should we seek for an open process or for open processes?

3.2. Will OSPD follow the same success path as OSSD?

Research results reported above tend to indicate that, while OSPD is a reality, we are still far away from having reached an era of ‘mass collaborative product development’ as hypothesised by Ball & Lewis (2018) and Panchal (2009). OSPD practices tend to be limited to projects of lower scale in terms of product complexity and number of developers, especially when it comes to mechanical or mechatronic products. OSPD projects mentioned in literature showed successes in development of early concepts (e.g., the OSCar project reported by Müller-Seitz & Reger 2010) and or functioning prototypes (e.g., the project Open Source Ecology reported by Macul & Rozenfeld 2015), but only few projects reach manufacture-ready designs that are actually introduced in the market, if at all.

This contrasts with the recent momentum and maturity acquired by the concept of Open Source Hardware itself, especially in the electronics sector and in academia. Nine hundred and sixty-seven pieces of electronic hardware are presently registered in the self-certification programme of the Open Source Hardware Association.¹² Companies such as Sparkfun and Adafruit Industries are highly represented in this programme and are successful in marketing open source electronic products. The two academic journals: Journal of Open Hardware and HardwareX have been established as channels for the publication of Open Source Hardware, mostly from the field of scientific instrumentation. The concept of Open Source Hardware made its way up to national standardisation organisation with the recent publication of the DIN SPEC 3105 (DIN 2020).

We see that,

Observation #2: while the concept of Open Source Hardware gained certain maturity, the transfer of open source development practices has not taken off in Open Source Hardware to the level we know from FLOSS, as exemplified by the iconic Linux project.

Since 2005, more than 13,594 people working for more than 1340 companies have been involved in the development of the 22 million lines of code constituting the Linux kernel. Since 2009, the development has been supported by a steady number of more than 200 companies (Corbet & Kroah-Hartman 2016). In 2019, Red Hat, one of the companies contributing most development resources to the Linux kernel and flagging themselves as ‘provider of enterprise open source solutions’, acquired a 3.4 billion $US revenue (Wonderlick & Walas 2019). These figures paint a picture of OSSD as a concept that made its way from an alternative to a mainstream practice in a successful economic sector. More, it established itself as instrumental in the construction of the digital economy, as Weber (2004) comments: ‘Much of the innovative programming that powers the Internet, creates operating systems, and produces software is the result of “open source” code, that is, code that is freely distributed—as opposed to being kept secret—by those who write it’.

Are there examples of this dimension and economic impact in the hardware domain? The open Instruction Set Architecture RISC-V (Waterman & Asanovic 2019) may be the example that approaches the dimensions of the Linux project to the closest. It is a large scale and well publicised initiative, has been implemented in numerous commercial applications, and has the potential to become a game changer in an industry that is so far largely controlled by major entities (Greengard 2020). Nevertheless, RISC-V is less a physical product than a recipe for building products and addresses a software-near hardware design level, far away from technological considerations of semiconductor manufacturing. The largest Open Source Hardware development project known to the authors is White Rabbit, part of CERN’s open source experimental physics facilities development strategy. The ethernet-based network technology benefited from ‘a large community of users and developers [who] have found ways of using and improving this technology in many different contexts’ (Serrano 2017).

Whether the successes gained by open source product development initiatives in the software and electronic sectors is transferable to mechanical products remains an open question, as no project of this size has emerged in this context yet. Whitney (2002) delivers arguments supporting the idea that the transfer of open source practices from software to electronic hardware may be simpler than from software to mechanical hardware. They defend the idea of a fundamental complexity leap between electronics and mechanical design. Electronic hardware is a very standardised field where components are purchased off the shelf. But this is not the case for mechanical hardware where nonstandardised free form components play a large role. ‘In [mechanical] design, there is […] no cell library from which parts can be drawn, with a few exceptions. These exceptions are mainly such items as fasteners, motors, valves, pipe fittings, and finishes like paint’. Certainly, the emergence of open source development practices in mechanical engineering suffers from a historical delay. It took some decades for these practices to transfer from software to electronic hardware and from electronic hardware to mechanical hardware. This phase shift is certainly reinforced by differences in the duration of product development cycles between disciplines. Release cycles in software development are significantly shorter than in the development of mechanical products, and so may be the adoption rates of new practices. Nevertheless, the question remains whether the absence of large scale open source mechanical product development projects is the result of a time gap resulting from later onboarding or whether there are structural barriers to such adoption.

This leads us to the

Research question #2: Is OSPD on the way to the same success as OSSD? Is there a trend towards a greater adoption of OSPD practices and the emergence of best practices to an extent that is observable in OSSD? What are the main drivers and barriers to the adoption of OSPD practices?

3.3. Are alternative design process models required?

The nonsequential, unpredictable and complex nature of design makes product development a particularly challenging process to manage. Design process models (PDP) help cope with these challenges as ‘enablers of coordination’ allowing product development teams to align their mental models (Wynn & Clarkson 2018). It seems reasonable to hypothesise that such an alignment is even more challenging in the context of distributed design processes involving participants from different organisations or even nonaffiliated participants, hence underlining the importance of having appropriate design process models at hand.

However,

Observation #3: it is not clear to what extent available design process models apply in OSPD, since these models reflect “orthodox” industrial practices Open Design tends to challenge.

Popular procedural models like the Vee model of systems engineering (VDI 2004) or the systematic approach to product development by Pahl et al. (2007) and VDI (1993) have been developed based on experience gained in organisations from space, transportation or building sectors and especially on large scale projects. These processes are based on an ideal of controlled convergence of the design process towards predefined and highly formalised product requirements. This ideal is absent from what we know of OSSD projects and would apply to OSPD projects assuming an isomorphism between open source software and hardware. Indeed, in OSSD, and by extension in OSPD, refined product designs tend to emerge from an evolutionary learning processes where ‘stable versions […] co-exist with experimental versions’ (Raasch & Herstatt 2011), or from an ‘experimental tree […] where innovative variations and experimentations are generated, tested, and selected to become a part of the stable tree where further refinement and improvement are conducted’, as Lee & Cole (2003) word it.

From this, it seems that OSSD/OSPD projects are less interested in controlling convergence than in encouraging divergence – a behaviour that may be explained by the governance model at stake. Participants in OSSD/OSPD projects operate a self-selection (Müller-Seitz & Reger 2010; Howison & Crowston 2014) of and even self-identification of tasks (Mies et al. 2018) that is little compatible with a centralised hierarchy and with clearly defined project and resource plans as usual in product development. As a result, product development can be less considered as a project with clearly defined and managed inputs, outputs and timeline, than as an ongoing process of continuous improvement by a community of interested people. The other side of the coin is that this induces a challenging turnover among contributors (Dai et al. 2020).

These alternative management and governance are reflected at the activity level in the widespread use of DVCS.¹³ Originating from OSSD, these systems are adopted in OSPD practices although they depart from the traditional Product Data Management systems used in engineering. Instead of a versioning logic implying a central vault and exclusive write access managed through check-in/check-out processes, DVCS allows each user to edit a local copy of the common repository and allows the coexistence of different development branches. Which of these copies and branches acts as reference repository is a matter of agreement within the group of developers. This agreement can be revised, and subteams can branch out from the original stream to create a ‘derivative’ of the original product. The idea of product derivative of course also exists in conventional product development where patents disclose product information while forcing competitors to develop them further to stay in the race. Nonetheless, the originality of OSPD is to transcribe this evolutionary mechanism at the activity level directly in the day-to-day development tools. While DVCS provide practical tools to branch merge conflicts, they also let the door open to branching out in case conflicts are too big to be resolved.

While OSPD differs on some points from what we termed here ‘conventional product development’, there is little chance that it would challenge product design and development textbooks such as Pahl et al. (2007) and Ulrich & Eppinger (2011). No matter how design is made, it still requires activities like ideation, concept selection, embodiment design and prototyping to be performed in a mix of chronological sequences and iteration loops. Even in compressed forms like in hackathons, design still involves ‘initial divergence in order to search for and understand a problem, convergence onto a specific design opportunity, divergence during the development of the solution, a final convergence via testing of the design, and the preparation and delivery of the final pitch’, a pattern that ‘closely aligns with the four phases of the well-known Double Diamond design process’ (Flus & Hurst 2021). Nonetheless, the report Macul & Rozenfeld (2015) on the spearhead OSPD project ‘Open Source Ecology’ tends to indicate that forcing stage-gate-like PDP models into an open source development community has limited potential. The researchers found the formalised PDP not to be used in practice by project contributors, maybe because it is defined in a way that mimics top-down hierarchical organisations. In line with this, Dai et al. (2020) observed in OSPD projects limited use of project and task management tools as well as low motivation to perform some key activities such as documentation. They underline that the volunteer-based participation, the do-ocracy decision-making style and the high turnover of OSPD participants makes it difficult to adopt conventional tools for OSPD project management.

Numerous factors may contribute to the difficulties encountered by these authors. One option would be to accuse the lack of design knowledge and design proficiency of OSPD projects members. Another would be to consider that the model of the ‘Bazaar’ by Raymond (1999) opposes the ‘Cathedral’ distribution of work in hierarchical organisations as it simply does not work in the context of open source development of tangible products. Another more constructive stake would be to acknowledge that while the widely acknowledged sequence of development phases (e.g., conceptual design, embodiment design and detailed design) may be conserved, Open Design may challenge configurational aspects of the PDP that we know today and require the development of new explicative and prescriptive design process models.

This leads us to the

Research question #3: To what extent can available design process models reflect OSPD practices? Is there a need for alternative design process models reflecting the specific characteristics of OSPD? In other words, is OSPD just like an “opened” conventional PDP or is it a radically different approach to product development processes?

3.4. What design features support openness?

An aspect of the multifaceted concept of openness as encountered in practice beyond the opposition product/process openness introduced by Huizingh (2011) is what we suggest naming here ‘structure openness’. As Gavras (2018) highlights, product and process openness are not ‘inherent properties’ of a given product. Product openness is a matter of intellectual property, documentation effort and public availability of technical documentation. Process openness is a matter of governance and coordination of the product development process. Whether a product is the result of an open process or whether its documentation is publicly shared does not say anything about the product design itself in the sense of product definition. ¹⁴ It does not inform about product characteristics such as form, functionality, architecture, aesthetics or complexity, to cite only a few.

Consequently, product characteristics themselves are largely absent from debates around Open Design in literature and in standards for Open Source Hardware. Only a few authors have linked product characteristics with the concept of openness. Ostuzzi et al. (2016) define openness as the degrees of freedom offered by a product so it can be re-appropriated and adapted to another context than its original context of development. This is similar to Brulé & Valentin (2016) who define openness as ‘the inclusion of people and their values during the project framing and ideation process’ and as ‘a space left to users in the formalisation process (choice of functions, interactions, aesthetics…)’ and therewith as the design of low constrained and customisable products. For his part, Kadushin (2010) states that a product must be ‘produced directly from file by CNC machines and without special tooling’ to qualify as Open Design.

Yet,

Observation #4: When parsing through catalogues of open source products, some recurrent design principles and design styles can be observed, especially when Open Design is used in combination with participative prototyping or production, i.e., when non-professionals are expected to reproduce the design with DIY means.

Among these we can cite:

1. (i) use of CNC sheet cutting for creating volumes (Figure 4a–c) in order to avoid complicated free forming processes when materials or part sizes are not compatible with three-dimensional (3D) printing (Figure 4e). The underlying idea is to adopt an integrated product-process design approach that considers the limited production capabilities of the stakeholders involved in product creation. In cases where these stakeholders are majorly laypeople, production processes are limited to production capabilities the general public has access to.

   

   Figure 4. Examples of open design and open source products: (a) Colorado Top Bar Beehive, © 2017 Aker Kits, (b) Scale model of WikiHouse system 1.0 and 2.0, Martin Luff, CC BY-SA 2.0, (c) Lamp, © Ronen Kadushin, (d) XYZ spaceframe Vehicles, © N55 and Till Wolfer and (e) Poppy humanoid robot, Inria, Poppy-project.org, Photo H. Raguet.

2. (ii) use of reversible joining techniques such as mortise and tenon (Figure 4a,b) or nuts and bolts (Figure 4d) to accommodate for possibility of error in the assembly process, to enable disassembly for product update or parts reuse. The underlying idea is to foster user agency along the product life cycle, that is, to support users in performing value creating or saving processes such as customising, repair, recycling and repurposing.

The presence of identifiable design styles across open source products indicates that there may be some dependency between product and process openness on the one hand, and some other product characteristics on the other hand. It indicates that, potentially, the use of certain design principles facilitates product or process openness, or that the adoption of an Open Design approach induces certain design styles.

Modularity is one of the inherent properties of hardware which is often mentioned as a key enabler of openness. The appetite for modularity in Open Source Hardware communities is reflected in the lego-like design style of some iconic projects like OpenStructures, Wikihouse or XYZ Cargo and is a key design principle for DIY production (Bonvoisin, Prendeville, & Galla 2017). One of the arguments behind the importance of modularity in Open Design is that it is ‘a form of task decomposition’ (Dafermos & Söderberg 2009) and therefore influences the organisation of production and development. For Kostakis & Papachristou (2014), modular product design is one of the key conditions for the emergence of commons-based peer production. Product structure and organisational structure of development teams also go hand in hand, as stated in the often-cited ‘mirroring hypothesis’, according to which ‘organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations’ (Conway 1968). MacCormack, Baldwin, & Rusnak (2012) empirically confirmed that modular design is characteristic of the OSSD development model in general and that products developed by loosely coupled organisations are more modular than those developed by tightly coupled organisations. It may also be reasonable to expect such correspondence between product and organisational structure in Open Design. This would in turn indicate that product modularity is a success factor of Open Design projects.

This leads us to the

Research question #4: What makes a product appropriate for Open Design and for what products is Open Design appropriate? Are there design features that facilitate success in Open Design endeavours? What design principles can be identified as best practices in Open Design?

3.5. What could be the ‘Linux’ of open hardware?

A significant marker of the maturity of OSPD practices would be the existence of a product like what Linux represents in OSSD: a type of product that is at the centre of a flourishing ecosystem of companies and individual contributors; a flagship product setting standards and practically demonstrating the relevance of OSSD practices. Yet, what kind of physical product would (i) be of such generic usefulness akin to an operating system so that many stakeholders would have an interest in collaborating towards a shared product design and (ii) require manufacturing techniques that are accessible to individual contributors?

Observation #5: RepRap is maybe the Open Source Hardware technology that gathered the most success and generated most business. However, RepRap is less a project than a multitude of initiatives from which emerges a decentral and evolutionary design process. There is to date no Open Source Hardware product that is the object of centrally coordinated collaborative design activity from an ecosystem of businesses.

Possible candidates would be open architecture products (OAP) as defined by Koren et al. (2013): products whose ‘components (i.e., modules) can be added to its original structure or swapped in order to change product features’. Generic problem solving machines such as personal computers and smartphones are obvious implementations of this concept. They offer a backbone that itself offers no end-user functionality but rather allows running application specific modules. Open source computers such as the MNT Reform¹⁵ provide examples of OAP where both the core product and the modules can be open source. Microcontrollers such as Arduino and BeagleBoard¹⁶ are other examples where both the core product and the modules can be open source physical elements. The authors of the present article do not know of any existing implementation of open source OAP beyond electronics so far. Koren et al. (2013) also do not provide such examples but speculate on their emergence, for example, in the automotive industry, where car interiors could be designed by the customer, the same way airplanes’ ‘interior is completely customised to meet the needs of the individuals that use the plane’. However, manufacturers of consumer or standalone products such as computers, cars or machine-tools have little incentive to converge towards shared solutions but have rather a drive to diverge in order to seize market shares. Consequently, the potential of such products in gathering a lively community of business and individual contributors may be limited.

In contrast, infrastructures may be good candidates since their success depends on a certain level of openness. Infrastructures like transportation, telecommunications or electricity transport networks are built and maintained by ecosystems of stakeholders sharing clear interfaces. These interfaces are built on standards or shared specifications that are not far away from a full product design in the sense of OSPD. Therefore, the leap between shared standards to shared product designs is not impossible to overcome. However, it is unlikely that nonaffiliated individuals could participate in the development of such shared designs and therefore unlikely that there is enough drive to make the leap. In that case, the future of OSPD rather points towards increased company engagement as it has been the case in OSSD and a potential for such companies to organise in standardisation initiatives as well.

Another opportunity for an ecosystem of contributors sharing common interests to emerge and overcome the drive for divergence is to switch from design to meta-design. That is, designing product meta-models allowing to generate numerous variants instead of designing one single product. Fischer & Scharff (2000) define meta-design as ‘activities, processes and objectives to create new media and environments that allow users to act as designers and be creative’. Kyriakou, Nickerson, & Sabnis (2017) define metamodels as ‘information to generate a range of related models, a family of designs’. Mining in the 3D-model sharing platform Thingiverse,¹⁷ they observed that 3D metamodels are reused more often than the 3D models they generate, indicating that metamodels offer a greater common ground for a community to build on.

This leads us to

Research question #5: What characteristics would make a product or a system a possible “Linux” of hardware, i.e., a product whose design is of interest for an entire ecosystem of businesses and people? How will value chains for production and manufacturing be organised in open source hardware ecosystems? What actors (B2B/B2C, private/public entities, corporates/SMEs, employees/freelancers, global/local, etc.) will emerge and contribute to the building of such ecosystems?

3.6. How diverse are OSPD practices?

We defended the idea that there is not one form of OSPD but rather a complex field of related practices. Consequently, caution must be taken in generalising research results and applying observations made in one specific OSPD project to another context. This is acknowledged by Müller-Seitz & Reger (2010) while reporting the learnings from their analysis of the OSCar project, stating that ‘such data risk being idiosyncratic and should not be generalised’. This is another aspect that can be ascribed to the isomorphism between OSPD and OSSD – a context in which the difficulty in generalising research results is a known issue. For Broca (2013), ‘each [OSSD] project establishes regulation mechanisms that make it distinct.’¹⁸ Healy and Healy & Schussman (2003) note that ‘the highly stratified structure of project development suggests that broad generalisations about the “OSS approach” or the “OSS community” or “OSS developers” may be much too broad’. In line with this, Ehls (2015) warns against the fairy lights of considering single case projects and especially successful projects as representative for the entire phenomenon.

This issue is particularly challenging in OSPD since:

Observation #6: OSPD practices have almost exclusively been reported in the form of isolated case studies.

This excludes some of the own work of the authors who undertook quantitative data acquisition campaigns on large numbers of Open Source Hardware and OSPD projects. A comparative analysis of interviews with leading figures of 23 Open Source Hardware development initiatives performed in 2017 highlighted a large diversity of motivations and approaches in terms of collaborative development processes (Bonvoisin et al. 2017). An analysis of the public documentation of 132 Open Source Hardware development initiatives showed that the diversity was mirrored by the content and the scope of the documentation published by these initiatives (Bonvoisin et al. 2017). This study confirmed the coexistence of different approaches to Open Design and led to the development of the Open Source Hardware Lifecycle depicted in Figure 3 and the categorisation of Open Design practices presented in Figure 2. The further analysis of the versioning control history of 256 repositories helped to refine this categorisation and depicted Open Source Hardware development as a heterogeneous field filling a continuum between OSPD and public innovation practices, between lively communities of contributors and dormant projects (Bonvoisin et al. 2018). OSPD practices themselves have been found to follow diverse organisational patterns with different levels of centralisation and work distribution, hence revealing different internal governance policies. This is in line with what Aksulu & Wade (2010) suggest in the field of OSSD: unlike ‘proprietary systems that are designed for well-defined purposes, the objectives of open source systems are often loosely defined and allow contributors great freedom to work on areas they find interesting. [… Consequently], open source systems are not fixated on technology outputs only, and typically produce people and process outputs with equal emphasis’. This larger scope provides greater room for differences in approaches to product development. This is reflected in observations that OSPD projects tend to be moved by a wide array of motivational drivers (Li et al. 2017) and to define success in a not less diverse way.

The diversity of motives and practices results in a diversity of OSPD project profiles that challenges the generalisation of research results. This diversity may further be blurred by the temporal dimension of this emerging phenomenon: what is true about OSPD today may not be true tomorrow since some characteristics of these practices may be more transitional than structural. Nonetheless, there is the issue of over-generalisation on the one hand, and the stance that generalisation is impossible on the other hand. A more reliable and detailed typology of Open Source Hardware development practices gained from large scale comparative studies would help refining the terms and appreciating the generalisability of research results.

This leads us to the

Research question #6: To what extent is it possible to further characterize OSPD practices in a way that facilitates the generation of generalizable learnings? How can dominant archetypes be characterised? Can a relatively low number of dominant archetypes represent accurately the rich landscape of OSPD approaches?

3.7. How to measure process openness?

Defining a typology reflecting the diversity of a population implies the capacity to differentiate subjects. This in turn requires the definition of relevant characteristic dimensions and the availability of metrics to situate subjects along these dimensions.

Thanks to the efforts made by practitioners to coin the concept of Open Source Hardware, the concept of product openness disposes of a solid definition and track record. The OSHWA-hosted ‘Open Source Hardware Statement of Principles 1.0’ (Open Source Hardware Association 2016) has been widely acknowledged in practice communities since years and it has been recently refined in DIN SPEC 3105 (DIN 2020). Together, these documents establish a set of minimal requirements for a product to qualify as open source and therewith provide a basis for measuring the openness of a product. At the same time, they only allow measuring openness in the interval between zero openness (none of their requirements are satisfied) and minimal openness (all their minimal requirements are satisfied) and leave out of focus any form of openness beyond minimal requirements. To date, process openness is one of these forms that lie beyond the minimal requirements set by standards.

The contrast between the well-defined formulation of product openness in standards and the lack of formal definition of process openness seem to contradict the depiction of both product and process openness as equally valuable pillars in defining Open Design and Open Source Hardware. Authors tend to agree that open processes are those which are participative in nature, although there is no commonly acknowledged definition of its nature, what participation is made of and what enables it. The closest attempt of what could be considered as a definition of process openness is delivered in the context of OSSD by the Best Practice Criteria for Free/Libre and Open Source Software maintained by the Linux Foundation Core Infrastructure Initiative (Core Infrastructure Initiative of the Linux Foundation 2020), although it is exclusively focussed on software maintenance (opposed to development) and on improving the security of software.

Observation #7: There is a contrast in the extent to which product and process openness are defined, this both in practice and academic communities. Process openness remains an ill-defined aspect of open source product development practices.

At least two approaches to process openness characterisation are conceivable. The first approach is to define a set of practices that play the role of enablers of process openness and indicate the willingness of the originators to encourage participation from a larger group. Among practices that are frequently encountered in practice or that are often referred by practitioners as best practices, the authors can cite: the use of Git repositories or Git-based repository hubs, describing a governance model, sharing a contribution guide, stating aims, use an open source or inexpensive tool chain, public issue management and flagging clear communication channels. What exact set of practices are required for participative processes to emerge or what is the influence of these practices on this emergence remains an open question today. The second approach is to seek for a characterisation of the participative design activity happening in projects seeking for process openness. In other words, answering the question ‘what defines participation’? Is there a task distribution pattern in Open Source Hardware projects (Boujut et al. 2019)? Are participative processes characterised by project member mobility from the periphery to the core within the network formed by all contributors as observed by Asri et al. (2017)? Or are social network topology indicators such as centrality and completeness more accurate representation of the participative nature of open processes, as suggested by Ball & Lewis (2018)? Padhye, Mani, & Sinha (2014) also suggest that the relative numbers of core, external and hybrid commits made by project members in project repositories is an indicator of openness towards external participation. What indicators best reflect the participative nature of open processes is also an open question today.

This leads us to the

Research question #7: What characterises an open process? Can this question be answered by academic research or yet depends on the settlement of more mature practices?

4. Recommendations for research and policy making

Based on the observations and research questions above, and taking the stance that Open Design, Open Source Hardware and especially OSPD bear socially relevant implications, we formulate a series of recommendations for research and policy making to support the further development of product development practices and to bring them to the same path towards success as OSSD (see observation #2).

These recommendations are to:

1. (i) encourage business involvement, and especially experiment with industry-led open industrialisation processes;

2. (ii) continue deblurring definitions, for example by investing in large scale comparative studies;

3. (iii) experiment with extreme openness as a way to investigate the limits of practicality in Open Design;

4. (iv) generate practical guidance based on the analysis of successful initiatives to support practitioners in their efforts to generate OSPD processes;

5. (v) push forward the standardisation efforts made on product openness and expand them to cover process openness as well; and

6. (vi) consolidate the ‘big picture’ of OSPD and Open Design as a socio-technical phenomenon addressing contemporary stress fields between society, economy and ecologies.

4.1. Encourage business involvement

While some rare pioneering businesses demonstrated the feasibility of building upon Open Source Hardware (either by releasing Open Source Hardware products themselves or appropriating externally developed ones), the authors do not know of any example of a company leading an OSPD process or participating in such a process. Yet, Open Source Hardware and OSPD may only take up and gain an audience with the emergence of a Linux-like product – an essential infrastructure product that is at the centre of an ecosystem of businesses and individual participants and generates significant economic activity (see observation #5). Companies may be encouraged to participate in such ecosystems through incentives from policy making and experience gained by other companies in live experimentation.

Specifically, it may be interesting to experiment with industry-led open industrialisation processes. Today’s practices of Open Source Hardware, OSPD and Open Design in general are largely focussed on early design processes like prototyping and technology development, as well as on distributed, hence low tech, manufacturing (see observation #1). There is no doubt that distributed design leads to viable product ideas, but relatively few products reach market readiness in Open Design settings. This is reflected in the recent attempts of the Open Source Hardware community to respond to the COVID-19 crisis (Chagas et al. 2020; Corsini, Dammicco, & Moultrie 2020). Whereas lots of prototypes have been developed as an attempt to address medical supply shortages, few of these prototypes actually entered hospitals. Actually entering markets requires products to satisfy standards and therefore to undergo tedious qualification processes that are best shouldered by conventional corporate structures (Stirling & Bowman 2020). But because qualification and more generally industrialisation processes are best hosted by companies does not necessarily mean these processes need to happen behind closed doors. Now that the relevance of open approaches in early design phases is clear, demonstrating the feasibility of end-to-end OSPD processes requires focussing on downstream processes and experimenting with business-led yet open industrialisation processes.

4.2. Continue deblurring definitions

Diversity of practices in Open Design makes it difficult to generate reliable phenomenal depictions beyond the mere report of idiosyncratic behaviours (see observation #6). Worse, it collides with our appetite for transferable learnings and leads us to make unreliable generalisations based on isolated observations.

The challenge of diversity may be addressed by investing in large scale comparative studies. Analysing the characteristics of high numbers of Open Design initiatives would allow generating typologies that could be used across later studies. This would increase the comparability of these studies and the reusability of their results. Clear archetypes would also lead to better communicability outside the academic domain into the public discourse and contribute to build trust across the general public and in businesses. Large-scale studies can take the advantage of data availability in Open Design and especially in Open Source Hardware and OSPD. Performing these studies under Open Science standards would also increase the discoverability of the examined projects and would simplify data acquisition efforts of further large-scale studies.

4.3. Experiment with extreme openness

In this article, we intentionally focussed on the form of Open Design that is the most challenging for mainstream industrial practice. Doing so, we navigated through a far-off and dangerous treading ground scarcely populated with courageous pioneering initiatives. Investigating extreme forms, pushing concepts to the extreme is a way to investigate limits of practicability. An open question of practicality in this context is to what extent design processes can be distributed and performed without central orchestration and whether distributed design requires us to reconsider existing design process models.

No matter how different Open Design may be from conventional product development, it remains design and as such it is unlikely to challenge the core of well-established design theories and models and their premises (see observation #3). To date, it seems Open Source Hardware and OSPD initiatives largely mimic the centrally structured processes at stake in conventional product development in order to fit the Bazaar into the corset of prescriptive design methods. Prevalent practice seems to recreate through the back door the controlling mechanisms that are obliterated by the absence of formal hierarchies, so that known methods remain applicable. But how would a design process look like in which activities such as requirement management and product architecting are not captured by a central authority but taken over by a swarm of participants? Such processes are partly to be observed in existing initiatives but would need to be experimented to a larger scale to understand their relevance.

4.4. Provide practical guidance

What success for Open Design initiatives and their participants means may largely vary. The typology of Open Design initiatives we advocated for above may help to see clearer. In the meantime, we suggest investigating the role of product architecture in supporting Open Design strategies, as an aspect that is independent from process and governance models and may therefore be transversal to all types of Open Design initiatives.

Product and process openness are aspects of product design that touch little upon the actual product design in the sense of ‘what the product actually looks like’, ‘what’s in it’ or ‘what the product is supposed to be’. Nonetheless, this design may largely influence both product and process openness. Depending on how the product is structured and what it is made of, product documentation may be more or less easy to author, mediate and communicate. Similarly, collaboration in loosely coupled organisational structures may be more or less appropriate. We called ‘structure openness’ an aspect of openness that is disregarded in design literature and has practical implications in Open Design (see observation #4). Modularity may play a role in facilitating breaking up tasks into work packages that are small enough to be appropriated by spontaneous contributions of volunteers operating self-selection of tasks. But other aspects of product design may also play a role, such as the complexity and discipline specialisation. Practitioners willing to engage in OSPD processes would gain from an access to practical product design guidelines with operable design principles that could indirectly support their efforts in establishing lively contributor communities.

4.5. Push forward standardisation efforts

For practitioners to make trustable claims about the compliance of their projects towards openness or simply for them to communicate their willingness to reach a certain level of openness, reference definitions are required, at best in the form of standards. Together with the OSHWA-hosted ‘Open Source Hardware Statement of Principles 1.0’ (Open Source Hardware Association 2016), DIN SPEC 3105 (DIN 2020) set a milestone by providing a definition of Open Source Hardware based on assessable criteria that allows building certification programmes. However, these initiatives only focussed on product openness and left the definition of process openness open.

In this article, we defined process openness as the collective nature of processes allowing the participation of any interested person. To explain this concept, we used terms such as ‘community’, ‘participation’, ‘volunteer’, ‘external people’ and ‘core team’. We did however not narrow down these terms nor did we explain practically what aspects of these processes exactly enable individuals who are external to a core team to volunteer and participate and therewith to form some sort of community. What is meant with ‘any interested person’ and what ‘allows’ them to do something? Some best practices are known (Open Source Hardware Association 2013; Bonvoisin & Schmidt 2017) but did not reach the same level of formalisation and general agreement than those associated with product openness (see observation #7). To bring transparency along both cornering dimensions of Open Design, standardisation efforts made on defining Open Source Hardware would need to be pursued and extended to the definition of process openness.

4.6. Consolidate the ‘big picture’

Many places in this article left the scope of engineering design and ventured into foreign disciplines. For example, as mentioned in the previous section, we use the term ‘community’ and adopt a simplistic definition that ignores questions of composition and structure of communities, not to mention underlying concepts of affiliation, participation and belonging. In Section 2.5 ‘Open Design in context’, we attempted to situate Open Design among other concurrent socio-technical phenomena, such as the maker movement and the renaissance of DIY. Doing so, we identified Open Design as an expression of postmodernity and critique of progress. These adventurous excursions in foreign competence domains reflect the difficulty to discuss the relevance and significance of Open Design from the point of view of engineering design only. Using tools from engineering design, we attempted to deliver a picture of how widespread or marginal Open Design practices are and what they are made of. The answers we delivered are at best partial. How are the chances for Open Design to become a mainstream practice and what would be the implications of such practices for society are still open questions that require transdisciplinary approaches.

5. Conclusions

Open Design, Open Source Hardware and OSPD are emerging phenomena striving to gain momentum and maturity in order to step out of marginality and to offer viable alternatives to conventional (proprietary) product creation. Carried by the new appetite of the civil society for technological independence and enabled by recent developments in information and production technologies, openness in product development is a concept that we perceive as increasingly gathering attention from pioneering businesses, policy makers and the general public. Whether this will lead Open Design practices to follow the path to success paved by their counterpart in the software sector depends on their ability to distil best practices and to generate their own methodologies. Design science research may play a role in the further emergence of Open Design by providing solid foundations for building a public discourse, defining terms, identifying success factors, pointing at challenges, and experimenting with solutions. All this being useful for policy makers and research institutes to build a research agenda that could foster the development of Open Design and OSPD. The other way round, Open Design practices challenges our understanding of the product development process and raises questions for design science.

In this article, based on the experience gathered through six years of common research, we undertook to provide an overview of the major challenges faced by Open Design as a practice as well as those faced by design research while approaching this practice. We first contributed to settle definitions by introducing a structured framework that helps situating and interpreting the rich landscape of partly competing terms encountered in academic research and in practice. We then shared seven observations that led us to formulate seven questions for further research. From these seven observations and research questions, we established recommendations for research and policy making in order to encourage a phenomenon we believe to bear social relevance and potentially far-reaching implications.

This article aims at opening a debate on this topic and calls for extensive research projects, scientific debates, and knowledge creation. We strongly believe Open Design, Open Source Hardware and Open Source Product Development will play an important role in the future of our society.