Manos invisibles: Los retos del FOSS de hoy y mañana

¿Quién mantiene el software libre y/o de código abierto (FOSS)?

Los programas FOSS son mantenidos por comunidades de desarrolladores que realizan su labor, en su mayoría, de forma independiente y sin un interés económico de por medio. Por supuesto, existen proyectos FOSS sostenidos por equipos afiliados a compañías o empresas; por ejemplo, el proyecto Code - OSS, el núcleo de Visual Studio Code, es liderado por ingenieros en Microsoft¹, y TensorFlow, una biblioteca de aprendizaje automático, es mantenida principalmente por Google a través de su equipo de investigación y desarrollo².

¿Y qué problemas surgen en esas comunidades de desarrolladores?

Bueno, las comunidades de FOSS no están liberadas de los males que pueden aparecer en cualquier otro grupo de personas que se juntan a hacer algo. Haciendo un pequeño ejercicio de remembranza, se me vienen a la mente los conflictos de interés, especialmente en proyectos de gran envergadura. Ya sabes, estos programas, al contar con muchos contribuidores, atraen a individuos con diferentes opiniones y de preferencias opuestas, lo que inevitablemente da lugar a tensiones. Y si no actúan los mediadores al momento, entonces lo que suele seguir no es más que agresión y controversia, algo que casi nunca termina beneficiando la reputación de la comunidad FOSS.

Como ejemplo, de vuelta en febrero de 2025, la intención del proyecto Rust4Linux (R4L) era incorporar el lenguaje de programación Rust en varios de los controladores principales del núcleo de Linux. Esto tendría dos implicancias directas: (1) Rust pasaría a formar parte del repositorio principal del proyecto, y (2) a partir de ello, sería necesario mantener en algunas partes código base escrito en múltiples lenguajes de programación. Dicho esto, Rust puede interactuar con código C gracias a su interfaz de funciones foráneas (FFI), lo cual facilita su integración en un núcleo escrito casi en su totalidad en C (98.3% hasta julio de 2025). Pero no tiene compatibilidad per se con C, así que sería un cambio progresivo.

Así pues, en el conflicto de R4L, muy cubierto por la prensa³, existía el bando que rechazaba fehacientemente la incorporación de Rust, por las mismas implicancias descritas arriba. En el otro lado del cuadrilátero estaba un grupo de desarrolladores que advocaban con que se promoviera Rust en el núcleo basándose en la mayor seguridad y grado de modernidad que otorgaba el mismo. Alrededor de esta disputa, se formó un cúmulo de habladurías totalmente ajenas al tema central de la controversia⁴. Esto, creo, muestra la inestabilidad de la gobernanza en FOSS.

Así que, sí. Escalar estos proyectos tiene retos.

¿Y qué pasa con los proyectos pequeños?

Estos suelen ser más volátiles. Existe un riesgo latente que podríamos llamar el de las "manos invisibles": cuando un proyecto no muestra de forma explícita aprecio ni gratitud por el trabajo de sus mantenedores, sea por descuido o por falta de recursos o algo, es común que estas personas, que sostienen el proyecto con su esfuerzo, pierdan la motivación para continuar. De allí que los mantenedores se sientan como "manos invisibles", sin reconocimiento.

¿Y cuál es el resultado?

Peligro la sostenibilidad del proyecto completo.

Después de todo, ningún desarrollador independiente, que además no recibe una remuneración formal, está "obligado" a contribuir con un proyecto de software libre. Exigirlo sería, en cierto modo, negar los mismos principios que definen al FOSS. Una antítesis, si es que deseas un término más bonito.

Otra causa frecuente de abandono es el burnout. La carga de trabajo puede acumularse rápidamente. Esta rutina de atender problemas constantes, mantener abiertos los issues reportados por los usuarios y, sobre todo, lidiar con expectativas poco realistas representan riesgos serios para la salud mental de quienes mantienen el software.

Si a eso le sumamos la falta de retroalimentación positiva, como la que mencionamos antes, el resultado es un cóctel muy ácido y difícil de tomar.

¿Y qué hacemos?

Sería muy naif recomendar una sola cosa para todos los proyectos FOSS, porque los hay de todos los tamaños y colores. Pero creo que la naturaleza de tu pregunta me invita a realizar una respuesta, sea la que ésta sea. Así que haré mi mayor esfuerzo en generalizar una afirmación que sea al mismo tiempo lo suficientemente específica como para servirle en la práctica a alguien.

Mientras el trabajo de quienes mantienen el FOSS siga dependiendo de buena voluntad y supuesta resiliencia, su futuro siempre será tan incierto como el de los dados.

La sostenibilidad del FOSS se debe sostener no solo en la cohesión de una comunidad, sino en iniciativas que recompensan el esfuerzo de cada mantenedor. Las formas existen (GitHub Sponsors, Open Collective)⁵ pero se debe priorizar la transparencia. Esta transparencia se debe de incorporar a su vez en la gobernanza. Los mediadores deben estar presentes para establecer límites saludables en las disputas que, aunque no desaparecerán por completo, pueden reducirse cuando comienzan a enfrentar a desarrolladores, generar malas impresiones y contradecir los valores que tantas comunidades FOSS dicen promover: libertad, respeto y trabajo en equipo.

Eso sería, sí.