Instructor Notes
These notes come from the first in-person run of the course (HU Berlin library, morning of 2026-09-24) and the feedback gathered afterwards. Items marked to confirm are proposals that have not yet been checked against how long the Berlin run actually took.
Who the course is for
The course is written for librarians, not for researchers or engineers. In Berlin, participants knew metadata, versioning, knowledge management and long-term preservation well, and knew little about engineering, the hardware life cycle, or quality control. Start from what they know and say clearly, early, why the course is for librarians. See the learner profiles for examples of who to expect.
Pacing and time
Each episode is currently listed with 20 minutes of teaching and 10
minutes of exercises, so the five episodes add up to about 2.5 hours
before breaks, introductions and feedback. The listed times have not
been checked against a real run. To confirm: compare
them with the Berlin timings and update the teaching: and
exercises: values in each episode.
Suggested structure for a half-day session (to confirm):
| Block | Content | Notes |
|---|---|---|
| Opening | Icebreaker and introduction | Keep the icebreaker to 30 minutes at most |
| Episodes 1 to 3 | Introduction, how OSH works, licensing | Short break after the licensing episode |
| Feedback check-in | Short group discussion | See below |
| Episodes 4 and 5 | Best practices, communities | |
| Close | Questions and written feedback |
Icebreaker
Open with questions that start from what participants know: “What do you work on? What do you know about open science hardware? What do you think it is?” Take no more than 30 minutes. Use the answers to link back to things the group already knows, such as open data, open software and git forges, science communication, patents and licensing, and the local research community.
Breaks and feedback sessions
Plan at least one break and one feedback check-in. Berlin participants suggested making these explicit, so decide in advance when they happen and how long they last, and tell the group at the start. A check-in can be as simple as asking what is unclear so far and what the group wants more of. To confirm: when and how long they ran in Berlin, and what worked.
Discussion prompts
- In the licensing episode, ask: “What do you currently tell your researchers about licensing?” The answers show where participants already advise on licenses and where they are unsure.
- When discussing why researchers hesitate to share, note that “open” can feel risky because of fear of being scooped, and that being cited can be a strong incentive.
Course length options
The course can run as a three-hour beginner course, or as a longer or more advanced course. Participants in Berlin suggested this split, and the beginner version could still cover all five episodes at an introductory level. Licensing in particular is covered at introductory depth and could be a separate course.
Invite a project developer
If you can, invite the developer of an open science hardware project to join a session live. Hearing how a real project was built, documented and shared makes the topics concrete, and the complete story of a project can also stand alone as a case study. This is a suggestion from the Berlin run, not yet part of the course.
Introduction: What is open science hardware?
Instructor Note
Keep this to about 8 minutes in total. It is a warm-up, not a lesson. Participants add what they know, and you do not define terms for them.
Before the session. Create a shared document that participants can edit without logging in, and paste in the term list below. Leave one empty line under each term.
Term list to copy and paste:
Open source:
Open science hardware (OSH):
FAIR:
Prototype:
Bill of materials (BOM):
Firmware:
Copyleft:
Fork / remix:
Calibration:
OSHWA:Edit the list if your group differs. A mix of terms participants probably know (open source, FAIR) and probably do not (firmware, copyleft, BOM) works best.
Running it.
- Share the link and show a timer. Give 3 minutes to add definitions and “?” marks.
- Spend 3 to 4 minutes on the terms with the most “?” marks. Read each one out and ask: “Does anyone want to take this one?” Do not define terms yourself unless nobody can.
- Leave anything unresolved as “?”. Say that each term gets explained in the episodes.
- Keep the document open. Point back to it when a term comes up, and ask the group to add to it during the course.
Keeping it short. Cap the skim at the timer, whatever is left. Do not go through every term, do not correct partial answers at length, and do not let one term turn into a discussion. If the group is enjoying it, offer to continue during a break.
Optional follow-up. At the end of the course, return to the document and ask what changed, and what the group would add or fix.
Instructor Note
This section is good for learners to exchange their own experience with science
Lesson 2: How does open science hardware work?
Lesson 3: licenses and open science hardware
Instructor Note
Before moving on, ask the group: “What do you currently tell your researchers about licensing?” Use the answers to see where participants already advise on licenses and where they are unsure.