Changement de méthode de développement pour Ladybird

• Ladybird cesse d’accepter les pull requests publiques à l’approche de sa première alpha release et de la préparation du lancement d’un navigateur destiné aux utilisateurs réels, et seuls les mainteneurs du projet intégreront désormais les changements de code
• Les outils d’IA permettent désormais de produire plus vite et à moindre coût des travaux qui ressemblent à des contributions sérieuses, ce qui affaiblit l’ancien modèle de confiance selon lequel un gros patch démontrait de bonnes intentions et un effort significatif
• Un navigateur exécute sur la machine de l’utilisateur des entrées non fiables provenant de l’ensemble d’Internet, si bien qu’une seule vulnérabilité bien dissimulée suffit à un attaquant
• Toutes les PR publiques actuellement ouvertes seront fermées, et aucun processus séparé de soumission de patchs ni système de contribution fantôme ne sera créé via les issues, les commentaires, l’email ou les forks
• Ladybird restera open source, et la participation externe sera orientée non plus vers la soumission de code mais vers des signalements de bugs clairs, des reproductions minimales, des tests de sites web, des discussions sur les standards et le design, des rapports de sécurité et des retours techniques

---

L’essentiel du changement de processus de développement

• Ladybird n’acceptera plus de pull requests publiques et adoptera un mode de fonctionnement dans lequel seuls les mainteneurs du projet intégreront les modifications dans la base de code
• À l’étape de préparation de la première alpha release, un processus de développement plus strict, un modèle de sécurité plus clair et un groupe plus restreint, responsable du code qui entre dans le navigateur, sont devenus nécessaires
• Par le passé, un patch conséquent constituait raisonnablement un signal indirect d’un effort important et de bonnes intentions, mais avec les outils d’IA, cette hypothèse ne tient plus
• Un navigateur exécute sur la machine de l’utilisateur des entrées non fiables venant d’Internet, et une seule vulnérabilité bien camouflée peut suffire à un attaquant
• Il y a déjà eu dans l’open source des campagnes patientes et bien financées visant à gagner puis à exploiter la confiance des mainteneurs, et ce qui change aujourd’hui, c’est qu’il est devenu plus rapide et moins coûteux de produire du travail qui semble être une contribution sérieuse
• Tous les changements intégrés à Ladybird doivent être compatibles avec l’architecture, résister aux futurs refactorings, interagir correctement avec le reste du navigateur, et être compris par les mainteneurs
• La question n’est pas de savoir si le code a été écrit à la main, mais qui en porte la responsabilité une fois qu’il entre dans le navigateur

Mesures de transition et formes de participation qui restent possibles

• Toutes les pull requests publiques actuellement ouvertes seront fermées, car conserver la file d’attente existante reviendrait dans les faits à laisser ouverte la voie des contributions publiques, et la transition est donc engagée dès maintenant
• À l’avenir, les pull requests ne seront accessibles qu’aux mainteneurs du projet
• Aucun processus séparé de soumission de patchs via les issues, les commentaires, l’email ou les forks ne sera mis en place, et les forks ou dépôts de patchs ne seront pas traités comme une file de revue pour le Ladybird upstream
• Du code externe peut exister selon les conditions de licence
• Ladybird restera open source, et le code source continuera d’être publié conformément aux licences open source
• La participation externe continuera d’aider le projet via des bug reports clairs, des reductions, des tests de sites web, des discussions sur les standards, des discussions de design, des rapports de sécurité et des retours techniques
• À l’étape de préparation du lancement d’un navigateur pour de vrais utilisateurs, le processus de développement doit lui aussi être à la hauteur de cette responsabilité

[GN⁺]

Réactions sur Hacker News

• Je vois passer récemment beaucoup de PR sur de gros projets open source comme Godot, et il y a nettement plus de PR où le code et l’explication sont entièrement produits par l’IA
  Comme c’est interdit par la politique du projet, l’auteur reçoit en général un simple rappel à l’ordre ; beaucoup l’acceptent bien, mais certains se mettent en colère parce que les mainteneurs ne leur sont pas reconnaissants
  Même les gens qui ont complètement adopté l’IA n’ont pas encore vraiment intégré qu’il n’y a pas de valeur intrinsèque à simplement produire un bloc de code
  Alors même que leurs efforts ont fortement diminué, ils s’attendent, lorsqu’ils soumettent une grosse PR, à recevoir la même réaction ou la même gratitude qu’avant l’IA

  • Cela dit, même avant l’IA, cette réaction n’était pas forcément justifiée. Un gros commit de code écrit à la main, potentiellement difficile à maintenir, n’est pas nécessairement une contribution positive, et une personne raisonnable ou un bon ingénieur n’attendrait pas de remerciements, quel que soit l’effort fourni
    Dans ce contexte, je ne m’attends pas à ce que les gens au sale caractère déjà trop nombreux dans ce milieu changent de comportement après l’arrivée de l’IA
    D’ailleurs, dans mon entreprise, du personnel non technique a commencé à soumettre des PR générées par l’IA sur le dépôt interne que je gère ; la qualité est excellente, et ils acceptent bien les retours de review puis les appliquent rapidement. Ce n’est pas un problème de profil technique, c’est un problème d’attitude
  • Il y a clairement chez certains adeptes du vibe coding une forme de sentiment de droit. Ce n’est peut-être pas le terme exact, mais c’est proche d’une obsession pour le livrable et d’une incapacité à accepter que l’essentiel du travail n’est pas vraiment le leur
    Cela transparaît non seulement dans leur manière de contribuer, mais aussi dans leur façon de parler au quotidien. On entend des choses comme « j’ai créé X », l’insistance sur le fait que leur propre « curation » a eu un impact énorme sur le résultat, la difficulté à reconnaître la contribution du LLM, l’attitude du type « moi je me concentre sur la création pendant que les autres perdent du temps sur les détails », ou encore le refus d’affronter les défauts potentiels
    C’est étonnamment différent des développeurs seniors qui soupçonnent toujours que ce qu’ils ont produit est peut-être rempli de défauts et bricolé à la va-vite. On dirait le syndrome de l’imposteur inversé
  • Si un projet a établi une règle selon laquelle il n’accepte pas les PR générées par l’IA, alors il ne faut absolument pas en soumettre à ce projet. C’est du spam. Même si les règles liées à l’IA sont plus nuancées, il faut les respecter
    Dans ce cas, le problème vient à 100 % des personnes qui envoient ces PR. Si quelqu’un montre qu’il n’a aucun scrupule à enfreindre les règles du projet et se montre même arrogant à ce sujet, cela devrait être un énorme signal d’alerte pour un employeur potentiel ou un futur collaborateur qui consulterait son profil
    Je ne comprends pas pourquoi ils sabotent volontairement leur réputation. Mieux vaut largement n’avoir aucune activité sur son profil que d’y laisser une trace de mauvais comportement
  • Je ne vois pas pourquoi il serait surprenant que des gens qui attendent des résultats sans effort aient aussi le sentiment de mériter des remerciements sans même avoir réfléchi
  • Dans ce genre de cas, on dirait bien que le LLM explique au « contributeur » à quel point il est intelligent et combien le projet se pénalise lui-même
    Quelque chose du style : « Il ne s’agit ni de préserver les frontières du projet, ni de garantir la qualité du code. C’est juste un mécanisme de gatekeeping mis en place par des traditionalistes qui se sentent menacés par des créateurs tournés vers l’avenir comme vous, qui maîtrisent vraiment l’efficacité de l’IA »

• « Un patch substantiel impliquait un effort substantiel, et cet effort était un indicateur indirect raisonnable de bonne foi. Cette hypothèse ne tient plus aujourd’hui. »
  Cette phrase est au cœur du billet, et je pense qu’elle s’applique à la plupart des projets

  • En généralisant, on découvre rapidement que l’IA rompt le contrat social entre l’auteur et le lecteur, qu’il s’agisse de prose, de code ou de n’importe quoi d’autre
  • D’accord. Je pense que la manière dont Ladybird procède ici pourrait devenir à l’avenir le modèle social habituel de l’open source
    Il faudra malgré tout un mécanisme pour juger si une personne peut, sur le long terme, s’investir suffisamment pour devenir mainteneur. Les contributions au code ne sont plus vraiment fiables comme signal, et je ne sais pas quel signal on utilisera à l’avenir. Ce sera un problème assez difficile
    Mais si l’IA augmente vraiment fortement la productivité des programmeurs, il se peut aussi qu’un projet open source réussi n’ait plus besoin d’une grande équipe de mainteneurs
  • Oui. C’est bien formulé et juste. Je n’avais jamais envisagé le spam de PR sous cet angle, mais c’est en réalité assez convaincant

• D’un côté, si on a grandi dans le bazar, passer à la cathédrale peut donner l’impression d’être face à « la mort de l’open source ». Alors qu’en réalité, ce n’est peut-être qu’un retour à une manière de travailler plus ancienne
  D’un autre côté, si on n’accepte plus de contributions de code externes, la posture de sécurité s’améliorera clairement, mais il deviendra plus difficile de savoir qui inviter dans le sacerdoce

  • Le développement open source est devenu de plus en plus superficiel à mesure qu’il s’est adapté aux caractéristiques des réseaux sociaux modernes. Plus que la valeur intrinsèque de la contribution ou du projet, ce sont les traces de contribution, l’historique de commits actifs, le nombre d’étoiles et autres preuves de réputation en pixels qui sont devenus importants
    Avant l’ascension de GitHub, les projets open source ressemblaient davantage à des jardins clos derrière de solides clôtures. Quand on entrait dans la pièce, on avait l’impression de petits clubs où tout le monde vous dévisageait. GitHub a marchandisé le contact et abaissé la barrière d’effort ou d’intérêt nécessaire avant de contribuer
    Cette époque est maintenant terminée, et il faut d’abord bâtir de la confiance avant de contribuer à quoi que ce soit
    Ce n’est pas la mort de l’open source, c’est la mort du village global où tout le monde circulait librement et interagissait facilement. C’est le retour de communautés petites, sociales et fondées sur la confiance, et j’aimerais que cette dynamique se propage à l’ensemble d’Internet
  • J’ai encore du mal à réaliser qu’il existe désormais toute une génération de développeurs qui n’a jamais connu un monde où « tout » était open source et développé selon le modèle du bazar
    Les gens aujourd’hui connaissent-ils seulement cette métaphore ou le livre de Raymond ? On vit dans un monde où Microsoft est un fournisseur majeur d’open source et détient la plateforme qui rend possible la majeure partie de la programmation open source sur Terre. Essayez d’expliquer ça à un voyageur temporel venu de la fin des années 1990
    Et comme le sous-entend le commentaire voisin, même un « bazar » typique comme le noyau Linux paraît aujourd’hui assez cathédrale comparé au modèle de chaos illimité de GitHub
  • Le point essentiel de cette annonce, c’est qu’à cause de l’IA, les contributions externes n’ont déjà presque plus aucune valeur comme signal pour identifier les personnes à inviter dans le sacerdoce
  • Si l’on regarde SQLite et ses projets frères (Fossil, etc.), on voit qu’il existe d’excellents projets open source qui fonctionnent très bien selon le modèle de la cathédrale
    Je ne vois donc pas la décision de Ladybird comme un problème. Au contraire, j’y vois une décision qui renforce la dimension humaine du développement logiciel et met un frein aux passagers clandestins de l’IA
  • Et si quelqu’un forkait le projet, puis appliquait ses patchs à ce fork ? Si ce fork rencontrait du succès et était réellement utilisé de manière active, l’upstream pourrait en reprendre sélectivement les patchs nécessaires. Le mainteneur du fork finirait lui aussi par être reconnu
    Ce n’est pas idéal, mais se construire une réputation a toujours été quelque chose qui prend du temps

• Quand je vois ce genre de choses, je me dis qu’on ferait peut-être mieux de ne pas avoir d’IA du tout
  C’est vraiment décevant de voir des projets open source perdre leur capacité à trouver de nouveaux mainteneurs et à les former

  • Ils ont réécrit un gros changement de leur projet avec un LLM
  • Je ne sais pas à quel point c’est vraiment lié à l’IA. Les problèmes d’open source et de mainteneurs existent depuis très longtemps

• « Il n’y aura aucune procédure pour soumettre des patchs, par quelque moyen que ce soit » et « la participation externe reste importante : des signalements de bugs clairs »
  Donc on peut trouver et corriger des bugs, mais on n’a pas le droit de dire exactement comment on les a corrigés ?
  L’équipe doit donc le redécouvrir elle-même. Ça doit vraiment les enthousiasmer de devoir refaire quelque chose que d’autres ont déjà fait à plusieurs reprises
  En tant qu’utilisateur et développeur, je ne vois pas pourquoi je consacrerais du temps à un projet qui met ce genre de barrières sur un logiciel susceptible d’améliorer ma vie. Il me paraît bien plus simple d’utiliser Firefox ou Chromium, où mes corrections peuvent réellement être acceptées
  Par le passé, quand une nouvelle version de Chromium faisait planter mon produit, j’ai pu proposer un correctif à V8, et il a été intégré à la version suivante de Chromium, ce qui a permis à mon produit de refonctionner ; ça a été extrêmement utile (https://github.com/v8/v8/commit/4f8a70adca01c)
  Sans cette voie, les développeurs de Chromium auraient peut-être manqué de temps pour identifier la cause et la corriger
  On dit que « les pull requests n’en disent plus autant qu’avant sur leur auteur », mais personne ne devrait avoir besoin de savoir quoi que ce soit sur la personne qui a ouvert la pull request
  J’aimerais que le code intégré dans Firefox ou Chromium soit jugé non pas sur les « efforts » ou la « bonne volonté » de son auteur, mais sur la justesse du code vérifiée lors de la revue
  Relire une correction de code est manifestement plus facile que la concevoir soi-même. Si ce n’est pas le cas, autant écrire directement le code soi-même
  Du point de vue du projet, il est toujours possible d’ignorer ou de fermer des PR non souhaitées. Mais interdire jusqu’à l’option de relire des contributions externes, ou de les utiliser comme base pour sa propre réécriture, ne semble pas très judicieux

  • Identifier précisément le point de rupture a bien plus de valeur que le code lui-même. Si tu as écrit le correctif, c’est que tu as déjà analysé le bug. La valeur n’est pas dans le code du correctif, mais dans l’analyse
    Partager cette analyse détaillée est la meilleure façon de maximiser la contribution. Le code n’est au mieux qu’un bonus facultatif
  • La revue de code de PR n’est pas une activité sans effort. Si 3 personnes travaillent sur le projet et que des milliers d’autres soumettent des PR de correction de bugs, ces 3 personnes seront totalement submergées par le simple volume des PR, même si ces corrections sont utiles
    Ta correction peut avoir de la valeur, mais cette valeur n’est pas forcément supérieure au coût de sa revue et de son intégration
    Dire que « relire une correction de code est manifestement plus facile que la concevoir soi-même » est complètement faux sur des projets suffisamment complexes. La correction peut tenir en une ligne, alors que ses conséquences peuvent se propager très loin
    En tant qu’utilisateur et développeur, si tu ne veux pas consacrer du temps à un projet qui suit de telles règles, alors ne le fais pas. Tu ne dois rien au projet, et le projet ne te doit rien non plus. C’est aussi simple que ça
    Firefox et Chromium sont portés par des équipes bien plus grandes, sans parler du noyau Linux. Ils ont peut-être les moyens d’accepter ta contribution
  • Tu présentes comme des faits l’idée qu’« il n’est pas nécessaire de savoir quoi que ce soit sur l’auteur, qu’il suffit de juger la justesse du code en revue, et que relire une correction est plus facile que de la produire », alors que cela va complètement à l’encontre de l’expérience réelle des mainteneurs open source
    C’est vrai non seulement dans mon expérience et dans le cas exposé dans le texte d’origine, mais aussi dans celle des nombreux mainteneurs qui ont partagé des billets similaires
    Peux-tu partager des liens vers des projets open source que tu maintiens depuis des années et où tu as relu des contributions, afin d’étayer ton expertise sur cette question ?
  • On peut toujours expliquer comment on a fait. Simplement, pas sous forme de code ou de patch
    Il suffit de l’écrire en langage naturel pour que les mainteneurs comprennent l’approche de résolution
  • Le point clé, c’est « ça m’a été extrêmement utile ». Tu veux que les autres changent pour répondre à tes besoins
    Leurs priorités et leurs besoins sont différents. Dans ce cas précis, ils ont évalué la situation et jugé que ce n’était pas utile. Autrement dit, le coût dépassait le bénéfice

• Il est intéressant de constater que, sur au moins un point important, Chromium/Gecko/WebKit ressemblent désormais à des moteurs de navigateur plus « ouverts » que Ladybird
  On pourrait dire que Servo est au milieu, puisqu’il accepte des contributions externes tant qu’elles n’utilisent pas l’IA
  On peut comprendre qu’une équipe peu financée ferme les contributions pour économiser du coût de travail. Mais j’ai aussi l’impression que les gens ne reconnaissent pas assez les ressources économiques que Google/Mozilla/Apple mobilisent pour rendre cette ouverture possible
  Pour exposer mes biais personnels et mon expérience : je suis à la retraite aujourd’hui, mais j’ai travaillé autrefois chez Google sur Chrome. J’ai vu beaucoup de collègues accompagner des contributeurs externes, et je l’ai moi-même fait dans un cadre informel ou via des programmes comme des stages

  • Ces entreprises ne font pas ça par bonté d’âme. Elles le font pour obtenir du contrôle afin de protéger la valeur de leur activité. Si l’intérêt économique disparaît, elles arrêteront dès demain
    Je ne pense pas qu’on doive être éternellement reconnaissant envers la construction de monopoles
  • Chrome est un produit d’appel à perte pour Google

• Je peux comprendre pourquoi ils prennent cette décision. Si la plupart des pull requests sont du code écrit par une IA, les mainteneurs peuvent tout aussi bien envoyer directement un prompt à Claude Code.
  Que ce soit dans l’open source ou non, j’ai l’impression que tout le jeu du software engineering a complètement changé. Un bloc de code ne signifie plus, ni n’implique, la même chose qu’il y a deux ans.

  • Je pense que c’est bien là le point essentiel.
    Il y a quelques années, si j’envoyais une PR complexe qui compilait et passait les tests, cela voulait dire que j’y avais investi ce temps et cet effort cognitif. Si je n’avais pas compris la codebase, la fonctionnalité ou le bug, il y a de fortes chances que je n’aurais pas fait cet investissement.
    Aujourd’hui, le coût pour acquérir cette compréhension reste globalement similaire à avant, mais l’IA a fortement réduit le coût de production d’un code qui compile et passe les tests.
    Les membres de la communauté, probablement de bonne foi, sont volontiers prêts à contribuer la chose devenue bon marché, c’est-à-dire des tokens Claude Code, mais comme cela coûte désormais trop peu, ce n’est plus un bon indicateur qu’ils ont apporté la chose coûteuse, la compréhension humaine.
  • Je vois souvent des positions du genre « le code généré par IA n’a aucune valeur ». Il est vrai qu’il est facile de produire du code sans valeur, mais je ne suis pas d’accord avec l’idée que tout code généré par IA ait une valeur nulle.
    Je travaille sur un side project avec OpenCode, et j’investis pas mal de temps à écrire des prompts, préparer les bons fichiers, et expliquer le produit que j’essaie de construire ainsi que sa roadmap.
    Je mets ensuite en place une boucle de validation serrée, capable d’exécuter beaucoup de contrôles automatiques après chaque changement, puis j’itère après avoir testé manuellement de nombreux cas limites que la fonctionnalité générée pourrait casser. C’est un type de travail différent, mais je peux avancer plus vite qu’en codant à la main. L’élément clé, c’est la boucle de validation.
    D’après mon expérience de ces derniers mois, coder avec l’IA est aussi une compétence : on apprend de nouvelles techniques en essayant, et on progresse. Cela veut aussi dire qu’en s’y prenant bien, on peut produire des résultats de valeur.
    Donc je ne suis pas d’accord avec la première phrase, mais j’adhère complètement à la seconde. Ce que nous avons perdu, c’est la capacité à distinguer facilement un résultat mûrement réfléchi d’un résultat généré sans réflexion. Ici, se concentrer sur une validation peu coûteuse serait d’une grande aide.
  • Le code n’est plus l’effort principal du travail. Puisque tout le monde peut générer une implémentation, il est plus rationnel que jamais de se montrer bien plus exigeant sur le quoi, pourquoi et comment qui sous-tendent une modification de code.
    J’ai l’impression que tous les projets vont évoluer dans cette direction. Il est plus logique d’affiner le plan ensemble.
  • Comme tu le dis, il serait presque plus utile de demander qu’on envoie plutôt le prompt.

• Quand l’IA est apparue, j’ai eu peur qu’un jour elle me fasse perdre mon travail. J’ai eu de la chance, mais beaucoup de gens l’ont réellement perdu, et ça a fait très mal.
  Quand quelqu’un perd quelque chose à cause de l’automatisation, indépendamment de la logique économique, on a envie d’être du côté des humains, ou au moins d’espérer que la société reste juste envers celles et ceux qui sont le plus touchés.
  Maintenant, je vois les communautés être touchées. Si on tue les PR, ce ne sont pas seulement les contributions de code qui vacillent, mais aussi les contributions invisibles comme les idées, ou le fait d’avoir davantage de regards sur le code. Et ça me paraît bien pire.
  Je suis tiraillé, confus, et j’ai peur. Et pourtant, j’utilise Claude et DeepSeek, diverses technologies, des harnesses complexes, du MCP, etc. Mais pour l’instant, tout cela ressemble à une période de transition. Une transition vers quoi exactement, je n’en sais rien.
  À beaucoup de ces questions, on ne peut pas répondre si l’on ne donne pas un sens à la vie. Le toucher humain ? Est-ce déjà trop tard ? Et puis, j’aimais bien une chanson, avant d’apprendre que c’était du Suno. Après l’avoir su, j’ai retiré mon like. J’ai l’impression d’être idiot bien trop souvent.
  Désolé pour cette digression décousue. J’aime Ladybird, j’ai même un sticker sur mon laptop. J’espère que ça marchera pour eux.

  • Je me reconnais dans cette phrase : « Tout cela ressemble à une période de transition. Une transition vers quoi exactement ? »
    J’ai l’impression d’être au beau milieu d’une tornade. Malgré tout, couper l’écran, s’asseoir à son bureau, se calmer, puis repenser lentement aux premiers principes aide.
    Pour reprendre Obama : « la réalité finit toujours par rattraper tout cela ».
    On parle beaucoup, mais iOS ne sort pas chaque année dix ans de fonctionnalités et de correctifs. Littéralement personne n’y arrive, et au contraire on entend des plaintes sur des fonctionnalités existantes qui se cassent. Donc l’idée que nous serions à une productivité multipliée par 10 ne peut pas être vraie, et ce fait finira par nous rattraper.
    Il faut réfléchir en êtres humains. Il faut aussi se souvenir que beaucoup de gens sont émotionnellement investis. Les juniors veulent que ce soit l’occasion de briller dans un marché qui les a rejetés. Les CEO ont parié sur l’IA et ne veulent pas faire marche arrière. Les seniors veulent envoyer le signal qu’ils ne sont pas devenus inutiles. Les entreprises d’IA vont polluer le débat. Mais cette fumée finira par se dissiper.
  • Il a toujours existé une petite quantité de ce genre de « contributions », mais la plupart ne correspondaient pas vraiment à ce qu’elles prétendaient être.
    En pratique, cela aboutissait le plus souvent à des avis non sollicités, des tentatives de prise de contrôle hostiles, de l’extraction de valeur, du drama en général, et une charge opérationnelle globale qui venait simplement se greffer sur le fait de produire du code.
    Cela n’a pas toujours été le cas, mais le modèle GitHub de développement open source libre et la suppression de toutes les frictions ont clairement créé une nouvelle norme par défaut.
    Ce modèle n’a jamais été soutenable à l’origine, mais le rythme d’épuisement était suffisamment faible pour qu’on puisse tenir en remplaçant les personnes usées par davantage d’humains.
    L’IA a fait passer le rythme d’épuisement au-dessus du rythme de remplacement. Il est donc très probable que davantage de projets adoptent cette position, ou une position proche.
  • Il est tout à fait normal d’avoir des sentiments contradictoires à propos de quelque chose, et cela ne signifie pas automatiquement qu’il y a un problème. C’est profondément humain, et je ressens quelque chose de similaire.
    Je suis créateur et programmeur ; je n’aime pas voir ce qui se passe dans certaines communautés, tout en utilisant des agents pour développer. Comme il était difficile d’éviter Google et Stack Overflow lorsqu’ils sont apparus, j’ai l’impression qu’il y a aussi avec les LLM un moment très net d’avant et après.
    Je n’ai pas grand-chose d’utile à ajouter, mais je voulais au moins dire que tu n’es pas seul à ressentir ce conflit. Les nouveautés sont souvent comme ça : elles apportent d’immenses gains dans certains domaines, mais semblent retirer de l’humanité ailleurs ; certaines personnes les utilisent pour produire de la frime et des déchets, tandis que d’autres acquièrent de nouvelles capacités et construisent quelque chose de meilleur. Malheureusement, il n’y a pas de vérité universelle.
  • Tu peux arrêter à tout moment. La réalité malheureuse, c’est que beaucoup de gens ne s’en soucient guère tant que ce sont les autres qui subissent les dégâts ; mais si cela détruit maintenant quelque chose que tu chéris personnellement, pourquoi continuer à le soutenir, moralement ou financièrement ?
  • Le fait que l’usage et le soutien des LLM propriétaires finissent simplement par enrichir davantage OpenAI, Anthropic, Google, etc., ne me met pas non plus à l’aise. Je ne peux pas justifier leur usage.

• La lecture de ce billet laisse un arrière-goût étrange. L’auteur a en effet tendance à produire des PR non triviales de plus de 1 000 lignes, parfois plusieurs par jour, puis à les fusionner le jour même sans review.
  Même en laissant de côté l’aspect LLM, cela reste problématique. Je ne sais pas quel pourcentage a été aidé, mais même si c’était 0 %, ce n’est pas un rythme de développement avec lequel je me sentirais à l’aise.

  • C’est totalement cohérent avec ce qui est dit ici.
    « Le point essentiel n’est pas de savoir si le code a été tapé à la main. L’important est de savoir qui en assume la responsabilité une fois qu’il entre dans le navigateur. Ladybird est en train de devenir un navigateur pour de vrais utilisateurs. La personne qui introduit un changement doit décider que ce changement a sa place dans le projet, et être celle qui en répondra. »
  • J’ai perdu confiance dans certains mainteneurs de projets open source qui fonctionnent de cette façon.
    Dans mon entreprise, nous utilisons depuis des années une plateforme open source, en version Enterprise payante. Une faille de sécurité assez grotesque a été introduite dans cette plateforme et, en regardant de plus près, il était clair que l’IA avait pris le contrôle du projet.
    Que cela soit explicitement indiqué ou non, c’est évident rien qu’au volume et à la fréquence dans les logs de commits. C’était très décevant.
  • Sa page GitHub [1] va aussi dans ce sens, dans une certaine mesure. 83 % de commits, 14 % de PR, 2 % de reviews, 1 % d’issues. C’est clairement hors de contrôle.
    [1] https://github.com/awesomekling

• Les LLM sont peut-être l’une des raisons qui ont conduit Ladybird à prendre cette décision, mais ce n’est pas la seule raison possible. Par exemple, SQLite est développé à peu près de cette manière depuis presque le début.
  Chacun semble avoir sa propre approche.

  • Lua aussi, si je me souviens bien, est similaire. C’est de l’open source, mais pas du développement ouvert.
    La licence est MIT et les mainteneurs apprécient toujours les rapports de bugs, mais tout le code du projet a été écrit par seulement trois personnes.
  • Je ne vois pas vraiment où est le problème. Certains des meilleurs logiciels sont créés et maintenus par un tout petit groupe très investi.
    C’est une décision parfaitement rationnelle pour protéger leur temps et leur projet.

[GN⁺]

Avis sur Lobste.rs

• En ce moment, faire des revues de contributions sur clang est vraiment misérable. Un flot interminable de PR nulles arrive, et les gens cachent mieux les signes évidents, mais on peut encore généralement les repérer, sauf que les filtrer prend du temps
  Même quand quelqu’un admet utiliser l’IA et explique comment, il faut encore vérifier si c’est vrai ou si la personne minimise son usage pour faire passer une mauvaise PR
  J’ai vu énormément de PR comme ça jusque-là, mais je ne crois pas avoir vu une seule PR de vibe coding qui soit réellement bonne. Certaines sont “correctes” et leur auteur commence lui-même à faire le travail, mais la plupart disparaissent, et pour le reste il est évident, même sans connaissance interne de clang, que les bases mêmes du code sont complètement fausses
  Le pire, ce sont les scripts qui automatisent le pipeline fuzzer → bug → LLM → PR, en comprenant gravement de travers le bug réel, en le “corrigeant” de façon cassée, et en ajoutant de mauvais tests, voire sans même inclure le cas d’échec d’origine
  Au final, ça réduit même l’envie de consacrer du temps à faire monter de nouveaux contributeurs en compétence. Quand un nom inconnu envoie une PR pour corriger un crash, je commence d’abord par me demander si c’est une perte de temps ou quelqu’un qui pourrait devenir un vrai contributeur
  Les gens qui se contentent de jeter des déchets sur un projet ne s’intéressent ni à la contribution ni à l’apprentissage, et pour la plupart on dirait qu’ils veulent surtout pouvoir mettre quelque chose comme « contribution à clang » sur leur CV

  • Le site web de D a une liste des contributeurs générée automatiquement à partir des PR fusionnées ; un débutant est venu sur le chat demander comment cette liste était mise à jour, puis a ouvert une PR mineure en pressant qu’on la fusionne
    Il est revenu plusieurs fois ensuite pour demander : « pourquoi la liste n’est-elle pas mise à jour ? pourquoi je n’y suis toujours pas ? », puis a disparu une fois le site actualisé
    Cela dit, moi aussi j’étais idiot de façon comparable quand j’étais plus jeune. J’ai déjà envoyé un mail pour demander qu’on ajoute à une liste un miroir que j’avais créé parce qu’on disait qu’on pouvait mettre en miroir le site web d’une personnalité célèbre de l’open source, et je me suis aussi abonné à la mailing list de développement de nmap pour devenir un 1337 hax0r sans jamais envoyer de patch

• La définition du problème est claire pour tout le monde. Depuis des décennies, les projets open source ont appris à qui faire confiance à travers les contributions de code : les gens faisaient le travail, assumaient la responsabilité des changements et restaient, et la confiance naissait du travail lui-même
  Mais je pense que cette solution est une version strictement pire que l’interdiction des contributions LLM choisie par le projet Zig
  Maintenant que les outils d’IA changent rapidement l’économie du secteur, une PR n’en dit plus autant qu’avant sur son auteur. Un gros patch impliquait autrefois un gros effort et servait d’indicateur indirect de bonne foi, mais cette hypothèse ne tient plus
  Ce qui m’inquiète, c’est que l’open source est déjà une activité difficile et qu’il faut exploiter au maximum ses avantages précieux ; or les contributeurs apportent en pratique une valeur énorme presque gratuitement (contributor poker), et ils sont aussi très importants comme vivier de recrutement. Rejeter tout cela en bloc me paraît être un choix insensé
  On pourrait soutenir que les LLM peuvent combler ce vide, mais d’abord on aurait pu interdire l’usage des LLM uniquement dans les PR de contributeurs non fiables ; ensuite même les meilleurs LLM ont un coût, le prix des tokens augmente, le code doit de toute façon être relu, et au bout du compte ils ne peuvent pas devenir des contributeurs clés de confiance responsables d’une partie de la base de code
  Si on supprime l’apport de code venant des PR, alors avec le temps une petite minorité de contributeurs finira par posséder l’ensemble du code, ce qui rendra un license rugpull plus facile pour le projet. Quand la propriété du copyright est bien répartie, c’est beaucoup plus difficile
  Globalement, ça ne sent pas bon. Cela transforme l’open source en modèle économique encore plus problématique qu’il ne l’est déjà, rend le recrutement de contributeurs clés plus difficile et concentre la propriété du code entre quelques mains. C’est une recette évidente pour le désastre, au point de me faire me demander si ce n’est qu’une simple erreur ou si certains sponsors de Ladybird jouent à un drôle de jeu

  • Pour être juste, l’open source n’implique pas forcément des contributions publiques ou une gouvernance communautaire. SQLite est un bon exemple de projet qui n’accepte aucune contribution tierce, et cela semble plutôt bien fonctionner
  • En regardant la liste des sponsors, je ne vois pas vraiment de groupe qui aurait intérêt à faire un rugpull sur un navigateur. Certains semblent problématiques pour d’autres raisons, mais pas avec ce genre de motivation
    Je suis vraiment curieux de connaître le fond de ce changement. Pour un projet qui se vantait en tête de ses rapports mensuels du nombre et de la diversité des nouveaux contributeurs, c’est un virage très brusque. L’explication fournie ici semble au minimum incomplète
  • Je travaille chez SUSE, une entreprise de distribution commerciale, dans un domaine adjacent à l’open source, et mon travail consiste moins à utiliser directement des navigateurs, compilateurs ou bases de données qu’à maintenir leurs versions en aval. Mon point de vue et mes limites viennent de là
    Zig et Ladybird cherchent tous deux une voie à suivre dans un avenir que nous ne voulions pas. Pendant des années, nous n’avons rien vu venir, et honnêtement je ne pensais pas que cet avenir arriverait. Maintenant, il n’est plus du tout clair de savoir ce qui est la “bonne chose à faire”
    Ce que j’aimerais demander à Zig, c’est ceci : on ne peut pas distinguer une PR LLM d’une PR écrite directement par un humain. On peut filtrer les déchets produits sans effort, mais pour faire du “sans IA”, il faut une sorte de test de Turing, et moi avec une licence Claude Pro je peux tout à fait le réussir
    Ce que fait réellement le “sans IA”, c’est permettre d’attaquer quelqu’un, ainsi que sa réputation, s’il envoie du code généré avec un LLM en prétendant que c’est du travail manuel et qu’il se fait prendre. Est-ce vraiment à cela qu’on veut consacrer du temps ? On finirait avec une sorte de Karl Jobst chargé de débusquer ceux qui utilisent des LLM en se faisant passer pour des codeurs à la main
    Cela n’empêche pas les PR issues de LLM, cela transforme juste le jeu en “attrape-moi si tu peux”. Quand j’ai vu Andreas prendre chez Ladybird une décision proche d’un rugpull, j’ai d’abord eu un frisson dans le dos, puis je me suis dit qu’il avait du culot. L’assistance par LLM et la confiance sont de très gros sujets, et j’aimerais voir Zig comme Ladybird réfléchir hors des cadres habituels
  • En lisant les statuts de l’organisation Ladybird (https://ladybird.org/assets/documents/…), j’ai été déçu d’apprendre que Christopher Wanstrath est co-BDFL. Avant, je pensais qu’il avait simplement donné 1 million de dollars et aidé à créer l’organisation
    En réalité, il est Designator et, si je lis correctement le texte, cette position lui est garantie à vie sauf démission ou incapacité. Les Designators décident à la majorité, mais comme ils ne sont que deux, ils doivent être d’accord tous les deux ; ce sont eux qui nomment ou révoquent les Directors, et leur accord est aussi nécessaire pour modifier les statuts
    En d’autres termes, il dispose de fait d’un droit de veto sans contre-pouvoir sur l’organisation à but non lucratif. Andreas aussi, mais Andreas est quelqu’un qui a produit une grande partie du travail, qui est impliqué dans le projet et qui n’est pas milliardaire. Wanstrath, lui, est milliardaire, s’est engagé à donner une fraction infime de sa fortune et n’est pas impliqué dans l’exploitation, tout en ayant les mêmes pouvoirs
    Sauf s’il y a une bonne raison juridique qui m’échappe, cela ne ressemble pas à une bonne structure de gouvernance pour un projet open source

• Je m’inquiète de voir ce qu’il adviendra à long terme des projets qui ont récemment fermé les contributions. À un moment, une partie des personnes clés de confiance finira par partir, et sans contributeurs de long terme déjà éprouvés, il risque de ne pas y avoir de successeurs évidents
  La trajectoire par défaut pourrait mener au burn-out et à des projets abandonnés, donc j’espère qu’ils trouveront un moyen de surmonter ça

  • J’espère que la frénésie autour des LLM se stabilisera ou retombera, ou que d’autres projets trouveront une manière durable de gérer l’avalanche de “contributions”. Du coup, je pense que ce sera temporaire. Le texte laisse aussi entendre qu’ils n’ont pas l’intention de rester comme ça après une release stable

• Je ne vois là aucune forme de leadership. Ce n’est pas un pas dans la bonne direction, ni une idée sur la manière dont nous pourrions coexister
  Je comprends que la pression soit réelle, mais la réponse semble cynique et défaitiste plutôt que dynamique et porteuse d’espoir, ce qui est décevant

  • Je suis curieux de savoir pourquoi tu ne vois pas ça comme allant dans la bonne direction

• Le passage disant qu’ils vont “fermer toutes les pull requests publiques actuellement ouvertes dans le cadre de ce changement” est choquant
  Il y a quelques années, un projet a fermé ma PR en décidant qu’il n’avait pas les ressources pour relire des PR ; ça fait assez mal et ce n’est pas juste pour les contributeurs qui ont investi du travail dans cette PR

  • Ça peut être blessant, mais si le mainteneur n’a pas effectivement demandé l’écriture de cette PR, je pense qu’il est difficile de parler d’injustice
  • Il n’est pas juste d’attendre que quelqu’un relise un travail non sollicité

• Je comprends les raisons avancées, mais la décision m’inquiète. Ce n’est pas forcément une mauvaise chose, et si c’est temporaire, avec un autre compromis trouvé plus tard, ça pourrait aller, mais cela reste préoccupant
  Ce n’est pas non plus le premier signal inquiétant. La réécriture Rust assistée par LLM m’a fait la même impression. Contrairement à Bun, cela semblait relativement prudent, avec des composants de taille révisable, des entrées et sorties claires, et une exécution en parallèle avec les composants existants pour repérer les divergences. Malgré cela, ce n’est pas la méthode que j’ai envie de voir dans un moteur de navigateur
  J’espère que Ladybird réussira. Je veux qu’un nouveau moteur de navigateur remette en cause la structure oligopolistique. Mais si Ladybird déraille, il est aussi rassurant de voir que Servo, qui stagnait depuis des années, progresse enfin bien

  • Je soutiens Servo. Quand je pense à la personne qui dirige Ladybird et aux opinions qu’elle porte, même en cas de succès, je n’ai pas envie que ce genre de personnes soit derrière l’une des applications les plus importantes sur ma machine. Au moins, pour l’instant, il y a aussi ce type de politique

• Utiliser du code poubelle généré par IA pour l’implémentation Rust, soutenir DHH, autrement dit sembler du côté du suprémacisme blanc et de l’anti-LGBT, tout en paraissant assez agressif. Je ne pense pas que ce projet ira très loin

• S’il n’y a pas de voie d’entrée permettant aux gens de devenir contributeurs depuis l’extérieur, j’ai l’impression qu’ils vont passer à côté de beaucoup de choses. Même si cela demande un engagement plus sérieux que de simplement passer et envoyer une PR
  De cette façon, lorsqu’ils voudront ajouter des développeurs, le vivier de personnes connaissant la base de code sera plus large, et des organisations externes pourront aussi résoudre des besoins que l’équipe centrale ne considère pas comme prioritaires. Cela aide aussi à l’adoption et réduit la charge de travail

• Je ne pense pas qu’il soit juste d’apposer le tag vibecoding à ce billet. Regrouper les victimes du vibe coding sous le même tag que les gens qui font la promotion de cette pratique me semble fondamentalement étrange

  • Ce contexte manque si l’on ne lit que ce billet, mais à la lumière d’autres billets récents et du contexte, l’une des raisons de fermer les PR est aussi la prolifération des PR de vibe coding, tout en sachant qu’eux-mêmes sont en train de basculer principalement vers le vibe coding. Le récent portage en vibe coding de C++ vers Rust vaut aussi le détour.