Removing Noise or Introducing Bias? The Hidden Cost of MSR Filtering

Stellen Sie sich das Internet als eine riesige, chaotische Bibliothek vor, in der jeder ein Regal bauen und es eine Bibliothek nennen kann. Dies ist die Welt der Open-Source-Software (OSS), ein massiver digitaler Spielplatz, auf dem Millionen von Menschen – von Studenten, die neue Programmierideen testen, bis hin zu professionellen Entwicklern, die die nächste große App bauen – ihre Projekte speichern. Forscher, die wie Detektive sind, die versuchen, Rätsel darüber zu lösen, wie Software funktioniert, lieben es, diese Bibliothek zu besuchen. Sie wühlen sich durch die Regale und schauen nach, wie viele Leute ein Projekt „geliked“ haben (Sterne), wie oft Leute die Bücher geändert haben (Commits) und wie viele Leute geholfen haben, sie zu schreiben. Diese Hinweise helfen ihnen, die Geheimnisse des Software-Engineerings zu verstehen. Aber hier ist der Haken: Die Bibliothek ist so riesig, dass sie voller leerer Kartons, Testpuppen und halbfertiger Skizzen ist. Um die „echten“ Bücher zu finden, werfen Forscher normalerweise alles weg, was nicht populär oder aktiv genug aussieht. Sie verwenden Regeln wie: „Wenn ein Projekt nicht mindestens 10 Sterne hat, ist es nur Rauschen, also werfen wir es weg.“

Aber was wäre, wenn diese Regeln die interessantesten Geschichten wegwerfen? Was wäre, wenn wir in unserem verzweifelten Versuch, die Bibliothek aufzuräumen, versehentlich die Tatsache verbergen, dass die meisten Bücher tatsächlich verlassen sind, oder dass wir am Ende nur diejenigen lesen, die von denselben wenigen berühmten Autoren geschrieben wurden? Das ist die große Frage, die die Forscher Mohit Kaushik und Jyoti Bawa stellen. Sie sind besorgt, dass genau die Filter, die Wissenschaftler verwenden, um ihre Daten „sauber“ zu machen, ihre Erkenntnisse „schmutzig“ machen könnten, indem sie die wahre, chaotische Realität dessen verbergen, wie Softwareprojekte tatsächlich leben und sterben.

Der Große Filter: Daten bereinigen oder die Wahrheit verbergen?

In dieser Studie beschlossen die Autoren, ein „Was wäre wenn?“-Spiel mit einem riesigen Stapel Daten zu spielen. Sie betrachteten 1,57 Millionen Software-Repositories von einer Plattform namens SEART. Betrachten Sie diesen Datensatz als einen riesigen Eimer mit gemischten LEGO-Steinen. Einige sind riesige, farbenfrohe Schloss-Sets; andere sind winzige, einzelne rote Steine; und viele sind einfach nur kaputte Teile, die niemand jemals fertiggestellt hat.

Normalerweise schauen Forscher auf diesen Eimer und sagen: „Okay, wir wollen nur die großen, fertigen Schlösser. Lassen Sie uns alles wegwerfen, was weniger als 10 Sterne (Likes) oder weniger als 10 Commits (Änderungen) hat.“ Die Autoren testeten, was passiert, wenn sie diese strengen Regeln anwenden, indem sie den Filter so weit aufdrehen, bis er richtig laut wird.

Die versteckten Kosten von „Popularität“
Als die Forscher einen „Popularitätsfilter“ anwandten (indem sie nur Projekte mit mehr Sternen betrachteten), fanden sie etwas Überraschendes heraus. Als sie die Stern-Schwelle von 10 auf 1.000 erhöhten, wurde das „durchschnittliche“ Projekt in ihrer Stichprobe nicht nur ein wenig besser; es wurde 7 Mal größer. Die Projekte wurden älter, hatten mehr Menschen, die daran arbeiteten, und es war viel wahrscheinlicher, dass sie eine formale Lizenz (wie ein Regelwerk) besaßen.

Aber hier ist die Wendung: Indem sie den populären Projekten nachjagten, verloren sie völlig den Blick auf die Realität. In ihrem ursprünglichen, ungefilterten Eimer waren 73,42 % der Projekte tatsächlich inaktiv oder „verlassen“. Doch als sie nach Popularität filterten, sank diese Zahl. Als sie schließlich nur noch die superpopulären Projekte (1.000+ Sterne) betrachteten, machte die Statistik den Eindruck, als wären nur noch 50,65 % verlassen. Der Filter entfernte nicht nur das Rauschen; er verbarg die Tatsache, dass die meisten Projekte scheitern oder zurückgelassen werden. Es ist, als würde man nur die erfolgreichsten Menschen einer Stadt nach ihrem Job fragen und dann schlussfolgern, dass „die Arbeitslosigkeit niedrig ist“, weil man nie mit den Menschen gesprochen hat, die ihren Job verloren haben.

Die „Aktivitätsfalle“
Die Autoren testeten auch „Aktivitätsfilter“, die nur Projekte mit einer hohen Anzahl an Commits (Änderungen) behalten. Dies war noch extremer. Wenn sie für hochaktive Projekte filterten, wuchs die durchschnittliche Projektgröße um das 18-Fache! Diese Filter veränderten auch die „Persönlichkeit“ der Software. Zum Beispiel waren Projekte, die die Sprache C++ verwendeten, in den Gruppen mit niedrigeren Schwellenwerten häufig, verschwanden aber aus den Top 5, wenn der Filter streng wurde. Währenddessen wurden TypeScript und Go in den gefilterten Listen viel häufiger.

Die Studie legt nahe, dass diese Filter nicht neutral sind. Sie wirken wie ein Sieb, das nur bestimmte Arten von Projekten durchlässt: ältere, riesige, gut finanzierte Infrastrukturprojekte. Sie drängen kleinere, neuere oder experimentellere Projekte heraus, selbst wenn diese kleineren Projekte real und aktiv sind.

Das Beziehungs-Rummeln
Vielleicht ist die spielerischste (und gefährlichste) Erkenntnis die darüber, wie diese Filter die Beziehungen zwischen verschiedenen Dingen durcheinanderbringen. Stellen Sie sich vor, Sie versuchen herauszufinden, ob „hart arbeiten“ (Commits) zu „Popularität“ (Sterne) führt. In der echten, chaotischen Welt (den Basisdaten) sind diese beiden Dinge nur schwach miteinander verbunden. Aber als die Forscher ihre Filter anwandten, sah die Verbindung plötzlich super stark aus.

Beispielsweise sprang die Verbindung zwischen „Commits“ und „Projektgröße“ von einem moderaten 0,466 auf einen sehr starken Wert von 0,808 in der aktivitätsgefilterten Gruppe. Die Autoren erklären, dass dies nicht liegt, weil sich die Projekte tatsächlich geändert haben; es ist, weil der Filter sie dazu zwang, so auszusehen. Indem sie nur die großen, geschäftigen Projekte behielten, ließen sie es so aussehen, als ob „große Projekte immer viele Commits haben“, während die Beziehung in Wirklichkeit viel komplizierter ist. Es ist, als würde man nur die größten Basketballspieler studieren und schlussfolgern, dass „Größe das Einzige ist, was im Sport zählt“, während man alle anderen ignoriert.

Das Urteil: Werfen Sie den Lärm nicht einfach weg
Die Autoren kommen zu dem Schluss, dass wir unsere Daten zwar bereinigen müssen, aber nicht einfach willkürliche Regeln wie „10 Sterne“ oder „500 Commits“ anwenden dürfen, ohne nachzudenken. Diese Regeln sind wie ein stumpfer Hammer: Sie zertrümmern das „Rauschen“, aber sie zertrümmern auch die Wahrheit. Sie erzeugen ein verzerrtes Bild, in dem Softwareprojekte erfolgreicher, älter und einheitlicher erscheinen, als sie es wirklich sind.

Anstatt blind zu filtern, schlagen die Autoren vor, dass Forscher geschichtete Stichproben (stratified sampling) verwenden sollten. Stellen Sie sich vor, man nimmt eine Schaufel aus dem LEGO-Eimer, die eine faire Mischung aus großen Schlössern, kleinen Häusern und kaputten Teilen enthält, anstatt nur die größten Schlösser herauszusuchen. Sie fordern Wissenschaftler auch auf, darüber nachzudenken, was als „Rauschen“ gilt. Vielleicht ist ein Projekt mit null Sternen nicht nur ein gescheitertes Experiment; vielleicht ist es ein verborgenes Juwel, das einfach noch nicht entdeckt wurde.

Kurz gesagt: Dieses Paper warnt uns davor, dass wir in unserem Eifer, die „perfekten“ Daten zu finden, vielleicht ein Kartenhaus bauen, das nach außen hin perfekt aussieht, aber in sich zusammenbricht, sobald wir versuchen, die echte, chaotische Welt der Software zu verstehen. Die Autoren sagen nicht, dass wir das Filtern ganz aufgeben sollen, aber sie legen nahe, dass wir aufhören sollten, diese „Einheitsregeln“ anzuwenden, und stattdessen vorsichtiger sein sollten, was wir wegwerfen.