En una conversación de la comunidad celebrada en mayo de 2024, Tiger, director de tecnología de IceWhale, y Axel, desarrollador de la comunidad, analizaron por qué los ecosistemas de aplicaciones de CasaOS y del emergente ZimaOS avanzaron hacia estándares de contenedores comunes en lugar de depender de un formato de paquetes específico de la plataforma.
La idea central era sencilla: un ecosistema de aplicaciones crece más rápido cuando los desarrolladores pueden reutilizar archivos conocidos de Docker Compose, añadir una pequeña cantidad de metadatos de la tienda de aplicaciones y distribuir aplicaciones sin tener que negociar directamente cada contribución con el equipo principal.
Esta fue una orientación técnica de 2024, no una especificación de una versión actual
La conversación tuvo lugar mientras ZimaOS aún evolucionaba a partir de bases compartidas con CasaOS. Las declaraciones sobre futuras API, talleres, extensiones de terceros y la modularización mediante systemd-sysext describían intenciones o experimentos iniciales de aquel momento. No deben interpretarse como promesas de que todos los conceptos se implementarían en el plazo sugerido.
Por qué el primer formato de aplicaciones JSON personalizado generaba fricción
Tiger explicó que la primera tienda de aplicaciones de CasaOS utilizaba un formato JSON personalizado. El archivo describía los metadatos de una imagen de Docker, incluidos el título de la aplicación, el icono, las capturas de pantalla y los detalles de configuración.
El problema no era que JSON no pudiera describir una aplicación. El problema era la incorporación de colaboradores: cualquiera que quisiera publicar una aplicación primero tenía que aprender un formato específico de CasaOS. Ese paso adicional de traducción limitaba la rapidez con la que los proyectos de contenedores existentes podían convertirse en aplicaciones instalables.
Por qué Docker Compose se convirtió en la base del empaquetado de aplicaciones
El equipo descubrió que Docker Compose era lo bastante extensible como para contener la definición del contenedor y, al mismo tiempo, admitir los metadatos adicionales necesarios para la tienda de aplicaciones. Por lo tanto, los proyectos de Compose existentes podían adaptarse en lugar de reconstruirse en un sistema de empaquetado independiente.
Esto cambió el modelo de contribución:
- Las imágenes de contenedores y las definiciones de servicios podían seguir utilizando las convenciones conocidas de Docker.
- Los campos de la tienda de aplicaciones, como títulos, iconos, capturas de pantalla, puertos e información de volúmenes, podían añadirse alrededor de la definición de Compose.
- Los colaboradores podían reutilizar el trabajo original en lugar de mantener un paquete no relacionado y exclusivo de la plataforma.
- ZimaOS y CasaOS podían beneficiarse del ecosistema más amplio de autoalojamiento.
Qué cambió Docker Compose para las contribuciones de la comunidad
La entrevista utilizó una contribución inicial de la comunidad como ejemplo. Tiger recordó que un colaborador conocido como Wisdom Sky convirtió aproximadamente 150 imágenes de contenedores en aplicaciones de CasaOS en una noche, mientras surgía la compatibilidad de la tienda de aplicaciones basada en Compose. Anteriormente, el equipo esperaba solo un aumento moderado respecto al ritmo anterior de una o dos aplicaciones nuevas al mes.
Esta fue una anécdota de la conversación de 2024, no una referencia sobre la rapidez con la que puede empaquetarse cualquier aplicación. Cada aplicación sigue necesitando puertos, volúmenes, compatibilidad de arquitectura, permisos y comportamiento de actualización correctos, además de la revisión de un responsable de mantenimiento.
Cómo encajan las tiendas de aplicaciones de terceros en el ecosistema
El equipo también describió la compatibilidad con fuentes de aplicaciones de terceros. En lugar de exigir que cada paquete de la comunidad entrara en el catálogo oficial, un responsable de mantenimiento podía alojar una fuente independiente que los usuarios podían añadir a CasaOS o ZimaOS.
Este modelo amplía las opciones y reduce el cuello de botella de revisión del equipo oficial, pero también separa la disponibilidad del respaldo oficial. Que una aplicación aparezca en una fuente de terceros no significa automáticamente que IceWhale mantenga su imagen, audite su código, garantice las actualizaciones o respalde su comportamiento en el manejo de datos. Antes de instalarla, los usuarios deben verificar el editor de la imagen, el repositorio, los privilegios solicitados, el almacenamiento asignado, la exposición de red y el historial de actualizaciones.
El equilibrio propuesto entre componentes abiertos y código de producto propietario
Tiger afirmó que ZimaOS se estaba desarrollando sobre componentes abiertos de CasaOS, incluidas partes de sus bases de puerta de enlace y bus de mensajes, mientras que otras capas del producto seguirían siendo propietarias. El equipo quería continuar aceptando contribuciones de código abierto y estaba considerando poner más API a disposición de los desarrolladores de extensiones.
La entrevista no afirmó que todo el código de ZimaOS fuera a convertirse en código abierto. Describió un límite híbrido: exponer interfaces reutilizables y componentes orientados a la comunidad, manteniendo privadas determinadas partes de la implementación del producto.
Qué pretendía permitir la modularización mediante systemd-sysext
La conversación mencionó un mecanismo muy inicial basado en systemd-sysext. El objetivo era permitir que terceros añadieran extensiones a nivel del sistema sin modificar directamente el núcleo inmutable, de forma similar, en principio, a desarrollar sobre una interfaz de plataforma definida.
Como Tiger describió explícitamente este trabajo como una fase inicial, esta sección debe leerse como contexto arquitectónico. La publicación no proporcionó un SDK público de extensiones, un contrato de API estable, una política de compatibilidad ni una fecha de lanzamiento confirmada.
El principio más amplio: reutilizar estándares en lugar de reinventarlos
La conclusión más duradera fue la preferencia por los estándares existentes de la comunidad. Reutilizar Docker y Compose redujo el trabajo específico de la plataforma tanto para el equipo de IceWhale como para los colaboradores de aplicaciones, y conectó la tienda de aplicaciones con un conjunto mucho mayor de software de autoalojamiento.
La descripción actual de ZimaOS presenta ahora una tienda de aplicaciones basada en escenarios, compatibilidad con Docker de terceros y un catálogo de más de 800 aplicaciones. Esta descripción actual del producto muestra cómo se ha desarrollado el ecosistema, mientras que la entrevista de 2024 explica el razonamiento de diseño que lo precedió.
Mira la conversación original sobre el ecosistema de la tienda de aplicaciones
El vídeo completo conserva el tono y el contexto histórico del debate entre Axel y Tiger.
Preguntas frecuentes sobre el ecosistema de la tienda de aplicaciones de ZimaOS
¿Por qué CasaOS abandonó el formato de aplicaciones basado únicamente en JSON personalizado?
El formato personalizado añadía un paso de aprendizaje para los colaboradores. Docker Compose permitía a los responsables de mantenimiento reutilizar una definición de servicios ampliamente conocida y añadir los metadatos necesarios para la tienda de aplicaciones.
¿Las tiendas de aplicaciones de ZimaOS de terceros son iguales que la tienda de aplicaciones oficial?
No. Las fuentes de terceros pueden ampliar la disponibilidad de aplicaciones, pero sus paquetes pueden estar mantenidos y revisados por personas diferentes. Los usuarios deben evaluar la fuente y la configuración del contenedor antes de instalar.
¿La entrevista confirmó una API pública de extensiones de ZimaOS?
No. El equipo afirmó que estaba considerando API, talleres y desarrollo de extensiones. La conversación no publicó una API estable ni una fecha de entrega.
¿systemd-sysext ya era una función terminada de ZimaOS en mayo de 2024?
No. Tiger caracterizó el mecanismo de modularización como una iniciativa en una fase muy inicial. Se presentó como una posible vía para crear extensiones alrededor de un núcleo inmutable.
¿Todo el código de ZimaOS es de código abierto?
La entrevista describió un equilibrio entre componentes abiertos y código de producto propietario, no un sistema operativo completamente de código abierto.
