Ich baue Number Five, weil ich meine Bootstechnik selbst gestalten möchte. Karten, Instrumente, Musik, Sonar und Bedienelemente sollen zusammenarbeiten – auf der Hardware, die zu meinem Boot und meinem Budget passt. Dabei glaube ich an einen Wandel: Wir können vernetzte Hardware mit derselben Haltung entwickeln, mit der wir Software seit Jahren weiterbringen. Etwas Nutzbares bauen, damit arbeiten, Erfahrungen teilen und die nächste Version besser machen.
01
Jede nutzbare Version zählt.
Eine App verändert sich über Jahre. Ihr Name bleibt, während Bedienung, Technik und Möglichkeiten wachsen. Genau diese Haltung möchte ich auf das Boot übertragen. Die Karte auf dem Display, die gemeinsame Audiobedienung oder die sichtbaren Sonarechos sind Ergebnisse, mit denen wir etwas anfangen können. Dass ich morgen eine bessere Version baue, nimmt ihnen heute nichts weg.
02
Im Einsatz lernen.
Ich möchte die Entwicklung mit der Wirklichkeit verbinden: mit echten Daten, dem tatsächlichen Einbau und den Menschen, die die Technik bedienen. Eine schwer erreichbare Schraube, ein störender Startablauf oder ein fehlender Regler geben uns eine konkrete nächste Aufgabe. Versuche und Messungen helfen dabei. Die Erfahrungen aus der Nutzung gehören genauso dazu und fließen zurück in Code, Konstruktion und Einbau.
03
Software bleibt veränderbar.
Wenn ein Softwarefehler auftaucht, will ich ihn verstehen, beheben und die Verbesserung verteilen können. Updates, Fernwartung und ein Weg zurück zu einer funktionierenden Version gehören für mich zum Systementwurf. Ein Display soll eine neue App bekommen können, der Pi einen neuen Dienst und ein Mikrocontroller eine neue Firmware. Je nach Gerät führt der Weg über das lokale Netz oder einen Wartungszugang.
Bei Number Five trennen wir dafür bereits Dienste und Oberflächen und halten Quellenstände, Geräteprofile und Wiederherstellungsrezepte fest. Darauf möchte ich die Verteilung und Wiederherstellung weiterer Komponenten aufbauen. So wird aus einer einzelnen Fehlerbehebung eine Verbesserung, die auch andere nutzen können.
04
Vorhandene Infrastruktur verwenden.
Ich möchte nicht jeden Baustein selbst erfinden. Ein kommerzielles Mobilfunk-Gateway kann den Wartungszugang liefern. Etablierte Werkzeuge können Software verteilen und Geräte erreichbar machen. Dahinter dürfen sich Pi, Displays und Erfassungsmodule unabhängig weiterentwickeln. Für mich ist das die sinnvolle Aufgabenteilung: vorhandene Infrastruktur einsetzen und unsere Energie in die Funktionen stecken, die wir auf dem Boot haben wollen.
05
Du bestimmst, wie du baust.
Möchtest du unterwegs selbst reparieren können? Dann zählen zugängliche Anschlüsse, austauschbare Module, Schraubverbindungen und ein Aufbau, den du verstehst. Möchtest du eine kompakte, individuell gestaltete Installation? Dann können eigene Leiterplatten und beauftragte Bestückung der passende Weg sein. Selbst bauen können heißt auch, jemand anderen mit Fertigung und Einbau beauftragen zu können.
Software lässt sich aktualisieren; eine kalte Lötstelle braucht einen Eingriff am Aufbau. Deshalb gehört die Werkstatt zur Idee. Deine Entscheidung über Reparierbarkeit, Platz, Gestaltung und Fertigung bestimmt, welche Ausführung zu dir passt.
06
Offen weiterbauen. Auch beruflich.
Ich teile Quellen, Schaltungen, Konstruktionen und Erfahrungen, damit andere darauf aufbauen können. KI ist dabei ein Werkzeug, das unsere Möglichkeiten erweitert. BBN Marine OS, AvNav, Signal K, OpenCPN und die weiteren offenen Grundlagen sind Teil dieser Geschichte. Eine Verbesserung am eigenen Boot kann wieder in den gemeinsamen Baukasten zurückfließen.
Daraus dürfen auch Angebote entstehen: fertig bestückte Platinen, passende Gehäuse, lokale Beschaffung, Einbau und Betreuung. Wer das gut kann, soll damit Geld verdienen können – unter den jeweiligen offenen Lizenzen. Mein Wunsch ist ein Baukasten, mit dem viele Menschen ihre eigene Lösung gestalten und voneinander profitieren.