Open Hardware Design Guide

Open Hardware ist vor allem eine gute Dokumentation. Doch wie sieht die aus? Auf diese Frage gehen wir hier ein und bauen Stück für Stück einen Design Guide – kurz und knapp.

Inhalt

Erste Schritte

Für eine gute Dokumentation muss du dir vor allem zwei Fragen stellen: Für wen ist die Dokumentation bestimmt? Und welche Informationen benötigt diese Person, um meine Hardware verstehen und reproduzieren zu können?

Der Grund liegt auf der Hand: Es macht einen großen Unterschied, ob du für technisch Versierte dokumentierst oder für Laien.

Folgende Fragen solltest du dir außerdem stellen

  • Wie kann ich meine Dokumentation zielgruppengerecht darstellen?
  • Wie möchte ich das Projekt zukünftig gestalten? Suche ich nach Mitentwickelnden?
  • Wo soll die Dokumentation veröffentlicht werden, brauche / möchte ich ein Versions-Kontroll-System? Wir empfehlen ein solches Tool. Dafür eignen sich z.B. MediaWiki, GitLab oder GitHub.
  • Wenn ich Beteiligung an der Entwicklung wünsche: Wie genau können Menschen beitragen? Wo wird kommuniziert? An welcher Stelle hole ich Beitragende ab?

Eine ideale Dokumentation enthält

  • eine Übersicht über das Hardware-Projekt: Um was geht es, welches Problem löst es, an wen richtet sich die Dokumentation, was ist in ihr zu finden und welche Werkzeuge und Maschinen werden benötigt. Außerdem: Wie können sich andere beteiligen?
  • eine Liste (Bill of Materials – BOM) der verwendeten Materialien, die folgende Aspekte enthält: Typenbezeichnung oder allgemeine Beschreibung, Stückzahl, Preis, wo können die Teile erworben werden und zu welche Komponente deines Projektes gehören sie?
  • sämtliche orginale Designs bzw. CAD-Zeichnungen (z.B. technische Zeichnungen, 3D-Modelle, elektrotechnische Designs), die für die Reproduktion und Anpassung des Objektes notwendig sind. Die Zeichnungen sollten als Projektdatei bzw. Austauschformat sowie finaler Konstruktionsdatei (z.B. STL, PDF, DXF, OBJ, GBR) vorliegen. Idealerweise wird für die Erstellung eine Open Source Software verwendet.
  • eine bebilderte Montageanleitung (z.B. auch als Video), die in einzelnen Schritten zeigt (und durch kurze Texte erklärt) wie alle Einzelteile zusammengefügt werden. Die Anleitung sollte editierbar sein und z.B. nicht als formatiertes PDF vorliegen.
  • eine passende Lizenz, unter der die Dokumentation verwendet werden kann und die die Open Hardware Definition erfüllt.

Gute Beispiele und was sie ausmacht

  • Precious Plastic ist ein wunderbares Community-Projekt. Die Gruppe hat es geschafft, weltweit Menschen zu erreichen, die ihre eigenen Maschinen bauen und nutzen. Das gelingt ihnen sicherlich durch das Thema: Plastikmüll ist ein drängendes Problem. Aber es ist besonders auch die Doku, die dazu einlädt, mitzumachen. Dabei arbeiten sie mit einem ansprechenden Design, einer klaren Struktur und vor allem: Videos. Mit ihnen führen sie erst allgemein ins Thema ein und zeigen auch jeweils, wie die einzelnen Maschinen gebaut werden. Mit allen weiteren notwendigen Details, wie Materialliste und 3D-Modell, gibt es auch ein Troubleshooting und Infos für den Betrieb der Maschinen.
  • Der Lasersaur zeigt besonders gut wie mit Hilfe von CAD-Zeichnungen eine Schritt-für-Schritt-Anleitung für den Zusammenbau aussehen kann. Außerdem ist das Projekt ein gutes Beispiel, wie eine übersichtliche Dokumentation mit Hilfe der Kombination aus Github und Wiki aussehen kann.
  • Der MNT Reform Notebook ist ein sehr umfangreiches Projekt, mit einer internationalen Community. Es ist ein gutes Beispiel, weil es mit der damit verbundenen Komplexität gut umgeht. Außerdem wurden zahlreiche Maßnahmen getroffen, um es anderen möglichst leicht zu machen, sich am Projekt zu beteiligen (Onboarding).

Das sollte bei der Prototypenentwicklung beachtet werden

  • Dokumentiere jeden Versuch, zu deinem Ziel zu gelangen. Das können Fotos, Videos oder CAD-Zeichnungen sein sowie kleine Aufzeichnungen deiner Erfahrungen. Möglicherweise kommt dein Projekt im Laufe der Entwicklung zum Erliegen. Die Schritte, die du bis dahin unternommen hast, sind aber für andere interessant, die es ebenfalls versuchen möchten. Teile dieses Wissen unbedingt – auch wenn es nur ein kleiner Blogartikel ist.
  • Veröffentliche dein Projekt frühzeitig und nicht erst, wenn du der Meinung bist, dass endlich alles vollständig ist. Denn diesen Punkt erreichst du wahrscheinlich nie. So können andere leichter unterstützen und du während des Prozesses bereits Interessierte einbinden.
  • Nutze, wenn möglich, Teile und Materialien, zu denen andere ebenfalls Zugang haben. Das sind z.B. Normteile aus dem Baumarkt.
  • Wenn du Material sparen möchtest, indem du auf Vorhandenes zurückgreifen möchtest, beschreibe, was die Teile allgemein ausmacht, die du verwendet hast, damit Dritte geeignete Alternativen finden können.

Die richtige Lizenz wählen

Grundsätzlich ist es so, dass alles, was du als Text (auch Code), Video oder Audio veröffentlichst, in Deutschland dem Urheberrecht unterliegt. Mit einer Lizenz gibst du anderen die Möglichkeit, die Dokumente rechtssicher zu nutzen. Bei physischen Objekten ist es anders. Ein von dir gebauter Gegenstand kann von allen nachgebaut werden. Um das zu verhindern, wurden Patente und Geschmacks- / Designmuster entwickelt. Da Open Hardware insbesondere auch eine umfangreiche Dokumentation bedeutet, müssen bei der Veröffentlichung beide Sphären berücksichtigen.

Grundsätzlich handelt es sich nur dann um Open Source Hardware, wenn folgende Definition erfüllt ist:

„Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design.” CC-BY-SA 4.0 OSHWA

Patentierbar sind nur Dinge, die noch nicht zum Stand der Technik gehören. Veröffentlichst du eine umfangreiche Dokumentation, dann gehört sie zum Stand der Technik und kann damit eigentlich nicht mehr patentiert werden.

Lizenzierung: So geht’s

Im Prinzip musst du dir zwei Fragen stellen:

  • Gibt es neben Bildern und Texten auch Code?
    Dann musst du ggf. eine Kombination aus Lizenzen verwenden, um den Code unter gleichen Bedingungen zu veröffentlichen. Denn oft werden Bibliotheken benutzt, die schon bestimmte Lizenzen mitsichbringen.
  • Möchte ich mein Projekt patentieren?
    Für eine Patentierung kann es unterschiedliche Gründe geben. Für Open Hardware ist es erst mal nicht erforderlich – kann aber, je nach Technologie, die Offenheit sichern. Wenn ihr euch für ein Patent entscheidet, solltet ihr in jedem Fall eine der CERN OHL Lizenzen wählen, da diese Lizenz potenziellen Nutzenden zusichert, dass ihr sie nicht wegen Patentrechtsverletzungen verklagen werdet. Diese Option decken die Creative Commons Lizenzen nicht ab und sind damit nicht mit Patenten kompatibel.

Wenn ihr beide Fragen mit “nein” beantworten könnt, dann reicht es völlig aus, wenn ihr euer Projekt unter einer mit der Open Hardware Definition kompatiblen Lizenz veröffentlicht, wie den Creative Commons Lizenzen CC BY 4.0 oder CC BY-SA 4.0.
Es ist also eine entsprechende Lizenz zu wählen, die das erfüllt. Am gängistens sind die Creative Commons und die CERN OHL.

Lizenzierung: So geht’s nicht – “Open Washing”

Es gibt weitestgehend Einigkeit innerhalb der Community, dass die OSHWA Definition gilt, wenn du dein Projekt Open Hardware nennst (oder vom PFH gefördert wirst). Stellst du deine Dokumentation z.b. unter eine Non-Commercial Creative Commons Lizenz und bezeichnest dein Projekt als Open Hardware, dann ist Unmut vorprogrammiert. Das ist dann in etwa so, wie ein Biolabel auf Milch aus konventioneller Landwirtschaft zu drucken. Mehr dazu erfährst du im Blogartikel Why are Creative Commons ‘Non Commercial’ licenses not Open Source and a big problem for hardware & product design.

Selbsteinschätzung, Review und Zertifizierung

Es gibt verschiedene Möglichkeiten, wie du selbst oder andere dein Projekt als Open Hardware und die Dokumentation auf Praxistauglichkeit klassifizieren können. Einen ersten Schritt kann du mit dem Open-o-Meter gehen (siehe unten). Noch besser ist es, wenn du anderen deine Dokumentation und Material explizit für das Testen zur Verfügung stellst. Das kannst du selbst organisieren oder dich von anderen unterstützen lassen, wie der Open Source Ecology Germany Community. Zur Verbesserung solcher Prozesse wurde mit der DIN Spec 3105 ein Standard entwickelt, an dem du dich orientieren kannst.

Schätze dein Projekt selbst ein: das Open-o-Meter

Was definiert ein Open-Source-Hardwareprodukt? Welche Anforderungen müssen erfüllt sein, damit ein Produkt als Open Source bezeichnet werden kann? Und wie lassen sich Open-Source-Produkte in Bezug auf Offenheit vergleichen? Das Open-o-Meter will diese Fragen mit Hilfe einer Open-Source-Skala beantworten. Entwickelt wurde es durch das Projekt “OPEN! Methods and tools for community-based product development”.

Das Open-o-Meter ist eine einfache Skala von 0 bis 8, bei der ein Produkt einen Punkt für jeden der folgenden Aspekte erhält

  • Designdateien werden veröffentlicht
  • Montageanleitungen werden veröffentlicht
  • eine Stückliste wird veröffentlicht
  • wird ein Beitragsleitfaden veröffentlicht
  • Veröffentlichte Dateien werden im Originalformat freigegeben
  • Verwendung eines Versionierungssystems
  • Verwendung eines Issue Management Systems
  • Veröffentlichung der Informationen unter einer Lizenz, die eine kommerzielle Weiterverwendung ermöglicht

So funktioniert es:

  • Wenn ein Produkt 8 Punkte erhält, entspricht es den Best Practices der Open Source Hardware.
  • Wenn ein Produkt 0 Punkte erhält, scheint es überhaupt nicht offen zu sein und sollte nicht als Open Source bezeichnet werden.
  • Wenn ein Produkt zwischen 1 und 7 liegt, ist es auf dem Weg!

Weiterführende Links / Themen