Erfolgreiche Beiträge zu Open-Source-Projekten sind eine Art Währung. Git Hub fördert dies besonders auf verschiedene Weise: durch das Anzeigen von Avataren der Mitwirkenden auf Repository-Seiten, durch das Zeigen Ihrer Beiträge an Ihre Follower über den Aktivitäten-Feed und durch das Signalisieren von Beiträgen pro Tag im Aktivitätsdiagramm Ihres Profils. Potenzielle Personalverantwortliche bemerken dies oft.

Recruiter finden und screenen Kandidaten oft auf diese Weise. Wenn Sie ein Softwareentwickler (bestehender oder angehender) sind, der nach Arbeit sucht, kann das Anpassen dieser Signale oft zu Ihrem Vorteil wirken. Als Open-Source-Maintainer ist es ziemlich bemerkenswert, wie sich das Muster der externen Beiträge im letzten Jahr verändert hat.

Wir erhalten viel häufiger Pull Requests statt Issues. Wenn wir Issues erhalten, kommen sie oft mit einer KI-generierten Analyse. Wir erhalten weit mehr Sicherheits-Schwachstellenberichte als je zuvor, und oft kommen sie sogar mit KI-generierten Fix-Vorschlägen.

Ich bezweifle nicht, dass einige dieser Beiträge von Menschen kommen, die wirklich an dem interessiert sind, was wir tun, aber mein zynischer Teil glaubt, dass ein erheblicher Teil davon daher rührt, dass die Leute erkennen, dass KI genutzt werden kann, um Git Hub zum eigenen Vorteil zu manipulieren. Es ist jetzt einfach, Claude zu bitten, eine Liste interessanter Open-Source-Projekte zu generieren, dann Claude zu bitten, einige Probleme darin zu finden, und dann Claude zu bitten, einige PRs zur Behebung einzureichen. Sie müssen die Projekte nicht einmal nutzen oder sich für sie interessieren, aber Sie können leicht die Illusion für Außenstehende erzeugen, dass es Ihnen etwas bedeutet, oder dass Sie ein Problem gefunden haben, oder dass Sie sich die Zeit genommen haben, es zu beheben.

Im Internet weiß niemand, dass Sie ein Hund sind, aber mit Hilfe von LLMs können Sie mühelos Ihre menschlichen Fähigkeiten in Ihrem Git-Hub-Profil übertreiben. Kürzlich hat ein Mitwirkender, der von Ende 2018 bis vor ein paar Wochen praktisch keine Git-Hub-weiten Beiträge hatte und, soweit wir wissen, keine vorherige Interaktion mit unserem Projekt hatte, drei separate PRs eingereicht, um Rechtschreib- und Grammatikfehler in Kommentaren zu korrigieren. Claude nahm die Korrekturen vor, schrieb vermutlich die PR-Beschreibungen, signierte sogar die Commits im Namen des Benutzers und fügte dann hilfsbereit seine Co-Autorschaft in die Trailer der Commit-Nachrichten ein.

Vielleicht hat es sogar die PRs selbst geöffnet, wer weiß. Ich wäre fasziniert zu erfahren, ob der Prompt lautete, "loszugehen und Probleme zu finden" oder ob er sich aus irgendeinem Grund speziell auf Rechtschreib- und Grammatikprobleme konzentrierte. Die Änderungen waren harmlos und korrekt, aber das machte mich nicht besser damit, sie zu akzeptieren oder zu mergen.

Stattdessen konnte ich mir nicht helfen, mich zu fragen: Warum das, warum jetzt? Warum, von allen Issues, TODOs und FIXMEs in unserer Codebase, reichen sie dies ein? Und dann wurde mir klar, dass diese Beiträge überhaupt nichts mit unserem Projekt zu tun hatten. Ich schloss alle drei PRs ohne Kommentar. Vielleicht war das unvernünftig, aber ehrlich gesagt, ich bin einfach nicht interessiert daran, Leute zu ermutigen, unsere Zeit mit dieser Art von Schufterei in Anspruch zu nehmen.

Ich will keinen Präzedenzfall schaffen, indem ich PRs akzeptiere, die materiell nichts verbessern, und ich will auch nicht, dass unsere Mitwirkendenliste zu einer Belohnung dafür wird, einen Roboter zu bitten, Tippfehler zu korrigieren. Das gleiche Muster ist bei Sicherheits-Schwachstellenberichten aufgetaucht. CVEs werden traditionell ihren Meldern zugeschrieben, aber alle Berichte, die wir kürzlich erhalten haben, waren offensichtlich KI-generiert.

Sicherheitsfixes sind natürlich immer wichtig, aber wieder frage ich mich, ob dies geschieht, weil den Leuten die Fixes wichtig sind oder weil sie nach einer einfachen Anerkennung suchen. Wir waren in letzter Zeit viel selektiver bei der Bewertung des Schweregrads solcher Berichte und haben in einigen Fällen die Ausstellung von CVE-Hinweisen für Items mit niedrigem Schweregrad abgelehnt. Ich habe einige Gefühle bezüglich der Tatsache, dass private Offenlegung ohnehin stirbt, worüber ich ein anderes Mal schreiben könnte, aber der Aufwand, der mit der Koordination privater Fixes, Offenlegungshinweise und Releases verbunden ist, ist erheblich genug, um von uns zu verlangen, selektiv zu sein.

Letztendlich basiert Open Source auf Vertrauen.