Einleitung

Open Source Hardware (OSH) bezeichnet greifbare Produkte, deren Konstruktions‑ und Fertigungsdaten – z. B. Schaltpläne, CAD‑Modelle, Stücklisten, Montage‑ und Prüfanleitungen – öffentlich und frei zugänglich sind. Jede:r darf diese Daten studieren, verändern, weiterverbreiten und daraus eigene Geräte herstellen oder verkaufen.

Das Arbeiten mit OSH folgt den Prinzipien Offenheit, Transparenz und Nachvollziehbarkeit. Durch die vollständige Offenlegung von Design‑, Produktions‑ und Testinformationen wird nicht nur die Reproduzierbarkeit wissenschaftlicher Ergebnisse gesichert, sondern auch ein nachhaltiger Innovationszyklus geschaffen: Dritte können Designs übernehmen, verbessern und weiterentwickeln. Dieser gemeinschaftsorientierte Ansatz ist ein zentraler Motor für neue technische Lösungen.

Der Erfolg einer OSH‑Entwicklung hängt jedoch nicht ausschließlich vom rein technischen Design ab. Gleichwertig wichtig sind Fragen der Dokumentationsqualität, Lizenzwahl, Finanzierung und Community‑Betreuung. Fehlentscheidungen in diesen Bereichen treten häufig erst spät im Projekt auf und können die Weiterverwendung oder Kommerzialisierung gefährden.

Ziel dieses Leitfadens ist es, Forschenden, Entwickler:innen, Transfer‑ und Technologiemanagement‑Einheiten sowie Industriepartner:innen eine praxisorientierte Unterstützung zu bieten. Er behandelt rechtliche, technische und geschäftliche Aspekte systematisch und liefert Werkzeuge, um nachhaltige, breit nutzbare OSH‑Projekte aufzusetzen und zu betreiben.

Der beschriebene Ablauf ist bewusst iterativ gestaltet: einzelne Schritte können parallel laufen, wiederholt oder angepasst werden, sobald neue Erkenntnisse oder veränderte Rahmenbedingungen auftreten.

Der Leitfaden richtet sich an alle Akteur:innen, die Open‑Source‑Hardware im Rahmen von Open‑Science‑Initiativen entwickeln, veröffentlichen und ggf. kommerziell nutzen wollen – unabhängig davon, ob sie an Forschungseinrichtungen, Hochschulen, Unternehmen, Start‑Ups oder anderen Organisationen tätig sind.

Der Weg zur Verwertung als Open-Source-Hardware

Bedarf und Motivation

Der Bedarf an neuer Hardware entsteht in Laboren, Produktionsstätten, Lehrumgebungen oder im Feld: Es fehlt ein Messgerät, ein Adapter, eine Steuerungseinheit oder ein komplett neu zu entwickelndes System. Gleichzeitig besteht oft der Wunsch, durch die Entwicklung einen Mehrwert zu schaffen und die Ergebnisse offen zu teilen – sei es zur Beschleunigung der Wissenschaft, zur Stärkung der Lehre oder zur Erschließung neuer Märkte.

Projektstart und Anforderungsanalyse

Jedes Projekt beginnt mit einer klaren Idee und einem definierten Ziel: Die zu entwickelnde Hardware soll ein konkretes Problem lösen. Die Entwickler:innen formulieren dabei

• funktionale und leistungsbezogene Anforderungen (z. B. Messgenauigkeit, Datenrate, Größe, Energiebedarf),

• Anwendungsparameter (Labor‑, Feld‑ oder Produktionsumgebung, vorhandene Infrastruktur) und

• den erwarteten Mehrwert (z. B. präzisere Messungen, höhere Durchsatzrate, geringere Kosten).

Eine realistische Risiko‑ und Machbarkeitsabschätzung ist dabei unverzichtbar.

• Technische Machbarkeit – Verfügbarkeit der Bauteile, Kompatibilität mit vorhandener Hardware, notwendige Fertigungsverfahren.

• IP‑Situation – Patente, Marken oder Lizenzbedingungen für einzelne Komponenten oder Software; dürfen sie im Open‑Source‑Kontext verwendet werden?

• Finanzielle Risiken – Beschaffungs‑ und Herstellungskosten im Vergleich zum Budget, Gefahr von Lieferengpässen oder Preisschwankungen.

• Zeitliche Risiken – Aufwand für Design, Prototyping, Test und Dokumentation; kritische Meilensteine.

• Regulatorische Risiken – Exportkontrollen, REACH‑/RoHS‑Vorschriften, CE‑Kennzeichnung, Produkthaftungsaspekte.

Kooperation und Weg zur Verwertung

Der Weg zur Verwertung einer Open Source Hardware sollte frühzeitig gemeinsam mit Transfermanager:innen und/oder einem Open Source Program Office (OSPO) beschritten werden. Diese unterstützen bei der Klärung offener Fragen zu Lizenzen, Schutzrechten und Geschäftsmodellen. Ein strukturierter Prozess von Anfang an vermeidet spätere Konflikte und sichert die Nachhaltigkeit des Projekts.

Potenzialanalyse

Um zu beurteilen, wie weit der Entwicklungsstand eines Hardwarevorhabens ist sowie ob und wie gut es für Open Source geeignet ist bzw. an welcher Stelle noch Handlungsbedarf besteht, wurde ein digitales Tool zur Bewertung des Potenzials erarbeitet. (Aufbauend auf dem Bewertungsschema und dem zugehörigen Excel-Tool »Potenzialanalyse – Bewertung des Verwertungspotenzials von Forschungssoftware« des SoftWert-Konsortiums. → www.SoftWert.org)

Dafür werden Dimensionen wie Charakteristika der Hardware selbst, das Entwicklungsteam und Nebenbedingungen der Forschungseinrichtung, aber auch der potenzielle Markt und das Potenzial für eine Ausgründung berücksichtigt. Die zugehörigen Fragen sind auf die Spezifika der das Tool nutzenden Einrichtung anpassbar.

Das Tool kann unter diesem Link heruntergeladen werden: EXCEL-TOOL Potenzialanalyse OSH

Eine ausführliche Anleitung finden Sie hier: Anleitung Potenzialanalyse OSH

Für die Nutzung ist Microsoft Excel notwendig. Die Fragen können in einem gewissen Umfang noch an die Spezifik eines Projektes oder die besonderen Erfordernisse einer Organisation angepasst werden.

Der Lebenszyklus eines Open-Source-Hardware-Projekts

Die Entwicklung von OSH ist kein lineares Vorgehen, sondern ein iterativer, feedbackgesteuerter Prozess, bei dem technische, rechtliche und geschäftliche Aspekte parallel bearbeitet werden. Die nachstehenden Phasen bilden einen orientierenden Rahmen; Übergänge sind fließend und Rückkopplungen jederzeit möglich.

Phase 1: Strategie und Entscheidung

Bevor mit der technischen Entwicklung begonnen wird, müssen die grundlegenden Weichen gestellt werden.

• Entscheidung „Open oder proprietär“ – Klärung, ob das Projekt als Open‑Source‑Hardware veröffentlicht werden soll oder ein proprietäres Geschäftsmodell verfolgt wird.

• Rechtliche Rahmenbedingungen – Prüfung von Exportkontrollen, bestehenden Schutzrechten und Haftungsfragen; Einbeziehung aller Rechteinhaber (Mitentwickler:innen).

• Lizenzwahl und Geschäftsmodell – Gemeinsame Festlegung einer passenden OSH‑Lizenz (z. B. Copyleft vs. permissiv) und des damit verbundenen Geschäftsmodells, da die Lizenz die zulässigen kommerziellen Nutzungsmöglichkeiten maßgeblich bestimmt.

Phase 2: Technische Umsetzung

In dieser Phase findet die eigentliche Entwicklung statt, wobei die Dokumentation von Anfang an mitgedacht wird.

• Technologie und Herstellverfahren – Auswahl der eingesetzten Hardware‑ und Software‑Technologien sowie der geeigneten Produktionsmethoden (z. B. 3‑D‑Druck, CNC‑Fräsen, Serienfertigung).

• Technische Dokumentation – Vollständige Erfassung aller Konstruktions‑ und Fertigungsdaten (Schaltpläne, CAD‑Dateien, Stücklisten, Montage‑ und Prüfanleitungen) in einer Form, die Dritte einen sicheren Nachbau und Betrieb ermöglicht.

Phase 3: Publikation, Distribution und Community

Die Veröffentlichung ist kein Endpunkt, sondern der Start einer neuen Phase.

• Publikation und Distribution – Festlegung, auf welchen Plattformen (z. B. GitHub, OSHWA‑Registry, Zenodo) die Daten bereitgestellt und wie sie dauerhaft zugänglich gemacht werden (z. B. DOI).

• Community‑Aufbau – Definition von Mechanismen zur Einholung von Feedback, zum Onboarding neuer Mitentwickler:innen und zur Moderation der Community.

• Betrieb – Umsetzung des gewählten Geschäftsmodells und Sicherstellung einer langfristigen Wartung und Weiterentwicklung des Projekts.

Praktischer Hinweis für den Projektstart

• Nicht alle Themen müssen zu Beginn vollständig geklärt sein – aber insbesondere nicht‑technische Fragen (Lizenz, Finanzierung, Community‑Management) werden in der Praxis häufig zu spät behandelt.

• Damit das Entwicklungsteam die Zügel selbst in die Hand nimmt, empfiehlt es sich, bereits zu Projektbeginn die einzelnen Themen kurz zu durchdenken und eine projektbezogene Zeitplanung zu erstellen, in der festgelegt wird, wann welche Entscheidung getroffen werden kann.

• Je nach Organisation gibt es unterschiedliche Unterstützungsangebote:

• ein bereits bestehendes Open‑Source‑Program‑Office (OSPO),

• die für Wissens‑ und Technologietransfer zuständige Struktureinheit,

• erfahrene Kolleg:innen aus anderen Fachbereichen, die bereits mit Open‑Source‑Projekten gearbeitet haben.