In einem Community-Gespräch im Mai 2024 diskutierten der IceWhale-CTO Tiger und der Community-Entwickler Axel, warum sich das CasaOS- und das entstehende ZimaOS-App-Ökosystem statt auf ein plattformspezifisches Paketformat auf gemeinsame Containerstandards zubewegten.
Die zentrale Idee war einfach: Ein App-Ökosystem wächst schneller, wenn Entwickler vertraute Docker-Compose-Dateien wiederverwenden, eine kleine Menge an App-Store-Metadaten hinzufügen und Apps verteilen können, ohne jede Einreichung direkt mit dem Kernteam abstimmen zu müssen.
Dies war eine technische Ausrichtung im Jahr 2024, keine aktuelle Release-Spezifikation
Das Gespräch fand statt, während sich ZimaOS noch aus einer gemeinsamen Grundlage mit CasaOS weiterentwickelte. Aussagen zu künftigen APIs, Workshops, Erweiterungen von Drittanbietern und der Modularisierung mit systemd-sysext beschrieben zu diesem Zeitpunkt Absichten oder Experimente in einer frühen Phase. Sie sollten nicht als Versprechen verstanden werden, dass jedes Konzept innerhalb des vorgeschlagenen Zeitplans umgesetzt wurde.
Warum das frühe benutzerdefinierte JSON-App-Format Probleme verursachte
Tiger erklärte, dass der CasaOS App Store anfangs ein benutzerdefiniertes JSON-Format verwendete. Die Datei beschrieb Metadaten rund um ein Docker-Image, darunter den App-Titel, das Symbol, Screenshots und Konfigurationsdetails.
Das Problem war nicht, dass JSON keine App beschreiben konnte. Das Problem war die Einarbeitung neuer Mitwirkender: Wer eine App veröffentlichen wollte, musste zunächst ein speziell für CasaOS entwickeltes Format erlernen. Dieser zusätzliche Übersetzungsschritt begrenzte, wie schnell bestehende Containerprojekte zu installierbaren Apps werden konnten.
Warum Docker Compose zur Grundlage der App-Paketierung wurde
Das Team stellte fest, dass Docker Compose ausreichend erweiterbar war, um die Containerdefinition zu transportieren und gleichzeitig die zusätzlichen, vom App Store benötigten Metadaten aufzunehmen. Bestehende Compose-Projekte konnten daher angepasst werden, anstatt sie in einem separaten Paketsystem neu zu erstellen.
Dadurch änderte sich das Beitragsmodell:
- Container-Images und Dienstdefinitionen konnten weiterhin vertraute Docker-Konventionen verwenden.
- App-Store-Felder wie Titel, Symbole, Screenshots, Ports und Volume-Informationen konnten rund um die Compose-Definition ergänzt werden.
- Mitwirkende konnten Arbeiten aus vorgelagerten Projekten wiederverwenden, statt ein unabhängiges, ausschließlich für die Plattform bestimmtes Paket zu pflegen.
- ZimaOS und CasaOS konnten vom größeren Self-Hosting-Ökosystem profitieren.
Wie Docker Compose Beiträge aus der Community veränderte
Im Interview wurde ein früher Community-Beitrag als Beispiel genannt. Tiger erinnerte sich, dass ein als Wisdom Sky bekannter Mitwirkender in einer Nacht ungefähr 150 Container-Images in CasaOS-Apps umwandelte, während die Compose-basierte Unterstützung des App Stores eingeführt wurde. Das Team hatte zuvor nur mit einer moderaten Steigerung gegenüber der alten Rate von ein oder zwei neuen Apps pro Monat gerechnet.
Dies war eine Anekdote aus dem Gespräch von 2024 und kein Maßstab dafür, wie schnell jede App paketiert werden kann. Jede App benötigt weiterhin korrekte Ports, Volumes, Architekturunterstützung, Berechtigungen, ein funktionierendes Aktualisierungsverhalten und eine Prüfung durch die Maintainer.
Wie App Stores von Drittanbietern in das Ökosystem passen
Das Team beschrieb außerdem die Unterstützung für App-Quellen von Drittanbietern. Statt jedes Community-Paket in den offiziellen Katalog aufnehmen zu müssen, konnte ein Maintainer eine unabhängige Quelle hosten, die Benutzer zu CasaOS oder ZimaOS hinzufügen konnten.
Dieses Modell erweitert die Auswahl und verringert den Prüfungsengpass des offiziellen Teams, trennt jedoch Verfügbarkeit von offizieller Unterstützung. Dass eine App in einer Quelle eines Drittanbieters erscheint, bedeutet nicht automatisch, dass IceWhale ihr Image pflegt, ihren Code prüft, Aktualisierungen garantiert oder das Verhalten bei der Datenverarbeitung unterstützt. Benutzer sollten vor der Installation den Herausgeber des Images, das Repository, angeforderte Berechtigungen, eingebundenen Speicher, die Netzwerkfreigabe und die Aktualisierungshistorie überprüfen.
Das vorgeschlagene Gleichgewicht zwischen offenen Komponenten und proprietärem Produktcode
Tiger sagte, ZimaOS werde auf offenen CasaOS-Komponenten aufgebaut, darunter Teilen seiner Gateway- und Message-Bus-Grundlage, während andere Produktschichten proprietär bleiben sollten. Das Team wollte weiterhin Open-Source-Beiträge annehmen und erwog, weitere APIs für Entwickler von Erweiterungen verfügbar zu machen.
Das Interview behauptete nicht, dass der gesamte ZimaOS-Code Open Source werden würde. Es beschrieb eine hybride Grenze: Wiederverwendbare Schnittstellen und Community-nahe Komponenten sollten offengelegt werden, während ausgewählte Teile der Produktimplementierung privat bleiben.
Was die Modularisierung mit systemd-sysext ermöglichen sollte
Im Gespräch wurde ein sehr früher Mechanismus auf Basis von systemd-sysext erwähnt. Ziel war es, Dritten das Hinzufügen systemweiter Erweiterungen zu ermöglichen, ohne den unveränderlichen Kern direkt zu modifizieren – ähnlich dem Prinzip, gegen eine definierte Plattformschnittstelle zu entwickeln.
Da Tiger diese Arbeit ausdrücklich als frühphasig bezeichnete, sollte dieser Abschnitt als architektonischer Kontext gelesen werden. Der Beitrag stellte weder ein öffentliches Erweiterungs-SDK noch einen stabilen API-Vertrag, eine Kompatibilitätsrichtlinie oder einen bestätigten Veröffentlichungstermin vor.
Das übergeordnete Prinzip: Standards wiederverwenden, statt sie neu zu erfinden
Die wichtigste nachhaltige Erkenntnis war die Präferenz für bestehende Community-Standards. Die Wiederverwendung von Docker und Compose verringerte den plattformspezifischen Aufwand sowohl für das IceWhale-Team als auch für App-Mitwirkende und verband den App Store gleichzeitig mit einem deutlich größeren Angebot an Self-Hosting-Software.
Die aktuelle ZimaOS-Übersicht präsentiert inzwischen einen szenariobasierten App Store, Docker-Unterstützung von Drittanbietern und einen Katalog mit mehr als 800 Apps. Diese aktuelle Produktbeschreibung zeigt, wie sich das Ökosystem entwickelt hat, während das Interview von 2024 die Designüberlegungen erläutert, die ihm vorausgingen.
Das ursprüngliche Gespräch über das App-Store-Ökosystem ansehen
Das vollständige Video bewahrt den Ton und den historischen Kontext des Gesprächs zwischen Axel und Tiger.
FAQ zum ZimaOS-App-Store-Ökosystem
Warum entfernte sich CasaOS von einem ausschließlich benutzerdefinierten JSON-App-Format?
Das benutzerdefinierte Format fügte für Mitwirkende eine zusätzliche Lernstufe hinzu. Docker Compose ermöglichte es Maintainerinnen und Maintainer, eine weithin bekannte Dienstdefinition wiederzuverwenden und die vom App Store benötigten Metadaten hinzuzufügen.
Sind App Stores von Drittanbietern für ZimaOS dasselbe wie der offizielle App Store?
Nein. Quellen von Drittanbietern können die Verfügbarkeit von Apps erweitern, ihre Pakete werden jedoch möglicherweise von anderen Personen gepflegt und geprüft. Benutzer sollten die Quelle und die Containerkonfiguration vor der Installation bewerten.
Bestätigte das Interview eine öffentliche ZimaOS-Erweiterungs-API?
Nein. Das Team sagte, dass es APIs, Workshops und die Entwicklung von Erweiterungen in Betracht ziehe. Das Gespräch veröffentlichte weder eine stabile API noch einen Veröffentlichungstermin.
War systemd-sysext im Mai 2024 bereits eine fertige ZimaOS-Funktion?
Nein. Tiger bezeichnete den Modularisierungsmechanismus als sehr frühe Entwicklung. Er wurde als möglicher Weg für Erweiterungen rund um einen unveränderlichen Kern vorgestellt.
Ist der gesamte ZimaOS-Code Open Source?
Das Interview beschrieb ein Gleichgewicht zwischen offenen Komponenten und proprietärem Produktcode, nicht ein vollständig quelloffenes Betriebssystem.
