El software de código abierto es fantástico. Años de esfuerzo y experiencia de la comunidad de código abierto han ayudado a construir un rico ecosistema de software, capaz de todo, desde reemplazar por completo alternativas comerciales costosas hasta respaldar casos de uso específicos que posiblemente no serían rentables como un producto independiente. En Internet se puede encontrar de todo, desde millones de pequeños scripts hasta enormes proyectos heredados que sustentan toda Internet, como Linux, Git u OpenSSL.
Sin embargo, para los consumidores, las aplicaciones de código abierto suelen tener un lado negativo. Pensemos en algunos de losprogramas de código abiertomás populares y ampliamente utilizados . Pensemos en OpenOffice,LibreOffice, GIMP, VLC media player, Audacity y otros programas similares. Se trata de aplicaciones gratuitas, excelentes y repletas de funciones que compiten cómodamente con sus alternativas propietarias. Sin embargo, son un poco feas. No terriblemente feas. No son una monstruosidad insoportable. Pero tampoco son exactamente... elegantes.
Pero, ¿por qué? ¿Las aplicaciones de código abierto están condenadas a tener una mala interfaz de usuario? ¿O hay algo más en juego? Analizaremos por qué las aplicaciones de código abierto suelen ser un poco feas.
En general, hablamos de proyectos FOSS gestionados en su totalidad o en gran medida por la comunidad. Hay proyectos de código abierto con patrocinadores corporativos, gerentes de productos, etc. Un ejemplo de esto serían proyectos como Bitwarden o Chromium.
No todas las aplicaciones de código abierto son feas
Los marcos de interfaz de usuario modernos han mejorado las cosas
Ahora bien, debemos ser claros: no todas las aplicaciones de código abierto son feas. Hay muchos ejemplos de software de código abierto excelente, limpio y bien diseñado. No es una generalización justa decir que todo el software de código abierto es feo, pero sería bastante preciso decir que las aplicaciones de código abierto consolidadas y con todas las funciones son a menudo más feas que sus alternativas propietarias.
Existen algunas aplicaciones de código abierto de excelente aspecto, pero tienden a estar en sus primeras iteraciones. El auge de los modernos marcos de interfaz de usuario multiplataforma comoElectronestá respaldando una nueva ola de aplicaciones de código abierto de excelente aspecto, pero a menudo estas carecen de las funciones avanzadas de los proyectos más establecidos.
¿Por qué las aplicaciones de código abierto son feas?
Los proyectos pueden carecer de una visión cohesiva
Hay un par de cosas que podemos señalar cuando hablamos de por qué las aplicaciones de código abierto pueden no verse bien. En primer lugar, las aplicaciones de código abierto, especialmente los proyectos más grandes como GIMP u OpenOffice, suelen ser trabajos en los que trabajan equipos extensos de personas durante largos períodos.
Esto contrasta con la forma en que a veces se desarrollan las aplicaciones propietarias dentro de una empresa, donde puede haber equipos de diseñadores que establecen el lenguaje visual y gerentes de producto que establecen la dirección del proyecto general y al mismo tiempo priorizan las características. El diseño en proyectos de código abierto y comunitarios suele estar dirigido por los propios desarrolladores, y la inclinación natural de muchos desarrolladores es priorizar las características y la funcionalidad por sobre el diseño.
En lugar de un diseño y una supervisión impecable del producto en una empresa, la dirección de los proyectos comunitarios suele estar fijada por un único responsable o un equipo de responsables, responsables de hacer cumplir los estándares en el proyecto, aprobar los cambios y gestionar las propuestas de la comunidad. Los buenos responsables son esenciales para liderar cualquier rediseño serio de la interfaz de usuario de un gran proyecto, para asignar el trabajo y gestionar el progreso. Sin embargo, los responsables suelen tener preocupaciones "más importantes", que incluyen características menos glamorosas como preservar la compatibilidad con versiones anteriores, la seguridad y la estabilidad. Los malos responsables pueden no fijar una dirección para el proyecto, y la falta de una visión cohesiva puede estancar el desarrollo.
Los desacuerdos entre la comunidad y los mantenedores sobre la dirección de un proyecto también pueden conducir a bifurcaciones, donde un grupo separado de desarrolladores toma el código existente y comienza a desarrollar su propia versión como un nuevo lanzamiento.
Las bifurcaciones no son algo malo: a menudo, los proyectos heredados deben priorizar la compatibilidad con versiones anteriores por sobre las nuevas funciones. Sin embargo, muchas bifurcaciones pueden reducir los esfuerzos de desarrollo en la versión original.
Es difícil refactorizar proyectos grandes
Con una base de código grande, refactorizar una gran parte es un desafío increíblemente difícil. Podría decirse que es uno de los mayores desafíos en el ciclo de vida del desarrollo de software, lo que a menudo lleva a las empresas a empezar desde cero en algunos casos en lugar de refactorizar código antiguo o de mala calidad.
Cómo instalar Windows 11 en casi cualquier PC no compatible
¿Quieres Windows 11 pero tienes una computadora que no es compatible? Aquí te mostramos cómo instalar Windows 11 incluso si tu PC no cumple con los requisitos mínimos.
Este problema existe en los proyectos de gran envergadura y suele verse agravado en el mundo del código abierto. Un proyecto de gran envergadura como GIMP u OpenOffice podría tardar años en refactorizarse para convertirse en una nueva biblioteca de gráficos. Si bien una empresa que busque refactorizar este software podría poner a un equipo de desarrolladores a trabajar en el rediseño a tiempo completo, un proyecto dirigido por la comunidad podría tener dificultades para generar el mismo impulso y esfuerzo de desarrollo.
Puede que no parezca el fin del mundo, pero a medida que crece la base de código de los grandes proyectos, se hace cada vez más difícil que la comunidad refactorice un proyecto. Sin embargo, hay algunas historias de éxito en este sentido. Los desarrolladores de Audacity, una popular y longeva aplicación de código abierto, están actualmente en proceso de un importante rediseño de la interfaz de usuario que parece prometedor (aunque con cierto grado de apoyo corporativo).
Los proyectos comunitarios no siempre intentan ser bellos
Este es un poco más controvertido, pero no todos los proyectos de código abierto liderados por la comunidad intentan ser atractivos. Estos proyectos suelen centrarse en ser extensibles, tener un amplio soporte y una gran cantidad de funciones, y están dispuestos a sacrificar algo de estética para facilitar el mantenimiento.
Algunos proyectos pueden priorizar una excelente interfaz de usuario, mientras que otros priorizarán una interfaz de línea de comandos que se pueda modificar fácilmente mediante scripts o automatizar. Algunos desarrolladores pueden valorar mucho la compatibilidad multiplataforma en un proyecto, mientras que otros pueden dejar de lado con gusto la compatibilidad con Windows a cambio de un rendimiento increíblemente rápido en Linux, por ejemplo.
Este es otro ejemplo de una bifurcación de un proyecto, cuando un grupo de desarrolladores vuelve a publicar una versión modificada con cambios que desean ver y que no se han aceptado en la versión principal. Este nuevo grupo de desarrolladores puede estar dispuesto a sacrificar cierta compatibilidad con versiones anteriores, extensibilidad o funciones a cambio de estética o de un nuevo conjunto de funciones que la versión principal no admita.
Las aplicaciones de código abierto priorizan las funciones
En esencia, estos programas priorizan las características y la compatibilidad por sobre la estética. Los proyectos liderados por la comunidad suelen comenzar siendo pequeños, con ambiciones simples de resolver un problema existente, y luego crecen lentamente con el tiempo. Tienen recursos limitados y los desarrolladores generalmente eligen asignar estos recursos a agregar nuevas características o corregir errores en lugar de rediseñar elementos de la interfaz de usuario. Estos proyectos tampoco necesitan ser comercializados ni vendidos a nadie, por lo que no se requiere tanto un diseño elegante e interactivo y se hace más hincapié en satisfacer las necesidades de manera pragmática.