Qué pasa cuando un proyecto open source pierde a su líder
Los proyectos open source dependen de pocas personas clave más de lo admitido. Qué pasa cuando se van, se agotan o cambian de rumbo.
Elena Vasquez
Cuando Ryan Dahl se apartó de Node.js, el proyecto sobrevivió, pero hicieron falta años de reestructuración de gobernanza, un fork (io.js) y una reconciliación antes de estabilizarse. Cuando Guido van Rossum renunció como BDFL de Python («Benevolent Dictator For Life»), la comunidad pasó meses debatiendo modelos de gobernanza hasta acordar un consejo directivo. Cuando el proyecto Deno enfrentó sus propias dudas sobre liderazgo, las consecuencias llegaron a cada desarrollador que había apostado por el runtime.
No son incidentes aislados. Son una característica estructural del desarrollo open source. La mayoría de los proyectos open source relevantes dependen de un número muy reducido de personas, a menudo una sola, mucho más de lo que sus usuarios imaginan. Cuando esa persona se va, se quema, cambia de prioridades o toma una decisión polémica, el proyecto enfrenta una crisis existencial que ninguna cantidad de estrellas en GitHub puede evitar.
El problema del factor autobús
El «factor autobús», es decir, cuántas personas tendrían que ser atropelladas por un autobús para que un proyecto colapse, es alarmantemente bajo en la mayoría de los proyectos open source. Un estudio de 2015 encontró que más del 60 % de los paquetes de npm tenían un solo mantenedor. Un análisis más reciente de infraestructura open source crítica reveló que muchos proyectos con millones de dependientes son mantenidos por una o dos personas, a menudo como trabajo voluntario no remunerado.
Esto no es un problema hipotético. OpenSSL, la biblioteca que protegía la mayor parte del tráfico cifrado de internet, era mantenida principalmente por dos personas que trabajaban en ella en su tiempo libre cuando se descubrió Heartbleed. Left-pad, un paquete trivial de 11 líneas en npm, rompió miles de builds cuando su autor lo eliminó. Core-js, descargado más de 25 millones de veces por semana, lo mantiene un único desarrollador que ha dicho públicamente que apenas puede pagarse la comida.
El patrón se repite: un proyecto crítico nace de una persona apasionada, gana adopción, se convierte en infraestructura de la que dependen millones de usuarios, y aun así la carga de mantenimiento sigue en esas mismas una o dos personas. La importancia del proyecto crece de forma exponencial. Su apoyo, no.
Modelos de gobernanza y sus compromisos
Los proyectos open source gestionan la gobernanza de algunas formas distintas, cada una con fortalezas y modos de fallo predecibles.
El modelo BDFL
Una sola persona toma las decisiones finales. Python (Guido van Rossum), Linux (Linus Torvalds), Ruby (Matz): los proyectos más exitosos suelen tener un líder técnico fuerte cuyo criterio y gusto dan forma al proyecto. La ventaja es clara: dirección definida, visión coherente y decisiones rápidas. El BDFL puede decir «no» a las funciones que no encajan, y el proyecto se mantiene enfocado.
El modo de fallo es igual de claro: el BDFL se va y no hay plan de sucesión. La transición de Python tras la renuncia de Guido fue turbulenta, a pesar de sus décadas construyendo comunidad. Los proyectos con comunidades menos comprometidas, sencillamente, suelen morir cuando su BDFL se marcha.
El modelo de fundación
Proyectos como Apache, Eclipse y la Linux Foundation funcionan bajo fundaciones sin ánimo de lucro con estructuras de gobernanza formales: comités técnicos de dirección, elecciones de committers y procesos de toma de decisiones. Esto aporta continuidad institucional: el proyecto sobrevive a las salidas individuales porque la estructura permanece.
El precio es la burocracia y la política interna. La gobernanza de las fundaciones puede ser lenta, conflictiva y capturada por intereses corporativos. Algunos desarrolladores encuentran que el proceso de comités asfixia en comparación con la agilidad de un proyecto liderado por un BDFL. El peor caso: una fundación donde la gobernanza gira más en torno a la política organizacional que al mérito técnico.
El modelo de patrocinio corporativo
React (Meta), Go (Google), Rust (originalmente Mozilla, hoy con su propia fundación), TypeScript (Microsoft): muchos proyectos importantes están patrocinados por empresas que emplean a los mantenedores principales. Esto resuelve el problema de financiación: los mantenedores cobran, pueden trabajar a tiempo completo y el proyecto se beneficia de recursos de ingeniería corporativos.
El riesgo es el desalineamiento. Las prioridades de las empresas cambian. Mozilla despidió al equipo de Rust. Google ha quitado prioridad y financiación a proyectos open source cuando cambió su foco de negocio. Cuando los intereses estratégicos de una empresa divergen de los de la comunidad, la fricción es inevitable. La tendencia reciente de cambiar licencias por parte de patrocinadores corporativos (Redis, Terraform, Elastic) muestra lo frágil que puede ser este modelo.
Cuándo los forks son sanos
Hacer un fork, es decir, crear una copia competidora de un proyecto, suele verse como señal de fracaso. Pero en open source es, en realidad, la válvula de seguridad definitiva. Cuando el liderazgo falla, los forks permiten que la comunidad siga adelante sin depender de los mantenedores originales.
El fork io.js de Node.js empujó a Node hacia un modelo de gobernanza más abierto y ciclos de publicación más rápidos. Cuando los proyectos se volvieron a unir, Node salió beneficiado. LibreOffice, bifurcado de OpenOffice.org, rescató el proyecto del interés decreciente de Sun/Oracle. MariaDB, creado a partir de MySQL tras la adquisición por parte de Oracle, sigue como alternativa impulsada por la comunidad.
Más recientemente, los cambios de licencia han provocado forks productivos. Cuando Elastic cambió la licencia de Elasticsearch, Amazon lo bifurcó como OpenSearch. Cuando HashiCorp cambió la de Terraform, la comunidad creó OpenTofu bajo la Linux Foundation. Estos forks existen porque el derecho a bifurcar es el control último de la comunidad sobre el liderazgo del proyecto.
La clave es que un fork funciona mejor cuando se divide limpiamente la comunidad, no solo el código. Un fork con mantenedores activos y apoyo de la comunidad prospera. Un fork creado por un desarrollador frustrado al que nadie sigue solo genera confusión.
La espiral del agotamiento
La mayoría de las crisis de liderazgo en open source no empiezan con una salida dramática. Empiezan con el agotamiento: la erosión lenta de la capacidad y el entusiasmo del mantenedor bajo el peso de incidencias, pull requests, peticiones de funciones y usuarios exigentes.
La dinámica es predecible. Un mantenedor crea algo útil. Llegan usuarios. Con ellos llegan reportes de errores, peticiones de funciones, dudas de soporte y exigencias. El mantenedor, sintiéndose responsable, intenta responder a todo. El volumen supera su capacidad. Empieza a temer las notificaciones. Responde más lento, luego con más sequedad, y finalmente deja de responder. Al final desaparece, y el proyecto entra en un periodo de mantenimiento zombi: técnicamente vivo, en la práctica abandonado.
El agotamiento de los mantenedores de open source no es un fallo personal. Es un problema estructural: los proyectos generan una demanda ilimitada de tiempo y atención de un número finito de personas, sin ningún mecanismo integrado para gestionarla.
Algunos mantenedores han encontrado formas de sobrellevarlo: límites estrictos en los tiempos de respuesta, delegar el triaje en miembros de la comunidad, mantenimiento remunerado mediante GitHub Sponsors u Open Collective, o simplemente aceptar tiempos de respuesta más largos. Pero todo esto exige resistirse conscientemente a la presión de estar disponible sin descanso, algo que choca con la cultura de muchas comunidades open source.
Cómo se ve una sucesión sana
Algunos proyectos han gestionado bien las transiciones de liderazgo, y comparten patrones comunes.
- Conocimiento distribuido, no solo código distribuido. El «conocimiento tribal» del proyecto, es decir, por qué se tomaron ciertas decisiones, qué alternativas se consideraron y cuáles son los principios de diseño, se documenta y no queda solo en la cabeza de una persona. Los Architecture Decision Records (ADR) y las RFC detalladas cumplen esta función.
- Varias personas con acceso de escritura y autoridad de publicación. Si solo una persona puede publicar una versión, esa persona es un punto único de fallo. Los proyectos sanos tienen al menos entre 3 y 5 personas que pueden publicar nuevas versiones de forma independiente.
- Documentos de gobernanza explícitos. ¿Cómo se toman las decisiones? ¿Quién tiene autoridad sobre qué? ¿Cómo se añaden nuevos mantenedores? Los proyectos que responden estas preguntas antes de una crisis gestionan mejor la sucesión que los que improvisan.
- Transiciones graduales, no salidas repentinas. Las mejores transiciones de liderazgo ocurren cuando el líder saliente reduce deliberadamente su implicación durante meses, orienta a los sucesores y transfiere explícitamente la autoridad. Las salidas abruptas, incluso las bien intencionadas, dejan vacíos.
- Sostenibilidad financiera. Los proyectos con financiación fiable (a través de fundaciones, patrocinadores corporativos o financiación comunitaria) sobreviven mejor a las transiciones, porque los nuevos mantenedores pueden recibir compensación por su tiempo. Pedirle a alguien que herede un trabajo a tiempo completo sin pago es una propuesta difícil de aceptar.
Qué deben hacer los usuarios y las empresas
Si tu negocio depende de software open source, y así es, tienes interés en la salud de los proyectos de los que dependes. Algunos pasos prácticos:
- Audita el factor autobús de tus dependencias. Revisa los proyectos open source críticos de tu stack. ¿Cuántos mantenedores activos tienen? ¿Cuándo fue la última versión? ¿Qué tan rápido se atienden los problemas de seguridad? Un proyecto con un solo mantenedor y una vulnerabilidad de seguridad de seis meses es un riesgo que deberías conocer.
- Financia lo que usas. Si un proyecto es crítico para tu negocio, contribuye a su financiación. GitHub Sponsors, Open Collective y Tidelift ofrecen mecanismos para ello. El coste de financiar a un mantenedor es insignificante comparado con el de que una dependencia crítica quede sin mantenimiento.
- Contribuye aguas arriba. Las correcciones de errores, las mejoras de documentación y el triaje de incidencias reducen la carga del mantenedor y dan a tu equipo familiaridad con el código. Si el proyecto necesita nuevos mantenedores algún día, estarás en posición de dar un paso al frente.
- Ten un plan de contingencia. Para las dependencias críticas, sabe qué harías si el proyecto se abandonara. ¿Podrías hacer un fork y mantenerlo? ¿Hay una alternativa a la que podrías migrar? El momento de responder estas preguntas es antes de necesitarlas.
La gobernanza de proyectos open source no es un trabajo vistoso. No genera titulares ni estrellas en GitHub. Pero la diferencia entre un proyecto que sobrevive a la salida de su fundador y uno que no sobrevive casi siempre es la gobernanza: el trabajo aburrido y estructural de documentar decisiones, distribuir la autoridad y planificar la sucesión. Los proyectos que perduran son los que construyen instituciones, no solo software.
