In a study by Bonvoisin et al. (2018), the maximum number of CAD file changes observed for Open Source Hardware projects over their complete lifetime was 7,522, with a median of 123 and an average of 509.
It is unclear whether GitHub offers appropriate support for early ideation phases of Open Source Hardware projects, which require higher interaction rates and sketching mechanisms.
Researchers often hypothesize an 'isomorphism' between Free/Libre and Open Source Software (FLOSS) and Open Source Hardware development practices because Open Source Hardware extends concepts originally developed for Open Source Software.
Open Source Hardware and Open Source Product Development (OSPD) may only gain a significant audience and ecosystem of participants if a 'Linux-like product'—defined as an essential infrastructure product that generates significant economic activity—emerges.
The number of CAD file changes in Open Source Hardware projects is relatively low compared to industrial standards, where automotive industry development teams commonly record tens of thousands of CAD file changes per month.
Open Source Hardware projects utilize reversible joining techniques, such as mortise and tenon or nuts and bolts, to allow for assembly error correction, product updates, and parts reuse.
As of the publication of the article, there is no Open Source Hardware product that is the subject of centrally coordinated collaborative design activity involving an ecosystem of businesses.
Moritz, Redlich, & Wulfsberg (2018) define Open Source Hardware as a decentralised and collaborative model of value creation where people jointly develop and freely share designs.
Current practices in Open Source Hardware, Open Source Product Development (OSPD), and Open Design are primarily focused on early-stage design processes, such as prototyping and technology development, and on distributed, low-tech manufacturing.
The White Rabbit project, part of CERN’s open source experimental physics facilities development strategy, is the largest known Open Source Hardware development project.
The analysis of 105 Open Source Hardware projects on GitHub did not demonstrate the existence of massively distributed development projects that adopt an Open Source Product Development (OSPD) process from the initial idea through to a commercialized product.
The Journal of Open Hardware and HardwareX are academic journals established as publication channels for Open Source Hardware, primarily focusing on scientific instrumentation.
Projects such as OpenStructures, Wikihouse, and XYZ Cargo demonstrate the preference for modular, lego-like design styles within Open Source Hardware communities, as noted by Bonvoisin, Prendeville, and Galla (2017).
Open Source Hardware products can initiate new life cycle iterations by being redesigned in either private or community-based settings.
Chagas et al. (2020) and Corsini, Dammicco, & Moultrie (2020) documented recent attempts by the Open Source Hardware community to respond to the COVID-19 crisis.
Public innovation involves the release of Open Source Hardware documentation only after a development process has been completed in a private setting.
Current standards for Open Source Hardware, including the 'Open Source Hardware Statement of Principles 1.0' and DIN SPEC 3105, only allow for measuring openness in the interval between zero openness and minimal openness, failing to account for openness beyond these minimal requirements.
The authors define 'Open Source Product Development' as the development of Open Source Hardware products performed in a collective process allowing the participation of any interested person.
The Design Science Journal has hosted research applying data mining approaches to engineering design using fictional data (Ball & Lewis, 2018), closed Product Lifecycle Management (PLM) databases (Gopsill, Snider, & Hicks, 2019), or publicly available Open Source Hardware repositories (Bonvoisin et al., 2018).
Current Open Source Hardware and Open Source Product Development (OSPD) practices often recreate controlling mechanisms to maintain the applicability of known design methods in the absence of formal hierarchies.
The high cost of manufacturing tools creates a significant barrier for end-users to participate in the build, test, and improvement loops of Open Source Hardware (OSHW) compared to Open Source Software (OSS).
A 2017 comparative analysis of interviews with leading figures from 23 Open Source Hardware development initiatives revealed a large diversity of motivations and approaches regarding collaborative development processes.
DIN (2020) identifies four fundamental rights for Open Source Hardware: the right to study, to modify, to make, and to distribute the documentation of a piece of hardware or the piece of hardware itself.
Modularity is considered an inherent property of hardware and a key enabler of openness in Open Source Hardware communities.
Open Design and Open Source Hardware aim to challenge the current growth-driven society and the modern division of roles between industries and customers.
Practices in open source hardware evolved to integrate mechanical hardware, but the terminology remained unchanged from its original electronic-focused roots.
An analysis of public documentation from 132 Open Source Hardware development initiatives showed that the diversity of these initiatives is reflected in the content and scope of their published documentation.
The term Open Source Hardware originated with electronic hardware, which was the hardware on which open source software would run, as discussed in Bonvoisin et al. (2020).
Open Design and Open Source Hardware are competing terms that can be partially explained by their different contexts of emergence.
Open Source Ecology's 'Global Village Construction Set' is an iconic Open Source Hardware project consisting of 50 open source industrial machines designed to allow users to build a small civilization with modern comforts.
Open Design is a term created by scholars to comment on new forms of product development, whereas Open Source Hardware is a term that emerged from practice and was coined by hardware developers to indicate compliance with the ethos of the open source movement.
Open Source Hardware data provides an empirical anchor for studying Open Source Product Development (OSPD) practices, offering an alternative to speculative or programmatic research contributions in the Open Design literature.
Open Source Hardware projects often focus on specific stages, such as feasibility assessment through first functional prototypes (e.g., Open Source Ecology, Apertus Axiom, and Echopen) or the maintenance and improvement of already published hardware (e.g., Circular Knitic and Lulzbot TAZ).
The authors of 'Seven observations and research questions about Open Design and Open Source Hardware' developed seven observations based on six years of research on Open Design and Open Source Hardware, which they intend to serve as an agenda for further research.
While some pioneering businesses have built upon Open Source Hardware by releasing products or appropriating external designs, the authors of 'Seven observations and research questions about Open Design and Open Source Hardware' are unaware of any company that has led or participated in an Open Source Product Development (OSPD) process.
Open Design and Open Source Hardware are rooted in values of economic sustainability, local autonomy, and human-centricity.
The DIN SPEC 3105 standard, published by DIN in 2020, refines the 'Open Source Hardware Statement of Principles 1.0' to establish minimal requirements for a product to qualify as open source.
The term Open Design embraces practices that share some form of openness but diverge in fundamental aspects, such as Open Source Hardware and crowdsourcing.
The authors distinguish between 'Closed and Open Source Hardware' (which refer to IP management strategies regardless of development process) and 'closed innovation and public innovation' (which refer to the closed process of developing either proprietary or Open Source Hardware).
Balka et al. (2010) assert that the concept of Open Source Hardware is inherently linked to the idea of a developer community.
In Open Source Hardware projects where stakeholders are primarily laypeople, production processes are restricted to the capabilities accessible to the general public.
An analysis of the versioning control history of 256 repositories characterized Open Source Hardware development as a heterogeneous field that exists on a continuum between Open Source Product Development (OSPD) and public innovation practices, ranging from active contributor communities to dormant projects.
Open Source Hardware and Open Source Product Development (OSPD) initiatives often mimic conventional, centrally structured product development processes to fit into existing prescriptive design methods.
Neither Huizingh’s nor Balka’s definitions of open source innovation reference the Open Source Definition or the Open Source Hardware definitions.
Standardization efforts for Open Source Hardware need to be extended to include the definition of process openness to achieve transparency in both dimensions of Open Design.
The authors of 'Seven observations and research questions about Open Design and Open Source Hardware' recommend six actions for research and policy to support Open Design and Open Source Product Development (OSPD): (i) encourage business involvement and industry-led open industrialization, (ii) clarify definitions through large-scale comparative studies, (iii) experiment with extreme openness, (iv) generate practical guidance for OSPD processes, (v) push standardization for both product and process openness, and (vi) consolidate the understanding of OSPD and Open Design as a socio-technical phenomenon.
In a study of 105 Open Source Hardware projects hosted on GitHub, the distribution of file changes across contributors confirmed the existence of collaborative development activity while revealing diverse governance structures ranging from centralized projects to loosely connected decentralized networks.
The DIN SPEC 3105 standard, published in 2020, represents the adoption of Open Source Hardware concepts by a national standardization organization.
The Open Source Hardware community is the primary school of thought that has provided a narrowed definition of openness as applied to products.
Open Source Hardware (OSHW) is an instantiation of OSPD that possesses a history of practices and sectoral organization.
Product characteristics, such as form, functionality, architecture, aesthetics, and complexity, are largely absent from debates regarding Open Design in literature and standards for Open Source Hardware.
GitHub is used by numerous Open Source Hardware projects as a data repository, and because it functions as a data versioning system with an issue tracking system, it is well-suited for later design phases or formal processes like engineering change management.
The authors of 'Seven observations and research questions about Open Design and Open Source Hardware' suggest that design processes where requirement management and product architecting are decentralized among a swarm of participants need to be experimented with at a larger scale to understand their relevance.
Process openness in Open Source Hardware is currently not covered by the minimal requirements set by existing standards like the 'Open Source Hardware Statement of Principles 1.0' and DIN SPEC 3105.
Open Source Hardware has not adopted open source development practices to the same level of maturity as Free/Libre and Open Source Software (FLOSS), such as the Linux project.
The goal of using reversible joining techniques in Open Source Hardware is to foster user agency throughout the product life cycle, supporting processes like customizing, repairing, recycling, and repurposing.
The Open Source Hardware Life Cycle, as illustrated in Figure 3, depicts the interplay between Open Source Product Development (OSPD), Open Source Hardware, and public innovation.
Open Design, Open Source Hardware, and OSPD are emerging phenomena attempting to gain maturity and move beyond marginality to offer alternatives to conventional proprietary product creation.
Commentators including Müller-Seitz & Reger (2010), Raasch & Herstatt (2011), and Powell (2012) have highlighted limitations to the hypothesized isomorphism between Open Source Software and Open Source Hardware development practices.
Boujut et al. (2019) investigated whether there is a specific task distribution pattern in Open Source Hardware projects.
A detailed typology of Open Source Hardware development practices derived from large-scale comparative studies would assist in refining terminology and assessing the generalizability of research results.
The Open Source Hardware Association defines open source hardware as hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design.
The Open Source Hardware Association (2020) defines Open Source Hardware as referring solely to product openness, whereas the broader concept of open source is generally understood to enable participative development processes.
The dimensions defined in contributions regarding Open Design and Open Source Hardware are currently vague, arbitrary, and lack validation from practice or academia.
Serrano (2017) asserts that Open Source Hardware naturally induces collaboration.
The low adoption of the term Open Source Hardware in mechanical engineering, engineering design, and design science may be due to the term hardware being used as a synonym for physical product.