Open-Source-Hardware ist weder die Universal-Lösung, die manche aus der Maker-Community proklamieren, noch das IP-Lecksystem, vor dem klassische Industrieunternehmen warnen. Es ist eine strategische Wahl, die in bestimmten Konstellationen klar überlegen ist und in anderen klar unterlegen. Entscheidend ist die ehrliche Antwort auf eine einzige Frage: Wo liegt mein eigentlicher Moat, in der Hardware selbst oder im Service drumherum? Wer Service, Beratung und Vertrauen verkauft, fährt mit Open Source oft besser. Wer eine patentierbare Schlüsselinnovation auf Schaltungsebene hat, im Allgemeinen nicht.
Der häufigste Einwand gegen Open-Source-Hardware und warum er unvollständig ist
„Wir wollen ein eigenes Hardwareprodukt bauen, aber Open Source kommt für uns nicht in Frage. Wir verlieren ja unser IP."
Diesen Satz hören wir in Erstgesprächen oft. Er ist nicht falsch, aber unvollständig. In der Realität ist Open-Source-Hardware weder die universelle Lösung, die manche aus der Maker-Community proklamieren, noch das IP-Lecksystem, vor dem klassische Industrieunternehmen warnen. Es ist eine strategische Entscheidung, die in manchen Konstellationen klar überlegen ist und in anderen klar unterlegen.
In diesem Artikel beschreiben wir am Beispiel des Open-Source-Hardwareprodukts BadUSB, das wir gemeinsam mit der österreichischen Cybersecurity-Firma BYTEBOLT entwickelt haben (BYTEBOLT vertreibt es als BYTEBOLT One mit Awareness-Service), wann Open Source als Geschäftsmodell trägt und welche Bedingungen erfüllt sein müssen.
Wer den Engineering-Hintergrund zu BadUSB lesen möchte: Die technische Engineering-Story haben wir in einem separaten Artikel dokumentiert.
Die unbequeme Frage: Wo liegt Dein Moat wirklich?
Bevor man die Open-Source-Frage entscheidet, muss man eine ehrlichere Frage beantworten: Wo liegt der eigentliche Wert Deines Produkts?
Vier mögliche Antworten:
- In der Hardware selbst, einzigartige Schaltung, patentierbare Sensorik, schwer reproduzierbare Mechanik
- In der Software/Firmware, Algorithmen, Modelle, Tuning, das auf Daten basiert, die Du hast und Wettbewerber nicht
- Im Service drumherum, Beratung, Support, Integrationsleistung, Branchenexpertise
- In der Marke und im Vertrauen, etablierte Beziehungen, Zertifizierungen, Compliance-Erfahrung
Die Antwort ist selten „nur eines davon". Aber eine ehrliche Gewichtung ist die Voraussetzung, um die Open-Source-Frage sinnvoll zu beantworten.
Wenn Dein Wert zu 80 % in der Hardware liegt, also in einer einzigartigen Schaltungsarchitektur, einem patentierbaren Sensor-Layout oder einem schwer reproduzierbaren Fertigungsverfahren, ist Open Source vermutlich der falsche Weg. Wenn Dein Wert zu 80 % im Service und in der Marke liegt, ist Open Source oft sogar die stärkere Strategie.
Was Open Source bei BadUSB / BYTEBOLT One leistet
Bei BadUSB liegt der Wert eindeutig nicht in der Hardware. Ein USB-HID-Tool mit ATmega32U4 ist seit über zehn Jahren in unzähligen Variationen am Markt. Wer das Schaltungsdesign sehen will, kann das auf GitHub tun. Wer die Firmware-Architektur verstehen will, ebenfalls.
Was BYTEBOLT bietet, ist:
- Die Erfahrung aus echten Pentest-Engagements. Welche Payloads wirken in welcher Branche?
- Die Awareness-Workshop-Methodik, in deren Rahmen die Sticks eingesetzt werden
- Das Bulk-Customization-Setup für Branding, vorinstallierte Payloads, Custom-VID/PID
- Die laufende Pflege und Weiterentwicklung des Tools
- Den vertraglichen Rahmen (Auftragspentest, Awareness-Programm, Schulung)
All das kann ein Wettbewerber nicht durch das Klonen des Schaltplans replizieren.
Drei konkrete Vorteile der Offenlegung
1. Es entwaffnet den Vertrauenseinwand. Eine Cybersecurity-Firma, die ihren Kunden Tools verkauft, deren Innenleben sie selbst nicht erklären kann, hat ein Glaubwürdigkeitsproblem. „Hier ist unser Tool. Hier ist der Source Code. Hier ist der Schaltplan. Du kannst Dich selbst überzeugen, dass es nichts tut, was wir nicht sagen", das ist ein Verkaufsargument, das ein geschlossenes Konkurrenzprodukt nicht haben kann.
2. Es senkt die Eintrittshürde für die Community. Pentester, die das Tool im Lab testen wollen, können das ohne kommerzielle Verpflichtung tun. Wer es mag, kommt für Custom-Bestellungen oder Awareness-Programme zurück. Die Open-Source-Variante ist faktisch ein kostenloses Akquise-Asset.
3. Es zwingt zu sauberer Arbeit. Wenn der Schaltplan öffentlich ist, kann man sich keine schludrigen Workarounds leisten. Wer Open Source publiziert, publiziert auch eine Visitenkarte seiner Engineering-Qualität. Das ist Druck, aber gesunder Druck.
Wann Open Source funktioniert, wann nicht
Aus unserer Erfahrung mit BadUSB und ähnlichen Projekten lassen sich vier Dimensionen formulieren, an denen man die Eignung eines Projekts für Open Source prüfen kann. Das Ergebnis ist ein zweispaltiges Bild:
| Dimension | Open Source funktioniert, wenn … | Open Source funktioniert nicht, wenn … |
|---|---|---|
| Geschäftsmodell | substantielle Service-Komponente: Beratung, Schulung, Pentest, Support | reines Hardware-Verkaufsgeschäft, Erlös ausschließlich aus Stückzahlen |
| Hardware-Differenzierung | Produkt ist eine durchdachte Integration bekannter Bausteine | patentierbare Schlüsselinnovation auf Schaltungs- oder Sensorebene |
| Markt & Community | technische Community ist Verkaufsargument (Maker, Pentest, Hobbyist-Elektronik) | stark regulierte Märkte: MDR-Medizintechnik, ISO-26262-Automotive, Luftfahrt |
| Service-Tiefe | eigene Tiefe in Support, Customization und Pflege ist tatsächlich vorhanden | keine eigene Service-Tiefe: Wettbewerber können das Service-Geschäft besser bedienen |
| Lizenzwahl | bewusste Wahl: Copyleft (GPL) bremst geschlossene Forks, permissive Lizenzen (MIT, Apache 2.0) maximieren Adoption | reflexartige Wahl ohne strategische Überlegung, Copyleft-Verpflichtungen werden später zum Problem |
Im Folgenden beleuchten wir die ersten vier Dimensionen genauer:
Geschäftsmodell: Service-Komponente vs. reines Produktgeschäft
Open Source funktioniert, wenn das Produkt nicht das ganze Geschäft ist, sondern der Türöffner zu einer Dienstleistung. Bei BYTEBOLT sind das Awareness-Schulungen, Pentests und Beratung. Wer dagegen ein reines Produktgeschäft hat, also nur Stückzahlen verkaufen will, wird mit Open Source schwer Geld verdienen. Niedrigpreisige Wettbewerber, häufig aus Asien, können das Design innerhalb weniger Tage oder Wochen klonen, mit niedrigeren Stückkosten produzieren und die Marge zerstören.
Hardware-Differenzierung: Integration vs. Schlüsselinnovation
Wenn Du eine Innovation auf Schaltungsebene hast (ein einzigartiges Frontend, eine clevere Topologie, eine patentierbare Architektur), dann ist Open Source eine Verschwendung dieses Vorsprungs. Patentschutz und Open Source schließen sich nicht grundsätzlich aus, aber die Kombination ist heikel und braucht juristische Begleitung. Wenn Dein Produkt aber im Wesentlichen eine durchdachte Integration bekannter Bausteine ist, schadet die Offenheit nicht.
Markt & Community: Asset oder Risiko?
In manchen Branchen wie Pentest-Tools, Maker-Hardware oder Hobbyist-Elektronik ist Community-Sichtbarkeit ein Verkaufsargument. In stark regulierten Märkten dagegen (Medizintechnik unter MDR, Automotive unter ISO 26262, Luftfahrt) verlangen Zulassungspfade geschlossene Validierungsketten. Wer Änderungen aus einer offenen Community akzeptiert, bricht im Zweifel die Validierungskette. Hier ist geschlossene Entwicklung mit kontrolliertem Change-Management der Standard.
Service-Tiefe: Vorhanden oder nicht
Open Source funktioniert nur, wenn Du das Service-Geschäft drumherum auch tatsächlich liefern kannst. Wenn Du ein Produkt freigibst, ohne den Support, die Beratung, die Customization-Leistung anbieten zu können, verschenkst Du das IP, und Wettbewerber, die das Service-Geschäft besser können, profitieren.
Lizenzwahl: bewusst, nicht reflexartig
GPLv3 ist nicht immer die richtige Wahl. Wer will, dass kommerzielle Wettbewerber das Produkt nicht in geschlossenen Forks weiterverkaufen können, ist mit einer Copyleft-Lizenz (GPL) gut bedient. Wer die maximale Adoption sucht, auch in kommerziellen Produkten, ist mit MIT oder Apache 2.0 besser dran. Diese Wahl muss bewusst getroffen werden, nicht reflexartig.
Die Sechs-Fragen-Checkliste für Deine Make-or-Open-Entscheidung
Wenn Du überlegst, ob Open Source für Dein nächstes Hardwareprodukt sinnvoll ist, sind das die Fragen, die wir in einem Erstgespräch stellen würden:
- Service-Anteil: Wie viel Prozent Deines Umsatzes mit dem Produkt entsteht nach dem Verkauf durch Service, Wartung, Beratung, Customization?
- Patentierbarkeit: Gäbe es einen patentierbaren Aspekt der Hardware, und wäre der Patentschutz tatsächlich durchsetzbar (auch gegen Klone aus Asien)?
- Community-Charakter: Wie groß ist die Community Deiner Zielgruppe, und wie technisch ist sie?
- Lizenz-Welten Deiner Kunden: Bewegen sich Deine Kunden in regulierten Compliance-Welten (Medizin, Automotive) oder in offenen Communities (Maker, Pentest)?
- Klon-Geschwindigkeit: Welche Wettbewerber hätten den größten Nutzen davon, Dein Design zu klonen, und wie schnell könnten sie das?
- Service-Tiefe: Kannst Du die Service-Tiefe tatsächlich liefern, die für ein Open-Source-Modell nötig ist?
Wer alle Fragen ehrlich beantwortet, hat in der Regel ein klares Bild auch wenn die Antwort dann manchmal „Nein, Open Source ist hier nicht der richtige Weg" lautet.
Was wir bei BadUSB / BYTEBOLT One konkret entschieden haben
Konkret haben wir folgendes Modell gewählt:
| Komponente | Lizenz / Status |
|---|---|
| Schaltplan und PCB-Layout | GPLv3, vollständig auf GitHub |
| Firmware-Source-Code | GPLv3, vollständig auf GitHub |
| Beispiel-Payloads | GPLv3, vollständig auf GitHub |
| Dokumentation | GPLv3, öffentlich |
| Fertigungspartner und Lieferketten | Dienstleistung, die wir anbieten |
| Bulk-Customization-Toolchain | Dienstleistung, die wir anbieten |
| Vorinstallierte Custom-Payloads | Vertraulich (Kunden-IP) |
| Awareness-Programm-Methodik | Geschlossen, Dienstleistung, die wir anbieten |
Diese Aufteilung folgt einer klaren Logik: Was reproduzierbar ist und was Vertrauen schafft, ist offen. Was Erfahrung, Service und kontinuierliche Pflege braucht, bleibt geschlossen.
Fazit: Bewusst entscheiden, nicht reflexartig
Open-Source-Hardware ist kein Allheilmittel und keine Bedrohung. Es ist eine Strategiewahl, die zur Antwort auf die Frage passen muss: Wo liegt mein Moat?
Wenn Dein Wert in Service, Beratung und Vertrauen liegt, ist Open Source oft die stärkere Option. Sie senkt Akquisekosten, baut Glaubwürdigkeit auf und entlastet Dich von der Pflege eines IP-Schutzes, der ohnehin nur bedingt durchsetzbar wäre. Wenn Dein Wert in der Hardware selbst liegt, ist sie der falsche Weg.
In unserer Arbeit als Embedded-Auftragsentwickler erleben wir beide Konstellationen regelmäßig, und beide sind valide. Was zählt, ist die bewusste Entscheidung zu Beginn des Projekts, nicht das nachträgliche Bedauern. Ein konkretes Beispiel für ein erfolgreiches Open-Source-Hardware-Projekt findest Du in unserer BadUSB-Referenz.
Wenn Du selbst über ein Hardwareprojekt nachdenkst und unsicher bist, welcher Weg für Dich der richtige ist, sprich mit uns. Ein Erstgespräch ist unverbindlich und führt häufig schon zu einer klareren Sicht, unabhängig davon, ob wir am Ende gemeinsam arbeiten oder nicht.
FAQ: häufig gestellte Fragen
Was bedeutet Open-Source-Hardware?
Open-Source-Hardware bezeichnet Hardware-Produkte, deren Designinformationen wie Schaltpläne, PCB-Layouts, Stücklisten und Mechanik-Daten unter einer offenen Lizenz veröffentlicht sind. Häufig sind das Lizenzen wie GPLv3, CERN OHL oder Solderpad. Bestehende Produkte sind dadurch reproduzierbar, modifizierbar und (je nach Lizenz) auch kommerziell weiternutzbar.
Verliere ich mit Open-Source-Hardware mein geistiges Eigentum?
Nicht automatisch. Du gibst das Schaltungs- und Layoutdesign frei, aber Markenrechte, Service-Know-how, Fertigungsbeziehungen und Branchenerfahrung bleiben Dein Eigentum. Ob das ein Verlust ist, hängt davon ab, wo Dein eigentlicher Wert liegt.
Welche Open-Source-Lizenz eignet sich für Hardware?
Für Hardware-Designs sind die häufigsten Lizenzen GPLv3 (Copyleft, verhindert geschlossene Forks), CERN OHL (speziell für Hardware konzipiert) und MIT/Apache 2.0 (permissiv, maximale Adoption). Die Wahl hängt davon ab, ob Du Wettbewerber daran hindern willst, das Design in geschlossenen Produkten weiterzuverwenden.
Funktioniert Open-Source-Hardware in regulierten Märkten wie Medizintechnik?
In der Regel nein, oder nur mit erheblichem zusätzlichem Aufwand. Regulierte Märkte (Medizintechnik unter MDR, Automotive unter ISO 26262, Luftfahrt) verlangen geschlossene Validierungsketten und kontrolliertes Change-Management. Open-Source-Beiträge von außen sind damit schwer vereinbar.
Macht Open-Source-Hardware bei Auftragsentwicklungen Sinn?
Es kommt auf das Geschäftsmodell des Auftraggebers an. Wenn der Auftraggeber das Produkt als Türöffner für eine Dienstleistung versteht (wie BYTEBOLT), kann Open Source ein starker Multiplikator sein. Wenn der Auftraggeber primär Stückzahlumsatz mit der Hardware selbst plant, ist klassischer IP-Schutz meistens die bessere Wahl.
Wie kann Embedded Solutions mein Hardwareprojekt begleiten?
Wir sind auf Embedded-Auftragsentwicklung spezialisiert: von der Konzeptphase über Schaltungsdesign, PCB-Layout und Firmware bis zur Fertigungsbegleitung. Bei jedem Projekt diskutieren wir früh die strategische Frage Open Source oder geschlossen, weil sie den weiteren Verlauf prägt. Ein unverbindliches Erstgespräch ist der einfachste Einstieg.
Was ist der Unterschied zwischen Open-Source-Software und Open-Source-Hardware?
Open-Source-Software bezieht sich auf Quellcode unter offener Lizenz. Open-Source-Hardware umfasst zusätzlich physische Designinformationen wie Schaltpläne, PCB-Layouts und Mechanik-Daten. Hardware ist komplexer, weil zwischen Design und Produkt immer noch Fertigung, Bestückung und Tests liegen, das Klonen ist also aufwendiger als bei reiner Software.