La dictadura del software libre

A mi mente volvieron algunas de aquellas clases del master en ingeniería en informática en la que el profesor de gestión de proyectos señalaba con dedo acusador a todo aquel que como un servidor, veía en el software libre la panacea a todos los males.

Falta de razón no tenía. Creo que sobra decir la importancia que ha tenido el software libre en la evolución de la tecnología (y por ende, del acceso a la información y el conocimiento de la sociedad). Pero esto no quita que alguien que llevaba ya sus años trabajando en el sector, fuera receloso a la hora de apostar 100% a un paradigma que tiene sus puntos buenos, y también sus malos.

Precisamente de esto último va este artículo, a colación de un informe que recientemente publicaba el grupo de investigación de la Universitat Oberta de Catalunya (EN/UOC), después de analizar la gestión de los 25 proyectos de software libre con más recorrido en GitHub.

Y las conclusiones seguramente harán levantarse de la silla (o si me apura, hasta ponerse calzado) al mismísimo Richard Stallman, porque lo que viene a decir la UOC, y el dedo acusador de mi antiguo profesor, es que la mayoría de proyectos de software libre se gestionan como auténticos baluartes de una dictadura férrea. Al mismo nivel, y en algunos casos, con mayor intensidad (habida cuenta de que no hay necesidad de dar explicaciones ni documentarlas para fases de análisis posteriores) que buena parte de los proyectos acogidos a licencias restrictivas.

El software libre no es democrático

Y es que una cosa no quita la otra.

Generalmente asociamos proyectos de software libre a proyectos gestionados de forma colectiva, amparados en el potencial de la Comunidad.

La realidad suele ser muy distinta, y es extrapolable a la mayoría de proyectos (sean o no tecnológicos) basados en los principios de la suma de unos muchos.

Según han observado los investigadores, de los 25 proyectos analizados tan solo uno explica claramente cómo se gobierna el proyecto (quién decide qué y cuándo), otros siete dan alguna pequeña indicación, mientras que el resto (un 68 % de los proyectos analizados), no explica nada sobre estas cuestiones. Y los que dicen algo, tampoco siguen prácticas democráticas. Así pues, ninguno de los 25 proyectos analizados sigue algún tipo de proceso democrático en su funcionamiento.

Hablamos de proyectos de software libre gestionados de manera privada, por sus fundadores o por un grupo reducido de dirigentes, que toman decisiones basadas en su propio criterio, teniendo o no en cuenta las peticiones y aportes de la Comunidad.

Es, de facto, un sistema restrictivo, al que se suele llegar por invitación y no, como cabría esperar, por un sistema más democrático y/o meritocrático.

Eso sí, por debajo se opera de manera correcta, sumando el trabajo de unos muchos y conformando lo que entendemos por software libre.

La investigación, como contaba, se centra en los proyectos de software, llegando a la conclusión de que la mayoría de los proyectos críticos con el funcionamiento de nuestra sociedad están en manos de un reducido grupo de personas que pueden escuchar o no las peticiones de los usuarios, pero que no están obligadas a atenderlas ni, como mínimo, a explicar la metodología que siguen a la hora de tomar las decisiones oportunas.

Pero es totalmente exportable a la mayoría de sistemas de gestión colaborativa, empezando por la ciudadana, siguiendo por proyectos de colaboración como pueden ser los que permiten sacar adelante una iniciativa social, o un proyecto de comunicación (como podría ser este mismo), y acabando por buena parte de aquellos acogidos a entornos de crowdfunding o holocráticos.

El caos de un sistema verdaderamente democrático

Entre las razones, un servidor apuntaría a la facilidad de gestión que representa un sistema basado en restricciones frente a otro basado en democracia.

Lo he experimentado con creces en mi andadura dentro de TID, trabajando con Mozilla en el desarrollo de Firefox OS, y lo veo ahora con la iniciativa de micromecenazgo de esta página.

Resulta muy, muy arduo, realizar movimientos en un entorno profundamente democrático, en el que todos tienen derecho a ejercer su voto.

En nuestra Comunidad, cada vez que pido el voto de los miembros, tardo alrededor de una semana en obtener una respuesta significativa (hay que dejar tiempo para que los miembros puedan contestar, y luego hay que aglutinar los datos y obtener un veredicto). Algo aceptable para un proyecto pequeño (somos pocos más de mil miembros), cuyo ciclo de iteración atiende a semanas/meses y no a días u horas, pero difícilmente extrapolable a un proyecto de gran repercusión como puede ser la evolución de un sistema operativo, o la designación de un presupuesto para un tema de ámbito estatal.

Intento, eso sí, ser lo más transparente posible, explicando con pelos y señales en qué invertimos el dinero y cuánto se ha recaudado, pero en última instancia, quien decide soy yo (amparado, eso sí, por el feedback que me dan los miembros), por la simple búsqueda del pragmatismo. Si el proyecto dependiera enteramente de la decisión democrática de los miembros, no haríamos absolutamente nada.

Descontando posibles tergiversaciones del propio sistema de voto, como el vivido recientemente con la petición a la sociedad de un nombre para el nuevo buque de Reino Unido, en el que iba ganando Blas de Lezo (un reputado almirante español, que trajo por la calle de la amargura a la flota inglesa del siglo XVIII), gracias al voto masivo (ES) proveniente de los miembros de Forocoches.

Si en efecto el sistema de decisión del nombre hubiera sido democrático, Blas de Lezo hubiera sido el próximo buque británico, para cachondeo del resto de países. Sin embargo, "alguien" decidió eliminarlo de la lista, anteponiendo los intereses privados al afán colaborativo de la propuesta.

Otro ejemplo que se me viene a la cabeza fue ese experimento de Twitch en el que, gracias a los bots, los propios usuarios debían ponerse de acuerdo para mover adecuadamente al personaje y acabar el juego (en este caso, uno de los antiguos de Pokemon). Una auténtica oda a la gestión multiusuario, que requería para avanzar que cientos de desconocidos se pusieran de acuerdo sobre el próximo movimiento, todo en tiempo real.

Y decisiones unilaterales como estas las hemos vivido en el software libre desde que tenemos uso de razón, como fueron las reticencias de Linus Tolvards a la hora de dirigir el desarrollo del núcleo de Linux hacia donde él creía que debía ir (y no hacia donde algunos grupos pedían), o los ya clásicos "Es que tenemos que proteger a los usuarios de ellos mismos", que vemos prácticamente cada semana en las actualizaciones de apps, servicios digitales y programas.

Desde SOM Research Lab indican que han elaborado herramientas y recomendaciones para transformar los procesos de desarrollo de software en procesos democráticos y transparentes con las reglas de decisión adecuadas a cada caso. Una vez definidas, estas reglas se podrán monitorizar y automatizar con el objetivo de producir un software que realmente responda a los intereses de la comunidad, y no únicamente a la de sus gestores.

Pero temo que aunque profundamente interesante (me gustaría ver cómo se gestionar realmente un proyecto de forma absolutamente democrática), no sea de interés real para el mercado, habida cuenta de los riesgos que ello conlleva.

Habida cuenta de que, mal que me pese, resulta muy, muy complicado sacar adelante algo en el que todos tienen derecho a opinar...

vua