Hace unos meses me topé con la interesante opinión de Michael Cornelison, autor de aplicaciones como Fotoxx y Watsup. Aunque en un principio diferí en algunos aspectos planteados, tras hacer a un lado algunos paradigmas creados por el entusiasmo por el software libre, concluí que Cornelison tiene toda la boca llena de razón, particularmente en sus argumentos finales: tiene que haber una entidad unificada que coordine y consolide los proyectos.

Concuerdo con Cornelison respecto de que el sistema operativo dominante en el mercado del escritorio ―Microsoft Windows― tienen un elevado costo, es un imán para el malware y un continuo atentado contra la privacidad del usuario. Pese a que los escritorios Linux ofrecen una alternativa de muy bajo costo, son más seguros y respetan la privacidad del usuario, Windows sigue ―y seguirá siendo― quien domine el mercado gracias a que las alternativas ofrecidas por el software libre han fracasado en proveer una alternativa lo suficientemente atractiva para la mayoría de los usuarios finales y ―sobre todo― fabricantes de equipo de cómputo.

Definamos «fracaso». Desde hace más de 25 años, el escritorio Linux ha fallado en posicionarse en más allá del 1% a 2% de la cuota de mercado de computadoras de escritorio y portátiles. Hay también mucha resistencia de la mayor parte de las industrias para adoptar Linux como escritorio por muy diversos y complejos motivos.

1. «Balcanización».

Este término peyorativo se acuñó tras la disolución de Yugoslavia y las guerras derivadas ocurridas a fines del siglo XX. El término se ha usado como un recurso retórico para describir los procesos de división de ciertas culturas en identidades separadas.

En lo que refiere a Software Libre y Linux en Particular, se puede resumir a lo siguiente:

• Demasiadas distribuciones Linux, cada una ofreciendo diferentes interfaces, características y funcionalidad. Aunque tiene como ventaja el que exista una distribución Linux para todas la necesidades y todos los usos imaginables.
• Usuarios de algunos proyectos menosprecian a los usuarios de otros proyectos, por cualquier cantidad de motivos.
• Esfuerzos se dividen en lugar de tener un objetivo en común.
• «Cada quien lleva agua a su propio molino». Proyectos que realizan cambios para cubrir sus propias necesidades sin tomar en cuenta a las aplicaciones de terceros que también hacen uso de los componentes de su proyecto. Sólo basta preguntar a los desarrolladores de temas para Gtk: ¿Qué tal les ha ido en los últimos 10 años tratando de adivinar los cambios en el código de Gtk para los temas con cada nuevo lanzamiento?
• GNOME versus los demás entornos de escritorio y todo lo que es ajeno a su proyecto.
• Ausencia de una organización que coordine proyectos. Cada proyecto tiene sus propios objetivos y tienen poco o ningún interés en común con otros proyectos. Ejemplo: instala y actualiza módulos de Python usando PIP y descubrirás que muchas aplicaciones dejan de funcionar por ser incompatibles con las versiones más recientes de módulos como urllib3, requests, protobuf, argcomplete, rapidfuzz, etc.

En contraste, quienes se encargan del desarrollo de Windows son coordinados por una sola entidad ―Microsoft― y por ende todos tienen un objetivo en común y prácticamente hay una nula competencia entre proyectos, es decir «todos llevan agua al mismo molino».

2. Poco o nulo soporte para distribuciones LTS.

• Pareciera que muchos desarrolladores asumen que todos los usuarios Linux tienen la capacidad técnica para actualizar sus sistemas operativos y utilizar las versiones más recientes de Ubuntu o Fedora o de instalar distribuciones como Arch Linux o Gentoo.
• Hay desarrolladores que explícitamente se niegan a darle soporte a distribuciones LTS por considerar que todos deberían siempre utilizar las versiones más recientes de componentes como GCC, Glibc o Python. Ejemplo: pese a que Python 3.8 tendrá soporte hasta fines de 2024 y que Python 3.9 tendrá soporte hasta fines de 2025, desarrollador de Gajim exige que su aplicación se utilice con Python 3.10 como versión mínima, por tanto es imposible instalar versión más reciente de Gajim en las distribuciones LTS más recientes.

Distribuciones LTS ofrecen soporte por hasta 10 años. Por tanto se equiparan con los lanzamientos de versiones de sistemas operativos privativos como Windows. Absurdo que desarrolladores ignoren distribuciones LTS. Los usuarios finales carecen de capacidad técnica para actualizar versión de sistema operativo cada 6 meses, como ocurre con distribuciones Linux como Fedora y los lanzamientos no-LTS de Ubuntu.

Cuando un desarrollador pide a los usuarios utilizar las versiones de componentes de software más recientes incluidas sólo en la versión más reciente de Fedora o la versión no-LTS más reciente de Ubuntu, es casi lo mismo que pedir al usuario utilizar la versión ALPHA o BETA de la siguiente versión de Windows.

3. Compatibilidad con software antiguo.

Algo en lo que Microsoft ha puesto mucha énfasis a lo largo de las historia de Windows, es que todos los programas sigan siendo compatibles con las versiones más recientes de Windows. Ejemplo: toma una aplicación para Windows del año 1995 y ésta seguramente instalará y ejecutará sin problemas en Windows 11 ―habilitando el modo de compatibilidad. Microsoft tiene una muy estricta política en cuanto a respetar los APIs y ABIs para impedir se rompan las dependencias de software de terceros. Microsoft se esmera en lograr que las aplicaciones de terceros en su ecosistema jamás dejen de funcionar sin importar su antigüedad.

En el caso de las distribuciones Linux, es común que programas de incluso hace un año de antigüedad tengan dependencias rotas que impiden su instalación en las versiones más recientes de Ubuntu o Fedora. Volver a compilar el software problema suele resolver el problema, algo que resulta absurdo solicitar a los usuarios finales, quienes carecen de los conocimientos y capacidades técnicas necesarias para realizar dicha tarea, sobre todo en ausencia de un código fuente.

Los cambios de API de las versiones de componentes de software más recientes son los principales responsables del denominado «infierno de dependencias» e implican tener que volver a compilar y modificar mucho software para hacer uso del nuevo API.

Volver a compilar software para resolver éste problema implica un considerable consumo de recursos de sistema y por tanto implica un considerable incremento en el consumo de energía eléctrica, lo cual es poco amistoso con el medio ambiente.

Utilizar distribuciones LTS resuelven este problema garantizando que al menos durante los 10 años de ciclo de vida, los mismos programas se podrán instalar y utilizar sin requerir tener que volver a compilar éstos durante el ciclo de vida de las distribuciones LTS.

4. Ausencia en el escritorio Linux de algunas aplicaciones y juegos exclusivos de Windows o Mac OS.

En Linux existen actualmente aplicaciones para todos los usos imaginables y aplicaciones equivalentes a muchas aplicaciones que suelen ser exclusivas de sistemas operativos privativos. Existen equivalencias para aplicaciones como MS Office, Adobe Photoshop y Apple Final Cut, sin embargo adoptar el uso de nuevas aplicaciones con una interfaz distinta a la conocida, implica una curva de aprendizaje a la cual suele resistirse el usuario final.

Sin embargo, si hablamos del mundo de los juegos... la historia un completo desastre. La cantidad de juegos comerciales nativos para Linux es muy limitada y aunque muchos ejecutan bien o de manera aceptable con Wine, implica un cierto nivel de conocimientos técnicos para lograr utilizar un juego de vanguardia. Steam llegó como una alternativa que facilitó las cosas a un par de clics del ratón, sin embargo se trata de un software privativo que tiene que instalarse desde un almacén de software de terceros.

Otro escenario desastroso ocurre cuando las empresas utilizan software comercial o software a la medida diseñado estrictamente para funcionar en Windows. Wine puede resultar una solución en algunos casos, pero en la mayoría dista de ser una solución confiable y estable. ¿Por qué los desarrolladores de este tipo de aplicaciones evaden ofrecer una versión para Linux? Porque la cuota de mercado de Linux en los escritorios es menor al 2%. Es decir, les resulta poco o nada atractivo.

5. Ausencia de estándares que todos realmente respeten.

Freedesktop.org es la referencia a seguir para los estándares de escritorio Linux, pero muchos desarrolladores ignoran dichos estándares e incluso llegan a crear sus propios estándares o bien sólo adoptan los que les convienen.

Ejemplo 1: GNOME descartó el uso de iconos en el área de notificación, todo lo anterior existiendo cientos de aplicaciones que hacen uso de iconos en el área de notificaciones y pese a que fue ―en su momento― una decisión muy impopular dentro de su propia comunidad de usuarios. Al día de hoy ―y pese a un nuevo estándar propuesto― muchos desarrolladores de GNOME parecen estar obsesionados con exterminar el uso de iconos en el área de notificaciones a como de lugar. Los lanzamientos más recientes de Gtk4 eliminaron todo rastro de soporte para utilizar éstos. Actualmente GNOME es el único entorno de escritorio que carece de soporte oficial para iconos en el área de notificación y sólo sus desarrolladores consideran ese concepto como algo obsoleto. Gtk puede ser todo lo que quieran, excepto ser un conjunto de herramientas de software neutral.

Ejemplo 2: Como consecuencia del ejemplo anterior, Linux Mint creó su propio estándar para iconos de área de notificación para aplicaciones Gtk en Xapp para su entorno de escritorio Cinnamon, existiendo al menos otros dos estándares previamente ―que fueron descartados por GNOME porque son específicos de X11 y por tanto imposibles de usar en Wayland. Se ha propuesto un borrador para un nuevo estándar para iconos en el área de notificaciones, el cual funciona tanto en X11 como Wayland. Se ha invitado diversas partes a estudiarlo, adoptarlo y apoyarlo. Pero se ve difícil que en el corto o mediano plazo Linux Mint lo llegue a adoptar este estándar en Cinnamon, pues ambas son implementaciones totalmente distintas en cuanto a funcionamiento y además ambas hacen conflicto entre si.

Fuente:xkcd.com/927

6. Ausencia de verdadero soporte de largo plazo para componentes principales del sistema.

Versiones de componentes como GCC, Glibc, kernel y Python suelen tener soporte por hasta 3 o 4 años a algunas versiones de éstos. Para distribuciones Linux no-LTS, ésto implica tener que estar actualizando continuamente éstos componentes para mantenerse vigentes.

Muchos desarrolladores parecen olvidar que para una distribución Linux:

• Actualizar la versión de GCC implica tener que volver a compilar cientos de paquetes ―particularmente todos los paquetes dependientes de C++ y Fortran― para que el sistema operativo quede realmente estable.
• Actualizar la versión de Python implica tener que volver a compilar todos los ―varios miles de― paquetes dependientes de Python.
• Actualizar componentes como Boost implica tener que volver a compilar al menos un centenar de paquetes.

Lamentablemente las versiones utilizadas por las distribuciones LTS ―mismas que utilizan versiones fijas de APIs y ABIs durante todo su ciclo de vida― dejan de ser soportadas por los desarrolladores luego de algunos años por considerar éstas como demasiado antiguas.

Ejemplo 1: KF5 5.89, KDE Applications 21.12.3 y KDE Plasma 5.22 son las últimas versiones que tienen soporte para GCC 8.5, versión utilizada por Red Hat Linux Enterprise 8 ―sistema operativo con fin de ciclo de vida hasta el año 2029― y sus derivados. Cualquier versión posterior de KF5, KDE Applications y KDE Plasma requieren como mínimo GCC 10 o Red Hat Linux Enterprise 9 o alguno de sus derivados.

Ejemplo 2: Qt >= 6.4 requiere GCC 10 o versión posterior.

Ejemplo 3: vte291 >= 0.65 requiere GCC 9 o versión posterior.

Ejemplo 4: Gajim >= 1.6 requiere como mínimo Python 3.10.

7. Monopolios.

Microsoft tiene la mayor cuota de mercado en el sector de computadoras de escritorio y portátiles. Es un monopolio que han sabido cuidar desde finales de la década de 1980, presionando a los principales fabricantes de equipos de cómputo para ofrecer solamente productos que incluyan Windows en sus principales líneas de productos. Si los fabricantes pudieran ofrecer una alternativa a Windows con el mismo ciclo de vida ―al menos 10 años― y que ésta pudiera ofrecer las mismas garantías que ofrece Microsoft sin adolecer de los seis primeros puntos abordados en este documento, muy probablemente estaríamos contando una historia muy distinta.

8. El enemigo en casa.

«La GPL es una licencia tiránica», «Fulano de Tal es un hippie mugroso». Son argumentos ―utilizados por algunos usuarios de Software Libre― que distan mucho de beneficiar la reputación del Software Libre y sólo contribuyen a alimentar los conflictos y radicalizar opiniones. ¡Caray, todos ―los que apoyamos al Software Libre― estamos en el mismo barco! Una cosa es diferir en ideas, opiniones o puntos de vista y otra muy distinta es instigar y promover la satanización de una licencia o el linchamiento mediático y social de alguna personalidad del software libre sólo por su aspecto o un comentario desafortunado.

Muchas empresas que utilizan y comercializan software libre evitan dentro de lo posible mencionar que se trata de software libre o que se trata de un sistema operativo Linux simplemente porque lo consideran malo para la mercadotecnia del producto, ¿verdad que sí, Google? ¡Cof, cof, Chrome, cof, cof, OS, cof, cof!

Conclusiones

• Desarrolladores deben brindar soporte para distribuciones Linux LTS y éstas deben ser su principal nicho de mercado.
• Desarrolladores deben entender que Fedora es una versión ALPHA de Red Hat Enterprise Linux, aunque les duela a algunos admitirlo.
• Desarrolladores deben entender que las versiones no-LTS de Ubuntu son las versiones BETA de Ubuntu LTS, aunque les duela a muchos admitirlo.
• Desarrolladores deben entender que Arch Linux y Gentoo Linux efectivamente son distribuciones Linux fabulosas pero orientadas a usuarios avanzados y expertos con muchísimo tiempo libre.
• Desarrolladores deben entender que actualizar la versión de kernel, GCC, Glibc y Python de un sistema operativo para satisfacer los requisitos de una aplicación en particular, son tareas que requieren un avanzado nivel de conocimientos y que los usuarios finales carecen de las habilidades necesarias para lograrlo.
• Desarrolladores deben entender que es absurdo solicitar a los usuarios finales cambiar de distribución Linux ―o actualizar a otra versión― sólo para cumplir con el requisito de una aplicación.
• Tiene que haber versiones del núcleo de Linux (kernel), GCC, Glibc y Python con verdadero soporte de largo plazo similar al de las distribuciones Linux LTS ―es decir, dar soporte a una o dos ramas por hasta 10 años― y los desarrolladores de aplicaciones deben priorizar la compatibilidad de éstas con dichas versiones.
• Debe crearse un entidad unificada que coordine los principales proyectos, defina estándares y establezca versiones de componentes de software que sean respetados y soportados por todos los proyectos principales de Software Libre.

Sí, El panorama es poco alentador, pues se ve difícil que ocurran en el corto o mediano plazo cambios que corrijan los errores y malas decisiones de los últimos 25 años, a menos que los proyectos de software libre y comunidades de usuarios comiencen realmente a colaborar entre si y por un bien y objetivo común. Entre tanto tendremos que seguir leyendo o escuchando la burlona y sarcástica frase «¡Éste sí va a ser el año del escritorio Linux!».