In a May 2024 community conversation, IceWhale CTO Tiger and community developer Axel discussed why the CasaOS and emerging ZimaOS app ecosystem moved toward common container standards instead of relying on a platform-specific package format.
The central idea was simple: an app ecosystem grows faster when developers can reuse familiar Docker Compose files, add a small amount of app-store metadata, and distribute apps without negotiating every contribution directly with the core team.
This Was a 2024 Technical Direction, Not a Current Release Specification
The conversation took place while ZimaOS was still evolving from foundations shared with CasaOS. Statements about future APIs, workshops, third-party extensions, and systemd-sysext modularization described intentions or early-stage experiments at that time. They should not be interpreted as promises that every concept was delivered on the suggested timeline.
Why the Early Custom JSON App Format Created Friction
Tiger explained that the early CasaOS App Store used a custom JSON format. The file described metadata around a Docker image, including the app title, icon, screenshots, and configuration details.
The problem was not that JSON could not describe an app. The problem was contributor onboarding: anyone who wanted to publish an app first had to learn a format specific to CasaOS. That extra translation step limited how quickly existing container projects could become installable apps.
Why Docker Compose Became the App Packaging Foundation
The team found that Docker Compose was extensible enough to carry the container definition while accommodating the additional metadata needed by the App Store. Existing Compose projects could therefore be adapted instead of rebuilt in a separate packaging system.
This changed the contribution model:
- Container images and service definitions could continue using familiar Docker conventions.
- App Store fields such as titles, icons, screenshots, ports, and volume information could be added around the Compose definition.
- Contributors could reuse upstream work instead of maintaining an unrelated platform-only package.
- ZimaOS and CasaOS could benefit from the broader self-hosting ecosystem.
What Docker Compose Changed for Community Contributions
The interview used an early community contribution as an example. Tiger recalled that a contributor known as Wisdom Sky converted roughly 150 container images into CasaOS apps in one night while Compose-based App Store support was emerging. The team had previously expected only a modest increase over the old rate of one or two new apps per month.
This was an anecdote from the 2024 conversation, not a benchmark for how quickly every app can be packaged. Each app still needs correct ports, volumes, architecture support, permissions, update behavior, and maintainer review.
How Third-Party App Stores Fit the Ecosystem
The team also described support for third-party app sources. Instead of requiring every community package to enter the official catalog, a maintainer could host an independent source that users could add to CasaOS or ZimaOS.
This model expands choice and reduces the official team’s review bottleneck, but it also separates availability from endorsement. An app appearing in a third-party source does not automatically mean that IceWhale maintains its image, audits its code, guarantees updates, or supports its data-handling behavior. Users should verify the image publisher, repository, requested privileges, mapped storage, network exposure, and update history before installation.
The Proposed Balance Between Open Components and Proprietary Product Code
Tiger said ZimaOS was being built on open CasaOS components, including parts of its gateway and message-bus foundation, while other product layers would remain proprietary. The team wanted to continue accepting open-source contributions and was considering making more APIs available to extension developers.
The interview did not claim that all ZimaOS code would become open source. It described a hybrid boundary: expose reusable interfaces and community-facing components while keeping selected product implementation private.
What systemd-sysext Modularization Was Intended to Enable
The conversation mentioned a very early mechanism based on systemd-sysext. The goal was to let third parties add system-level extensions without directly modifying the immutable core, similar in principle to building against a defined platform interface.
Because Tiger explicitly described this work as early stage, this section should be read as architecture context. The post did not provide a public extension SDK, stable API contract, compatibility policy, or confirmed release date.
The Broader Principle: Reuse Standards Instead of Reinventing Them
The strongest durable takeaway was the preference for existing community standards. Reusing Docker and Compose reduced platform-specific work for both the IceWhale team and app contributors while connecting the App Store to a much larger pool of self-hosted software.
The current ZimaOS overview now presents a scenario-based App Store, third-party Docker support, and a catalog of more than 800 apps. That current product description shows how the ecosystem has developed, while the 2024 interview explains the design reasoning that preceded it.
Watch the Original App Store Ecosystem Conversation
The full video preserves the tone and historical context of the discussion between Axel and Tiger.
ZimaOS App Store Ecosystem FAQ
Why did CasaOS move away from a custom JSON-only app format?
The custom format added a learning step for contributors. Docker Compose allowed maintainers to reuse a widely understood service definition and add the metadata needed by the App Store.
Are third-party ZimaOS app stores the same as the official App Store?
No. Third-party sources can expand app availability, but their packages may be maintained and reviewed by different people. Users should evaluate the source and container configuration before installation.
Did the interview confirm a public ZimaOS extension API?
No. The team said it was considering APIs, workshops, and extension development. The conversation did not publish a stable API or delivery date.
Was systemd-sysext already a finished ZimaOS feature in May 2024?
No. Tiger characterized the modularization mechanism as very early stage. It was presented as a possible route for extensions around an immutable core.
Is all ZimaOS code open source?
The interview described a balance between open components and proprietary product code, not a fully open-source operating system.
