Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See
Dieses Paper führt eine kuratierte „Deforking“-Map für die Welt des Codes ein, welche die Projektfamilien über verschiedene Forges hinweg rekonstruiert, indem sie gemeinsame Git-Historien zu vereinheitlichten Clustern kollabiert, wodurch Popularitätsinflation korrigiert und tausende von Fork-Beziehungen offenbart wird – einschließlich Multi-Forge-Familien und Nicht-GitHub-Ursprüngen –, die in plattformspezifischen Graphen unsichtbar sind.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich die gesamte Geschichte der Softwareentwicklung als eine riesige, chaotische Bibliothek vor. In dieser Bibliothek befinden sich Millionen von Büchern (Repositories). Aber hier ist der Haken: Viele dieser Bücher sind nur Fotokopien derselben ursprünglichen Geschichte.
In der Welt des Codierens nennt man das Forking. Ein Entwickler nimmt ein bestehendes Projekt, kopiert es und startet seine eigene Version. Er mag vielleicht ein paar Zeilen hier und da ändern, aber die Kernhistorie ist identisch.
Das Problem, das das Paper behandelt, ist, dass man, wenn man versucht zu zählen, wie „populär“ ein Stück Code ist, indem man einfach jedes einzelne Buch in der Bibliothek zählt, eine völlig übertriebene Zahl erhält. Wenn eine populäre Geschichte 10.000 Mal kopiert wurde, sieht es so aus, als würden 10.000 verschiedene Geschichten gelesen, während es in Wirklichkeit nur eine einzige Geschichte ist, die an 10.000 verschiedenen Orten gelesen wird.
Dieses Paper stellt eine neue Karte (ein Werkzeug) vor, die diese Bibliothek aufräumt. Sie gruppiert alle Fotokopien wieder mit ihrer ursprünglichen Quelle zusammen, damit Forscher die echte Geschichte sehen können und nicht das Rauschen der Kopien.
So haben sie es gemacht, unter Verwendung einfacher Analogien:
1. Der „Gemeinsame Seite“-Detektiv
Die Autoren erkannten, dass man in der digitalen Welt die Historie nicht leicht fälschen kann. Wenn zwei Bücher exakt dieselbe Seite (einen spezifischen „Commit“ oder eine Änderung im Code) teilen, müssen sie miteinander verwandt sein.
- Der alte Weg: Sie versuchten, jedes Buch zu verknüpfen, das eine gemeinsame Seite teilte. Aber das war so, als würde man sagen: „Wenn zwei Bücher dieselbe Seite mit der Aufschrift ‚Copyright 2024‘ haben, sind sie dieselbe Geschichte.“ Das ist falsch! Viele unzusammenhängende Bücher haben dieselbe Copyright-Seite. Dies führte dazu, dass die Karte völlig unterschiedliche Geschichten zu einem einzigen, riesigen, unordentlichen Klumpen zusammenklebte.
- Der neue Weg: Sie bauten eine intelligentere Karte. Sie suchten nach vielen gemeinsamen Seiten, nicht nur einer. Wenn zwei Bücher ein ganzes Kapitel teilen, sind sie definitiv verwandt.
2. Der „Größenlimit“-Filter (Die Kappe)
Selbst mit der intelligenteren Karte fungierten einige riesige, langweilige Seiten (wie Standard-Lizenzvereinbarungen oder leere Starter-Templates) immer noch als Brücken, die unzusammenhängende Geschichten verbanden.
- Die Lösung: Die Autoren setzten ein Größenlimit für diese Brücken ein. Wenn eine gemeinsame Seite in mehr als 250 Büchern erscheint, gehen sie davon aus, dass es sich nur um ein generisches Template handelt (wie eine Standard-„Nutzungsbedingungen“-Seite) und ignorieren sie.
- Das Ergebnis: Dies löste die riesigen, unordentlichen Klumpen auf. Plötzlich zeigte die Karte deutliche Familien von Geschichten statt eines einzigen, riesigen, verwirrenden Super-Clusters. Es spaltete nicht echte Familien auf, sondern entfernte lediglich den Kleber, der unzusammenhängende Dinge zusammenkleben würde.
3. Der „Echte Historie“-Check
Die Autoren sorgten sich, dass sie durch das Aufbrechen dieser riesigen Klumpen versehentlich eine echte, komplexe Geschichte zerschnitten haben könnten, die von Natur aus viele Teile hatte (wie eine Geschichte, die in viele Sprachen übersetzt und dann wieder kombiniert wurde).
- Der Test: Sie betrachteten die größte verbleibende Gruppe auf ihrer Karte. Sie fanden heraus, dass dies kein Fehler war, sondern eine echte, komplexe Geschichte, bei der ein großes Projekt tatsächlich Teile anderer berühmter Projekte absorbiert hatte (wie etwa ein bedeutendes Betriebssystem, das Code aus einem Webbrowser integriert hat).
- Die Entscheidung: Da diese „Restgruppe“ aus echter, tiefer Historie bestand und nicht nur aus billigem Kleber, entschieden sie sich, sie nicht weiter aufzubrechen. Sie ließen sie intakt, weil sie eine wahre, komplexe Beziehung in der Softwarewelt repräsentiert.
4. Der Abgleich mit der „Offiziellen Liste“
Um sicherzustellen, dass ihre Karte genau war, verglichen sie sie mit GitHubs offizieller „Fork-Liste“ (einer Liste, in der Benutzer manuell auf einen „Fork“-Button klicken).
- Die Übereinstimmung: Wenn sie Projekte betrachteten, die sowohl auf ihrer Karte als auch auf GitHubs Liste existierten, stimmten sie zu 99 % überein.
- Die Überraschung: Ihre Karte fand Dinge, die GitHubs Liste übersah!
- Cross-Forge-Familien: Sie fanden Familien von Projekten, die auf GitHub begannen, aber auf GitLab, Bitbucket und andere Seiten kopiert wurden. GitHubs Liste sieht nur die GitHub-Seite; diese Karte sieht den gesamten Stammbaum über das gesamte Internet.
- Abgetrennte Forks: Sie fanden Projekte, die als Kopien begannen, aber dann ihre Historie komplett neu geschrieben haben, sodass sie nicht mehr mit dem Original verbunden sind. Die Karte identifizierte diese korrekt als separate Einheiten, während die offizielle Liste sie möglicherweise noch als verbunden ansieht.
5. Warum das wichtig ist
Bevor es diese Karte gab, wenn man wissen wollte, wie viele verschiedene Projekte ein einzelner Programmierer bearbeitet hat, könnte man eine falsche Zahl wie „5.000 Projekte“ erhalten, nur weil er an einem populären Projekt mit 5.000 Kopien gearbeitet hat.
- Die Korrektur: Diese Karte behebt das. Sie sagt einem, dass der Programmierer tatsächlich an 5 distinkten Projekten gearbeitet hat, nicht an 5.000.
- Das Ergebnis: Sie bietet eine saubere, genaue Sicht auf die Softwarewelt, trennt die ursprünglichen Geschichten von den Fotokopien und erkennt sogar Geschichten, die über verschiedene Websites hinweg verlaufen.
Kurz gesagt: Die Autoren haben ein Werkzeug gebaut, das das unordentliche Geflecht aus kopiertem Code entwirrt. Sie nutzten ein „Größenlimit“, um zu verhindern, dass unzusammenhängende Projekte zusammenkleben, verifizierten ihre Arbeit anhand offizieller Aufzeichnungen und entdeckten, dass die Softwarewelt über verschiedene Websites hinweg noch stärker vernetzt ist, als wir zuvor wussten. Sie haben diese Karte für jeden zur Verfügung gestellt, um sicherzustellen, dass zukünftige Studien der Softwaregeschichte nicht durch das schiere Volumen an Kopien getäuscht werden.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.