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 pokémon). 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…
Una vez más vuelves a ser valiente con tus artículos. Este tema siempre crea indignación en la comunidad, especialmente cuando se crítica, o mejor dicho, no se considera como perfecto al software libre.
Sin embargo creo que das una visión muy acertada de la estructura jerárquica que se da en estos casos. Las ventajas y beneficios del software libre son muy conocidos, a poco que se busque un poco Online aparecen cientos de odas a él, pero considero necesario que se conozca tanto las luces, como la sombras.
Particularmente, me gusta usar software libre y open source siempre que puedo, pero lo que no me gusta es ese “activismo” que se genera en algunas comunidades, donde se pierden la libertad de usar otro tipo de programas por estar cerrado al software libre solamente.
Un saludo y enhorabuena por el artículo
Pd: ya llevo unos meses aplicando la reducción de notificaciones que comentaste en tu artículo. Un gran acierto también, mis distracciones y “multitasking” innecesario se ha reducido considerablemente.
No podría estar más de acuerdo. Mismamente hoy me han atacado por Twitter, y es normal. Todos los extremos son malos.
Que haya surgido, en medio de un escenario tan aparentemente centralizado, propuestas de software libre es casi un milagro. Le debemos (y le deberemos) muchísimo.
Pero como comentas, hay que hablar también de las cosas menos buenas. Esas que resultan molestas de hablar, máxime cuando has bebido de su fuente a diario y te sientes tan sumamente arropado por los que beben igual que tú.
Y me alegro que te haya servido aquel artículo. Curiosamente, veo que ahora muchas de estas nuevas aplicaciones de nueva generación están aplicando parte de sus principios. No se trata de molestar por molestar, sino de hacerlo cuando de verdad es necesario.
Y hay muy poco casos reales en los que un usuario espera ser molestado.
Saludos Asier!
Não escrevo espanhol, apenas entendo.
É importante notar que os projetos que estão no GitHub *não são sinônimo de software livre*.
nMas concordo contigo sobre a possibilidade de alguns projetos serem muito ditadores. Porém, isso é às vezes necessário, *principalmente* quando as liberdades essenciais da sociedade digital estão em jogo, visto que relaxar em garantir estas liberdades é um comportamento *visto nos proponentes do [código-]fonte aberto*, e é por isso que nosso movimento filosófico não possui os mesmos valores que eles, veja: gnu (EN).
Totalmente de acuerdo. En GitHub puedes tener proyectos de software libre o privados. Simplemente la investigación se centró en proyectos alojados en GitHub como podían haber elegido BitBucket o cualquier otro.
Saludos, y muchas gracias por el comentario.
Hay una cosa que no tienes en cuenta, y es la capacidad de modificar y distribuir ese producto inherente al software libre.
En el momento que pones eso en juego, todo ese argumento de la “dictadura” se desmorona.
Muchos proyectos mal gobernados pueden acabar siendo reemplazados por un fork.
Buen punto. En el estudio se analizó varios de los grandes proyectos acogidos a GitHub de software libre. WordPress Estaba entre ellos.
Por supuesto, habría que ver si esos fork en verdad se gestionan de manera democrática. La tendencia es justo la contraria, pero oye, en ámbitos más reducidos creo que es posible.
Vine tarde a comentar, pero pensando en la situacion que se genera con estos temas y luego de leer en uno de estos comentario que has recibido mensajes en contra por lo publicado, y viendo la fecha… le has venido a dar en la madre a varios jejeje
Jajajaj. La verdad, normalmente, duele Dbillyx :).
Eso sí, mucha crítica y trolleo por redes sociales, pero poca defensa seria y argumentada. Está claro que no todos los proyectos de software libre son dictatoriales, pero lamentablemente la mayoría de grandes sí lo son. Es más, para alguien al que le gustaría un escenario radicalmente opuesto, sigue siendo escéptico a que fuera viable a lo largo del tiempo.