{"id":7863,"date":"2019-03-22T02:04:38","date_gmt":"2019-03-22T02:04:38","guid":{"rendered":"http:\/\/peerproduction.net\/editsuite\/?page_id=7863"},"modified":"2019-04-03T21:42:48","modified_gmt":"2019-04-03T21:42:48","slug":"open-source-beyond-software","status":"publish","type":"page","link":"http:\/\/peerproduction.net\/editsuite\/issues\/issue-13-open\/peer-reviewed-papers\/open-source-beyond-software\/","title":{"rendered":"Open Source beyond software: Re-invent open design on the Common&#8217;s ground"},"content":{"rendered":"<p style=\"text-align: right;\"><strong>By Kosmas Gavras<\/strong><\/p>\n<p style=\"text-align: right;\"><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Open-Source-beyond-software.pdf\">Download as PDF<\/a><\/p>\n<h2>INTRODUCTION<\/h2>\n<p>Open source software (OSS) has become a dominant mode of production in a number of areas such as server software, operating systems and scripting languages (Lerner and Tirole, 2005; Chesbrough and Appleyard, 2007). Since the last decade, several studies have focused to a wider applicability (von Krogh and von Hippel, 2006; Nuvolari and Rullani, 2007) of the OSS organizational and production model (von Hippel and von Krogh, 2003; Osterloh and Rota, 2007). Benkler (2002, 2006) draws from OSS and early P2P sharing networks, to describe a third mode of production, the Commons based peer production (CBPP), extending beyond software to open content such as Wikipedia and Openstreetmap among others. Additionally, an equally important direction is the extension of the open source model to the world of tangible objects (Raasch et al., 2009; Balka et al., 2009a, 2009b; Shirky, 2005).<\/p>\n<p>Initially, a significant number of free and OSS theorists have objected to, or at least have been sceptical of, the openness parallelization between bits and atoms (Stallman, 1999; Raymond, 1999a; Maurer and Scotchmer, 2006; Ackermann, 2009). However, in the course of time the open source hardware\u2019s (OSH\u2019s) potential was realized, as among other advantages, the OSH will represent the only possibility to run freely OSS in the near future (Stallman, 2015). In the mean time a lot of major OSH projects have emerged. Indicatively, some of the most prominent approaches are located in the fields of: Electronics (Arduino), Mechanical (Farmhack, Ateliers Paysan, Open Source Ecology), Mechatronics (RepRap, OpenBionics), Non electronic &#8211; nor mechanical (Wikihouse, Opendesk, Openstructures, Open Architecture Network, Hexayurt).<\/p>\n<p>Von Hippel makes a parallelization between OSS and open design (OD) as the immaterial phase of OSH: <em>&#8216;Hardware is becoming much more like software up to the point you actually fabricate an object.&#8217;<\/em> (Von Hippel in Thompson, 2008).<\/p>\n<p>Despite most of the OSH\u2019s theoretical background was transcribed from OSS\u2019s principles and licenses, the main theoretical stake persists. What is the &#8216;source code&#8217; of OSH? The profound answer that design is the &#8216;source code&#8217; of hardware is not solid and specific enough to establish an analytical framework (Vardouli and Buechley, 2014; Fuller and Haque, 2008). The purpose of the research is to provide a critical insight to existing OSH and OD theoretical definitions and describe potential new dimensions based on the following starting points:<\/p>\n<ul>\n<li>Current OSH\u2019s theoretical framework is based to two cumulatively applied assumptions. Firstly, it is assumed that design for hardware is what source code for software. Secondly, it is deducted that by applying to design, the same license\u2019s degrees of freedom that have been applied to OSS, then design will be turned to open source design or simply OD. While license principles are exogenous properties of source code, and thus easily transferable to other fields, it may be more fruitful to examine how intrinsic OSS\u2019s properties could be tranfered to hardware\u2019s design.<\/li>\n<li>Even if design as well as source code are essentially immaterial, we should always consider that design is not an end in itself but an integral input in the design-construction continuum. In this way, the theoretical foundation of OSH and OD should extend beyond the mere replication of OSS\u2019s model in order to reflect the digital fabrication revolution and the emergence of makerspaces.<\/li>\n<li>Hardware is a broad and generic description for diverse groups of objects while software is a much more coherent concept. Therefore, the design of a microcontroller may not share the same principles with the design of a piece of furniture. Consequently, it is meaningful to evaluate whether current OSH theoretical framework is applicable towards non-examined subsets of hardware.<\/li>\n<\/ul>\n<p>In order to describe the &#8216;source code&#8217; of OSH, we will analyze a set of case studies against existing OSH definitions and in relation with the above-mentioned points. Specifically, we will highlight inefficiencies or inconsistencies of existing OSH theory in the given context and suggest ways to overcome the recognized limitations. The article is structured as follows: In the next section we describe the existing literature context that operationalizes the research framework. The stimulated research questions as well as the research approach and methodology are developed in the third section. Successively, the fourth section contains the case study analysis. The fifth section discusses the resulting limitations and outlines an emergent OSH and OD direction based on the instrumental potential of the case study research. The final section provides a conclusion of research results along with directions for future elaboration.<\/p>\n<h2>LITERATURE REVIEW<\/h2>\n<h3>The multiple dimensions of OD<\/h3>\n<p>The term OD does not imply a single and cohesive meaning (De Mul, 2011; Vardouli and Buechley, 2014). In theory and practice it is often used interchangeably with different but frequently complementary meanings, such as the collaborative, cooperative or participatory design (Habraken, 1972; Kaspori, 2003; Salingaros et al., 2010; Manzini, 2015; Ratti and Claudel, 2015), the modular design (Fuller and Haque, 2008; Kostakis and Papachristou, 2014a), or the freely and globally shared design (Open Architecture Network, no date; Open Architecture License, 2016). Actually, all of those meanings represent major dimensions of an evolving OD definition in the framework of digital Commons and digital fabrication.<\/p>\n<p>Analytically, the Design Global, Manufacture Local (DGML) model (Kostakis et al., 2015) highlights a new productive model with transformative socio-economic implications that is based on the convergence of globally shared OD Commons with desktop manufacturing. The voxel-based fabrication describes a modular design methodology along with an experimental manufacturing technique, which is based on the discourse between digital and analog materiality (Gershenfeld 2007, 2012; Gershenfeld et al., 2017; Kostakis and Papachristou, 2014a; Hiller and Lipson, 2009). At last, participatory design has a history that precedes the domination of the open source model. During the decade of 1970s the approaches of Habraken (1972), Friedman (1975) and Alexander et al. (1977) targeted to the user empowerment in the design process. Despite the aim for increasing user participation, there was always a common and clear separation line between what Manzini (2015) defines as expert and diffuse design. In the case of Habraken (1972) it was the distinction between the design of structure and infill that reflects the bipole of expert and user. Alexander et al. (1977) and Friedman (1975) constructed a pattern language and a computational design process respectively, as non-technical vocabularies for user participation. In general terms, the principle is common: the expert designs an almost closed system that the user interacts with. On the other hand, approaches that draw from the open source model (Kaspori, 2003; Salingaros et al., 2010) describe emphatically the demise of the expert design in the context of what Von Hippel (2017) coined as collaborative free innovation.<\/p>\n<h3>From OSS to OSH definition: the case of open-o-meter<\/h3>\n<p>Despite the existence of wide literature on various partial aspects of OSH and OD, there are very few attempts to provide an integrated definition of openness in the sphere of hardware. In general, the most systematic and comprehensive quantitative method up to date regarding hardware\u2019s openness evaluation is the open-o-meter (OPEN!, 2018). Open-o-meter is a numeric scale, consisting of eight equivalent Boolean values which cumulatively express the total openness of OSH. Analytical documentation of the openness scale (Table 1) is presented by Bonvoisin et al. (2017). While the openness levels refer to the hardware, the evaluation criteria examine exclusively aspects of immaterial documentation or OD content. In this way open-o-meter is, beyond an evaluation tool, the theoretical foundation of OD as the open hardware\u2019s &#8216;source code&#8217;.<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-1.jpg\"><img class=\"alignnone size-large wp-image-8043\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-1-1024x757.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-1-1024x757.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-1-300x222.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-1-768x568.jpg 768w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-1.jpg 1894w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/p>\n<p><strong>Table 1. Open-o-meter. OSH product characterization criteria (Bonvoisin et al., 2017). [Click image for larger view.]<\/strong><\/p>\n<p>In order to develop a critical stance on existing theoretical framework, it is important to trace open-o-meter history back (Table 2). Open-o-meter is a further specification of theoretical freedom principles (<em>study<\/em>, <em>make<\/em>, <em>modify<\/em>, <em>distribute<\/em>), and forms (<em>transparency<\/em>, <em>replicability<\/em>, <em>accessibility<\/em>) of openness, referenced in Open Source Hardware Association\u2019s Statement of Principles 1.0 (2011) and Balka et al. (2010, 2014) respectively. Successively, Open Source Hardware Association\u2019s principles are based to the Open Source Definition (Open Source Initiative [OSI], 2007).<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-2.jpg\"><img class=\"alignnone size-large wp-image-8044\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-2-1024x349.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-2-1024x349.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-2-300x102.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-2-768x262.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/p>\n<p><strong>Table 2. OSH theoretical framework as an evolution from OSS definitions. [Click image for larger view.]<\/strong><\/p>\n<p>(abbreviations: Open Source Initiative [OSI])<\/p>\n<p>Consequently, open-o-meter framework leans towards OSS rather than free and open source software\u2019s (F\/OSS\u2019s) political standpoint. As a proof of this tendency, open-o-meter defines commercial usability of design documentation and physical product, as one of the basic parameters of openness. In fact, there is a profound contradiction between commercial usability and the notion of openness, which is more evident at the immaterial side of the design-construction continuum. How can design documentation be commercially exploitable and freely editable and available concurrently? Some of the most known examples of F\/OSS (GNU\/Linux, Apache server, Mozilla Firefox) thrive in the absence of commercial appropriation. Additionally, it is proved that total openness, as expressed by the sum of transparency, replicability and accessibility excluding commercial usability criterion, increases the level of contribution (Balka et al., 2014) even if some forms of openness play a greater role than others.<\/p>\n<p>At this point, it should be stated that from an ideological point of view the author stands with the position of the Free Software Foundation (FSF), rather than that of OSI, regarding the social imperative of software (FSF, 2016). Since at the technical level, free software source code qualifies as open source code (Stallman, 2016) and vice versa, it could be supported that open source code is just one -the technical one- of the constituents of F\/OSS definition. In this sense, hereby the term open source code, OSS or open source design does not necessarily point to the OSI definition, unless otherwise explicitly stated. Additionally, taking into consideration the framework of this paper, OD is a commonly acceptable term, comparing with the limited usage of the term free design.<\/p>\n<p>To get back on track, previous research works employing a quantitative assessment of hardware\u2019s openness have covered the field of electronic products (Balka et al., 2010, 2014), as well as the field of non-electronic but mechanical hardware (Bonvoisin et al., 2017). To the author\u2019s knowledge, there is no published quantitative study evaluating openness of the OSH subset that is neither electronic nor mechanical. This absence is explained by the initial lack of OSH practices being neither electronic nor mechanical. Due to the proximity of electronic hardware with OSS movement, the earlier OSH initiatives were concerning electronic devices (Gibb, 2014) or later mechanical (Vallance et al., 2001). It is characteristic that TAPR (2007) &#8211; one of the first open hardware licenses &#8211; had considered only electrical or mechanical artifacts as potentially open hardware.<\/p>\n<p>To synopsize, the existing theoretical background of OSH is transcribed from OSS definitions and licensing schemes which are not structural properties of the source code. Even if the license profoundly affects to some extent the subsequent form and development of the code, it is not an inherent property of the code itself.<\/p>\n<h3>OSS\u2019s structural properties: the parameter of modularity<\/h3>\n<p>If the licensing schemes represent exogenous properties of open source code, which are the structural properties? According to Conway (1968:31), <em>&#8216;organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations&#8217;<\/em>. In other words, the structural properties of code or design mirror the structure of the organization that developed them. MacCormack et al. (2006, 2012) proved empirically the &#8216;mirroring hypothesis&#8217; in the field of software industry, highlighting source code\u2019s modularity. Modularity is defined as the decomposition of a product or design to independent modules. Analytically, the more distributed, informal and open organizations tend to produce the more modular codebases. On the contrary, the more centralized, hierarchical and closed organizations produce more monolithic software. As a summarizing outcome, OSS is structurally different from proprietary software in terms of modularity (MacCormack et al., 2006). The difference in modularity between the opposite ends is surprisingly large, reaching a factor of eight between software of similar size and function (MacCormack et al., 2012).<\/p>\n<p>Therefore, there is a causal bidirectional mechanism between, on the one hand, the dispersed geographical distribution of open source communities, the open contribution spirit and the informal authority, and on the other hand, the emergent modular code\u2019s structure (MacCormack et al., 2012). The causal linkage is bidirectional as <em>ex ante<\/em> modular code\u2019s structure is prerequisite for attracting and facilitating a diverse and distributed community of developers which in turn enhance the overall modular effect in the course of time (Baldwin and Clark, 2006; MacCormack et al., 2012). Preliminary design choices are proved critical regarding the potential successful evolution of OSS projects. Baldwin and Clark (2002) explicated further the importance of modularity as a structural constituent of the open source model:<\/p>\n<ul>\n<li>&#8216;<em>Modularity makes complexity manageable<\/em>&#8216; through: (i) the decomposition of complex tasks to simpler, and (ii) the parallel processing of complex tasks in the direction of selecting the optimal solution;<\/li>\n<li>&#8216;<em>Modularity enables parallel work<\/em>&#8216; through the division of a monolithic system to independent modules or what Benkler (2006) named granularity; and<\/li>\n<li>&#8216;<em>Modularity is tolerant of uncertainty<\/em>&#8216;. Code modules embed option values that render an overall code structure which is susceptible to change in potentially unforeseen ways. Modular structures can be modified and evolve over time at low cost comparing with monolithic data structures.<\/li>\n<\/ul>\n<p>To summarize, modularity is a fundamental property with causal role at the open source model that can not be omitted when transferring the open source methodology to other fields, including OSH. As a conclusion, the freedoms to <em>study<\/em> and <em>modify<\/em> depend to a great extent in code\u2019s modularity.<\/p>\n<h3>Digital fabrication from a design perspective<\/h3>\n<p>While modularity is an important parameter of an evolving OD definition, we realize that it is meaningless to examine the OSH solely as an OSS offspring, but only in a wider perspective including the technological advancements related with hardware&#8217;s material nature. For instance, the digital fabrication revolution makes feasible the distributed &#8211; even personal \u2013 manufacturing of a genealogy of customized objects, virtually at the same unit cost as if producing identical copies (Rifkin, 2014).\u00a0According to Carson (2010), manufacturing is fading as a centralized, closed and capital-intensive activity.\u00a0As a proof of concept, the digital fabrication revolution and hackerculture have already led to the emergence of a rapidly increasing global network of local makerspaces (Niaros et al., 2017), answering to the user\u2019s need for custom products (Von Hippel, 2005) among others. But manufacturing (being the second part in the design-construction continuum) depends to a great extent on the design input.<\/p>\n<p>What kind of design will form the necessary data input to a localized, on-demand, and customized fabrication? A monolithic, closed, centrally produced design aiming to cover the greater homogeneous market segment of user needs, or a modular, open, globally produced design able to be modified at low cost to fit the local needs? Lakhani describes a user-powered design innovation, proactively forcing companies out of the product design space (2007). Consequently, the real potential of digital fabrication will be actualized more effectively in combination with the peer production, in proposing an alternative, holistic emergent productive model (Kostakis et al., 2013, 2015), rather than in re-organizing existing corporate infrastructure (Hermann et al., 2016) according to design principles that are primarily native to open source culture.<\/p>\n<p>To sum up, modularity, beyond being a structural property of the open source mode of development, it is also related with the freedom to <em>make<\/em> in the socio-technological framework of digital fabrication.<\/p>\n<h2>RESEARCH DESIGN<\/h2>\n<h3>Research Questions<\/h3>\n<p>Current OSH theoretical framework have tested and been tested against electronic products (Balka et al., 2010, 2014) and mechanical devices (Bonvoisin et al., 2017), but to the author\u2019s knowledge there is not any published study concerning physical products being neither electronic nor mechanical. There is preliminary evidence that current OSH theory can not migrate free ride from one kind of hardware to another. Both electronic and mechanical devices usually include stardardized, ready-made and commercially available components to a great extent. Off-the-shelf components can limit the design and customization potential which are inherent to the concept of user-developed hardware and digital fabrication. On the other hand, non electronic or mechanical hardware, ranging from a piece of furniture to a house, is characterized by higher degree of customization. Additionally, electronic circuits, machines and other hardware do not share a common design language. Electronic design is comprised of 2d layouts; mechanical design requires a kinetic 4d approach; whereas other hardware can be thoroughly described by a 3d model.<\/p>\n<p>Bonvoisin et al. (2017) acknowledge that the broader applicability of open-o-meter is an open question. Beyond breadth, according to Bonvoisin et al. (2017) further research is required to provide an in depth qualitative specification of each openness criterion. The authors of open-o-meter followed a simplistic binary evaluation for each criterion that was practically imposed by the substantial sample size required for statistical analysis. Based on the literature review and the scope of the research, the following questions will be addressed (Figure 1):<\/p>\n<p>RQ1a &#8211; theory\u2019s breadth: Is open-o-meter a valid quantitative tool and definition in the framework of neither electronic nor mechanical hardware?<\/p>\n<p>RQ1b &#8211; theory\u2019s depth: If open-o-meter is not generically applicable, then which criteria fail to capture actual openness levels of the examined subset? How can these criteria be improved by further qualitative specification?<\/p>\n<p>RQ2 &#8211; theory\u2019s context: How is modularity, which has not been expressed directly in open-o-meter, reflected in OSH practice? How can we describe a positive feedback loop between OSH\u2019s practice and theory, based on a new reading of openness in the context of digital fabrication and OSS\u2019s structure?<\/p>\n<p><em><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-1.jpg\"><img class=\"alignnone size-large wp-image-8050\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-1-1024x718.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-1-1024x718.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-1-300x210.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-1-768x538.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/em><\/p>\n<p><strong>Figure 1. Research questions placement in the conceptual timeline diagram framed by the literature review. [Click image for larger view.]<\/strong><\/p>\n<p>(image processing: author, image source:author, abbreviations: Free and Open Source Software [FOSS], Open Source Software [OSS], Free Software Foundation [FSF], Open Source Hardware [OSH])<\/p>\n<h3>Research Approach and Methodology<\/h3>\n<p>In order to address the research questions mentioned above, we employed an empirical quantitative and qualitative case study research.<\/p>\n<p>Analytically, the hybrid quantitative-qualitative method refers to the first question (RQ1a) regarding open-o-meter theory\u2019s breadth, while following research questions will be tackled with exclusively qualitative approaches. Theory\u2019s breadth will be evaluated by the assessment of how quantified openness levels of the examined subset, actually correspond in practice to the more abstract and qualitatively approached freedoms of <em>study<\/em>, <em>make<\/em> and <em>modify<\/em> (Table 2). The quantitative method of openess\u2019 assessment is the open-o-meter (Table 1), as documented by Bonvoisin et al. (2017). Despite the fact that the original openness scale utilizes only binary value rating, the current research adopts the use of midpoint assessment, as a general measure for those cases where a variable pattern is discerned. Furthermore, the open-o-meter method followed in this article refers solely to part 1 of the original method, as the external and secondary criteria consisting the part 2 table, are mostly constrained by the case study selection process.<\/p>\n<p>Empirical data required for the quantitative assessment and the qualitative inquiry are acquired from web-based documentation and databases. Indicatively, sources that have been used depending on each occasion are the following: websites of the product development communities, archived webpages, web-based repositories, github or other party development statistics, processing of CAD or other files, participation in developers forums and communication networks, and member initiation questionnaires among others. It is important to stress that data input to the quantitative assessment, is based on the &#8216;macroscopically&#8217; observed presense or absence (or variable pattern) of certain documentation as described by open-o-meter methodology, avoiding any qualitative characterization of the usefulness of each provided document. Data analysis has followed a combination of categorical aggregation and direct interpretation strategies, as described by Stake (1995).<\/p>\n<p>The choice of case study research is based on the need for detailed examination of particular cases and their context. In this way, the shortlisted cases are intentionally not representative of the whole range of the OSH scape, but they are examined as collective &#8211; instrumental case studies (Stake, 1995), able to offer a new understanding of OD in the OSH framework. As the selection of cases is of critical importance in any type of case study research (Stake, 2003), the formal selection process and criteria actually reflect the author\u2019s strategy in the given context. Moreover, it is important to note that the aim of the collective quantitative case study research is not to concentrate on a comparative analysis per se, but to illustrate potentially different viewpoints to the research questions.<\/p>\n<p>The selection<a id=\"cite_ref_1\" href=\"#cite_note_1\">[1]<\/a> of case studies is based on an already existing online directory of OSH projects, maintained by Wikipedia (2018a) which is a prominent example of CBPP beyond software. Previous studies have employed either conventional internet search, using a snowball effect approach that was prone to be author biased or online directories built-up and biased by OSH projects\u2019 &#8216;owners&#8217;. On the other hand, the selection of a Wikipedia directory ensures a minimum consensus about what is considered by the greater community as open source. The Wikipedia online directory is a dynamic, bottom-up archive of the OSH projects, the launch of which mostly coincides with the recent history of the OSH development<a id=\"cite_ref_2\" href=\"#cite_note_2\">[2]<\/a>. The following selection criteria were applied to the initial list, in order to narrow the corpus of research, according to the research questions:<\/p>\n<ul>\n<li>The hardware is neither electronic nor mechanical. As the first two fields are already evaluated regarding openness by Balka et al. (2010, 2014) and Bonvoisin et al. (2017) respectively, it is crucial to define the complementary subset in order to test the broadness of the already set openness criteria. Moreover, the examined subset of the OSH is dictated by the background of the author in architectural design allowing an in-depth examination of qualitative properties of design process.<\/li>\n<li>Inactive communities are excluded. Evaluating inactive communities regarding openness is a task of limited value. Active communitites are considered those, who have commited a new structure upload or even a minor edit in already uploaded documentation, in the 9 months before the case selection took place. This criterion aims to exclude those communities that practically cease activities after producing the first or a few functional prototypes.<\/li>\n<li>Premature communities and projects are also excluded. An arbitrarily set time limit of 4 years from startup is considered as a reasonable time interval that most OSH communities should have acquired a certain level of maturity, if they are to do so. Another point of maturity is the production of at least one functional prototype product. Previous attempts (Bonvoisin et al, 2017) have taken into consideration immature communities among others, as shown by the fact that nearly 50% of the cases do not provide editable CAD files and almost 25% do not even publish CAD files. These results indicate either immature communities that could not be characterized as open source yet, or products that do not include any custom parts. In any case, the scope of this paper is not to study the evolution of openness in the course of development of OSH projects, but to evaluate the &#8216;source code&#8217; in relation to the discussed framework. At this point, we acknowledge the rare but possible limitation of omitting an early but open and well developed project.<\/li>\n<li>The hardware should feature a minimum level of complexity. An assumption is made that adequately complex products are considered those comprised of at least 5 parts. Web-based 3D printing repositories of nearly compact gimmicks, such as the Thingiverse, are usually characterized by an individual design approach. The rationale behind complexity constraint is that more complex objects force and require more collective product development. Peer production in its essence is a synergistic rather than an individual modus operandi.<\/li>\n<\/ul>\n<p>The OSH communities that satisfy the imposed criteria are: the Wikihouse (2018a), the Opendesk (2018) and the Openstructures (2018a). As denoted by their names, Wikihouse and Opendesk produce house and furniture designs respectively. Openstructures\u2019 range starts from furniture and household equipment, ending potentially to houses or even bigger structures.<\/p>\n<h2>ASSESSMENT OF PRACTICES<\/h2>\n<h3>Opendesk<\/h3>\n<p>Opendesk is a for-profit company, supporting an online platform that connects furniture designers with customers and local makers all over the world. It was founded in 2014, and part of the founders is part of the Wikihouse creators. Opendesk practice largely depends on the DGML model, as it is by definition a global platform for local making. Moreover, it is based completely on CNC manufacturing, as all designs are assembled from flat cut wooden profiles. Most of the furniture overpasses the assigned minimum complexity limit but features significantly less parts than other OSH projects, comprising from a few elements to some dozens of elements. Profit making comes from charging 30% of the manufacturing cost as a transaction fee every time a customer orders a piece of furniture. Apart from the transaction fee, there is a provision for a design fee which is calculated at 8% of the manufacturing cost. In any case, all of the furniture designs are freely available for personal fabrication and usage.<\/p>\n<p>Opendesk project collects 4.5 out of 8 points in the openness scale (Table 3). Assembly instructions and bill of materials (BOM) are provided in non-editable formats, whereas contribution guide is a rather vague and closed process. Furthermore, licensing does not follow a uniform pattern, featuring a variety from copyleft to licenses allowing commercial appropriation. As the object of design is considerably smaller comparing to other OSH projects, the shortage of editable supporting documentation (assembly guide, BOM) is rendered less important than the absence of an open contribution process. The top-down enforced modus operandi of Opendesk is based on a standard and fixed relation between designer(s) and object of design, not formally allowing any collective optimization process which usually is very common to every CBPP and OSS project. Actually, modifications are theoretically feasible but for personal use only, as there is not any open platform or any even informal process for forking and then merging back into master branch. To conclude, Opendesk\u2019s one way workflow is almost identical to the conventional non-participatory design process, being characterized by a small scale closed design team or individual designer, retaining a practical ownership (above formal licensing) over artifact by indirectly controlling the potential modifications. Apparently, this is related to the nature of the for-profit organization and it seriously decreases the project\u2019s overall openness. It seems not rational to rate open contribution potential equally with the existence of editable BOM or other secondary documentation. Is it open a project that just freely reveals the &#8216;source code&#8217; of the hardware but restricts users and other designers from contributing?<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-3.jpg\"><img class=\"alignnone size-large wp-image-8045\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-3-1024x310.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-3-1024x310.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-3-300x91.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-3-768x233.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/p>\n<p><strong>Table 3. Openness evaluation. [Click image for larger view.]<\/strong><\/p>\n<p>It could be supported that despite drawbacks, Opendesk still offers what is considered by open-o-meter the &#8216;source code&#8217; (editable CAD files and non-editable BOM and assembly instructions) which seems almost enough to <em>study<\/em>, <em>make <\/em>and <em>modify<\/em> the design individually. In contrast, a detailed examination of the shared &#8216;source code&#8217; will reveal that it is indirectly but efficiently restricting users and designers from altering the shared furniture designs even for personal use. The criterion regarding editable CAD files (Table 1) in practice seems a rather generic and abstract scheme. The limitation of the evaluation criterion does not lie only in the quality of CAD files, as suggested by Bonvoisin et al. (2017), but to the nature of the CAD files. To further the argument, it is required to make a clear distinction between design and fabrication CAD files. The actual shared &#8216;source code&#8217; of Opendesk is flat-cut drawings, intended for CNC manufacturing, which are provided in editable format. Fabrication files, even in native file format, are still a derivative of actual design files. It is self-evident that cut-out drawings (Figure 2) by themselves can not help neither to <em>study<\/em> nor to <em>modify<\/em> the design, but only to <em>make<\/em> it. There is no doubt that if personal resources were limitless, an expert designer could use the fabrication outline drawings and the assembly instructions to reverse-engineer the design files, but this can not be the case. Another important note, beyond the analytic distinction between design and fabrication CAD files, is that the cognitive process producing the latter from the former is of utmost importance regarding the OSH development, and definitely subject of openness evaluation. To conclude, community is not only restricted from providing optimization feedback, but it is generally constrained from <em>studying<\/em> and <em>modifying<\/em>.<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-2.jpg\"><img class=\"alignnone size-large wp-image-8051\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-2-1024x294.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-2-1024x294.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-2-300x86.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-2-768x221.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/p>\n<p><strong>Figure 2. Opendesk shared CAD files in relation to the design &#8216;source code&#8217;. [Click image for larger view.]<\/strong><\/p>\n<p>(image processing: author, image source: <a href=\"https:\/\/www.opendesk.cc\/\">https:\/\/www.opendesk.cc\/<\/a>, last visit: 01\/07\/2018)<\/p>\n<p>Even the freedom to <em>make<\/em> should not be considered as a totally independent principle from <em>studying<\/em> and <em>modifying<\/em> an object. Specifically, the three principles are interconnected to a great extent in a synergistic manner as the full potential of <em>making<\/em> is achieved only if you are first of all able to <em>study<\/em> and <em>modify<\/em>. Otherwise, the DGML concept will be deducted to a simple model of distributed &#8216;mass production&#8217;, negatively affecting the real potential of OD and digital fabrication. It is less meaningful and underutilized to use a CNC or a 3d printer just as a medium to manufacture locally identical copies of what is used to be massively designed and produced.<\/p>\n<h3>Openstructures<\/h3>\n<p>Openstructures began as a student project at Institute without Boundaries in 2006. In September of 2009, Thomas Lommee &#8211; designer and former member of the student team &#8211; organized an exhibition, showcasing the concept and some initial prototypes, as well as an open call for the collaborative development of the project. Openstructures is defined as an open modular system for building hardware &#8211; in contrast with current closed (proprietary) modular systems &#8211; which is inspired by the modularity of OSS (Openstructures, 2018b). The centerpiece of Openstructures system is OS grid, an openly shared geometrical grid, built up from the supersposition of a diagonal, polar and regular grid (Figure 3). The OS grid serves as the common compatibility base to design parts and their interfaces which then can be assembled in different combinations to form anything from furniture to houses. Another important design principle is the vertical organization of artifacts in <em>parts<\/em>, <em>components<\/em> and <em>structures<\/em> depending on the functional autonomy and relative position of each element in a posssible greater scheme. Specifically, <em>components<\/em> are made of <em>parts<\/em> and respectively <em>structures<\/em> are made of <em>components<\/em> in a recursive manner.<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-3.jpg\"><img class=\"alignnone size-full wp-image-8052\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-3.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-3.jpg 800w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-3-300x232.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-3-768x594.jpg 768w\" sizes=\"(max-width: 800px) 100vw, 800px\" \/><\/a><\/p>\n<p><strong>Figure 3. Openstructures modular grid made out of 4X4 cm square bold-lined cells. [Click image for larger view.]<\/strong><\/p>\n<p>(source: http:\/\/beta.openstructures.net\/block_images\/0000\/0242\/grid4.jpg?1268343038, last visit: 01\/07\/2018)<\/p>\n<p>&#8216;<em>The open modular system has the potential to:<\/em><\/p>\n<ul>\n<li><em>generate flexible and dynamic puzzle structures rather than uniform modular entities<\/em><\/li>\n<li><em>introduce variety within modularity<\/em><\/li>\n<li><em>stimulate re-use cycles of various parts and components<\/em><\/li>\n<li><em>enable collaborative (and thus exponential) innovation within hardware construction.<\/em>&#8216; (Openstructures, 2018b)<\/li>\n<\/ul>\n<p>In contrast with the declared intentions, Openstructures is the less open project (Table 3) in the open-o-meter scale as the contribution guide is the only steadily provided documentation. Basic documentation, as CAD files whether editable or not, is provided occasionally. Supporting documentation, as BOM or assembly guide, is totally absent and licensing does not follow a specific pattern. From a first point of view, the freedoms to <em>study<\/em>, <em>make<\/em> and <em>modify<\/em> are only occasionally exercised.<\/p>\n<p>Despite the lack of consistently open documentation, according to project\u2019s initiators, community is encouraged to participate either one or more of the following ways:<\/p>\n<ul>\n<li><em>&#8216;Designing parts, components or structures according to the OpenStructures grid<\/em><\/li>\n<li><em>Trading designs online.<\/em><\/li>\n<li><em>Exchanging your experiences and ideas with others in order to improve the system&#8217;. <\/em>(Openstructures, 2018b)<\/li>\n<\/ul>\n<p>How can it be possible to contribute to an open invitation when there is not steadily provided any hardware\u2019s &#8216;source code&#8217;? A related important observation, regarding Openstructures\u2019 online platform, is that technically each contributor is permitted to <em>modify<\/em> only those elements that he has authored. Consequently, even in these cases that the design files are available and editable, the development is characterized by a conventional, individual and authoritative design workflow. On the other hand, in the CBPP framework, the collective optimization of existing knowledge modules is equally or even more important than making new modules. Digital Commons &#8211; with OSS being an eminent example &#8211; are structured more like work in progress (Raymond, 1999b), continuously optimizing according to new inputs, rather than as finished products. As a result, an OD platform without hierachical control of what &#8211; new design &#8211; is published, while being in the correct direction, it is not a per se sufficient condition to trigger the wealth of open source collaborative practices.<\/p>\n<p>Beyond the actual technical and collaborative limitations of the platform, the Openstructures\u2019 most fundamental characteristic is the modular design development. Even if it is not explicitly mentioned, it seems that modular design in combination with the imposed classification to <em>parts<\/em>, <em>components<\/em> and <em>structures<\/em>, was indirectly a method of asynchronous collaboration and optimization. For instance, the process of re-using a <em>part<\/em> (module) from another designer to a new assembly turns the new assembly into a collaboratively produced object. In fact, a closer look to the repository reveals that most <em>structures<\/em> are composed of <em>parts<\/em> and\/or <em>components<\/em> designed by the same author, practically eliminating the potentially emergent collaborative effect.\u00a0Why does the design modularity not lead to re-use cycles in a collaborative innovation environment as declared?<\/p>\n<p>Apart from the collaborative limitations imposed by the online platform and the cases of absolute documentation scarcity, the reason lies in the essence of modularity itself. What is different, when comparing the OS grid system with the voxel-based design described by 3d printing pioneers (Hiller and Lipson, 2009; Gershenfeld, 2007, 2012), is the interface design. The potentially innumerable joints that can be designed, based on the OS grid, render any interoperability between modules unfeasible. On top of that, the hierarchical division of elements (<em>parts<\/em>, <em>components<\/em>, <em>structures<\/em>) from an individual design perspective leads to an a posteriori modularization of a structure to <em>parts<\/em> and <em>components<\/em>, in an analytic rather than a synthetic manner, with limited re-usability.<\/p>\n<p>In regard to the freedom to <em>make<\/em>, even if design files are occasionally shared, the fabrication files are never shared. This fact renders almost impossible for potential users to fabricate complex structures with little effort, efficiently precluding them from a feedback process. On the other hand, beta-testers and generally users are extremely valuable for digital Commons comparing even to developers base (Shirky, 2008). Raymond (1999b) strengthens the argument:<\/p>\n<blockquote><p><em>&#8216;# 6 Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. <\/em><\/p>\n<p><em>The power of this effect is easy to underestimate. In fact, pretty well all of us in the open-source world drastically underestimated how well it would scale up with number of users and against system complexity, until Linus Torvalds showed us differently.&#8217;<\/em><\/p><\/blockquote>\n<p>Fabrication files\u2019 contribution is not limited to the freedom of <em>making<\/em>. Moreover, fabrication drawings are not derived from design files in a deterministic way as each specific design can be materialised in more than one way. To sum up, as the production of OSH does not culminate in the design documentation, design and fabrication files as well as the intermediary process are subject to <em>study<\/em> and <em>modify<\/em> beyond merely <em>making<\/em>.<\/p>\n<h3>Wikihouse<\/h3>\n<p>Wikihouse was initiated by a non-profit foundation in 2011 (Wikipedia, 2018b), claimed to be &#8216;<em>an open source project that re-invents the way we make homes<\/em>&#8216; (Wikihouse, 2018b), based on distributed digital manufacturing. Since then, architects, builders and users had constructed pilot wikihouses all over the world, inspired from the basic Wikihouse prototype called <em>microhouse<\/em>. <em>Microhouse<\/em> ensures by definition an advanced level of complexity far from the imposed cut-off limit. According to its declaration, Wikihouse draws a clear parallelization between OSS and architectural design as &#8216;<em>digital design allows every home to be designed as code; instantly customized to its site and user<\/em>&#8216; (2018a). Moreover, it is self-defined as a collaborative project: &#8216;<em>by everyone for everyone<\/em>&#8216; (Wikihouse, 2018a), following the DGML principle: &#8216;<em>share global, manufacture local<\/em>&#8216; (Wikihouse, 2018b).<\/p>\n<p>Wikihouse\u2019s design knowledge is organized from smaller to larger elements in: <em>tools<\/em>, <em>technologies<\/em> and <em>types<\/em>. <em>Types<\/em> are ready-made building designs, hosting <em>technologies<\/em> as add-on systems which are assembled using <em>tools<\/em>. <em>Microhouse<\/em> is a one bed house design (Figure 4), currently being the only shared <em>type<\/em>. Available <em>technologies<\/em> include <em>WREN<\/em> chassis system and <em>OWL<\/em> internal door kit. The latter along with <em>tools <\/em>(mallet and a step unit) are components of limited interest and we will not analyze them further. On the other hand, <em>WREN<\/em> is an integral system for developing and sharing new Wikihouse <em>types<\/em> or modifying existing ones. Its main purpose is to automate fabrication analysis, subdivision and indexing required for the construction of 3-dimensional structural frame out of flat cut panels milled in CNC machines (Figure 5). Taking into consideration the distinction between design and fabrication CAD files as highlighted in the previous cases, <em>WREN<\/em> could be characterized as the intermediary process going from design to fabrication files. Openness levels will be assessed separately for <em>type<\/em> and <em>technologies<\/em> as they do not share the same documentation. Digital repositories of <em>type<\/em> and <em>technologies<\/em> are maintained at Github<a id=\"cite_ref_3\" href=\"#cite_note_3\">[3]<\/a>.<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-4.jpg\"><img class=\"alignnone size-large wp-image-8053\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-4-725x1024.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-4-725x1024.jpg 725w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-4-212x300.jpg 212w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-4-768x1085.jpg 768w\" sizes=\"(max-width: 725px) 100vw, 725px\" \/><\/a><\/p>\n<p><strong>Figure 4. Microhouse type. [Click image for larger view.]<\/strong><\/p>\n<p>(source: <a href=\"https:\/\/github.com\/wikihouseproject\/Microhouse\/blob\/master\/microhouse_0.5_isoFull.jpg\">https:\/\/github.com\/wikihouseproject\/Microhouse\/blob\/master\/microhouse_0.5_isoFull.jpg<\/a>, <a href=\"https:\/\/github.com\/wikihouseproject\/Microhouse\/blob\/master\/microhouse_0.5_iso.jpg\">https:\/\/github.com\/wikihouseproject\/Microhouse\/blob\/master\/microhouse_0.5_iso.jpg<\/a>, last visit: 01\/07\/2018)<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-5.jpg\"><img loading=\"lazy\" class=\"alignnone size-large wp-image-8054\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-5-1024x742.jpg\" alt=\"\" width=\"598\" height=\"433\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-5-1024x742.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-5-300x217.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-5-768x557.jpg 768w\" sizes=\"(max-width: 598px) 100vw, 598px\" \/><\/a><\/p>\n<p><strong>Figure 5. WREN technology. [Click image for larger view.]<\/strong> (source: <a href=\"https:\/\/github.com\/wikihouseproject\/Wren\/raw\/master\/Images\/Connectors-01.png\">https:\/\/github.com\/wikihouseproject\/Wren\/raw\/master\/Images\/Connectors-01.png<\/a>, last visit: 01\/07\/2018)<\/p>\n<p>The<em> Microhouse<\/em> <em>type<\/em> is evaluated as the most advanced project in the openness scale (Table 3). According to open-o-meter <em>microhouse<\/em> scores 7\/8 points, the only drawback being the lack of assembly instructions in editable format which seems a minor deficiency comparing to the other criteria. In other words, if open-o-meter was a thorough and reliable method for the assessment of openness, then Wikihouse should be an almost perfectly open instance in-line with the principles of OSS development. Contrary to the expectations, <em>microhouse<\/em> development has considerable structural differences from the well-known OSS examples. Despite the fulfilment of participation guidelines criterion, the development of <em>microhouse type<\/em> remains largely at the control of a closed team mostly coinciding with Wikihouse founders. The <em>microhouse<\/em> repository at github<a id=\"cite_ref_4\" href=\"#cite_note_4\">[4]<\/a> has 42 commits from only 3 unique contributors. The initial commit was made on the 25<sup>th<\/sup> of August 2016 and thereafter most of the commits refer to supplementary documentation rather than design files. In other words, the &#8216;source code&#8217; was uploaded to repository when the project was mature and most of the core files were already prepared by the founders. Since then, only minor edits have occurred. The above-mentioned characteristics are very common to the early stages of OSS development, before migrating to an open distributed and global mode of production. On the other hand, Wikihouse is a seven years old effort that could not be considered as an immature initiative. Consequently, a published contribution guide along with editable CAD files, BOM and assembly manual may not be enough to promote <em>accessibility<\/em> and the freedom to collaboratively <em>modify<\/em> an existing design.<\/p>\n<p>The role of modularity in &#8216;<em>voluntary large scale parallel processing<\/em>&#8216; (Weber, 2004: 88) of a project is already described in the literature review as one dimension of its influence among others (Baldwin and Clark, 2002). If CAD files with the supporting documentation constitute the &#8216;source code&#8217; of OSH, then the knowledge contained in CAD files should be organized and built in a modularized way. GNU\/Linux, Wikipedia and other known Commons could not have been developed to that magnitude, if they were not synthesized as an assemblage (DeLanda, 2006) of interconnected and semi-independent modules. On the contrary, CAD platforms are shaped to fit a much different mode of production, ranging from the sole designer to medium-sized dispersed but closed interdisciplinary teams. The first mode usually corresponds to an unstructured aggregation of 2-dimensional geometric data, while the second to a hierarchical relational model made out of preset 3-dimensional entities, which is known as <em>Building Information Modelling<\/em>. Whilst the uploaded design files of <em>microhouse<\/em> belong to the former data organizational structure, both are incompatible with an open source modular mode of development.<\/p>\n<p>Beyond the collaborative role of modularity, another dimension is its tolerance of uncertainty. The case of Wikihouse, more than the other cases, highlights the need for adjustable design according to local or individual needs, faced in a globalized DGML methodology. It is oversimplistic to consider as realistic case the widespread application of OSH standard housing <em>types<\/em> all over the world, regardless how the number of <em>types<\/em>. Consequently, it is required to incorporate differentiation parameters in <em>type<\/em> design that will make easier the engagement of the community and the application of each <em>type<\/em> to different site, climate and materials among others. At this framework, it seems less arduous to design parametric housing <em>types<\/em>, than creating a new solid <em>type<\/em> for almost each one local instance. In the former case is required to design the change instead of the final object\u2019s properties. The global gestion leads on to a relational or procedural object definition rather than a categorical finished and unique artifact. It could not be overlooked that Wikipedia entries as well as OSS modules are defined in relation to other entries or modules resembling a distributed flexible network organization. Moreover, the design and execution of any OSS is procedural in its essence or in other words algorithmic. To summarize <em>microhouse<\/em> despite the nearly full rating in the openness scale, it is qualitatively less collaborative and customizable than expected in the placed framework, which can be attributed to the absence of design modularity.<\/p>\n<p><em>WREN<\/em> and <em>OWL<\/em> <em>technologies<\/em> score 6\/8 (Table 3), as besides non-editable assembly instructions they lack license allowing commercial usage. Despite fundamentally disagreeing with rating commercial usability as an openness parameter, it is noted that<em> microhouse<\/em> is released under CC BY-SA 3.0 while <em>WREN<\/em> system under the copyleft MPL 2.0. But, <em>WREN<\/em> and <em>microhouse<\/em> share a more fundamental difference. <em>WREN <\/em>system is not designed in conventional CAD platforms, but it is created in a visual programming environment (Figure 6) which functions as an extension of a proprietary design platform. Visual programming as well as classic programming (scripting) is in-line with a relational or procedural definition of the design, being potentially more modular than conventional CAD if used as core of the design methodology. Consequently, CAD files are not necessarily the only design files, which was an axiomatic admission for open-o-meter evaluation framework.<\/p>\n<p>Furthermore, it is interesting that both <em>type<\/em> and <em>technologies<\/em> have been accomplished and released under a proprietary and commercial design platform. It is generally accepted that OSS design platforms are not so common, and they have not approached yet the functionality of commercial platforms, possibly with the exception of Blender (Velkova, 2016) which is addressed more to visualization rather than design industry. Nonetheless, this is a highly restrictive fact regarding contribution potential, as it automatically excludes a great amount of the community. While design platform\u2019s openness is not part of open-o-meter evaluation, it certainly and severely affects the ability of a project to be characterized as open. To reformulate open-o-meter criteria regarding CAD files, they need not only to be in native file format but in open file format as well.<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-6.jpg\"><img class=\"alignnone size-large wp-image-8055\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-6-1024x458.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-6-1024x458.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-6-300x134.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Figure-6-768x343.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/p>\n<p><strong>Figure 6. WREN system\u2019s source code in visual programming environment. [Click image for larger view.]<\/strong><\/p>\n<p>(source: <a href=\"https:\/\/github.com\/wikihouseproject\/Wren\/blob\/master\/WikiHouse_WREN_(v4.3).gh\">https:\/\/github.com\/wikihouseproject\/Wren\/blob\/master\/WikiHouse_WREN_(v4.3).gh<\/a>, last visit: 01\/07\/2018)<\/p>\n<h2>DISCUSSION<\/h2>\n<h3>OSH theory\u2019s breadth<\/h3>\n<p>Open-o-meter has a double function in the field of the OSH. On the one hand, it is a tool for the quantitative assessment of practices\u2019 openness. On the other hand, it serves as an OSH programmatic definition, a kind of guide for startup open initiatives. While more and more researchers highlight the potential of the Common &#8211; as extensively demarcated by Vercellone et al. (2015) &#8211; to become a dominant (Rifkin, 2014) socio-economic paradigm, at the same time Shirky (2005) recognizes that open source model can not migrate free ride to any other domain. Consequently, the systematization of OSH theoretical specifications is crucial for the successful diffusion of open source principles in the material world.<\/p>\n<p>The openness\u2019 analysis of the three case studies highlights major and minor limitations of the OSH theoretical framework as specified by open-o-meter. Minor limitations include over-simplification in the description of some of the evaluation criteria. Minor limitations can be painlessly overcomed by further in-depth specification and development of the already set criteria, without altering the quantitative nature of the open-o-meter. Major limitations come out from feed back loops between OSH and its constituent origins, revealing the absence or misconception of structural properties that characterize the open source model. The realization of the major limitations opens up a broader and more structural discussion regarding the social dimension, the transferability and the essence of OD as the hardware\u2019s &#8216;source code&#8217;. Minor limitations are defined below and adressed in the next sub-section. The last sub-section discusses the major limitations of current theoretical framework and highlights an emerging OD direction based on the examined case studies and their context.<\/p>\n<p>In general, among the examined case studies Opendesk and Wikihouse present the greater divergence between the quantitative assessment of openness and the respective qualitative evaluation of the freedoms to <em>study<\/em>, <em>make<\/em>, <em>modify <\/em>and<em> distribute<\/em>. It is noteworthy that Opendesk is rated 4.5\/8 in the openness scale whilst the only actually provided freedom is to <em>make<\/em> identical copies of the shared design, practically without being able neither to <em>study<\/em> nor to <em>modify<\/em> the design before. On the contrary, Wikihouse is an almost perfectly (7\/8) open example according to open-o-meter. Theoretically all of the described freedoms (<em>study<\/em>, <em>make<\/em>, <em>modify<\/em>, <em>distribute<\/em>) are unobstructed. But the closer look to collaboration platform\u2019s statistics revealed in practice poor collaborative development and limited number of contributors despite the project\u2019s maturity. In other words, the most successfully open case study is characterized more by a conventional design workflow and organization, rather than by a really open source mode of distributed development. To summarize, open-o-meter is proved to be a tool of limited applicability in the field of neither electronic nor mechanical hardware. In the direction of optimizing open-o-meter efficiency, some criteria, that profoundly need further specification, are the following:<\/p>\n<ol>\n<li>The criteria concerning the availability and editability of CAD files are over-simplistic and incomprehensive. As a consequence, a strong tendency to produce positively biased results is observed in the examined subset. While the quality of the documentation is not easily quantifiable, the research showcased steps that can easily specify further these criteria.<\/li>\n<li>The criterion of participation guidelines is a generic reference to open contribution not corresponding effectively to the wealth of the open source participatory development practices. In most practices open contribution rating is positively biased.<\/li>\n<li>The criterion concerning OSH license\u2019s provision of commercial usability counteracts system\u2019s openness. The described interrelation is explicated early in the literature review and highlighted further in the case of Opendesk where the for-profit organization is branded as open but at the same time directly and indirectly obstructs open source bottom-up processes.<\/li>\n<li>Apart from examining the openness criteria individually, it is equally or more important to explore their possible correlation. In terms of openness in the discussed framework, an important observation is that the freedom to <em>make<\/em> is thoroughly utilized when the user is first of all able to <em>study<\/em> and <em>modify<\/em> the design. Accordingly, the freedom to <em>study<\/em> is more thoroughly exercised when the user is able to <em>modify<\/em> the design or the piece of code. In other words, all of the four freedoms (<em>study<\/em>, <em>make<\/em>, <em>modify<\/em>, <em>distribute<\/em>) cumulatively account for more than the sum of each one freedom separately. Therefore the OSH freedoms interact in a synergetic way that is not reflected in open-o-meter methodology.<\/li>\n<\/ol>\n<h3>OSH theory\u2019s depth<\/h3>\n<p>The above-mentioned minor limitations of open-o-meter criteria regarding the examined subset can be addressed as follows:<\/p>\n<p>a) CAD files available \/ editable.<\/p>\n<p>The <em>WREN<\/em> case study reveals that CAD is not the only language of hardware\u2019s &#8216;source code&#8217;. Hardware design apart from conventional digital drafting can also be parametric or computational design as expressed by visual programming and programming. The second point is that &#8216;source code&#8217;, whether CAD or any other form, can be categorized further according to its content. All of the three case studies feature a clearly recognized division in design and fabrication files either are provided both, the one or the other. Fabrication files, which are derived from design files in a non-deterministic way, contain the information input required by either additive (3d printer) or substractive (CNC, laser cutter) digital fabrication media to manufacture hardware parts. But why are fabrication files so important as to be considered part of hardware\u2019s &#8216;source code&#8217;?<\/p>\n<p>Undoubtedly, the hardware made completely out of standardized and off the shelf elements that are centrally and massively produced, does not need any fabrication files. On the contrary, the decision to analyze this specific OSH subset in the light of free innovation (Von Hippel, 2017) and digital fabrication revolution, is central to our research strategy. In this way, as the actual matter of research is the hardware, it seems self-evident that &#8216;source code&#8217; should refer to all the way up to the product\u2019s materialization. Fabrication files beyond being a substantial part of the freedom to <em>make<\/em>, they are important for one more reason. Fabrication files are directly related with parameters such as cost and environmental footprint among others that are extremely significant in a broader conception of OSH production. Consequently, given an evolving design practice, the fabrication file is the instant output of a knowledge intensive process which is object of continuous optimization from the community and certainly part of the product development.<\/p>\n<p>Design and fabrication files as well as the intermediary process point to another associated limitation. How can we evaluate the openness of hardware based on shared CAD files or other type of design data without taking into account the openness of the design platform? An open design for <em>studying<\/em>, <em>making<\/em> and <em>modifying<\/em> that was shared in a native but proprietary format is a dead-end in itself. Design platform, whether the design is processed in conventional CAD, visual programming or classic programming, has to be open and developed as well as maintained in the Commons framework. The issue of proprietary platforms at the framework of netarchical capitalism was extensively described by Kostakis and Bauwens (2014b). We acknowledge the fact that currently open design platforms &#8211; especially beyond the conventional CAD &#8211; are scarce. This is partially attributed to the premature phase of the OSH in general, as well as to the nature and history of the &#8211; architectural &#8211; design itself regarding the intellectual property of the unique &#8216;handcrafted&#8217; design. In any case, it is relatively arguable to believe that OD platforms scarcity is subject to change in the near future. To conclude, CAD files criteria can be replaced by the following:<\/p>\n<p>a.1) Design files available \/ editable.<\/p>\n<p>a.2) Fabrication files available \/ editable.<\/p>\n<p>a.3) Intermediary process from design to fabrication files available \/ editable.<\/p>\n<p>a.4) Design platform &#8211; file format (FOSS compliant).<\/p>\n<p>b) Guidelines for participation.<\/p>\n<p>An open-o-meter\u2019s deficiency &#8211; that in different forms is discerned to most of the case studies \u2013 is that editable documents and a call for participation are not enough prerequisites to address the freedom to <em>modify<\/em> in its original full meaning. As the freedom to <em>modify<\/em> passed successively from OSS to OSH definitions, is gradually lost its collective dimension. Originally, the freedom to <em>modify<\/em> was addressing both the freedom to fork and modify a source code repository, as well as the freedom to merge modified code back to the master branch at your disposal. Instead of this rationale, the complete fulfilment of open-o-meter criteria can lead to an individual modus operandi that is so far from the collaborative intelligence of open source initiatives. An extreme example is Openstructures which is an aggregation of individually produced designs.<\/p>\n<p>Even if participation guidelines or license allows directly or not all of the above mentioned freedoms to <em>modify<\/em>, none of them will ever occur without at least the required technical infrastructure. The respective infrastructure of OSS communities is an open and web-based collaboration platform that also serves for communication between contributors, version control, sharing and storing the source code. Similarly to the design platform, the open source character of the collaboration infrastructure is supporting the community and product\u2019s openness comparing to a proprietary platform. Additionally, the collaboration platform is a crucial point for supporting asynchronous collaboration which is so common to communities growing beyond spatial limitations.<\/p>\n<p>Furthermore, the participation guidelines requirement does not define explicitly the aspect of unconditional participation which is fundamental characteristic of CBPP as demonstrated from OSS to Wikipedia paradigms. For instance, the Opendesk \u2013 which lost the point for participation guidelines \u2013 had issued a call for contributors in the past that is currently inactive. As the call was addressed to designers who were subject to further formal evaluation, it was a certainly closed procedure that formally would have passed open-o-meter generic evaluation. At this point, it is important to return to the OD dimensions and particularly participatory design to remind that contribution guide must be unconditional not only for the experts but for the users too.<\/p>\n<p>To conclude it is suggested to replace the participation guidelines criterion with the more specific following:<\/p>\n<p>b.1) Potential to fork repository.<\/p>\n<p>b.2) Potential to merge back into repository.<\/p>\n<p>b.3) Unconditional participation.<\/p>\n<p>b.4) Collaboration platform (FOSS compliant).<\/p>\n<p>c) Commercial usage allowed.<\/p>\n<p>The case study analysis highlighted that OSH projects governed by for-profit organizations are characterized less open comparing to the non-profit communitites. Despite that case study research is not offered for inductive reasoning, this correlation can be further supported by the numerous OSS paradigms. The most interesting part is that the for-profit organizations employ a variety of direct and indirect techniques beyond licensing to limit bottom-up open practices. As the indirect techniques have been covered by further specification of openness criteria, what remains is a licensing strategy to replace the limitations and vagueness created by the commercial usability criterion. According to Vercellone et al. (2015) the mechanism of enclosure is what structurally differentiates cognitive capitalism from knowledge-intensive communities. On the other hand, it will be a paper by itself to analyze in-depth the different degrees and ways (from scratch, over derivative works, by selling exceptions or by parallel free distributon) that commercial usability as a mechanism of enclosure is incorporated to free and open source licenses. It is neither our scope nor it is feasible to initiate herein one more OSH license to face the raised issues. On the contrary, guided by the general concept of &#8216;<em>inappropriability<\/em>&#8216; (Vercellone et al., 2015: 62, 78), it could be simply supported that copyleft-minded licensing will certainly have a positive impact on hardware\u2019s openness. As the freedom to <em>run<\/em> mostly coincides with the freedom of <em>making <\/em>(executing the fabrication files)<em>,<\/em> and the hardware\u2019s source code is actually immaterial, there are not so many differences to consider from OSS\u2019s to OSH\u2019s licensing.<\/p>\n<p>d) Synergy \u2013 OSH freedoms\u2019 correlation<\/p>\n<p>On the one hand, it is exposed by the examined case studies in the described context that the OSH freedoms (<em>study<\/em>, <em>make<\/em>, <em>modify<\/em>, <em>distribute<\/em>) are correlated to some extent but this is not easily and mathematically quantifiable. How can we quantify the contribution of the freedom to <em>modify<\/em> in the potential to <em>make<\/em> customized products comparing to standardized ones? On the other hand, it seems that the current open-o-meter scheme in which each OSH freedom corresponds to a completely different set of criteria is inaccurate. It is feasible from the case study research to define those criteria that contribute to more than one freedom. In this way, an indirect synergistic effect between the four freedoms will be approximately defined.<\/p>\n<p>Specifically, the freedom to <em>study<\/em> is accomplished more efficiently when the &#8216;source code&#8217; is shared in editable format. While this argument actually depends on the nature of the &#8216;source code&#8217;, it is generally arguable that trial and error is one of the basic methods for knowledge acquisition and in that way editable files add to the freedom of <em>studying<\/em>. The object of <em>study<\/em> exceeds the mere design files by including the fabrication ones as well as the intermediary process. Regarding the freedom to <em>make<\/em>, assembly instructions and BOM are insufficient means for making a custom object out of non-standardized parts. The availability of fabrication files is a minimum prerequisite of the <em>making<\/em> process. Additionally, the editable &#8216;source code&#8217; contributes even further to the freedom of <em>making<\/em> by freeing the customization of shared design according to local needs.<\/p>\n<p>The following table synopsizes the described interrelations among the specified criteria:<\/p>\n<p><a href=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-4.jpg\"><img class=\"alignnone size-large wp-image-8048\" src=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-4-1024x605.jpg\" alt=\"\" width=\"100%\" srcset=\"http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-4-1024x605.jpg 1024w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-4-300x177.jpg 300w, http:\/\/peerproduction.net\/editsuite\/wp-content\/uploads\/2019\/03\/Table-4-768x454.jpg 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/p>\n<p><strong>Table 4. The matrix of open-o-meter (abbreviations: Free and Open Source Software [FOSS]). [Click image for larger view.]<\/strong><\/p>\n<p>The criterion of design modularity is part of the next sub-section\u2019s discussion.<\/p>\n<h3>An emerging OD direction<\/h3>\n<p>As described in the literature review, modularity is a structural parameter of the open source mode of development and it is inextricably linked with the freedom to <em>study<\/em>, <em>modify<\/em> and <em>make<\/em>. Furthermore, modularity is what structurally differentiates open source code from proprietary code, Wikipedia from a conventional encyclopedia and so forth. As modularity is absent from OSH evaluation framework, it may be useful to analyze types of modularity that are observed in practice in order to theorize about them in a positive feedback loop. Generally, modularity can refer to different factors of OSH production such as: the community, the design, the physical product or even the procedure going from design to fabrication files. The types of modularity that have been observed in practice are the following:<\/p>\n<ul>\n<li>Openstructures features a geometric type of modularized design. Lower class objects (<em>parts<\/em>) and interfaces are designed, based on a fixed geometrical grid. Secondly, Openstructures features a type of hierarchical product segmentation as <em>components<\/em> are composed of <em>parts<\/em>, and successively <em>structures<\/em> are composed of <em>components<\/em>.<\/li>\n<li>Wikihouse potentially can be characterized by a non-hierarchical type of product modularity as <em>type<\/em> (house shell) can host other <em>technologies<\/em> (components) while not composed out of them. Potentiality is substantiated as currently the only provided component to be hosted is the <em>OWL<\/em> door-kit. However, the most promising part of Wikihouse, in terms of modularity, is the <em>WREN<\/em> system which is the intermediary process between design and fabrication files. <em>WREN<\/em> by its internal relational and procedural structure exemplifies the modularity in the closest form to the open source code modularity.<\/li>\n<\/ul>\n<p>First of all, the fundamental principle of all modular systems is the standardization of the interface between modules. This is the basic difference between the lego-like natively modular design (Kostakis and Papachristou, 2014a) and Openstructures\u2019 modularized design. The freedom to design countless types of joints eliminates progressively the flexibility and reusability of the modules, leading to the solidification of hardware and design. Respectively, hierarchical product segmentation is incompatible within the open source mode of development and reveals a top-down rationale. The emergence of bottom-up assemblies between modules is more consistent with a truly open source community and design.<\/p>\n<p>Furthermore, design modularity is not directly translated to product modularity. In other words design modules are not necessarily physical modules but modules of design knowledge. This fact is clearly demonstrated by <em>WREN<\/em>\u2019s visual programming approach. Visual programming is positioned in the intersection of design and programming. Visual programming by its intrinsic algorithmic nature is more receptible to modularization. Traditional CAD, in contrast, is to great extent a monolithic sum of geometric and positional data that do not reveal the knowledge or the design process behind them. From the inception of CAD systems, researchers (Hanna et al., 1995) have attempted to propose more modular data structures that will be more susceptible to change and design re-usability. According to Terzidis (2006), CAD systems are a computerized version of the traditional hand drafting methodology, while the real potential in the utilization of computers in the design workflow lies in the computational design. Aish and Bredella (2017: 65) formulate the argument more explicitly: <em>&#8216;the increased use of parametric methods and scripting allow for the development of modelling and fabrication techniques, which in turn challenge the role of drawing as one of the main tools for conceptualising and realising architecture&#8217;<\/em>. Consequently, in the modularity framework, is it possible to articulate an OSH methodology out of conventional CAD drawings? In a similar comparison between the failure of collaborative writing of textbooks and the success of the collaborative writing of Wikipedia, Shirky (2005: 488) notes:<\/p>\n<blockquote><p>&#8216;<em>Instead of assuming that Open Source methods are broadly applicable to the rest of the world, we can instead assume that that they are narrowly applicable, but so valuable that it is worth transforming other kinds of work, in order to take advantage of the tools and techniques pioneered here.<\/em>&#8216;<\/p><\/blockquote>\n<p>During the last decade many architectural schools have integrated code learning to their curriculum\u00a0(Papalexopoulos, 2011),\u00a0going from a computerized analog drafting method to a computational workflow. Additionally, many individually produced design code snippets have been uploaded to proprietary platforms\u2019 repositories<a id=\"cite_ref_5\" href=\"#cite_note_5\">[5]<\/a> due to the aforementioned lack of OD platforms. Even the little known controversy at 2011 (Davis, 2011; Piker, 2011) between the\u00a0creator of\u00a0the freely distributed plugin named <em>Kangaroo<\/em> and the geometry rationalization company <em>Evolute GmbH<\/em>, is apocalyptic of the shift of interest from the drawing to the code<a id=\"cite_ref_6\" href=\"#cite_note_6\">[6]<\/a>. In this sense, <em>WREN<\/em> system may exemplify the future direction of OD in the OSH framework. Actually, <em>WREN<\/em> system concentrates the properties of what Papalexopoulos (2011) characterizes as Digital Design Commons:<\/p>\n<blockquote><p>&#8216;<em>Digital Design Commons are pools of a multitude of micro- architecture problem solutions, a multitude of micro &#8211; syntaxes covering partial aspects of design, waiting to be actualized in larger design schemes. <\/em><\/p>\n<p><em>They also deny the unique and ultimate &#8216;form&#8217; in favor of a network\u2019s syntax. They tend to substitute the object\u2019s design with the design of networked multiplicities. Finally, they question the ubiquity of design as an end of work process, linking it to the (local) use value production.<\/em>&#8216;<\/p><\/blockquote>\n<h2>CONCLUSION<\/h2>\n<p>The aforementioned analysis shows that the OSH theoretical framework as specified by open-o-meter is not generally applicable to the whole range of OSH. In the examined subset of OSH, open-o-meter lacks specificity, which is easily revealed under the light of case study research but covered by large scale statistical analyses that have been performed before this paper. The over-simplification leads to positively biased results at the examined sample but the direction of the deviation can not be safely generalized for the full range of hardware. Intrinsic contradictions of open-o-meter are dependent on the political investment of open source movement: constituent of knowledge-based economy or cognitive capitalism. The author stands for the first position which is deeply rooted to the intrinsic properties of the open source code.<\/p>\n<p>The matrix of open-o-meter is a suggestion to fine-tune the open-o-meter based on qualitative evidence without altering its quantitative and generic nature. However, the applicability of the matrix to the whole range of hardware is subject to future research. Furthermore, the research highlighted the hidden structural dimension of modularity in the OSH development and described an emergent type of design modularity beyond the much discussed geometric modularization. Also further investigation is required to establish an evaluation framework of modularity among different design media. This is a known limitation of the matrix of open-o-meter. Additionally, the proposed version of the matrix is delimited by the specific socio-technological research context of the digital fabrication and the digital Commons.<\/p>\n<p>While OSS had long been a practice without theory, this condition is inverted when open source principles are applied outside their original domain. In this way, the articulation of a consistent and comprehensive OSH theory is of crucial importance in further OSH diffusion.<\/p>\n<h2>REFERENCES<\/h2>\n<p>Ackermann, John (2009) Toward open source hardware, <em>University of Dayton Law Review<\/em>, 34 (2), pp. 183\u2013222.<\/p>\n<p>Aish, Robert and Nathalie Bredella (2017) The evolution of architectural computing: From building modelling to design computation, <em>Architectural Research Quarterly<\/em>, 21(1), pp. 65-73.<\/p>\n<p>Alexander, Christopher, Ishikawa, Sara, Silverstein, Murray, Jacobson, Max, Fiksdahl-King, Ingrid and Shlomo Angel (1977) <em>A Pattern Language: Towns, Buildings, Construction<\/em>. New York: Oxford University Press.<\/p>\n<p>Baldwin, Carliss Y. and Kim B. Clark (2002) The option value of modularity in design: An example from design rules, Volume 1: The power of modularity, <em>Harvard NOM Working Paper<\/em>, No. 02-13; Harvard Business School Working Paper, No. 02-078, &lt;<a href=\"https:\/\/papers.ssrn.com\/sol3\/papers.cfm?abstract_id=312404\">https:\/\/papers.ssrn.com\/sol3\/papers.cfm?abstract_id=312404<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Baldwin, Carliss Y. and Kim B. Clark (2006) The architecture of participation: Does code architecture mitigate free riding in the open source development model?, <em>Management Science<\/em>, 52, issue 7, pp. 1116-1127.<\/p>\n<p>Balka, Kerstin, Raasch, Christina and Cornelius Herstatt (2009a) Open source enters the world of atoms: A statistical analysis of open design, <em>First Monday<\/em>, 14(11), &lt;<a href=\"http:\/\/firstmonday.org\/ojs\/index.php\/fm\/article\/view\/2670\/2366\">http:\/\/firstmonday.org\/ojs\/index.php\/fm\/article\/view\/2670\/2366<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Balka, Kerstin, Raasch, Christina and Cornelius Herstatt (2009b) Open source beyond software: An empirical investigation of the open design phenomenon, R&amp;D Management Conference, &lt;<a href=\"http:\/\/citeseerx.ist.psu.edu\/viewdoc\/download?doi=10.1.1.595.3840&amp;rep=rep1&amp;type=pdf\">http:\/\/citeseerx.ist.psu.edu\/viewdoc\/download?doi=10.1.1.595.3840&amp;rep=rep1&amp;type=pdf<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Balka, Kerstin, Raasch, Christina and Cornelius Herstatt (2010) How open is open source? \u2013 Software and Beyond, <em>Creativity and Innovation Management<\/em>, 19\/3, pp. 248-256.<\/p>\n<p>Balka, Kerstin, Raasch, Christina and Cornelius Herstatt (2014) The effect of selective openness on value creation in user innovation communities, <em>Journal of Product Innovation Management<\/em>, 31, pp. 392-407.<\/p>\n<p>Benkler, Yochai (2002) Coase&#8217;s penguin, or, Linux and &#8216;The Nature of the Firm&#8217;, <em>The Yale Law Journal<\/em>, 112(3), pp. 369-446.<\/p>\n<p>Benkler, Yochai (2006) <em>The Wealth of Networks: How Social Production Transforms Markets and Freedom<\/em>. New Haven: Yale University Press.<\/p>\n<p>Bessen, James (2002) What good is free software in R. W. Hahn (ed.) <em>Government policy toward open source software<\/em>. Washington, DC: Brookings Institution Press, pp. 12-33.<\/p>\n<p>Bonvoisin, J\u00e9r\u00e9my, Mies, Robert, Boujut, Jean-Fran\u00e7ois and Rainer Stark (2017) What is the &#8216;source&#8217; of open source hardware?, <em>Journal of Open Hardware<\/em>, 1(1): 5, pp. 1\u201318.<\/p>\n<p>Carson, Kevin A. (2010) <em>The Homebrew Industrial Revolution: A Low-Overhead Manifesto<\/em>. Charleston, SC: BookSurge Publishing.<\/p>\n<p>Chesbrough, Henry W. and Melissa M. Appleyard (2007) Open innovation and strategy, <em>California Management Review<\/em>, 50(1), pp.57-76.<\/p>\n<p>Conway, E. Melvin (1968) How do committees invent?,<em>\u00a0Datamation<\/em>, 14(5), pp.28-31.<\/p>\n<p>Davis, Daniel (2011) Patenting Geometry, &lt;<a href=\"http:\/\/www.danieldavis.com\/patenting-geometry\/\">http:\/\/www.danieldavis.com\/patenting-geometry\/<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>De Mul, Jos (2011) Redesigning Design in Bas van Abel, Lucas Evers, Roel Klaassen and Peter Troxler (eds) <em>Open Design Now<\/em>. Amsterdam: BIS Publishers, pp. 34-41.<\/p>\n<p>DeLanda, Manuel (2006) <em>A New Philosophy of Society: Assemblage Theory and Social Complexity<\/em>. London: Continuum.<\/p>\n<p>Free Software Foundation (2016) Why &#8216;Free Software&#8217; is better than &#8216;Open Source&#8217;, &lt;<a href=\"https:\/\/www.gnu.org\/philosophy\/free-software-for-freedom.html\">https:\/\/www.gnu.org\/philosophy\/free-software-for-freedom.html<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Friedman, Yona (1975) <em>Toward a Scientific Architecture<\/em>. (transl. Lang Cynthia). Cambridge: MIT Press.<\/p>\n<p>Fuller, Matthew and Usman Haque (2008) Urban versioning system 1.0 in Khan, Omar, Sholz, Trebor and Mark Shepard (eds.) <em>Situated Technologies Pamphlet Series<\/em>. New York: Architectural League of New York.<\/p>\n<p>Gershenfeld, Neil (2007) <em>FAB: The Coming Revolution on Your Desktop: From Personal Computers to Personal Fabrication<\/em>. New York: Basic Books.<\/p>\n<p>Gershenfeld, Neil (2012) How to make almost anything: the digital fabrication revolution, <em>Foreign Affairs<\/em>, 91(6), pp. 42\u201357, &lt;<a href=\"http:\/\/cba.mit.edu\/docs\/papers\/12.09.FA.pdf\">http:\/\/cba.mit.edu\/docs\/papers\/12.09.FA.pdf<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Gershenfeld, Neil, Gershenfeld, Alan and Joel Cutcher-Gershenfeld (2017) <em>Designing Reality: How to Survive and Thrive in the Third Digital Revolution<\/em>. New York, NY: Basic Books.<\/p>\n<p>Gibb, Alicia (2014) <em>Building Open Source Hardware: DIY Manufacturing for Hackers and Makers<\/em>. Upper Saddle River, NJ: Addison-Wesley Professional.<\/p>\n<p>Habraken, John (1972) <em>Supports \u2013 An Alternative to Mass Housing<\/em>. London: The Architectural Press.<\/p>\n<p>Hanna, Paul J.R., Millar, Richard J. and John Hamilton Frazer (1995) A CAD data structure to facilitate change, <em>Computing Systems in Engineering<\/em>, 6(6), pp.511-519.<\/p>\n<p>Hermann, Mario, Pentek, Tobias and Boris Otto (2016) Design principles for industrie 4.0 scenarios, <em>49<sup>th<\/sup> <\/em><em>Hawaii International Conference on System Science<\/em>, IEEE Press, pp.3928-3937.<\/p>\n<p>Hiller, Jonathan and Hod Lipson (2009) Design and analysis of digital materials for physical 3D voxel printing,\u00a0<em>Rapid Prototyping Journal,<\/em>\u00a015\/2, pp.137-149.<\/p>\n<p>Kaspori, Dennis (2003) A Communism of ideas: Towards an open-source architectural practice, <em>Archis<\/em>, Issue 3, pp. 13-18.<\/p>\n<p>Kostakis, Vasilis, Fountouklis, Michail and Wolfgang Drechsler (2013) Peer production and desktop manufacturing: The case of the Helix_T wind turbine project, <em>Science, Technology, &amp; Human Values<\/em>, Vol 38, Issue 6, pp. 773 \u2013 800.<\/p>\n<p>Kostakis, Vasilis and Marios Papachristou (2014) Commons-based peer production and digital fabrication: The case of a RepRap-based, Lego-built 3D printing-milling machine, <em>Telematics and Informatics<\/em>, 31(3), pp. 434\u2013443.<\/p>\n<p>Kostakis, Vasilis and Michel Bauwens (2014) <em>Network Society and Future Scenarios for a Collaborative Economy<\/em>. London: Palgrave Macmillan.<\/p>\n<p>Kostakis, Vasilis, Niaros, Vasilis, Dafermos, George and Michel Bauwens (2015) Design global, manufacture local: Exploring the contours of an emerging productive model,\u00a0<em>Futures,<\/em>\u00a0Volume 73, pp.126-135<\/p>\n<p>Lakhani, Karim (2007) Communities driving manufacturers out of the design space, <em>The Future of Communities Blog<\/em>, &lt;<a href=\"https:\/\/web.archive.org\/web\/20080602024947\/http:\/www.futureofcommunities.com\/2007\/03\/25\/communities-driving-manufacturers-out-of-the-design-space\">https:\/\/web.archive.org\/web\/20080602024947\/http:\/\/www.futureofcommunities.com\/2007\/03\/25\/communities-driving-manufacturers-out-of-the-design-space<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Lerner, Josh and Jean Tirole (2005) The economics of technology sharing: Open source and beyond, <em>Journal of Economic Perspectives 19<\/em>, no. 2, pp.99\u2013120. (Earlier version distributed as NBER Working Paper Series No. w10956.)<\/p>\n<p>MacCormack, Alan, Rusnak, John and Carliss Baldwin (2006) Exploring the structure of complex software designs: An empirical study of open source and proprietary code,\u00a0<em>Management<\/em><em> Science,<\/em>\u00a0Volume 52, No. 7, pp.1015-1030.<\/p>\n<p>MacCormack, Alan, Baldwin, Carliss and John Rusnak (2012) Exploring the duality between product and organizational architectures: A test of the &#8216;mirroring&#8217; hypothesis,\u00a0<em>Research <\/em><em>Policy,<\/em>\u00a0Volume 41, pp.1309-1324.<\/p>\n<p>Manzini, Ezio (2015) <em>Design, When Everybody Designs: An Introduction to Design for Social Innovation<\/em>. Cambridge, MA: The MIT Press.<\/p>\n<p>Maurer, Stephen M. and Suzanne Scotchmer (2006) Open source software: The new intellectual property paradigm, <em>NBER Working Paper Series,<\/em> No. 12148, &lt;<a href=\"http:\/\/www.nber.org\/papers\/w12148\">http:\/\/www.nber.org\/papers\/w12148<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Niaros, Vasilis, Kostakis, Vasilis and Wolfgang Drechsler (2017) Making (in) the smart city: The emergence of makerspaces, <em>Telematics and Informatics<\/em>, Volume 34, Issue 7, pp. 1143-1152.<\/p>\n<p>Nuvolari, Allesandro and Francesco Rullani (2007) Curious exceptions? Open source software and &#8216;open&#8217; technology in Kirk St. Amant and Brian Still (eds.) <em>Handbook of Research on Open Source Software: Technological, Economic, and Social Perspectives.<\/em> Hershey, New York: Information Science Reference, pp. 227-239.<\/p>\n<p>Open Architecture License (2016) &lt;https:\/\/github.com\/dortheimer\/open-architecture&gt;, retrieved: 24 Oct 2018.<\/p>\n<p>Open Architecture Network, &lt;https:\/\/web.archive.org\/web\/20150315014820\/http:\/\/openarchitecturenetwork.org\/&gt; (archived version), retrieved: 24 Oct 2018.<\/p>\n<p>Open Source Hardware Association (2011) Open Source Hardware (OSHW) Statement of Principles 1.0., &lt;https:\/\/freedomdefined.org\/index.php?title=OSHW&amp;oldid=9134&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Open Source Initiative (2007) The Open Source Definition, &lt;https:\/\/opensource.org\/docs\/osd &gt;, retrieved: 10 Jun 2018.<\/p>\n<p>OPEN! (2018) Open-O-meter, &lt;<a href=\"https:\/\/opensourcedesign.cc\/wiki\/index.php\/Open-O-meter\">https:\/\/opensourcedesign.cc\/wiki\/index.php\/Open-O-meter<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Opendesk (2018) &lt;<a href=\"https:\/\/www.opendesk.cc\/\">https:\/\/www.opendesk.cc\/<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Openstructures (2018a) &lt;<a href=\"http:\/\/openstructures.net\/\">http:\/\/openstructures.net\/<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Openstructures (2018b) &lt;<a href=\"http:\/\/beta.openstructures.net\/pages\/2\">http:\/\/beta.openstructures.net\/pages\/2<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Osterloh, Margit and Sandra Rota (2007) Open source software development &#8211; Just another case of collective invention?, <em>Research Policy<\/em>, 36(2), pp. 157-171.<\/p>\n<p>Papalexopoulos, Dimitris (2011) Digital Design Commons, <em>Symposium: Computational Politics and Architecture: From the Digital Philosophy to the End of Work<\/em>, &lt;http:\/\/atru.arch.ntua.gr\/sites\/atru\/files\/posts\/50digital-design-commons\/papalexopoulosensapm2011.pdf&gt;, retrieved: 12 Nov 2017<\/p>\n<p>Perens, Bruce (1997) Debian&#8217;s &#8216;social contract&#8217; with the free software community, &lt;<a href=\"https:\/\/lists.debian.org\/debian-announce\/1997\/msg00017.html\">https:\/\/lists.debian.org\/debian-announce\/1997\/msg00017.html<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Piker, Daniel (2011) Patents, precedents and geometry, &lt;<a href=\"https:\/\/spacesymmetrystructure.wordpress.com\/2011\/09\/03\/patents-precedents-and-geometry\/\">https:\/\/spacesymmetrystructure.wordpress.com\/2011\/09\/03\/patents-precedents-and-geometry\/<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Raasch, Christina, Herstatt, Cornelius and Kerstin Balka (2009) On the open design of tangible goods, <em>R&amp;D Management<\/em>, 39, pp. 382-393.<\/p>\n<p>Ratti, Carlo and Matthew Claudel (2015) <em>Open Source Architecture<\/em>. London: Thames &amp; Hudson.<\/p>\n<p>Raymond, Eric S. (1999a) Afterword: Beyond Software?, &lt;<a href=\"http:\/\/www.catb.org\/esr\/writings\/homesteading\/afterword\/\">http:\/\/www.catb.org\/esr\/writings\/homesteading\/afterword\/<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Raymond, Eric S.\u00a0(1999b) The cathedral and the bazaar, &lt;<a href=\"http:\/\/www.catb.org\/~esr\/writings\/cathedral-bazaar\/\">http:\/\/www.catb.org\/~esr\/writings\/cathedral-bazaar\/<\/a>&gt;, retrieved: 12 Nov 2017<\/p>\n<p>Rifkin, Jeremy (2014) <em>The Zero Marginal Cost Society: The internet of things, the collaborative commons, and the eclipse of capitalism<\/em>. New York: Palgrave Macmillan.<\/p>\n<p>Salingaros, Nikos A., Caperna, Antonio, Bauwens, Michel, Brain, David, Duany, Andr\u00e9s M., Mehaffy, Michael W., Mehta, Geeta, Mena-Quintero, Federico, Philibert-Petit, Ernesto, Rizzo, Agatino, Serafini, Stefano and Emanuele Strano (2010) <em>P2P Urbanism<\/em>. &lt;<a href=\"http:\/\/zeta.math.utsa.edu\/~yxk833\/P2PURBANISM.pdf\">http:\/\/zeta.math.utsa.edu\/~yxk833\/P2PURBANISM.pdf<\/a>&gt;, retrieved: 23 Oct 2018.<\/p>\n<p>Shirky, Clay (2005) Epilogue: Open source outside the domain of software in Joseph Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R. Lakhani, <em>Perspectives on Free and Open Source Software<\/em>. Cambridge, MA: The MIT Press.<\/p>\n<p>Shirky, Clay (2008) <em>Here Comes Everybody: The Power of Organizing without Organizations<\/em>. New York: Penguin Press.<\/p>\n<p>Stake, Robert (1995) <em>The Art of Case Study Research<\/em>. Thousand Oaks, CA: Sage.<\/p>\n<p>Stake, Robert (2003) Case studies in Denzin, Norman K. and Yvonna S. Lincoln (eds.) <em>Strategies of Qualitative Inquiry<\/em>. Thousand Oaks, CA: Sage, pp. 134-164.<\/p>\n<p>Stallman, Richard (1986) What is the Free Software Foundation, <em>GNU\u2019s Bulletin<\/em>, 1 (1), pp. 8-9, &lt;<a href=\"https:\/\/www.gnu.org\/bulletins\/bull1.txt\">https:\/\/www.gnu.org\/bulletins\/bull1.txt<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Stallman, Richard (1999) On &#8216;Free Hardware&#8217;, &lt;<a href=\"https:\/\/www.linuxtoday.com\/infrastructure\/1999062200505NWLF\">https:\/\/www.linuxtoday.com\/infrastructure\/1999062200505NWLF<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Stallman, Richard (2015) Why we need Free Digital Hardware Designs, <em>Wired Magazine<\/em>, &lt;<a href=\"https:\/\/www.wired.com\/2015\/03\/need-free-digital-hardware-designs\/\">https:\/\/www.wired.com\/2015\/03\/need-free-digital-hardware-designs\/<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Stallman, Richard (2016) Why Open Source misses the point of Free Software, &lt;<a href=\"https:\/\/www.gnu.org\/philosophy\/open-source-misses-the-point.html\">https:\/\/www.gnu.org\/philosophy\/open-source-misses-the-point.html<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>TAPR (2007) The TAPR Open Hardware License, &lt;<a href=\"https:\/\/www.tapr.org\/TAPR_Open_Hardware_License_v1.0.pdf\">https:\/\/www.tapr.org\/TAPR_Open_Hardware_License_v1.0.pdf<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Terzidis, Kostas (2006) <em>Algorithmic Architecture<\/em>. Oxford: Elsevier Architectural Press.<\/p>\n<p>Thompson, Clive (2008) Build it. Share it. Profit. Can Open Source Hardware work?, <em>Wired Magazine, &lt;<\/em> <a href=\"https:\/\/www.wired.com\/2008\/10\/ff-openmanufacturing\/\">https:\/\/www.wired.com\/2008\/10\/ff-openmanufacturing\/<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Vallance, Ryan, Kiani, Sepehr and Samir Nayfeh (2001) Open design of manufacturing equipment,\u00a0<em>Proceedings of the CHIRP 1st International Conference on Agile, Reconfigurable Manufacturing<\/em>, &lt;<a href=\"http:\/\/citeseerx.ist.psu.edu\/viewdoc\/download?doi=10.1.1.557.1285&amp;rep=rep1&amp;type=pdf\">http:\/\/citeseerx.ist.psu.edu\/viewdoc\/download?doi=10.1.1.557.1285&amp;rep=rep1&amp;type=pdf<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Vardouli, Theodora and Leah Buechley (2014) Open Source Architecture: An exploration of Source Code and Access in Architectural Design, <em>Leonardo \/ ISAST<\/em>, 47 (1), pp. 51\u201355.<\/p>\n<p>Velkova, Julia (2016) Open cultural production and the online gift economy: The case of Blender,\u00a0<em>First Monday<\/em>, 21 (10), &lt;<a href=\"http:\/\/firstmonday.org\/ojs\/index.php\/fm\/article\/view\/6944\">http:\/\/firstmonday.org\/ojs\/index.php\/fm\/article\/view\/6944<\/a>&gt;, retrieved: 10 Jun 2018.<\/p>\n<p>Vercellone, Carlo, Bria, Francesca, Fumagalli, Andrea, Gentilucci, Eleonora, Giuliani, Alfonso, Griziotti, Giorgio and Pierluigi Vattimo (2015) Managing the commons in the knowledge economy, &lt;<a href=\"https:\/\/dcentproject.eu\/wp-content\/uploads\/2015\/07\/D3.2-complete-ENG-v2.pdf\">https:\/\/dcentproject.eu\/wp-content\/uploads\/2015\/07\/D3.2-complete-ENG-v2.pdf<\/a>&gt;, retrieved: 25 Dec 2018.<\/p>\n<p>Von Hippel, Eric (2005) <em>Democratizing Innovation<\/em>. Cambridge, MA: The MIT Press.<\/p>\n<p>Von Hippel, Eric (2017) <em>Free Innovation<\/em>. Cambridge, MA: The MIT Press.<\/p>\n<p>Von Hippel, Eric and Georg von Krogh (2003) Open source software and the &#8216;private-collective&#8217; innovation model: Issues for organization science, <em>Organization Science 14<\/em>, 2, pp. 209-223.<\/p>\n<p>Von Krogh, Georg and Eric Von Hippel (2006) The promise of research on open source software, <em>Management Science<\/em>, 52(7), pp. 975-983.<\/p>\n<p>Weber, Steven (2004) <em>The Success of Open Source<\/em>. Cambridge, MA: Harvard University Press.<\/p>\n<p>Wikihouse (2018a) &lt;<a href=\"https:\/\/wikihouse.cc\/\">https:\/\/wikihouse.cc\/<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Wikihouse (2018b) &lt;<a href=\"https:\/\/wikihouse.cc\/about\">https:\/\/wikihouse.cc\/about<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<p>Wikipedia (2018a) List of open-source hardware projects, &lt;<a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_open-source_hardware_projects\">https:\/\/en.wikipedia.org\/wiki\/List_of_open-source_hardware_projects<\/a>&gt;, retrieved: 17 Jun 2018.<\/p>\n<p>Wikipedia (2018b) Wikihouse, &lt;<a href=\"https:\/\/en.wikipedia.org\/wiki\/WikiHouse\">https:\/\/en.wikipedia.org\/wiki\/WikiHouse<\/a>&gt;, retrieved: 01 Jul 2018.<\/p>\n<h2>ENDNOTES<\/h2>\n<p><a id=\"cite_note_1\" href=\"#cite_ref_1\">[1]\u00a0<\/a>The author consulted the Wikipedia list of OSH projects on the 17<sup>th<\/sup> of June 2018.<\/p>\n<p><a id=\"cite_note_2\" href=\"#cite_ref_2\">[2]<\/a>\u00a0<a href=\"https:\/\/xtools.wmflabs.org\/articleinfo\/en.wikipedia.org\/List_of_open-source_hardware_projects\">https:\/\/xtools.wmflabs.org\/articleinfo\/en.wikipedia.org\/List_of_open-source_hardware_projects<\/a>\u00a0 The &#8216;List of open-source hardware projects&#8217; is a dynamic entry first edited in 2010, featuring 683 edits by 328 editors at the time of writing, most of them characterized as major edits. Last visit: 17\/07\/2018<\/p>\n<p><a id=\"cite_note_3\" href=\"#cite_ref_3\">[3]\u00a0<\/a><a href=\"https:\/\/github.com\/wikihouseproject\/\">https:\/\/github.com\/wikihouseproject\/<\/a>, last visit: 01\/07\/2018<\/p>\n<p><a id=\"cite_note_4\" href=\"#cite_ref_4\">[4]\u00a0<\/a><a href=\"https:\/\/github.com\/wikihouseproject\/Microhouse\/\">https:\/\/github.com\/wikihouseproject\/Microhouse\/<\/a>, last visit: 01\/07\/2018<\/p>\n<p><a id=\"cite_note_5\" href=\"#cite_ref_5\">[5]\u00a0<\/a><a href=\"https:\/\/www.food4rhino.com\/\">https:\/\/www.food4rhino.com\/<\/a>, last visit: 01\/07\/2018.<\/p>\n<p><a id=\"cite_note_6\" href=\"#cite_ref_6\">[6]\u00a0<\/a>It is worth noting that when this paper was under review, Opendesk launched customization services of existing designs based on algorithmic processes and parametric design. This is one more fact that augments the belief that a tranformative transition from drawing to code is taking place. The customization services were not openly available which is consistent with the precedent analysis and the initiative\u2019s for-profit strategy. <a href=\"https:\/\/www.opendesk.cc\/blog\/parametric-design-and-tailoring\">https:\/\/www.opendesk.cc\/blog\/parametric-design-and-tailoring<\/a>, last visit: 23\/12\/2018.<\/p>\n<h2>APPENDIX<\/h2>\n<h3>List of Acronyms<\/h3>\n<table>\n<tbody>\n<tr>\n<td width=\"130\">BOM<\/td>\n<td width=\"491\">Bill of materials<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">CBPP<\/td>\n<td width=\"491\">Commons-based Peer Production<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">DGML<\/td>\n<td width=\"491\">Design Global Manufacture Local<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">FOSS<\/td>\n<td width=\"491\">Free and Open Source Software<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">FSF<\/td>\n<td width=\"491\">Free Software Foundation<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">OD<\/td>\n<td width=\"491\">Open Design<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">OSH<\/td>\n<td width=\"491\">Open Source Hardware<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">OSI<\/td>\n<td width=\"491\">Open Source Initiative<\/td>\n<\/tr>\n<tr>\n<td width=\"130\">OSS<\/td>\n<td width=\"491\">Open Source Software<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h2>Acknowledgements<\/h2>\n<p>The author is grateful to Professor Athena Stavridou and Professor Vasilis Kostakis for their valuable comments and guidance.<\/p>\n<h2>About the Author<\/h2>\n<p>Kosmas Gavras (email: kgavras@mail.ntua.gr) is PhD candidate in the School of Architecture at the National Technical University of Athens. He holds a MArch and MSc degree from NTUA. His MSc thesis focused on &#8216;<a href=\"http:\/\/dspace.lib.ntua.gr\/handle\/123456789\/44574?locale-attribute=en\">The structural properties of digital commons<\/a>&#8216;. He has given lectures as a guest to NTUA School of Architecture concentrating on Open Design and Digital Commons. Beyond the Commons, his research interests include: Computational Design and Digital Fabrication. He has taken part to international conferences and architectural design competitions gaining awards and honorable mentions. His professional experience is complemented by participation in a wide range of architectural design projects across all scales. Currently, he is project architect at ATEN architects leading transportation and infrastructure design projects at Middle East.<\/p>\n\n","protected":false},"excerpt":{"rendered":"<p>By Kosmas Gavras Download as PDF INTRODUCTION Open source software (OSS) has become a dominant mode of production in a number of areas such as server software, operating systems and scripting languages (Lerner and Tirole, 2005; Chesbrough and Appleyard, 2007). Since the last decade, several studies have focused to a<\/p>\n<p class=\"top10\"><a href=\"http:\/\/peerproduction.net\/editsuite\/issues\/issue-13-open\/peer-reviewed-papers\/open-source-beyond-software\/\" class=\"link\">Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"parent":7922,"menu_order":3,"comment_status":"closed","ping_status":"closed","template":"template_full_width.php","meta":[],"tags":[],"_links":{"self":[{"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/pages\/7863"}],"collection":[{"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/comments?post=7863"}],"version-history":[{"count":32,"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/pages\/7863\/revisions"}],"predecessor-version":[{"id":8453,"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/pages\/7863\/revisions\/8453"}],"up":[{"embeddable":true,"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/pages\/7922"}],"wp:attachment":[{"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/media?parent=7863"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/peerproduction.net\/editsuite\/wp-json\/wp\/v2\/tags?post=7863"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}