Es klingt etwas seltsam, wenn man schreibt, „ich bin froh, dass Ihr damit gescheitert seid“, aber ich bin es tatsächlich. Scheitern gehört bei der Entwicklung immer dazu und es ist wichtig, wie man mit dem Scheitern umgeht. Ich bin froh, wie es gelaufen ist und finde es positiv, dass Ihr das Scheitern sogar dokumentiert. Ihr habt Euch von „Es gibt Zweifel, wohin sich Nitrokey entwickeln wird“ hin zu „Der Ausflug ist beendet, man kann das Vertrauen wieder aufbauen” in meinen Augen gemausert.

Als ich von der NextBox laß, interessierten mich auch die Specs und als ich UbuntuCore laß, habe ich die Hände über dem Kopf zusammengeschlagen und mir nur gedacht, wie können die nur. Ich habe einen NitroKey(1) und hatte mich für diesen damals entschieden, da ich OpenSource wenn überhaupt unterstützen wollte und auf Sicherheit bedacht war. Mit UbuntuCore hätte ich dieses Produkt definitiv nicht gekauft und hätte es auch niemandem empfohlen.

UbuntuCore durch snap hat man ein Walled Garden, genauso wie mit Apple. Es gibt einen Gatekeeper und das ist Ubuntu und falls die plötlich keinen Bock mehr haben, dann drehen sie etwas eventuell ab. snap ist auch kein OpenSourceökosystem, denn es funktioniert nicht ohne Canonicals nicken. Es gibt jetzt schon nur NextCloud für UbuntuCore18, nicht 20. Wer sagt, dass es dies bald garnicht mehr gibt und wer garantiert für Updates? Canonical hat in der Vergangenheit schon sehr oft gezeigt, dass ihre Entwicklungen ein Griff ins Klo sind - upstart, mir, netplan, snap. upstart war davon am erfolgreichsten und verwendet inzwischen niemand mehr. mir wurde bei der Ankündigung bereits verrissen und netplan hat nichts neues beizutragen, im Gegenteil, man hat sofort Einschränkungen, die man zuvor (ifupdown) nicht hatte (VLAN-Support). Ubuntu war Canonicals einziger erfolgreicher Schritt, welcher wirklich OpenSource und den Menschen etwas positives gebracht hat. Somit hoffe ich sehr, dass snap keine Zukunft hat.

Wer nichts Zahlt, ist nicht Kunde, sondern Produkt. Ihr hättet Canonical nichts bezahlt, aber dafür hätte Canonical Euch einstellen können, wie sie es mit jedem Produkt hätten machen können. Mit einem Vertrag hättet Ihr eine vertragliche Zusicherung. Aber ich bin froh, dass Ihr Euch das nicht leisten konntet. ;)

Das snap irgendwie zusätzliche Sicherheit brächte gegenüber debs ist definitiv nicht möglich, denn als Benutzer kann ich nicht einmal die Builds kontrollieren, ob diese wirklich aus den angegeben Sourcen erstellt worden sind. Reproduceable Builds sind bei debs kein Problem. Wenn Canonical will, kann es fremde Software einschleusen. Das Vertrauen ist somit für mich nicht vorhanden. Bei docker/podman sieht dies deutlich besser aus.

Aber auch zu den Images gibt es immer viel Potential für Kritik. Wer garantiert, dass es Updates für die Software gibt? Bei docker-Images gibt es einen Ersteller. Oft gibt es nur Updates für das Image, wenn eine neue Version der Software veröffentlicht wurde. Bugs im Betriebssystem werden hingegen vollkommen ignoriert. Wie die Updatepolitik der NextCloud-Images ist, weiß ich nicht, mir ist dies zuletzt bei MediaWiki aber aufgefallen. Fixes für Sicherheitslöcher des Webservers wurden nicht als Anlass genommen, ein neues Image zuerstellen, das Sicherheitsloch blieb offen.

Daher wäre von mir an die NextBox aus Sicherheitsgründen auf jeden Fall die Anforderung: Jegliche Software muss zeitnah mit Fixes bedacht werden und nicht nur die Software, dessen Name auf dem Image steht. Im Endeffekt ist dies eine Anforderung an Euch, denn Ihr wollt die NextBox anbieten. Der Kunde ist sonst von Euch enttäuscht, denn Ihr preist es mit Sicherheit an. Macht Euch daher vertraut mit den Images, die Ihr verwendet. Macht am Besten von Anfang an ein Fork vom eigentlichen Image, damit Ihr die Kontrolle darüber habt, welches Image zu Anfang installiert ist. Wenn das NextCloud-Image plötzlich freidreht, könnt Ihr den Kunden nicht sagen, „wir haben zwar gesagt, Ihr müsst nichts tun, aber leider müsst Ihr nun leider doch etwas tun und zwar bezieht nicht mehr NextCloud, sondern wechselt zu NextBox/NextCloud“. Die wichtigsten Images sollten von Euch bereits verwaltet werden. Reproduceable Builds sollten wohl klar sein. Eventuell baut einen eigenen Docker-Hub auf, um auch vom eventuellen freidrehenden Docker unabhängig zu sein. Der Kunde vertraut Euch und Ihr wollt nicht das Vertrauen der Kunden verlieren, nur weil Ihr Euch schlechte Partner ins Bett geholt habt. Falls der Kunde Euch irgendwann nicht mehr vertraut, weil Ihr Sch**** gebaut habt, dann ist das war ganz anderes. Der aufgeklärte Benutzer kann immer noch zum original NextCloud-Image wechseln, den anderen fällt dies erst garnicht auf.

Es wurde podman bereits erwähnt. Mit bullseye wird podman bei Debian dabei sein. Frische/junge Software unterliegt oft nervigen Fluktuationen. Bei Debian bleibt es aber stabil bei einer Version. Ich habe noch keine Erfahrung mit podman, aber es klingt „besser“ als docker. Da die selben Images bezogen werden können, sollte es auch kaum ein Risiko geben, dass sich Formate ändern. Besonders wenn Ihr einen eigenen Docker-Hub betreibt.

Wegen der finanziellen Risiken und den laufenden Kosten, kann ich es verstehen, wenn Ihr kein Docker-Hub betreiben werdet. Aber das eigene NextCloud-Image ist schon etwas, was Ihr Euch leisten könntet.

Habt Ihr bedacht, dass NextCloud seine Architektur umstellen will? Wie wollt Ihr damit umgehen?

Ich wünsche Euch viel Erfolg mit der NextBox und dass es für Euch und den Kunden eine Bereicherung wird.