Content from Introduction: What is open science hardware?
Last updated on 2025-06-13 | Edit this page
Estimated time: 30 minutes
Overview
Questions
- What is open science hardware (OSH)?
- Why is OSH important in academia?
- What are examples of OSH projects?
Objectives
- Define open science hardware
- Describe how OSH benefits reproducibility, access, and innovation
- List at least 3 concrete examples of OSH in research or education.
Background: complex challenges, open opportunities
The challenges we are facing in the 21st century call for a more democratic, collaborative, all hands on deck approach to science and technology. But to participate in research, people need tools. Ideally, tools that would allow anyone to locally pursue the research questions they are seeking to answer.
During the last decade, following the ideas of free and open source software and seizing the opportunities opened by the maker movement, more and more people started building their own tools for research. Taking the “open” in open science one step further, they release their creations or modifications under open licenses, sharing them through different internet platforms so anyone can build, study, modify, or commercialize them.
This practice, or “open science hardware (OSH)”, is growing worldwide.
Callout
In their 2021 Open Science recommendation, UNESCO defines open science hardware as “the design specifications of a physical object which are licensed in such a way that said object can be studied, modified, created and distributed by anyone, providing as many people as possible with the ability to construct, remix and share their knowledge of hardware design and function.”
Why are researchers using and developing OSH?
Today, researchers in academia have a hard time making science hardware work for their own needs. Science tools can be considered what we call black boxes: we know what goes in and what we get back, but we have limited or no information on their internal workings or design. This is a significant problem for science in terms of reproducibility, but it also has other consequences.
For scientists, black boxes are a problem because they make it difficult to source, maintain and adapt tools to different needs. Science often demands adapting experimental settings to new research questions; collaborative research with communities or citizen science projects often presents needs that were not originally conceived in the design of science hardware. The lack of access to blueprints combined with the niche, highly-specialized nature of science increases labs’ dependence on centralized vendors; only some can afford the extra costs and delays.
Beyond customization, most of the tools used in research today are unevenly distributed. Science infrastructure is usually available to highly skilled experts, well-funded laboratories, and renowned institutions in countries with high investments in science and technology. For many scientists with limited budgets, access to the tools for research is hampered by prohibitive import taxes, lack of access to technical support, or inability to source spare parts. It becomes even more difficult for those communities aiming to participate in research in non-conventional settings, outside academia.
This section is good for learners to exchange their own experience with science
Advantages of open science hardware
In this context, developing and using OSH gives researchers much better control over their experiments, and access to research that wouldn’t be possible with conventional proprietary instrumentation.
There are several benefits of OSH, including:
Research integrity: Research is inherently iterative, where we always build on past knowledge. Making hardware designs open source for others to study, peer review, reuse, and improve demonstrates accountability and commitment to the scientific process.
Replicability: Open Source Hardware designs can be replicated, allowing for verification and reproduction of experiments and data. Moreover, users can have much better control on the calibration of their devices, boosting replicability even further.
Innovation: By making OSH designs open source, others can collaborate on the design process leading to faster development, better products, and a larger user base for OSH instruments. Everyone benefits, as new designs do not need to start from scratch and designers of original instruments get access to derivatives of their work without having to develop things themselves.
Accessibility: OSH can make research more accessible, inclusive and diverse as the availability of designs allow anyone, anywhere to replicate and use hardware to test emerging ideas, and collect data, independently from who and/or where they are.
Flexibility: OSH allows researchers to quickly put together designs to test new research questions in an accessible way. With less risk, researchers can explore a new direction before committing more resources or using shared facilities that imply greater bureaucracy. Using rapid prototyping tools and open source licences scientists can adapt their experiments to their needs, and share these changes so others can do the same.
Parallelisation: Given the general fairer price point of OSH, the same budget that allows for the purchase of one proprietary device, normally enables the purchase/building of several equivalent OSH designs. This potentially enables much faster data collection and even collection of certain types of data that would be too cumbersome to do in a serial manner.
Sustainability: OSH designs can be more sustainable than proprietary products because they can be repaired and modified, extending the lifespan of the product and reducing waste. And in the case of the supplier going out of business, users and/or third party companies can keep systems running.
Education: OSH designs can be a valuable educational tool, allowing students and researchers to learn from it, and fully understand how a certain tool is capable of capturing data on specific phenomena/events. This in turn opens up the opportunity for the design of better experiments and better control of data being output by equipment.
Callout
How does OSH align with FAIR principles?
People in the community are working towards alignment with FAIR, to make OSH: - Findable: Projects are shared with searchable metadata on open platforms. - Accessible: Designs are available online under open licenses—no paywalls or restrictions. - Interoperable: Uses standard, widely accepted formats like STL or CSV, and modular designs that work well with other systems. - Reusable: Complete documentation and clear licensing make it easy for others to build, adapt, and improve on the work.
Challenge 1: OSH and libraries
Identify three ways in which open science hardware aligns with library values of access and preservation.
ACCESS - It makes science tools available to more people: Just like libraries help people access books and info for free, OSH makes lab equipment and tools available without needing to buy expensive commercial stuff.
Helps level the playing field: A small university or school with limited funds can build tools using OSH designs, giving more people a chance to do real science.
Encourages learning by doing: Since people can build and modify the hardware, it’s like having hands-on learning resources, which libraries often promote.
Supports community-driven knowledge: OSH is often built and improved by communities, similar to how libraries value sharing knowledge openly.
PRESERVATION - It documents everything: OSH projects usually include manuals, design files, parts lists, etc. That makes them easy to reproduce and store—just like libraries archive useful information.
It keeps knowledge from disappearing: If a company stops making a tool, you’re stuck. But if it’s open, the design still exists and can be reused or repaired later.
Formats and licenses make reuse easier :Like how libraries like open formats (PDF, CSV, etc.), OSH encourages using accessible formats and clear licenses, so designs can be preserved and reused easily.
People can adapt and remix the designs: like preserving not just the object, but the idea behind it—so others can build new things from the old.
It’s sustainable: by enabling repairs and upgrades instead of throwing things away, OSH supports long-term use and reduces waste—something libraries increasingly care about.
Examples of OSH in academia and beyond
Neuroscience: Open Ephys
Open Ephys is an open-source, employee-owned cooperative that aims to make neuroscience research more accessible by providing high-quality, affordable tools for electrophysiology. Founded in 2014, it supports researchers in building their own open-source rigs and promotes community ownership of scientific tools. By focusing on collaboration, open standards, and cost-effective alternatives to commercial systems, Open Ephys helps reduce duplication of effort and fosters innovation across the global neuroscience community.
Conservation ecology: Audiomoth - Open Acoustic Devices
AudioMoth is a low-cost, open-source audio recorder designed for environmental and biodiversity research, capable of capturing both audible and ultrasonic sounds. Originally funded by UK research councils, it has been widely used to monitor wildlife and detect illegal activities impacting ecosystems, such as tracking jaguar and puma populations. Its affordability and open design have led to broader applications, including studies on human health and noise pollution. Now developed and distributed by Open Acoustic Devices, AudioMoth can be bought pre-assembled or built using freely available design files.
Microscopy: OpenFlexure
OpenFlexure is a high-precision, 3D-printed microscope designed to be affordable, customizable, and easy to maintain, making it ideal for education, research, and even healthcare applications. Originally developed at the University of Bath and now co-developed with STICLab in Tanzania, it combines traditional microscope objectives or a Raspberry Pi camera with submicron stage precision. Its open, modular design allows users around the world to adapt the tool for needs like water quality testing or malaria diagnosis. By relying on locally printable parts, OpenFlexure enables communities to build and repair their own scientific equipment without costly servicing.
Challenge 2: Find open science hardware projects
Use a simple browser search and list the three most interesting open science hardware projects you can find online.
Many possible answers!
Key Points
- 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
Content from Lesson 2: How does open science hardware work?
Last updated on 2025-06-13 | Edit this page
Estimated time: 30 minutes
Overview
Questions
- Who is making open science hardware and for whom?
- What is shared in open science hardware?
Objectives
- Be aware of the diversity of open science hardware projects and how it impacts documentation
- Understand the main elements of open science hardware projects
Multiple ways of producing open science hardware
Open science hardware is created through a variety of pathways, reflecting the wide range of people and institutions engaged in science. As a result, documentation can be found in multiple, and often non-academic, publication venues.
Some designs emerge from DIY or maker communities, where individuals use accessible digital fabrication tools—such as 3D printers or microcontrollers—to develop low-cost, adaptable solutions. Other hardware originates in academic and research institutions, often in response to specific scientific needs. In these cases, researchers may document and share their work through scholarly publications or institutional repositories.
There are also collaborative efforts, such as hackathons or international gatherings like GOSH (Gathering for Open Science Hardware), where interdisciplinary teams co-develop tools with input from scientists, engineers, educators, and community members. These communities often run their own forums, where documentation can be found either in repositories or websites/wikis.
Finally, some commercial initiatives have adopted open hardware principles, releasing product designs under open licenses to foster community engagement and innovation. In these cases, a company website is probably the best source of information on that specific open hardware design.
Challenge 1: Meeting people where they are
Imagine a researcher at your institution has developed a custom sensor and wants to make it openly available. Based on what you’ve learned about the diversity of OSH practices, list two questions you would ask to better assess their choice.
- Where do you plan to share the documentation?
- Who is the intended audience or user community for your sensor?
- What kind of documentation have you prepared?
- Are you collaborating with any community or platform that supports open science hardware?
- Have you chosen a license that allows others to freely reuse and adapt your design?
- Are you considering publishing your work in a formal or informal venue?
- Are you aiming to make the sensor easy to reproduce using accessible tools?
- Would users need specialized equipment or knowledge to build or use the sensor?
From idea to prototypes and more
Open science hardware projects, like other research tools, typically begin with a clear problem or need identified by the researcher or developer. This need is gradually translated into desired features—the specific functions or capabilities the hardware should offer.
With access to affordable rapid prototyping tools such as Arduino boards, laser cutters, or 3D printers, researchers can now create and test multiple hardware concepts quickly. These early iterations are used to explore technical possibilities and gather feedback from potential users.
For librarians supporting researchers, it’s helpful to recognize that open hardware development is often iterative. A researcher may begin with a simple prototype—something functional but rough—that allows them to experiment with certain features. Through multiple cycles of testing and improvement, a more stable version may emerge.
At this stage, the design may be called a demonstrator: it works and meets the intended need, but may still require manual adjustments, lacks full documentation, or depends on custom parts. Only after thorough refinement, testing, and documentation does the hardware reach the stage of a product—something that others can reliably build or even manufacture.
Callout
While most OSH documentation begins once the design reaches the demonstrator stage, open science advocates encourage sharing from the very beginning—even during the problem-definition phase.
Documenting decisions, trade-offs, and failed experiments can benefit others in the community and foster a culture of transparency and learning. As librarians, encouraging researchers to share early—and helping them organize and preserve that documentation—can play a key role in making hardware development more collaborative, discoverable, and reproducible.
What is shared in open science hardware?
In the context of open science, sharing hardware goes beyond publishing a paper or uploading a schematic. Librarians can play a key role in guiding researchers toward comprehensive documentation practices, ensuring that shared hardware is both reproducible and impactful.
For a design to be truly open and reusable, it must include a comprehensive set of materials. The core “source” in open hardware typically consists of what we call design files that describe how the hardware is built.
Depending on the nature of the hardware, the design files can include circuit diagrams, CAD models, layout plans, files for 3D-printing or more. If the project includes programmable elements, source code or firmware should also be shared.
Open hardware should include a detailed bill of materials (BOM), outlining every component needed, along with technical specifications and sources. Assembly instructions, often with visual aids or videos, guide users through construction and setup. Well-documented projects often include information on testing and calibration, helping users assess the tool’s performance.
All these elements should be accompanied by clear and open licensing, ensuring that others can legally reuse, adapt, and redistribute the work.
Callout
A README file is a plain-text document that gives an overview of a project and guides users on how to use, build, or contribute to it. In open hardware, it typically includes the project’s purpose, key components, setup instructions, links to design files, and licensing information. It’s often the first thing someone reads—so clarity and completeness are essential.
Barriers in open hardware
While efforts to standardize how open science hardware is documented, discovered, and evaluated have grown over the past decade, significant challenges remain—many of which are directly relevant to librarians supporting researchers.
Since the OSH definition was first introduced, various initiatives have worked to align practices around openness. In reality, however, implementations across projects and organizations still vary widely.
One of the core challenges lies in differing interpretations of what “open” means in practice. It’s not unusual to encounter projects that are technically open-licensed but lack the necessary design files, build instructions, or supporting information to enable real reuse.
For librarians, this poses a key concern: a license alone does not guarantee accessibility or usability. Without proper documentation, researchers may struggle to replicate or build upon existing work, limiting the collaborative and inclusive potential of open hardware.
Challenge 2: Reusing existing designs
You’re working with a researcher who wants to reuse an open hardware design for a lab tool. They’ve found a promising project online. What questions would you ask to identify if the project is usable?
- Is the documentation complete and clear?
- Is the license open and does it allow reuse and modification?
- Has the hardware been tested or used by others?
- Are the materials and components easy to source?
- Is there community support or a place to ask questions?
- Is the design up to date?
- Is it adaptable to your lab’s specific needs or constraints? – Was it developed in a reliable context (e.g., research lab, maker community, company)?
Key Points
- 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.
Content from Lesson 3: licenses and open science hardware
Last updated on 2025-06-13 | Edit this page
Estimated time: 30 minutes
Overview
Questions
- What licensing options exist for open hardware?
- How can librarians help researchers choose a license?
Objectives
- Identify the most relevant open hardware licenses.
- Understand the differences between them
- Recommend a license based on a researcher’s goals.
What is an open source license?
Licensing is a critical part of making hardware “open.” For researchers working on open science hardware (OSH), selecting an appropriate open license—or understanding one that’s already in use—can determine whether a design is reusable, modifiable, and legally shareable. As librarians, you can help researchers make informed decisions about how to license their work or how to assess the reusability of existing designs.
Open source licenses are legal tools that define how others can use, modify, and distribute a project. In open science hardware, licenses perform two key functions: they guarantee user freedoms and set the conditions under which those freedoms are granted. These licenses originate in the free and open-source software (FOSS) movement and have since been adapted for hardware contexts.
Open licenses are not the same as placing something in the public domain. While public domain tools like Creative Commons Zero (CC0) waive all rights, open licenses retain copyright but grant specific permissions, usually with obligations—such as requiring attribution or ensuring derivatives remain open. This structure fosters collaboration while protecting the author’s intentions.
Callout
The latest version of the CERN-OHL is one of the most widely used licenses for open hardware, providing a suite of strong copyleft, weak copyleft and permissive alternatives
Why licensing matters for OSH
Unlike software, open hardware projects combine multiple types of materials: physical designs, documentation, firmware, and often branding. This makes licensing more complex. It’s not uncommon to find a project labeled “open” that uses a valid open license for its documentation, but offers no instructions or files to actually reproduce the hardware.
Licenses for OSH fall into two broad categories:
- Copyleft licenses (like CERN-OHL-S or TAPR OHL) require that any modifications or derived designs are also shared openly under the same terms. These are useful when a researcher wants to ensure that improvements remain part of the commons.
- Permissive licenses (like Solderpad or CERN-OHL-P) allow for reuse with minimal restrictions, including commercial use and incorporation into proprietary designs. These can help maximize adoption but don’t require that others contribute improvements back.
The CERN Open Hardware Licence (OHL) is currently one of the most widely recommended licenses in OSH. Its three variants—strongly reciprocal (CERN-OHL-S), weakly reciprocal (CERN-OHL-W), and permissive (CERN-OHL-P)—allow researchers to choose the level of openness and control they’re comfortable with.
When helping a researcher choose a license or evaluate an existing one, consider the following questions:
- Does the license clearly allow use, modification, and redistribution?
- Is the license compatible with the researcher’s goals—e.g., wide adoption, community building, or commercial integration?
- Does the project apply the license consistently to all parts of the work (hardware design files, software/firmware, documentation, branding)?
- Is attribution required, and are there clauses about how derivatives must be shared?
For projects aiming for certification, the OSHWA Certification Program provides guidance on applying appropriate licenses to each component—hardware, software, documentation, and branding—and helps clarify the distinction between open and partially open projects.
Challenge 1: Copyleft or not?
A researcher asks if they should use a copyleft or permissive license for their new design they’re working on. Write two pros and two cons of each approach.
Common pitfalls and how to address them
Many OSH projects still use software licenses (like GPL or MIT) or Creative Commons licenses without fully understanding their implications for hardware. This can lead to confusion or legal uncertainty. For example, Creative Commons licenses aren’t designed for functional objects, and standard software licenses might not account for physical reproduction or patent rights.
We should encourage researchers to:
- Choose a hardware-specific license (e.g. CERN OHL or Solderpad).
- Be explicit about which license applies to which component of their project.
- Avoid mixing incompatible licenses.
- Document their licensing choices clearly in a README or metadata file.
Tools like ChooseALicense.com now include hardware options and can help researchers navigate their choices with plain-language explanations.
Callout
Licenses that include non-commercial (NC) or no-derivatives (ND) clauses—like CC BY-NC or CC BY-ND—are not considered open source because they limit how others can use, modify, or build upon your work. For hardware to be truly open, others need the freedom to reuse, adapt, and redistribute—including for commercial and derivative purposes.
Learn more about this here: Why are Creative Commons ‘Non Commercial’ licenses not Open Source and a big problem for hardware & product design - Mifactori
Challenge 2: Licenses in real projects
Find an example of a project using CERN-OHL and summarize why this license fits the project.
- Projects in the Open Hardware repository (https://ohwr.org/)
- Projects in the OSHWA list, filtered by CERN license (https://certification.oshwa.org/list.html)
Key Points
- 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.
Content from Lesson 4: Open science hardware best practices
Last updated on 2025-06-13 | Edit this page
Estimated time: 30 minutes
Overview
Questions
- What are the most popular platforms for sharing open science hardware?
- How can librarians assess if a project follows best practices?
Objectives
- Recommend platforms for finding or publishing OSH designs.
- Quickly assess a project for documentation completeness and licensing clarity.
Where do people share designs?
Open hardware designs are shared through a variety of platforms and channels, chosen depending on the project’s goals and audience.
Online code repositories such as GitHub and GitLab are among the most common spaces, offering version control, collaboration features, and easy file sharing. These repositories are the standard in software development, and will be easily accessible to some researchers but not to most of them. A good README file or website associated with the repository is necessary to ensure broad accessibility.
Some platforms like Hackaday.io or Wikifactory offer dedicated hosting for hardware designs. These are often websites where makers and scientists can showcase their work and receive feedback from peers. Specific communities, like biohacking ones, run their own Wikis. These are more accessible than repositories, but if they don’t point to them they may lack essential information (such as version control).
Academic journals also play an important role: publications such as HardwareX or the Journal of Open Hardware allow researchers to publish peer-reviewed articles that include design files and documentation. In recent years, traditional journals have started accepting open science hardware as part of their scope. This means that you may find open hardware designs for microscopy in journals such as Biomedical Optics Express.
In addition, some institutions maintain their own open access repositories, where staff and students can deposit hardware designs alongside datasets or publications. The Open Hardware Repository (OHR) at CERN is an early example of a platform where engineers and scientists share designs for scientific instruments under open licenses, making it a valuable resource for librarians seeking high-quality, peer-tested hardware documentation.
Callout
A good OSH repository makes it easy for people to upload their designs, and for others to find, understand, replicate, and contribute to the projects in it.
Checking for a good design
When assessing whether an open hardware project follows best practices, librarians can guide researchers by focusing on a few essential elements. The first and most critical is documentation.
A good open science hardware (OSH) project should include all the necessary files—such as design schematics, bills of materials (BOM), assembly instructions, and source code where relevant. This documentation should be clear, complete, and accessible to users who are not part of the original development team. Without it, the project may be difficult or impossible to reproduce.
Another key element is licensing. A project is not truly open unless it is accompanied by a recognized open license, such as the CERN Open Hardware Licence (OHL). This license ensures that users are legally permitted to reuse, adapt, and redistribute the design. Clear licensing also builds trust and signals a commitment to openness and collaboration.
Importantly, librarians should also consider the development stage of the design. Is the project an early-stage prototype, a more stable demonstrator, or a market-ready product? This distinction affects how usable the project is in practice.
A prototype may offer valuable insights but might not yet be fully documented or reproducible. A product-level design, on the other hand, should be well-tested, standardized, and ready for others to adopt with minimal modifications. Recognizing where a project sits along this spectrum helps manage expectations and guides the kind of support or caution librarians might offer to researchers exploring reuse.
Callout
Academics often reuse, develop and publish open hardware prototypes. This is because most use open science hardware to test new ideas, and appreciate the flexibility it provides. On the other hand, researchers can also be final users of open science hardware. In this case, they may not be interested in development, but looking for final products that ensure they are safe and reliable enough to generate good data.
Finally, signs of community engagement—such as active GitHub issues, user feedback, or visible updates—can indicate that a project is maintained and evolving. Evidence of testing or calibration data further strengthens confidence in the hardware’s reliability. And, as with any research tool, accessibility matters: designs that rely on widely available and affordable components are more likely to be usable across diverse settings. By combining these criteria, librarians can help researchers identify open hardware projects that are not only open in theory but truly usable in practice.
Challenge 1: Exploring OSH platforms
Choose one platform mentioned in the lesson (e.g., GitHub, Hackaday.io, OSF, or the Open Hardware Repository at CERN). Explore a few sample projects and assess the platform’s usability for non-expert users. Would a typical researcher at your institution be able to understand, access, and reuse projects hosted there? What guidance would you offer to someone considering sharing their own project on that platform?
Questions to ask before sharing
In addition to knowing where to find and evaluate open science hardware (OSH) projects, librarians can play a proactive role in helping researchers prepare their own designs for sharing. Before choosing a platform or writing documentation, researchers benefit from structured reflection on what they are sharing, why, and for whom.
Librarians can support this process by asking a few targeted questions that clarify the project’s goals and readiness. For example: Is the hardware functional and tested? Is the documentation complete and understandable to someone outside the lab? Does the researcher want community contributions, visibility, citations, or potential commercial uptake?
These early conversations can also surface issues that may otherwise go unnoticed, such as gaps in attribution, unclear licensing, or ethical concerns related to safety or misuse. For instance, a researcher may be unsure whether their design is eligible for open licensing, or may want to restrict certain uses without knowing how to reflect that in a license. Others may be unclear about whether internal documentation (lab notes, partial prototypes) should be included.
Readiness conversations are an opportunity to align expectations and introduce best practices from the start. If a researcher wants their design to be used by others, then thinking early about documentation structure, file formats, and accessibility will save effort down the line.
Basic recommendations such as using plain-language README files, ensuring bill of materials are clearly sourced, and publishing in open, editable formats can be helpful early on a project. Beyond discovery and curation of open science hardware, librarians can help researchers make their work not just open, but useful, transparent, and inclusive.
Challenge 2: Guiding compass
Based on the “Questions to ask before sharing” section, create a short guide or template with 4–6 key questions you could use when consulting with a researcher who wants to share an open hardware project. Your goal is to help them clarify their objectives, check for documentation completeness, and ensure their licensing approach matches their intentions.
- What is your goal in sharing this project?
- Who is your intended audience or user group?
- Is your documentation complete and easy to follow?
- Have you chosen an open license?
- Where will you publish or host the project?
- Are there any risks or responsibilities others should be aware of?
Key Points
- 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.
Content from Lesson 5: Connecting to open science hardware communities
Last updated on 2025-06-13 | Edit this page
Estimated time: 30 minutes
Overview
Questions
- How do researchers interact differently with OSH, as users or developers?
- Where can researchers get support and collaborate with others?
Objectives
- Understand the roles researchers play in OSH use and development
- Name key OSH communities and forums.
- Help connect researchers with peers and mentors.
Researchers’ roles in OSH: users, developers and in-between
As we’ve seen in previous lessons, researchers engage with open science hardware (OSH) in different ways—sometimes as developers creating new tools, and sometimes as users looking for ready-to-use solutions. Understanding this distinction helps librarians tailor their support, whether that means guiding a researcher through licensing and documentation or helping them assess whether an existing tool meets their needs. Two examples will help clarify these situations.
Dr. Liu: Open science hardware as a research prototype
Dr. Liu, a biomedical engineering professor, is designing a custom fluorescence imaging system to study bacterial colonies. Commercial systems are too expensive and don’t support the specific wavelengths her research requires.
To solve this, her lab builds a working prototype using open-source components: 3D-printed mounts, Arduino boards, and open-source image capture software. The system works well for testing ideas, but it’s not production-grade—it requires manual calibration and includes fragile parts.
Still, Dr. Liu considers the design to be useful and publishes the design files and experimental results on GitHub under an open license. This enables others to build on her work, refine the system, or apply it in related contexts. As a developer, Dr. Liu is contributing to the OSH ecosystem by openly sharing a prototype that reflects her research needs and invites further collaboration.
Dr. Khan: Open science hardware as a research tool
In contrast, Dr. Khan, a plant biologist, needs a reliable field-deployable system to monitor soil moisture in her drought-resistance trials. She’s not interested in designing new hardware—she wants something she can use right away with confidence in its performance.
She finds a well-documented OSH project created by another lab, complete with calibration data, a weatherproof casing, and clear instructions. Because the design is stable and has been tested in real-world conditions, she’s able to build and deploy it with minimal adaptation. In this scenario, Dr. Khan is acting as a user, relying on the maturity and reproducibility of the hardware to generate high-quality data.
Callout
Recognizing whether a researcher is seeking an adaptable prototype or a ready-to-use tool can help you provide more targeted support—whether that means pointing to appropriate repositories, helping interpret documentation quality, or guiding early-stage researchers through best practices in sharing their own designs.
Where and how to connect: Community mapping for Librarians
Open science hardware thrives in community spaces—both online and offline—where researchers, makers, educators, and activists collaborate, troubleshoot, and share ideas. As a librarian, one of the most valuable forms of support you can offer is helping researchers find the right community for their needs and stage of engagement.
Below is a short guide to some key OSH communities and platforms:
| Community / Platform | Focus | Who It’s For | How to Connect |
|---|---|---|---|
| Gathering for Open Science Hardware (GOSH) | Global community promoting OSH for science and social justice | Developers, researchers, educators | Forum, mailing list, community calls |
| Open Science Hardware Foundation (OSHF) | Stewardship of the GOSH movement, fiscal sponsorship, governance | Institutions, funders, community builders | Website, contact form, governance updates |
| OSHWA (Open Source Hardware Association) | Advocacy, policy, and certification | Designers, educators, researchers | Website, newsletter, certification directory |
| Public Lab | Community science & environmental monitoring | Activist researchers, educators, community groups | PublicLab.org, Q&A forum, open calls |
| Wikifactory | Collaborative platform for hardware design | Makers, product developers | Platform, project hosting, discussions |
| CERN Open Hardware Repository (OHR) | Scientific hardware sharing and collaboration | Scientists, engineers | OHR, Git-based repositories |
| Local makerspaces / fab labs | Prototyping tools and peer exchange | Beginners to advanced users | Local directories, Meetup, university networks |
You don’t need to be an expert in every platform to help—just knowing what exists and how to help someone navigate it is a powerful way to connect researchers to support, feedback, and collaborators.
Challenge 1: Mapping communities
Create a short referral guide or table listing 3–5 OSH communities or platforms you would feel confident pointing researchers toward. For each, describe in 1–2 sentences who it’s for, what type of support it offers, and how to connect. If you’re unsure about one, explore its website or forum and note what kind of questions are typically asked.
Any of the communities listed above, or any new ones brought by learners.
Supporting researchers to participate in OSH Communities
Even when researchers are enthusiastic about open hardware, they may be unsure how to participate in existing communities. As a librarian, you can encourage them by normalizing engagement as part of the research process and highlighting accessible entry points.
Many communities are beginner-friendly and value a wide range of contributions—not just technical expertise. A researcher might:
- Ask a question on a forum about replicating a tool.
- Comment on an open design they’ve used or tested.
- Share how they adapted an open design to a new context (e.g., for fieldwork or teaching).
- Report bugs or suggest documentation improvements.
These contributions help others and are often welcomed as meaningful engagement, even if they don’t involve new inventions. You can also encourage researchers to attend virtual gatherings or community calls, where they can meet others working on similar challenges and learn how knowledge and tools circulate outside traditional publication venues.
Reminding researchers that OSH communities are collaborative—not competitive—spaces can reduce hesitation and help build confidence. You might suggest starting with a “lurking” phase (reading discussions, reviewing existing posts), followed by small contributions, and eventually deeper participation if they feel comfortable.
Challenge 2: Libraries as hubs for open science hardware
What role does your library already play in supporting open communities? Consider your spaces, programs, and partnerships. Where might OSH fit in or expand your existing work?
Free answers
Key Points
- 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.
Content from [Visual guide] Supporting Open Science Hardware: A guide for librarians
Last updated on 2025-06-13 | Edit this page
Estimated time: 2 minutes
