La distancia entre la utopía del FOSS y la realidad

Todos los proyectos de código abierto excelentes que he visto y utilizado están liderados por grandes empresas/organizaciones, o bien más del noventa por ciento de su código ha sido escrito por un único desarrollador de alto nivel. Más que código abierto, estos proyectos son en realidad "código fuente visible", ya que a las personas externas les resulta difícil intervenir en el flujo de desarrollo principal. En la dicotomía entre "la catedral" y "el bazar", estos proyectos se inclinan claramente hacia el lado de "la catedral", a pesar de que ciertamente llevan puesta la piel del "código abierto".

Los proyectos de código abierto que he visto que reclutan ampliamente a desarrolladores externos, aquellos en los que casi cualquiera puede meter mano en el proceso de desarrollo, son comúnmente desastres al nivel de un incendio en un contenedor de basura. Estos son los verdaderos proyectos de "código abierto" que, en la oposición entre "la catedral" y "el bazar", pertenecen sin duda al lado del "bazar".

Con la experiencia mencionada, resulta difícil no ser crítico con la práctica del modelo del "bazar". El estado actual de la industria del software ya ha demostrado que el modelo del "bazar" no es adecuado para la mayoría de los proyectos de software.

Pregúntate con total sinceridad: ¿cuántos forks de proyectos de código abierto has mantenido? ¿Es capaz tu fork de seguir el ritmo del desarrollo upstream?

La mayoría de los forks mantenidos por individuos u organizaciones pequeñas se convierten en ruinas tras un breve periodo de commits intensivos:

Incluso en el caso de forks a gran escala nacidos de cismas ideológicos y mantenidos por una parte del equipo de desarrollo original, a menudo les resulta difícil perdurar. La evidencia es más que obvia: en el mercado no existen prácticamente proyectos de software que, tras un fork a gran escala, hayan logrado mantener con éxito un desarrollo paralelo a largo plazo—no pasa mucho tiempo antes de que uno de los bandos se declare vencedor. Esa diminuta minoría de forks a gran escala capaces de mantener el desarrollo en paralelo o bien tienen como upstream un proyecto maduro que apenas añade nuevas funcionalidades, o bien se han desvinculado por completo de la dependencia del upstream.

La brecha en la comprensión del proyecto entre los mantenedores principales y "un desconocido cualquiera de Internet" es abismal: Para escribir "código correcto" o código al nivel de la "programación estratégica", este último necesita invertir una gran cantidad de tiempo y esfuerzo en profundizar su comprensión del proyecto. Por desgracia, la mayoría de los colaboradores no poseen ese nivel de espíritu de código abierto ni las condiciones objetivas necesarias.

Los mantenedores de proyectos de código abierto tienen que revisar las pull requests enviadas por "desconocidos de Internet", para luego descubrir, con una alta probabilidad, que la mayoría de ellas no se pueden fusionar directamente. Cuanto más propenso sea un proyecto a atraer a desarrolladores de bajo nivel, más fácil será toparse con este tipo de pull requests. Ya sea guiando a los colaboradores externos para que reescriban el código hasta que sea apto para fusionarse, o encargándose el propio mantenedor de reescribirlo, ambas opciones requieren tiempo y energía. Los ciclos de comunicación y retroalimentación construidos sobre la filosofía del código abierto suelen ser extremadamente ineficientes, hasta el punto de que, en muchas ocasiones, no compensan el esfuerzo invertido; los mantenedores harían mejor en dedicar su tiempo a tareas más eficientes.

Es muy común que existan discrepancias entre los objetivos de los colaboradores externos y los del equipo de desarrollo, razón por la cual muchos proyectos no necesitan contribuciones externas a nivel de funcionalidades.

Para las funciones que realmente le importan al equipo de desarrollo, la implementación oficial suele ser rápida y de calidad. Para aquellas que en realidad no les importan, las solicitudes de funciones (feature requests) serán cerradas por un bot tras un periodo de inactividad, y las pull requests caerán en el olvido. O peor aún: se fusiona una implementación apresurada que termina convirtiéndose en una vulnerabilidad de seguridad del software, la cual, tras múltiples intentos de solución, vuelve a reaparecer en versiones posteriores; en cualquier caso, su destino final e inevitable será la eliminación.

¿Cómo mantener la compostura y la elegancia mientras se mantiene un proyecto de código abierto? Respuesta de calidad: no lo sé.

Me temo que Linus Torvalds, el líder del proyecto de código abierto con mayor impacto, tampoco lo sabe. Considerando que los proyectos que gestiona tienen una barrera de entrada tan alta que alguien insignificante como yo ni siquiera contemplaría contribuir, la capacidad requerida para cumplir con sus funciones está más allá de lo que una persona común puede imaginar. Incluso en estos proyectos con un listón tan alto, donde la información que llega ante los ojos de Linus ya ha pasado por múltiples capas de filtrado, Linus a veces se muestra mordaz y despiadado, recurriendo al sarcasmo y al insulto extremo en sus críticas—un fenómeno tan grave que deleitarse con estos desahogos emocionales se ha convertido casi en un entretenimiento. Una proporción considerable de desarrolladores ve con buenos ojos el temperamento de Linus, llegando incluso a considerarlo una parte importante de su buena reputación (en parte porque este tipo de información tiene mayor potencial de difusión), ya que un mundo sin dictadores técnicos como Linus es muy fácil de imaginar: no tendríamos software con la calidad actual, todo sería mucho peor que ahora. Para quienes no son gestores la situación es similar: la comunidad de código abierto no es un grupo de elogios mutuos, y las formas más eficientes de comunicación suelen ser tóxicas.

Es cierto que en el mundo existen algunos superhombres capaces de mantener la calma en cualquier circunstancia y de gestionarlo todo con diplomacia; yo se lo atribuyo al talento innato o a los fármacos. Porque si esta habilidad pudiera enseñarse, o al menos adquirirse mediante el entrenamiento, ya se habría popularizado hace tiempo, pues seguro que hay muchísima gente en el mundo deseosa de tener tal control emocional. Al mismo tiempo, cabe señalar que estos superhombres rara vez se encuentran en la cima del ámbito técnico—la cúspide técnica está ocupada básicamente por ególatras cargados de toxicidad, y las diferencias que se aprecian entre ellos dependen principalmente de la calidad de sus relaciones públicas. Esta correlación nos conduce a una regla imposible de demostrar, pero que parece existir objetivamente: el verdadero espíritu del código abierto y una buena salud mental son, al igual que no poder nadar y guardar la ropa, mutuamente excluyentes.

A menos que ya te encuentres en el círculo más selecto de la cúspide de tu campo, siempre tendrás la oportunidad de conocer a personas mejores que tú: que saben más, piensan más profundamente y ejecutan mejor. La distancia entre el peor y el mejor de los ingenieros no se puede resumir simplemente con el concepto del "ingeniero 10x". En áreas especializadas, acompañada por la brecha de experiencia y conocimientos técnicos, la distancia entre ingenieros puede ser muy superior a diez veces.

En lo que respecta únicamente al movimiento del código abierto, existe una forma sencilla de clasificar a los ingenieros según su nivel de habilidad:

Sin embargo, en la comunidad de código abierto, los falsos ingenieros carentes de autoconciencia son tan comunes que parecen estar ahí solo para confirmar el efecto Dunning-Kruger. Estos generadores de problemas suelen estar obsesionados con acumular "crédito social", prefieren dejar comentarios sin contenido informativo real y contribuyen solo por el mero hecho de contribuir. Entre ambas categorías existe en realidad una fase de transición conocida como el síndrome del impostor; estas personas a menudo no participan en proyectos de código abierto y, por tanto, resultan mucho menos dañinas.

Lo más irritante del código abierto es que errores, problemas y malentendidos que podrían resolverse de forma autónoma acaban trasladándose indebidamente de los falsos ingenieros a los auténticos debido a la disparidad en sus niveles de habilidad. Esto es una pura pérdida de tiempo para estos últimos. Si la gente fuera capaz de dudar primero de sí misma y actuar con cautela y rigor, la mayoría de estas situaciones podrían evitarse a pesar de las diferencias de nivel. Lo triste es que estas cualidades, que deberían ser parte de la competencia básica, son en realidad bastante escasas, y el movimiento de código abierto carece de mecanismos eficaces para mantener a los falsos ingenieros fuera.

Lo admitas o no, los conceptos de software libre y software de código abierto significan prácticamente lo mismo para el usuario final—son sinónimos de "software gratuito y seguro".

La idea de "obtener algo a cambio de nada" tiene un efecto sumamente potente a nivel de marketing, y la mayoría de las personas no tienen defensas ante semejante tentación. El ejemplo más clásico se da en la industria del videojuego (que también forma parte del sector del software), donde los juegos más rentables son los llamados "juegos gratuitos". Hazte esta pregunta: si no fuera gratuito, ¿seguirías eligiéndolo?

En una proporción considerable de los "proyectos de código abierto", el valor publicitario de la etiqueta "código abierto" supera con creces su valor como modelo de desarrollo. Quienes los gestionan o bien son plenamente conscientes de que estos proyectos difícilmente subsistirían fuera del equipo de desarrollo original y usan el código abierto solo como una táctica de marketing para adelantar a sus competidores; o bien recurren directamente a "licencias de código abierto" de cosecha propia (cuando un "proyecto de código abierto" no utiliza una licencia estándar, no es difícil imaginar las trampas ocultas); e incluso hay proyectos originalmente de código abierto que, tras cambiar a una licencia privativa, siguen utilizando el término para confundir al público, lo que demuestra claramente el valor publicitario que encierra la expresión "código abierto".

En el ámbito de la inteligencia artificial, ahora incluso a los "pesos abiertos" se les llama "código abierto". Del mismo modo que "código fuente visible" no es código abierto, los "pesos abiertos" tampoco lo son. Los únicos beneficiados de estos disparates que amplían arbitrariamente el significado de los términos son aquellos que esperan utilizar el código abierto como herramienta publicitaria.

El lado oscuro del software de código abierto a menudo queda oculto tras la fachada superficial de lo "gratuito". No hay almuerzo gratis; aprender, entender, explotar y contribuir al software de código abierto tiene un coste. Dado que la documentación del software libre suele ser más escasa, la resolución de errores y la obtención de soporte dependen en gran medida de la comunidad, y abunda el código que jamás ha sido probado en escenarios reales, el software de código abierto genera con frecuencia costes imprevistos. En el momento en que decides depender de un proyecto de código abierto, ya estás asumiendo esos costes.

La única parte verdaderamente gratuita del software de código abierto es la autoesclavitud de los mantenedores, impulsada por ideales y un sentido de misión, lo cual conduce fácilmente a colapsos mayores. Que un software de código abierto funcione bien temporalmente no garantiza que lo siga haciendo en el futuro. Los mantenedores pueden cansarse, abandonar, perder la capacidad de mantenimiento, resultar insuficientes o, simplemente, sufrir un arrebato y decidir destrozar un proyecto que antes era decente. Por lo tanto, usar software de código abierto no solo implica costes, sino también asumir riesgos. El software comercial, impulsado por un evidente interés económico, resulta paradójicamente más fiable que el de código abierto.

"¡Pero los mantenedores de código abierto no te deben nada!"—Espero que sigas siendo capaz de decir esa frase con total seguridad cuando sufras pérdidas debido a ataques a la cadena de suministro o vulnerabilidades de seguridad. Incluso si se trata de un plato de comida regalado, mear en él sigue siendo imperdonable. La confianza ciega de la gente en el software de código abierto y su uso indiscriminado han creado demasiadas oportunidades para orinar en la comida, provocando que cualquier software que utilice dependencias externas pueda introducir indirectamente y por accidente dependencias problemáticas, perjudicando así a todos los que se encuentran aguas abajo en la cadena de dependencias. Esta crisis de confianza incrementa radicalmente el coste de seguir utilizando software de código abierto para todo el mundo; al final, todo lo que en su origen era ágil y ligero acabará encadenado a pesados grilletes debido al teatro de la seguridad montado por advenedizos que "intentan resolver el problema".

El uso indiscriminado de los LLM ha hecho que los problemas inherentes al FOSS estallen de manera absoluta y concentrada. Si antes el software de código abierto conservaba aún cierto valor de aprovechamiento, hoy en día lo ha perdido por completo: el coste de juzgar el nivel de habilidad del autor y su comprensión del dominio del problema a través del código se ha vuelto prohibitivo. Especialmente el código publicado después de noviembre de 2025: ya no merece ni un solo segundo de atención rigurosa; la única forma de mantener la eficiencia es tratarlo todo directamente como basura.

Desde mi punto de vista, el FOSS ya solo existe de nombre. La única salida para la comunidad es crear una nueva marca y unir bajo un nuevo estandarte a aquellos que todavía respetan la calidad del código—y esto siempre que estas personas sean capaces de derrotar a la nueva generación del principio worse is better impulsada por la programación con LLM.

Hasta que los LLM colapsen porque los nuevos datos de entrenamiento no sean más que basura, no creo que la comunidad FOSS tenga ninguna posibilidad de recuperarse. La mejor opción que tienen es reconocer el valor del código generado por LLM, fingir que todo sigue yendo sobre ruedas y, finalmente, extinguirse en el silencio y la asfixia, tal como lo hizo la Unión Soviética.