Difference between revisions of "Journal:What is the "source" of open-source hardware?"

From LIMSWiki
Jump to: navigation, search
(Saving and adding more.)
(Saving and adding more.)
Line 498: Line 498:
 
   | style="background-color:white; padding-left:10px; padding-right:10px;"|19
 
   | style="background-color:white; padding-left:10px; padding-right:10px;"|19
 
   | style="background-color:white; padding-left:10px; padding-right:10px;"|58%
 
   | style="background-color:white; padding-left:10px; padding-right:10px;"|58%
 +
|-
 +
|}
 +
|}
 +
 +
A first possible reason for the absence of published documentation may be that this documentation does not exist and cannot exist in the level of detail required by the criterion used here. Indeed, in early design stages, the product documentation may not be mature enough for the product concept to be formalized into CAD files, assembly instructions, and bills of materials. This explanation tends to be supported by the gathered data, as the average openness index of products in the early phases (concept and prototype) is significantly lower than those of production phases (DIY, kit, full product production). The percentage of products satisfying the criterion of transparency grows along with product maturity: it is lower than 54% in the concept and prototype phases and grows over 89% in the other phases. The average openness index increases as well; however, it starts to sink again at the last stage (full product production) due to lower replicability and commercial reusability. In this phase, products are marketed by companies which are taking financial risks. This may make them hesitant to disclose information that facilitates imitation.
 +
 +
A second possible reason for the absence of published documentation may be that the community which drove the product development is not active anymore. In that case, there is not enough workforce anymore to maintain data online; links become “dead links” and information finally disappears. This explanation tends to be supported by the gathered data, as the average openness index is significantly higher for products with active surrounding communities than for products with inactive communities (respectively 4.57 points and 2.91 points).
 +
 +
A third possible reason for the absence of published documentation may be that the community which drives the product development does not follow an open-source approach for the entire product but only for selected components. A straightforward case is when products include off-the-shelf components which are not open source. Another case is when originators deliberately exclude a developed component from the open-source approach in order to protect their strategic knowledge. This behavior has been previously empirically observed and is discussed by Balka, Raasch, and Herstatt.<ref name="BalkaTheEffect14" /> It is however explicitly excluded by the Open Source Hardware Certification Programme of the Open Source Hardware Association, as it is claimed that “all parts, designs, code, and rights under the control of the creator must be made open.”<ref name="OSHAReqs17">{{cite web |url=https://certificate.oshwa.org/ |title=Requirements for Certification |author=Open Source Hardware Association |date=2017}}</ref> In the current study, only the openness of mechanical components has been assessed, and those of software and electronic hardware components contained in mechatronic products have been left aside. It is therefore possible that a mechatronic product appears here as non-open although the corresponding electronic hardware and software are open source. Following this explanation, there would be a high chance that the average openness of mechanical parts of mechatronic products should be lower than those of purely mechanical products. This explanation is however not supported by the gathered data, as the average openness index is higher for mechatronic products than for purely mechanical products.
 +
 +
The following other possible interpretations of the absence of published documentation cannot be verified by the data gathered in this article:
 +
 +
* The intention of openness is given in the product development project, but the project lacks capacity to document and to put the product-related documentation online. Although in open-source communities publishing documentation is seen as a way to gather new workforce, generating product documentation remains a time-consuming process and may get lower priority than other product development activities.
 +
* There is a certain delay between the statement that the product is open source and the actual disclosure of product-related information. Project initiators may start claiming a product is open source before the corresponding documentation is put online.
 +
* The product is claimed to be open source whereas no intention to publish product-related information is given in the product development project, what we can term here as “openwashing” in analogy to “greenwashing” or “whitewashing.”
 +
 +
===Typical profiles===
 +
In order to identify possible typical profiles, the k-medioids algorithm has been computed on the dataset leading to the identification of five clusters. The similarity matrix reordered according to the identified clusters is displayed in Figure 6.
 +
 +
 +
[[File:Fig6 Bonvoisin JOfOpenHard2017 1-1.png|640px]]
 +
{{clear}}
 +
{|
 +
| STYLE="vertical-align:top;"|
 +
{| border="0" cellpadding="5" cellspacing="0" width="640px"
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"| <blockquote>'''Figure 6.''' Heatmap representing the Manhattan distance Sij between each pair of the 132 products (dark green pairs are similar, light green are dissimilar)</blockquote>
 +
|-
 +
|}
 +
|}
 +
 +
The openness of the products of each cluster is displayed in Table 3 and described hereafter:
 +
 +
* Cluster 1. Fully open products which satisfy almost all openness criteria and having hence a high average OI value (mean value 6.83/8)
 +
* Cluster 2 and 3. Products being transparent, replicable and commercially usable but not accessible; their average OI value is medium to high (mean value respectively 5.23 and 3.81/8) and is mainly handicapped by the lack of accessibility.
 +
* Cluster 4. Products being transparent, accessible and commercially usable but not replicable; their average OI value is medium to low (mean value 2.94/8) and is mainly handicapped by the lack of replicability
 +
* Cluster 5. Fully closed products, i.e., products for which almost no documentation can be found and out of which two thirds do not provide commercially usable documentation; their average OI value is very low (mean value 0.83/8)
 +
 +
{|
 +
| STYLE="vertical-align:top;"|
 +
{| class="wikitable" border="1" cellpadding="5" cellspacing="0" width="80%"
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;" colspan="11"|'''Table 3.''' Openness of the four identified clusters
 +
|-
 +
  ! style="padding-left:10px; padding-right:10px;" |Cluster
 +
  ! style="padding-left:10px; padding-right:10px;" |Number of products
 +
  ! style="padding-left:10px; padding-right:10px;" |OI
 +
  ! style="padding-left:10px; padding-right:10px;" colspan="2"|Transparency
 +
  ! style="padding-left:10px; padding-right:10px;" colspan="2"|Accessibility
 +
  ! style="padding-left:10px; padding-right:10px;" colspan="2"|Replicability
 +
  ! style="padding-left:10px; padding-right:10px;" colspan="2"|Commercial usability
 +
|-
 +
  ! style="padding-left:10px; padding-right:10px;" |
 +
  ! style="padding-left:10px; padding-right:10px;" |
 +
  ! style="padding-left:10px; padding-right:10px;" |Mean value
 +
  ! style="padding-left:10px; padding-right:10px;" |Absolute
 +
  ! style="padding-left:10px; padding-right:10px;" |Relative
 +
  ! style="padding-left:10px; padding-right:10px;" |Absolute
 +
  ! style="padding-left:10px; padding-right:10px;" |Relative
 +
  ! style="padding-left:10px; padding-right:10px;" |Absolute
 +
  ! style="padding-left:10px; padding-right:10px;" |Relative
 +
  ! style="padding-left:10px; padding-right:10px;" |Absolute
 +
  ! style="padding-left:10px; padding-right:10px;" |Relative
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|C1
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|29
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|6.83
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|26
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|90%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|24
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|83%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|28
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|97%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|24
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|83%
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|C2
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|31
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|5.23
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|31
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|100%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|7
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|235
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|27
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|87%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|26
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|84%
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|C3
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|31
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|3.81
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|28
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|90%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|5
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|16%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|25
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|81%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|24
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|77%
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|C4
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|17
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|2.94
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|15
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|88%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|10
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|59%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|0
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|0%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|13
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|76%
 +
|-
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|C5
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|24
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|0.83
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|2
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|8%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|8
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|33%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|0
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|0%
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|8
 +
  | style="background-color:white; padding-left:10px; padding-right:10px;"|33%
 
  |-
 
  |-
 
|}
 
|}

Revision as of 03:29, 14 January 2020

Full article title What is the "source" of open-source hardware?
Journal Journal of Open Hardware
Author(s) Bonvoisin, Jérémy; Mies, Robert; Boujut, Jean-François; Stark, Rainer
Author affiliation(s) Technische Universität Berlin, Grenoble Alpes University
Primary contact Email: jeremy dot bonvoisin at tu-berlin dot de
Year published 2017
Volume and issue 1(1)
Page(s) 5
DOI 10.5334/joh.7
ISSN 2514-1708
Distribution license Creative Commons Attribution 4.0 International
Website https://openhardware.metajnl.com/articles/10.5334/joh.7/
Download https://openhardware.metajnl.com/articles/10.5334/joh.7/galley/12/download/ (PDF)

Abstract

What “open source” means once applied to tangible products has been so far mostly addressed through the light of licensing. While this approach is suitable for software, it appears to be over-simplistic for complex hardware products. Whether such a product can be labelled as open-source is not only a question of licence but a question of documentation, i.e. what is the information that sufficiently describes it? Or in other words, what is the “source” of open-source hardware? To date there is no simple answer to this question, leaving large room for interpretation in the usage of the term. Based on analysis of public documentation of 132 products, this paper provides an overview of how practitioners tend to interpret the concept of open-source hardware. It specifically focuses on the recent evolution of the open-source movement outside the domain of electronics and DIY to that of non-electronic and complex open-source hardware products. The empirical results strongly indicate the existence of two main usages of open-source principles in the context of tangible products: publication of product-related documentation as a means to support community-based product development and to disseminate privately developed innovations. It also underlines the high variety of interpretations and even misuses of the concept of open-source hardware. This reveals in turn that this concept may not even be clear to practitioners and calls for more narrowed down definitions of what has to be shared for a product to be called open source. This article contributes towards this effort through the definition of an open-source hardware lifecycle, summarizing the observed approaches to open-source hardware.

Keywords: open-source hardware, open design, open innovation, open-source innovation, open-source product development

Introduction

We are currently witnessing an increasing number of initiatives transferring product development and production from the private sector to the public. Enabled by the growing accessibility of affordable manufacturing technology, this is manifested in the expansion of the so-called “maker culture,” which takes action to install participational production as an alternative to industrial production.[1][2] The emergence of this culture is interwoven with the phenomenon of open-source hardware (OSH), which transfers open-source principles (as defined by Open Source Initiative 2007) from their origins in software development to the world of physical objects.[3] While these new practices are raising significant attention, they are still in their infancy and struggle to reveal their full economic, social, and environmental potential. One of the challenges they face is that sharing knowledge about atoms is not as frictionless as sharing bits.

Both practitioners and the scientific community generally acknowledge that online sharing of a piece of hardware is more difficult than the sharing of a piece of software (e.g., see discussion of this point by Raasch[4]. Software is digital by nature; it is made of series of characters in a format that can be shared and displayed online without specific tools, with a text editor being enough. Hardware may need to be described through more complex constructs like 2D or 3D schematics, which may require more specific software to be edited and displayed. Based on the evaluation of a pool of 20 OSH projects whose products embedded both software and hardware components, Balka, Raasch, and Herstatt[5] highlighted that hardware components were generally less documented than the software components. This result raises questions in terms of practice. When a piece of hardware is poorly documented, is it still open source? What does “less documented” mean? What are the minimal requirements for labeling a hardware product as "open source"?

In the absence of clear guidance on this issue, it is not easy to draw a line between which piece of hardware is open source and which is not, even when licensing terms may be clear. Unlike in software, attributing appropriate licences[a] is not sufficient to call hardware open source. Given OSH is a sociotechnical phenomenon, the answer primarily depends on how the product documentation enables co-development and replication. This article seeks to provide guidance on which information sufficiently describes OSH. In other words, what is the source of OSH?

The objective of this article is to provide an overview of how current projects tend to interpret and make use of the concept of OSH. Its ultimate goal is to provide a deeper description of what OSH means based on the observation of actual practices. This is performed through the analysis of the “source”, i.e., the published documentation of 132 OSH products with the help of categorical criteria addressing the question “how open are OSH products?” It specifically focuses on the recent evolution of the open-source movement outside the domain of electronics and DIY to those of non-electronic and complex OSH products.

The remainder of the paper is structured as follows. In the next section the general context of emergence of OSH as an alternative product development pattern based on free distribution of information is depicted and characterized. Then definitions from practice communities and scholars are analysed and combined in order to provide a consolidated overview of the concept of OSH. After the definitions, the methodological approach for the acquisition of empirical data allowing the analysis of current practices of OSH documentation is introduced. The results produced by the application of this method are then described and interpreted. Finally, we summarize the findings into an original framework termed "OSH lifecycle," additionally summarizing observed approaches to OSH.

The context of open-source hardware

OSH is a relatively young phenomenon with projects emerging in the past decade[7], although it has several prominent examples already. Pioneering projects such as RepRap, Open Source Ecology, and Local Motors have certainly set a precedence to lift the air of mystery and aloofness of engineering ingenuity closely guarded for means of commercial appropriation. As to whether these are heralds of what Moritz et al.[8] depict as disruptive changes on the upstream end of value chains toward value-co-creation, only time will tell. Clearly, this alternative course of action could take an active part in shaping the technological future. Indeed, there are already promising examples of successful businesses based on OSH for which the scientific community identified corresponding value creation models.[9][10] These examples, together with the empirical evidence provided by free and open-source software, allow for a foreseeing of a flourishing future for OSH.[9][10]

Like free and open-source software, OSH is an IT-enabled internet phenomenon. Fjeldsted et al.[11], as well as Bonvoisin and Boujut[12], point out the integral part IT platforms play in fostering product-related data sharing and community-based product development, as well as the emergence of OSH-based business models. However, Raasch[4] draws a contrast: compared with OSS development, the aspect of physical object design in OSH has strong impacts on required skills, tools, and infrastructure. This aspect is even increasingly salient as the focus of OSH progressively expands towards many other forms of hardware than electronic hardware, like mechanical, construction, medical, optical, agricultural, or textile hardware. From a design point-of-view, the degree of freedom in the problem-solution space introduced by their mechanical portion rises significantly. Howard et al.[13] and Raasch, Herstatt, and Balka[14] also illustrate how OSH is looking at the full spectrum of product complexity and different manufacturing strategies, from do-it-yourself (DIY) to industrial production.

The capacity of communities outside the closed and hierarchical environment of research and development (R&D) departments to develop complex and high-quality products remains a challenge; the largest majority of OSH products available to date are gadgets for hobbyists.[15] As processes transform inputs into outputs, their structure is generally related to the product and project scope. OSH can be described as individual or participatory realization of a shared product design. Therefore, 3D printing designs shared by individuals on sites such as Thingiverse[b] may classify as OSH, similar to large community-based efforts such as the E-Nable project.[c] This makes a big difference in regards to the type of effort being structured for the realization of an open-source product. Hence, depending on the product scope and also the originator's intent to foster co-design, levels of interaction maturity differ starkly in OSH. A useful macro-level classification is offered by Camarinha-Matos et al.[16], starting at networks, then moving to coordination, cooperation, and collaboration.

The conceptual space that supports collective spirit and collaborative problem solving is described by Maher, Paulini, and Murty.[17] It is based on the three aspects of shared representation, motivation, and communication. They enable problem solving in collective design projects within a continuum from collected (individual) to collective intelligence. The latter is demarcated by collaborative generation of solutions as well as synthesis of individual solutions. From their study of collective design activities[18] conclude that within the frame of what they call an inclusive nature of participatory design, individuals proactively self-organize and choose their own roles as well as period of involvement. The maturity of this participatory nature may in fact be the primary determinant of collective design projects.

Social dynamics in crowds are context-dependent, however. In the OSH context, from all of the above, communities can be viewed as socially formed groups of heterogeneous actors who co-create OSH products. Depending on the participatory roles of actors, they may engage as followers, replicators, developers, or community managers. In the frame of open innovation, West and Lakhani[19] describe them as actor volunteers lacking of organizational affiliation. Due to partial influence of market-based factors, this role may somewhat reflect the notion of people giving away their time and effort without any monetary compensation. In addition, actors may as well include individuals, firms, and many other types of organizations.[20]

Aksulu and Wade[21] provide insight on how pure open-source systems set a community-based context of personal development, process learning, and effective technology outputs. In contrast, within the purely proprietary context, purpose is realized by the efficient generation of technology outputs within organizations with clear boundaries.

What exactly makes open-source processes effective seems to be rooted in the task environment. According to Lee and Cole[22], the trade-off between exploration and exploitation is made through a two-tier task structure of generated variations within the periphery, and selection and retention at the core. In their case study of the Linux kernel development project, they observe community-based knowledge creation in the form of an evolutionary learning process based on a culture of critical evaluations and peer learning. Moreover, Howison and Crowston[23] describe collaborative development of OSS as an evolutionary process of incremental and independent tasks, by which a layer structure emerges task-by-task. They argue that added layers change the context over time and significantly reduce complexity of tasks. By gradually laying the foundation, previously unattainable tasks eventually may suddenly become easily achievable by individual developers, or simple workarounds may become obvious. This is in line with the concept of Maher et al.[24] concerning the co-evolution of the problem and solution spaces, which describes how these dimensions influence each other during the design process. Collaborative evolutionary design on the activity level is key in explaining how solutions are generated effectively in open-source systems[d] and needs to be further researched.

Definitions of openness from practice and research

This section reviews existing definitions from practice and identifies resulting implications in terms of published product-related documentation. These definitions are then matched with existing contributions from research in order to provide a comprehensive framework defining OSH. Results of empirical studies which challenge these definitions and show a more heterogeneous landscape of OSH are then presented and lead to the identification of two research questions addressed in this article.

Definitions from practice communities

The Open Source Hardware Statement of Principles 1.0 states that “open source hardware is 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.”[25] It is based on the assumption that publishing a “design” (alternatively termed “documentation”) realizes the four freedoms of the open-source concept, which are reinterpreted in the context of tangible products as the freedom to study, modify, make, and distribute.[e]

This definition is an adaptation of the original Open Source Definition by the Open Source Initiative[27] to the realms of tangible products. Coined in the context of free and open-source software, it specifies requirements on two interwoven objects: the “software,” alternatively called the “product,” and the “source code.” It is implicitly accepted that the object called “source code” allows defining the object called “product” unambiguously in its depth and its entirety. In the case of software, this implicit prerequisite is automatically fulfilled, as a software product is the translation of a text written in programming language into a machine language by a deterministic algorithm. However, this is not the case for tangible products: what information has to be shared in order to allow any interested person to study, modify, make, and distribute a piece of hardware is not a simple question.

A closer look at the definitions of widely recognized OSH licences and current practices of OSH seeks to give some hints and shows that the four freedoms of open source tend to be supported by different document types or properties[28]:

  • The freedom to study (i.e., the right to access sufficient information to understand how the piece of hardware—referred herein as the product—works and to retrace the underlying design rationale as defined by Wang, Johnson, and Bracewell[29]) can be supported by the publication of schematics, 2D, or 3D CAD files.
  • The freedom to modify (i.e., the right to edit the product definition documents and to tweak or develop the product further for any purpose) can be supported by the publication of all documents in their original editable format.
  • The freedom to make (i.e., the right to use the product definition documents in order to make—in other words to produce, to manufacture—the piece of hardware) can be supported by the publication of a bill of materials and assembly instructions.
  • The freedom to distribute (i.e., the right to give or sell the product definition documents as well as the physical products fabricated with the help of these documents) is allowed by the publication of all documents under a licence which grants free redistribution, including for commercial purposes.

Definitions from scholarly research

Scholarly definitions—mostly stemming from innovation management research—deliver categories which are consistent with the Open Source Hardware Statement of Principles 1.0 without, however, giving further details on the nature of the documentation to be published.

Freedoms to study, to edit, and to make are consistent with the three factors of openness defined by Balka, Raasch, and Herstatt.[5] They respectively term these factors "transparency," "accessibility," and "replicability." Transparency refers to the possibility for any interested person to access sufficient information to understand the product in detail without restriction (which equals the freedom to study). Accessibility refers to the possibility for any interested person to edit design information and therefore to further develop the product (which equals the freedom to modify). Replicability refers to the possibility for any interested person to physically produce the product (which equals the freedom to make). These three factors of openness are introduced as preconditions for three complementary behaviors on the part of the community surrounding the product: Transparency enables observation (and eventually feedback), accessibility enables further development (and eventually co-development), and replicability enables prototyping and production (and eventually co-production). What is missing in this contribution is the fourth factor of openness termed henceforth "commercial usability," which addresses the above listed freedom to distribute.

The four freedoms and corresponding factors of openness cover both “distinct and competing meanings” of openness identified by von Hippel[30]: the permeability of the innovation process to the participation of external people and the public sharing of documentation. Transparency, replicability, and commercial usability are about sharing documentation publicly. Accessibility is about enabling the participation of external people in the design process. Aitamurto, Holland, and Hussain[31] term two meanings of openness: process openness (whether the innovation process is open or closed) and product openness (whether the innovation outcome is open or closed). Huizingh[32] defines open-source innovation as a result of both process and product openness. Raasch, Herstatt, and Balka[14] particularly deliver the following definition: “open-source innovation is characterized by 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.”

The coherent picture of OSH drawn by those definitions from practice and scholarly research is displayed in Figure 1. OSH builds upon product and process openness. Product openness results from the factors transparency, replicability, and commercial usability, which respectively address the freedoms to study, make, and distribute. Process openness results from the sole factor accessibility, which addresses the freedom to edit.


Fig1 Bonvoisin JOfOpenHard2017 1-1.png

Figure 1. Forms of openness involved in open-source hardware

Theory-practice-gap

The few existing empirical studies of OSH deliver a picture from practice observations that is less strict than the ambitious theoretical approach summarized by Figure 1, beyond the misuses, which can be expected with the upcoming of a new concept.

Balka, Raasch, and Herstatt[5] showed that factors of openness may be valued differently by development community members in the fields of consumer electronics and IT hardware. In the communities they analyzed, accessibility of software tended to play the largest role in the involvement of members, while transparency and replicability of software played a secondary role, and the openness of the related hardware played no role. They also highlighted that, as a result of the low importance given to hardware in those communities, hardware components were generally “less documented” than the software components. This raises the following research question:

RQ1 – To what extent are the four aspects of openness reflected by practitioners in the publication of product-related documentation? Do practitioners tend to employ the whole set of these factors, or do they tend to employ only subsets of these factors?

Based on interviews with originators of OSH products, Bonvoisin et al.[33] defined the contours of two archetypes of projects developing OSH they termed "development communities" and "isolated innovators." Development communities are characterized by high process openness, adopt systematic and early release policies, and gather contributions from a larger and permeable group of people. On the contrary, isolated innovators are characterized by low levels of process openness. They do not gather contributions from the outside, but rather they release complete product documentations after product versions are fully developed. While the former are interested in integrating people from the outside during the product development process, the latter are more interested in broadcasting their innovation, i.e., enabling other people to produce it. This contradicts the statement made by Gacek and Arief[34] that “the term 'open source' has been widely used to describe a software development process.” Findings reported by Bonvoisin et al.[33] suggest on the contrary that motivations for publishing documentation may depend on the phase of the product lifecycle in which the community is supposed to play a role and raise the following second research question:

RQ2 – If factors of openness are understood by practitioners as optional, can we find typical patterns in the way practitioners decide to comply with specific factors of openness? Are these aspects related to specific product lifecycle phases?

Research approach and methodology

In order to address the research questions defined above, an empirical approach based on the systematic analysis of a representative group of OSH products, as well as their published documentation, has been adopted. This approach is similar to those adopted by Balka, Raasch, and Herstatt[5][35] while avoiding two pitfalls limiting the validity of the produced results. The first is the use of unclear categories such as the size of the development community. As shown in Bonvoisin et al.[33], belonging to a development community is a fickle concept which may be based on different types of activities (from pressing the button “I like” to bringing significant contribution to the product design), which are highly flexible over time and therefore difficult to measure objectively.[f] The second is the use of subjective evaluation of the openness factors with the help of Likert scales. In contrast to the approaches of Balka, Raasch, and Herstatt[5][35], the research reported here strives at a systematic analysis of published documentation with the help of measurable indicators, from the part of an impartial observer.

In the following subsections, the approach adopted for the acquisition and the analysis of empirical data is presented. The first subsection introduces methodological choice made in focusing on non-electronic complex hardware products. The second subsection describes the method applied for the establishment of a representative pool of those products. The third subsection defines a set of criteria used to characterize products and their related documentation. The fourth subsection defines criteria for the assessment of openness factors based on the acquired data. The last subsection introduces a clustering method used for identifying typical patterns in the publication of OSH documentation.

Focus: Complex non-electronic hardware products

While the transfer of open-source principles from software to hardware historically and logically started with electronic hardware[36], other technologies are increasingly impacted by the phenomenon. The extension of open-source practices to non-electronic hardware such as mechanical products is of particular interest in terms of documentation. Electronic hardware is a thoroughly standardized field where components are purchased off the shelf. But this is not the case for mechanical hardware, where non-standardized free form components play a large role.

Also, particularly interesting is the consideration of complex products. Product complexity is defined by Jacobs[37] as “a design state resulting from the multiplicity of, and relatedness among, product architectural elements.” This characteristic influences the level of professionalization required in the development and production of a given product. It also determines whether production can take place in either DIY or industrial production settings. Noteworthy is that, while DIY and OSH are two interwoven phenomena, not every OSH product is meant to be produced in a DIY production setting.[38] Product complexity also relates to design effort in terms of resources consumed and process duration.[39] Highly complex products tend to require inputs from multiple people and are more relevant for the topic of collaborative design.

In order to reflect the challenges faced by OSH products in terms of documentation, the methodological approach pursued in this article is to focus on the most challenging range of products. The underlying assumption is that “who can do more can do less,” so what applies to complex non-electronic hardware applies also to more electronic hardware and simple products. As a consequence, this article specifically focuses on the recent evolution of the open-source movement outside the domain of electronics and DIY to those of non-electronic and complex OSH products. It excludes the field of purely electronic hardware products. Not only is this methodological choice in consistency with the academic background of the authors situated in mechanical engineering and collaborative engineering design; it is also in line with the most recent advancement of the open-source concept on forms of hardware which are in the sphere of influence in these disciplines. It should be borne in mind that the huge achievements of the still much larger open electronic hardware field have paved the way for this development. In no way is the exclusion of this field in this study an indicator of its irrelevance. Rather, it is a matter of limiting the extent of the research undertaking.

As a result of this position, in the rest of the paper, “open source hardware” is used to refer to complex, non-electronic OSH.

Product selection

In contrast to previous research works aiming at grasping the contours of a phenomenon related to open source, e.g., sharing of 3D-printed designs (see Kyriakou, Nickerson, and Sabnis[40]), no major centralized online entry point exists which aggregates relevant products in the context of OSH. While platforms such as GitHub or Thingiverse are playing this role for free and open-source software or 3D-printing communities, to date, there is no generally acknowledged and widely used online platform supporting open-source product development. These observations have been respectively made by Raasch[4] and Howard et al.[13] and are still valid. On the contrary, projects developing OSH products tend to use a wide variety of tools for collaboration and dissemination.[33]

As a result, OSH products have been identified using conventional internet search engines using a snowball-effect approach. The results of this search have been screened through a restrictive criteria set in order to ensure a conservative evaluation of the phenomenon to be studied and to keep a deliberately narrow focus within the highly diverse field of open-source innovation (see for example Ehls[41] on that topic). The following selection criteria have been applied:

  • The product is the outcome of discrete manufacturing. Products of food and process industries such as yogurt, cement, chemicals, or plastic compounds are excluded.
  • The product contains at least in-house, tangible, and non-electronic hardware, which includes mechanical or any other type of non-electronic physical elements (e.g., textile). It may eventually include electronic hardware and consequently software. Purely electronic hardware or software products such as Arduino or Linux are therefore excluded. In-house means that the piece of non-electronic hardware is "original equipment" created by the product originator and not a component bought off the shelf.
  • The product is complex. While well-defined metrics assessing product complexity on a positive real scale have been proposed in the scientific literature (e.g., Rodriguez-Toro, Jared, and Swift [39]), using those metrics requires having sufficient access to detailed data such as the number of parts. This condition is difficult to satisfy in the context of observation of partly documented and defined products. Therefore, in the following analysis, the complexity of products is evaluated with a rule of thumb: products are considered as complex if they consist of more than two parts of different materials. Products such as business card holders, cell phone cases, or other 3D-printed gimmicks are out of scope. The objective here is to bring to the foreground those open-source products that are on the upper side of the complexity scale. In other words, to select the few complex ones and let aside the myriad of gimmicks that can be found on CAD file exchange platforms such as Thingiverse or Shapeways.
  • The product is developed for functional rather than aesthetic purposes. Jewelry, artistic, and decorative items do not fulfill this criterion and therefore were not included.
  • The product is at least partly defined, i.e., is provided with sufficient documentation to indicate that the product development maturity is equivalent or above the stage “system-level design” of the product development process as defined by Ulrich and Eppinger.[42] Undeveloped product concepts are not considered. Thus, the focus delineates them from challenge platforms, which focus solely on capturing concepts from external participants.
  • The product is labelled by its surrounding community as open source. The terms “open source,” “open-source hardware,” or “open hardware” are used in the published documentation as an adjective to qualify either the product or the activities around the product. This is quite a conservative criterion. A non-negligible number of projects adopt principles of OSH without necessarily fitting neatly into this conservative criterion.
  • There are no systematic 1:1 relations between product, project, and community. For example, a community may be involved in more than one project and a project may involve the development of more than one product. However, in order to simplify the analysis, only one product per project and per community has been considered.

Data acquisition

For each of the selected products, two sets of descriptive criteria are defined. These are summarized in Table 1. The first set is dedicated to the characterization of the published product-related information. It translates in measurable terms the best practices of OSH as provided by the Open Source Hardware Association[43] and complemented by a practice review performed prior to the reported research.[28] In the absence of practicable indicators for assessing the quantity, the quality, or the relevance of a piece of information, simple binary criteria are used, which indicate the presence or the absence of a given piece of information or of a given property. The second set delivers contextual information about the product, the corresponding development project, as well as the surrounding product development community.

Table 1. Open-source hardware product characterization criteria.
Ref. Name Description
Part I – Criteria regarding shared product-related documentation
a CAD files available Boolean value indicating whether CAD files or schematics of the non-electronic hardware are available online
b CAD files aeditable Boolean value indicating whether the online released CAD files of the product are editable. CAD files are considered editable if they are released in their original format. They are not considered editable if they are only released in an export format such as PDF or STL, which does not allow further modifications.
c Assembly instructions available Boolean value indicating whether instructions for building the non-electronic hardware are available online
d Assembly instructions editable Boolean value indicating whether the published assembly instructions are editable. Assembly instructions are considered editable if they can be edited in a web 2.0 environment or downloaded as editable files. A file is furthermore considered editable if it is released in its original format. It is not considered as editable if it is only available in an export format such as PDF.
e Bill of materials available Boolean value indicating whether a bill of materials relative to the non-electronic hardware is available online
f Bill of materials editable Boolean value indicating whether the published bill of materials is editable. A bill of materials is considered editable if it can be edited in a web. 2.0 environment or downloaded as an editable file. A file is furthermore considered editable if it is released in the original format. It is not considered editable if it is only available in an export format such as PDF.
g Guidelines for participation Boolean value indicating whether guidelines for participation or a dedicated call for contribution are provided to potential contributors
h Commercial usage allowed Boolean value indicating whether the licence applied to the non-electronic hardware allows commercial usage of the published content. If no licence is applied, the criterion is set to false.
Part II – Criteria regarding contextual information
i License Licensing scheme used for the publication of the non-electronic hardware
j Contains electronics Boolean value indicating whether the product contains electronic hardware components as well
k Maturity Defines the maximum maturity level achieved by one of the eventual versions of the product over time. Five maturity levels are defined in the order of increasing liability risk:
 

1. Design - There is only a theoretical design that is still to be fully developed. No liability of the product originator applies.
2. Prototype - The early design phases have been completed and the first functional prototype has been built. No liability of the product originator applies.
3. Production/DIY - The product is fully defined and documented and can be replicated. No liability of the product originator applies.
4. Production/Kit - The product is sold by a commercial actor as a kit. Limited availability applies to the vendor.
5. Production/full product - The product is sold by a company as a finished product. Full availability applies to the vendor.

l Status of the community Binary value indicating whether the community is active. The community is considered inactive in case no activity (encompassing either product development or sales and marketing) can be detected on the website or the collaboration platforms within one year.
m Product category Classification of the products in product groups

Criteria are evaluated based on information that can be accessed through the websites of the product development communities. For the four criteria “CAD files available,” “assembly instructions available,” “bill of materials available,” and “guidelines for participation,” the following practical cut-off rule is applied for each binary criterion: If the necessary information to satisfy a criterion cannot be found in less than 10 minutes, it is considered unavailable. This cut-off rule is consistent with the fact that accessibility to documents required by the Open Source Definition implies not only that these documents can be accessed, but also that they can be found easily.

Note that with the focus of the prior subsection titled “Focus: Complex non-electronic hardware products,” solely the documentation relative to the non-electronic hardware has been assessed. Documentation regarding electronic hardware and software has not been regarded. The authors emphasize here that this does not mean that the openness of electronic hardware has lower relevance in general. This methodological choice is instead dictated by the background of the authors and the willingness to limit volume of data to be gathered in this study. This attempt is based on the assumption that data gathered for non-electronic hardware are representative for data about electronic hardware.

Also, this article specifically focuses on OSH development. The use of OSH may require pieces of documentation which are not considered here, such as operating instructions and parts specifications. Withholding this information may render a product useless or even unsafe. The provision of operating instructions is for this reason legally requested in specific product branches such as an automobile. As a consequence, the provision of operational instructions has not been considered as a distinctive characteristic of OSH in this article.

Openness assessment criteria

Based on the data defined in previous sections, four composite criteria are defined for assessing the compliance of the product-related documentation to the four factors of openness:

  • The transparency (T) criterion addresses the freedom to study. A product satisfies this criterion when CAD files are published.
  • The accessibility (A) criterion addresses the freedom to modify. A product satisfies this criterion when all published content is editable or when a guideline for participation is available.
  • The replicability (R) criterion addresses the freedom to make. A product satisfies this criterion when assembly instructions and bill of materials are available.
  • The commercial usability (C) criterion addresses the freedom to distribute. A product satisfies this criterion when licences applied to the non-electronic hardware allow commercial usage of the published content.

The four criteria are defined as logical operations on the Boolean values [a,…,h] as depicted by the following equation:



In addition to this, a global openness index (OI) is defined as a cumulative point system. A product gets one point each time one of the criteria a, b, c, d, e, f, g, and h is satisfied. An OI = 8 means the product fully satisfies the best practices of OSH. An OI = 0 means the product satisfies none of the criteria defining OSH. The openness index is defined in the next equation:



Clustering

In order to identify typical patterns in the publication of product-related documentation, products are clustered according to the values of the eight binary criteria [a,…,h] defined above. The k-medioids algorithm (or PAM, Partitioning Around Medioids) has been used since it is particularly adapted to the clustering of objects described by categorical data. This method requires as input an n*n matrix giving a measure of the similarity of each pair of product. Each product is represented by a binary word of eight bits, with each bit representing a criterion from a to h, as described in the following equation:


Where:

  • Pi is an eight-bit word representing the product i; and
  • ai, …, hi are the binary values of criteria a to h evaluated for product i.


Inter-product similarity is computed according to the Manhattan distance[44] of the products’ descriptive 8-bit words as described in the following equation:


Where:

  • Sij is the Manhattan distance of binary words Pi and Pj and is a numerical of [0, 8]. A distance of 0 means words are equal. A distance of 8 means words are completely different.
  • Pi,k and Pj,k are respectively the kth bit of words Pi and Pj; and
  • Γ is the function defined in the second equation.


The k-medioids algorithm requires also as parameter the number of clusters to be defined. The optimal number of clusters—so that adding another cluster does not provide further information—is calculated with the help of the elbow method.[45]

Results

A data acquisition campaign was carried out between March 2016 and April 2017. This large time period ensured sufficient exhaustiveness of the snow-ball research. At the same time, it generated risks of data obsolescence. Therefore, the gathered data set was screened and actualized in its entirety in a last verification pass performed May 2017. In total, 132 products were found which satisfied the conservative selection criteria. Further modifications of the considered objects of research that occurred after May 2017 were not considered and are not reported in this article.

Pool of gathered products

The selected products cover a wide range of categories. The largest categories represented are machine tools (33 products), vehicles (18 products), and robotics (11 products), as well as medical and laboratory equipment (9 products each, Figure 2a). The category of machine tools includes mainly desktop machine tools such as the 3D printer Ultimaker or the laser cutter Lasersaur. The vehicles category mainly consists of bikes like XYZ Space Frame Vehicles and cars like the Tabby OSVehicle. The robotics category is largely represented by humanoid robots developed for teaching or research purposes, such as the igus Humanoid Open Platform. Finally, the medical equipment category covers diverse products like OpenBionics’ Prosthetic Hand or diagnostic equipment such as the echo-stethoscope echOpen.


Fig2 Bonvoisin JOfOpenHard2017 1-1.png

Figure 2. Characterization per product category (a), per technology (b) and per project status (c)

In total, a share of 43% of these (57 products) consist exclusively of non-electronic components. The remaining share of 57% (75 products) also comprise electronic hardware as well as software (Figure 2b). Three quarters of the products are currently developed and/or marketed; while other products originate from projects which are not active anymore (Figure 2b).

The distribution of products per maturity level, depicted in Figure 3, indicates that the majority of the selected products has reached a stage of development that enables systematic replication and production; 70% are in production stages.


Fig3 Bonvoisin JOfOpenHard2017 1-1.png

Figure 3. Distribution of products per maturity level

Overall openness of the published documentation

Figure 4 depicts the number of products satisfying the criteria a to h, as well as the distribution of products along the openness index (OI). The most satisfied criterion is the publication of CAD files (criterion a, with 77%, 102/132) and the least satisfied are the publication of a call for contribution and the editability of assembly instructions (criterion g and d, with respectively 26% and 25%, 34/ and 33/132). In total, 11 products satisfy all criteria [a,…,h], while 10 products satisfy none of them. The arithmetic mean of the openness index of all products is 4.2 points (median value 4 points).


Fig4 Bonvoisin JOfOpenHard2017 1-1.png

Figure 4. Number of products satisfying the criteria a to h

Figure 5 shows the number of products satisfying the four criteria of openness (T, A, R, and C). The most satisfied criterion is transparency (T, 77%, 102/132), respectively followed by commercial usability (C, 72%, 95/132), replicability (R, 60%, 80/132), and accessibility (A, 41%, 54/132). In total, 22 products comply with all the four criteria, while 11 others fulfill none of them. The average number of criteria fulfilled is 2.5 (median value 3).


Fig5 Bonvoisin JOfOpenHard2017 1-1.png

Figure 5. Number of products satisfying the criteria T, A, R, and C

This data highlights a certain heterogeneity of practices in the publication of OSH product documentation. The large spectrum of openness observed tends to indicate that the different factors of openness are considered by practitioners more as optional factors rather than mandatory ones. On one side of the spectrum, a few products can be considered as fully open, because they satisfy the four criteria of openness (17%, 22/132) or get the maximal openness index (11%, 15/132). On the other side of the spectrum, another few products can be considered as fully closed, as they either do not satisfy any of the four criteria of openness (8%, 10/132) or get a null openness index (8%, 11/132). Between those extremes, the large majority of products show diverse profiles of partial openness, without clearly identifiable patterns.

Relative frequency of openness factors

Results provided by Figure 4 suggest that transparency and commercial usability may be aspects which are given high importance on average or which are easily achievable, while accessibility is an aspect which may be given low importance on average or difficult to achieve.

Transparency is not associated with high additional costs, as it is related to the publication of files which are required in the development process (CAD files and schematics). Nonetheless, a significant number of products (almost one fourth) are not providing these files publicly.

Commercial usability is related to IP risks. The commercial usability aspect is at the core of the concept of open source, yet more than one third of the products are not provided with a licence allowing commercial usage or are published under licences excluding commercial usage. In the latter case, these products are actually unambiguously not complying with the Open Source Hardware Statement of Principles 1.0, which requires explicitly the use of licences allowing commercial usability.

The lower occurrence rate of replicability may be explained by the corresponding additional effort. Indeed, it requires more resources to make a product replicable than transparent or commercially usable. Furthermore, while transparency is about sharing files which are required for the development process of the product and exist whether or not the product is open source, replicability requires the formalization of assembly instructions and bill of materials, which is a time intensive activity. Not all communities may be willing to make the effort to formalize these documents. Moreover, assembly instructions may only be relevant for products which are meant to be produced in a DIY production setting. In the context of projects dedicated to the development of complex OSH products which are meant for industrial production, assembly instructions may be secondary or even irrelevant information.

The lower occurrence rate of accessibility may also be explained by the corresponding additional effort. As introduced earlier, accessibility is a precondition for the emergence of a community-based co-development process. Integrating contributions from a development community implies significant coordination costs and requires dedicated resources. As accessibility supports a process which is difficult to implement in practice, not all product originators may give this aspect a high priority.

Role of contextual criteria in openness

Table 2 compares the openness of all products categorized along three assessed contextual criteria: product maturity, whether products are purely mechanical or mechatronic, and whether the surrounding community is active or inactive.

Table 2. Openness vs. contextual criteria
Number of products OI Transparency Accessibility Replicability Commercial usability
Mean value Absolute Relative Absolute Relative Absolute Relative Absolute Relative
Concept 14 1.64 4 29% 6 43% 1 7% 7 50%
Prototype 26 2.54 14 54% 10 38% 6 23% 16 62%
Production/DIY 61 4.93 54 89% 26 43% 48 79% 46 75%
Production/kit 16 5.38 15 94% 4 25% 15 94% 14 88%
Production/full product 15 4.80 15 100% 8 53% 10 67% 12 80%
Mechanic 57 3.65 38 67% 25 44% 30 53% 39 68%
Mechatronic 75 4.53 64 85% 29 39% 50 67% 56 75%
Active 99 4.57 83 84% 46 46% 67 68% 76 77%
Inactive 33 2.91 19 58% 8 24% 13 39% 19 58%

A first possible reason for the absence of published documentation may be that this documentation does not exist and cannot exist in the level of detail required by the criterion used here. Indeed, in early design stages, the product documentation may not be mature enough for the product concept to be formalized into CAD files, assembly instructions, and bills of materials. This explanation tends to be supported by the gathered data, as the average openness index of products in the early phases (concept and prototype) is significantly lower than those of production phases (DIY, kit, full product production). The percentage of products satisfying the criterion of transparency grows along with product maturity: it is lower than 54% in the concept and prototype phases and grows over 89% in the other phases. The average openness index increases as well; however, it starts to sink again at the last stage (full product production) due to lower replicability and commercial reusability. In this phase, products are marketed by companies which are taking financial risks. This may make them hesitant to disclose information that facilitates imitation.

A second possible reason for the absence of published documentation may be that the community which drove the product development is not active anymore. In that case, there is not enough workforce anymore to maintain data online; links become “dead links” and information finally disappears. This explanation tends to be supported by the gathered data, as the average openness index is significantly higher for products with active surrounding communities than for products with inactive communities (respectively 4.57 points and 2.91 points).

A third possible reason for the absence of published documentation may be that the community which drives the product development does not follow an open-source approach for the entire product but only for selected components. A straightforward case is when products include off-the-shelf components which are not open source. Another case is when originators deliberately exclude a developed component from the open-source approach in order to protect their strategic knowledge. This behavior has been previously empirically observed and is discussed by Balka, Raasch, and Herstatt.[5] It is however explicitly excluded by the Open Source Hardware Certification Programme of the Open Source Hardware Association, as it is claimed that “all parts, designs, code, and rights under the control of the creator must be made open.”[46] In the current study, only the openness of mechanical components has been assessed, and those of software and electronic hardware components contained in mechatronic products have been left aside. It is therefore possible that a mechatronic product appears here as non-open although the corresponding electronic hardware and software are open source. Following this explanation, there would be a high chance that the average openness of mechanical parts of mechatronic products should be lower than those of purely mechanical products. This explanation is however not supported by the gathered data, as the average openness index is higher for mechatronic products than for purely mechanical products.

The following other possible interpretations of the absence of published documentation cannot be verified by the data gathered in this article:

  • The intention of openness is given in the product development project, but the project lacks capacity to document and to put the product-related documentation online. Although in open-source communities publishing documentation is seen as a way to gather new workforce, generating product documentation remains a time-consuming process and may get lower priority than other product development activities.
  • There is a certain delay between the statement that the product is open source and the actual disclosure of product-related information. Project initiators may start claiming a product is open source before the corresponding documentation is put online.
  • The product is claimed to be open source whereas no intention to publish product-related information is given in the product development project, what we can term here as “openwashing” in analogy to “greenwashing” or “whitewashing.”

Typical profiles

In order to identify possible typical profiles, the k-medioids algorithm has been computed on the dataset leading to the identification of five clusters. The similarity matrix reordered according to the identified clusters is displayed in Figure 6.


Fig6 Bonvoisin JOfOpenHard2017 1-1.png

Figure 6. Heatmap representing the Manhattan distance Sij between each pair of the 132 products (dark green pairs are similar, light green are dissimilar)

The openness of the products of each cluster is displayed in Table 3 and described hereafter:

  • Cluster 1. Fully open products which satisfy almost all openness criteria and having hence a high average OI value (mean value 6.83/8)
  • Cluster 2 and 3. Products being transparent, replicable and commercially usable but not accessible; their average OI value is medium to high (mean value respectively 5.23 and 3.81/8) and is mainly handicapped by the lack of accessibility.
  • Cluster 4. Products being transparent, accessible and commercially usable but not replicable; their average OI value is medium to low (mean value 2.94/8) and is mainly handicapped by the lack of replicability
  • Cluster 5. Fully closed products, i.e., products for which almost no documentation can be found and out of which two thirds do not provide commercially usable documentation; their average OI value is very low (mean value 0.83/8)
Table 3. Openness of the four identified clusters
Cluster Number of products OI Transparency Accessibility Replicability Commercial usability
Mean value Absolute Relative Absolute Relative Absolute Relative Absolute Relative
C1 29 6.83 26 90% 24 83% 28 97% 24 83%
C2 31 5.23 31 100% 7 235 27 87% 26 84%
C3 31 3.81 28 90% 5 16% 25 81% 24 77%
C4 17 2.94 15 88% 10 59% 0 0% 13 76%
C5 24 0.83 2 8% 8 33% 0 0% 8 33%

Footnotes

  1. For an overview of OSH licences, see for example Katz.[6]
  2. Thingiverse is a platform that allows users to share a huge variety of 3D models based on CAD or STL files.
  3. Enable Outreach is a network of makers that collaborate locally with disabled children to provide them with adapted 3D printed hand prosthesis.
  4. Evolutionary design may not generally contradict parallelization or staging of processes, i.e., in the intra-project environment for scaling and efficiency. Also, this is different from the predetermined mechanism of breaking down problems into constituent parts (modularization) and avoids creation of task interdependencies.
  5. These four freedoms are derived from the free software definition[26], which are: Freedom 0, the freedom to run the program for any purpose; Freedom 1, the freedom to study how the program works; Freedom 2, the freedom to redistribute copies; Freedom 3, the freedom to distribute copies of modified versions. In the transition from the context of immaterial intellectual property to the realm of tangible products, these freedoms have been reinterpreted. For example, running a program requires compiling the source code (an action alternatively termed as build or make in the software jargon). The freedom to run became the freedom to make the product, that is, to produce it.
  6. or deeper insights into the different degrees of involvement in open source communities, see for example Gacek and Arief.[34]

References

  1. Hatch, M. (2013). The Maker Movement Manifesto: Rules for Innovation in the New World of Crafters, Hackers, and Tinkerers. McGraw-Hill Education. ISBN 9780071821124. 
  2. Voigt, C.; Montero, C.S.; Menichinelli, M. (2016). "An Empirically Informed Taxonomy for the Maker Movement". In Bagnoli, F., Satsiou, A.; Stavrakakis, I. et al.. Internet Science - INSCI 2016. Lecture Notes in Computer Science. 9934. Springer. doi:10.1007/978-3-319-45982-0_17. ISBN 9783319459820. 
  3. Balka, K. (2011). Open Source Product Development - The Meaning an Relevance of Openness. Gabler Verlag. p. 4. doi:10.1007/978-3-8349-6949-1. ISBN 9783834969491. 
  4. 4.0 4.1 4.2 Raasch, C. (2011). "Product Development in Open Design Communities: A Process Perspective". International Journal of Innovation and Technology Management 8 (4): 557–75. doi:10.1142/S021987701100260X. 
  5. 5.0 5.1 5.2 5.3 5.4 5.5 Balka, K.; Raasch, C.; Herstatt, C. (2014). "The Effect of Selective Openness on Value Creation in User Innovation Communities". The Journal of Product Innovation Management 31 (2): 392–407. doi:10.1111/jpim.12102. 
  6. Katz, A. (2012). "Towards a Functional Licence for Open Hardware". The Journal of Open Law, Technology & Society 4 (1): 41–62. doi:10.5033/ifosslr.v4i1.69. 
  7. Balka, K. (2016). "Project List". Open Innovation Projects. Archived from the original on 27 September 2016. https://web.archive.org/web/20160927222446/http://open-innovation-projects.org/project-list. 
  8. Moritz, M.; Redlich, T.; Krenz, P. et al. (2015). "Open up or Close down - The new Era of “Openneers” and how they lead the Way to Future Success". Journal of Systemics, Cybernetics and Informatics 13 (6): 15–22. http://www.iiisci.org/journal/sci/FullText.asp?var=&id=HB188KY15. 
  9. 9.0 9.1 Pearce, J.M. (2017). "Emerging Business Models for Open Source Hardware". Journal of Open Hardware 1 (1): 2. doi:10.5334/joh.4. 
  10. 10.0 10.1 Li, Z.; Seering, W.; Ramos, J.D. et al. (2017). "Why Open Source?: Exploring the Motivations of Using an Open Model for Hardware Development". Proceedings of the ASME 2017 International Design Engineering Technical Conferences and Computers and Information in Engineering Conference. doi:10.1115/DETC2017-68195. 
  11. Fjeldsted, A.S.; Adalsteinsdottir, G.; Howard, T.J. et al. (2012). "Open Source Development of Tangible Products - From a business perspective". Proceedings of NordDesign 2012. https://orbit.dtu.dk/en/publications/open-source-development-of-tangible-products-from-a-business-pers. 
  12. Bonvoisin, J.; Boujut, J.-F. (2015). "Open Design Platforms for Open Source Product Development: Current State and Requirements". Proceedings of the 20th International Conference on Engineering Design 8: 11–20. https://www.designsociety.org/publication/37899/OPEN+DESIGN+PLATFORMS+FOR+OPEN+SOURCE+PRODUCT+DEVELOPMENT%3A+CURRENT+STATE+AND+REQUIREMENTS. 
  13. 13.0 13.1 Howard, T.J.; Achiche, S.; Özkil, A. et al. (2012). "Open Design and Crowdsourcing: Maturity, Methodology and Business Models". Proceedings of DESIGN 2012: 181–90. https://www.designsociety.org/publication/31985/OPEN+DESIGN+AND+CROWDSOURCING%3A+MATURITY%2C+METHODOLOGY+AND+BUSINESS+MODELS. 
  14. 14.0 14.1 Raasch, C.; Herstatt, C.; Balka, K. (2009). "On the open design of tangible goods". R&D Management 39 (4): 382–93. doi:10.1111/j.1467-9310.2009.00567.x. 
  15. Hansen, A.; Howard, T.J. (2013). "The Current State of Open Source Hardware: The Need for an Open Source Development Platform". ICoRD'13: 977–88. doi:10.1007/978-81-322-1050-4_77. 
  16. Camarinha,-Matos, L.M.; Afsarmanesh, H.; Galeano, N. et al. (2009). "Collaborative networked organizations – Concepts and practice in manufacturing enterprises". Computers & Industrial Engineering 57 }issue=1: 46–60. doi:10.1016/j.cie.2008.11.024. 
  17. Maher, M.L.; Paulini, M.; Murty, P. (2010). "Scaling Up: From Individual Design to Collaborative Design to Collective Design". Proceedings from Design Computing and Cognition '10: 581–99. doi:10.1007/978-94-007-0510-4_31. 
  18. Paulini, M.; Murty, P.; Maher, M.L. (2013). "Design processes in collective innovation communities: A study of communication". CoDesign - International Journal of CoCreation in Design and the Arts 9 (2): 90–112. doi:10.1080/15710882.2012.716850. 
  19. West, J.; Lakhani, K.R. (2008). "Getting Clear About Communities in Open Innovation". Industry and Innovation: 223–31. doi:10.1080/13662710802033734. 
  20. von Hippel, E. (2006). Democratizing Innovation. MIT Press. pp. 4, 165. ISBN 9780262720472. 
  21. Aksulu, A.; Wade, M.R. (2010). "A Comprehensive Review and Synthesis of Open Source Research". Journal of the Association for Information Systems 11 (11): 576–656. doi:10.17705/1jais.00245. 
  22. 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): 615–758. doi:10.1287/orsc.14.6.633.24866. 
  23. Howison, J.; Crowston, K. (2014). "Collaboration Through Open Superposition: A Theory of the Open Source Way". MIS Quarterly 38 (1): 29–50. https://misq.org/collaboration-through-open-superposition.html. 
  24. Maher, M.L.; Poon, J.; Boulanger, S. (1996). "Formalising Design Exploration as Co-Evolution". Advances in Formal Design Methods for CAD: 3–30. doi:10.1007/978-0-387-34925-1_1. 
  25. Open Source Hardware Association (2016). "Definition (English)". https://www.oshwa.org/definition/. 
  26. Free Software Foundation (2015). "What is free software?". GNU.org. https://www.gnu.org/philosophy/free-sw.en.html. 
  27. Open Source Initiative (2007). "The Open Source Definition (Annotated)". https://opensource.org/osd-annotated. 
  28. 28.0 28.1 Bonvoisin, J.; Schmidt, K.C. (15 February 2017). "Best practices of open source mechanical hardware: A guide with practical advice for sharing product-related documentation". DepositOnce. doi:10.14279/depositonce-5729. https://depositonce.tu-berlin.de/handle/11303/6164. 
  29. Wang, H.; Johnson, A.L.; Bracewell, R.H. (2012). "The retrieval of structured design rationale for the re-use of design knowledge with an integrated representation". Advanced Engineering Informatics 26 (2): 251–66. doi:10.1016/j.aei.2012.02.003. 
  30. von Hippel, E. (2010). "Comment on ‘Is open innovation a field of study or a communication barrier to theory development?’". Technovation 30 (11–12): 555. doi:10.1016/j.technovation.2010.09.003. 
  31. 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. 
  32. 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. 
  33. 33.0 33.1 33.2 33.3 Bonvoisin, J.; Laetitia, T.; Mies, R. et al. (2017). "Current state of practices in open source product development". Proceedings of the 21st International Conference on Engineering Design 2: 111–120. https://www.designsociety.org/publication/39565/Current+state+of+practices+in+open+source+product+development. 
  34. 34.0 34.1 Gacek, C.; Arief, B. (2004). "The many meanings of open source". IEEE Software 21 (1): 34–40. doi:10.1109/MS.2004.1259206. 
  35. 35.0 35.1 Balka, K.; Raasch, C.; Herstatt, C. (2009). "Open source enters the world of atoms: A statistical analysis of open design". First Monday 14 (11). doi:10.5210/fm.v14i11.2670. 
  36. Gibb, A. (2014). Building Open Source Hardware: DIY Manufacturing for Hackers and Makers. Addison-Wesley Professional. ISBN 9780321906045. 
  37. Jacobs, M.A. (2007). "Product Complexity: A Definition and Impacts on Operations". Decision Line 38 (5): 6–9, 21. https://ecommons.udayton.edu/mis_fac_pub/94. 
  38. Bonvoisin, J.; Galla, J.K.; Prendeville, S. (2017). "Design Principles for Do-It-Yourself Production". Proceedings from Sustainable Design and Manufacturing 2017: 77–86. doi:10.1007/978-3-319-57078-5_8. 
  39. 39.0 39.1 Rodriguez-Toro, C.A.; Jared, G.; Swift, K. (2004). "Product-Development Complexity Metrics: A Framework for Proactive-DFA Implementation". Proceedings of DESIGN 2004: 483–90. https://www.designsociety.org/publication/19794/PRODUCT-DEVELOPMENT+COMPLEXITY+METRICS%3A+A+FRAMEWORK+FOR+PROACTIVE-DFA+IMPLEMENTATION. 
  40. Kyriakou, H.; Nickerson, J.V.; Sabnis, G. (2017). "Knowledge Reuse for Customization: Metamodels in an Open Design Community for 3D Printing". MIS Quarterly 41 (1): 315-332. doi:10.25300/MISQ/2017/41.1.17. 
  41. Ehls, D. (2015). "Diversity of Participants in Open Source Projects: Comparing Individual Demographics and Participation Rationales in Software, Content, Fun, and Business Communities". In Herstatt, C.; Ehls, D.. Open Source Innovation: The Phenomenon, Participant's Behaviour, Business Implications. Routledge. pp. 63–80. ISBN 9781315754482. 
  42. Ulrich, K.T.; Eppinger, S.D. (2011). Product Design and Development (5th ed.). McGraw-Hill Education. ISBN 9780073404776. 
  43. Open Source Hardware Association (2013). "Best Practices for Open-Source Hardware 1.0". https://www.oshwa.org/sharing-best-practices/. 
  44. Choi, S.-S.; Cha, S.-H.; Tappert, C.C. (2010). "A Survey of Binary Similarity and Distance Measures". Journal of Systemics, Cybernetics and Informatics 8 (1): 43–48. http://www.iiisci.org/journal/sci/FullText.asp?var=&id=GS315JG. 
  45. Tibshirani, R.; Walther, G.; Hastie, T. (2001). "Estimating the number of clusters in a data set via the gap statistic". Statistical Methodology Series B 63 (2): 411–23. doi:10.1111/1467-9868.00293. 
  46. Open Source Hardware Association (2017). "Requirements for Certification". https://certificate.oshwa.org/. 

Notes

This presentation is faithful to the original, with only a few minor changes to presentation. In some cases important information was missing from the references, and that information was added. The original article lists references alphabetically, but this version—by design—lists them in order of appearance. To more easily differentiate footnotes from references, the original footnotes (which where numbered) were updated to use lowercase letters. Some footnotes simply referencing web pages were either turned into inline links or removed entirely for being superfluous. In the original, the citation for the Free Software Foundation 2015 is inadvertently missing; the presumed citation is added in this version.