2.2.1. Learnings from open source software

It is also useful to consider the characteristics and challenges of OSS before attempting to identify those pertaining to OSH. OSS is characterized as being intensely people-oriented (Lethbridge, Sim & Singer Reference Lethbridge, Sim and Singer2005) and knowledge-intensive (Giovan Francesco & Michle Reference Giovan Francesco and Michle2003). The process of open source product development usually involves the continuous modification and improvement of a current design. OSS projects can be extremely complex, and the knowledge needed for the software development process is very broad and unlikely to be held by any one software developer or small group of developers. Understanding exactly how knowledge is produced, shared and reused during the process of OSS development is a challenge in itself (Sowe, Stamelos & Angelis Reference Sowe, Stamelos and Angelis2008). Licorish & MacDonell (Reference Licorish and MacDonell2014) argue that open source projects are usually led by a core team comprising a few individuals in charge of project communication, source code changes and major decision-making. This has been also shown by Boujut et al. (Reference Boujut, Pourroy, Marin, Dai and Richardot2019), who studied the distribution of design activities among the communities. Hence, knowledge is mainly created by this core team and shared among its members.

However, open source projects also entail a ‘do-ocracy’ work process, that is, a governance model allowing anyone to initiate ad-hoc solutions as long as they are willing to provide them. In this case, the knowledge used for decision-making is implicit (Bonvoisin, Thomas, et al. Reference Bonvoisin, Mies, Boujut and Stark2017). Any individual can make a change to an OSH project without providing justifications. This change can then be overridden by other contributions. However, the reasons behind such changes are not given. According to Rigby et al. (Reference Rigby, Zhu, Donadelli and Mockus2016), one of the challenges of OSS project KM stems from the close relationship between the author and the authored source code. This means that a software development project can suffer knowledge loss if authors leave the project with their code unfinished. Their replacements tend to be less productive since they have to work on an unfamiliar code base. This phenomenon, called ‘ turnover ’, also applies to OSH projects as we will see later. The open source product work force (usually unpaid volunteers) is transient leading to a high turnover rate and project knowledge loss (Rashid, Clarke & O’Connor Reference Rashid, Clarke and O’Connor2017). So, like OSS projects, OSH projects are also knowledge-intensive and driven by a transient work force usually composed of volunteer makers. The OSH development process can be organized to resemble that of OSS to a considerable degree (Raasch Reference Raasch2011). Therefore, it can be assumed that OSH projects will inherit the same KM challenges as OSS projects.

2.2.2. Specific questions raised by open source hardware

Furthermore, due to the physical nature of tangible products, another particular KM challenge for OSH projects lies in the difficulty of sharing knowledge related to physical product development using digital IT platforms (Boisseau, Omhover & Bouchard Reference Boisseau, Omhover and Bouchard2018; Chandrasegaran et al. Reference Chandrasegaran, Ramani, Sriram, Horváth, Bernard, Harik and Gao2013).

In short, three main research questions can be identified for OSH projects related to KM challenges:

1. (i) The OSH community is usually largely self-organized and comprises members occupying a diversity of roles. However, according to the literature, an OSH project is often dominated by a core team made up of a few people in charge of major project decisions and that is carefully managed by the project coordinator (Raasch Reference Raasch2011). Project contributors who are not part of the core team have limited access to knowledge production and knowledge sharing. As Aitamurto et al. (Reference Aitamurto, Holland and Hussain2015) argue, the data produced during the design process should be available as open data in order to expand knowledge access. Therefore, is there a challenge in scaling up knowledge sharing across the entire OSH community?

2. (ii) An open source project team is usually initiated and steered by the core team while there is a high turnover among other volunteer participants (Foucault et al. Reference Foucault, Palyart, Blanc, Murphy and Falleri2015). This constant organizational change leads to knowledge loss (Rashid et al. Reference Rashid, Clarke and O’Connor2017), since not all contributors are aware of the overall project status and other contributors’ activities (Treude & Storey Reference Treude and Storey2010). Does this turnover issue also apply to open source hardware?

3. (iii) Since OSH development aims to produce tangible products (Müller-Seitz & Reger Reference Müller-Seitz and Reger2010), do ‘offline’ activities documentation such as prototyping and testing represent an issue for OSH developers?

Limited research has been performed to address the KM challenges in OSH projects. This paper contributes to better understanding of how OSH communities manage their project knowledge before suitable KM solutions can be put forward. A systematic analysis of OSH practitioners’ interviews highlighted interesting issues raised by OSH specificities, such as volunteer-based participation, high turnover or very heterogeneous profiles and motivations of the participants. In turn we found a significant commitment to information structuring, documentation sharing which face important challenges due to the specific context of OSH. Socialization could be seen as an interesting alternative. Unfortunately, the geographical dispersion of the participants seriously hinders the process. The paper supports the idea that KM approach could provide an interesting way to overcome the limitations observed in this study. Based on the background, characteristics and challenges outlined above, we shall put forward and explore several concepts related to OSH KM.

5.3.1. Term frequency analysis

As already stated, the aim of this analysis is to identify the most frequently annotated concepts. A Term Frequency Matrix (TFM) can be calculated by counting how many times a term appears in the DTM. This TFM can be visualized as a bar plot as shown in Figure 3, where each bar shows how many times a concept appeared in the annotation.

Figure 3. Bar plot of concept frequency.

The aim of visualizing concept frequency is to pinpoint the most discussed concepts in the interview corpus. Interesting insights can then be drawn from the corpus content annotated with these concepts. Since each time a sub-concept is annotated all the root-concepts related to it are also annotated, root-concepts are naturally more frequent than subconcepts. Figure 3 shows that, in our case, ‘knowledge sharing’ is the most frequent concept while ‘codification’ is frequently talked about as a knowledge management strategy followed by the concept ‘challenge’, which refers to the difficulties of knowledge codification. It appears that many ‘codification’ sub-concepts occur, for example, codification ‘content’, codification ‘tools’ and codification ‘benefits’ are all in the top 10 concepts. The top 10 concepts represent 69% of the occurrences and the path knowledge-sharing, codification, challenge appears to be the main one in terms of number of citations. It is worth mentioning that among all the subconcepts, the concept of knowledge codification ‘tools’ occurs the most frequently. ‘Personalization’, the other KM strategy, is also one of the top 10 concepts. The ‘knowledge loss’ phenomenon is also a frequently recurring concept in the corpus. This concept is often accompanied by the sub-concepts ‘awareness’, referring to project members’ low awareness of a project’s status, ‘unstructured information’, suggesting that project information is unstructured, and turnover, that is the phenomenon of transient community membership. Next come concepts detailing the benefits, challenges and methods of knowledge codification. For example ‘physical’ relates to the tangible features of physical products that throw up new problems for knowledge codification; ‘motivation’ is used in reference to the lack of motivation to document project knowledge; ‘open source’ is tied to knowledge codification as a precondition for open-sourced projects, etc. With respect to ‘decision-making’, the subconcept ‘core team’ occurs slightly more frequently than ‘do-ocracy’.

In summary, this analysis shows that ‘knowledge codification’ is frequently talked about in our corpus, especially its ‘challenges’ and its ‘benefits’; ‘knowledge loss’ is an important issue; and ‘core team’ dominated project decision-making and self-organized ‘do-ocracy’ both exist. The frequency of these concepts gives us a general idea of the themes in this corpus. This means that we can now search for associations, that is concepts that appear frequently together.

5.3.2. Term association analysis

Another way to analyse corpus data is to search for repeatedly associated concepts to verify the existence of patterns in the corpus data. Usually patterns are identified by a researcher according to a qualitative analysis methodology. However, the cognitive process of pattern identification is implicit. In this exploratory study, we used text-mining techniques to help us identify these patterns. In the DTM, each document may contain multiple concepts, some of which often appear together in a document while others are relatively scarce. One way to visualize frequently associated concepts is to use hierarchical clustering techniques to group documents based on their Euclidean distance (Huang Reference Huang2008). In our case, the aim was to calculate the distance of concepts (terms) rather than documents. This meant transposing the DTM into a Term Document Matrix (TDM), in which rows are concepts (terms) and columns are documents. The Euclidean distance between these concepts can be calculated; the shorter it is between two terms, the more likely they appear together in the same document. Furthermore, as documents are interviews of projects’ participants, each of them reflects the point of view of one project. Therefore, the analysis provides information on the proximity of projects with respect to a certain concept. If two concepts are close to each other this means that an important number of projects share the same association.

Based on the Euclidean distance, the concepts are hierarchically clustered according to Ward’s minimum variance method (Ward 1963). The results are displayed in a dendrogram in Figure 4. This diagram should be read from left to right and bottom to top. Each branch point encountered is the distance at which a cluster merge occurs. Consequently, the most distinct clusters are those with the largest separation, in other words those that are furthest from each other in the dendrogram. On the other hand, those closest to each other, often linked by branches from a low branch point, are those with the highest similarity (or Euclidian distance in our case). Our aim now is to identify the concepts displaying a high similarity, that is, those belonging to the same cluster or close to each other in the dendrogram.

Figure 4. Dendrogram of concept association.

There are six clusters of concepts in this dendrogram, each shown by a different colour and surrounded by dotted lines. The first cluster at the bottom of the diagram puts ‘motivation’, ‘collaborative design’ and ‘project management’ together. This cluster in fact covers codification benefits, collaborative design improvement, codification content, project management information, codification challenges and lack of motivation. To our knowledge, there is no literature showing this association and no semantic connection can be found in the corpus regarding these three main concepts. Therefore, this cluster was considered irrelevant.

The second cluster (in blue) includes an interesting codification challenge: the physical nature of tangible products, the trial and error process involved in making them and the time-consuming nature of prototyping are associated with computer-mediated communication (CMC). This highlights the difficulties raised by transforming everything into digital format. According to the literature, knowledge codification for OSH is harder than for OSS owing to the physical aspects of tangible products. Our results show a connection between a certain type of codification content (trial and error) and CMC, which requires another type of codification. Also, the trial and error process involved in product prototyping is a typical feature of a physical product, one which naturally renders its codification time-consuming and makes its translation into the digital world (CMC) difficult. This aspect is related to our third research question and will be developed in the next section.

The third cluster (in green) includes ‘turnover’, ‘do-ocracy’, ‘unskilled’ and ‘design files’. A high level of turnover in an OSH community naturally leads to potential issues in a do-ocracy based decision-making organization since there are many volunteer participants. The concept ‘unskilled’ refers to people lacking knowledge about design rationale documentation. This concept is therefore naturally linked to the codification content of ‘design files’. The connection between ‘turnover’ and ‘unskilled’ may imply that volunteer amateur OSH participants lack the proper training for design rationale documentation which corresponds to our second research question. The third cluster also basically includes most of the concepts related to the benefits of codification. The association between the ‘open source’ and ‘design rationale’ concepts should be noted as it may indicate that documenting ‘design rationale’ helps to make a project open source.

In the fourth cluster (in orange), the ‘meeting’ and ‘core team’ concepts are grouped together. In the corpus, many interviewees mentioned that the core team of an OSH project usually has regular meetings to make decisions. Meetings are a classic personalization strategy for knowledge management and the core team usually plays an important role in decision-making in small sized OSH projects.

The last cluster (in dark blue) at the top of the dendrogram includes four concepts: lack of proper ‘management’ in an OSH project, ‘unstructured information’, low project status ‘awareness’ and ‘workshops’. Due to the unstable organization of OSH projects, there is much unstructured information produced by volunteer participants. This naturally lowers people’s awareness of project status since unstructured information is hard to interpret. In the corpus, some interviewees mentioned that lack of management is one of the challenges of knowledge codification. The association of ‘management’, ‘awareness’ and ‘unstructured information’ indicates that this lack of proper management may be one of the main reasons for knowledge loss. These remarks clearly highlight the issue of scaling up knowledge sharing across the community which is our first research question. As already stated, workshops are one of the personalization strategies used in OSH projects. It is interesting to see that it is associated with concepts representing knowledge loss and knowledge codification challenges. This suggests that it would be worth searching the corpus for the semantic relations between ‘workshop’ and the other three concepts in this cluster.

This exploratory provided us with insights into the corpus that helped us to navigate the voluminous and complex data set by generating indicators. These indicators tell us where we should focus in order to generate findings. Based on this analysis, we therefore reviewed the corpus content and our findings are presented in the next section.

6.1.1. Codification is a precondition for project openness

In order to render a project open-sourced any project information must be accessible to a large public. Documenting project information and sharing it publicly via the internet is one of the fundamental features of an OSH project. Therefore, knowledge codification is considered essential to guarantee a project’s openness. As one of the initiators of Knitic put it:

A participant to project Apertus Axiom also stated:

6.1.2. Codification is a precondition for personalized production, maintenance and recycling

One of the advantages of open-source hardware is its potential for personalized production. However, this is only possible if knowledge about the product design is well documented enabling OSH users to understand and modify the design of a product. In our case, some interviewees argued that OSH product documentation should go beyond product design files to include the whole project process. After all, the life cycle of an OSH product is not over after production. There is still maintenance and recycling to be considered. This point is underlined in what one of the initiators of OSE Germany said:

An Ultrascope participant adds:

This aspect clearly illustrates the need for codification in order to allow scaling up knowledge sharing strategies in OSH communities (first research question).

Codification can mitigate the negative influence of ‘Turnover’

Turnover issues have been raised in research question 2. Interviewees mentioned the difficulties of managing unfinished contributions from unstable participants in an OSH project. Knowledge codification is usually evoked as a solution to facilitate collaborative design given this unstable organization. When newcomers join an OSH project, they can gain project experience from project documentation. When they decide to leave the project, their unfinished work can be continued by other people if their work has been well documented. The importance of documentation is reflected in the words of one of the initiators of Open Source Ecology:

Apertus Axiom adds also:

The connection between socialization and project decision-making

Several interviewees emphasized the importance of talking to each other for project decision-making. The most common form of decision-making in an OSH project is made by the core team, which has regular meetings. These meetings can be face-to-face, or people can communicate with each other by email, skype or other forms of computer-mediated communication (CMC). Collaborative decision-making can also take place on a larger scale via a coordinating committee. The coordinating committee is also organized according to the principle of socialization meeting regularly to make project decisions. Note that socialization in the context of OSH always takes the form of CMC. Google hangout and Skype are frequently referred to as the two major tools for communication, especially for big OSH projects with a relatively large and dispersed team. As for collocated project teams, physical meetings are more common.

The importance of workshops to expand knowledge sharing

Workshop organization was mentioned repeatedly by several project initiators as a way to exchange ideas, gain new ideas, increase project visibility and develop networking. It is important for an OSH project to have a certain level of visibility in order to attract new participants and expand knowledge sharing across a large perimeter in the community, which refers explicitly to research question one. The OSH online community builds reputation and visibility mainly in two ways: online social media promotion and workshops at conferences, seminars and design fairs. For example, LaCoolCo project uses workshops as a means of promoting their project because ‘everyone is there’.

Ozoncyclery uses workshops as a way to enrich design ideation. This is neatly summed up by one of the initiators:

Opensource ecology integrates this as part of its business model:

6.3.1. Lack of management within the community

Some interviewees reported their ‘frustration’ with the open source hardware design process. As mentioned in the section on ‘turnover’, free volunteer participation at any point in an OSH project is the signature of open source design. As already highlighted, this unstable form of participation raises several challenges. Many practitioners reported that one of the difficulties of collaborative documentation is the absence of a proper task management protocol within the community. Without a coordinating mechanism there is no clear documentation standard, even for sharing design files. There is no proper ‘workflow management’, especially when the stakeholders of a project are geographically distributed. This problem is reflected in the following words of one of the initiators of OSE Germany:

Apertus axiom insist on the interest of a proper management tool:

Task management and coordination mechanisms are classical problems in engineering design and are currently addressed in product life cycle management and project management tools. Our results clearly show that the problem remains in OSH communities as the tools available do not fully cover this need and the maturity of the collaboration practices has not reached a sufficient level today.

‘We do not know where to start’

Some people said that despite their motivation and awareness of the importance of documentation, they lacked the training or skill to do it. Many OSH contributors are amateur designers and DIY makers whose design process is more like that of a craftsman than an engineer. They usually begin their design process by trying out different solutions directly on a prototype rather than starting with a clear ideation and conceptual design phase. This kind of design process introduces subsequent problems for design knowledge documentation. According to an initiator from Ultrascope one of the main challenges is precisely this lack of documentation expertise:

Even if they are technically skilled persons, the profile of the OSH participants makes it difficult to follow a structured engineering process. This is a clear drawback for OHS communities. Even for those capable of design knowledge documentation, there is still the problem of how to capture design rationale. Design rationale is an important research subject that has been addressed extensively in engineering design literature (Rohde et al. Reference Rohde, Štorga and Marjanović2015; Eng, Marfisi & Aurisicchio Reference Eng, Marfisi and Aurisicchio2011; Bracewell et al. Reference Bracewell, Wallace, Moss and Knott2009; Schaik et al. Reference van Schaik, Scanlan, Keane, Takeda and Gorissen2011). It reflects the reasons behind design decisions. Capturing it involves taking into account not only decisions about product design but also why those decisions are made. A number of interviewees complained that some design knowledge documentation cannot be understood because the context of that knowledge is missing, in other words the design rationale is absent. One of the initiators from FarmHack emphasizes the importance of Q&A knowledge sharing forums where the OSH community context is preserved, making the knowledge more comprehensible:

6.3.2. Participants are not motivated to document

Some participants are not motivated to document their project information. They do not realize what the benefits of knowledge codification are and are especially discouraged by how time-consuming it can be. One specific interviewee from Hovalin argued that OSH projects for him were a hobby and you do not document what you decide about your hobbies.

FarmHack member complains:

This can also be connected to the issue of design rational capture that has been clearly identified as an issue in engineering design for long as highlighted in the previous section. Both skills and motivations are two factors that hinder the documentation process and appear as relatively typical from OSH communities. In more traditional engineering contexts, professionals are trained and documentation is part of the engineers’ duty making these difficulties less salient.

6.3.3. The physical aspect of OSH

Compared with software design, OSH development involves ‘offline’ activities linked to the tangible attributes of physical products. Many interviewees reported that they usually tried to make a prototype directly without working on the conceptual design on a computer. By directly handling a physical product, the designer can feel the material, make quick adjustments and explore different alternatives. This kind of activity does not require extensive knowledge of CAD. However, it is challenging and sometimes impossible for designers to put all this tangible experience into a documentary form. As one of the initiators of Apertus Axiom said:

Another particular feature of a tangible product compared with an entirely digital software product concerns its manufacturing, usage, maintenance and recycling, all of which are completely ‘offline’. The knowledge related to these offline phases is usually lost. As one of initiators from InMove put it:

These nondocumented activities clearly represent a problem for OSH communities in terms of knowledge sharing (scaling up knowledge sharing) and in terms management. This aspect seems typical from OSH communities and absent from engineering design literature.

6.3.4. Tool limitations

Some of the interviewees reported that the tools they use are not adapted to OSH. Currently, there are no collaborative platforms specifically dedicated to OSH. Practitioners mainly rely on GitHub, which is a platform developed for open source software design and, as such, it lacks many essential features for tangible product knowledge sharing, especially CAD file sharing. A number of people interviewed said they use a series of management and file-sharing tools to support their project, for example, google drive, basecamp and wiki. However, a specially designed collaborative work platform is needed to scale up participation in an OSH project. Recently, more and more initiatives have emerged to build potential alternatives dedicated especially to OSH, for example, Wikimedia, Wikifactory.