In una conversazione della community del maggio 2024, il CTO di IceWhale Tiger e lo sviluppatore della community Axel hanno discusso del motivo per cui l’ecosistema delle app di CasaOS e il nascente ecosistema delle app di ZimaOS si siano orientati verso standard comuni per i container, invece di affidarsi a un formato di pacchetti specifico della piattaforma.
L’idea centrale era semplice: un ecosistema di app cresce più rapidamente quando gli sviluppatori possono riutilizzare file Docker Compose familiari, aggiungere una piccola quantità di metadati per l’app store e distribuire le app senza dover negoziare direttamente ogni contributo con il team principale.
Questa era una direzione tecnica del 2024, non una specifica per una versione attuale
La conversazione si è svolta mentre ZimaOS era ancora in evoluzione a partire da fondamenta condivise con CasaOS. Le dichiarazioni sulle API future, sui workshop, sulle estensioni di terze parti e sulla modularizzazione tramite systemd-sysext descrivevano intenzioni o esperimenti nelle fasi iniziali di sviluppo di quel periodo. Non devono essere interpretate come promesse che ogni concetto sarebbe stato realizzato secondo le tempistiche suggerite.
Perché il primo formato personalizzato delle app in JSON creava difficoltà
Tiger ha spiegato che il primo App Store di CasaOS utilizzava un formato JSON personalizzato. Il file descriveva i metadati relativi a un’immagine Docker, inclusi il titolo dell’app, l’icona, gli screenshot e i dettagli di configurazione.
Il problema non era che JSON non potesse descrivere un’app. Il problema riguardava l’ingresso dei contributori: chiunque volesse pubblicare un’app doveva prima imparare un formato specifico di CasaOS. Questo passaggio aggiuntivo di conversione limitava la velocità con cui i progetti di container esistenti potevano diventare app installabili.
Perché Docker Compose è diventato la base per il pacchettizzazione delle app
Il team ha constatato che Docker Compose era sufficientemente estensibile da contenere la definizione del container e, allo stesso tempo, supportare i metadati aggiuntivi necessari all’App Store. I progetti Compose esistenti potevano quindi essere adattati invece di essere ricostruiti in un sistema di pacchettizzazione separato.
Questo ha cambiato il modello di contribuzione:
- Le immagini dei container e le definizioni dei servizi potevano continuare a utilizzare le convenzioni Docker familiari.
- I campi dell’App Store, come titoli, icone, screenshot, porte e informazioni sui volumi, potevano essere aggiunti alla definizione Compose.
- I contributori potevano riutilizzare il lavoro upstream invece di gestire un pacchetto separato destinato esclusivamente alla piattaforma.
- ZimaOS e CasaOS potevano beneficiare dell’ecosistema più ampio dell’hosting autonomo.
Cosa ha cambiato Docker Compose per i contributi della community
L’intervista ha utilizzato come esempio un primo contributo della community. Tiger ha ricordato che un contributore noto come Wisdom Sky aveva convertito circa 150 immagini di container in app CasaOS in una sola notte, mentre il supporto dell’App Store basato su Compose era ancora in fase di sviluppo. In precedenza, il team si aspettava soltanto un aumento modesto rispetto al ritmo precedente di una o due nuove app al mese.
Si trattava di un aneddoto della conversazione del 2024, non di un parametro di riferimento per la velocità con cui può essere pacchettizzata ogni app. Ogni app necessita comunque di porte e volumi corretti, supporto per l’architettura, permessi, comportamento degli aggiornamenti e revisione da parte dei manutentori.
Come si inseriscono gli app store di terze parti nell’ecosistema
Il team ha descritto anche il supporto per fonti di app di terze parti. Invece di richiedere che ogni pacchetto della community entrasse nel catalogo ufficiale, un manutentore poteva ospitare una fonte indipendente che gli utenti potevano aggiungere a CasaOS o ZimaOS.
Questo modello amplia la scelta e riduce il collo di bottiglia nella revisione da parte del team ufficiale, ma separa anche la disponibilità dall’approvazione. La presenza di un’app in una fonte di terze parti non significa automaticamente che IceWhale ne gestisca l’immagine, ne verifichi il codice, garantisca gli aggiornamenti o fornisca supporto per il modo in cui gestisce i dati. Prima dell’installazione, gli utenti dovrebbero verificare il publisher dell’immagine, il repository, i privilegi richiesti, lo spazio di archiviazione associato, l’esposizione alla rete e la cronologia degli aggiornamenti.
Il compromesso proposto tra componenti open source e codice proprietario del prodotto
Tiger ha affermato che ZimaOS veniva costruito su componenti open source di CasaOS, incluse parti delle sue fondamenta relative al gateway e al bus dei messaggi, mentre altri livelli del prodotto sarebbero rimasti proprietari. Il team voleva continuare ad accettare contributi open source e stava valutando la possibilità di rendere disponibili più API per gli sviluppatori di estensioni.
L’intervista non affermava che tutto il codice di ZimaOS sarebbe diventato open source. Descriveva un confine ibrido: esporre interfacce riutilizzabili e componenti destinati alla community, mantenendo private alcune implementazioni del prodotto.
Cosa avrebbe dovuto consentire la modularizzazione tramite systemd-sysext
La conversazione menzionava un meccanismo ancora nelle primissime fasi, basato su systemd-sysext. L’obiettivo era consentire a terze parti di aggiungere estensioni a livello di sistema senza modificare direttamente il core immutabile, in modo simile, come principio, allo sviluppo su una piattaforma con un’interfaccia definita.
Poiché Tiger aveva descritto esplicitamente questo lavoro come ancora iniziale, questa sezione deve essere letta come contesto architetturale. Il post non forniva un SDK pubblico per le estensioni, un contratto API stabile, una politica di compatibilità o una data di rilascio confermata.
Il principio più ampio: riutilizzare gli standard invece di reinventarli
La conclusione più duratura era la preferenza per gli standard esistenti della community. Riutilizzare Docker e Compose riduceva il lavoro specifico della piattaforma sia per il team di IceWhale sia per i contributori delle app, collegando al contempo l’App Store a un bacino molto più ampio di software per l’hosting autonomo.
L’attuale panoramica di ZimaOS presenta ora un App Store basato su scenari, il supporto Docker di terze parti e un catalogo di oltre 800 app. Questa descrizione attuale del prodotto mostra come si è sviluppato l’ecosistema, mentre l’intervista del 2024 spiega le motivazioni progettuali che lo hanno preceduto.
Guarda la conversazione originale sull’ecosistema dell’App Store
Il video completo conserva il tono e il contesto storico della discussione tra Axel e Tiger.
Domande frequenti sull’ecosistema dell’App Store di ZimaOS
Perché CasaOS ha abbandonato il formato personalizzato delle app basato esclusivamente su JSON?
Il formato personalizzato aggiungeva un passaggio di apprendimento per i contributori. Docker Compose consentiva ai manutentori di riutilizzare una definizione dei servizi ampiamente conosciuta e di aggiungere i metadati necessari all’App Store.
Gli app store di terze parti di ZimaOS sono uguali all’App Store ufficiale?
No. Le fonti di terze parti possono ampliare la disponibilità delle app, ma i loro pacchetti possono essere gestiti e revisionati da persone diverse. Prima dell’installazione, gli utenti dovrebbero valutare la fonte e la configurazione del container.
L’intervista ha confermato un’API pubblica per le estensioni di ZimaOS?
No. Il team ha affermato che stava valutando API, workshop e lo sviluppo di estensioni. La conversazione non ha pubblicato un’API stabile né una data di rilascio.
systemd-sysext era già una funzionalità completa di ZimaOS nel maggio 2024?
No. Tiger ha descritto il meccanismo di modularizzazione come ancora nelle primissime fasi. È stato presentato come una possibile soluzione per le estensioni attorno a un core immutabile.
Tutto il codice di ZimaOS è open source?
L’intervista descriveva un equilibrio tra componenti open source e codice proprietario del prodotto, non un sistema operativo completamente open source.
