Cambiando cómo desarrollamos Ladybird

Artículo original ↗ Discusión en Hacker News ↗

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.