Seven observations and research
questions about Open Design and
Open Source Hardware
Jérémy Bonvoisin
1
, Robert Mies
2
and Jean-François Boujut
3
1
Department of Mechanical Engineering, University of Bath, Bath, UK
2
Chair of Quality Science, Institute for Machine Tools and Factory Management, Technische
Universität Berlin, Berlin, Germany
3
Industrial Engineering, Grenoble Institute of Technologie, Grenoble, France
Abstract
‘Openness’is one of the key concepts brought forward by postindustrial narratives ques-
tioning the modern repartition of roles between industries and customers. In these narra-
tives, 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.
Key words: open source product development, open source innovation, crowdsourcing,
social product development
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
Received 18 December 2020
Revised 27 July 2021
Accepted 28 July 2021
Corresponding author
Jean-François Boujut
jean-francois.boujut@grenoble-
inp.fr
© The Author(s), 2021. Published by
Cambridge University Press. This is
an Open Access article, distributed
under the terms of the Creative
Commons Attribution licence (http://
creativecommons.org/licenses/by/
4.0), which permits unrestricted re-
use, distribution and reproduction,
provided the original article is
properly cited.
Des. Sci., vol. 7, e22
journals.cambridge.org/dsj
DOI: 10.1017/dsj.2021.14
1/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 tech-
nology –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 under-
standing 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 Develop-
ment and define as the development of Open Source Hardware products per-
formed 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 fore-
ground 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
2/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
recommendations for research and policy making to support the further develop-
ment of Open Design practices.
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
What?
- Outstanding or archetypal examples
- Design features supporting openness
How?
- Alternative design process models
- Open process vs open processes
- Openness assessment
When?
- Defining success of open processes
- Diversity of practices
Figure 1. Seven open issues addressed in the research programme discussed in this article.
3/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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, develop-
ment projects whose results are published as open source once they reached a
maturity level that is deemed as satisfactory by the authors. Private open innova-
tion, 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
1
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
1
In the context of this article, we do not delve into questions about composition and structure of
communities and adopt a simplistic definition. We refer to a ‘community’as a group of people
participating in the development of a shared knowledge base and whose participation is not necessarily
bound to their affiliation in a shared formal organisation. In this context, a community can be, among
others, a group of volunteers gathered around an online platform, a group of companies contributing to
a common project or a mix of both.
4/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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.
The prevalent, if not only, school of thought that delivered a narrowed down
definition of openness applied to products is the Open Source Hardware commu-
nity. 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 prod-
uct 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 nondiscri-
mination against persons or groups and nondiscrimination against fields of
endeavour (Open Source Initiative 2007).
Table 1. Openness factors introduced by Balka, Raasch, & Herstatt (2014).
Openness factor Definition
Transparency ‘[…] incorporates two distinct aspects: the possibility and the right to “look”at the
design […] To see that they are distinct, just think of the practice of reverse
engineering (possibility, but often no right) or of designs being shared freely in
cumbersome formats (right, but effectively little possibility)’.
Accessibility ‘[…] the possibility and the right for the community to access and modify design
information. The possibility hinges on an actionable design format (e.g., source
code instead of binary, computer-aided design [CAD] files instead of photos); the
right can be instituted by an open license, for example, the General Public License or
Creative Commons. Accessibility does not require that every community member
has the skills, tools, and other prerequisites that render him or her effectively
capable of being involved in codevelopment’.
Replicability ‘[…] the possibility and the right of the community to produce instantiations of (parts
of) the design. Replicability is created by the availability of individual components
(either by making or by buying), the provision of requisite information about the
design layout and assembly, and by the absence of legal barriers impeding self-
production or self-assembly’.
5/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 combi-
nation 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 hard-
ware on which open source software would run. Over time, practices evolved to
6/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
integrate other kinds of hardware, like mechanical hardware, while the terminol-
ogy 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.
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
Open source product
development
(open source innovation)
Public innovation
Private open innovation
(crowdsourcing, social
product development)
Conventional
product development
(closed innovation)
Closed process Open process
Process openness
Product
openness
Open source hardware
(downloadable design)
Proprietary hardware
Regardless of any process
closed
product
open
product
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.
7/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 devel-
opment 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).
2
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 fab-
rication’(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
Open Source
Product
Development
Open Source
Hardware Public Innovation
RevealRelease
Redesi
g
nRedesi
g
n
Figure 3. The Open Source Hardware Life Cycle introduced in Mies, Bonvoisin, &
Jochem (2018).
2
https://reprap.org/wiki/RepRap_Family_Tree (downloadable on August 25th 2020).
8/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 produc-
tion 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 tech-
nical 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 produc-
tion 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) popu-
larised by Pearce (2012).
Against this context, Open Design and more specifically Open Source Hard-
ware 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 trans-
fer 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
9/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
(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 con-
verge 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 study-
ing 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
3
(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
3
see https://oho.wiki,https://certification.oshwa.org/ and https://search.openknowhow.org/ (down-
loadable on December 18th 2020).
10/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 uncer-
tainties 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 require-
ments to the release of manufacture-ready product documentation.
The idea of community-led ‘mass collaborative product development’projects
(Panchal 2009) putting Linus’s Law
4
into practice and providing communities with
high end products, seems to be more a projected ideal than a contemporary reality.
4
The so-called Linus’s law is the assertion that ‘given enough eyeballs, all bugs are shallow’. It is one of
the mantras of FLOSS and implies that transparency leads to better quality software, since more people
can investigate it and uncover design flaws.
11/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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
5
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
6
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 Ecol-
ogy
7
, Apertus Axiom
8
and Echopen
9
), while some others concentrate on the
maintenance and improvement of an already published piece of hardware (e.g.,
Circular Knitic
10
and Lulzbot TAZ
11
). 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 devel-
opment 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
5
https://github.com/.
6
From the first file change recorded by the shared repository to the date of the data acquisition
campaign performed for the study.
7
https://www.opensourceecology.org/ (downloadable October 20th, 2020).
8
https://www.apertus.org/axiom (downloadable on October 20th, 2020).
9
http://www.echopen.org/ (downloadable on October 20th, 2020).
10
http://varvarag.info/circular-knitic/ (downloadable on October 20th, 2020).
11
https://www.lulzbot.com/store/printers/lulzbot-taz-6 (downloadable on October 20th, 2020).
12/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 man-
agement. 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 com-
plexity 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.
12
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 organisa-
tion 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 matu-
rity, 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.
12
https://certification.oshwa.org/list.html (downloadable on August 8th, 2020).
13/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 commu-
nity 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 compo-
nents 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 devel-
opment 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.
14/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 organi-
sations 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’,asLee
&Cole(2003)wordit.
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).
15/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
These alternative management and governance are reflected at the activity level
in the widespread use of DVCS.
13
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 competi-
tors 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
13
Mostly based on Git (https://git-scm.com/). A significant share of Open Source Hardware projects
uses GitHub (https://github.com/) which is a project repository sharing platform based on Git
(Bonvoisin, Thomas, et al. Bonvoisin et al. 2017).
16/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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) high-
lights, 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.
14
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.
14
In relation with this, it may be more accurate to refer to ‘product openness’as ‘product information
openness’since it concerns product-related information and not the product design itself.
17/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
Among these we can cite:
(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.
(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 open-
ness, 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
abc
de
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.
18/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 mod-
ular 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 evolu-
tionary 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.
19/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
Open source computers such as the MNT Reform
15
provide examples of OAP
where both the core product and the modules can be open source. Microcontrollers
such as Arduino and BeagleBoard
16
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, telecommuni-
cations 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 inter-
ests 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 numer-
ous 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,
17
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?
15
https://mntre.com.
16
http://beagleboard.org/.
17
https://www.thingiverse.com/.
20/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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.’
18
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 them-
selves 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. […Conse-
quently], 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
18
Translation by the authors from the French ‘chaque projet a mis en place des formes de régulations
qui lui sont propres’.
21/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 dimen-
sions.
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 require-
ments 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
22/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 prac-
tices.
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 inexpen-
sive 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 periph-
ery 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:
(i) encourage business involvement, and especially experiment with industry-led
open industrialisation processes;
(ii) continue deblurring definitions, for example by investing in large scale com-
parative studies;
23/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
(iii) experiment with extreme openness as a way to investigate the limits of
practicality in Open Design;
(iv) generate practical guidance based on the analysis of successful initiatives to
support practitioners in their efforts to generate OSPD processes;
(v) push forward the standardisation efforts made on product openness and
expand them to cover process openness as well; and
(vi) consolidate the ‘big picture’of OSPD and Open Design as a socio-technical
phenomenon addressing contemporary stress fields between society, econ-
omy 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 partic-
ipants 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 indus-
trialisation processes. Today’s practices of Open Source Hardware, OSPD and
Open Design in general are largely focussed on early design processes like proto-
typing 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 pro-
totypes 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.
24/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
The challenge of diversity may be addressed by investing in large scale com-
parative 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 coura-
geous 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 architec-
ture 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’sinit’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
25/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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. How-
ever, 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
26/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
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 asa practice aswellas those facedby 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 com-
peting 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 recommen-
dations 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.
Acknowledgements
The reported research was supported by the French–German interdisciplinary
research project `Open! Methods and tools for community-based product devel-
opment’and the EU-funded project OPEN_NEXT. The project OPEN! was jointly
funded by the French and German national science agencies ANR (Agence
Nationale de la Recherche, grant ANR-15-CE26-0012) and DFG (Deutsche For-
schungsgemeinschaft, grants STA 1112/13-1 and JO 827/8-1). OPEN_NEXT has
27/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
received funding from the European Union’s Horizon 2020 research and innova-
tion programme under grant agreement no. 869984.
Competing interest
The authors declare none.
References
Aitamurto, T.,Holland, D. &Hussain, S. 2015 The open paradigm in design research.
Design Issues 31 (4), 17–29; doi:10.1162/DESI_a_00348.
Affonso, C. A. C. &Amaral, D. C. 2015 Boundary objects in open source design:
experiences from OSE community. In DS 80-3 Proceedings of the 20th International
Conference on Engineering Design (ICED 15) (Vol. 3). Organisation and Management,
Milan, Italy, 27–30.07.2015.
Aksulu, A. &Wade, M. 2010. A comprehensive review and synthesis of open source
research. Journal of the Association for Information Systems 11 (11/12), 576–656.
Asri, I. E. l.,Kerzazi, N.,Benhiba, L. &Janati, M. 2017. From periphery to core: a temporal
analysis of GitHub contributors’collaboration network. In Collaboration in a Data-Rich
World, pp. 217–229. IFIP Advances in Information and Communication Technology.
Springer; doi:10.1007/978-3-319-65151-4_21.
Avital, M. 2011 The generative bedrock of open design. In Open Design Now: Why Design
Cannot Remain Exclusive (ed. B. van Abel, R. Klaassen, L. Evers & P. Troxler), BIS
Publishers, Amsterdam, pp. 48–58.
Balka, K. 2011 Open Source Product Development - The Meaning and Relevance of Openness
(ed. H. D. Bürgel, D. Grosse, C. Herrmann, H. Koller & M. G. Möhrle). Gabler Verlag.
Balka, K.,Raasch, C. &Herstatt, C. 2010. How open is open source? –software and beyond.
Creativity and Innovation Management 19 (3): 248–256; doi:10.1111/j.1467-
8691.2010.00569.x.
Balka, K.,Raasch, C. &Herstatt, C. 2014. The effect of selective openness on value creation
in user innovation communities. Journal of Product Innovation Management 31 (2),
392–407; doi:10.1111/jpim.12102.
Ball, Z. &Lewis, K. 2018. Observing network characteristics in mass collaboration design
projects. Design Science 4; doi:10.1017/dsj.2017.26.
Benkler, Y. &Nissenbaum, H. 2006 Commons-based peer production and virtue. Journal
of Political Philosophy,14(4) p. 394–419.
Bihouix, P. 2020 The Age of Low Tech: Towards a Technologically Sustainable Civilization.
Bristol University Press, 198p.
Boisseau, É.,Omhover, J.-F. &Bouchard, C. 2018 Open-design: a state of the art review.
Design Science 4. doi:10.1017/dsj.2017.25.
Bonvoisin, J.,Buchert, T.,Preidel, M. &Stark, R. G. 2018 How participative is open source
hardware? Insights from online repository mining. Design Science 4; doi:10.1017/
dsj.2018.15.
Bonvoisin, J. &Mies, R. 2018 Measuring openness in open source hardware with the open-
o-meter. Procedia CIRP 78, 388–393; doi:10.1016/j.procir.2018.08.306.
Bonvoisin, J.,Mies, R.,Stark, R. &Boujut, J.-F. 2017 What is the ‘source’of open source
hardware? Journal of Open Hardware 1(1): 18; doi:http://doi.org/10.5334/joh.7.
Bonvoisin, J.,Molloy, J.,Haeuer, M. &Wenzel, T. 2020 Standardisation of practices in
open source hardware. Journal of Open Hardware.4(1), p. 1–11.
28/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
Bonvoisin, J.,Prendeville, S. &Galla, J. K. 2017 Design principles for do-it-yourself
production. In Sustainable Design and Manufacturing 2017. Smart Innovation, Systems
and Technologies.
Bonvoisin, J. &Schmidt, K. C. 2017 Best Practices of Open Source Mechanical Hardware: A
Guide with Practical Advice for Sharing Product-related Documentation. Technische
Universität; doi:10.14279/depositonce-5729.
Bonvoisin, J.,Thomas, L.,Mies, R.,Gros, C.,Stark, R.,Samuel, K.,Jochem, R. &Boujut,
J.-F. 2017 Current state of practices in open source product development. In 21 Int.
Conf. on Engineering Design (ICED17), Vancouver, Canada.
Boujut, J. F. &Blanco, E. 2003 Intermediary objects as a means to foster co-operation in
engineering design. Computer Supported Cooperative Work 12 (2), 205–219; doi:
10.1023/A:1023980212097.
Boujut, J. F.,Pourroy, F.,Marin, P.,Dai, J. &Richardot, P. 2019 Open source hardware
communities: investigating participation in design activities. In 22nd International Con-
ference on Engineering Design (ICED19),August, pp. 2307–2316;doi:10.1017/dsi.2019.237.
Broca, S. 2013 Utopie du Logiciel Libre. Le Passager Clandestin.
Brulé, E. &Valentin, F. 2016 Of open bodies: challenges and perspectives of an open design
paradigm. In 50th Anniversary Design Research Society Conference. Proceedings of
DRS’16. Brighton, United Kingdom. https://hal.archives-ouvertes.fr/hal-01304721.
Buitenhuis, A. J. &Pearce, J. M. 2012 Open-source development of solar photovoltaic
technology. Energy for Sustainable Development 16 (3), 379–388; doi:10.1016/j.
esd.2012.06.006.
Chagas, M. A.,Molloy, J. C.,Prieto-Godino, L. L. &Baden, T. 2020 Leveraging open
hardware to alleviate the burden of COVID-19 on global health systems. PLoS Biology
18 (4), e3000730; doi: 10.1371/journal.pbio.3000730.
Chaturvedi, K. K.,Sing, V. B. &Singh, P. 2013 Tools in mining software repositories. In
2013 13th International Conference on Computational Science and Its Applications,
pp. 89–98; doi:10.1109/ICCSA.2013.22.
Chen, D.,Heyer, S.,Ibbotson, S.,Salonitis, K.,Steingrímsson, J. G. &Thiede, S. 2015
Direct digital manufacturing: definition, evolution, and sustainability implications.
Journal of Cleaner Production 107, 615–625. doi:10.1016/j.jclepro.2015.05.009.
Chesbrough, H. 2012 Open innovation: where we’ve been and where we’re going. Research-
Technology Management 55 (4), 20–27; doi:10.5437/08956308X5504085.
Conway, M. E. 1968 How do committees invent. Datamation 14 (4), 28–31.
Corbet, J. &Kroah-Hartman, G. 2016 Linux Kernel Development, How Fast It Is Going,
Who Is Doing It, What They Are Doing and Who Is Sponsoring the Work, 25th
Anniversary Edition. The Linux Foundation.
Core Infrastructure Initiative of the Linux Foundation 2020 Best practices criteria for
free/libre and open source software (FLOSS). GitHub. https://github.com/coreinfras
tructure/best-practices-badge.
Corsini, L.,Dammicco, V. &Moultrie, J. 2020 Critical factors for implementing open
source hardware in a crisis: lessons learned from the COVID-19 pandemic. Journal of
Open Hardware 4(1), 8; doi:http://doi.org/10.5334/joh.24.
Cruickshank, L. &Atkinson, P. 2014. Closing in on open design. The Design Journal 17 (3),
361–377; doi:10.2752/175630614X13982745782920.
Dafermos, G. &Söderberg, J. 2009 The hacker movement as a continuation of labour
struggle. Capital & Class; doi:10.1177/030981680909700104.
Dahlander, L. &Gann, D. M. 2010 How open is innovation? Research Policy 39(6),
699–709.
29/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
Dai, J. X.,Boujut, J.-F.,Pourroy, F. &Marin, P. 2020 Issues and challenges of knowledge
management in online open source hardware communities. Design Science 6; doi:
10.1017/dsj.2020.18.
DIN 2020 DIN SPEC 3105-1:2020-07, Open Source Hardware –Part 1: Requirements for
Technical Documentation. Beuth Verlag GmbH; doi:10.31030/3173063.
Ehls, D. 2015 Diversity of participants in open source projects: revealing differences within
and between software, content, fun and business communities. In Open Source Inno-
vation The Phenomenon, Participant’s Behaviour, Business Implications (ed. C. Herstatt
and D. Ehls) pp. 63–80. Routledge.
Fischer, G. &Scharff, E. 2000 Meta-design: design for designers. In Proceedings of the 3rd
Conference on Designing Interactive Systems: Processes, Practices, Methods, and Tech-
niques, pp. 396–405. Association for Computing Machinery; doi:
10.1145/347642.347798.
Fjeldstad, Ø. D.,Snow, C. C.,Miles, R. E. &Lettl, C. 2012 The architecture of collabo-
ration. Strategic Management Journal 33 (6), 734–750.
Fjeldsted, A. S.,Adalsteinsdottir, G.,Howard, T. J. &McAloone, T. C. 2012 Open source
development of tangible products-from a business perspective. In DS 71: Proceedings of
NordDesign 2012, the 9th NordDesign conference, 22–24.08.2012. Aalborg, Denmark
(ed. P. K. Hansen, J. Rasmussen, K. A. Jřrgensen & C. Tollestrup).
Flus, M. &Hurst, A. 2021 Design at hackathons: new opportunities for design research.
Design Science 7, E4; doi:10.1017/dsj.2021.1.
Gacek, C. &Arief, B. 2004 The many meanings of open source. IEEE Software 21 (1), 34–40;
doi:10.1109/MS.2004.1259206.
Gasparotto, S. 2020 From 0 to 20. An evolutionary analysis of open design and open
manufacturing. Strategic Design Research Journal 13 (1) p 57–71.
Geyer, M.,Reise, C.,Manav, F.,Schwenke, N.,Böhm, S. &Seliger, G. 2012 Open design
for manufacturing –best practice and future challenges. In Proceedings of the 10th
Global Conference on Sustainable Manufacturing,Istanbul, Turkey, 2012.
Gopsill, J. A.,Snider, C. &Hicks, B. J. 2019 The emergent structures in digital engineering
work: what can we learn from dynamic DSMs of near-identical systems design projects?
Design Science 5; doi:10.1017/dsj.2019.20.
Gavras, Kosmas.“Open source beyond software: re-invent open design on the common’s
ground.”Journal of Peer Production 13 (2018).
Greengard, S. 2020 Will risc-v revolutionize computing? Communications of the ACM 63
(5), 30–32.
Healy, K. &Schussman, A. 2003 The Ecology of Open-Source Software Development.
Department of Sociology, University of Arizona.
Hamalainen, M.,Mohajeri, B. &Nyberg, T. 2018 Removing barriers to sustainability
research on personal fabrication and social manufacturing. Journal of Cleaner Produc-
tion 180, 666–681.
Hamalainen, M. &Karjalainen, J. 2017 Social manufacturing: when the maker movement
meets interfirm production networks. Business Horizons 60 (6), 795–805.
Herrera, A. 2020 The promises and challenges of open source hardware. IEEE Annals of the
History of Computing 53 (10), 101–104.
Heskett, J. 2001 Past, present, and future in design for industry. Design Issues 17 (1), 18–26.
Howison, J. &Crowston, K. 2014 Collaboration through open superposition: a theory of
the open source way. Mis Quarterly 38 (1), 29–50.
Huizingh, E. K. R. E. 2011 Open innovation: state of the art and future perspectives.
Technovation 31 (1), 2–9; doi:10.1016/j.technovation.2010.10.002.
30/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
Johansson, A.,Kisch, P. &Mirata, M. 2005 Distributed economies –a new engine for
innovation. Journal of Cleaner Production 13 (10–11), 971–979; doi:10.1016/j.jcle-
pro.2004.12.015.
Jones, R.,Haufe, P.,Sells, E.,Iravani, P.,Olliver, V.,Palmer, C. &Bowyer, A. 2011
RepRap –the replicating rapid prototyper. Robotica 29 (1), 177–191; doi:10.1017/
S026357471000069X.
Kadushin, R. 2010 Open Design Manifesto. https://www.ronen-kadushin.com/open-
design-manifesto.
Kalliamvakou, E.,Gousios, G.,Blincoe, K.,Singer, L.,German, D. M. &Damian, D. 2016
An in-depth study of the slpromises and perils of mining GitHub. Empirical Software
Engineering 21 (5), 2035–2071; doi:10.1007/s10664-015-9393-5.
Kohtala, C. 2014 Addressing sustainability in research on distributed production: an
integrated literature review. Journal of Cleaner Production;106, p. 654–668; doi:
10.1016/j.jclepro.2014.09.039.
Koren, Y.,Shpitalni, M.,Gu, P. &Hu, S. J. 2015 Product design for mass-individualization.
Procedia Cirp 36,64–71.
Koren, Y.,Hu, S. J.,Gu, P. &Shpitalni, M. 2013 Open-architecture products. CIRP Annals
- Manufacturing Technology 62 (2), 719–729; doi:10.1016/j.cirp.2013.06.001.
Kostakis, V.,Niaros, V.,Dafermos, G. &Bauwens, M. 2015 Design global, manufacture
local: exploring the contours of an emerging productive model. Futures 73, 126–135;
doi:10.1016/j.futures.2015.09.001.
Kostakis, V. &Papachristou, M. 2014 Commons-based peer production and digital
fabrication: the case of a reprap-based, lego-built 3d printing-milling machine. Tele-
matics and Informatics 31 (3), 434–443; doi:10.1016/j.tele.2013.09.006.
Kyriakou, H.,Nickerson, J. V. &Sabnis, G. 2017 Knowledge Reuse for Customization:
Metamodels in an Open Design Community for 3D Printing. Social Science Research
Network.
Lee, G. K. &Cole, R. E. 2003 From a firm-based to a community-based model of knowledge
creation: the case of the linux kernel development. Organization Science 14 (6), 633–649;
doi:10.1287/orsc.14.6.633.24866.
Li, Z.,Seering, W.,Ramos, J. D. &Wallace, D. R. 2017 Why open source? Exploring the
motivations of using an open model for hardware development. In Proceedings of
TheASME2017 International Design Engineering, Technical Conferences and Computers
and Information in Engineering Conference, IDETC/CIE 2017,Cleveland, OH, USA.
https://www.researchgate.net/publication/316884384_DETC2017-68195_WHY_
OPEN_SOURCE_EXPLORING_THE_MOTIVATIONS_OF_USING_AN_OPEN_
MODEL_FOR_HARDWARE_DEVELOPMENT.
MacCormack, A.,Baldwin, C. &Rusnak, J. 2012 Exploring the duality between product
and organizational architectures: a test of the ‘mirroring’hypothesis. Research Policy 41
(8): 1309–1324; doi:10.1016/j.respol.2012.04.011.
Macul, V. &Rozenfeld, H. 2015 How an open source design community works: the case of
open source ecology. In DS 80-3 Proceedings of the 20th International Conference on
Engineering Design (ICED 15) Vol 3: Organisation and Management, Milan, Italy, 27–
30.07.2015, pp. 359–366.
Malinen, T.,Mikkonen, T.,Tienvieri, V. &Vadén, T. 2010 Open source hardware through
volunteer community: a case study of ECars –now! In Proceedings of the 14th Inter-
national Academic MindTrek Conference: Envisioning Future Media Environments,
pp. 65–68. MindTrek ’10. ACM; doi:10.1145/1930488.1930502.
Mies, R.,Bonvoisin, J. &Jochem, R. 2018 Harnessing the synergy potential of open source
hardware communities. In Open Up or Close Down! How Co-Creation Reshapes Business
31/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
and Society in Bottom-up Economics, (ed. T. Redlich, M. Moritz & J. P Wulfsberg),
pp. 129–145. Springer.
Moritz, M.,Redlich, T. &Wulfsberg, J. 2018 Best practices and pitfalls in open source
hardware. In International Conference on Information Theoretic Security, pp. 200–210.
Springer.
Müller-Seitz, G. &Reger, G. 2010 Networking beyond the software code? An explorative
examination of the development of an open source car project. Technovation 30 (11–
12), 627–634; doi:10.1016/j.technovation.2010.07.006.
Open Source Hardware Association 2013 Best Practices for Open Source Hardware 1.0.
https://www.oshwa.org/sharing-best-practices/.
Open Source Hardware Association 2016 Open Source Hardware (OSHW) Statement of
Principles 1.0. http://www.oshwa.org/definition/.
Open Source Hardware Association 2020 Brief History of Open Source Hardware Orga-
nizations and Definitions. https://www.oshwa.org/research/brief-history-of-open-
source-hardware-organizations-and-definitions/.
Open Source Initiative 2007 The Open Source Definition 1.0. https://opensource.org/osd-
annotated.
Ostuzzi, F.,Conradie, P.,De Couvreur, L.,Detand, J.,&Saldien, J. (2016). The Role of Re-
Appropriation in Open Design: A Case Study on How Openness in Higher Education
for Industrial Design Engineering Can Trigger Global Discussions on the Theme of
Urban Gardening. The International Review of Research in Open and Distributed
Learning,17(4). https://doi.org/10.19173/irrodl.v17i4.2543.
Padhye, R.,Mani, S. &Sinha, V. S. 2014 A study of external community contribution to
open-source projects on GitHub. In Proceedings of the 11th Working Conference on
Mining Software Repositories, pp. 332–335. MSR 2014. ACM; doi:
10.1145/2597073.2597113.
Pahl, G.,Beitz, W.,Feldhusen, J. &Grote, K.-H. 2007 Engineering Design: A Systematic
Approach. 3rd ed. Springer-Verlag. www.springer.com/gb/book/9781846283185.
Panchal, J. 2009 Co-evolution of products & communities in mass collaborative product
development: a computational exploration. In Proceedings of ICED 09, the 17th Inter-
national Conference on Engineering Design, Vol. 1, Design Processes. Palo Alto, CA, USA.
Panori, A.,Piccoli, A.,Ozdek, E.,Spyridopoulos, K. &Altsitsiadis, A. 2020 Pop Machina,
Market Research Report, Deliverable 2.2.
Pearce, J. M. 2012 The case for open source appropriate technology. Environment, Devel-
opment and Sustainability 14, 425–431; doi:10.1007/s10668-012-9337-9.
Peterson, A. &Schaefer, D. 2014 Social product development: introduction, overview, and
current status. In Product Development in the Socio-Sphere, pp. 1–33. Springer; doi:
10.1007/978-3-319-07404-7_1.
Pomerantz, J. &Peek, R. 2016 Fifty shades of open. First Monday, April; doi:10.5210/fm.
v21i5.6360.
Powell, A. 2012 Democratizing production through open source knowledge: from open
software to open hardware. Media, Culture & Society;34(6), p. 691–708; doi:
10.1177/0163443712449497.
Raasch, C. &Herstatt, C. 2011 Product development in open design communities: a
process perspective. International Journal of Innovation and Technology Management
08 (04), 557–575; doi:10.1142/S021987701100260X.
Raasch, C.,Herstatt, C. &Balka, K. 2009 On the open design of tangible goods. R&D
Management 39 (4), 382–393; doi:10.1111/j.1467-9310.2009.00567.x.
32/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
Raymond, E. 1999 The Cathedral and the Bazaar. Knowledge, Technology & Policy 12 (3),
23–49; doi:10.1007/s12130-999-1026-0.
Redlich, T.,Moritz, M. &Wulfsberg, J. P. 2019 Introduction: co-creation in the era of
bottom-up economics. In Co-Creation: Reshaping Business and Society in the Era of
Bottom-Up Economics (ed. T. Redlich, M.Moritz& J. P. Wulfsberg), pp. 1–6.Management
for Professionals. Springer International Publishing; doi:10.1007/978-3-319-97788-1_1.
Redwine, C. &Weinberg, M. 2020 Open Source Hardware Weather Report 2020.
Serrano, J. 2017 Open hardware and collaboration. In Proceedings of the 11st Int. Workshop
on Personal Computers and Particle Accelerator Controls PCaPAC2016: 6 pages, 0.114
MB; doi:10.18429/JACOW-PCAPAC2016-THKTPLK01.
Stirling, J. &Bowman, R. 2020 The COVID-19 pandemic highlights the need for open
design not just open hardware. Paper Preprint, Hosted on the Open Science Framework,
August.
Thomson, C. C. &Jakubowski, M. 2012 Toward an open source civilization (innovations
case narrative: open source ecology). Innovations: Technology, Governance, Globaliza-
tion 7(3), 53–70.
Tooze, J.,Baurley, S.,Phillips, R.,Smith, P.,Foote, E. &Silve, S. 2014 Open design:
contributions, solutions, processes and projects. The Design Journal 17 (4), 538–559;
doi:10.2752/175630614X14056185480069.
Troxler, P. &Wolf, P. 2017 Digital maker-entrepreneurs in open design: what activities
make up their business model?. Business Horizons 60 (6), 807–817.
Ulrich, K. &Eppinger, S. 2011 Product Design and Development. 5th ed. McGraw-Hill
Higher Education.
VDI 1993 Design Handbook 2221, Systematic Approach to the Development and Design of
Technical Systems and Products.
VDI 2004 VDI 2206 –Entwicklungsmethodik für mechatronische Systeme. https://www.vdi.
de/richtlinien/details/vdi-2206-entwicklungsmethodik-fuer-mechatronische-systeme.
Vinck, D. 2011 Taking intermediary objects and equipping work into account in the study
of engineering practices. Engineering Studies 3(1), 25–44; doi:
10.1080/19378629.2010.547989.
Waterman, A. &Asanovic, K. 2019 The RISC-V Instruction Set Manual, Volume I:
Unprivileged ISA, document version 20191213. RISC-V International.
Weber, S.. 2004. The Success of Open Source. Harvard University Press.
Whitney, D. E. 2002 Physical limits to modularity. Massachusetts Institute of Technology
Engineering Systems Division, Working Paper Series, ESD-WP-2003-01.03-ESD
Internal Symposium.
Wolf, P. &Troxler, P. 2016 Community-based business models: insights from an emerging
maker economy. IxD&A 30,75–94.
Wonderlick, S. &Walas, S. 2019 Red Hat Reports Fourth Quarter and Fiscal Year 2019
Results.
Wu, D.,Rosen, D. W.,Panchal, J. H. &Schaefer, D. 2015 Understanding communication
and collaboration in social product development through social network analysis.
Journal of Computing and Information Science in Engineering 16 (1), 011001–011010;
doi:10.1115/1.4031890.
Wynn, D. C. &Clarkson, P. J. 2018 Process models in design and development. Research in
Engineering Design 29 (2): 161–202; doi:10.1007/s00163-017-0262-7.
Zhang, S. &Li, Y. 2017 Modeling and simulation study of designer’s bidirectional behavior
of task selection in open source design process. Mathematical Problems in Engineering;
2017, p.1–13 doi:10.1155/2017/6738139.
33/33
https://doi.org/10.1017/dsj.2021.14 Published online by Cambridge University Press
