Este texto es algo simple y está dirigido a quienes usan Linux principalmente y a quienes simplemente hacen software, siempre hay mucho debate sobre que algo no funciona como debe, o que han implementado algo que no te gusta, etc.

Yo pienso lo siguiente: si el software no se adapta a tus necesidades, si no funciona como esperas, si sientes que sus devs te ignoran y no eres importante para el desarrollo, entonces no pierdas tiempo en intentar “arreglar” eso, la mayoría del tiempo no va a funcionar, solo terminará en debates interminables con mucha soberbia por parte de quienes no entienden tu punto. No pierdas tu tiempo en eso: construye una alternativa o ayuda a potenciar una existente

Las alternativas no nacen, se hacen

Si te quedas sentado esperando que alguien más resuelva el problema por ti, sin mover un solo dedo, es poco probable que algo suceda. Si lees esto y piensas: “¡Pero yo no escribo código!”, tranqui, no me refiero solo a eso.

Tenemos un concepto erróneo de que el software de código abierto nace y se constituye única y exclusivamente por quien hace el código, eso es un error en la mayoría de los casos, los aportes de quienes no pueden aportar código también son importantes.

Míralo así: no sabes nada de código, pero, hablas el idioma original usado en la app, y quieres que otras personas que hablan tu lengua nativa tengan la oportunidad de conocerlo, bueno, ahí tienes una tarea: traduce, traduce y no te detengas, es una realidad que mucha gente evita software que no está en su idioma. Una traducción puede ser una gran ayuda para la expansión de una alternativa.

Puedes promover una alternativa, de muchas formas, en tus redes, con amigos, con familiares. Siempre habrá alguien dispuesto a escuchar.

Mi punto es: no saber nada de código no es una limitante, puedes ayudar de muchas formas, hasta económicamente.

También: tus punto de vista importan. Una buena sugerencia puede cambiar el rumbo de un proyecto de formas inesperadas. He visto esto, no es un cuento chino. En proyectos donde he sido muy activo, mis sugerencias y las del resto de personas involucradas, aún cuando no hemos aportado código, han ayudado a formar parte de la identidad de una app.

Si eres un dev, no te cierres a seguir solamente tu visión, vivimos en un mundo diverso, el open source es diverso, diferentes visiones, diferentes ideas, puede que sea molesto recibir sugerencias o ideas de gente que no sabe ni como implementarlas, pero ten empatía, intenta entender, quizás hay buenas ideas que te estás perdiendo por cerrarte.

¿Por qué necesitamos alternativas?

Porque si hay una sola app para hacer una sola cosa, y es la única relevante, sin competencia alguna, entonces tiene un poder inmenso que nadie debería tener:

• Pueden implementar funciones problemáticas sin que nadie pueda oponerse, porque es lo que hay.
• Pueden definir como debería hacerse algo aunque toda una comunidad no esté de acuerdo.
• Pueden crecer y volverse tan grandes que pensar en usar software diferente podría ser considerado imposible.
• Y por último, pueden hacer que una sola visión reine por encima de todo lo demás, sin más visiones, sin más ideas, solamente las suyas y las que ellos aprueben

De esto te puedo dar un par de ejemplos claros: Chromium, y Flatpak.

Chromium es el gran motor que impulsa a la mayoría de navegadores actuales, aunque esos navegadores son básicamente forks y cada quien añade lo que quiera y demás, es innegable la gran influencia de Google en esto y su gran porción del pastel, Google define y gobierna Chromium, y eso está mal, de nuevo, nadie debería tener tanto poder.

Y sí, existe Firefox, es precisamente una alternativa, una alternativa inferior y con personas problemáticas dirigiendo su rumbo, pero sí. Aunque en general sufre el mismo problema, piensa esto: ¿Si Google renunciara a Chromium mañana y los ingenieros de Google ya no tuviesen permitido aportar código, podría el ecosistema sobrevivir y mantener algo tan grande y tan ligado a Google? si la respuesta es no, entonces entiendes el problema. Lo mismo pasa con Firefox, hay muchos forks de Firefox, pero seamos honestos: ninguno podría mantener la base si Mozilla desapareciera mañana

En Linux pasa algo similar con Flatpak, bueno, en algunos contextos, como en entornos musl, la dependencia de Flatpak en esos entornos podría ser casi que obligatoria ante la ausencia de paquetes nativos.

Eso es un problema, es un problema porque honestamente parece que a los devs de Flatpak no les importan los usuarios fuera de glibc y fuera de systemd, más allá de rumores y demás, hay una realidad: ¿vale la pena intentar arreglar un software que parece no considerarnos a quienes somos la minoría? por eso importan las alternativas, esa dependencia de Flatpak en tales entornos debe ser combatida, debe haber una opción.

Mi apuesta por una alternativa a Flatpak: Anylinux Appimages

Actualmente escribo esto desde Obsidian, mi software favorito para escribir mis cosas… y, estoy en Alpine Linux, una distro que usa musl libc en vez de glibc, es decir, una distro “no estándar”, gran parte del software compilado para Linux no considera a musl, so, los paquetes oficiales de Obsidian para Linux no funcionarán aquí.

La única forma real de usar Obsidian en Alpine es instalando la app desde Flatpak… pero, yo no uso Flatpak, no lo tengo ni instalado… entonces… ¿Cómo lo hago?

Les presento al proyecto Anylinux AppImages

Esto es una alternativa real, eficiente, y superior (en mi opinión) al modelo Flatpak, en vez de tener un paquete que requiere 8 o 10 runtimes para funcionar y ocupan montones de espacio, tienes un solo binario que empaqueta todo, una appimage universal que funciona en cualquier entorno, funcionan mientras se cumplan estas condiciones, no relacionadas entre sí, con que se cumpla una ya funcionan:

• Tienes FUSE instalado
• Tienes namespaces habilitados
• Tienes una carpeta tmp (o sea, cualquier Linux)

Como dije, no hay relación entre esas 3 opciones, es decir, si tienes FUSE, funcionarán, si no tienes FUSE intentará ir a por los namespaces, si eso no es posible irá a la opción segura: usará la carpeta tmp para descomprimir el contenido de la appimage y funcionar desde ahí.

Gracias a esto tienes un paquete realmente universal, sin depender de runtimes excesivos como Flatpak.

Grandioso, ¿no?

Ahora bien, me dirás: “Las AppImage no se integran al escritorio, y mantenerlas actualizadas es complicado” a lo que yo te daré esta respuesta: por si solas puede que estos paquetes no sean tan cómodos como usar Flatpak, pero, para eso están opciones como soar o AM, son gestores de paquetes agnósticos, si usas Android creo que el mejor ejemplo sería: son como Obtainium para Linux, si bien tienen repositorios propios que puedes usar si quieres y en donde están disponibles gran parte de estos paquetes, también puedes usarlos como quieras, es decir, añadir manualmente tus paquetes desde GitHub, etc. Yo hago eso con Soar, ya que tiene “paquetes declarativos”, es decir que puedo gestionar todo desde un archivo de texto.

Sé que esto no es para todos, no estoy diciendo que esto es un reemplazo inmediato, es una opción. Ahora quienes usamos musl, tenemos una opción que no es Flatpak.

Quiero promover esto, y quiero formar parte también, recientemente me uní para mantener un paquete, aunque mi intención es: añadir paquetes que yo pueda mantener, e impulsar en los repositorios upstream de ese paquete la idea de usar nuestro formato. Puede que no funcione siempre, lo espero, pero la idea es dejar claro que existe una alternativa, y que estamos ahí.

El resumen de todo esto es: necesitamos alternativas, siempre, mientras más mejor. Hay que construirlas, traducirlas, promoverlas, mantenerlas y así tener un ecosistema realmente diverso, realmente sano.

O al menos así es como yo lo veo, es solamente mi opinión

¿Que piensas tú?

Abajo hay comentarios pero si prefieres otra vía, puedes enviarme un email con tu opinión de todo esto: nubesu@tuta.io

Créditos de ilustraciones en la portada:

• Transhumans
• Humanities Illustration Library