Research Hardware Publications Should Help Build Communities, Careers and Better Hardware

1. Introduction

This study asked why people who had developed open source hardware projects (the research hardware engineers, RHEs) would use or have used the academic journal publication system inside these projects. After introducing the concepts of open source hardware publishing and research hardware engineers, we will present the result of an analysis of 15 interviews run in 2023.

1.1. Hardware Documentation Publication

Open source hardware was first recognised as a pillar of open science strategies in the UNESCO Open Science recommendation in 2021 (UNESCO 2021). This was the result of a decade of advocacy (Arancio 2021; Pearce 2012), as well as the development of open licenses dedicated to hardware (Luis Felipe R et al. 2010), and standardization efforts to improve documentation (Open Source Hardware Association 2010; Bonvoisin et al. 2020). The interest in better documenting and sharing hardware designs is growing (for instance the “OSHWA Certified Projects List” (2023) has close to 3000 projects currently). In addition, there are presently three academic journals that are publishing articles devoted to hardware: Journal of Open Hardware (ISSN 2475-9066), HardwareX (ISSN 2468-0672) and Hardware (ISSN: 2813-6640). Academic publishing is a part of scholarly communication that encompass the processes of producing, reviewing, organizing, disseminating and preserving scholarly knowledge (Working Group Open Access and Scholarly Communication of the Open Access Network Austria 2016). It usually involves the creation and dissemination of an archived (preserved) version of that knowledge, which has been previously peer-reviewed and can be cited in other academic publications.

Hardware journal articles present a summary of the hardware documentation in the form of text and images, while often linking to additional digital assets online. However, software and hardware documentation or “source” is not in the form of a single plain text file like manuscripts are (Bonvoisin et al. 2017). In recent years, new concepts of peer-review dedicated to software emerged, where reviewers deal with the technical content and quality (meaning the source code), instead of only with a report about the software and its performance. Research software peer review has been developed inside different communities (Ropensci, Pyopensci), and is getting more attention (Wasser 2024). The Journal of Open Source Software (ISSN 2475-9066) combines the two approaches: it performs a software peer review and publishes a “short abstract describing the high-level functionality of the software (and perhaps a figure) as an academic article” (Smith 2016), if the review is positive. In hardware communities, there have been attempts at reviewing hardware documentation (Bonvoisin et al. 2020), as well as self-certification of their open source nature (Open Source Hardware Association 2023), but an academically recognized publication of hardware documentation is still missing.

1.2. Roles of Research Hardware Engineers

In order to build an efficient hardware documentation publication ecosystem, one needs to understand research hardware engineers (RHEs) motivations and needs. We define here RHEs as people who are participating in a research hardware (RH which describes “physical objects developed as part of or for a research process”, (Milijković et al. 2024)) project and feel ownership over that project or part of it. While we focus mainly on the role of RHEs as project owners and publication authors in this report, the same RHEs may also be reviewers or readers of other hardware publications. As we expected the needs of the reviewers and readers to be of importance to the authors, we did not try to separate motivation and needs per actor types, but grouped them into different topics instead.

We interviewed people involved in different emblematic projects (Colomb et al. 2024). We did find a large variety in engineering knowledge inside our sample of RHEs: some are biologist, artists or software engineers becoming makers, others are highly skilled and experienced engineers who have been working in academia or in the industry for decades. While different groups of RHEs may have different expectations for a hardware publication system, we did not try to analyse how expectations are interlinked or what relative value they may have. We then discuss the implication our results may have on future directions in hardware publication systems.

2. Method

From the transcripts of the fifteen interviews, we derived 52 user stories in the form of “as a [user category], I want [features], in order to [objective]”. The interviews lasted for one hour. There were no direct questions on the motivation to publish the hardware in a journal. We then categorized these user stories, following four categories: “Growing community of contributors”, “Making the work discoverable and recognized”, “Have a quality control”, and “Facilitate knowledge transfer and production”. Finally we went through each story, including and organising the objectives and feature requests in a first draft. We then went through a series of reviews to make the text easier to read. While this negatively affected the provenance information of the statement made in this article, the readability of the text improved significantly. The categorization was also modified during the process. Data availability: A derived form of most of the interviews was published under a CC-BY license with interviewees as coauthors (Colomb et al. 2024). The user stories are available on zenodo (Colomb, Maxeiner, and Mies 2025)

3. Results

We read the transcript of 15 interviews of research hardware engineers, looking for features they would expect from a hardware publication platform and reasons they would want these features. We present here the results of the analysis of these user stories, which were grouped following categories of motivation: Two intrinsic motivations (career and personal development) and two extrinsic motivations (community building and hardware improvement). Subcategories were also defined as presented in Figure 2. Here, we present the different features in more details, in order of complexity and not importance, as this latter property was not assessed.

Figure 1. Mind map representation of the RHEs main motivations and needs. One node represents RHEs motivation, with four main branches: Community building, improving the hardware, career development and personal interest. The “recognition for all contributors” is seen primarily a career development motivation, but is also linked to giving motivation to contributors and therefore grow the community. Similarly, elements which improve the hardware, are also helping to grow the community. The second node represent some wishes for a better hardware publication ecoystem: RHEs wish for an inclusive system which would be integrated into their current workflow and which would keep RH project independent from that platform. See text for further details.

Figure 1. Mind map representation of the RHEs main motivations and needs. One node represents RHEs motivation, with four main branches: Community building, improving the hardware, career development and personal interest. The “recognition for all contributors” is seen primarily a career development motivation, but is also linked to giving motivation to contributors and therefore grow the community. Similarly, elements which improve the hardware, are also helping to grow the community. The second node represent some wishes for a better hardware publication ecoystem: RHEs wish for an inclusive system which would be integrated into their current workflow and which would keep RH project independent from that platform. See text for further details.

3.1. Growing a Community

RHEs mentioned that publication may be a way to grow their community of contributors and users, helping the project to be discovered and taken seriously. We separated different aspects of the development of a community of contributors, which starts with raising their interest, continue with facilitating contributions, and end with keeping them in the project or creating their derived projects. In addition, the community may also involve users and production partners.

3.1.1. Attracting Contributions

In order for projects to find their audience and adopters, a publication platform should first be compatible with present and future discovery tools. This is particularly important for new projects looking for new adopters. One should be able to browse and filter projects, for instance by topics, stage of the project and skill needed (to use or to contribute), as well as compare different projects. The audience should access concise information to rapidly be able to decide whether they want to contribute to a project, for instance giving a condensed, well structured, and easy to consume primers of the project, as well as information about the community and the project general aim.

On one hand, it might be relevant to have a preview of the hardware (in some cases a video of the hardware in function may be particularly useful), and information about and example of the type of output/data produced by the hardware. Indication about the skills needed to build the hardware should be made clear, such that newcomers can evaluate whether the project can be adapted to their local conditions. On the other hand, information about the community – such asits values, practices, and project governance should be easily findable. Long term objectives and the overall vision should also be provided. In addition, there should be clear information on the legal framework that allows (or restrict) the reuse of all material.

3.1.2. Facilitating Contributions

In order to facilitate contribution to a project, new contributors should know how they can contribute and what recognition they can expect. They should find information about what contribution is welcome, how they can communicate with the project leads or the community (including internet and social media platforms), and how they can actually make contributions. The tool and infrastructure used to document the hardware project should be indicated (and relatively simple) in order to facilitate onboarding of new contributors and prevent confusion for the readers.

3.1.3. Motivating Contributors

In order to attract and retain community members, it is important to be able to recognize different contributions to the project. Similar to open source software projects, varied roles are important and the platform should be able to give credits to every contributor, respectively of their engagement and type of contribution (see Section 3.4).

Finally, the community should be able to grow independently from the publication platform and from the project leads (see Section 3.5.3). Its existing structure (governance, succession plan) and communication channels should be indicated. The readers will therefore know where to look for additional information or direct help. Furthermore, the platform should ensure the hardware documentation is archived beyond the involvement of the project owners and beyond the existence of the platform itself.

3.1.4. Community of Users and Producers

Several RHEs are also selling hardware, or using the community of users to buy hardware component in batches to reduce costs. Publishing their RH documentation package is a way to attract users and buyers and get publicity for their project. In order to attract customers, the documentation should give an overview of the hardware capacities and cost. In particular, if relevant, it should give example of data collected and describe related data standards and repositories. In order to facilitate the use of the hardware and widen the audience, the presence of training material (for instance tutorials) aimed at users with limited engineering experience is welcome.

On the other hand, RHEs may want to attract industrial partners who would produce, maintain, repair or recycle the hardware on a larger scale (reducing costs). The ultimate goal is to reach a wider market, and therefore attract and help more users. Importantly, this aspect is not restricted to production, and RHEs should design and document hardware while being mindful of the life cycle of the product. In addition, mature projects with potential for commercialization should provide information on the certification of the hardware (this might include tests to perform and existing certification processes), in order to facilitate the work of producers, such that the product can be safely and legally sold.

3.1.5. Promoting Derived Projects

As readers, RHEs may often look for solutions to create or modify their own project, often reusing only a small part of a hardware. This can be facilitated by providing documentation in a modular way and giving as much background as possible on design choices. Furthermore, by promoting derived project, one may gather feedback which can then be used to improve the hardware (see section Section 3.2).

It is good practice to document hardware as smaller parts or modules of a larger instrument, as it can facilitate reuse. The ecosystem should highlight these aspects of the documentation and show how the hardware is or can be treated as different modules.

Information about the development history of the project should also be easily accessible. Indeed, future changes in hardware design, especially by RHEs outside of the original project, is greatly facilitated when design decision are recorded and explained. This is particularly important for decision taken in relation to the local infrastructure or material sourcing, as itthis information will facilitate the adaptation of the design to different objectives or local conditions.

3.2. Improving the Hardware

RHEs often complain about the difficulties to obtain feedback on their design. Good feedback has the potential to speed up new iterations of the product and improve the design. RHEs are looking for feedback from other RHEs, from manufacturers, and from users.

Other engineers could indeed discover imperfections and problems before manufacturing starts, as well as help to make or plan improvement of the design. Feedback from hardware producers may especially help make the hardware ready for commercialization or for local manufacturing. As stated in Section 3.1.4, this feedback can also be useful in early stage of development, as knowledge on the life cycle of the hardware or certification processes may direct specific design choices. Finally, feedback from the community of users (including non-experts) might help improve both the hardware design and its documentation. As stated in Section 3.1.5, improving the hardware might also lead to a modularisation of the project, which facilitates reuse, especially for the creation of derived projects. It also

3.3. Personal Interest: Learning and Having Fun

The whole activity to develop open source hardware is often seen as a way to expand one’s skill-set, RHEs are using the project to get in contact with new tools or learn new aspects of hardware development. Similarly, a hardware publication platform could be a learning experience for both the authors and the reviewers. Highlighting the history of the project (see Section 3.1.4) is also a way to promote a learning experience for peer-reviewers and future readers. In addition, providing this context information is necessary for the reviewer to give useful and informed review.

Many RHEs have a pleasant and fun time creating hardware, while interacting with other RHEs in their communities. The hardware publication process has the potential to become a pleasant exchange of ideas and knowledge, if the tooling does not come in the way but allow creative ideas to emerge.

3.4. Career Development and Recognition

RHEs want to control when they are going public, as part of their strategy to maximize impact and control the narrative around a project. This implies that the platform should provide the possibility to get private content reviewed, so RHEs can make sure only content reaching a certain quality threshold get public. In addition, hardware projects may follow different stages of development, and RHEs seek recognition for the maturation of projects (beyond the prototyping stage), meaning that reaching a new milestone in a project should be sufficient to lead to a new publication.

A main objective for academic RHEs is to get a method to quantify and showcase the impact of a project. For them it is a way to build a reputation and may help them get more public funding and institutional support for not only that project but also new projects. It should also serve as a personal achievement and an official recognition of their skills, such that it can help them get a new job in academia or in the industry. Publication can be a way for RHEs to contribute to the scientific knowledge and get recognized by the scientific community. In a virtuous cycle, building recognition for RHEs work will also help the development of a community of professional contributors in the project (see section Section 3.1.3).

3.5. Some Barriers and Wishes

3.5.1. Inclusive Ecosystem and Communities

Most project want to address a global audience, and a publication platform has to be inclusive for project created anywhere . In particular it should avoid financial or language barriers for readers and authors. This ideally includes both mulitlinguism of the platform and the absence of unexplained jargon terms.

3.5.2. Compatible with Existing Workflows

In order to facilitate modification of the hardware documentation during review, a platform should allow RHEs to use their usual workflow. In particular, RHEs often use continuous integration (CI) tool that automatically make several checks in the repository where the project lives. A platform to hardware publication should make sure RHEs can still use their CI tools while changing the documentation in response to the reviewers comments.

The platform should help the RHEs avoid pitfalls and prevent confusion of the reader. This might mean restricting the information available at first sight, for example via the use of warnings or ways to hide information that is only useful for the specialists.

A hardware publication platform should be fun to use, or at least straightforward. It should avoid the use of forms to input data, and provide other acceptable formats for data entry. It should also be designed to facilitate the publication of new versions of the hardware, in order to make it easier to recognize different types of accomplishments (and different types of contributions).

3.5.3. Independent and Trustworthy

Last but not least, the research hardware project should stay independent of the publication system. On top of the community communication, the development itself should happen somewhere else, and the platform should accept submission coming from different hardware development software and platforms. The platform should be known and inspire trust in the published projects. The quality assurance should be thorough, transparent and easy to understand. The platform should be endorsed by the community (or communities), well known, and easy to access.

4. Discussions

Based on 15 interviews of prominent open source hardware projects (Colomb et al. 2024), our qualitative analysis suggests that the motivators for RHEs to invest time in the publication of their research hardware is to build a community, to improve the hardware, to get advancement in their career and to learn new things (Figure 1). While looking at a predefined set of motivation which did not include community building aspect, previous work (Hausberg and Spaeth 2020)) suggests that expected skill learning and having fun correlate with the time spent hacking. Another study looked at motivation to use an open source hardware license for commercialized products, finding that moral obligation, altruism, as well as market obligations, reduced time-to-market, and lowered costs were motivators (Li et al. 2021). While our sample had only project having such a license, these motivation did not show in our analysis, suggesting that licensing and publishing hardware are two different aspects of research hardware activities. Indeed, research hardware publication does not always comes with a license,.like for data and software, one can distinguish hardware openness and hardware documentation availability, using the FAIR principles (Chue Hong et al. 2021; Wilkinson et al. 2016).

While our analysis does not allow to sort motivations by their importance in a representative way, the mentions of community growing was surprisingly widespread (mentioned in at least 3/4 of interviews). While this might be related to the questions asked during the interviews, it might also reflect specific needs in RH projects. RHEs intend to use RH publications to raise awareness of and build trust in their project, hoping to attract users, contributors, and hardware producers. It should also help consolidating teams by motivating current contributors to continue to work on the project. In addition, RH publications should provide recognition for RHEs and their work, (including work to elevate the maturity level of the product), and bring a seal of quality that is valued by other engineers and researchers (who could then become new contributors in the project). It should be considered a research output, which means publication should provide an entity that can be cited, has a persistent identifier and can be easily discovered (Mathiak et al. 2023), for example through indexing in aggregated databases using specific metadata (Bonvoisin et al. 2020). It should ideally also be free of charge for readers and authors in order to be inclusive (UNESCO 2024).

Concerning the quality control aspects, a review system should be incorporated with tools already in use in the community (mostly GitHub and GitLab), in order to lower the technological hurdles. The improvement of the hardware documentation should be an important objective of the publication process. Specific aspects of the process could be derived from the DIN SPEC 3105-1 (DIN e.V. 2020), while the peer review should be interesting, pleasant to use, and an opportunity to learn. Since RHEs are also eager to learn, it might be interesting to include some quality management tooling inside the peer review (Mies et al. 2020), which would also call for reviews at early stages of the RH development.

There is an inherent discrepancy between making a snapshot of the project at a certain time (a peer reviewed, archived version which is necessary to be considered a research output), and growing a community over time and associated hardware iterations (Klump et al. 2024). For each type of information, one needs to consider how to link the verified (peer reviewed) snapshot content and updated information, such that readers can easily find the latest state of the project. Indeed, RHEs mentioned that the development of the project should be independent of the publication platform. In the current academic ecosystem, project impact is usually quantified by number of citations, meaning the hardware should be easy to cite and probably obtain a well established type of persistent identifier. Since it should be a tool to grow a community of users and contributors, the publication might include a manuscript format. A paper is indeed a way to distribute the knowledge in a format recognized by non-engineers researchers, who may get inspired by the project, and become new users or contributors.

This analysis of the motivations of RHEs can help in the analysis and modification of the current research hardware publication ecosystem(s). For example, our analysis confirms the choice made by the Journal of Open Hardware to become a diamond open access journal (The Journal of Open Hardware Editorial Board 2024). By analyzing the content of publications and other documentations, it will be possible to highlights further gaps. This may help the design of new publication and peer review systems dedicated to research hardware (Colomb et al. 2023), which may enhance the current ecosystem. A RH publication system independent of journal papers may complement the current OSH journals ecosystem, such that both elements bring complementary values and do not substitute for each other.

Importantly, our analysis shows that community development aspects are extremely important. This suggests that a hardware publication ecosystem should not only report about the hardware product but also about the hardware development process and community practices. While these aspects were previously recognized in the literature (Bonvoisin and Mies 2018; Mies, Häuer, and Hassan 2022), and in the Turing way book chapter on open hardware (Community 2022)(https://book.the-turing-way.org/reproducible-research/open/open-hardware), their importance has probably been underestimated so far. We therefore thrived for investigating the needs for a hardware publication system which considers not only the hardware product and replicability, but also the documentation of the hardware development process, especially its collaborative aspects. A publication system should be integrated in the development workflow, and become both a specific snapshot of a project and an entry point for new community members, who will further develop, use, or produce the hardware.