Auch in English, Español中文 und Français verfügbar

Wie in der Open-Source-Hardware-Grundsatzerklärung und Definition geschildert, besteht die Essenz von Open-Source-Hardware (OSHW) im Teilen der Quelldateien eines Hardware-Produktes, so dass andere dieses Produkt (evtl. mit kommerziellen Absichten) überarbeiten oder herstellen können. Zusätzlich gibt es aber viele weitere Maßnahmen, die getroffen werden können, um die Entstehung einer lebhaften Community von Leuten zu unterstützen, die zu Ihrem Open-Source-Projekt beitragen oder dessen Ergebnissen benutzen können. Ziel dieses Dokuments ist es, diese Wege zu zeigen.

Bestandteile eines Open-Source-Hardware-Projektes

Im Folgenden finden Sie einen Überblick der Dateien, die Sie bei der Veröffentlichung Ihres Open-Source-Hardware-Projektes teilen können. Sie sind in keiner Weise verpflichtet, alle diese Daten bereitzustellen. Je mehr Informationen Sie allerdings teilen, desto mehr profitiert die Community und desto höher sind die Chancen, dass sie Ihr Projekt annimmt.

Überblick / Einleitung

Ihr Open-Source-Hardware-Projekt sollte eine allgemeine Darstellung des Zwecks und Nutzens des Produktes aufweisen. Diese Darstellung sollte so weit wie möglich für ein breites Publikum verständlich sein. Bevor Sie sich in technischen Details verlieren, erklären Sie auf einfache Weise worum es in Ihrem Projekt geht. Eine gute Abbildung oder ein Rendering kann dabei helfen.

Ursprüngliche Quelldateien

Hierbei handelt sich um die Dateien, die Sie selber benutzen würden, um weitere Änderungen Ihres Produktdesigns einzuarbeiten. Diese Dateien zu teilen ist der Kernbestandteil von Open-Source-Hardware.

Idealerweise haben Sie die Inhalten Ihres Open-Source-Hardware-Projektes mit Hilfe freier und quelloffener Software produziert, um anderen maximale Möglichkeiten zu eröffnen, diese zu betrachten und zu bearbeiten. Allerdings werden Design-Dateien oft mit proprietären Programmen generiert und in proprietären Formaten gespeichert. Auch in diesen Fällen bleibt es aber essentiell, diese Dateien zu teilen: Sie bilden den originalen „Quellcode“ des Produktes. Das sind jene Dateien, die andere brauchen werden, um Änderungen des Produktdesigns einarbeiten zu können.

Versuchen Sie, Ihre Quelldateien für andere leicht verständlich zu machen. Sortieren Sie die Dateien anhand einer logischen Systematik, kommentieren Sie komplexe Aspekte, merken Sie jede Besonderheit des Herstellungsprozesses an, usw.

Beispiele für Quelldateien sind:

  • 2D-Zeichnungen oder CAD-Dateien (von engl. computer-aided design), wie beispielsweise die Definitionsdatei eines zweidimensionalen laser-, vinyl- oder wasserstrahlgeschnittenen Teils, in ihrem ursprünglichen Bearbeitungsformat. Beispielformate: Native Formate, die von Corel Draw (.cdr), Inkscape (.svg), Adobe Illustrator (.ai), AutoCAD, usw., benutzt werden.
  • 3D-Modelle von Teilen, die 3D-gedruckt, gefräst, gegossen, durch Spritzguss, Extrusion, usw., hergestellt werden können. Beispielformate: Formate, die von SolidWorks (.sldprt, .sldasm), Rhino (.3dm), usw., benutzt werden.
  • Leiterplattendesigns wie Schaltpläne und PCB-Layouts. Beispielformate: Native Formate, die von Eagle, Altium, KiCad, gEDA, usw., benutzt werden.
  • Komponentenbibliotheken, die zur Erarbeitung der obengenannten Dateien erforderlich sind (Definition von elektronischen Symbolen oder mechanischen Verbindungen).
  • Zusätzliche technische Zeichnungen in ihren ursprünglichen Bearbeitungsformaten, falls zur Herstellung des Produktes erforderlich.
  • Zusätzliche graphische Gestaltungselemente wie Logo oder Graphiken, die auf dem Produkt angebracht werden können und zum Umfang der als open-source freigegebenen Arbeit gehören.

Ein Produktdesign, das von Anfang an in einem alternativen Format kreiert worden ist, kann eventuell als Quelldatei betrachtet werden, auch wenn es nach der im nächsten Abschnitt erläuterten Definition als Exportformat betrachtet werden kann.

Beispiele alternativer Formate, die unter Umstände als Quelldateiformate betrachtet werden können, sind:

  • Selbst geschriebener G-Code eines gefrästen Bauteils (G-Code).
  • Gescannte handgezeichnete Entwürfe (JPEG).
  • 3D-Modelle, die aus einem 3D-Scanning-Prozess gewonnen worden sind, z.B. einer handgeschnitzten Gießharzform.
  • Mit MS-Paint erstellte Layouts zum Ätzen von einseitigen Leiterplatten (PNG).

Exportformate und andere Hilfsdateien

Zusätzlich zu den ursprünglichen Quelldateien ist es oft hilfreich, das Produktdesign in anderen, zugänglicheren, Dateiformaten zu Teilen. Eine geeignete Möglichkeit wäre beispielsweise, Produktdefinitionsdateien nicht nur in ihrem ursprünglichen Bearbeitungsformat zu teilen, sondern auch in einer Reihe von Austausch- und Exportformaten, die von anderen CAD-Programme geöffnet oder importiert werden können.

Außerdem ist es hilfreich, Produktdesigns in Formaten bereitzustellen, die Endbenutzer, die die Funktionsweise des Produktes verstehen wollen, ohne sie editieren zu wollen, auf unkomplizierte Weise sichten können. Beispiele dafür sind PDF-Dateien von Schaltplänen oder STL-Dateien von dreidimensionalen Produkten. Diese zusätzlichen Produktdefinitionsdateien ermöglichen es anderen, Ihr Design zu studieren und vielleicht auch das entsprechende Produkt herstellen zu können, auch ohne Zugang zu proprietärer Software. Beachten Sie dennoch, dass zusätzliche Produktdefinitionsdateien kein Ersatz für die ursprünglichen Quelldateien sind.

Beispiele für Exportformate und andere Hilfsdateien sind:

  • In Austausch- und Exportformaten gespeicherte 2D-Zeichnungen oder CAD-Dateien. Beispielformate: PDF, JPEG, PNG, usw. (wenn möglich sollten Vektorformate gegenüber Rasterformaten bevorzugt werden).
  • In Austausch- und Exportformaten gespeicherte 3D-Zeichnungen oder CAD-Dateien. Beispielformate: STEP, IGES.
  • In speziell für die Herstellung definierten Exportformaten gespeicherte 3D-Designs. Beispielformate: G-Code, STEP-NC, STL, AMF.
  • In Austausch- und Exportformaten gespeicherte Schaltpläne. Beispielformate: EDIF, Open JSON.
  • In speziell für die Herstellung definierten Exportformaten gespeicherte Schaltpläne. Beispielformate: Gerber RS-274X, Excellon.
  • Zusätzliche technische Zeichnungen in ihren ursprünglichen Bearbeitungsformaten, und, falls für die Herstellung des Produktes notwendig, auch in allgemeinzugänglichen Formaten wie PDF gespeichert.
  • Zusätzliche Graphiken, zum Beispiel verschiedenfarbige Oberflächen eines Armaturenbretts.

Stückliste

Obwohl es theoretisch möglich wäre, aus den Quelldateien die Bestandteile eines Produktes auszulesen, ist es wichtig, eine separate Stückliste bereitzustellen. Dies kann entweder eine Tabelle (z.B. CSV, XLS, Google Docs) oder einfach eine Textdatei mit einem Bauteil pro Zeile sein. Manche CAD-Anwendungen können Stücklisten automatisch erstellen (beispielsweise Solidworks oder das Tool bom-ex in Eagle). Hilfreiche Informationen, die zu einer Stückliste gehören können, sind die Anzahl an Teilen, Hinweise zu Anbietern, Kosten und eine kurze Beschreibung jedes Bauteiles. Versuchen Sie diese Liste so zu gestalten, dass es leicht ersichtlich ist, welche Teile der Liste welchen Komponenten in der Quelldatei entsprechen: Benutzen Sie übereinstimmende Benennungen auf beiden Seiten, stellen sie Diagramme bereit, die darauf hinweisen, welches Teil wo hingehört, oder erklären Sie die Entsprechungen.

Software and Firmware

Sie sollten jeglichen Quellcode oder Firmware teilen, die für das Funktionieren Ihres Produktes gebraucht wird. Dies ermöglicht es anderen, die Software für ihre Produkte zu benutzen oder sie während dem Ändern ihres Produktes anzupassen. Dokumentieren Sie den Erstellungsprozess (build) Ihrer Software, ohne mögliche Abhängigkeiten von z.B. Drittpartei-Bibliotheken oder Tools zu vergessen. Darüber hinaus ist es hilfreich, einen Überblick des Entwicklungsstands der Software zu verschaffen (z.B. „stabile“, „beta“ oder „kaum funktionierendes Hack“).

Abbildungen

Abbildungen helfen anderen Ihr Projekt zu verstehen und Ihr Produkt zusammenzubauen. Es ist generell gut, Fotos Ihres Produktes aus unterschiedlichen Perspektiven und verschiedener Montageschritte zu veröffentlichen. Wenn Sie keine Fotos zur Verfügung haben, sind 3D-Renderings Ihres Designs eine gute Alternative. So oder so ist es gut, Beschriftungen oder Texte bereitzustellen, die erklären, was in jeder Abbildung gezeigt wird und was daran hilfreich ist.

Anleitungen und andere Erklärungen

Zusätzlich zu den Quelldateien gibt es eine Vielfalt an unterschiedlichen Erklärungen, die anderen unschätzbare Hilfe schaffen, um Ihr Produkt zu replizieren oder zu verändern:

Das Produkt replizieren. Um anderen zu helfen, Ihr Produkt herzustellen und zu verändern, sollten Sie Anleitungen bereitstellen, die den Weg von der Quelldatei zum funktionierenden Produkt erklären. Dazu gehört, die Datenblätter mit den Bauteilen des Produktes zu verlinken und die Werkzeuge, die zur Montage benötigt werden, aufzulisten. Wenn die Herstellung des Produktes spezielle Werkzeuge erfordert, informieren Sie andere, wie diese sie zu finden sind.

Das Produkt benutzen. Nach erfolgreicher Herstellung muss man auch wissen, wie sich das Produkt bedienen lässt. Stellen Sie Anleitungen bereit, die erklären, was das Produkt kann, wie es eingestellt werden sollte und wie man damit interagieren kann.

Unterlegende Logik des Designs. Wenn jemand Ihr Produktdesign verändern will, muss er oder sie wissen, warum es ist wie es ist. Erklären Sie die Gesamtstruktur des Produktdesigns und warum Sie ausgerechnet die Entscheidungen getroffen haben, die sie getroffen haben.

Dabei sollten Sie nicht aus den Augen verlieren, dass diese Anleitungen von Leuten gelesen werden, deren Erfahrungen und Ausbildung von der Ihren abweichen mögen. Bemühen Sie sich, soweit es geht, für ein breites Publikum zu schreiben. Versuchen Sie, Fachjargon zu vermeiden. Stellen Sie explizit dar, von welchen Vorkenntnissen Sie ausgehen.

Die Anleitungen können in unterschiedlichen Formaten gespeichert werden, wie beispielsweise in einem Wiki, einem Google Doc oder als PDF-Datei. Beachten Sie jedoch, dass andere möglicherweise Ihre Anleitungen nach Änderung Ihres Designs entsprechend anpassen möchten. Demnach ist es gut, die Originaldateien Ihrer Dokumentation in ihren ursprünglichen Bearbeitungsformaten zur Verfügung zu stellen, nicht nur in Exportformaten wie PDF.

Open-Source-Hardware Prozesse und Vorgehensweisen

Entwicklung

Bei der Open-Source-Veröffentlichung Ihres Produktes können Sie es durch die folgenden Hinweise einfacher für andere machen, das Produkt zu bauen und zu verändern:

  • Benutzen Sie, wenn möglich, freie und quelloffene CAD-Anwendungen. Wenn dies nicht möglich ist, versuchen Sie, günstige oder weit verbreitete Software zu benutzen.
  • Benutzen Sie normierte und allgemein erhältliche Komponenten, Materialien und Herstellungsprozesse. Bemühen Sie sich, Bauteile zu vermeiden, die nicht von Privatkunden beschafft werden können, sowie Prozesse, die erhebliche Einrichtungskosten erfordern.

Speicherort Ihrer Quelldateien

Ein einfacher Weg, Ihre Dateien zur Verfügung zu stellen, ist, das Herunterladen einer Zip-Datei auf Ihrer Webseite anzubieten. Das ist zwar ein toller Anfang, allerdings ermöglicht dies nicht, dass andere Ihre Fortschritte verfolgen oder dazu beitragen können.

Für das Speichern der Dateien Ihres Open-Source-Projektes empfehlen wir die Benutzung von OnlineRepositories wie GitHub, Gitorious oder Google Code. Alle Dateien (Quelldateien, Stücklisten, Montageanleitungen, Quellcode, usw.) sollten wenn möglich Versions-kontrollierbar sein. Wenn Sie vorhaben, Ihr Produkt öffentlich zu entwickeln, werden diese OnlineRepositories Ihnen helfen, Ihre Fortschritte nach und nach öffentlich zu machen. Außerdem können Sie Updates in Verbindung mit Veröffentlichungen des Produktes posten.

Die meisten OnlineRepositories betten Issue Trackers ein. Diese Werkzeuge sind dabei hilfreich, den Überblick über Bugs und künftige Verbesserungen Ihrer Software zu behalten. Dadurch werden anderen befähigt, diese zu sehen und zu kommentieren. Manche Anwendungen beinhalten auch Wikis, in denen das Projekt dokumentiert werden kann.

Als Alternative zu OnlineRepositories können Sie Ihr Projekt in OnlineCAD-Anwendungen wie Upwerter verwirklichen. Alternativ können Sie Ihre Dateien auch auf Seiten wie Thingiverse teilen.

Designs lizenzieren

Obwohl Lizenzierung ein komplexes Thema ist, ist es wichtig, Lizenzen zu benutzen, um zu signalisieren, wie andere Ihre Arbeiten benutzen sollen. Durch die explizite Festlegung einer Open-Source-Lizenz für Ihre Produktdefinitionsdateien und für den Rest der Dokumentation verdeutlichen Sie, dass diese Informationen kopiert und geändert werden dürfen. Beachten Sie bei der Lizenzierung Ihres Projektes, dass jemand, der eine neue Version Ihres Produktes entwickelt, wahrscheinlich auch Ihre Software, Anleitungen und andere Dokumentation weiterentwickeln wollen wird. Daher sollten Sie nicht nur die Hardware-Quelldateien als open-source lizenzieren, sondern auch diese anderen Elemente Ihres Projektes.

Beachten Sie, dass Urheberrecht (worauf die meisten Lizenzen bauen) nicht für die Hardware-Produkte selbst gelten, sondern nur für deren Produktdefinitionsdaten und selbst dabei nur für die Elemente, die „originale Werke im Sinne der Urheberschaft“ (im U.S.-amerikanischen Gesetz) bilden und keinesfalls die dadurch beschriebenen zugrundeliegenden Funktionalitäten oder Ideen. Somit ist der Umfang des gesetzlich gewährleisteten Schutzes durch Lizenzen nicht ganz klar. Trotzdem sind diese Lizenzen wichtig, um zu verdeutlichen, welche Freiheiten Sie anderen bei der Benutzung Ihrer Designs einräumen wollen.

Es gibt grundsätzlich zwei Klassen von Open-Source- und Free-Software-Lizenzen. Die sog. copyleft (oder auch viralen) Lizenzen erfordern, dass Überarbeitungen unter gleichen Bedingungen lizenziert werden. Die permissiven Lizenzen hingegen erlauben es anderen, Überarbeitungen durchzuführen, ohne diese als Open-Source-Hardware weiter zu lizenzieren. Beachten Sie, dass die Definition von Open-Source-Hardware spezifiziert, dass Sie Überarbeitungen und kommerzielle Anwendungen Ihres Designs erlauben müssen. Demzufolge dürfen Sie Lizenzen, die Klausen zur Verbietung weiterer Bearbeitungen und kommerzieller Anwendungen enthalten, nicht benutzen.

Beispiele verbreiteter Copyleft-Lizenzen sind:

  • Creative Commons mit Namensnennung und Weitergabe unter gleichen Bedingungen (CC-BY-SA)

Beispiele verbreiteter permissiver Lizenzen sind:

Ein gutes Verfahren ist es, Quelldateien mit einer Kopie des Lizenzvertrages sowie ein README beizufügen, in dem die Autoren der nichttrivialen Änderungen sowie die Lizenz benannt werden. Am besten ist es, die Informationen zur Lizenz und Autoren in jeder Datei einzubetten.

Open-SourceHardware verbreiten

  • Vermerken Sie den Link zu den Quelldateien entweder auf dem Produkt selbst, auf der Verpackung oder in der Dokumentation.
  • Sorgen Sie dafür, dass es einfach ist, die Quelldateien auf der Webseite des Produktes zu finden.
  • Beschriften Sie das Produkt mit einer Versionsnummer oder einem Release-Datum, um die Identifikation der Dokumentation, die mit dem Hardware-Produkt übereinstimmt, zu ermöglichen.
  • Benutzen Sie das Logo der Open-Source-Hardware auf Ihrem Produkt. Sorgen Sie dafür, dass klar erkennbar ist, auf welchen Teil des Produktes das Logo verweist (d.h. welche Teile open-source sind.
  • Machen Sie generell klare Angaben dazu, welche Teile des Produktes open-source sind und welche nicht.
  • Bezeichnen Sie kein Produkt als open-source, solange die dazugehörigen Quelldateien nicht zugänglich sind. Wenn Sie vorhaben, das Produkt künftig als open-source zu veröffentlichen, kommunizieren Sie das stattdessen so.

Auf Open-Source-Hardware bauen

  • Respektieren Sie das Urheberrecht von anderen.
  • Obwohl eine direkte kommerzielle Verwendung verfügbarer Open-Source-Hardware explizit zugelassen ist, ist es besser—wenn möglich—vor der Vermarktung des Produktes nützliche Verbesserungen des Designs einzuarbeiten und erst die verbesserte Version als Open-Source-Hardware zu veröffentlichen.
  • Teilen Sie dem Urheber des ursprünglichen Produktes Ihre Änderungen und Verbesserungen mit.
  • Seien Sie emotional darauf vorbereitet, das Kopieren Ihres Projektes zu erlauben (außer wenn es um einer Verletzung Ihrer Schutzmarke geht: in diesem Fall handeln Sie dem Markenrecht entsprechend).

Letzte Änderungen: 18. April 2013, von dem OSHWA-Emailverteiler, von David A. Mellis koordiniert.

Initiale Version (English): 21. November 2012, von Nathan Seidle und dem OSHWA-Emailverteiler.

Übersetzung aus dem Englischen : 20 Juli 2017 von Jérémy Bonvoisin und Kerstin Carola Schmidt.

Dieses Werk ist mit einer Creative-Commons-Lizenz mit Namensnennung und Weitergabe unter gleichen Bedingungen lizensiert.