Hat Claude die Zahl der Bugs in rsync erhöht?

• Claude-unterstützte Releases gibt es nur zwei, rsync v3.4.2 und v3.4.3, und es gibt keine Hinweise darauf, dass sie gemessen an schwerengewichteten Bugs pro 10 Commits ungewöhnlich viel fehlerhafter sind als frühere Releases
• sev/10c ist die zentrale Kennzahl: Dabei werden Bug-Schweregrade auf 0 bis 1 normalisiert, pro Release aufsummiert, durch die Zahl der Commits geteilt und auf 10 Commits hochgerechnet
• v3.4.2 hatte 50 Commits, 9 Claude-Commits, 0 Bugs und 0,00 sev/10c; v3.4.3 hatte 34 Commits, 28 Claude-Commits, 17 Bugs und 3,29 sev/10c und liegt beidseits des IQR, ohne dass eines von beiden ein Ausreißer wäre
• Der p-Wert des exakten Permutationstests beträgt 46 %, der p-Wert von Fishers exaktem Test 74 %, bei einer Odds Ratio von 1,06; es gibt also kaum ein Signal dafür, dass Claude-Releases schlechter sind als zwei zufällig gewählte Releases oder häufiger über dem Median liegen
• v3.4.1 war ein Release vor der Einführung von Claude, hatte aber mit 59 Bugs, 9 Commits und 39,39 sev/10c den schlechtesten Wert im gesamten Datensatz; der Kern der rsync-Kontroverse liegt darin, eine einzelne Regression ohne historische Verteilung mit Claude zu verknüpfen

---

Hintergrund und Fragestellung

• Die rsync-Kontroverse Ende Mai 2026 begann mit einem Mastodon-Post, der die Regression in v3.4.3 mit Claude-Commits in diesem Release verknüpfte, und verbreitete sich über Hacker News und das GitHub-Issue "Please Do Not Vibe Fuck Up This Software"; dort sammelten sich mehr als 300 Kommentare
• Die wiederholte Kernthese lautete, dass Claude-unterstützte Entwicklung Bugs in ein zuvor stabiles Tool eingebracht habe; die Datenfrage ist, ob Claude-unterstützte Releases im Vergleich zu historischen Releases ungewöhnlich viele Bugs haben
• Auf Lobsters wurde gefordert, die Zahl der Regressionen pro Release in einem Zeitdiagramm zu betrachten; der Fokus der Analyse ist die einzelne Frage: „Haben Claude-unterstützte Releases ungewöhnlich viele Bugs?“

Datenumfang und Reproduzierbarkeit

• Die Daten umfassen 36 Releases aus RsyncProject/rsync von v2.4.6 bis v3.4.3, für die Bug-Daten vorliegen; Releases mit Claude-Commits gibt es nur zwei: v3.4.2 und v3.4.3
• Auswahl von Kennzahlen, Methodik und Datenquellen erfolgte manuell und unter Einbezug des Rats einer Ehepartnerin mit Masterabschluss in Statistik
• Datenerhebung, Laden in DuckDB, View-Erstellung und Skripte für die statistische Analyse wurden von GLM 5.1 erstellt, aber alle Zahlen, Statistiken, Karten und Grafiken wurden per automatischer Vorlage aus dem Python-Skript eingefügt, das die statistische Analyse ausgeführt hat
• Das Reproduktions-Repository alexispurslane/rsync-analysis kann die komplette Pipeline von Anfang bis Ende ausführen

Kennzahl und Zuordnung der Bugs

• Die zentrale Kennzahl ist die nach Schweregrad gewichtete Zahl der Bugs pro 10 Commits, sev/10c, mit der Formel sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Die Commits werden nach dem committer date des Basis-Branches sortiert; der Bereich eines Releases reicht vom vorherigen Tag bis zum jeweiligen Tag, wobei pre- und rc-Tags an den Grenzen ausgeschlossen und in das finale Release aufgenommen werden
• Quellen der Bugs sind GitHub-Issues, rsync Bugzilla und die rsync-Mailingliste; Bugs aus GitHub-Issues und der Mailingliste werden dem neuesten Release zugeordnet, das unmittelbar vor dem Meldezeitpunkt ausgeliefert wurde
• Bei Bugzilla-Einträgen benennt das Feld „Version“ explizit das Release, in dem der Bug gemeldet wurde; entsprechend werden sie diesem Release zugeordnet
• Der Grund für die Analyse auf Release-Ebene ist, dass die Kritik selbst die Form hat, „gesamte Releases mit Claude-Commits wurden fehlerhafter“, und die meisten Bugs nicht explizit angeben, aus welchem Commit sie genau stammen

Bewertung der Schweregrade

• Alle Bug-Reports wurden von Qwen 3 35B auf einer Skala von 0 bis 100 bewertet; der Prompt wies dem Modell die Rolle eines Senior Reliability Engineers aus Sicht realer Auswirkungen auf Nutzer zu
• 90 bis 100 Punkte stehen für stille Datenkorruption, Datenverlust, Remote Code Execution oder Sicherheitslücken mit unbefugtem Zugriff; 70 bis 89 für Abstürze, Hänger, Backup-Fehler oder Build-Fehler; 50 bis 69 für funktionale Regressionen mit möglichem Workaround
• Bei Bugzilla und der Mailingliste lagen nur Titel ohne Text vor, daher bewertete das Modell nur anhand der Titel; bei unzureichender Information wurde es angewiesen, eher in den mittleren Bereich von 40 bis 60 Punkten zu tendieren
• Die Ausgabe ließ über structured output per JSON-Schema nur ganzzahlige Schweregrade zu; temperature war auf 0 fixiert, damit derselbe Input stets denselben Score ergibt
• Issues mit 0 Punkten, etwa Funktionswünsche, Spam, nichttechnische AI-bezogene Beschwerden oder leere Einreichungen, wurden aus der Basiszahl der Bugs ausgeschlossen

Statistische Ergebnisse der Claude-Releases

• v3.4.2 hatte bei 50 Commits 9 Claude-Commits, 0 tatsächliche Bugs, 0,00 sev/10c und liegt im 0. Perzentil
• v3.4.3 hatte bei 34 Commits 28 Claude-Commits, 17 Bugs, 3,29 sev/10c und liegt im 77. Perzentil
• Der historische IQR liegt bei 0,29 bis 2,59 sev/10c; v3.4.2 liegt knapp darunter, v3.4.3 knapp darüber, sodass beide Releases die mittlere Verteilung auf entgegengesetzten Seiten flankieren
• Der exakte Permutationstest ergibt, dass bei 272 von 595 möglichen Kombinationen aus zwei Releases der Mittelwert der Claude-Gruppe von 1,65 sev/10c erreicht oder überschritten wird; daraus folgt ein p-Wert von 46 %
• Fishers exakter Test prüfte anhand des Medians von 0,74 sev/10c, ob Claude-Releases häufiger oberhalb des Medians liegen, und ergab einen p-Wert von 74 % bei einer Odds Ratio von 1,06

Commit-Zahl und Änderungsumfang

• Claude-Releases hatten im Mittel 42 Commits, Releases ohne Claude im Mittel 185 Commits; die Wahrscheinlichkeit, dass zwei beliebige Releases ebenso viele oder mehr Commits haben, lag bei 88 %
• Gemäß GitHub Compare API lag die Zahl geänderter Zeilen bei Claude-Releases im Mittel bei 3.756, bei Releases ohne Claude im Mittel bei 696; die Wahrscheinlichkeit, dass zwei beliebige Releases ebenso viele oder mehr geänderte Zeilen haben, lag bei 5 %
• Die Zahl schwerengewichteter Bugs lag bei Claude-Releases im Mittel bei 5,6, bei Releases ohne Claude im Mittel bei 14,9; die Wahrscheinlichkeit, dass zwei beliebige Releases ebenso viele oder mehr schwerengewichtete Bugs haben, lag bei 77 %
• Insgesamt hatten Claude-Releases also deutlich mehr geänderte Zeilen, aber nicht mehr Commits und auch nicht mehr schwerengewichtete Bugs

Versionssystem und frühere Ausreißer

• Der Mittelwert der v2.x-Releases liegt bei 1,11 sev/10c, der der v3.x-Releases bei 4,23 sev/10c; v3.x zeigt also generell höhere Bugraten
• Selbst bei einem Vergleich nur innerhalb von v3.x liegen Claude-Releases im Mittelfeld oder besser; damit Claude als Ausreißer erscheint, müsste man mit einer ruhigeren früheren Ära vergleichen und Veränderungen, die schon vor Claude einsetzten, Claude zuschreiben
• Der Wald–Wolfowitz-Runs-Test ergab für 35 Releases ohne Claude 13 beobachtete Runs, einen Zufallserwartungswert von 18,5, z=-1,88 und p=0,060; nach einem 0,05-Kriterium ist das nicht stark genug, um Zufälligkeit zu verwerfen
• v3.4.1 war ein Release vor der Einführung von Claude und verzeichnete dennoch mit 59 Bugs, 9 Commits und 39,39 sev/10c die höchste Bugrate im gesamten Datensatz
• v3.4.1 war ein Hotfix-Release am Tag nach v3.4.0 und zeigte die mit Abstand höchste Bugrate aller Releases, mit mehr als einem einstelligen Abstand zum restlichen Feld, allerdings zu einer Zeit, in der man keine AI verantwortlich machen konnte

Interpretation und Grenzen

• Die mit den Daten konsistente Interpretation lautet: „Die beiden bisherigen Claude-Releases sind statistisch nicht von historischen Releases zu unterscheiden.“
• v3.4.3 liegt mit 3,29 sev/10c im 77. Perzentil und damit zwar relativ hoch, ist aber kein Extremwert; acht historische Releases erzielten höhere Werte
• Die These „Claude hat es eindeutig schlechter gemacht“ wird weder durch die Release-Verteilung noch durch den Permutationstest oder Fishers Test gestützt
• Umgekehrt folgt aus diesen Daten aber auch nicht, dass Claude-Commits künftig im Allgemeinen nichts verschlechtern; die Aussage reicht nur so weit, dass die beiden aktuellen Releases im normalen Bereich liegen
• Die Kennzahl ist ein grobes Instrument und kontrolliert weder für Commit-Komplexität noch für die Intensität von Sicherheitsarbeit

Diskutierte Störfaktoren

• Ein Nutzer auf Hacker News vermutete, dass sicherheitsbezogene CVE-Fixes Programmierfehler offengelegt hätten, die seit 2007 im Code vorhanden waren
• Ein Nutzer auf Lobsters skizzierte die Kausalkette „LLM → mehr bekannte Sicherheitsprobleme → mehr Änderungen als üblich nötig → mehr Regressionen als üblich“
• Andrew Tridgell erklärte, dass eine Flut AI-generierter CVE-Meldungen rasche und weitreichende Änderungen an der Angriffsfläche von rsync erforderlich gemacht habe
• Berücksichtigt man auch diesen Störfaktor, liegt das Problem eher nicht bei Claude selbst, sondern bei umfangreicherer Sicherheitsarbeit und der daraus resultierenden größeren Änderungsmenge

[GN⁺]

Lobste.rs-Meinungen

• Ich denke, jeder kann für sich entscheiden, ob er FOSS-Projekte weiter nutzen will, die künftig per Vibe Coding entwickelt werden. Allerdings war ich ziemlich überrascht, wie wütend die Community reagierte, nachdem der Maintainer auf Vibe-Coding-Tools umgestiegen war, und die im Artikel gezeigten empirischen Daten helfen zumindest dabei, die Auswirkungen dieses Praxiswechsels besser einzuordnen
  Ob das Vertrauen erhalten bleibt oder durch die Übernahme dieser Coding-Methode weiter beschädigt wird, wird sich erst mit der Zeit zeigen

  • Ich frage mich, wie viele der Leute, die über diesen Wechsel verärgert waren, tatsächlich substanziell zu rsync beigetragen oder Geld dafür bezahlt haben

• Diese Analyse war genau das, was ich mir erhofft hatte, und noch mehr. Besonders gut fand ich den Teil „Alle Metriken, die Methodik und die Datenquellen habe ich selbst ausgewählt, nachdem ich sie mit meiner Frau besprochen hatte, die einen Master in Statistik von der Penn State University hat“, und dass ein echter Statistikexperte eingebunden wurde und der Text gut lesbar ist
  Es wurde zwar nur die einzelne Kennzahl „Bugs pro 10 Commits“ verwendet, aber damit wurde die Gelegenheit verpasst, mit SI-Präfixen von Dezibugs pro Commit zu sprechen

  • Stimme zu. Es ist nicht mein Text, aber ich fand es gut, dass jemand jenseits der überhitzten Pro-und-Contra-Debatte mit Daten gezeigt hat, welchen Einfluss das auf die Codequalität hatte

• Der Erfolg von Open-Source-Projekten hängt so stark von der Wahrnehmung ab, dass Leute sogar GitHub-Stars kaufen. Leider ist dieses Wahrnehmungsproblem diesmal außer Kontrolle geraten und zu einem Talking Point geworden, und irgendwelche Daten werden das kaum ändern
  Künftig wird die Aussage „Der rsync-Maintainer hat ein LLM benutzt und es kaputtgemacht“ wohl von AI-Skeptikern zusammen mit Talking Points wie „Datacenter verschwenden pro Tag 500.000 Gallonen sauberes Wasser“ oder „METR-Forschung hat gezeigt, dass LLMs die Produktivität senken“ hervorgeholt werden
  Ich will damit nicht sagen, ob ich ein AI-Skeptiker bin oder nicht, sondern nur, dass Debatten zu diesem Thema normalerweise so verlaufen

  • Warum ist das ein „Talking Point“ und nicht einfach eine Tatsache?
  • Ich weiß nicht, ob der Autor mit Daten irgendjemanden überzeugen wollte. Ich sehe den Text eher als Datenkontext für die hitzige Debatte um die Tool-Einführung bei rsync
    Es stimmt aber, dass andere nicht quantitative Faktoren im Text komplett fehlen, und vermutlich war das Absicht, weil es auf Seiten der Evangelisten wie der Skeptiker schon genug Lärm gibt

• Dass der schlimmste Release in der Geschichte von rsync noch vor der Einführung von Claude lag und 39,39 Bugs pro 10 Commits hatte, ist ein sehr wichtiger und vorhersehbarer Befund
  Wenn Prozesse wie Tests und Qualitätssicherung zwischen Nutzern und Entwicklern die Korrektheit von Software nicht sicherstellen, werden Bugs ausgeliefert, egal ob ein LLM im Spiel ist oder nicht. LLMs können diesem Prozess schaden oder auch helfen

  • Stimme zu. Ein aktueller Beitrag zu cURL scheint das Gegenbeispiel zu zeigen
    Dank starker Software-Engineering-Praktiken, die dort schon seit Jahren etabliert sind, ist der generelle Nutzen ähnlicher AI-Tools beim Finden von Bugs eher gering geworden
  • Ich habe einige Sorgen bezüglich der Zukunft von rsync. Das größte Problem ist, dass rsync im Grunde schon seit Jahren ein abgeschlossenes Projekt war, dann mit AI die bestehende Testbasis herausgerissen und durch eine Python-Test-Suite ersetzt wurde und über längere Zeit keine parallele Validierung mit den bisherigen Tests stattfand
    Nach meinem Maßstab ist das verantwortungslos. Vor allem, weil rsync in erster Linie dazu dient, wertvolle Daten zu übertragen, und die Integrität dieser Daten absolut entscheidend ist

• Ich wünschte, man würde Formulierungen wie „Wie typisch für AI-Gegner, eskalierte es am Ende zu Gewaltfantasien“ vermeiden. Das verallgemeinert nicht nur einige Leute, denen der Autor nicht zustimmt, sondern schreckt auch Leser ab, die ohnehin anderer Meinung sind, sodass gerade die Leute, die den Text am ehesten lesen sollten, ihn dann nicht lesen
  Unabhängig davon ist es mir ziemlich egal, ob diese Version mehr oder weniger Bugs hat als frühere. Was für mich zählt, ist, dass sie auf eine Weise entwickelt wird, die nicht mit meinem Verständnis von Softwareentwicklung übereinstimmt. Wenn man nicht das grundlegende Verständnis dafür hat, dass es neben Effizienz noch andere Probleme gibt, erwarte ich nicht, jemanden davon überzeugen zu können, dass diese Position vernünftig ist
  Zum Glück muss man diese Version von rsync nicht verwenden, wenn man nicht will, und ich werde eine Alternative wählen, die vor dem Einsatz von LLMs abgespalten wurde

  • Dieser Text ist so voller Wut, dass ich ihn nicht lange lesen konnte und irgendwann aufgegeben habe. Es wäre besser gewesen, wenn er fairer gewesen wäre oder zumindest so gewirkt hätte
    Auch die Wiederholung eines Mems, das schon vor langer Zeit widerlegt wurde, nämlich dass der erste Bugreport ein Issue gewesen sei, auf das sich alle gestürzt hätten, war nicht hilfreich. Den tatsächlichen ersten Bugreport gab es separat

• Ich finde den aktuellen Text ehrlich gesagt besser. Allerdings verfehlt die Passage „Diese Metrik kontrolliert weder Commit-Komplexität noch Sicherheitsrelevanz oder Fehlerschwere. Sie ist ein stumpfes Werkzeug, das einen Ein-Zeilen-Tippfehler-Fix nicht von einem CVE-Patch unterscheiden kann“ aus meiner Sicht, die eher auf der Seite LLMs sind schlecht steht, die zentrale Kritik.
  Die Kritik, die ich und andere vorbringen, ist, dass AI dazu führt, dass größere, schwerer verständliche Commits herausgepumpt werden, die die Komplexität erhöhen. Auch LLM-Befürworter sagen oft etwas Ähnliches und verschieben dann die Torpfosten von der jahrzehntelang bewährten Praxis des „PR-Lesens“ zu „das LLM sollte alles testen können“. Aber das Problem, dass Code-Komplexität technische Schulden bedeutet, verschwindet dadurch nicht.
  In diesem Fall ist die Fehlerschwere sehr hoch. Denn der Backup-Workflow wurde tatsächlich kaputtgemacht. rsync wird breit für Backups eingesetzt, und die Leute haben es als so „kampferprobtes“ Werkzeug angesehen, dass sie sich kaum vorstellen konnten, dass ein Patch-Update Backup-Skripte kaputtmachen könnte.
  Man kann sagen, dass es Zufall war, dass das LLM fehlerhafte Software erzeugt hat, oder dass der Maintainer den LLM-Workflow ändern und die Testabdeckung erhöhen müsse. Tatsächlich hat der Maintainer das auch gesagt. Aber der Kern der Wut liegt darin, dass dieses Tool dieses Vertrauen gebrochen hat.
  Tatsächlich gibt es inzwischen eine neue Art von LLM-Programmierern, die sagen, sie „lesen den Code überhaupt nicht“. Es dauere zu lange und sei komplexer zu durchschauen als Code von normalen Programmierern. Code zu lesen bedeutet, das mentale Modell anderer Menschen zu lernen, aber LLM-Tools liefern kein einziges konsistentes mentales Modell.
  Unabhängig davon sollte auch die Zugänglichkeit der Website geprüft werden. Ich sehe ziemlich gut und bin Ende 20, aber hellgrauer Text auf creme-/gelbem Hintergrund ist wirklich schmerzhaft zu lesen.

  • Die zitierte Stelle verwirrt mich. Die im Artikel verwendete Metrik scheint die Zahl der Bugs pro 10 Commits mit einer Schweregewichtung zu versehen. Widerspricht sich der Autor da selbst? Oder habe ich es falsch gelesen?
  • Für die Leute, deren Workflow kaputtgegangen ist, ist das vielleicht eine gute Gelegenheit zu lernen, was Open-Source-Software und die GPL-Lizenz sind und welche Garantien sie geben.
    Ich glaube nicht, dass die Leute diesen Bug selbst entdeckt hätten. Ich vermute, dass über 90 % der rsync-Nutzer noch eine ältere Version ohne diesen Bug verwenden. Ich gehöre auch dazu.

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    Dass das so viel Aufmerksamkeit auf sich zieht, ist auch ohne Steven Pinker nachvollziehbar, weil gerade ein großer Teil der Community in Verwirrung steckt. Dass LLMs besser programmieren als Menschen, ist nicht leicht zu akzeptieren.
    Menschen, die ihre Identität und ihr Selbstwertgefühl auf ihre Programmierfähigkeiten oder ihren Beruf gegründet haben, erleben nun eine doppelte Krise: Unsicherheit über den künftigen Lebensunterhalt bzw. Marktwert und eine Identitätskrise.
    Angst, Unsicherheit und Zweifel sind schwer zu bewältigen, und die LLM-Firmen tun ihr Bestes, diese Effekte zur Kurssteigerung ihrer Aktien zu verstärken. Wenn sich der Markt nach Oktober stark korrigiert, könnte auch dieser Verstärker schwächer werden.
    Der sehr kleine Anteil der Programmierer weltweit, der Code als Kunstform betrachtet, wird LLMs vermutlich für Training und zur Verbesserung der eigenen Fähigkeiten nutzen.

• Der Artikel zitiert viele Kommentare, die von Regressionen sprechen, aber die Analyse selbst misst keine Regressionen, sondern nur Bug-Reports. Sie ordnet Bugs der Release zu, in der sie gemeldet wurden, nicht der Release, in der sie eingeführt wurden, und misst die Schwere einer Release an der Zahl der Commits, während offensichtliche Faktoren wie Release-Dauer oder Distributions-Adoption ausgelassen werden.
  Ich verstehe nicht, wie das sinnvoll sein soll.

• Ich persönlich meide Projekte, die LLMs verwenden. Nicht weil ich dafür einen besonders sachlichen Grund hätte, sondern einfach weil es sich sehr unangenehm anfühlt, ähnlich wie wenn jemand „kek“ oder „fren“ sagt und ich das ohne großen Grund als Signal lese, lieber nicht weiter zu interagieren.
  Die Erklärungen, die derzeit dafür gegeben werden, warum Leute LLM-Nutzung nicht mögen, wirken auf mich wie nachträglich aufgesetzte Rationalisierungen. Die aktuellen Sorgen um Ethik, Qualität usw. sind berechtigt, aber selbst wenn diese Probleme gelöst würden, würden Leute wie ich mit anti-AI-Neigung das wohl nicht plötzlich okay finden.
  Deshalb meide ich Projekte mit „AGENTS.md“ oder von Claude mitverfassten Commits ohne einen konkreten Grund. Es ist einfach unangenehm, trifft nicht meinen Geschmack, und ob es Bugs gibt oder nicht, ist mir dabei egal. Ich vermute, dass andere das ähnlich empfinden.

• An den Autor gerichtet: Erstens ist Fantasie Sprache. In Wirklichkeit behauptest du also, es sei bei Sprache stehengeblieben, oder zumindest behauptest du nicht, dass es zu einer nichtsprachlichen Eskalation gekommen sei.
  Zweitens solltest du, wenn du so eine Behauptung aufstellen willst, einen Statistikexperten in deiner Nähe fragen, wie man sie stützen kann. Nur weil ein paar Leute solche Posts verfasst haben, lässt sich die Behauptung, das sei „typisch“, nicht sinnvoll belegen.
  Meine nicht statistisch untermauerte anekdotische Beobachtung ist, dass „anti-AI“-Nutzer eher traurig darüber sind, dass LLMs sich dort einmischen, wo sie nicht helfen, als dass sie darauf überwiegend aggressiv reagieren.

  • Gelegentlich sehe ich sehr ausführliche und detaillierte Texte, die einen Teil der LLM-Gegner widerlegen sollen, meist diejenigen, die emotional oder sozial auf LLMs reagieren. Solche Texte wirken auf mich sehr unaufrichtig, auch wenn ich schwer genau erklären kann, warum, und sie fühlen sich an, als würde man nach unten treten.
    Sie sind so detailliert, dass man aus einer emotionalen Perspektive kaum dagegenhalten kann, und am Ende läuft es darauf hinaus: „LLMs sind nicht das Problem, wenn man sie richtig einsetzt, sind sie ein Verstärker. Die AI-Gegner verstehen es nur nicht und haben bloß Angst, abgehängt zu werden.“
    Ich möchte die Arbeit der rsync-Maintainer auch nicht zu einer Debatte herabwürdigen, daher weiß ich nicht, wie ich einen überzeugenden Gegenpunkt formulieren könnte.
    Die Statistik hier mag aus Sicht von Open-Source-Maintenance interessant sein, aber die Schlussfolgerung ist seltsam einseitig, und es bleibt bei mir das Gefühl, dass GitHub-artiges Open Source nicht die Form ist, zu der ich beitragen möchte.
    Trotzdem finde ich es überhaupt nicht gut, dass Leute die Maintainer im rsync-Repository kollektiv bedrängt haben.
  • Es ist richtig, öffentliche Gewaltfantasien nicht okay zu nennen. Das ist nichts, worauf wir als Zivilisation hinarbeiten sollten. Aber dass der Autor das als „typisch“ bezeichnet, stört mich, weil es eine Verallgemeinerung ist.
    Was anekdotische Beobachtungen angeht, scheint dieser Comic recht zu haben. Ich sehe gern konkrete, messbare Behauptungen, auch weil ich Zahlen mag und weil es Online-Diskussionen zumindest ein wenig näher an die ideale Welt des letzten Panels bringt.

• Danke für die Analyse, aber bei der Methodik bin ich mir nicht sicher. Mich würden Kennzahlen interessieren wie die Anzahl der Bugs pro Diff-Einheit, also etwa die Zahl der geänderten Zeilen im Kerncode pro Commit — Änderungen an Tests oder Dokumentation ausgenommen —, sowie eine Analyse, wie lange es nach einem Release dauert, bis eine bestimmte Zahl von Bugs erreicht wird.
  Allerdings scheint es gut möglich, dass dieses Release viel mehr Aufmerksamkeit als andere Releases bekommen hat und deshalb mehr Bugs gemeldet wurden. Daher wirkt es schwierig, eine wirklich überzeugende Kennzahl zu entwickeln. Auch Fragen wie „Ist das gemessen an den Wochen nach dem Release typisch?“ sind womöglich nicht besonders nützlich.