Haz aplicaciones para Linux

Artículo original ↗ Discusión en Hacker News ↗

Los llamamientos a “dejar de hacer distribuciones de Linux y hacer aplicaciones en su lugar” han reavivado tensiones de larga data sobre fragmentación, usabilidad y prioridades en el ecosistema Linux. Los comentaristas argumentan que, aunque hay incontables distros y gestores de ventanas, las apps para el usuario final —especialmente las pulidas y centradas en la UX— siguen siendo escasas, obstaculizadas por empaquetado inconsistente, ABI inestables y elecciones confusas de toolkits (Qt, GTK, Electron, Flutter, etc.). Muchos ven las tecnologías multiplataforma o web y nuevos formatos de empaquetado como Flatpak como vías pragmáticas, pero no hay consenso sobre cómo equilibrar la comodidad del desarrollador, la experiencia del usuario, la apertura y el deseo de obtener un ingreso sostenible con software para Linux.

Fragmentación de distribuciones vs. aplicaciones

  • Muchos sostienen que Linux tiene demasiadas distribuciones, lo que provoca “parálisis por elección” y diluye el esfuerzo que podría dedicarse a las aplicaciones y a la UX.
  • Otros dicen que la fragmentación se exagera: la mayoría de los usuarios de escritorio ejecutan Debian/Ubuntu/Mint o algo similar; puedes “elegir una” y listo.
  • Algunos ven los llamados a un “único y verdadero Linux” como una centralización motivada comercialmente; la diversidad se presenta como creatividad y seguridad (evitar la monocultura).
  • Contraargumento: la diversidad complica la vida de los desarrolladores de apps, que deben navegar por distintas distros, DEs y componentes básicos (Wayland/X11, systemd, etc.).

Empaquetado, ABI y “apuntar a todas las distros”

  • Los desarrolladores debaten cuán realista es compilar una vez y ejecutar en todas partes.
  • Enfoque tradicional: distribuir código fuente y usar los gestores de paquetes de la distro, o depender de quienes mantienen los paquetes; los desarrolladores propietarios a menudo simplemente prueban en una distro y aceptan que los usuarios hagan ajustes.
  • La distribución binaria se ve obstaculizada por problemas de ABI de glibc / libstdc++ y por símbolos versionados de .so; los desarrolladores de juegos en Steam lo sufren de forma especialmente aguda.
  • AppImage, Flatpak, Snap, Steam Runtime y los contenedores se consideran soluciones parciales, pero añaden complejidad y no ocultan por completo el cambio de ABI.
  • Los esquemas de nombres de bibliotecas (-dev, números de versión) confunden a los recién llegados, pero se explican como versionado de ABI y separación entre cabeceras y tiempo de ejecución.

Toolkits y frameworks multiplataforma

  • GNOME/GTK y KDE/Qt son las principales pilas nativas, pero se les critica por cambiar APIs, tener UX desigual y un alcance multiplataforma limitado.
  • Comparación con macOS/Windows: esas plataformas ofrecen frameworks base más ricos y estables (gráficos, audio, ML, etc.), lo que hace que desarrollar apps sea más fluido.
  • Electron es ampliamente criticado por ser voluminoso, pero se le reconoce por facilitar el soporte en Linux y permitir muchas apps populares.
  • Se mencionan alternativas: Flutter, Kirigami/QtQuick, Java/JavaFX, NW.js, Wails, WebUI; las opiniones difieren sobre rendimiento, madurez y calidad de UX.
  • Algunos dicen que desarrollar GUI para Linux no resulta atractivo porque hay que elegir entre varias pilas imperfectas.

UX, cultura de la línea de comandos y enfoque en el usuario final

  • Un hilo recurrente: Linux y el software libre suelen invertir poco en UX; muchos usuarios aceptan un acabado pobre en comparación con macOS/Windows.
  • Debate entre CLI y GUI: algunos afirman que las CLIs son la “UX máxima” para usuarios competentes; otros argumentan que las CLIs son un infierno de descubribilidad y hostiles para no expertos.
  • Varios comentaristas subrayan que los usuarios promedio necesitan apps intuitivas y visualmente coherentes, no más gestores de ventanas en mosaico ni herramientas de nicho.

Monetización y economía del código abierto

  • Varios mensajes describen lo difícil que es ganarse la vida con apps de FOSS (los anuncios, las donaciones y las funciones premium suelen rendir poco).
  • Algunos desarrolladores consideran o defienden pasar a código cerrado (o a código disponible pero binarios de pago) para financiar apps de Linux pulidas y orientadas a la UX.
  • Otros enfatizan que un gran subconjunto de usuarios de Linux prefiere firmemente el FOSS por razones de privacidad, longevidad y para evitar el bloqueo; las apps propietarias pueden perder a ese público.
  • Se discuten varios modelos de negocio: contratos de soporte, donaciones/patrocinios, open core, hosting de pago, binarios de pago con código disponible.

Colaboración vs. “otra app/otra distro más”

  • Un sector insta a contribuir a las apps existentes en lugar de reimplementar herramientas similares o crear nuevas distros; ese enfoque podría dar lugar a unas pocas apps excelentes en vez de muchas mediocres.
  • Otro sector sostiene que el esfuerzo y la motivación de los desarrolladores no son fungibles: la gente hackea en lo que le interesa, no le gusta la política de proyectos y valora la autonomía de “rascarse su propia picazón”.
  • La conclusión en el hilo es mixta: se desean más y mejores apps, pero los intentos de dirigir de forma centralizada el trabajo de los aficionados se ven como poco realistas y contrarios al espíritu del software libre.