2024年5月のコミュニティ対談で、IceWhaleのCTOであるTigerとコミュニティ開発者のAxelは、CasaOSと発展途上のZimaOSアプリエコシステムが、プラットフォーム固有のパッケージ形式に依存するのではなく、共通のコンテナ標準へ移行した理由について語りました。
中心となる考え方はシンプルでした。開発者が使い慣れたDocker Composeファイルを再利用し、少量のアプリストア用メタデータを追加して、コアチームと各コントリビューションについて個別に調整することなくアプリを配布できれば、アプリエコシステムはより速く成長します。
これは2024年時点の技術方針であり、現在のリリース仕様ではありません
この対談は、ZimaOSがCasaOSと共有する基盤から発展していた時期に行われました。当時の将来API、ワークショップ、サードパーティ拡張機能、systemd-sysextによるモジュール化に関する発言は、その時点での意図や初期段階の実験について述べたものです。すべての概念が提案されたスケジュールどおりに実装されたという保証として解釈すべきではありません。
初期のカスタムJSONアプリ形式が摩擦を生んだ理由
Tigerは、初期のCasaOS App StoreがカスタムJSON形式を使用していたと説明しました。このファイルには、アプリのタイトル、アイコン、スクリーンショット、設定の詳細など、Dockerイメージに関するメタデータが記述されていました。
問題は、JSONではアプリを記述できなかったことではありません。問題は、コントリビューターの参加にありました。アプリを公開したい人は、まずCasaOS専用の形式を学ぶ必要がありました。この追加の変換作業によって、既存のコンテナプロジェクトをインストール可能なアプリへ移行できる速度が制限されていました。
Docker Composeがアプリパッケージングの基盤になった理由
チームは、Docker Composeがコンテナ定義を扱うのに十分な拡張性を持ち、同時にApp Storeに必要な追加メタデータにも対応できることを確認しました。そのため、既存のComposeプロジェクトを別のパッケージシステムで作り直すのではなく、適応させることが可能になりました。
これにより、コントリビューションモデルが変わりました。
- コンテナイメージとサービス定義では、使い慣れたDockerの規約を引き続き利用できる。
- タイトル、アイコン、スクリーンショット、ポート、ボリューム情報などのApp Store用フィールドを、Compose定義に追加できる。
- コントリビューターは、プラットフォーム専用の無関係なパッケージを保守するのではなく、上流の成果物を再利用できる。
- ZimaOSとCasaOSは、より広範なセルフホスティングエコシステムの恩恵を受けられる。
Docker Composeがコミュニティからのコントリビューションにもたらした変化
インタビューでは、初期のコミュニティコントリビューションが例として取り上げられました。Tigerによると、Wisdom Skyという名前で知られるコントリビューターが、ComposeベースのApp Storeサポートが発展し始めた時期に、一晩でおよそ150個のコンテナイメージをCasaOSアプリに変換しました。チームは以前、従来の月1～2個の新規アプリというペースから、わずかな増加にとどまると予想していました。
これは2024年の対談で語られたエピソードであり、すべてのアプリをパッケージ化できる速度のベンチマークではありません。各アプリには、正しいポート、ボリューム、アーキテクチャ対応、権限、更新動作、メンテナーによるレビューが引き続き必要です。
サードパーティアプリストアがエコシステムに適合する仕組み
チームは、サードパーティのアプリソースへの対応についても説明しました。すべてのコミュニティパッケージを公式カタログに登録するよう求めるのではなく、メンテナーが独立したソースをホストし、ユーザーがそれをCasaOSまたはZimaOSに追加できるという仕組みです。
このモデルは選択肢を広げ、公式チームのレビューボトルネックを軽減しますが、提供されていることと推奨されていることは分離されます。サードパーティソースに表示されるアプリが、IceWhaleによってイメージの保守、コードの監査、更新の保証、データ取り扱い動作のサポートまで行われているとは限りません。インストール前に、イメージの公開元、リポジトリ、要求される権限、割り当てられたストレージ、ネットワークへの公開範囲、更新履歴を確認してください。
オープンコンポーネントとプロプライエタリな製品コードの提案されたバランス
Tigerは、ZimaOSがゲートウェイやメッセージバスの基盤の一部を含むオープンなCasaOSコンポーネント上に構築されており、一方で他の製品レイヤーはプロプライエタリなままになると述べました。チームはオープンソースのコントリビューションを引き続き受け入れたいと考えており、拡張機能の開発者向けにより多くのAPIを公開することも検討していました。
インタビューでは、ZimaOSのすべてのコードがオープンソースになるとは述べていません。再利用可能なインターフェースとコミュニティ向けコンポーネントを公開しつつ、選択した製品実装は非公開にするという、ハイブリッドな境界について説明していました。
systemd-sysextによるモジュール化で実現しようとしていたこと
この対談では、systemd-sysextをベースとした非常に初期段階の仕組みについて触れられました。目的は、定義されたプラットフォームインターフェースを基盤に開発する場合と原理的に同様に、イミュータブルなコアを直接変更せず、サードパーティがシステムレベルの拡張機能を追加できるようにすることでした。
Tigerがこの取り組みを明確に初期段階だと説明していたため、このセクションはアーキテクチャの背景として読むべきです。この投稿では、公開された拡張機能SDK、安定したAPI契約、互換性ポリシー、確定したリリース日については説明していません。
より広い原則：標準を再発明せず、再利用する
最も長期的に重要な点は、既存のコミュニティ標準を優先する姿勢でした。DockerとComposeを再利用することで、IceWhaleチームとアプリコントリビューターの双方にとってプラットフォーム固有の作業が減り、App Storeをより大規模なセルフホスティングソフトウェアの集合に接続できました。
現在のZimaOS概要では、シナリオベースのApp Store、サードパーティDocker対応、800を超えるアプリのカタログが紹介されています。この現在の製品説明はエコシステムがどのように発展したかを示しており、2024年のインタビューはその前段となった設計上の理由を説明しています。
元のApp Storeエコシステム対談を見る
完全版の動画では、AxelとTigerの対談の雰囲気と歴史的背景を確認できます。
ZimaOS App Storeエコシステムに関するFAQ
CasaOSがカスタムJSONのみのアプリ形式から離れたのはなぜですか？
カスタム形式によって、コントリビューターには学習すべき手順が追加されていました。Docker Composeなら、広く理解されているサービス定義をメンテナーが再利用し、App Storeに必要なメタデータを追加できます。
サードパーティのZimaOSアプリストアは公式App Storeと同じものですか？
いいえ。サードパーティソースによってアプリの提供数は増やせますが、パッケージの保守やレビューを担当する人は異なる場合があります。インストール前に、ソースとコンテナ設定を評価してください。
インタビューでは、公開されたZimaOS拡張機能APIが確認されましたか？
いいえ。チームはAPI、ワークショップ、拡張機能開発を検討していると述べましたが、対談では安定したAPIや提供時期は公開されませんでした。
2024年5月の時点で、systemd-sysextはすでに完成したZimaOSの機能でしたか？
いいえ。Tigerはこのモジュール化の仕組みを非常に初期段階のものだと説明しました。これは、イミュータブルなコアの周辺で拡張機能を実現する可能性のある方法として紹介されたものです。
ZimaOSのコードはすべてオープンソースですか？
インタビューで説明されたのは、オープンなコンポーネントとプロプライエタリな製品コードのバランスであり、完全なオープンソースOSではありません。
