2.1. About design(s)

The word ‘design’ may either refer to a process or to the outcome of a process (Heskett Reference Heskett2001) 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 (Reference Huizingh2011) who introduced the concepts of ‘process openness’ and ‘product openness’ in an effort to refine the concept of Open Innovation as defined by Chesbrough (Reference Chesbrough2012). 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 Reference Boujut and Blanco2003) 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 (Reference Huizingh2011) 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 (Reference Boisseau, Omhover and Bouchard2018) 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 (Reference Stirling and Bowman2020) 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 (Reference Peterson and Schaefer2014) and Wu et al. (Reference Wu, Rosen, Panchal and Schaefer2015), 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 (Reference Raasch, Herstatt and Balka2009)) 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. (Reference Geyer, Reise, Manav, Schwenke, Böhm and Seliger2012) 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 communityFootnote ¹ 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. (Reference Pahl, Beitz, Feldhusen and Grote2007). This aspect is acknowledged by Aitamurto & Hussain (Reference Aitamurto, Holland and Hussain2015) 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 Reference Chesbrough2012). Huizingh (Reference Huizingh2011) 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 (Reference Avital, van Abel, Klaassen, Evers and Troxler2011) notes, ‘“openness” is a recurring and increasingly frequent theme in recent buzzwords that populate the discourse on the forefront of technology’. For Pomerantz & Peek (Reference Pomerantz and Peek2016), ‘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 Reference Balka, Raasch and Herstatt2010; Bonvoisin & Mies Reference Bonvoisin and Mies2018) hiding more or less precise requirements. The most cited factors of openness across literature are the trichotomy introduced by Balka et al. (Reference Balka, Raasch and Herstatt2014): 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 (Reference Balka, Raasch and Herstatt2014).

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 (Reference Aitamurto, Holland and Hussain2015) 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 (Reference Serrano2017), Open Source Hardware ‘naturally induces collaboration’, and for Balka et al. (Reference Balka, Raasch and Herstatt2010), the concept of Open Source Hardware goes hand in hand with the idea of developer community. For Moritz, Redlich, & Wulfsberg (Reference Moritz, Redlich and Wulfsberg2018), 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 (Reference Gacek and Arief2004) 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. Reference Bonvoisin, Molloy, Haeuer and Wenzel2020). 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 Reference Balka, Bürgel, Grosse, Herrmann, Koller and Möhrle2011; Bonvoisin et al. Reference Bonvoisin, Thomas, Mies, Gros, Stark, Samuel, Jochem and Boujut2017), 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 (Reference Gacek and Arief2004). Other authors used the terms ‘open source development’ or ‘open source design’ (Buitenhuis & Pearce Reference Buitenhuis and Pearce2012; Fjeldsted et al. Reference Fjeldsted, Adalsteinsdottir, Howard, McAloone, Hansen, Rasmussen, Jřrgensen and Tollestrup2012; Macul & Rozenfeld Reference Macul and Rozenfeld2015; Zhang & Li Reference Zhang and Li2017). 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 (Reference Huizingh2011) 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. (Reference Boisseau, Omhover and Bouchard2018) or along cumulative openness factors as suggested by Bonvoisin & Mies (Reference Bonvoisin and Mies2018). 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 Reference Raymond1999, 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. (Reference Jones, Haufe, Sells, Iravani, Olliver, Palmer and Bowyer2011).Footnote ²

Figure 3. The Open Source Hardware Life Cycle introduced in Mies, Bonvoisin, & Jochem (Reference Mies, Bonvoisin, Jochem, Redlich, Moritz and Wulfsberg2018).

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 Reference Benkler and Nissenbaum2006), ‘personal fabrication’ (Kohtala Reference Kohtala2014), ‘direct digital manufacturing’ (Chen et al. Reference Chen, Heyer, Ibbotson, Salonitis, Steingrímsson and Thiede2015), ‘bottom-up economy’ (Redlich, Moritz, & Wulfsberg Reference Redlich, Moritz, Wulfsberg, Redlich, Moritz and Wulfsberg2019), ‘distributed economy’ (Johansson, Kisch, & Mirata Reference Johansson, Kisch and Mirata2005), ‘open manufacturing’ (Gasparotto Reference Gasparotto2020) and the motto ‘design global, manufacture local’ (Kostakis et al. Reference Kostakis, Niaros, Dafermos and Bauwens2015). 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. Reference Panori, Piccoli, Ozdek, Spyridopoulos and Altsitsiadis2020). 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 Reference Wolf and Troxler2016). 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 Reference Bihouix2020). 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 (Reference Pearce2012).

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 Reference Thomson and Jakubowski2012). 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. Reference Koren, Shpitalni, Gu and Hu2015). This coincides with an increased openness of firms towards multi party collaboration and experimentation with new forms of organisation (Fjeldstad et al. Reference Fjeldstad, Snow, Miles and Lettl2012) 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 Reference Dahlander and Gann2010). 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 Reference Herrera2020; Redwine & Weinberg Reference Redwine and Weinberg2020). Recent standardisation initiatives contribute to further codification of shared practices and referencing databases allow browsing into the corpus of available projects and their outcomesFootnote ³ (Bonvoisin et al. Reference Bonvoisin, Molloy, Haeuer and Wenzel2020). 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 Reference Chaturvedi, Sing and Singh2013; Kalliamvakou et al. Reference Kalliamvakou, Gousios, Blincoe, Singer, German and Damian2016). Design Science Journal hosted some attempts to apply similar approaches in engineering design, either on fictional data (Ball & Lewis Reference Ball and Lewis2018), closed PLM databases (Gopsill, Snider, & Hicks Reference Gopsill, Snider and Hicks2019) or publicly available Open Source Hardware repositories (Bonvoisin et al. Reference Bonvoisin, Buchert, Preidel and Stark2018). 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.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 Reference Raasch and Herstatt2011) between FLOSS and Open Source Hardware development practices. Nonetheless, commentators of OSPD highlighted certain limitations to this isomorphism (Müller-Seitz & Reger Reference Müller-Seitz and Reger2010; Raasch & Herstatt Reference Raasch and Herstatt2011; Powell Reference Powell2012). 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:

The idea of community-led ‘mass collaborative product development’ projects (Panchal Reference Panchal2009) putting Linus’s LawFootnote ⁴ 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. Reference Malinen, Mikkonen, Tienvieri and Vadén2010; Müller-Seitz & Reger Reference Müller-Seitz and Reger2010; Macul & Rozenfeld Reference Macul and Rozenfeld2015). 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. Reference Bonvoisin, Buchert, Preidel and Stark2018). The authors analysed the number of file changes observable in the shared repositories of 105 Open Source Hardware projects hosted on GitHubFootnote ⁵ 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 lifetimeFootnote ⁶ was 7522, with a median value of 123 and average value of 509 (Bonvoisin et al. Reference Bonvoisin, Buchert, Preidel and Stark2018). 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. (Reference Gopsill, Snider and Hicks2019) 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 EcologyFootnote ⁷, Apertus AxiomFootnote ⁸ and EchopenFootnote ⁹), while some others concentrate on the maintenance and improvement of an already published piece of hardware (e.g., Circular KniticFootnote ¹⁰ and Lulzbot TAZFootnote ¹¹). 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 Reference Aitamurto, Holland and Hussain2015) 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 Reference Boujut and Blanco2003; Vinck Reference Vinck2011; Affonso & Amaral Reference Affonso and Amaral2015) 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

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 (Reference Ball and Lewis2018) and Panchal (Reference Panchal2009). 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 Reference Müller-Seitz and Reger2010) and or functioning prototypes (e.g., the project Open Source Ecology reported by Macul & Rozenfeld Reference Macul and Rozenfeld2015), 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.Footnote ¹² 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,

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 Reference Corbet and Kroah-Hartman2016). 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 Reference Wonderlick and Walas2019). 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 (Reference Weber2004) 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 Reference Waterman and Asanovic2019) 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 Reference Greengard2020). 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 Reference Serrano2017).

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 (Reference Whitney2002) 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

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 Reference Wynn and Clarkson2018). 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,

Popular procedural models like the Vee model of systems engineering (VDI 2004) or the systematic approach to product development by Pahl et al. (Reference Pahl, Beitz, Feldhusen and Grote2007) 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 Reference Raasch and Herstatt2011), 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 (Reference Lee and Cole2003) 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 Reference Müller-Seitz and Reger2010; Howison & Crowston Reference Howison and Crowston2014) of and even self-identification of tasks (Mies et al. Reference Mies, Bonvoisin, Jochem, Redlich, Moritz and Wulfsberg2018) 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. Reference Dai, Boujut, Pourroy and Marin2020).

These alternative management and governance are reflected at the activity level in the widespread use of DVCS.Footnote ¹³ 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. (Reference Pahl, Beitz, Feldhusen and Grote2007) and Ulrich & Eppinger (Reference Ulrich and Eppinger2011). 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 Reference Flus and Hurst2021). Nonetheless, the report Macul & Rozenfeld (Reference Macul and Rozenfeld2015) 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. (Reference Dai, Boujut, Pourroy and Marin2020) 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 (Reference Raymond1999) 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

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 (Reference Huizingh2011) is what we suggest naming here ‘structure openness’. As Gavras (Reference Gavras2018) 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. Footnote ¹⁴ 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. (Reference Ostuzzi, Conradie, De Couvreur, Detand and Saldien2016) 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 (Reference Brulé and Valentin2016) 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 (Reference Kadushin2010) states that a product must be ‘produced directly from file by CNC machines and without special tooling’ to qualify as Open Design.

Yet,

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 Reference Bonvoisin, Prendeville and Galla2017). One of the arguments behind the importance of modularity in Open Design is that it is ‘a form of task decomposition’ (Dafermos & Söderberg Reference Dafermos and Söderberg2009) and therefore influences the organisation of production and development. For Kostakis & Papachristou (Reference Kostakis and Papachristou2014), 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 Reference Conway1968). MacCormack, Baldwin, & Rusnak (Reference MacCormack, Baldwin and Rusnak2012) 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

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?

Possible candidates would be open architecture products (OAP) as defined by Koren et al. (Reference Koren, Hu, Gu and Shpitalni2013): 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 ReformFootnote ¹⁵ provide examples of OAP where both the core product and the modules can be open source. Microcontrollers such as Arduino and BeagleBoardFootnote ¹⁶ 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. (Reference Koren, Hu, Gu and Shpitalni2013) 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 (Reference Fischer and Scharff2000) 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 (Reference Kyriakou, Nickerson and Sabnis2017) define metamodels as ‘information to generate a range of related models, a family of designs’. Mining in the 3D-model sharing platform Thingiverse,Footnote ¹⁷ 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

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 (Reference Müller-Seitz and Reger2010) 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 (Reference Broca2013), ‘each [OSSD] project establishes regulation mechanisms that make it distinct.’Footnote ¹⁸ Healy and Healy & Schussman (Reference Healy and Schussman2003) 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 (Reference Ehls, Herstatt and Ehls2015) 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:

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. Reference Bonvoisin, Thomas, Mies, Gros, Stark, Samuel, Jochem and Boujut2017). 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. Reference Bonvoisin, Mies, Stark and Boujut2017). 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. Reference Bonvoisin, Buchert, Preidel and Stark2018). 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 (Reference Aksulu and Wade2010) 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. Reference Li, Seering, Ramos and Wallace2017) 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

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.

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. Reference Boujut, Pourroy, Marin, Dai and Richardot2019)? 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. (Reference Asri, Kerzazi, Benhiba and Janati2017)? 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 (Reference Ball and Lewis2018)? Padhye, Mani, & Sinha (Reference Padhye, Mani and Sinha2014) 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

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. Reference Chagas, Molloy, Prieto-Godino and Baden2020; Corsini, Dammicco, & Moultrie Reference Corsini, Dammicco and Moultrie2020). 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 Reference Stirling and Bowman2020). 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 Reference Bonvoisin and Schmidt2017) 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.