Lors d’une conversation avec la communauté en mai 2024, Tiger, directeur technique d’IceWhale, et Axel, développeur de la communauté, ont expliqué pourquoi l’écosystème d’applications de CasaOS et le jeune écosystème d’applications de ZimaOS s’étaient orientés vers des standards de conteneurs communs plutôt que de dépendre d’un format de paquet propre à la plateforme.
L’idée centrale était simple : un écosystème d’applications se développe plus rapidement lorsque les développeurs peuvent réutiliser des fichiers Docker Compose familiers, ajouter une petite quantité de métadonnées pour l’App Store et distribuer des applications sans devoir négocier directement chaque contribution avec l’équipe principale.
Il s’agissait d’une orientation technique de 2024, et non d’une spécification actuelle de version
La conversation a eu lieu alors que ZimaOS évoluait encore à partir de bases communes avec CasaOS. Les déclarations concernant les futures API, les ateliers, les extensions tierces et la modularisation avec systemd-sysext décrivaient des intentions ou des expérimentations à leurs débuts à cette époque. Elles ne doivent pas être interprétées comme la promesse que chaque concept serait livré dans les délais suggérés.
Pourquoi le premier format d’application JSON personnalisé créait des frictions
Tiger a expliqué que l’App Store initial de CasaOS utilisait un format JSON personnalisé. Le fichier décrivait les métadonnées associées à une image Docker, notamment le titre de l’application, son icône, ses captures d’écran et ses paramètres de configuration.
Le problème n’était pas que JSON ne pouvait pas décrire une application. Le problème concernait l’intégration des contributeurs : toute personne souhaitant publier une application devait d’abord apprendre un format propre à CasaOS. Cette étape de traduction supplémentaire limitait la vitesse à laquelle des projets de conteneurs existants pouvaient devenir des applications installables.
Pourquoi Docker Compose est devenu la base du empaquetage des applications
L’équipe a constaté que Docker Compose était suffisamment extensible pour contenir la définition du conteneur tout en prenant en charge les métadonnées supplémentaires nécessaires à l’App Store. Les projets Compose existants pouvaient ainsi être adaptés au lieu d’être recréés dans un système de paquet distinct.
Cela a changé le modèle de contribution :
- Les images de conteneurs et les définitions de services pouvaient continuer à utiliser les conventions Docker familières.
- Les champs de l’App Store, tels que les titres, les icônes, les captures d’écran, les ports et les informations sur les volumes, pouvaient être ajoutés autour de la définition Compose.
- Les contributeurs pouvaient réutiliser le travail en amont au lieu de maintenir un paquet sans lien, réservé à la plateforme.
- ZimaOS et CasaOS pouvaient tirer parti de l’écosystème plus vaste de l’auto-hébergement.
Ce que Docker Compose a changé pour les contributions de la communauté
L’entretien s’appuyait sur une contribution communautaire réalisée à ses débuts comme exemple. Tiger se souvenait qu’un contributeur connu sous le nom de Wisdom Sky avait converti environ 150 images de conteneurs en applications CasaOS en une nuit, alors que la prise en charge de l’App Store basée sur Compose commençait à émerger. L’équipe s’attendait auparavant à une augmentation modeste par rapport au rythme de une ou deux nouvelles applications par mois.
Il s’agissait d’une anecdote issue de la conversation de 2024, et non d’une référence indiquant la vitesse à laquelle chaque application peut être empaquetée. Chaque application doit toujours disposer de ports, de volumes, d’une prise en charge de l’architecture, de permissions et d’un comportement de mise à jour corrects, et faire l’objet d’une vérification par un mainteneur.
La place des App Stores tiers dans l’écosystème
L’équipe a également décrit la prise en charge de sources d’applications tierces. Au lieu d’exiger que chaque paquet communautaire soit intégré au catalogue officiel, un mainteneur pouvait héberger une source indépendante que les utilisateurs pouvaient ajouter à CasaOS ou ZimaOS.
Ce modèle élargit le choix et réduit le goulot d’étranglement lié à la vérification par l’équipe officielle, mais il dissocie également la disponibilité de l’aval officiel. Le fait qu’une application apparaisse dans une source tierce ne signifie pas automatiquement qu’IceWhale maintient son image, audite son code, garantit ses mises à jour ou assure la prise en charge de son comportement en matière de gestion des données. Avant l’installation, les utilisateurs doivent vérifier l’éditeur de l’image, le dépôt, les privilèges demandés, le stockage associé, l’exposition réseau et l’historique des mises à jour.
L’équilibre proposé entre composants ouverts et code produit propriétaire
Tiger a déclaré que ZimaOS était construit sur des composants ouverts de CasaOS, notamment certains éléments de sa passerelle et de sa base de bus de messages, tandis que d’autres couches du produit resteraient propriétaires. L’équipe souhaitait continuer à accepter les contributions open source et envisageait de rendre davantage d’API disponibles aux développeurs d’extensions.
L’entretien n’affirmait pas que tout le code de ZimaOS deviendrait open source. Il décrivait une frontière hybride : exposer des interfaces réutilisables et des composants destinés à la communauté tout en conservant privée une partie de l’implémentation du produit.
Ce que la modularisation avec systemd-sysext devait permettre
La conversation mentionnait un mécanisme très précoce fondé sur systemd-sysext. L’objectif était de permettre à des tiers d’ajouter des extensions au niveau du système sans modifier directement le cœur immuable, selon un principe similaire à celui qui consiste à développer au-dessus d’une interface de plateforme définie.
Comme Tiger avait explicitement décrit ce travail comme étant à ses débuts, cette section doit être lue comme un élément de contexte architectural. La publication ne fournissait ni SDK public pour les extensions, ni contrat d’API stable, ni politique de compatibilité, ni date de sortie confirmée.
Le principe général : réutiliser les standards plutôt que les réinventer
La conclusion la plus durable était la préférence pour les standards existants de la communauté. La réutilisation de Docker et de Compose réduisait le travail spécifique à la plateforme pour l’équipe d’IceWhale comme pour les contributeurs d’applications, tout en connectant l’App Store à un ensemble beaucoup plus vaste de logiciels auto-hébergés.
La présentation actuelle de ZimaOS met désormais en avant un App Store organisé par scénarios, la prise en charge de conteneurs Docker tiers et un catalogue de plus de 800 applications. Cette description actuelle du produit montre comment l’écosystème s’est développé, tandis que l’entretien de 2024 explique les raisons de conception qui l’ont précédé.
Regarder la conversation d’origine sur l’écosystème de l’App Store
La vidéo complète restitue le ton et le contexte historique de la discussion entre Axel et Tiger.
FAQ sur l’écosystème de l’App Store de ZimaOS
Pourquoi CasaOS a-t-il abandonné le format d’application exclusivement basé sur un JSON personnalisé ?
Le format personnalisé ajoutait une étape d’apprentissage pour les contributeurs. Docker Compose permettait aux mainteneurs de réutiliser une définition de service largement connue et d’y ajouter les métadonnées nécessaires à l’App Store.
Les App Stores tiers de ZimaOS sont-ils identiques à l’App Store officiel ?
Non. Les sources tierces peuvent élargir la disponibilité des applications, mais leurs paquets peuvent être maintenus et vérifiés par d’autres personnes. Les utilisateurs doivent évaluer la source et la configuration du conteneur avant l’installation.
L’entretien a-t-il confirmé l’existence d’une API publique d’extension pour ZimaOS ?
Non. L’équipe a indiqué qu’elle envisageait des API, des ateliers et le développement d’extensions. La conversation n’a publié ni API stable ni date de mise à disposition.
systemd-sysext était-il déjà une fonctionnalité ZimaOS finalisée en mai 2024 ?
Non. Tiger a décrit le mécanisme de modularisation comme étant à un stade très précoce. Il a été présenté comme une voie possible pour ajouter des extensions autour d’un cœur immuable.
Tout le code de ZimaOS est-il open source ?
L’entretien décrivait un équilibre entre des composants ouverts et du code produit propriétaire, et non un système d’exploitation entièrement open source.
