Open Science Hardware: An Introduction for Librarians: Key Points

Introduction: What is open science hardware?

Open science hardware (OSH) makes scientific tools freely available to study, build, and adapt—supporting transparency and innovation.
OSH addresses the limitations of proprietary “black box” tools by promoting reproducibility, accessibility, and customization.
It empowers researchers worldwide, especially those with limited resources, to participate in and contribute to science.
Examples of open science hardware can be found in most academic fields, with salient examples in neuroscience, environmental monitoring and microscopy

OSH is developed by a wide range of actors—from academic labs and companies to DIY communities and grassroots collaborations.
Good documentation includes: design files, bill of materials (BOM), source code or firmware (if applicable), assembly instructions, testing/calibration data, and a clear open license.
Librarians can support researchers by helping assess documentation completeness and encouraging early sharing—even before a design is finalized.
Not all “open” projects are truly reusable—many lack the documentation needed for others to replicate or adapt them.

Licensing grants others the legal rights to use, modify, and redistribute a design.
OSH projects often involve multiple license layers—for hardware designs, documentation, software, and firmware.
Two main types of open licenses: Copyleft (e.g. CERN-OHL-S, TAPR OHL), requiring that any derivatives are shared under the same license; Permissive (e.g. Solderpad, CERN-OHL-P), allowing broad reuse with minimal restrictions, including in proprietary contexts.
The CERN Open Hardware Licence v2 is the most used one, and offers three variants (Strong, Weak, Permissive) to suit different openness levels.
Not all Creative Commons licenses are truly open source—those with NC (Non-Commercial) or ND (No Derivatives) clauses restrict reuse and are not suitable for OSH.

OSH projects are shared on a range of platforms—GitHub, GitLab, Hackaday.io, Wikifactory, academic journals, and institutional repositories—all with different strengthts
A well-documented OSH project should include at least: A README file, design files in open formats, bill of materials (BOM), assembly/testing instructions, open licensing
Visible community engagement (e.g. GitHub issues, forum interactions, feedback) is a strong signal of project health and usability.
Even early-stage sharing—of ideas, trade-offs, and decisions—can foster transparency, collaboration, and reuse.

Researchers engage with OSH as both developers (creating and sharing new tools) and users (replicating or adapting existing tools); recognizing this distinction is key to offering the right support.
Support can include recommending forums, guiding participation, and lowering entry barriers
OSH communities value all types of contributions—from bug fixes and documentation improvements to new use cases and adaptations.
Many researchers hesitate to engage; librarians can help normalize participation and foster confidence by highlighting that OSH is collaborative, not competitive.
Your library can play a strategic role in supporting open communities—through referrals, programming, infrastructure, or peer learning.