Cambio en la forma de desarrollar Ladybird

• Ladybird dejará de aceptar pull requests públicas de cara a su primera alpha release y a la preparación del lanzamiento del navegador para usuarios reales, y solo los mantenedores del proyecto incorporarán cambios al código
• Con las herramientas de IA ahora es posible producir más rápido y más barato trabajo que parece una contribución seria, lo que debilita el modelo de confianza anterior donde un parche grande servía como señal de buena fe y esfuerzo significativo
• Un navegador ejecuta en la máquina del usuario entradas no confiables de todo internet, por lo que una sola vulnerabilidad bien disfrazada puede ser suficiente para un atacante
• Todas las PR públicas actualmente abiertas se cerrarán, y no se creará un proceso alternativo para enviar parches mediante issues, comentarios, correo electrónico o forks, ni un sistema de contribuciones en la sombra
• Ladybird seguirá siendo de código abierto, y la participación externa se orientará a reportes claros de errores, reproducciones mínimas, pruebas de sitios web, discusiones sobre estándares y diseño, reportes de seguridad y retroalimentación técnica en lugar de envío de código

---

Puntos clave del cambio en el proceso de desarrollo

• Ladybird ya no aceptará pull requests públicas y pasará a un modelo en el que solo los mantenedores del proyecto incorporan cambios al codebase
• En esta etapa de preparación para la primera alpha release se necesita un proceso de desarrollo más estricto, un modelo de seguridad más claro y un grupo más pequeño que se haga responsable del código que entra al navegador
• Antes, un parche sustancial era una señal indirecta razonable de esfuerzo importante y buena fe, pero con las herramientas de IA esa suposición ya no se sostiene
• El navegador ejecuta en la máquina del usuario entradas no confiables de internet, y una sola vulnerabilidad bien camuflada puede darle al atacante las condiciones que necesita
• Ya ha habido campañas pacientes y con recursos en el mundo open source para ganarse la confianza de los mantenedores y abusar de ella; lo que cambió es que ahora es más rápido y más barato producir trabajo que parece una contribución seria
• Todos los cambios que entren a Ladybird deben encajar con la arquitectura, resistir futuras refactorizaciones, interactuar correctamente con el resto del navegador y poder ser entendidos por los mantenedores
• Lo importante no es si el código fue escrito a mano, sino quién se hace responsable de él una vez que entra al navegador

Medidas de transición y formas de seguir participando

• Todas las pull requests públicas actualmente abiertas se cerrarán, ya que mantener la cola existente en la práctica dejaría abierta la vía de contribuciones públicas, por lo que la transición se hará ahora
• En adelante, las pull requests solo estarán disponibles para los mantenedores del proyecto
• No se creará un proceso separado para enviar parches mediante issues, comentarios, correo electrónico o forks, y no se tratarán los forks ni los lotes de parches como una cola de revisión para Ladybird upstream
• El código externo puede existir según lo permitan las condiciones de la licencia
• Ladybird seguirá siendo open source, y el código fuente continuará disponible conforme a su licencia de código abierto
• La participación externa puede ayudar al avance del proyecto mediante bug reports claros, reductions, pruebas de sitios web, discusiones sobre estándares, discusiones de diseño, reportes de seguridad y retroalimentación técnica
• En esta etapa de preparación para lanzar el navegador a usuarios reales, el proceso de desarrollo también debe estar a la altura de esa responsabilidad

[GN⁺]

Opiniones en Hacker News

• Últimamente estoy viendo muchos PR de proyectos grandes de código abierto como Godot, y han aumentado bastante los PR cuyo código y descripción fueron hechos por IA
  Como la política del proyecto los prohíbe, normalmente al autor solo se le llama la atención de forma ligera; mucha gente lo acepta bien, pero algunos se enojan porque los mantenedores no les agradecen
  Parece que incluso quienes ya se subieron por completo al tren de la IA todavía no han interiorizado que producir bloques de código en sí mismo no tiene un valor intrínseco
  Aunque el esfuerzo propio se redujo muchísimo, cuando envían un PR grande esperan la misma reacción o gratitud que antes de la IA

  • La reacción previa a la IA tampoco era necesariamente justa. Un gran commit de código escrito a mano que luego puede ser difícil de mantener no es obligatoriamente una contribución positiva, y cualquier ingeniero decente o incluso una persona común no esperaría agradecimiento sin importar cuánto esfuerzo haya invertido
    En ese sentido, no espero que la abundancia de gente con mala actitud que siempre hubo en esta industria cambie su comportamiento por culpa de la IA
    Por cierto, personal no técnico de mi trabajo empezó a enviar PR generados por IA al repositorio interno que administro, y la calidad es excelente; además aceptan bien el feedback de revisión y lo incorporan rápido. No es un problema de no ser técnico, es un problema de actitud
  • En parte del mundo del vibe coding sí hay claramente una especie de sentido de derecho adquirido. No es la palabra exacta, pero se parece a una obsesión con el resultado final y a no poder aceptar que la mayor parte del trabajo no fue suya
    Se nota no solo en cómo contribuyen, sino también en cómo hablan habitualmente. Está el “yo hice X”, la insistencia en que su “curaduría” influyó muchísimo en el resultado, la dificultad para hablar del aporte del LLM, la actitud de “yo me concentro en crear y los demás pierden tiempo en detalles”, o la negativa a enfrentarse a defectos potenciales
    Es sorprendentemente distinto de los desarrolladores senior, que siempre sospechan que lo que hicieron puede estar lleno de fallas y haber sido hecho a la carrera. Se siente como un síndrome del impostor invertido
  • Si un proyecto tiene una regla de no aceptar PR generados por IA, entonces jamás debes enviarle PR generados por IA. Eso es spam. Incluso si las reglas sobre IA son más matizadas, hay que respetarlas
    El problema aquí es 100% de quienes envían esos PR. Si alguien tiene antecedentes de romper las reglas del proyecto sin remordimiento e incluso con arrogancia, eso debería ser una enorme señal de alerta para posibles empleadores o futuros colaboradores que revisen su perfil
    No entiendo por qué alguien arruinaría su propia reputación a propósito. Es muchísimo mejor tener un perfil sin actividad que dejar un historial de mal comportamiento
  • No veo por qué habría de sorprender que gente que espera resultados sin esfuerzo sienta también que merece agradecimiento sin haber pensado mucho
  • En estos casos, me imagino que el LLM le está diciendo al “colaborador” lo inteligente que es y cuánto se está perjudicando el proyecto
    Algo como: “Esto no se trata de proteger los límites del proyecto ni de garantizar la calidad del código. Es un mecanismo de control de acceso creado por tradicionalistas que se sienten amenazados por creadores visionarios como tú, que realmente dominan la eficiencia de la IA”

• “Un parche sustancial implicaba un esfuerzo sustancial, y ese esfuerzo era un indicador indirecto razonable de buena fe. Ahora esa suposición ya no se sostiene.”
  Creo que esa frase es el núcleo del texto y aplica a la mayoría de los proyectos

  • Si lo generalizamos, estamos descubriendo rápidamente que la IA rompe el contrato social entre quien escribe y quien lee, ya sea prosa, código o cualquier otra cosa
  • De acuerdo. Creo que lo que Ladybird está haciendo aquí podría convertirse en el modelo social habitual del código abierto de ahora en adelante
    Aun así, hace falta algún mecanismo para juzgar si una persona puede comprometerse lo suficiente a largo plazo como para convertirse en mantenedora. Las contribuciones al código ya no son una señal confiable para eso, y no sé qué señal vamos a usar en el futuro. Va a ser un problema bastante difícil
    Pero si la IA de verdad aumenta drásticamente la productividad de los programadores, quizá los proyectos exitosos de código abierto ya no necesiten equipos grandes de mantenedores
  • Sí. Está bien escrito y es acertado. Nunca había pensado en el spam de PR desde esta perspectiva, pero la verdad resulta bastante convincente

• Por un lado, si creciste en el bazar, pasar a la catedral puede sentirse como “la muerte del código abierto”. Aunque en realidad podría ser simplemente una vuelta a una forma de trabajo más antigua
  Por otro lado, si no se aceptan contribuciones externas de código, sin duda mejorará la postura de seguridad, pero será más difícil averiguar a quién invitar al sacerdocio

  • El desarrollo de código abierto se ha vuelto cada vez más superficial para acomodarse a las características de las redes sociales modernas. La evidencia de contribuciones, de historial activo de commits o de cuántas estrellas tienes, esos pixeles de prestigio, pasó a importar más que el valor intrínseco de la contribución o del proyecto
    Antes de que GitHub se volviera dominante, los proyectos de código abierto eran más parecidos a jardines amurallados. Eran como pequeños clubes donde, al entrar a una sala, todos te miraban fijamente. GitHub mercantilizó el contacto y redujo la barrera de esfuerzo o interés necesaria antes de contribuir
    Ahora esa etapa terminó, y antes de contribuir a cualquier cosa primero hay que construir confianza
    Esto no es la muerte del código abierto, sino la muerte de la aldea global donde todos podían deambular libremente e interactuar con facilidad. Es el renacimiento de comunidades pequeñas, sociales y basadas en la confianza, y ojalá esta tendencia se extienda a todo internet
  • Todavía no me acostumbro a que ya exista toda una generación de programadores que nunca vio un mundo donde “todo” fuera código abierto y se desarrollara al estilo bazar
    ¿La gente de hoy siquiera conoce esa metáfora o el libro de Raymond? Vivimos en un mundo donde Microsoft es un proveedor principal de código abierto y además controla la plataforma que hace posible la mayor parte de la programación de código abierto del planeta. Intenta explicárselo a un viajero del tiempo de finales de los 90
    Además, como insinuó el comentario hermano, incluso un “bazar” clásico como el kernel de Linux hoy parece bastante catedral comparado con el modelo de caos ilimitado de GitHub
  • El punto central de este anuncio es que, debido a la IA, las contribuciones externas ya casi no valen nada como señal para identificar a quién invitar al sacerdocio
  • Si miras SQLite y sus proyectos hermanos (Fossil, etc.), hay excelentes proyectos de código abierto que funcionan bien también con el modelo catedral
    Por eso no veo la decisión de Ladybird como un problema. Más bien la veo como una decisión que refuerza el lado humano del desarrollo de software y pone freno a los oportunistas de la IA
  • ¿Y qué tal si alguien hace un fork del proyecto y mete sus parches en ese fork? Si el fork tiene éxito y usuarios reales lo usan activamente, upstream podría tomar de ahí los parches que necesite de forma selectiva. Al final, el mantenedor del fork también terminaría siendo reconocido
    No es lo ideal, pero construir reputación siempre ha sido algo que toma tiempo

• Esto me hace pensar que ojalá la IA no existiera en absoluto.
  Es muy decepcionante que los proyectos de código abierto estén perdiendo la capacidad de encontrar y mentorizar nuevos mantenedores.

  • Reescribieron un cambio grande de su proyecto con un LLM.
  • No sé realmente qué tanto tiene que ver esto con la IA. Los problemas del código abierto y de los mantenedores existen desde hace muchísimo tiempo.

• Eso de “no habrá un proceso para enviar parches por ningún medio” y “la participación externa sigue siendo importante: reportes de bugs claros”...
  Entonces, ¿puedes encontrar y arreglar bugs, pero no puedes decir exactamente cómo los arreglaste?
  En cambio, el equipo tiene que volver a descubrirlo por su cuenta. Seguro que al equipo le encantará tener que rehacer algo que otra persona ya logró repetidamente.
  Como usuario y desarrollador, no entiendo por qué debería dedicar tiempo a un proyecto que pone este tipo de barreras a software que podría mejorar mi vida. Parece mucho más fácil usar Firefox o Chromium, donde mis cambios sí pueden ser aceptados.
  En el pasado, cuando una nueva versión de Chromium hacía crashear mi producto, pude proponer una corrección a V8 y la incluyeron en la siguiente versión de Chromium, con lo que mi producto volvió a funcionar; fue algo muy valioso (https://github.com/v8/v8/commit/4f8a70adca01c).
  Sin ese canal, puede que los desarrolladores de Chromium no hubieran tenido tiempo de identificar la causa y corregirla.
  Dicen que “las pull requests ya no nos dicen tanto sobre quien las envía”, pero nadie debería necesitar saber nada sobre la persona que envía una pull request.
  Espero que el código que entra en Firefox o Chromium se decida por la corrección del código verificada en la revisión, no por el “esfuerzo” o la “buena voluntad” de quien lo envía.
  Revisar una corrección de código es obviamente más fácil que idearla desde cero. Si no lo fuera, entonces simplemente escribirían el código ellos mismos.
  Desde la perspectiva del proyecto, siempre pueden ignorar o cerrar PRs que no quieran. Pero bloquear por completo la opción de revisar contribuciones externas, o de usarlas como insumo para sus propias reescrituras, no parece muy inteligente.

  • Señalar con precisión dónde está el problema vale mucho más que el código. Si escribiste el arreglo, entonces ya analizaste el bug. El valor no está en el código del arreglo, sino en el análisis.
    Compartir ese análisis sofisticado es la forma de maximizar la contribución. El código, como mucho, es un bono opcional.
  • Revisar código en una PR no es una acción sin esfuerzo. Si en un proyecto trabajan 3 personas y miles envían PRs con arreglos de bugs, por útiles que sean esos arreglos, esas 3 personas quedan completamente abrumadas por la cantidad de PRs.
    Tu arreglo puede tener valor, pero ese valor quizá no sea mayor que el costo de revisarlo y aceptarlo.
    Decir que “revisar una corrección de código es obviamente más fácil que idearla” es completamente falso en proyectos lo bastante complejos. La corrección puede ser de una sola línea, pero sus efectos pueden propagarse muy lejos.
    Si como usuario y desarrollador no quieres dedicar tiempo a un proyecto con esas reglas, entonces no lo hagas. Tú no le debes nada al proyecto, y el proyecto no te debe nada a ti. Así de simple.
    Firefox y Chromium operan con equipos mucho más grandes, y ni hablar del kernel de Linux. Tal vez ellos sí tengan capacidad para aceptar tu contribución.
  • Hablas como si “no hace falta saber nada del remitente, solo mirar la corrección del código en la revisión, y revisar una corrección es más fácil que crearla” fueran hechos, pero eso va totalmente en contra de la experiencia real de los mantenedores de código abierto.
    No solo de mi experiencia y del caso del texto original, sino también de la experiencia de muchísimos mantenedores que han compartido opiniones similares.
    ¿Podrías compartir enlaces a proyectos de código abierto que hayas mantenido durante años y donde hayas revisado contribuciones, como base de tu supuesta experiencia en este tema?
  • Todavía puedes explicar cómo lo hiciste. Simplemente no en forma de código o parche.
    Basta con escribirlo como una explicación en lenguaje natural para que los mantenedores entiendan el enfoque de la solución.
  • La clave está en “fue algo muy valioso para mí”. Tú quieres que otros cambien para satisfacer tus necesidades.
    Sus prioridades y necesidades son distintas. En este caso, lo evaluaron y concluyeron que no les resultaba útil. Eso significa que el costo era mayor que el beneficio.

• Es interesante que, al menos en un aspecto importante, Chromium/Gecko/WebKit ahora parezcan motores de navegador más “abiertos” que Ladybird.
  Se podría decir que Servo está en un punto intermedio, ya que acepta contribuciones externas siempre que no usen IA.
  Se entiende que un equipo con poco financiamiento tenga que cerrar contribuciones para ahorrar costos laborales. Pero también siento que la gente no reconoce lo suficiente los recursos económicos que Google/Mozilla/Apple destinan para hacer posible esa apertura.
  Para declarar mis propios sesgos y experiencia: ahora estoy retirado, pero antes trabajé en Google desarrollando Chrome. Vi a muchos colegas formar contribuidores externos, y yo también lo hice en cierta medida, de manera informal o mediante programas como pasantías.

  • Esas empresas no lo hacen por buena voluntad. Lo hacen para asegurar control y proteger el valor de su negocio. Si deja de ser rentable, lo detendrán mañana mismo.
    No creo que haya que agradecer eternamente la construcción de monopolios.
  • Chrome es un producto gancho con pérdidas para Google.

• Entiendo por qué toman esa decisión. Si la mayoría de los pull requests son código escrito con IA, entonces los mantenedores también pueden meter prompts directamente en Claude Code.
  Creo que todo el juego de la ingeniería de software, sea open source o no, cambió por completo. Un bloque de código ya no significa ni implica lo mismo que hace dos años.

  • Creo que este es el punto clave.
    Hace unos años, si yo enviaba un PR complejo que compilaba y pasaba las pruebas, eso significaba que había invertido esa misma cantidad de tiempo y esfuerzo cognitivo. Si no hubiera entendido la base de código, la funcionalidad o el bug, probablemente no habría hecho esa inversión.
    Ahora el costo de obtener esa comprensión sigue siendo más o menos parecido al de antes, pero la IA redujo mucho el costo de generar código que compila y pasa las pruebas.
    Los miembros bien intencionados de la comunidad están dispuestos a aportar lo barato, o sea, tokens de Claude Code, pero como eso se volvió demasiado barato, ya no es un buen indicador de que también hayan aportado lo caro: comprensión humana.
  • A menudo veo posturas del tipo “el código generado por IA no tiene valor”. Es cierto que ahora es fácil producir código de valor cero, pero no estoy de acuerdo con que todo el código generado por IA tenga valor cero.
    Yo uso OpenCode para trabajar en proyectos personales, y dedico bastante tiempo a escribir prompts, preparar los archivos adecuados y explicar el producto y la hoja de ruta que quiero construir.
    Después itero con un bucle de validación bien ajustado que me permite correr muchas verificaciones automáticas tras cada cambio, y pruebo manualmente muchos casos límite que la funcionalidad generada podría romper. Es un tipo de trabajo distinto, pero puedo avanzar más rápido que cuando programo todo a mano. El componente clave es el bucle de validación.
    Por mi experiencia de estos últimos meses, programar con IA también es una habilidad: aprendes técnicas nuevas al probar cosas y mejoras con la práctica. Eso también significa que, si lo haces bien, puedes producir resultados valiosos.
    Así que no coincido con la primera frase, pero estoy totalmente de acuerdo con la segunda. Lo que perdimos es la capacidad de distinguir fácilmente entre un resultado profundamente pensado y uno generado sin pensar. Aquí ayudaría mucho enfocarse en la validación barata.
  • El código ya no es el esfuerzo principal del trabajo. Como cualquiera puede generar una implementación, tiene más sentido que nunca discutir con más rigor el qué, por qué y cómo detrás de cualquier cambio de código.
    Creo que todos los proyectos van a ir en esa dirección. Tiene más sentido refinar el plan en conjunto.
  • Como dices, hasta sería más útil pedir que te envíen el prompt.

• Cuando apareció la IA por primera vez, tenía miedo de perder mi trabajo algún día. Yo tuve suerte, pero mucha gente sí lo perdió, y eso dolió bastante.
  Cuando alguien pierde algo por la automatización, más allá de la lógica económica, uno tiende a ponerse del lado humano, o al menos a querer que la sociedad siga siendo justa con quienes salen más afectados.
  Ahora veo a las comunidades siendo afectadas. Si matas los PR, no solo se tambalean las contribuciones de código, sino también aportes invisibles como las ideas o más ojos revisando el código. Eso se siente mucho peor.
  Me siento en conflicto, confundido y asustado. Y aun así estoy usando Claude, DeepSeek, varias tecnologías, harnesses complejos, MCP y todo eso. Pero ahora mismo todo parece una transición. No sé hacia qué transición exactamente.
  Muchas preguntas no se pueden responder si no les das un sentido en la vida. ¿El toque humano? ¿Ya es demasiado tarde? Además, había una canción que me gustaba y resultó ser de Suno. Cuando me enteré, le quité el like. Siento que muy seguido quedo como un idiota.
  Perdón por desviarme y sonar desordenado. Me gusta Ladybird, hasta tengo un sticker en mi laptop. Ojalá le vaya bien.

  • También me identifico con eso de “todo esto parece una transición. ¿Una transición hacia qué exactamente?”.
    Se siente como estar en medio de un tornado. Aun así, ayuda apagar la pantalla, sentarse en el escritorio, recordar con calma los primeros principios y pensar despacio.
    Para citar a Obama: “la realidad termina alcanzándote”.
    Se habla mucho, pero iOS no está lanzando cada año diez años de funciones y correcciones. Literalmente nadie está logrando eso; más bien la gente se queja de que se rompen funciones existentes. Así que no puede ser verdad que hayamos llegado a una productividad 10x, y ese hecho eventualmente nos va a alcanzar.
    Hay que pensar como seres humanos. También hay que recordar que mucha gente está emocionalmente invertida en esto. Los juniors quieren que sea su oportunidad de brillar en un mercado que los rechazó. Los CEO apostaron por la IA y no quieren echarse para atrás. Los seniors quieren mandar la señal de que no se volvieron inútiles. Las empresas de IA van a contaminar la conversación. Pero al final este humo se va a disipar.
  • Sí existía una pequeña cantidad de estas “contribuciones”, pero la mayoría en realidad no era lo que decía ser.
    En general terminaban siendo opiniones no deseadas, intentos de toma hostil, extracción de valor, drama en general y una carga operativa adicional encima del simple trabajo de hacer código.
    No siempre fue así, pero el modelo de desarrollo open source libre estilo GitHub y la eliminación de toda fricción claramente crearon una nueva configuración por defecto.
    Ese modelo ya era insostenible de origen, pero la tasa de desgaste era lo bastante baja como para aguantar reemplazando a la gente agotada por más personas.
    La IA hizo que la tasa de desgaste superara la tasa de reemplazo. Por eso es muy probable que más proyectos adopten esta postura o algo parecido.
  • Tener sentimientos encontrados sobre algo es completamente normal, y no significa de inmediato que haya un problema. Es algo profundamente humano, y yo me siento parecido.
    Soy creador y programador, y aunque no me gusta ver lo que está pasando en ciertas comunidades, también uso agentes para desarrollar. Igual que era difícil evitar Google y Stack Overflow cuando aparecieron, parece que con los LLM también hay un claro momento de antes y después.
    No tengo mucho más útil que agregar, pero sí quiero decir que no eres la única persona que siente este conflicto. Las cosas nuevas suelen ser así: en algunas áreas traen beneficios enormes, pero en otras parecen arrancarle la humanidad a las cosas; algunas personas producen puro humo y basura, mientras otras ganan capacidades nuevas y construyen algo mejor. Por desgracia, no parece haber una verdad universal.
  • Siempre puedes parar. La triste realidad es que a mucha gente no le importa demasiado cuando el daño lo sufren otros, pero si ahora está destruyendo algo que tú valoras personalmente, ¿por qué seguir apoyándolo moral o financieramente?
  • Tampoco me deja tranquilo el hecho de que usar y apoyar LLM privativos al final solo hace más ricos a OpenAI, Anthropic, Google y compañía. No puedo justificar ese uso.

• Este texto me deja una sensación extraña. El autor suele crear PR no triviales de más de 1.000 líneas, a veces varios en un solo día, y tiende a fusionarlos el mismo día sin revisión
  Incluso dejando de lado el tema de los LLM, sigue siendo así. No sé qué porcentaje de eso fue asistido, pero aunque fuera 0%, no es una velocidad de desarrollo con la que yo me sentiría cómodo

  • Es totalmente consistente con lo que se dijo aquí
    “No importa si el código se escribió a mano. Lo importante es quién se hace responsable una vez que ese código entra al navegador. Ladybird está camino a convertirse en un navegador para usuarios reales. Quien introduce un cambio debe decidir que ese cambio pertenece al proyecto y debe ser quien responda por sus consecuencias.”
  • He perdido la confianza en algunos mantenedores de proyectos open source que hacen este tipo de cosas
    Hay una plataforma open source que hemos usado durante años en la empresa, y usamos la versión Enterprise de pago. A esa plataforma le metieron una vulnerabilidad de seguridad bastante absurda, y al revisarla quedó claro que la IA se había apoderado del proyecto
    Estuviera o no explicitado, con solo ver el log de commits era evidente por la cantidad y la frecuencia. Fue muy decepcionante
  • Su página de GitHub [1] también parece encajar hasta cierto punto. 83% commits, 14% PR, 2% reviews, 1% issues. Claramente está fuera de control
    [1] https://github.com/awesomekling

• Los LLM pueden ser una de las razones que llevaron a Ladybird a tomar esta decisión, pero no son la única posible. Por ejemplo, SQLite se ha desarrollado así casi desde el principio y lo sigue haciendo
  Parece que cada quien tiene su propia forma de trabajar

  • Lua también es parecido, si no recuerdo mal. Es open source, pero no tiene un desarrollo abierto
    Tiene licencia MIT y los mantenedores siempre agradecen los reportes de bugs, pero todo el código del proyecto lo han escrito solo 3 personas
  • No veo cuál es el gran problema aquí. Parte del mejor software lo crea y mantiene un grupo muy pequeño y muy dedicado
    Es una medida completamente razonable para proteger su tiempo y su proyecto

[GN⁺]

Comentarios en Lobste.rs

• Últimamente, revisar contribuciones en clang es demasiado miserable. Siguen llegando PR basura sin fin, la gente oculta mejor las señales obvias, pero por lo general aún se pueden detectar, y filtrarlos toma tiempo
  Incluso cuando alguien admite usar AI y explica cómo la usó, igual hay que volver a verificar si eso es cierto o si está minimizando su uso para hacer pasar un PR malo
  He visto muchísimos PR así hasta ahora, pero no creo haber visto ni uno solo de vibe coding PR que de verdad haya sido bueno. Algunos están en un nivel “aceptable” y la persona que los envía sí empieza a hacer el trabajo por su cuenta, pero la mayoría desaparece, y del resto es evidente que están completamente equivocados incluso en conceptos básicos de programación, aun sin tener conocimiento interno de clang
  Lo peor son los scripts que automatizan el pipeline fuzzer→bug→LLM→PR: malinterpretan gravemente el bug real, lo “arreglan” de una forma rota, y le agregan pruebas malas o ni siquiera incluyen el caso que fallaba originalmente
  Al final, hasta se te quitan las ganas de invertir tiempo en nuevos contribuidores y ayudarles a desarrollar capacidad. Cuando un nombre desconocido envía un PR para corregir un crash, primero sospechas si es una pérdida de tiempo o si de verdad será alguien que termine siendo un contribuidor real
  La gente que solo le avienta basura al proyecto no está interesada en contribuir ni en aprender, y la mayoría parece querer poner algo como “contribuí a clang” en su currículum

  • En el sitio web de D hay una lista de contribuidores generada automáticamente a partir de los PR fusionados. Una vez, un principiante entró al chat a preguntar cómo se actualizaba esa lista, luego envió un PR trivial y empezó a insistir para que se lo fusionaran
    Después siguió volviendo para preguntar: “¿Por qué no se actualiza la lista? ¿Por qué todavía no aparezco?”. Cuando el sitio finalmente se actualizó, desapareció
    Aunque, siendo justo, yo también fui así de tonto cuando era joven. Una vez vi que se podía crear un mirror del sitio web de una figura famosa del open source, así que hice uno y mandé un correo para pedir que lo agregaran a la lista; y también me suscribí a la lista de correo de desarrollo de nmap porque quería ser un 1337 hax0r, pero nunca envié un patch

• La definición del problema es clara para todos. Durante décadas, los proyectos de código abierto aprendieron en quién confiar a través de las contribuciones de código: la gente hacía trabajo, se hacía responsable de los cambios y permanecía, y la confianza surgía del trabajo mismo
  Pero me parece que esta solución es una versión estrictamente peor que la prohibición de contribuciones con LLM que eligió el proyecto Zig
  A medida que las herramientas de IA cambian la economía rápidamente, ahora un PR ya no dice tanto sobre quien lo envía como antes. Antes, un parche grande implicaba un gran esfuerzo y servía como indicador indirecto de buena fe, pero esa suposición ya no se sostiene
  Lo preocupante es que el código abierto es un negocio difícil y debería aprovechar al máximo sus ventajas valiosas, y los contribuyentes en la práctica aportan un valor enorme casi gratis (contributor poker); además, son muy importantes como vía de contratación. Rechazar todo eso parece una decisión de locos
  Se podría argumentar que los LLM pueden llenar ese vacío, pero en primer lugar se podría haber prohibido el uso de LLM solo en los PR de colaboradores no confiables; en segundo lugar, incluso el mejor LLM cuesta dinero, el precio de los tokens está subiendo, el código de todos modos hay que revisarlo y, al final, no puede convertirse en un colaborador central de confianza que se responsabilice de una parte de la base de código
  Si eliminas el flujo de código que llega por PR, con el tiempo unos pocos contribuyentes terminan adueñándose de todo el código, y eso hace más fácil que el proyecto haga un rugpull de licencia. Si la propiedad del copyright está bien distribuida, eso se vuelve más difícil
  En general se ve mal. Está convirtiendo al código abierto en un modelo de negocio innecesariamente más problemático, dificultando más la contratación de colaboradores clave y concentrando la propiedad del código en pocas manos. Es una receta tan claramente desastrosa que me hace preguntarme si fue un simple error o si algunos patrocinadores de Ladybird están jugando algún juego raro

  • Siendo justos, código abierto no significa necesariamente contribuciones públicas o gobernanza comunitaria. SQLite es un buen ejemplo de un proyecto que no acepta en absoluto contribuciones de terceros, y parece que le va bastante bien
  • Al ver la lista de patrocinadores, no se aprecia mucho qué grupo podría beneficiarse de un rugpull en un navegador. Algunos parecen problemáticos por otras razones, pero no se ve esa clase de motivación
    De verdad me intriga qué hay detrás del cambio. Que un proyecto que al inicio de sus informes mensuales presumía la cantidad de nuevos contribuyentes diversos cambie de rumbo así de repente es un giro muy brusco. La explicación que dieron ahora parece, como mínimo, incompleta
  • Trabajo cerca del código abierto desde SUSE, una empresa de distribuciones comerciales, y mi trabajo consiste más en mantener versiones derivadas que en usar directamente navegadores, compiladores o bases de datos. De ahí viene mi perspectiva y también mis límites
    Tanto Zig como Ladybird están tratando de encontrar cómo seguir adelante en un futuro que no queríamos. Durante años no entendí nada y, sinceramente, no pensé que este futuro fuera a llegar. Ahora mismo ya no está nada claro qué es “lo correcto”
    Lo que me gustaría preguntarle a Zig es esto: no se puede distinguir entre PR hechos con LLM y PR hechos directamente por personas. Se puede filtrar la basura de poco esfuerzo, pero para aplicar un “prohibido IA” hay que pasar una especie de prueba de Turing, y yo con una licencia de Claude Pro podría pasarla perfectamente
    Lo que realmente hace una política de “prohibido IA” es permitir atacar a una persona y su reputación si alguien envía código de LLM, dice que fue trabajo manual y luego lo descubren. ¿De verdad quieren gastar tiempo en eso? Sería como crear una especie de Karl Jobst dedicado a atrapar a gente que usa LLM fingiendo que codifica a mano
    No detiene los PR con LLM; solo convierte el juego en “a ver si me atrapas”. Cuando vi a Andreas tomar en Ladybird una decisión cercana a un rugpull, primero sentí un escalofrío y luego pensé que, al menos, tiene audacia. La asistencia de LLM y la confianza son problemas realmente grandes, así que me gustaría ver tanto a Zig como a Ladybird pensar fuera del molde
  • Me decepcionó enterarme, al leer los estatutos de la organización Ladybird (https://ladybird.org/assets/documents/…), de que Christopher Wanstrath es co-BDFL. Antes pensaba que solo había donado 1 millón de dólares y ayudado a fundar la organización
    En realidad es Designator y, según como lo leo, ese estatus está garantizado de por vida salvo que renuncie o quede incapacitado. Los Designators deciden por mayoría, pero como solo son 2, ambos tienen que estar de acuerdo; además, designan y remueven a los Directors y también se requiere su consentimiento para cambiar los estatutos
    Es decir, en la práctica tiene un veto sin contrapesos sobre la organización sin fines de lucro. Andreas también, pero Andreas es quien creó una parte importante del trabajo, está involucrado en el proyecto y no es multimillonario. Wanstrath es multimillonario, decidió donar una fracción ínfima de su riqueza y no participa en la operación, pero tiene el mismo poder
    A menos que me esté perdiendo alguna buena razón legal, no suena como una buena estructura de gobernanza para un proyecto de código abierto

• Me preocupa qué va a pasar a largo plazo con los proyectos que recientemente cerraron las contribuciones. En algún momento parte del personal central de confianza se va a ir, y sin contribuidores de largo plazo ya probados puede que no haya sucesores evidentes
  El camino por defecto puede llevar a burnout y proyectos abandonados, así que espero que encuentren una manera de superarlo

  • Espero que la fiebre de los LLM se estabilice o se enfríe, o que otros proyectos encuentren una forma sostenible de manejar la avalancha de “contribuciones”. Por eso creo que esto será temporal. El texto también da a entender que no planean seguir así para siempre después del lanzamiento estable

• No veo esto como ninguna clase de liderazgo. No es ni un paso en la dirección correcta ni una idea sobre cómo podemos convivir con esto
  Entiendo que la presión es real, pero me decepciona que la respuesta se sienta cínica y derrotista, en vez de enérgica y esperanzadora

  • Me gustaría saber por qué no lo ves como la dirección correcta

• La parte de “como parte de este cambio cerraremos todos los pull request públicos abiertos actualmente” fue impactante
  Hace unos años, un proyecto cerró un PR mío al decidir que no tenía recursos para revisarlo, y dolió bastante; tampoco es justo con los contribuyentes que invirtieron trabajo en ese PR

  • Puede doler, pero si el mantenedor en realidad no pidió que se escribiera ese PR, me cuesta decir que sea injusto
  • No es justo esperar que alguien revise trabajo no solicitado

• Entiendo las razones presentadas, pero la decisión me preocupa. No digo que sea necesariamente mala, y si es temporal y después encuentran otro punto de equilibrio, quizá esté bien, pero aun así me inquieta
  Tampoco es la primera señal de preocupación. La reescritura en Rust asistida por LLM me dio una sensación parecida. A diferencia de Bun, fue un enfoque relativamente más cuidadoso, con componentes de tamaño revisable, entradas y salidas claras, y ejecución en paralelo con componentes existentes para detectar discrepancias. Aun así, no es el tipo de enfoque que me gustaría ver en un motor de navegador
  Ojalá a Ladybird le vaya bien. Quiero que un nuevo motor de navegador desafíe la estructura oligopólica. Pero si pienso en la posibilidad de que Ladybird se desvíe, también es una suerte que Servo, que estuvo estancado durante años, esté avanzando bien

  • Yo apoyo a Servo. Si pienso en quién lidera Ladybird y en las posturas que tiene, incluso si tiene éxito, no quiero que haya gente así detrás de una de las aplicaciones más importantes en mi máquina. Al menos por ahora, también existe esta política

• Están usando código basura de IA en la implementación en Rust, y parecen estar del lado que apoya a DHH, es decir, del lado del supremacismo blanco y anti-LGBT, además de verse bastante agresivos. No creo que este proyecto vaya a llegar muy lejos

• Si no hay una vía de entrada para que la gente contribuya desde afuera, creo que van a perder muchas cosas. Incluso si hace falta un compromiso más serio que simplemente pasar y mandar un PR
  Hacerlo así también amplía el grupo de personas que conocen el codebase cuando quieran sumar desarrolladores, y organizaciones externas podrían resolver necesidades que el equipo central no tenga como prioridad. Eso también ayuda con la adopción y reduce la carga de trabajo

• No me parece correcto ponerle a esta publicación la etiqueta de vibecoding. Meter a las víctimas del vibecoding en la misma etiqueta que quienes promueven esa práctica es algo fundamentalmente extraño

  • Ese contexto no aparece si solo lees esta publicación, pero si revisas otras publicaciones recientes y el trasfondo, una de las razones para cerrar PRs es la proliferación de PRs de vibecoding, y al mismo tiempo ellos mismos están pasando principalmente a vibecoding. También vale la pena revisar el port reciente de C++ a Rust hecho con vibecoding