Cambiando cómo desarrollamos Ladybird
Un anuncio de que el navegador Ladybird dejará de aceptar contribuciones públicas de código ha desencadenado preocupaciones más amplias sobre el futuro de la colaboración de código abierto en la era del código generado por IA. Los comentaristas señalan que los grandes modelos de lenguaje han hecho barato producir pull requests plausibles pero de baja calidad o poco fiables, saturando a los mantenedores —especialmente en proyectos sensibles a la seguridad como los navegadores— y rompiendo la antigua señal de “prueba de esfuerzo” que sustentaba la confianza. Muchos ven el giro de Ladybird hacia un modelo de desarrollo más cerrado, de estilo “catedral”, como comprensible, pero temen que erosione la participación comunitaria, dificulte el crecimiento de nuevos mantenedores y anticipe cambios similares en otros proyectos de código abierto.
Resumen del cambio
- Ladybird ya no aceptará contribuciones públicas de código; solo los mantenedores podrán incorporar cambios.
- El código fuente y la licencia siguen siendo abiertos; el cambio afecta al proceso de desarrollo, no a la licencia.
- La razón dada: riesgo de seguridad para un navegador, y el colapso de los PR como señal de confianza en la era del código generado por IA.
Reacciones sobre la apertura y el destino del proyecto
- Algunos ven esto como la “muerte” del aspecto comunitario del proyecto, y predicen la pérdida de buena voluntad y menos usuarios que se preocupen por navegadores independientes.
- Otros sostienen que es una medida razonable, incluso inevitable, para software serio de usuario final, señalando a SQLite, Lua, partes de Blender, etc. como modelos exitosos de “código abierto pero no desarrollo abierto”.
- Debate sobre la terminología: muchos insisten en que sigue siendo claramente código abierto (por licencia), no simplemente “source-available”, aunque las contribuciones estén cerradas.
IA, PR “slop” y señales de confianza rotas
- Tema central: la IA ha abaratado la generación de grandes parches, así que un PR grande ya no demuestra comprensión profunda ni buena fe.
- Los mantenedores informan estar desbordados por PR de baja calidad o codificados con vibra de IA, y por informes de vulnerabilidades duplicados; el esfuerzo de revisión no se ha vuelto más barato.
- Varios comentaristas generalizan esto a la escritura y a los foros: la IA rompe el contrato social implícito de que una producción sustancial implica un esfuerzo humano sustancial.
Seguridad, coste de revisión y agotamiento
- Para un navegador que ejecuta código no confiable, una sola vulnerabilidad sutil es catastrófica; esto amplifica la desconfianza hacia contribuyentes desconocidos.
- Muchos mantenedores dicen que revisar PR externos suele ser un coste neto y resulta más fácil que escribir ellos mismos la corrección, especialmente bajo el spam de IA.
- Algunos lo ven como análogo a un DDoS: la primera respuesta es levantar un cortafuegos.
Vías para futuros contribuyentes y mantenedores
- Preocupación importante: sin PR externos o incluso parches enviados por correo, ¿cómo surgirán nuevos mantenedores?
- Sugerencias del hilo: sistemas de confianza/reputación, verificación en persona en conferencias, cuotas pequeñas/limitadas de PR, reputación a través de proyectos, o reclutamiento mediante forks.
- Otros replican que históricamente la confianza a menudo se construía socialmente (listas de correo, interacción a largo plazo) más que solo mediante PR de GitHub, y esperan un regreso a eso.
Implicaciones más amplias para el código abierto
- Muchos esperan que más proyectos grandes adopten modelos de “catedral” o de contribución cerrada a medida que la IA escala el volumen de PR.
- Algunos temen que esto acelere el declive del desarrollo abierto y orientado a la comunidad, empujando el trabajo hacia comunidades cerradas, chats privados o espacios solo por invitación.
- Otros lo ven como un reinicio necesario, alejándose de “GitHub como red social” y volviendo a grupos más pequeños y de alta confianza, aunque eso excluya a muchos posibles contribuyentes.