Podczas rozmowy społeczności w maju 2024 r. dyrektor techniczny IceWhale, Tiger, oraz deweloper społeczności Axel omówili, dlaczego ekosystem aplikacji CasaOS i rozwijającego się ZimaOS zaczął zmierzać w stronę wspólnych standardów kontenerów zamiast polegać na specyficznym dla platformy formacie pakietów.
Główna idea była prosta: ekosystem aplikacji rozwija się szybciej, gdy deweloperzy mogą ponownie wykorzystywać znane pliki Docker Compose, dodawać niewielką ilość metadanych sklepu z aplikacjami i dystrybuować aplikacje bez konieczności uzgadniania każdego wkładu bezpośrednio z głównym zespołem.
Był to kierunek techniczny z 2024 roku, a nie aktualna specyfikacja wydania
Rozmowa odbyła się, gdy ZimaOS nadal rozwijał się na bazie fundamentów współdzielonych z CasaOS. Wypowiedzi dotyczące przyszłych interfejsów API, warsztatów, rozszerzeń firm trzecich i modularyzacji za pomocą systemd-sysext opisywały ówczesne zamierzenia lub eksperymenty na wczesnym etapie. Nie należy ich interpretować jako obietnic, że każda z tych koncepcji zostanie zrealizowana w sugerowanym terminie.
Dlaczego wczesny niestandardowy format aplikacji JSON powodował problemy
Tiger wyjaśnił, że wczesny sklep z aplikacjami CasaOS korzystał z niestandardowego formatu JSON. Plik opisywał metadane obrazu Dockera, w tym tytuł aplikacji, ikonę, zrzuty ekranu i szczegóły konfiguracji.
Problem nie polegał na tym, że JSON nie nadawał się do opisywania aplikacji. Chodziło o wdrażanie nowych współtwórców: każda osoba, która chciała opublikować aplikację, musiała najpierw nauczyć się formatu właściwego dla CasaOS. Ten dodatkowy etap tłumaczenia ograniczał tempo, w jakim istniejące projekty kontenerowe mogły stawać się instalowalnymi aplikacjami.
Dlaczego Docker Compose stał się podstawą pakowania aplikacji
Zespół uznał, że Docker Compose jest wystarczająco rozszerzalny, aby przechowywać definicję kontenera i jednocześnie obsługiwać dodatkowe metadane potrzebne sklepowi z aplikacjami. Dzięki temu istniejące projekty Compose można było dostosowywać zamiast przebudowywać je w oddzielnym systemie pakowania.
Zmieniło to model współtworzenia:
- Obrazy kontenerów i definicje usług mogły nadal korzystać ze znanych konwencji Dockera.
- Pola sklepu z aplikacjami, takie jak tytuły, ikony, zrzuty ekranu, porty i informacje o wolumenach, można było dodawać do definicji Compose.
- Współtwórcy mogli ponownie wykorzystywać pracę z projektów nadrzędnych zamiast utrzymywać niezależny pakiet przeznaczony wyłącznie dla danej platformy.
- ZimaOS i CasaOS mogły korzystać z większego ekosystemu self-hostingu.
Co Docker Compose zmienił we współtworzeniu aplikacji przez społeczność
W wywiadzie jako przykład wykorzystano wczesny wkład społeczności. Tiger wspominał, że współtwórca znany jako Wisdom Sky przekształcił około 150 obrazów kontenerów w aplikacje CasaOS w ciągu jednej nocy, gdy wsparcie sklepu z aplikacjami oparte na Compose dopiero się rozwijało. Wcześniej zespół spodziewał się jedynie niewielkiego wzrostu względem dotychczasowego tempa jednej lub dwóch nowych aplikacji miesięcznie.
Była to anegdota z rozmowy z 2024 roku, a nie punkt odniesienia dla szybkości pakowania każdej aplikacji. Każda aplikacja nadal wymaga prawidłowej konfiguracji portów i wolumenów, obsługi architektury, uprawnień, sposobu aktualizacji oraz weryfikacji przez opiekuna.
Jak sklepy z aplikacjami firm trzecich wpisują się w ekosystem
Zespół opisał również obsługę źródeł aplikacji firm trzecich. Zamiast wymagać, aby każdy pakiet społeczności trafiał do oficjalnego katalogu, opiekun mógł prowadzić niezależne źródło, które użytkownicy mogli dodać do CasaOS lub ZimaOS.
Ten model zwiększa wybór i zmniejsza wąskie gardło związane z weryfikacją przez oficjalny zespół, ale jednocześnie oddziela dostępność od rekomendacji. Pojawienie się aplikacji w źródle firmy trzeciej nie oznacza automatycznie, że IceWhale utrzymuje jej obraz, kontroluje jej kod, gwarantuje aktualizacje lub wspiera sposób przetwarzania danych. Przed instalacją użytkownicy powinni sprawdzić wydawcę obrazu, repozytorium, wymagane uprawnienia, mapowane miejsce na dane, ekspozycję sieciową i historię aktualizacji.
Proponowana równowaga między otwartymi komponentami a zastrzeżonym kodem produktu
Tiger powiedział, że ZimaOS jest budowany na otwartych komponentach CasaOS, w tym na elementach jego fundamentów w postaci bramy i magistrali komunikatów, podczas gdy inne warstwy produktu pozostaną zastrzeżone. Zespół chciał nadal przyjmować wkład open source i rozważał udostępnienie większej liczby interfejsów API deweloperom rozszerzeń.
Wywiad nie stwierdzał, że cały kod ZimaOS stanie się otwartoźródłowy. Opisywał hybrydową granicę: udostępnianie wielokrotnego użytku interfejsów i komponentów przeznaczonych dla społeczności przy jednoczesnym zachowaniu prywatności wybranych elementów implementacji produktu.
Co miała umożliwić modularyzacja za pomocą systemd-sysext
W rozmowie wspomniano o bardzo wczesnym mechanizmie opartym na systemd-sysext. Jego celem było umożliwienie firmom trzecim dodawania rozszerzeń na poziomie systemu bez bezpośredniej modyfikacji niezmiennego rdzenia, podobnie jak w przypadku tworzenia oprogramowania na podstawie zdefiniowanego interfejsu platformy.
Ponieważ Tiger wyraźnie opisał tę pracę jako znajdującą się na wczesnym etapie, tę część należy traktować jako kontekst architektoniczny. Wpis nie przedstawiał publicznego SDK rozszerzeń, stabilnego kontraktu API, zasad zgodności ani potwierdzonej daty wydania.
Szersza zasada: korzystać ze standardów zamiast wymyślać je na nowo
Najważniejszym trwałym wnioskiem była preferencja dla istniejących standardów społeczności. Ponowne wykorzystanie Dockera i Compose ograniczyło liczbę prac specyficznych dla platformy zarówno po stronie zespołu IceWhale, jak i twórców aplikacji, a jednocześnie połączyło sklep z aplikacjami ze znacznie większą pulą oprogramowania self-hostingowego.
Aktualny opis ZimaOS przedstawia obecnie sklep z aplikacjami oparty na scenariuszach, obsługę Dockera firm trzecich oraz katalog obejmujący ponad 800 aplikacji. Ten aktualny opis produktu pokazuje, jak rozwinął się ekosystem, podczas gdy wywiad z 2024 roku wyjaśnia przesłanki projektowe, które go poprzedziły.
Obejrzyj oryginalną rozmowę na temat ekosystemu sklepu z aplikacjami
Pełne nagranie zachowuje charakter i historyczny kontekst dyskusji Axela z Tigerem.
FAQ dotyczące ekosystemu sklepu z aplikacjami ZimaOS
Dlaczego CasaOS odszedł od niestandardowego formatu aplikacji opartego wyłącznie na JSON?
Niestandardowy format dodawał współtwórcom dodatkowy etap nauki. Docker Compose pozwolił opiekunom ponownie wykorzystywać powszechnie rozumianą definicję usługi i dodawać metadane potrzebne sklepowi z aplikacjami.
Czy sklepy z aplikacjami ZimaOS firm trzecich są tym samym co oficjalny sklep z aplikacjami?
Nie. Źródła firm trzecich mogą zwiększać dostępność aplikacji, ale ich pakiety mogą być utrzymywane i weryfikowane przez inne osoby. Przed instalacją użytkownicy powinni ocenić źródło i konfigurację kontenera.
Czy wywiad potwierdził istnienie publicznego API rozszerzeń ZimaOS?
Nie. Zespół powiedział, że rozważa interfejsy API, warsztaty i rozwój rozszerzeń. W rozmowie nie opublikowano stabilnego API ani terminu udostępnienia.
Czy systemd-sysext był już ukończoną funkcją ZimaOS w maju 2024 roku?
Nie. Tiger określił mechanizm modularyzacji jako znajdujący się na bardzo wczesnym etapie. Przedstawiono go jako możliwą drogę tworzenia rozszerzeń wokół niezmiennego rdzenia.
Czy cały kod ZimaOS jest open source?
Wywiad opisywał równowagę między otwartymi komponentami a zastrzeżonym kodem produktu, a nie system operacyjny w pełni open source.
