💻 computer science

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

Questo articolo introduce una mappa di "deforking" curata per il World of Code che ricostruisce le famiglie di progetti cross-forge collassando le cronologie git condivise in cluster unificati, correggendo così l'inflazione della popolarità e rivelando migliaia di relazioni di fork — inclusi i nuclei multi-forge e quelli con radici non GitHub — che sono invisibili ai grafi specifici delle singole piattaforme.

Autori originali: Audris Mockus

Pubblicato 2026-06-30

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Audris Mockus

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina l'intera storia dello sviluppo del software come una biblioteca enorme e caotica. In questa biblioteca ci sono milioni di libri (repository). Ma ecco il problema: molti di questi libri sono solo fotocopie della stessa storia originale.

Nel mondo della programmazione, questo si chiama forking. Uno sviluppatore prende un progetto esistente, lo copia e avvia la propria versione. Potrebbe modificare qualche riga qui o là, ma la storia centrale è identente.

Il problema che il documento affronta è che, se provi a contare quanto sia "popolare" un pezzo di codice contando semplicemente ogni singolo libro nella biblioteca, ottieni un numero enormemente gonfiato. Se una storia popolare è stata copiata 10.000 volte, sembra che siano state lette 10.000 storie diverse, quando in realtà è solo una storia letta in 10.000 posti diversi.

Questo documento presenta una nuova mappa (uno strumento) che pulisce questa biblioteca. Raggruppa tutte le fotocopie con la loro fonte originale, così i ricercatori possono vedere la vera storia, non il rumore delle copie.

Ecco come l'hanno fatto, usando analogie semplici:

1. Il detective della "Pagina Condivisa"

Gli autori si sono resi conto che nel mondo digitale non è facile falsificare una storia. Se due libri condividono la stessa identica pagina (un particolare "commit" o modifica nel codice), devono essere correlati.

Il vecchio modo: Cercavano di collegare ogni libro che condivideva una pagina. Ma questo era come dire: "Se due libri hanno entrambi una pagina che dice 'Copyright 2024', sono la stessa storia". Questo è sbagliato! Molti libri non correlati hanno la stessa pagina del copyright. Ciò causava l'unione di libri completamente diversi in un unico, enorme e disordinato ammasso.
Il nuovo modo: Hanno costruito una mappa più intelligente. Cercavano molte pagine condivise, non solo una. Se due libri condividono un intero capitolo, sono sicuramente correlati.

2. Il filtro del "Limite di Dimensione" (Il Cap)

Anche con la mappa più intelligente, alcune pagine enormi e noiose (come le licenze standard o i modelli di partenza vuoti) agivano ancora come ponti, collegando storie non correlate.

La soluzione: Gli autori hanno imposto un limite di dimensione a questi ponti. Se una pagina condivisa appare in più di 250 libri, assumono che sia solo un modello generico (come una pagina standard dei "Termini di Servizio") e la ignorano.
Il risultato: Questo ha frammentato i grandi e disordinati ammassi. Improvvisamente, la mappa mostrava distinte famiglie di storie invece di un unico, confuso super-cluster. Non ha rotto le vere famiglie; ha solo rimosso la colla che univa cose non correlate.

3. Il controllo della "Storia Reale"

Gli autori temevano che, tagliando questi grandi ammassi, potessero aver accidentalmente interrotto una storia reale e complessa che naturalmente aveva molte parti (come una storia che è stata tradotta in molte lingue e poi ricombinata).

Il test: Hanno esaminato il gruppo più grande rimanente sulla loro mappa. Hanno scoperto che non era un errore; era una storia reale e complessa in cui un grande progetto aveva genuinamente assorbito parti di altri progetti famosi (come un importante sistema operativo che incorpora codice da un browser web).
La decisione: Poiché questo gruppo "residuo" era composto da una storia reale e profonda e non da semplice colla economica, hanno deciso di non tagliarlo ulteriormente. Lo hanno lasciato intatto perché rappresenta una vera, complessa relazione nel mondo del software.

4. Il controllo contro la "Lista Ufficiale"

Per assicurarsi che la loro mappa fosse accurata, l'hanno confrontata con la "Lista dei Fork" ufficiale di GitHub (una lista dove gli utenti cliccano manualmente il tasto "Fork").

L'abbinamento: Quando hanno guardato i progetti presenti sia sulla loro mappa che sulla lista di GitHub, hanno riscontrato un abbinamento del 99% delle volte.
La sorpresa: La loro mappa ha trovato cose che la lista di GitHub ha mancato!
- Famiglie Cross-Forge: Hanno trovato famiglie di progetti che sono iniziate su GitHub ma sono state copiate su GitLab, Bitbucket e altri siti. La lista di GitHub vede solo il lato di GitHub; questa mappa vede l'intera famiglia attraverso internet.
- Fork Distaccati: Hanno trovato progetti che sono iniziati come copie ma che hanno poi riscritto completamente la loro storia, in modo da non essere più connessi all'originale. La mappa ha identificato correttamente questi come entità separate, mentre la lista ufficiale potrebbe ancora considerarli connessi.

5. Perché questo è importante

Prima di questa mappa, se volevi sapere quanti diversi progetti ha lavorato un singolo programmatore, avresti potuto ottenere un numero falso come "5.000 progetti" solo perché ha lavorato su un progetto popolare che ha 5.000 copie.

La correzione: Questa mappa risolve questo problema. Ti dice che il programmatore ha effettivamente lavorato su 5 progetti distinti, non 5.000.
Il risultato: Fornisce una visione pulita e accurata del mondo del software, separando le storie originali dalle fotocopie, e individuando persino storie che attraversano diversi siti web.

In breve: Gli autori hanno costruito uno strumento che districa la rete disordinata del codice copiato. Hanno usato un "limite di dimensione" per impedire a progetti non correlati di attaccarsi insieme, hanno verificato il loro lavoro rispetto ai record ufficiali e hanno scoperto che il mondo del software è ancora più interconnesso tra diversi siti web di quanto pensassimo in precedenza. Hanno rilasciato questa mappa affinché chiunque possa usarla, assicurando che le future ricerche sulla storia del software non siano ingannate dall'enorme volume di copie.

Sintesi Tecnica: Deforking del Mondo del Codice (World of Code)

Definizione del Problema
L'estrazione di dati dai repository software su scala globale è fondamentalmente compromessa dal fenomeno del forking. Quando una singola cronologia upstream viene copiata in migliaia di repository derivati, le metriche standard basate sul conteggio grezzo dei repository (come la diffusione degli autori, la dimensione del progetto e il fan-out delle dipendenze) risultano gonfiate di ordini di grandezza. Un approccio ingenuo al "deforking" — ovvero la fusione di repository che condividono la stessa cronologia git — fallisce catastroficamente perché fonde eccessivamente software non correlati. Ciò accade quando gruppi di commit trivialmente condivisi (ad esempio, commit vuoti, scaffold iniziali identici o file LICENSE/CI boilerplate) agiscono come "hub" che collegano famiglie di fork disgiunte in enormi cluster privi di significato. Questo fenomeno rispecchia i problemi di sovra-unificazione riscontrati nella disambiguazione dell'identità degli autori.

Metodologia
Il documento presenta una mappa di deforking curata per la collezione World of Code (WoC) V2604, estendendo un precedente approccio basato sui commit condivisi a un dataset di 5,87 miliardi di commit e 116 milioni di repository. La metodologia prevede tre fasi primarie:

Codifica Hub-Node Star: Invece di connettere i repository che condividono un commit come un clique quadratica ( $O(N^2)$ ), gli autori materializzano la relazione di commit condiviso come un grafo bipartito. Per ogni set distinto di repository che condividono un commit identico, viene creato un singolo nodo "hub", connesso tramite archi a tutti i repository partecipanti. Questo linearizza la codifica a $O(N)$ .
Clustering Louvain Parallelo: Il grafo bipartito risultante viene raggruppato utilizzando il metodo Parallel Louvain (PLM) per identificare le comunità. Il rappresentante canonico di ogni comunità (escludendo i nodi hub) diventa il progetto deforked $P$ .
Limitazione Strutturale (Structural Capping): Per prevenire la sovra-unificazione causata dagli hub boilerplate, gli autori introducono un limite di dimensione deterministico ( $C$ ). Durante la costruzione del grafo, qualsiasi gruppo di commit condivisi che superi la dimensione $C$ viene scartato prima dell'assegnazione dei nodi. Questo rimuove i "giant hubs" che collegano famiglie non correlate, preservando al contempo le genuine famiglie di fork connesse da molti gruppi di commit condivisi più piccoli. Gli autori testano diversi valori di $C$ (specificamente $C=250$ e $C=500$ ) per determinare la soglia ottimale.

Risultati Chiave e Contributi

Il Problema del Mega-Cluster e il Limite (Esp. D1): Senza il limite, la comunità più grande assorbe 861.948 repository. Applicando un limite di $C=250$ , la comunità più grande si riduce a 183.654 repository (una riduzione del 78,7%) e collassa la coda dei cluster massicci (da 13 cluster con $\ge 10^5$ membri a 1). Fondamentalmente, questo limite non distrugge le genuine famiglie di fork; il conteggio delle famiglie multi-repository rimane stabile (aumentando leggermente da 14,34M a 14,35M), indicando che il limite recide i ponti tra le famiglie piuttosto che frantumare le famiglie stesse.
Analisi Residua (Esp. D2): Un diagnostico strutturale utilizzando la centralità di intermediazione (betweenness centrality) sul più grande cluster limitato rivela che il "residuo" rimanente non è un artefatto di clustering ma una genuina cronologia condivisa. I nodi con alta centralità sono repository aggregatori (ad esempio, qtwebengine-chromium, i mono-repo di Debian) che hanno genuinamente incorporato (vendored) cronologie upstream. A differenza dei grafi di identità degli autori dove un taglio strutturale dissolve il mega-cluster, tagliare i nodi con la più alta centralità nel grafo dei progetti riduce il cluster solo di circa il 20%, confermando che il residuo è una rete densa di vera cronologia condivisa che non dovrebbe essere rimossa chirurgicamente.
Impatto sui Segnali degli Sviluppatori (Esp. D3): Il limite ripristina significativamente il segnale di "diffusione" (spread, ovvero il numero di progetti distinti toccati da un autore). Un deforking senza limiti collassa la media della diffusione da 89,6 a 4,4, cancellando di fatto il segnale per gli autori prolifici multi-progetto. Il limite $C=250$ ripristina la media della diffusione a 38,2 e recupera il conteggio degli autori con $>1.000$ progetti da 15 a 2.213, pur continuando a collassare i veri fork.
Validazione Esterna (Esp. D4): La mappa è validata rispetto al grafo dei fork dichiarato di GitHub (ricostruito da GHArchive ForkEvents). Condizionatamente alla presenza di entrambi gli endpoint in WoC, c'è un accordo sugli archi del 99,01% tra il deforking basato sui commit e i fork dichiarati di GitHub. Lo 0,99% di divergenza rimanente consiste in fork che si sono completamente diversificati o che non hanno mai condiviso un commit, che è il comportamento corretto per un metodo basato sui commit. L'analisi identifica anche l'11,04% dei genitori di fork dichiarati che WoC non ha ancora ingerito, fungendo da metrica di completezza.
Cross-Forge e Fork Distaccati (Esp. D5): Poiché la mappa si basa su commit condivisi anziché su metadati della piattaforma, essa identifica famiglie di fork invisibili ai grafi a singola piattaforma.
- Famiglie Cross-Forge: Il 5,41% delle famiglie di fork attraversa più forge (ad esempio, GitHub, GitLab, Bitbucket).
- Radici Non-GitHub: Il 1,51% delle famiglie di fork ha una radice canonica non ospitata su GitHub.
- Fork Distaccati: L'analisi identifica 455.550 archi "hard-detached" dove un fork dichiarato non ha alcuna cronologia di commit condivisa con il suo genitore in WoC. Di questi, 240.441 rappresentano origini indipendenti genuine che hanno sviluppato i propri alberi a valle.
Lista di Esclusione Aggiornata: Gli autori rilasciano una lista aggiornata di esclusione dei fork contenente 134,1 milioni di figli (3,4 volte più grande della precedente lista dell'era GHTorrent), raffinata per escludere solo quei fork che non sono distaccati.

Significato e Rivendicazioni
Il documento sostiene che questa mappa di deforking fornisce una costruzione prerequisito necessaria per qualsiasi analisi su scala globale dei repository software, correggendo l'inflazione delle metriche di popolarità e diffusione causata dalla molteplicità dei fork.

Gli autori sottolineano che il loro approccio è complementare ai metadati delle piattaforme. Mentre i grafi delle piattaforme (come quello di GitHub) registrano solo i fork creati tramite azioni dell'interfaccia utente entro una specifica finestra temporale, questo approccio basato sui commit recupera le relazioni di fork che attraversano diverse forge e sopravvivono al distacco della cronologia. La mappa cattura famiglie di fork "solo-WoC" che i grafi delle piattaforme non possono rappresentare.

Gli autori dichiarano esplicitamente che la mappa senza limiti (attualmente distribuita da WoC) dovrebbe rimanere intatta riguardo al mega-cluster "residuo", poiché il diagnostico strutturale prova che esso rappresenta una genuina cronologia incorporata (vendored) piuttosto che un artefatto; tuttavia, raccomandano la mappa con limite ( $C=250$ ) per l'adozione futura al fine di eliminare la sovra-unificazione del codice boilerplate, notando che la versione senza limiti attualmente in circolazione soffre della sovra-unificazione di progetti non correlati collegati da commit triviali condivisi.

Tutti gli artefatti, inclusi i grafi di deforking, le varianti con limite, le liste di esclusione dei fork e il codice di replicazione, sono rilasciati come un pacchetto autosufficiente e ospitato indipendentemente, riferito alla collezione WoC V2604.