💻 computer science

Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See

Dit artikel introduceert een gecureerde "deforking"-kaart voor de World of Code die cross-forge projectfamilies reconstrueert door gedeelde git-historieën samen te voegen tot verenigde clusters, waardoor populariteitsinflatie wordt gecorrigeerd en duizenden fork-relaties worden onthuld—inclusief multi-forge families en niet-GitHub wortels—die onzichtbaar zijn voor platformspecifieke grafieken.

Oorspronkelijke auteurs: Audris Mockus

Gepubliceerd 2026-06-30

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Audris Mockus

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je de hele geschiedenis van softwareontwikkeling voor als een enorme, chaotische bibliotheek. In deze bibliotheek bevinden zich miljoenen boeken (repositories). Maar hier komt de adder onder het gras: veel boeken zijn slechts fotokopieën van hetzelfde originele verhaal.

In de wereld van coderen wordt dit forking genoemd. Een ontwikkelaar neemt een bestaand project, maakt er een kopie van en start zijn eigen versie. Ze passen misschien hier en daar een paar regels aan, maar de kern van de geschiedenis is identiek.

Het probleem dat het artikel aanpakt, is dat als je probeert te tellen hoe "populair" een stuk code is door simpelweg elk boek in de bibliotheek te tellen, je een enorm opgeblazen aantal krijgt. Als één populair verhaal 10.000 keer is gekopieerd, lijkt het alsof er 10.000 verschillende verhalen worden gelezen, terwijl het in werkelijkheid slechts één verhaal is dat op 10.000 verschillende plaatsen wordt gelezen.

Dit artikel introduceert een nieuwe kaart (een hulpmiddel) die deze bibliotheek opruimt. Het groepeert alle fotokopieën weer bij hun oorspronkelijke bron, zodat onderzoekers het echte verhaal kunnen zien, en niet de ruis van de kopieën.

Zo hebben ze het gedaan, met behulp van eenvoudige analogieën:

1. De "Gedeelde Pagina" Detective

De auteurs realiseerden zich dat je in de digitale wereld de geschiedenis niet gemakkelijk kunt vervalsen. Als twee boeken exact dezelfde pagina delen (een specifieke "commit" of wijziging in de code), moeten ze aan elkaar verwant zijn.

De Oude Manier: Ze probeerden elk boek te koppelen dat een pagina deelde. Maar dit was alsof zeggen: "Als twee boeken beide een pagina hebben met 'Copyright 2024', dan zijn ze hetzelfde verhaal." Dat is fout! Veel ongerelateerde boeken hebben dezelfde copyrightpagina. Dit zorgde ervoor dat de kaart volledig verschillende verhalen aan elkaar plakte tot één grote, rommelige brij.
De Nieuwe Manier: Ze bouwden een slimmere kaart. Ze keken naar veel gedeelde pagina's, niet slechts één. Als twee boeken een heel hoofdstuk delen, zijn ze zeker aan elkaar verwant.

2. De "Groottebeperking" Filter (De Cap)

Zelfs met de slimmere kaart waren sommige enorme, saaie pagina's (zoals standaard licentieovereenkomsten of lege starter-templates) nog steeds bezig als bruggen die ongerelateerde verhalen met elkaar verbonden.

De Oplossing: De auteurs voegden een groottebeperking toe aan deze bruggen. Als een gedeelde pagina in meer dan 250 boeken voorkomt, gaan ze ervan uit dat het een generieke template is (zoals een standaard "Algemene Voorwaarden"-pagina) en negeren ze deze.
Het Resultaat: Dit brak de grote, rommelige brijen uit elkaar. Plotseling toonde de kaart duidelijke families van verhalen in plaats van één grote, verwarrende super-cluster. Het brak geen echte families af; het verwijderde alleen de lijm die ongerelateerde dingen aan elkaar plakte.

3. De "Echte Geschiedenis" Check

De auteurs maakten zich zorgen dat ze door deze grote brijen door te snijden, per ongeluk een echt, complex verhaal hadden doorgehakt dat van nature uit veel delen bestond (zoals een verhaal dat in veel talen is vertaald en daarna weer is samengevoegd).

De Test: Ze keken naar de grootste resterende groep op hun kaart. Ze ontdekten dat dit geen fout was; het was een echt, complex verhaal waarbij één groot project daadwerkelijk delen van andere beroemde projecten had geabsorbeerd (zoals een groot besturingssysteem dat code van een webbrowser incorporeerde).
De Beslissing: Omdat deze "residuele" groep bestond uit echte, diepe geschiedenis en niet uit goedkope lijm, besloten ze niet verder te snijden. Ze lieten het intact omdat het een ware, complexe relatie in de softwarewereld vertegenwoordigt.

4. Controleren tegen de "Officiële Lijst"

Om er zeker van te zijn dat hun kaart accuraat was, vergeleken ze deze met de officiële "Fork List" van GitHub (een lijst waar gebruikers handmatig op een "Fork"-knop klikken).

De Match: Wanneer ze naar projecten keken die zowel op hun kaart als op de lijst van GitHub stonden, kwamen ze in 99% van de gevallen overeen.
De Verrassing: Hun kaart vond dingen die de lijst van GitHub miste!
- Cross-Forge Families: Ze vonden families van projecten die op GitHub begonnen maar werden gekopieerd naar GitLab, Bitbitket en andere sites. De lijst van GitHub ziet alleen de GitHub-kant; deze kaart ziet de hele familieboom over het hele internet.
- Detached Forks: Ze vonden projecten die als kopieën begonnen maar daarna hun geschiedenis volledig hadden herschreven, waardoor ze niet langer verbonden zijn met het origineel. De kaart identificeerde deze correct als aparte entiteiten, terwijl de officiële lijst misschien nog steeds denkt dat ze verbonden zijn.

5. Waarom dit ertoe doet

Voordat deze kaart bestond, als je wilde weten hoeveel verschillende projecten een enkele programmeur heeft gewerkt, kreeg je misschien een vals aantal zoals "5.000 projecten", simpelweg omdat diegene aan één populair project heeft gewerkt dat 5.000 kopieën heeft.

De Correctie: Deze kaart herstelt dat. Het vertelt je dat de programmeur eigenlijk aan 5 verschillende projecten heeft gewerkt, en niet aan 5.000.
De Uitkomst: Het biedt een schoon, accuraat beeld van de softwarewereld, waarbij de originele verhalen worden gescheiden van de fotokopieën, en zelfs projecten opspoort die over verschillende websites heen reiken.

Kortom: De auteurs hebben een hulpmiddel gebouwd dat het rommelige web van gekopieerde code ontwarrt. Ze gebruikten een "groottebeperking" om te voorkomen dat ongerelateerde projecten aan elkaar bleven plakken, verifieerden hun werk tegen officiële registers, en ontdekten dat de softwarewereld nog veel meer verbonden is over verschillende websites dan ze voorheen wisten. Ze hebben deze kaart vrijgegeven voor iedereen om te gebruiken, om ervoor te zorgen dat toekomstige studies van de softwaregeschiedenis niet worden misleid door de enorme hoeveelheid kopieën.

Technische Samenvatting: Het de-forken van de Wereld van Code

Probleemstelling
Het minen van software-repositories op wereldwijde schaal wordt fundamenteel gecompromitteerd door forking. Wanneer één upstream-geschiedenis wordt gekopieerd naar duizenden afgeleide repositories, worden standaardmetrieken gebaseerd op ruwe repository-aantallen (zoals author spread, projectgrootte en dependency fan-out) met ordes van grootte opgeblazen. Een naïeve benadering van "de-forking"—het samenvoegen van repositories die een gedeelde git-geschiedenis delen—faalt catastrofaal omdat het ongerelateerde software overmatig samenvoegt. Dit gebeurt wanneer triviaal gedeelde commit-groepen (bijv. lege commits, identieke initiële scaffolding, of boilerplate LICENSE/CI-bestanden) fungeren als "hubs" die uiteenlopende fork-families overbruggen tot gigantische, betekenisloze clusters. Dit fenomeen weerspiegelt de problemen met overmatige samenvoeging die worden gevonden bij de disambiguatie van auteur-identiteiten.

Methodologie
Het artikel presenteert een gecureerde de-forking kaart voor de World of Code (WoC) V2604 collectie, waarbij een eerdere methode gebaseerd op gedeelde commits wordt uitgebreid naar een dataset van 5,87 miljard commits en 116 miljoen repositories. De methodologie bestaat uit drie primaire stadia:

Hub-Node Star Encoding: In plaats van repositories die een commit delen te verbinden als een kwadratische clique ( $O(N^2)$ ), materialiseert de auteur de gedeelde-commit-relatie als een bipartiete graaf. Voor elke unieke set repositories die een identieke commit delen, wordt een enkele "hub"-node gecreëerd, verbonden via randen aan alle participerende repositories. Dit lineariseert de codering naar $O(N)$ .
Parallel Louvain Clustering: De resulterende bipartiete graaf wordt geclusterd met behulp van Parallel Louvain (PLM) om gemeenschappen te identificeren. De canonieke vertegenwoordiger van elke gemeenschap (exclusief de hub-nodes) wordt het de-forked project $P$ .
Structurele Afkapping (Structural Capping): Om de overmatige samenvoeging veroorzaakt door boilerplate-hubs te voorkomen, introduceren de auteurs een deterministische groottecap ( $C$ ). Tijdens de graafconstructie wordt elke gedeelde-commit-groep die een omvang boven $C$ overschrijdt, weggegooid voordat de node-toewijzing plaatsvindt. Dit verwijdert "reusachtige hubs" die ongerelateerde families overbruggen, terwijl echte fork-families die verbonden zijn door veel kleinere gedeelde-commit-groepen behouden blijven. De auteurs onderzoeken verschillende $C$ -waarden (specifiek $C=250$ en $C=500$ ) om de optimale drempelwaarde te bepalen.

Belangrijkste Bevindingen en Bijdragen

Het Mega-Cluster Probleem en de Cap (Exp. D1): Zonder afkapping absorbeert de grootste gemeenschap 861.948 repositories. Het toepassen van een cap van $C=250$ vermindert de grootste cluster tot 183.654 repositories (een reductie van 78,7%) en laat de staart van massieve clusters instorten (van 13 clusters $\ge 10^5$ leden naar slechts 1). Cruciaal is dat deze cap geen echte fork-families vernietigt; het aantal multi-repository families blijft stabiel (een lichte stijging van 14,34M naar 14,35M), wat aangeeft dat de cap bruggen tussen families doorsnijdt in plaats van de families zelf te versplinteren.
Residuele Analyse (Exp. D2): Een structurele diagnose met behulp van betweenness centrality op de grootste afgekapte cluster onthult dat het resterende "residue" geen clustering-artefact is, maar een echte gedeelde geschiedenis. De high-betweenness nodes zijn aggregator-repositories (bijv. qtwebengine-chromium, de mono-repos van Debian) die daadwerkelijk upstream-geschiedenissen hebben ge-vendored. In tegenstelling tot auteur-identiteitsgrafen, waar een structurele snede de mega-cluster oplost, zorgt het snijden van de top betweenness-nodes in de projectgraaf er alleen voor dat de cluster met ~20% krimpt, wat bevestigt dat het residue een dicht web van echte gedeelde geschiedenis is dat niet chirurgisch verwijderd moet worden.
Impact op Developer Signalen (Exp. D3): De cap herstelt het "spread"-signaal (het aantal verschillende projecten waarmee een auteur in aanraking komt) aanzienlijk. Ongekapte de-forking laat de gemiddelde spread instorten van 89,6 naar 4,4, wat het signaal voor productieve multi-project auteurs effectief wist. De $C=250$ cap herstelt de gemiddelde spread naar 38,2 en brengt het aantal auteurs met $>1.000$ projecten terug van 15 naar 2.213, terwijl het nog steeds echte forks samenvoegt.
Externe Validatie (Exp. D4): De kaart wordt gevalideerd tegen de door GitHub verklaarde fork-graaf (gereconstrueerd uit GHArchive ForkEvents). Geconditioneerd op het bestaan van beide eindpunten in WoC, is er een overeenkomst van 99,01% in randen (edge agreement) tussen de op commits gebaseerde de-forking en de door GitHub verklaarde forks. De resterende 0,99% divergentie bestaat uit forks die volledig zijn gedivergeerd of nooit een commit hebben gedeeld, wat het correcte gedrag is voor een op commits gebaseerde methode. De analyse identificeert ook 11,04% van de door GitHub verklaarde fork-ouders die WoC nog niet heeft opgenomen, wat dient als een volledigheidsmetriek.
Cross-Forge en Detached Forks (Exp. D5): Omdat de kaart vertrouwt op gedeelde commits in plaats van platformmetadata, identificeert het fork-families die onzichtbaar zijn voor single-platform grafen.
- Cross-Forge Families: 5,41% van de fork-families overspannen meerdere forges (bijv. GitHub, GitLab, Bitbucket).
- Niet-GitHub Roots: 1,51% van de fork-families heeft een canonieke root die niet op GitHub wordt gehost.
- Detached Forks: De analyse identificeert 455.550 "hard-detached" randen waar een verklaarde fork geen gedeelde commit-geschiedenis heeft met zijn ouder in WoC. Hi van zijn 240.441 vertegenwoordigen werkelijke onafhankelijke origines die hun eigen downstream-bomen hebben ontwikkeld.
Verfriste Exclusie-lijst: De auteurs brengen een bijgewerkte lijst met uitgesloten forks uit die 134,1 miljoen kinderen bevat (3,4× groter dan de vorige lijst uit het GHTorrent-tijdperk), verfijnd om alleen die forks uit te sluiten die niet gedetacheerd zijn.

Significantie en Claims
Het artikel beweert dat deze de-forking kaart een noodzakelijke voorbereidende constructie biedt voor elke analyse van software-repositories op wereldwijde schaal, waarbij de inflatie van populariteit en spread-metrieken door fork-multipliciteit wordt gecorrigeerd.

De auteurs benadrukken dat hun aanpak complementair is aan platformmetadata. Terwijl platformgrafen (zoals die van GitHub) alleen forks registreren die via UI-acties binnen een specifieke periode zijn aangemaakt, herstelt deze op commits gebaseerde aanpak fork-relaties die over verschillende forges heen reiken en geschiedenis-detachment overleven. De kaart legt "alleen-in-WoC" fork-families vast die platformgrafen niet kunnen representeren.

De auteurs stellen expliciet dat de ongekapte kaart (die momenteel door WoC wordt verspreid) intact moet blijven met betrekking tot de "residuele" mega-cluster, aangezien de structurele diagnose bewijst dat dit een echte ge-vendorde geschiedenis vertegenwoordigt en geen artefact is. Ze bevelen echter de gekapte kaart ( $C=250$ ) aan voor toekomstig gebruik om overmatige samenvoeging door boilerplate te elimineren, waarbij zij opmerken dat de ongekapte versie die momenteel in omloop is, lijdt onder de overmatige samenvoeging van ongerelateerde projecten die door triviale gedeelde commits worden overbrugd.

Alle artefacten, inclusief de de-forking kaarten, de gekapte varianten, de lijst met uitgesloten forks en de replicatiecode, worden uitgebracht als een zelfstandig, onafhankelijk gehost pakket dat gekoppeld is aan de WoC V2604 collectie.