I ett communitysamtal i maj 2024 diskuterade IceWhales teknikchef Tiger och communityutvecklaren Axel varför app-ekosystemet för CasaOS och det framväxande ZimaOS gick mot gemensamma containerstandarder i stället för att förlita sig på ett plattformsspecifikt paketformat.
Grundidén var enkel: ett app-ekosystem växer snabbare när utvecklare kan återanvända välbekanta Docker Compose-filer, lägga till en liten mängd metadata för appbutiken och distribuera appar utan att behöva förhandla om varje bidrag direkt med kärnteamet.
Detta var en teknisk inriktning från 2024, inte en specifikation för en aktuell version
Samtalet ägde rum medan ZimaOS fortfarande utvecklades från en grund som delades med CasaOS. Uttalanden om framtida API:er, workshops, tillägg från tredje part och modularisering med systemd-sysext beskrev dåvarande avsikter eller experiment i ett tidigt skede. De ska inte tolkas som löften om att varje koncept skulle levereras enligt den föreslagna tidsplanen.
Varför det tidiga anpassade JSON-appformatet skapade friktion
Tiger förklarade att CasaOS App Store i ett tidigt skede använde ett anpassat JSON-format. Filen beskrev metadata kring en Docker-avbildning, bland annat appens titel, ikon, skärmbilder och konfigurationsuppgifter.
Problemet var inte att JSON inte kunde beskriva en app. Problemet var introduktionen av bidragsgivare: alla som ville publicera en app behövde först lära sig ett format som var specifikt för CasaOS. Detta extra översättningssteg begränsade hur snabbt befintliga containerprojekt kunde bli installerbara appar.
Varför Docker Compose blev grunden för apppaketeringen
Teamet upptäckte att Docker Compose var tillräckligt utbyggbart för att hantera containerdefinitionen och samtidigt rymma den ytterligare metadata som behövdes av App Store. Befintliga Compose-projekt kunde därför anpassas i stället för att byggas om i ett separat paketeringssystem.
Detta förändrade bidragsmodellen:
- Containeravbildningar och tjänstedefinitioner kunde fortsätta använda välbekanta Docker-konventioner.
- App Store-fält som titlar, ikoner, skärmbilder, portar och information om volymer kunde läggas till runt Compose-definitionen.
- Bidragsgivare kunde återanvända uppströmsarbete i stället för att underhålla ett orelaterat plattformsexklusivt paket.
- ZimaOS och CasaOS kunde dra nytta av det bredare self-hosting-ekosystemet.
Vad Docker Compose förändrade för communitybidrag
Intervjun använde ett tidigt communitybidrag som exempel. Tiger mindes att en bidragsgivare känd som Wisdom Sky konverterade ungefär 150 containeravbildningar till CasaOS-appar under en natt, medan stödet för en Compose-baserad App Store höll på att införas. Teamet hade tidigare bara förväntat sig en måttlig ökning jämfört med den tidigare takten på en eller två nya appar per månad.
Detta var en anekdot från samtalet 2024, inte ett riktvärde för hur snabbt alla appar kan paketeras. Varje app behöver fortfarande korrekta portar, volymer, arkitekturstöd, behörigheter, uppdateringsbeteende och granskning av en underhållare.
Hur appbutiker från tredje part passar in i ekosystemet
Teamet beskrev också stöd för appkällor från tredje part. I stället för att kräva att varje communitypaket skulle tas in i den officiella katalogen kunde en underhållare vara värd för en oberoende källa som användare kunde lägga till i CasaOS eller ZimaOS.
Denna modell ökar valfriheten och minskar den officiella teamets granskningsflaskhals, men skiljer samtidigt tillgänglighet från godkännande. Att en app visas i en källa från tredje part innebär inte automatiskt att IceWhale underhåller dess avbildning, granskar koden, garanterar uppdateringar eller stöder dess hantering av data. Användare bör kontrollera avbildningens utgivare, kodförråd, begärda behörigheter, mappade lagring, nätverksexponering och uppdateringshistorik före installation.
Den föreslagna balansen mellan öppna komponenter och proprietär produktkod
Tiger sade att ZimaOS byggdes på öppna CasaOS-komponenter, inklusive delar av dess gateway- och meddelandebussgrund, medan andra produktlager skulle förbli proprietära. Teamet ville fortsätta ta emot bidrag med öppen källkod och övervägde att göra fler API:er tillgängliga för utvecklare av tillägg.
Intervjun hävdade inte att all ZimaOS-kod skulle bli öppen källkod. Den beskrev en hybridgräns: återanvändbara gränssnitt och communityinriktade komponenter skulle exponeras, medan utvalda delar av produktimplementeringen skulle förbli privata.
Vad modularisering med systemd-sysext var tänkt att möjliggöra
Samtalet nämnde en mycket tidig mekanism baserad på systemd-sysext. Målet var att låta tredje parter lägga till systemnivåtillägg utan att direkt ändra den oföränderliga kärnan, ungefär som att bygga mot ett definierat plattformsgränssnitt.
Eftersom Tiger uttryckligen beskrev arbetet som tidigt bör detta avsnitt läsas som arkitekturkontext. Inlägget tillhandahöll inget offentligt SDK för tillägg, inget stabilt API-avtal, ingen kompatibilitetspolicy och inget bekräftat lanseringsdatum.
Den bredare principen: återanvänd standarder i stället för att uppfinna dem på nytt
Den tydligaste bestående slutsatsen var preferensen för befintliga communitystandarder. Genom att återanvända Docker och Compose minskade det plattformsspecifika arbetet för både IceWhale-teamet och appbidragsgivarna, samtidigt som App Store kopplades till en mycket större mängd self-hostad programvara.
Den aktuella översikten av ZimaOS presenterar nu en scenariobaserad App Store, Docker-stöd från tredje part och en katalog med fler än 800 appar. Den aktuella produktbeskrivningen visar hur ekosystemet har utvecklats, medan intervjun från 2024 förklarar designidéerna som föregick det.
Se det ursprungliga samtalet om App Store-ekosystemet
Hela videon bevarar tonen och den historiska kontexten i diskussionen mellan Axel och Tiger.
Vanliga frågor om ZimaOS App Store-ekosystemet
Varför övergav CasaOS ett appformat som enbart byggde på anpassad JSON?
Det anpassade formatet innebar ett extra inlärningssteg för bidragsgivare. Docker Compose gjorde det möjligt för underhållare att återanvända en välkänd tjänstedefinition och lägga till den metadata som behövdes av App Store.
Är ZimaOS appbutiker från tredje part samma sak som den officiella App Store?
Nej. Källor från tredje part kan utöka apputbudet, men deras paket kan underhållas och granskas av andra personer. Användare bör utvärdera källan och containerkonfigurationen före installation.
Bekräftade intervjun ett offentligt tilläggs-API för ZimaOS?
Nej. Teamet sade att det övervägde API:er, workshops och utveckling av tillägg. Samtalet publicerade inget stabilt API eller leveransdatum.
Var systemd-sysext redan en färdig ZimaOS-funktion i maj 2024?
Nej. Tiger beskrev modulariseringsmekanismen som mycket tidig. Den presenterades som en möjlig väg för tillägg runt en oföränderlig kärna.
Är all ZimaOS-kod öppen källkod?
Intervjun beskrev en balans mellan öppna komponenter och proprietär produktkod, inte ett helt operativsystem med öppen källkod.
