Featuritis en Software Libre

Featuritis es un término acuñado con la mezcla del anglicismo feature (característica, propiedad, funcionalidad, prestación) y la desinencia itis (con la que se designan en medicina las inflamaciones), para identificar el momento del desarrollo de una aplicación en el que se dispone de tantas funcionalidades y prestaciones que complican la usabilidad del fin principal de dicha aplicación.

En el mundo del software privativo la featuritis es la consecuencia de la sobre oferta de plug-ins, propagandas y otras funciones «cerradas» que llegan al usuario para «utilizar mejor» la herramienta. También la featuritis está motivada por la necesidad de ofrecer al mercado nuevas mejoras (que muchas veces no son necesarias) pero que terminan siendo importantes argumentos de venta para la nueva versión, forzando la aparición de necesidades (inexistentes) en los usuarios. Ejemplos hay muchos, desde hace un tiempo estoy recolectando capturas de ellos:

En el mundo del software libre las aplicaciones son más modulares y no tenemos la presión de forzar necesidades en los consumidores. La frase lo que se necesita es muy utilizada para definir el alcance de una aplicación. Por otro lado, siempre digo que es posible adaptar la herramienta, quitar lo que no necesito, juntar las mejores funcionalidades de dos herramientas distintas….. pero llevado al terreno prácitco, es realmente así la realidad del software libre? puede una aplicación de software libre sufrir de featuritis?

La respuesta es sí y tengo un ejemplo (que supongo no ha de ser el único).

Se trata de TikiWiki, un manejador de contenido (CMS) para web que ha crecido horizontalmente de forma muy explosiva y que, actualmente, no es posible definirlo como un CMS, sino que es casi de todo, como se describe en su documentación. El propio autor de Tikiwiki, Luis Argerich ofreció una clara explicación para este fenómeno, explicando que Tikiwiki no es un CMS ampliado, sino que es un framework para programar aplicaciones en PHP cuyo aplicación principal (un CMS) recibe contribuciones de cualquier tipo.

Entonces, lo que en un principio podía ser interpretado como featuritis del Tikiwiki, ya no es así.

No obstante, el otro día me enfrenté a un problema con Tikiwiki, que fue lo que me llevó a escribir este análisis: Sucede que instaló la última versión y la misma viene con un editor de gráficos llamada JGraph que está muy interesante, pero que es una herramienta demasiado potente para el tipo de gráficos que yo edito. Con anterioridad Tikiwiki era acompañado por la aplicación jHotDraw que era la que yo aprendí a usar y que es mucho más sencilla y simple que JGraph.

Y la featuritis de JGraph, que permite editar dibujos 3D de paisajes y vaya uno a saber qué mas…, me golpeó en carne propia, cuando yo solo necesitaba escribir un texto reodeado por un cuadrado.

Entonces junto con Gustavo y algun tiempo de configuración e instalación, pudimos dejar funcionando el jHotDraw dentro de mi Tikiwiki sin problemas. Por supuesto que necesitamos meternos en los códigos íntimos de Tikiwiki, editar la biblioteca que llama a la aplicación de dibujo, modificar el programa que controla la edición/grabación de los gráficos, etc., pero gracias a que trabajamos con software libre, tuvimos la posibilidad de hacerlo.

En el mundo del software privativo, posiblemente habría tenido que aceptar el cambio y aprender a trabajar con una aplicación llena de funcionalidades que nunca usaré. Y esto me demostró que si es posible en el software libre aplicar los preceptos que uno difunde, siempre que exista el suficiente interés y la necesidad para tener funcionando lo que a uno más le sirve.