In een communitygesprek in mei 2024 bespraken IceWhale-CTO Tiger en communityontwikkelaar Axel waarom het app-ecosysteem van CasaOS en het zich ontwikkelende ZimaOS overstapte op gemeenschappelijke containerstandaarden in plaats van te vertrouwen op een platformspecifiek pakketformaat.
Het centrale idee was eenvoudig: een app-ecosysteem groeit sneller wanneer ontwikkelaars vertrouwde Docker Compose-bestanden kunnen hergebruiken, een kleine hoeveelheid metagegevens voor de appstore kunnen toevoegen en apps kunnen distribueren zonder elke bijdrage rechtstreeks met het kernteam te hoeven afstemmen.
Dit was een technische richting voor 2024, geen specificatie voor een huidige release
Het gesprek vond plaats toen ZimaOS nog in ontwikkeling was vanuit een gedeelde basis met CasaOS. Uitspraken over toekomstige API's, workshops, extensies van derden en modularisering met systemd-sysext beschreven intenties of experimenten in een vroeg stadium op dat moment. Ze mogen niet worden geïnterpreteerd als beloften dat elk concept volgens de voorgestelde planning zou worden opgeleverd.
Waarom het vroege aangepaste JSON-appformaat voor wrijving zorgde
Tiger legde uit dat de CasaOS App Store aanvankelijk een aangepast JSON-formaat gebruikte. Het bestand beschreef metagegevens rond een Docker-image, waaronder de titel van de app, het pictogram, schermafbeeldingen en configuratiegegevens.
Het probleem was niet dat JSON geen app kon beschrijven. Het probleem was het inwerken van bijdragers: iedereen die een app wilde publiceren, moest eerst een formaat leren dat specifiek was voor CasaOS. Die extra vertaalslag beperkte hoe snel bestaande containerprojecten konden worden omgezet in installeerbare apps.
Waarom Docker Compose de basis voor appverpakking werd
Het team ontdekte dat Docker Compose voldoende uitbreidbaar was om de containerdefinitie te bevatten en tegelijkertijd de aanvullende metagegevens te ondersteunen die de App Store nodig had. Bestaande Compose-projecten konden daardoor worden aangepast in plaats van opnieuw te worden opgebouwd in een afzonderlijk pakketsysteem.
Dit veranderde het bijdragemodel:
- Container-images en servicedefinities konden vertrouwde Docker-conventies blijven gebruiken.
- Appstorevelden zoals titels, pictogrammen, schermafbeeldingen, poorten en informatie over volumes konden rond de Compose-definitie worden toegevoegd.
- Bijdragers konden werk uit upstreamprojecten hergebruiken in plaats van een niet-gerelateerd, uitsluitend voor het platform bedoeld pakket te onderhouden.
- ZimaOS en CasaOS konden profiteren van het bredere selfhosting-ecosysteem.
Wat Docker Compose veranderde voor bijdragen vanuit de community
In het interview werd een vroege bijdrage vanuit de community als voorbeeld gebruikt. Tiger herinnerde zich dat een bijdrager met de naam Wisdom Sky in één nacht ongeveer 150 container-images omzette in CasaOS-apps, terwijl ondersteuning voor een op Compose gebaseerde App Store in opkomst was. Het team had eerder slechts een bescheiden stijging verwacht ten opzichte van het oude tempo van één of twee nieuwe apps per maand.
Dit was een anekdote uit het gesprek in 2024 en geen maatstaf voor hoe snel elke app kan worden verpakt. Elke app heeft nog steeds correcte poorten, volumes, architectuurondersteuning, machtigingen, updategedrag en beoordeling door een beheerder nodig.
Hoe appstores van derden in het ecosysteem passen
Het team beschreef ook ondersteuning voor appbronnen van derden. In plaats van te eisen dat elk communitypakket aan de officiële catalogus wordt toegevoegd, kon een beheerder een onafhankelijke bron hosten die gebruikers aan CasaOS of ZimaOS konden toevoegen.
Dit model vergroot de keuze en vermindert de beoordelingsachterstand bij het officiële team, maar maakt ook onderscheid tussen beschikbaarheid en goedkeuring. Het verschijnen van een app in een bron van derden betekent niet automatisch dat IceWhale de image onderhoudt, de code controleert, updates garandeert of het gedrag rond gegevensverwerking ondersteunt. Gebruikers moeten vóór installatie de uitgever van de image, de repository, de gevraagde bevoegdheden, de gekoppelde opslag, de netwerktoegang en de updategeschiedenis controleren.
De voorgestelde balans tussen open componenten en propriëtaire productcode
Tiger zei dat ZimaOS werd gebouwd op open CasaOS-componenten, waaronder delen van de basis voor de gateway en messagebus, terwijl andere productlagen propriëtair zouden blijven. Het team wilde open-sourcebijdragen blijven accepteren en overwoog meer API's beschikbaar te maken voor ontwikkelaars van extensies.
Het interview beweerde niet dat alle ZimaOS-code opensource zou worden. Het beschreef een hybride grens: herbruikbare interfaces en componenten voor de community beschikbaar stellen, terwijl geselecteerde productimplementaties privé blijven.
Wat modularisering met systemd-sysext mogelijk moest maken
In het gesprek werd een zeer vroeg mechanisme genoemd dat was gebaseerd op systemd-sysext. Het doel was om derden systeemextensies te laten toevoegen zonder de onveranderlijke kern rechtstreeks aan te passen, vergelijkbaar met het bouwen op basis van een gedefinieerde platforminterface.
Omdat Tiger dit werk nadrukkelijk als een vroege fase beschreef, moet dit gedeelte worden gelezen als architectuurcontext. Het bericht leverde geen openbare SDK voor extensies, stabiel API-contract, compatibiliteitsbeleid of bevestigde releasedatum.
Het bredere principe: standaarden hergebruiken in plaats van ze opnieuw uit te vinden
De meest blijvende conclusie was de voorkeur voor bestaande standaarden uit de community. Het hergebruik van Docker en Compose verminderde het platformspecifieke werk voor zowel het IceWhale-team als appbijdragers en verbond de App Store tegelijkertijd met een veel grotere verzameling selfhostingsoftware.
Het huidige overzicht van ZimaOS presenteert nu een scenario-gebaseerde App Store, Docker-ondersteuning van derden en een catalogus met meer dan 800 apps. Deze actuele productbeschrijving laat zien hoe het ecosysteem zich heeft ontwikkeld, terwijl het interview uit 2024 de ontwerpredenering uitlegt die eraan voorafging.
Bekijk het oorspronkelijke gesprek over het appstore-ecosysteem
De volledige video bewaart de toon en historische context van de bespreking tussen Axel en Tiger.
Veelgestelde vragen over het ZimaOS-appstore-ecosysteem
Waarom stapte CasaOS af van een uitsluitend aangepast JSON-appformaat?
Het aangepaste formaat voegde een leerstap toe voor bijdragers. Met Docker Compose konden beheerders een breed begrepen servicedefinitie hergebruiken en de metagegevens toevoegen die de App Store nodig had.
Zijn appstores van derden voor ZimaOS hetzelfde als de officiële App Store?
Nee. Bronnen van derden kunnen de beschikbaarheid van apps uitbreiden, maar hun pakketten kunnen door andere mensen worden onderhouden en beoordeeld. Gebruikers moeten de bron en containerconfiguratie vóór installatie beoordelen.
Bevestigde het interview een openbare extensie-API voor ZimaOS?
Nee. Het team zei dat het API's, workshops en de ontwikkeling van extensies overwoog. In het gesprek werd geen stabiele API of leverdatum gepubliceerd.
Was systemd-sysext in mei 2024 al een voltooide functie van ZimaOS?
Nee. Tiger beschreef het modulariseringsmechanisme als zeer vroeg in ontwikkeling. Het werd gepresenteerd als een mogelijke route voor extensies rond een onveranderlijke kern.
Is alle ZimaOS-code opensource?
Het interview beschreef een balans tussen open componenten en propriëtaire productcode, niet een volledig opensourcebesturingssysteem.
