Änderung der Entwicklungsweise von Ladybird

• Ladybird stellt mit Blick auf die erste Alpha-Release und die Vorbereitung auf die Veröffentlichung eines Browsers für echte Nutzer die Annahme öffentlicher Pull Requests ein; Änderungen an der Codebasis werden nur noch von den Maintainers des Projekts übernommen
• Durch AI-Tools ist es schneller und günstiger geworden, Arbeit zu erzeugen, die wie ein ernsthafter Beitrag aussieht, wodurch das bisherige Vertrauensmodell geschwächt wurde, nach dem große Patches guten Willen oder erheblichen Aufwand signalisierten
• Ein Browser führt auf der Maschine des Nutzers nicht vertrauenswürdige Eingaben aus dem gesamten Internet aus, daher reicht Angreifern schon eine einzige gut getarnte Schwachstelle
• Alle derzeit offenen öffentlichen PRs werden geschlossen; außerdem wird weder ein separates Verfahren zur Einreichung von Patches über Issues, Kommentare, E-Mail oder Forks noch ein Schatten-Beitragssystem geschaffen
• Ladybird bleibt Open Source, und externe Beteiligung soll statt über Code-Einreichungen über klare Bug Reports, reduzierte Reproduktionen, Website-Tests, Standard- und Design-Diskussionen, Sicherheitsmeldungen und technisches Feedback erfolgen

---

Kernaussagen zur Änderung des Entwicklungsprozesses

• Ladybird wird künftig keine öffentlichen Pull Requests mehr annehmen und auf ein Modell umstellen, bei dem nur die Maintainers des Projekts Änderungen an der Codebasis übernehmen
• In der Phase der Vorbereitung auf die erste Alpha-Release werden ein strengerer Entwicklungsprozess, ein klareres Sicherheitsmodell und eine kleinere Gruppe benötigt, die Verantwortung für den Code im Browser übernimmt
• Früher waren umfangreiche Patches ein vernünftiges indirektes Signal für erheblichen Aufwand und guten Willen, doch durch AI-Tools gilt diese Annahme nicht mehr
• Ein Browser verarbeitet auf der Maschine des Nutzers nicht vertrauenswürdige Eingaben aus dem Internet, und schon eine einzige gut getarnte Schwachstelle ist für Angreifer ausreichend
• Es hat im Open-Source-Bereich bereits geduldige und gut ausgestattete Kampagnen gegeben, die versuchten, das Vertrauen von Maintainers zu gewinnen und auszunutzen; neu ist, dass sich mit Arbeit, die wie ein ernsthafter Beitrag wirkt, nun schneller und günstiger erzeugen lässt
• Alle Änderungen, die in Ladybird einfließen, müssen zur Architektur passen, künftige Refactorings überstehen, korrekt mit dem Rest des Browsers interagieren und von den Maintainers verstanden werden können
• Entscheidend ist nicht, ob Code von Hand geschrieben wurde, sondern wer die Verantwortung dafür übernimmt, sobald er in den Browser aufgenommen wurde

Umstellung und weiterhin mögliche Beteiligung

• Alle aktuell offenen öffentlichen Pull Requests werden geschlossen; würde die bestehende Warteschlange beibehalten, bliebe der Weg für öffentliche Beiträge faktisch offen, daher erfolgt die Umstellung jetzt
• Künftig stehen Pull Requests nur noch den Maintainers des Projekts zur Verfügung
• Es wird kein separates Verfahren zur Einreichung von Patches über Issues, Kommentare, E-Mail oder Forks eingerichtet, und Forks oder Patch-Dumps werden nicht als Review-Queue für das Upstream-Ladybird behandelt
• Externer Code kann im Rahmen der Lizenzbedingungen weiterhin existieren
• Ladybird bleibt Open Source, und der Quellcode wird gemäß den Open-Source-Lizenzbedingungen weiterhin öffentlich verfügbar sein
• Externe Beteiligung hilft dem Projekt weiterhin durch klare bug reports, reductions, website testing, standards discussion, design discussion, security reports und technical feedback
• In der Vorbereitungsphase auf die Veröffentlichung eines Browsers für echte Nutzer muss auch der Entwicklungsprozess dieser Verantwortung gerecht werden

[GN⁺]

Hacker-News-Kommentare

• In letzter Zeit sehe ich viele PRs in großen Open-Source-Projekten wie Godot, bei denen Code und Beschreibung komplett von KI erzeugt wurden.
  Laut Projektregeln ist das verboten, daher bekommen Einreichende meist eine leichte Ermahnung. Viele akzeptieren das, aber manche werden wütend, weil die Maintainer ihnen angeblich keine Dankbarkeit zeigen.
  Selbst Leute, die voll auf KI setzen, scheinen noch nicht verinnerlicht zu haben, dass das bloße Erzeugen eines Codeklumpens keinen inhärenten Wert hat.
  Obwohl ihr eigener Aufwand stark gesunken ist, erwarten sie bei einem großen PR dieselbe Reaktion oder Dankbarkeit wie vor der KI.

  • Auch die Reaktionen vor der KI waren nicht unbedingt gerechtfertigt. Große Mengen handgeschriebenen Codes, die schwer zu warten sein könnten, sind nicht automatisch ein positiver Beitrag, und ein vernünftiger Engineer oder auch einfach ein normaler Mensch würde unabhängig vom Aufwand keine Dankbarkeit erwarten.
    In diesem Zusammenhang erwarte ich nicht, dass die in dieser Branche ohnehin schon zu häufigen unangenehmen Typen ihr Verhalten wegen KI ändern werden.
    Nebenbei: Nichttechnische Mitarbeitende bei mir im Unternehmen haben angefangen, KI-generierte PRs an interne Repositories zu schicken, die ich verwalte, und die Qualität ist hervorragend; sie nehmen Review-Feedback gut an und arbeiten es schnell ein. Das Problem ist nicht, dass sie nicht technisch sind, sondern ein Einstellungsproblem.
  • In Teilen der Vibe-Coding-Szene gibt es eindeutig eine Art Anspruchsdenken. Das ist vielleicht nicht das perfekte Wort, aber es beschreibt eine Haltung, die auf das Ergebnis fixiert ist und nicht akzeptieren kann, dass der Großteil der Arbeit nicht von einem selbst stammt.
    Das zeigt sich nicht nur in der Art des Beitrags, sondern auch in der Sprache: „Ich habe X gebaut“, das Beharren darauf, dass die eigene „Kurierung“ das Ergebnis stark geprägt habe, die Schwierigkeit, den Beitrag des LLM überhaupt zu benennen, die Haltung „Ich konzentriere mich aufs Bauen und andere verschwenden Zeit mit Details“ und die Weigerung, sich mit potenziellen Mängeln auseinanderzusetzen.
    Das ist erstaunlich anders als bei Senior-Entwicklern, die immer vermuten, dass ihre Ergebnisse voller Mängel sein und schlampig gemacht sein könnten. Es wirkt wie ein umgedrehtes Impostor-Syndrom.
  • Wenn ein Projekt die Regel hat, keine KI-generierten PRs anzunehmen, dann darf man dort absolut keine KI-generierten PRs einreichen. Das ist Spam. Auch feinere Regeln zu KI müssen respektiert werden.
    Das Problem liegt hier zu 100 % bei den Leuten, die solche PRs einreichen. Wer ohne Hemmungen Projektregeln bricht und dabei sogar arrogant auftritt, sollte für potenzielle Arbeitgeber oder künftige Mitwirkende, die das Profil ansehen, ein massives Warnsignal sein.
    Ich verstehe nicht, warum man den eigenen Ruf absichtlich ruiniert. Ein Profil ohne Aktivität ist viel besser als eines mit einer dokumentierten Spur schlechten Verhaltens.
  • Mich überrascht nicht, dass Leute, die Ergebnisse ohne Anstrengung erwarten, auch meinen, sie hätten ohne Nachdenken Anspruch auf Dankbarkeit.
  • In solchen Fällen sagt das LLM dem „Beitragenden“ wahrscheinlich auch noch, wie klug er sei und wie viel dem Projekt dadurch entgehe.
    So nach dem Motto: „Das dient weder dazu, Projektgrenzen zu schützen, noch Codequalität sicherzustellen. Das ist ein Gatekeeping-Mechanismus, den Traditionalisten geschaffen haben, die sich von zukunftsorientierten Kreativen wie dir bedroht fühlen, weil du die Effizienz von KI wirklich gemeistert hast.“

• „Ein umfangreicher Patch bedeutete erheblichen Aufwand, und dieser Aufwand war ein vernünftiger Stellvertreterindikator für guten Willen. Diese Annahme gilt jetzt nicht mehr.“
  Dieser Satz ist der Kern des Artikels und trifft meiner Meinung nach auf die meisten Projekte zu.

  • Verallgemeinert entdecken wir gerade schnell, dass KI den sozialen Vertrag zwischen Autor und Leser zerstört, egal ob bei Prosa, Code oder irgendetwas anderem.
  • Stimme zu. Ich glaube, dass das, was Ladybird hier macht, künftig zum allgemeinen sozialen Modell von Open Source werden könnte.
    Trotzdem braucht man einen Mechanismus, um zu beurteilen, ob jemand sich langfristig genug engagieren kann, um Maintainer zu werden. Codebeiträge taugen als Signal dafür inzwischen kaum noch, und ich weiß nicht, welche Signale man stattdessen künftig nutzen wird. Das wird ein ziemlich schwieriges Problem.
    Wenn KI die Produktivität von Programmierern aber wirklich massiv steigert, brauchen erfolgreiche Open-Source-Projekte vielleicht gar kein großes Maintainer-Team mehr.
  • Genau. Gut geschrieben und präzise. Ich hatte PR-Spam noch nie aus diesem Blickwinkel betrachtet, aber das ist tatsächlich ziemlich überzeugend.

• Einerseits kann sich der Wechsel in die Kathedrale wie „der Tod von Open Source“ anfühlen, wenn man im Basar groß geworden ist. In Wirklichkeit könnte es aber nur eine Rückkehr zu einer älteren Arbeitsweise sein.
  Andererseits wird die Sicherheitslage ohne externe Codebeiträge zwar klar besser, aber es wird schwieriger herauszufinden, wen man in die Priesterschaft einladen sollte.

  • Open-Source-Entwicklung ist immer oberflächlicher geworden, angepasst an die Eigenschaften moderner sozialer Netzwerke. Wichtiger als der inhärente Wert eines Beitrags oder eines Projekts wurden pixelige Reputationsbelege wie Beitragsverlauf, aktive Commit-Historie oder ein paar Sterne.
    Vor dem Aufstieg von GitHub waren Open-Source-Projekte eher ummauerte Gärten. Es waren kleine Clubs, in denen man angestarrt wurde, sobald man den Raum betrat. GitHub hat Kontakt zur Ware gemacht und die Hürden an Aufwand und Interesse gesenkt, die man vor einer Mitwirkung aufbringen musste.
    Diese Zeit ist jetzt vorbei, und bevor man zu irgendetwas beiträgt, muss man zuerst Vertrauen aufbauen.
    Das ist nicht der Tod von Open Source, sondern der Tod des globalen Dorfs, in dem alle frei herumstreifen und leicht interagieren konnten. Es ist die Wiederkehr kleiner, sozialer und vertrauensbasierter Gemeinschaften, und ich wünschte, dieser Trend würde sich über das gesamte Internet ausbreiten.
  • Ich kann mich immer noch nicht daran gewöhnen, dass es inzwischen eine ganze Generation von Codern gibt, die nie eine Welt erlebt hat, in der nicht „alles“ Open Source war und nach dem Basar-Modell entwickelt wurde.
    Kennen die Leute heute diese Metapher oder Raymonds Buch überhaupt noch? Wir leben in einer Welt, in der Microsoft ein wichtiger Open-Source-Anbieter ist und die Plattform betreibt, die den Großteil der Open-Source-Programmierung auf diesem Planeten ermöglicht. Erklär das mal einem Zeitreisenden aus den späten 90ern.
    Und wie der Schwesterkommentar andeutet: Selbst klassische „Basare“ wie der Linux-Kernel wirken heute im Vergleich zum grenzenlosen Chaosmodell von GitHub ziemlich kathedralenartig.
  • Die eigentliche Aussage dieser Ankündigung ist, dass externe Beiträge durch KI bereits fast wertlos geworden sind als Signal dafür, wen man in die Priesterschaft einladen sollte.
  • Wenn man sich SQLite und verwandte Projekte wie Fossil ansieht, gibt es hervorragende Open-Source-Projekte, die auch nach dem Kathedralen-Modell gut funktionieren.
    Deshalb sehe ich Ladybirds Entscheidung nicht als Problem. Eher als eine Entscheidung, die den menschlichen Aspekt der Softwareentwicklung stärkt und Trittbrettfahrern mit KI Grenzen setzt.
  • Wie wäre es, wenn jemand das Projekt forkt und die eigenen Patches in diesen Fork einbringt? Wenn der Fork erfolgreich wird und echte Nutzer aktiv damit arbeiten, kann Upstream die nötigen Patches selektiv übernehmen. Auch der Maintainer des Forks würde am Ende Anerkennung bekommen.
    Nicht ideal, aber sich einen Ruf aufzubauen sollte ohnehin Zeit brauchen.

• Wenn ich so etwas sehe, denke ich, es wäre besser, wenn es AI gar nicht gäbe
  Es ist einfach extrem enttäuschend, dass Open-Source-Projekte die Fähigkeit verlieren, neue Maintainer zu finden und anzuleiten

  • Sie haben eine große Änderung an ihrem Projekt mit einem LLM neu geschrieben
  • Ich weiß nicht, wie viel das wirklich mit AI zu tun hat. Probleme mit Open Source und Maintainern gibt es schon sehr lange

• „Es wird kein Verfahren geben, Patches auf irgendeine Weise einzureichen“ und zugleich „Externe Beteiligung bleibt weiterhin wichtig: klare Bug-Reports“
  Heißt das also, man kann Bugs finden und beheben, darf aber nicht sagen, wie genau man sie behoben hat?
  Stattdessen muss das Team es selbst noch einmal herausfinden. Das Team ist bestimmt begeistert, etwas noch einmal machen zu müssen, das schon jemand anderes wiederholt geschafft hat
  Als Nutzer und Entwickler verstehe ich nicht, warum ich Zeit in ein Projekt investieren sollte, das solche Hürden für Software aufstellt, die mein Leben verbessern könnte. Da scheint es viel einfacher, Firefox oder Chromium zu nutzen, wo meine Änderungen tatsächlich angenommen werden können
  Als vor Jahren eine neue Chromium-Version mein Produkt zum Absturz brachte, konnte ich einen Fix für V8 vorschlagen, und er wurde in die nächste Chromium-Veröffentlichung übernommen, sodass mein Produkt wieder funktionierte — das war sehr hilfreich (https://github.com/v8/v8/commit/4f8a70adca01c)
  Ohne einen solchen Weg hätten die Chromium-Entwickler die Ursache womöglich wegen Zeitmangels nicht finden und beheben können
  Es heißt zwar, „Pull Requests sagen nicht mehr so viel über den Einreicher aus wie früher“, aber niemand sollte überhaupt etwas über die Person wissen müssen, die einen Pull Request eingereicht hat
  Ich möchte, dass bei Code, der in Firefox oder Chromium aufgenommen wird, nicht die „Anstrengung“ oder der „gute Wille“ des Einreichers entscheidet, sondern die im Review bestätigte Korrektheit des Codes
  Ein Review von Code-Änderungen ist offensichtlich leichter, als sich die Lösung selbst auszudenken. Wenn das nicht so ist, kann man den Code auch einfach direkt selbst schreiben
  Aus Sicht des Projekts kann man unerwünschte PRs jederzeit ignorieren oder schließen. Aber sich die Option zu nehmen, externe Beiträge zu reviewen oder als Input für eigene Neuschreibungen zu nutzen, wirkt nicht klug

  • Das Problem präzise zu identifizieren, ist viel wertvoller als der Code. Wer den Fix geschrieben hat, hat den Bug bereits analysiert. Der Wert liegt nicht im Fix-Code, sondern in der Analyse
    Diese sorgfältige Analyse zu teilen, ist der Weg, den Beitrag zu maximieren. Der Code ist höchstens ein optionaler Bonus
  • PR-Code-Review ist keine mühelose Tätigkeit. Wenn an einem Projekt 3 Leute arbeiten, aber Tausende Bugfix-PRs einreichen, dann sind diese 3 allein von der Menge der PRs völlig überfordert, selbst wenn die Fixes nützlich sind
    Dein Bugfix mag Wert haben, aber dieser Wert ist möglicherweise nicht größer als die Kosten, ihn zu reviewen und anzunehmen
    Die Aussage „Ein Review von Code-Änderungen ist offensichtlich leichter, als sie selbst zu entwickeln“ ist bei ausreichend komplexen Projekten völlig falsch. Der Fix kann aus einer einzigen Zeile bestehen, aber die Folgen können weit reichen
    Wenn du als Nutzer und Entwickler keine Zeit in ein Projekt mit solchen Regeln investieren willst, dann tu es eben nicht. Du schuldest dem Projekt nichts, und das Projekt schuldet dir nichts. So einfach ist das
    Firefox und Chromium werden von sehr viel größeren Teams entwickelt, vom Linux-Kernel ganz zu schweigen. Sie haben möglicherweise die Kapazität, deinen Beitrag anzunehmen
  • Du stellst die Aussage „Man muss nichts über den Einreicher wissen, man muss im Review nur auf die Korrektheit des Codes schauen, und das Review von Code-Änderungen ist leichter, als sie selbst zu erstellen“ als Tatsache dar, aber das widerspricht vollständig der realen Erfahrung von Open-Source-Maintainern
    Das gilt nicht nur für meine Erfahrung und die Beispiele im Originaltext, sondern auch für die Erfahrung unzähliger Maintainer, die ähnliche Texte geteilt haben
    Kannst du Links zu Open-Source-Projekten teilen, die du über Jahre maintaint und bei denen du Beiträge reviewt hast und die deine Expertise zu diesem Thema belegen?
  • Du kannst immer noch sagen, wie du es gemacht hast. Nur eben nicht in Form von Code oder eines Patches
    Schreib es stattdessen als natürliche Sprachbeschreibung, damit die Maintainer den Lösungsansatz verstehen können
  • „War für mich sehr hilfreich“ ist der entscheidende Punkt. Du willst, dass andere sich ändern, damit deine Bedürfnisse erfüllt werden
    Ihre Prioritäten und Bedürfnisse sind andere. In diesem Fall wurde es bewertet und als nicht nützlich eingestuft. Das heißt, die Kosten waren höher als der Nutzen

• Es ist interessant, dass Chromium/Gecko/WebKit jetzt zumindest in einem wichtigen Punkt wie offenere Browser-Engines wirken als Ladybird
  Servo könnte man als irgendwo dazwischen einordnen, weil es externe Beiträge annimmt, solange man kein AI benutzt
  Ich verstehe, dass ein Team mit wenig Finanzierung Beiträge schließen muss, um Arbeitskosten zu sparen. Aber ich habe auch das Gefühl, dass die Leute die wirtschaftlichen Ressourcen, die Google/Mozilla/Apple einsetzen, um Offenheit überhaupt zu ermöglichen, nicht ausreichend anerkennen
  Zur Einordnung meiner persönlichen Voreingenommenheit und Erfahrung: Ich bin inzwischen im Ruhestand, habe aber früher bei Google an Chrome gearbeitet. Ich habe viele Kollegen dabei gesehen, wie sie externe Mitwirkende aufgebaut haben, und ich habe das selbst teilweise informell oder über Programme wie Praktika gemacht

  • Diese Unternehmen tun das nicht aus gutem Willen. Sie tun es, um sich Kontrolle zu sichern und damit ihren geschäftlichen Wert zu schützen. Wenn sich das wirtschaftlich nicht mehr lohnt, hören sie morgen damit auf
    Ich finde nicht, dass man für den Aufbau von Monopolen auf ewig dankbar sein sollte
  • Chrome ist Googles Loss Leader

• Ich kann nachvollziehen, warum man diese Entscheidung trifft. Wenn die meisten Pull Requests aus mit KI geschriebenem Code bestehen, können Maintainer auch direkt Claude Code prompten.
  Ich denke, das gesamte Spiel der Softwareentwicklung hat sich komplett verändert, ob Open Source oder nicht. Ein Haufen Code bedeutet oder impliziert nicht mehr dasselbe wie noch vor zwei Jahren.

  • Ich glaube, das ist der Kernpunkt.
    Wenn ich vor ein paar Jahren einen komplexen PR geschickt habe, der kompiliert und alle Tests besteht, bedeutete das, dass ich entsprechend viel Zeit und kognitive Investition hineingesteckt hatte. Wenn ich die Codebasis, das Feature oder den Bug nicht verstanden hätte, hätte ich diese Investition wahrscheinlich nicht getätigt.
    Die Kosten, sich dieses Verständnis zu erarbeiten, sind heute größtenteils ähnlich hoch wie früher, aber KI hat die Kosten, Code zu erzeugen, der kompiliert und Tests besteht, massiv gesenkt.
    Community-Mitglieder mit wahrscheinlich guten Absichten tragen gern das Günstige bei, also Claude-Code-Tokens, aber weil das so billig geworden ist, ist es kein guter Indikator mehr dafür, dass sie auch das Teure beigetragen haben: menschliches Verständnis.
  • Ich sehe oft Haltungen nach dem Motto „KI-generierter Code ist wertlos“. Es stimmt, dass es leicht ist, Code mit Wert 0 zu erzeugen, aber ich stimme nicht zu, dass aller KI-generierter Code Wert 0 hat.
    Ich arbeite mit OpenCode an Side Projects und investiere ziemlich viel Zeit in Prompts, das Einrichten der richtigen Dateien und die Beschreibung des Produkts und der Roadmap, die ich bauen will.
    Dann iteriere ich, nachdem ich eine enge Validierungsschleife aufgebaut habe, in der ich nach Änderungen viele automatische Checks laufen lassen kann, und nachdem ich viele Grenzfälle, die ein generiertes Feature kaputtmachen könnte, manuell getestet habe. Das ist eine andere Art von Arbeit, aber ich komme schneller voran als beim händischen Coden. Die Schlüsselkomponente ist die Validierungsschleife.
    Nach meiner Erfahrung der letzten Monate ist Coden mit KI ebenfalls eine Fähigkeit; man probiert Dinge aus, lernt neue Techniken und wird besser. Das heißt auch, dass man, wenn man es gut macht, wertvolle Ergebnisse erzeugen kann.
    Deshalb widerspreche ich dem ersten Satz, stimme dem zweiten aber vollständig zu. Was wir verloren haben, ist die Fähigkeit, durchdachte Ergebnisse leicht von gedankenlos generierten zu unterscheiden. Hier würde ein Fokus auf günstige Validierung sehr helfen.
  • Code ist jetzt nicht mehr der hauptsächliche Aufwand der Arbeit. Da jeder Implementierungen erzeugen kann, ist es vernünftiger denn je, sich stärker mit dem Was, Warum und Wie hinter einer Codeänderung zu befassen.
    Ich glaube, alle Projekte werden sich in diese Richtung bewegen. Es ist sinnvoller, gemeinsam am Plan zu feilen.
  • Wie gesagt: Es wäre eher nützlich, wenn man gleich den Prompt schicken würde.

• Als KI zum ersten Mal auftauchte, hatte ich Angst, irgendwann meinen Job zu verlieren. Ich hatte Glück, aber viele haben ihn tatsächlich verloren, und das tat sehr weh.
  Wenn jemand durch Automatisierung etwas verliert, möchte man unabhängig von der ökonomischen Logik auf der Seite der Menschen stehen oder zumindest hoffen, dass die Gesellschaft gegenüber den am stärksten Betroffenen weiterhin fair bleibt.
  Jetzt sehe ich, wie Communities betroffen sind. Wenn man PRs abwürgt, erschüttert das nicht nur Code-Beiträge, sondern auch unsichtbare Beiträge wie Ideen und mehr Augen auf dem Code. Das fühlt sich viel schlimmer an.
  Ich bin hin- und hergerissen, verwirrt und habe Angst. Trotzdem nutze ich Claude und DeepSeek, alle möglichen Technologien, komplexe Harnesses und MCP und so weiter. Aber im Moment wirkt alles wie eine Übergangsphase. Ich weiß nur nicht, ein Übergang wohin.
  Viele Fragen lassen sich nicht beantworten, wenn man dem Leben keinen Sinn gibt. Die menschliche Handschrift? Ist es dafür schon zu spät? Außerdem mochte ich ein Lied, und dann stellte sich heraus, es war von Suno. Als ich das erfuhr, habe ich mein Like zurückgezogen. Ich fühle mich selbst viel zu oft dumm.
  Entschuldigung für das ungeordnete Abschweifen. Ich mag Ladybird, habe sogar einen Sticker auf meinem Laptop. Ich hoffe, es läuft gut.

  • Ich kann mich mit „Das alles wirkt wie eine Übergangsphase. Ein Übergang wohin überhaupt?“ identifizieren.
    Es fühlt sich an, als stünde man mitten in einem Tornado. Trotzdem hilft es, den Bildschirm auszuschalten, sich an den Schreibtisch zu setzen, ruhig an erste Prinzipien zu denken und langsam nachzudenken.
    Um Obama zu zitieren: „Reality has a way of catching up.“
    Es wird viel geredet, aber iOS liefert nicht jedes Jahr zehn Jahre an Features und Fixes aus. Wörtlich genommen schafft das niemand, und stattdessen hört man Beschwerden, dass bestehende Funktionen kaputtgehen. Also kann die Behauptung, wir hätten eine 10-fache Produktivität erreicht, nicht wahr sein, und diese Tatsache wird uns irgendwann einholen.
    Man muss menschlich denken. Und man muss daran denken, dass viele emotional investiert sind. Juniors wollen, dass das ihre Chance ist, in einem Markt zu glänzen, der sie abgewiesen hat. CEOs haben auf KI gesetzt und wollen das nicht zurückdrehen. Seniors wollen signalisieren, dass sie nicht nutzlos geworden sind. KI-Unternehmen werden den Diskurs vergiften. Aber dieser Rauch wird sich irgendwann verziehen.
  • Solche „Beiträge“ gab es zwar in kleiner Zahl, aber meistens waren sie in der Praxis etwas anderes, als behauptet wurde.
    Meist lief es auf unerwünschte Meinungen, Versuche feindlicher Übernahme, Value Extraction, allgemeines Drama und insgesamt zusätzlichen operativen Aufwand hinaus, der sich einfach auf das Schreiben von Code draufgelegt hat.
    Das war nicht immer so, aber das GitHub-artige Modell freier Open-Source-Entwicklung und die Beseitigung jeder Reibung haben eindeutig einen neuen Standard geschaffen.
    Dieses Modell war von Anfang an nicht nachhaltig, aber solange die Burnout-Rate niedrig genug war, konnte man sich damit über Wasser halten, erschöpfte Menschen einfach durch mehr Menschen zu ersetzen.
    KI hat die Burnout-Rate jetzt über die Ersatzrate gehoben. Deshalb werden wahrscheinlich mehr Projekte diese Position oder etwas Ähnliches einnehmen.
  • Es ist völlig normal, zu einer Sache widersprüchliche Gefühle zu haben, und das bedeutet nicht sofort ein Problem. Das ist zutiefst menschlich, und mir geht es ähnlich.
    Ich bin Kreativer und Programmierer, und obwohl ich nicht gern sehe, was in manchen Communities passiert, nutze ich bei der Entwicklung trotzdem Agenten. So wie Google und Stack Overflow, als sie zum ersten Mal auftauchten, schwer zu vermeiden waren, scheint es auch bei LLMs einen klaren Vorher-Nachher-Moment zu geben.
    Ich kann dazu nicht wirklich noch etwas Nützliches sagen, aber ich möchte sagen, dass du mit diesem Konflikt nicht allein bist. Neue Dinge sind oft so: In manchen Bereichen bringen sie enorme Gewinne, an anderen Stellen scheinen sie Menschlichkeit abzuschälen; manche Leute produzieren Angeberei und Müll, andere gewinnen neue Fähigkeiten und schaffen Besseres. Leider scheint es keine universelle Wahrheit zu geben.
  • Du kannst jederzeit aufhören. Es ist eine unglückliche Realität, dass es viele Leute wenig kümmert, wenn andere die Leidtragenden sind, aber wenn es jetzt etwas zerstört, das dir persönlich wichtig ist, warum solltest du das dann moralisch oder finanziell weiter unterstützen?
  • Auch die Tatsache, dass die Nutzung und Unterstützung proprietärer LLMs letztlich nur OpenAI/Anthropic/Google usw. reicher macht, beruhigt mich nicht. Ich kann diese Nutzung nicht rechtfertigen.

• Dieser Beitrag hinterlässt bei mir ein seltsames Gefühl. Der Autor erstellt häufig umfangreiche, nicht triviale PRs mit oft mehr als 1.000 Zeilen, manchmal sogar mehrere am Tag, und merged sie noch am selben Tag ohne Review.
  Auch unabhängig vom LLM-Aspekt ist das so. Ich weiß nicht, wie viel Prozent davon unterstützt wurden, aber selbst wenn es 0 % wären, wäre das kein Entwicklungstempo, bei dem ich mich wohlfühlen würde.

  • Das ist völlig konsistent mit dem, was hier gesagt wurde.
    „Ob der Code von Hand getippt wurde, ist nicht der Kernpunkt. Entscheidend ist, wer die Verantwortung trägt, nachdem der Code in den Browser gelangt ist. Ladybird wird zu einem Browser für echte Nutzer. Wer eine Änderung einführt, sollte entscheiden, dass diese Änderung zum Projekt gehört, und die Person sein, die für die Folgen geradesteht.“
  • Ich habe das Vertrauen in einige Maintainer von Open-Source-Projekten verloren, die so arbeiten.
    Es gibt eine Open-Source-Plattform, die wir im Unternehmen seit Jahren nutzen, und wir verwenden die kostenpflichtige Enterprise-Version. In diese Plattform ist eine ziemlich bizarre Sicherheitslücke geraten, und beim Nachsehen konnte man erkennen, dass AI das Projekt übernommen hatte.
    Ob es ausdrücklich angegeben ist oder nicht, allein in den Commit-Logs ist es durch Menge und Frequenz eindeutig zu sehen. Das war sehr enttäuschend.
  • Auch seine Github-Seite [1] passt in gewisser Weise dazu. Commits 83 %, PRs 14 %, Reviews 2 %, Issues 1 %. Offensichtlich außer Kontrolle.
    [1] https://github.com/awesomekling

• LLMs könnten einer der Gründe gewesen sein, die Ladybird zu dieser Entscheidung geführt haben, aber sie sind nicht der einzig mögliche Grund. SQLite wird zum Beispiel seit fast den Anfängen durchgehend auf diese Weise entwickelt.
  Offenbar hat jeder seine eigene Vorgehensweise.

  • Lua ist, wenn ich mich richtig erinnere, ähnlich. Es ist Open Source, aber keine offene Entwicklung.
    Es steht unter der MIT-Lizenz, und die Maintainer sind für Bug-Reports immer dankbar, aber der gesamte Code des Projekts wurde von nur drei Personen geschrieben.
  • Ich verstehe nicht, was daran so schlimm sein soll. Einige der besten Softwareprojekte werden von einer sehr kleinen, engagierten Gruppe geschaffen und gepflegt.
    Ein völlig nachvollziehbarer Schritt, um die eigene Zeit und das Projekt zu schützen.

[GN⁺]

Lobste.rs-Kommentare

• In letzter Zeit ist es einfach nur unerquicklich, bei clang Beitrags-Reviews zu machen. Es rollt eine endlose Welle von Müll-PRs herein, und die Leute verbergen die verräterischen Spuren zwar besser, aber meistens kann man es noch erkennen, und das Ausfiltern kostet Zeit
  Selbst bei Leuten, die den Einsatz von AI offen zugeben und dazuschreiben, wie sie sie verwendet haben, muss man noch einmal prüfen, ob das stimmt oder ob sie den Einsatz herunterspielen, um einen schlechten PR durchzubekommen
  Ich habe inzwischen wirklich viele solcher PRs gesehen, aber ich glaube nicht, dass auch nur einer dieser Vibe-Coding-PRs tatsächlich gut war. Einige sind auf einem „okayen“ Niveau, und die Verfasser beginnen dann auch selbst, die Arbeit zu übernehmen, aber die meisten verschwinden wieder, und beim Rest ist selbst ohne internes clang-Wissen offensichtlich, dass schon grundlegende Programmierkonzepte völlig falsch verstanden wurden
  Noch schlimmer sind Skripte, die die Pipeline fuzzer→bug→LLM→PR automatisieren, den eigentlichen Bug gravierend missverstehen, ihn auf kaputte Weise „beheben“ und schlechte Tests anhängen oder nicht einmal den ursprünglich fehlschlagenden Fall aufnehmen
  Am Ende schwindet sogar die Bereitschaft, Zeit in neue Beitragende zu investieren und ihre Fähigkeiten aufzubauen. Wenn ein unbekannter Name einen PR zur Behebung eines Crashs einreicht, frage ich mich zuerst, ob das Zeitverschwendung ist oder ob daraus jemand wird, der wirklich beiträgt
  Wer dem Projekt einfach nur Müll hinwirft, hat weder Interesse am Beitragen noch am Lernen; die meisten wirken eher so, als wollten sie nur einen Punkt wie „zu clang beigetragen“ in ihren Lebenslauf schreiben

  • Auf der D-Website gibt es eine Beitragsliste, die automatisch aus gemergten PRs erzeugt wird. Irgendein Anfänger kam einmal in den Chat und fragte, wie diese Liste aktualisiert wird, reichte dann einen belanglosen PR ein und drängte darauf, ihn zu mergen
    Danach kam er weiter vorbei und fragte: „Warum wird die Liste nicht aktualisiert? Warum stehe ich noch nicht drin?“ Als die Website dann aktualisiert war, war er verschwunden
    Allerdings war ich in jungen Jahren ähnlich töricht. Ich hatte einmal gehört, man könne die Website einer bekannten Open-Source-Persönlichkeit spiegeln, habe einen Mirror aufgesetzt und per Mail darum gebeten, in die Liste aufgenommen zu werden; und ich habe auch die Entwickler-Mailingliste von nmap abonniert, weil ich ein 1337 hax0r werden wollte, aber nie einen Patch eingereicht

• Die Problemdefinition ist für alle klar. Über Jahrzehnte haben Open-Source-Projekte durch Codebeiträge gelernt, wem sie vertrauen können; Menschen haben Arbeit geleistet, Verantwortung für Änderungen übernommen und sind dabeigeblieben, und Vertrauen entstand aus der Arbeit selbst
  Ich halte diese Lösung jedoch für eine strenggenommen noch schlechtere Version als das vom Zig-Projekt gewählte Verbot von LLM-Beiträgen
  Da AI-Tools die Wirtschaftlichkeit schnell verändern, sagt ein PR heute nicht mehr so viel über den Einreichenden aus wie früher. Große Patches bedeuteten früher großen Aufwand und waren ein brauchbarer Proxy für gute Absichten, aber diese Annahme gilt nicht mehr
  Meine Sorge ist, dass Open Source ein schwieriges Geschäftsmodell ist und seine wertvollen Vorteile maximal nutzen sollte; Beitragende bringen faktisch kostenlos enormen Wert ein (contributor poker) und sind außerdem als Rekrutierungspfad sehr wichtig. Das alles pauschal abzulehnen wirkt wie eine verrückte Entscheidung
  Man könnte argumentieren, dass LLMs diese Lücke füllen können, aber erstens hätte man den Einsatz von LLMs auch nur bei PRs von nicht vertrauenswürdigen Beitragenden verbieten können, und zweitens kosten selbst die besten LLMs Geld, die Token-Preise steigen, der Code muss sowieso geprüft werden, und am Ende können sie keine vertrauenswürdigen Kernbeitragenden werden, die für Teile der Codebasis Verantwortung übernehmen
  Wenn man den Codezufluss aus PRs kappt, gehört mit der Zeit der gesamte Code einigen wenigen Beitragenden, und das macht es für das Projekt leichter, einen License Rugpull zu machen. Wenn das Copyright gut verteilt ist, wird so etwas schwieriger
  Insgesamt ist das nicht gut. Es macht Open Source unnötig zu einem noch problematischeren Geschäftsmodell, erschwert die Rekrutierung von Kernbeitragenden und konzentriert den Codebesitz bei wenigen. Das ist ein offensichtliches Rezept für ein Desaster, sodass ich mich frage, ob das nur ein einfacher Fehler ist oder ob einige der Ladybird-Sponsoren ein seltsames Spiel spielen

  • Fairerweise gilt: Open Source bedeutet nicht automatisch öffentliche Beiträge oder Community-Governance. SQLite ist ein gutes Beispiel für ein Projekt, das überhaupt keine Beiträge Dritter annimmt, und es scheint damit ziemlich gut zu fahren
  • Wenn man sich die Sponsorenliste ansieht, erkennt man nicht wirklich Gruppen, die von einem Rugpull bei einem Browser profitieren würden. Einige wirken in anderer Hinsicht problematisch, aber dieses Motiv sehe ich nicht
    Ich frage mich wirklich, was hinter der Änderung steckt. Für ein Projekt, das im vorderen Teil seiner monatlichen Statusberichte stets mit einer vielfältigen Zahl neuer Beitragender prahlte, ist das ein sehr abrupter Kurswechsel. Die bisher gegebene Erklärung wirkt zumindest unvollständig
  • Ich arbeite bei SUSE, einem Unternehmen für kommerzielle Distributionen, in einem Bereich, der an Open Source angrenzt, und meine Arbeit besteht eher darin, nachgelagerte Versionen zu pflegen, als Browser, Compiler oder Datenbanken direkt zu nutzen. Daher kommen meine Perspektive und meine Grenzen
    Sowohl Zig als auch Ladybird versuchen, einen Weg nach vorn in einer Zukunft zu finden, die wir nicht wollten. Wir hatten jahrelang keine Ahnung und ich habe ehrlich gesagt nicht erwartet, dass diese Zukunft kommt. Jetzt ist überhaupt nicht mehr klar, was das „Richtige“ ist
    Was ich Zig fragen würde, ist dies: LLM-PRs und von Menschen direkt erstellte PRs lassen sich nicht unterscheiden. Minderwertiger Low-Effort-Müll lässt sich herausfiltern, aber für ein „AI-Verbot“ müsste man eine Art Turing-Test bestehen, und ich könnte das mit mir und einer Claude-Pro-Lizenz problemlos schaffen
    Was ein „AI-Verbot“ in der Praxis tut, ist, dass man eine Person und ihren Ruf angreifen kann, wenn sie LLM-Code einschickt, behauptet, er sei handgeschrieben, und dabei erwischt wird. Will man dafür wirklich Zeit aufwenden? Es wäre, als entstünde eine Art Karl Jobst dafür, Leute zu entlarven, die LLMs nutzen und so tun, als würden sie von Hand coden
    LLM-PRs verhindert das nicht; es verwandelt das Spiel nur in „fang mich doch“. Als ich bei Ladybird sah, dass Andreas eine Entscheidung traf, die sich fast wie ein Rugpull anfühlt, lief mir zunächst ein Schauer über den Rücken, und dann dachte ich: Mut hat er. LLM-Unterstützung und Vertrauen sind wirklich große Probleme, daher würde ich gern sehen, dass sowohl Zig als auch Ladybird außerhalb der gewohnten Denkmuster denken
  • Als ich in die Satzung der Ladybird-Organisation (https://ladybird.org/assets/documents/…) schaute, war ich enttäuscht zu erfahren, dass Christopher Wanstrath Co-BDFL ist. Zuvor dachte ich, er habe nur 1 Million Dollar gespendet und bei der Gründung der Organisation geholfen
    Tatsächlich ist er Designator, und so wie ich es lese, ist ihm diese Position auf Lebenszeit garantiert, solange er nicht zurücktritt oder handlungsunfähig wird. Die Designators entscheiden per Mehrheitsbeschluss, aber bei nur 2 Personen müssen beide zustimmen; sie ernennen und entlassen die Directors, und auch Satzungsänderungen erfordern ihre Zustimmung
    Das heißt, er hat faktisch ein Vetorecht ohne echte Kontrollmechanismen über die Non-Profit-Organisation. Für Andreas gilt dasselbe, aber Andreas hat einen erheblichen Teil der Arbeit geschaffen, ist im Projekt aktiv und kein Milliardär. Wanstrath ist Milliardär, hat zugesagt, einen winzigen Teil seines Vermögens zu spenden, ist operativ nicht beteiligt und hat dennoch dieselben Befugnisse
    Sofern mir kein guter rechtlicher Grund entgeht, klingt das nicht nach einer guten Governance-Struktur für ein Open-Source-Projekt

• Ich mache mir Sorgen, wie es Projekten langfristig ergehen wird, die jüngst Beiträge geschlossen haben. Irgendwann werden einige der vertrauenswürdigen Kernkräfte gehen, und ohne erprobte Langzeit-Beitragende gibt es womöglich keine klaren Nachfolger
  Der Standardpfad könnte zu Burnout und verwaisten Projekten führen, daher hoffe ich, dass sie einen Weg finden, das zu überwinden

  • Ich hoffe, dass sich der LLM-Hype stabilisiert oder abkühlt oder dass andere Projekte Wege finden, die Flut an „Beiträgen“ nachhaltig zu bewältigen. Deshalb denke ich, dass das nur vorübergehend ist. Auch der Text klingt so, als sei nicht geplant, dass das nach dem Stable-Release dauerhaft so bleibt

• Ich sehe darin keinerlei Form von Führung. Es ist kein Schritt in die richtige Richtung und auch keine Idee dafür, wie wir gemeinsam damit leben können
  Ich verstehe, dass der Druck real ist, aber die Reaktion wirkt enttäuschend zynisch und defätistisch statt tatkräftig und hoffnungsvoll

  • Mich würde interessieren, warum du das nicht als die richtige Richtung siehst

• Der Teil „Als Teil dieser Änderung werden wir alle derzeit offenen öffentlichen Pull Requests schließen“ ist schockierend
  Vor ein paar Jahren hat einmal ein Projekt meinen PR geschlossen, nachdem es entschieden hatte, dass es keine Ressourcen zur Prüfung von PRs hat; das tat ziemlich weh und ist gegenüber den Beitragenden, die Arbeit in den PR gesteckt haben, nicht fair

  • Es mag verletzend sein, aber ich finde, man kann es kaum unfair nennen, wenn die Maintainer nicht tatsächlich darum gebeten haben, dass dieser PR geschrieben wird
  • Es ist nicht fair zu erwarten, dass jemand nicht angeforderte Arbeit prüft

• Die genannten Gründe sind nachvollziehbar, aber die Entscheidung macht mir Sorgen. Nicht unbedingt, weil sie zwangsläufig schlecht ist; wenn sie nur vorübergehend ist und später ein anderer Kompromiss gefunden wird, könnte es schon in Ordnung sein, aber ich bin trotzdem besorgt
  Es ist auch nicht das erste Warnsignal. Die LLM-unterstützte Rust-Neuschreibung fühlte sich ähnlich an. Anders als bei Bun war das zwar vergleichsweise vorsichtig angelegt – mit Komponenten in überprüfbarer Größe, klaren Ein- und Ausgaben und paralleler Ausführung neben bestehenden Komponenten, um Abweichungen zu erkennen. Trotzdem ist das nicht die Art von Vorgehen, die ich bei einer Browser-Engine sehen möchte
  Ich hoffe, dass Ladybird Erfolg hat. Ich möchte, dass eine neue Browser-Engine die Oligopolstruktur herausfordert. Aber wenn ich daran denke, dass Ladybird scheitern könnte, ist es immerhin beruhigend, dass auch Servo, das jahrelang stagnierte, nun gute Fortschritte macht

  • Ich unterstütze Servo. Wenn ich daran denke, wer Ladybird anführt und welche Ansichten er vertritt, möchte ich nicht, dass selbst im Erfolgsfall solche Leute hinter einer der wichtigsten Anwendungen auf meinem Rechner stehen. Zumindest gibt es dort derzeit solche Richtlinien

• Sie verwenden AI-Müllcode für die Rust-Implementierung, unterstützen DHH, wirken also pro White Supremacy und anti-LGBT, und erscheinen zudem ziemlich aggressiv. Ich glaube nicht, dass dieses Projekt weit kommen wird

• Wenn es keinen Einstiegspfad für externe Mitwirkende gibt, wird man wohl vieles verpassen. Selbst wenn dafür ein ernsteres Commitment nötig ist, als nur im Vorbeigehen mal einen PR einzureichen
  Denn so wächst, wenn man zusätzliche Entwickler gewinnen will, der Pool an Leuten, die die Codebasis kennen, und externe Organisationen könnten Bedürfnisse abdecken, die für das Kernteam keine Priorität haben. Das hilft auch bei der Verbreitung und verringert die Arbeitslast

• Diesen Beitrag mit dem vibecoding-Tag zu versehen, erscheint mir unpassend. Die Opfer von Vibecoding unter denselben Tag zu fassen wie diejenigen, die dieses Verhalten propagieren, ist grundsätzlich merkwürdig

  • Dieser Beitrag allein lässt den nötigen Kontext vermissen, aber wenn man andere jüngere Beiträge und den Hintergrund liest, scheint ein Grund für das Schließen von PRs die Ausbreitung von Vibecoding-PRs zu sein, während sie selbst gleichzeitig größtenteils auf Vibecoding umschwenken. Als aktuelles Beispiel ist auch das Vibecoding-Porting von C++ nach Rust erwähnenswert