Ubuntu busca convertir sus Snaps en un estándar para todas las distros GNU/Linux

Aún así esos 287 MB no se comparan con los 156 MB utilizando Flatpak.

Una cosa que no se ha mencionado, es que Canonical no está trabajando con la comunidad para implementar Snap, sino están creando repositorios externos para hacer instalable snapd en otrasd distribuciones. Además el sistema de distribución es centralizado y para poder publicar una aplicación en la tienda de software de Ubuntu, hay que firmar un acuerdo CLA obligatorio. Por lo tanto, utilizar un repositorio centralizado y un servidor cerrado de Canonical para la distribución de aplicaciones en todas partes me parece que se aleja de la idea principal y es que cada desarrollador puede distribuir sus aplicaciones directamente y sin intermediarios.

Por ahora la principal pega que le encuentro es la duplicación de librerías y software adicional. Cada aplicación incluiría dentro de su paquete las librerías adicionales que la hacen funcionar, pero muchas de ellas son compartidas con otras aplicaciones, por lo que tendríamos, por ejemplo, decenas de veces repetida la librería necesaria para cierta tarea o trabajar con cierto formato que fueran lo bastante comunes.

Siguen habiendo aspectos negativos de la implementación de Snap, como la necesidad de instalar una parte de Ubuntu en nuestras distribuciones para que snap funcione (ubuntu-core). Lo más probable es que agreguen stacks básicos a ubuntu core para compartir esas librerías con otras aplicaciones y evitar la duplicación de procesos. Sigue siendo negativo depender de otra empresa en este aspecto.

Sobre "el trabajo" de la comunidad según Canonical, puedes revisar foros, listas de correos de proyectos (fedora, mint, arch linux, etc) o Reddit y te enterarás que no hubo tal trabajo, simplemente eran empleados de Canonical que implementaron repositorios externos para añadir Snapd a diferentes distribuciones. No presentaron su idea con anterioridad en eventos, conferencias de desarrolladores, listas de correo, etc. No hubo conversación previa o posterior al anuncio y solo existe trabajo de empleados de Canonical como "voluntarios" en otros proyectos. Recientemente en WeblogSl se "anunció" que los Snaps llegaron a ElementaryOS, pero simplemente fue que un empleado de Canonical añadió soporte a la versión beta de ElementaryOS Loki.

Sobre el objetivo de tecnologías como Snap o Flatpak, es acercar el desarrollador de software con sus usuarios y así poder distribuir directamente sus aplicaciones y que éstas puedan ser utilizadas en cualquier distribución. Transformarse en el distribuidor oficial, con un repositorio centralizado y alojado en un servidor cerrado, obligado a firmar un acuerdo con Canonical se aleja de eso. Actualmente afirman la posibilidad de añadir servidores personalizados, pero la gracia es que los desarrolladores tienen que hacer ingeniería inversa a Snapd e ingeniarselas para que ésto funcione por su cuenta, ya que ese código no será liberado.... (sin palabras).

Si la intención es distribuirlas independientemente entonces da igual que sea "controlado" por canonical que no. Nada va impedir al sistema coger e instalar un snap como hoy se usa un deb. Lo acabo de probar, y he instalado LibreOffice beta sin ser de los repositorios. Y de hecho funciona bastante bien.
Y lo siento por flatpak, pero si Canonical va a darle un empujón importante a Snap y realmente funciona en todas las distribuciones (en plan "build once, run anywhere"), pues no me importa dejar atrás a flatpak.

El paquete de LibreOffice no es oficial y está siendo creado por un empleado de Canonical (TDF apoya a Flatpak). Teniendo en consideración que snapd está en desarrollo activo, se permiten esas licencias para hacer pruebas de software.

Sin embargo, está planificado un funcionamiento similar a la Play Store, así que cualqueir Snap fuera de la tienda será bloqueado y en el caso de darle permisos, será marcado como inseguro. Más adelante podrás descargar un archivo Snap, pero si lo haces desde la tienda de Ubuntu y con previa inscripción.

Lo dudo, solo mira como terminó Unity, Mir y Upstart (solo canonical lo usa).

Aparte, que esta ves a canonical le dio por poner que snap era apoyado por otras comunidades cuando no es así (fea mentira para darse publicidad), solo usaron repos no oficiales en fedora y en ARCH (flatpak, aquí si está en oficiales), o sea, los "PPA" de las otras distros. El apoyo nunca estuvo, realmente (en los foros gringos se amó un "flame" de los buenos xD).

Canonical, ganado no tiene nada, ni va a dar ningún "empujón" con esta publicidad, solo se hará peor fama (ahora de mentiroso) dentro de la comunidad y eso no es bueno si se considera que para que algo de verdad triunfe y mejore dentro de GNU/Linux debe tener el apoyo de la misma para que otros desarrolladores se involucren.

Si canonical de verdad quiere darle un empujón a snap, que lo mejore hasta superar a cualquier otro, cosa que aún no sucede (no descarto que sea posible).

Canonical tiende siempre a imitar tareas que otros ya están haciendo como en este caso existe fatpak (antes xdg-app), OStree (el que usa ChromeOS), Guix (en el que se inspiró flatpak) o el viejo appimage, snap llegó tarde y los originales no solo funcionan mejor, si no que varios son apoyados de verdad por las comunidades.

Hasta ahora de todos esas "versiónes canonical" solo a Unity le he visto sentido real (Gnome 3 dio un salto muy loco), el resto supongo que lo hacen para depender lo menos posible de la comunidad.

Por suerte, en el mundo de GNU/Linux, las cosas no funcionan como en otros y el que hace más publi gana, lo que termina ganando suele ser lo que mejor funcione, mientras el resto se mantienen vivos, pero solo como alternativas.

Canonical no lo hace mal, pero tampoco lo hace bien siempre: La versión 14.04 fue toda una goleada (salió muy bien pulida), pero otras cosas como los mencionados en el primer párrafo se equivocan y yo sinceramente espero (por no decir, pronostico) que lo mismo le pase con Snap: que solo lo use Ubuntu, hasta que tenga que seguir los pasos de Debian como lo hiso con systemd.