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

Resumen Técnico: Desforkar el Mundo del Código

Planteamiento del Problema
La minería de repositorios de software a escala global se ve fundamentalmente comprometida por el forking (bifurcación). Cuando un único historial ascendente (upstream) es copiado en miles de repositorios derivados, las métricas estándar basadas en el recuento bruto de repositorios (como la dispersión de autores, el tamaño del proyecto y el abanico de dependencias) se ven infladas en órdenes de magnitud. Un enfoque ingenuo para el "desforkado" (deforking) —fusionar repositorios que comparten el historial de git— falla catastróficamente porque fusiona en exceso software no relacionado. Esto ocurre cuando grupos de commits trivialmente compartidos (por ejemplo, commits vacíos, andamiaje inicial idéntico o archivos de licencia/CI de boilerplate) actúan como "nodos centrales" (hubs) que conectan familias de forks disjuntas en clústeres gigantes y carentes de sentido. Este fenómeno refleja los problemas de sobre-fusión encontrados en la desambiguación de identidad de autores.

Metodología
El artículo presenta un mapa de desforkado curado para la colección World of Code (WoC) V2604, extendiendo un enfoque previo de commits compartidos a un conjunto de datos de 5.87 mil millones de commits y 116 millones de repositorios. La metodología consta de tres etapas principales:

1. Codificación de Estrella Nodo-Hub: En lugar de conectar repositorios que comparten un commit como un clique cuadrático ($O(N^2)$), los autores materializan la relación de commit compartido como un grafo bipartito. Para cada conjunto distinto de repositorios que comparten un commit idéntico, se crea un único nodo "hub", conectado mediante aristas a todos los repositorios participantes. Esto linealiza la codificación a $O(N)$.
2. Clustering de Louvain en Paralelo: El grafo bipartito resultante se agrupa mediante Louvain en Paralelo (PLM) para identificar comunidades. El representante canónico de cada comunidad (excluyendo los nodos hub) se convierte en el proyecto desforkado $P$.
3. Limitación Estructural (Structural Capping): Para prevenir la sobre-fusión causada por los hubs de boilerplate, los autores introducen un límite de tamaño determinista ($C$). Durante la construcción del grafo, cualquier grupo de commits compartidos que exceda el tamaño $C$ es descartado antes de la asignación de nodos. Esto elimina los "hubs gigantes" que conectan familias no relacionadas, preservando al mismo tiempo las familias de forks genuinas conectadas por muchos grupos de commits compartidos más pequeños. Los autores analizan diversos valores de $C$ (específicamente $C=250$ y $C=500$) para determinar el umbral óptimo.

Hallazgos Clave y Contribuciones

• El Problema del Mega-Clúster y el Límite (Exp. D1): Sin la limitación, el clúster más grande absorbe 861,948 repositorios. Aplicar un límite de $C=250$ reduce el clúster más grande a 183,654 repositorios (una reducción del 78.7%) y colapsa la cola de clústeres masivos (de 13 clústeres con $\ge 10^5$ miembros a solo 1). Crucialmente, este límite no destruye las familias de forks genuinas; el recuento de familias de múltiples repositorios permanece estable (aumentando ligeramente de 14.34M a 14.35M), lo que indica que el límite corta los puentes entre familias en lugar de fragmentar las familias mismas.
• Análisis Residual (Exp. D2): Un diagnóstico estructural utilizando la centralidad de intermediación (betweenness centrality) en el clúster limitado más grande revela que el "residuo" restante no es un artefacto de agrupamiento, sino un historial compartido genuino. Los nodos de alta intermediación son repositorios agregadores (por ejemplo, qtwebengine-chromium, los mono-repos de Debian) que han integrado genuinamente historiales ascendentes. A diferencia de los grafos de identidad de autores donde un corte estructural disuelve el mega-clúster, cortar los nodos de alta intermediación en el grafo de proyectos solo reduce el clúster en un ~20%, confirmando que el residuo es una red densa de historial compartido real que no debe ser eliminada quirúrgicamente.
• Impacto en las Señales de Desarrollador (Exp. D3): El límite restaura significativamente la señal de "dispersión" (spread) (el número de proyectos distintos que toca un autor). El desforkado sin límite colapsa la media de dispersión de 89.6 a 4.4, borrando efectivamente la señal para autores prolíficos de múltiples proyectos. El límite de $C=250$ restaura la media de dispersión a 38.2 y recupera el recuento de autores con $>1,000$ proyectos de 15 a 2,213, mientras sigue colapsando los forks genuinos.
• Validación Externa (Exp. D4): El mapa se valida contra el grafo de forks declarado de GitHub (reconstruido a partir de GHArchive ForkEvents). Condicionado a que ambos extremos existan en WoC, hay un acuerdo de aristas del 99.01% entre el desforkado basado en commits y los forks declarados de GitHub. La divergencia restante del 0.99% consiste en forks que han divergido completamente o que nunca compartieron un commit, lo cual es el comportamiento correcto para un método basado en commits. El análisis también identifica un 11.04% de padres de forks declarados que WoC aún no ha ingerido, sirviendo como métrica de completitud.
• Cross-Forge y Forks Desacoplados (Exp. D5): Debido a que el mapa depende de commits compartidos y no de metadatos de la plataforma, identifica familias de forks invisibles para los grafos de una sola plataforma.
  • Familias Cross-Forge: El 5.41% de las familias de forks abarcan múltiples forges (por ejemplo, GitHub, GitLab, Bitbucket).
  • Raíces No-GitHub: El 1.51% de las familias de forks tienen una raíz canónica que no está alojada en GitHub.
  • Forks Desacoplados (Detached Forks): El análisis identifica 455,550 aristas "fuertemente desacopladas" donde un fork declarado no tiene historial de commits compartido con su padre en WoC. De estas, 240,441 representan orígenes independientes genuinos que han desarrollado sus propios árboles descendientes.
• Lista de Exclusión Actualizada: Los autores lanzan una lista de exclusión de forks actualizada que contiene 134.1 millones de hijos (3.4 veces mayor que la lista anterior de la era GHTorrent), refinada para excluir solo aquellos forks que no están desacoplados.

Significancia y Reivindicaciones
El artículo sostiene que este mapa de desforkado proporciona una construcción prerrequisito necesaria para cualquier análisis a escala global de repositorios de software, corrigiendo la inflación de las métricas de popularidad y dispersión causada por la multiplicidad de los forks.

Los autores enfatizan que su enfoque es complementario a los metadatos de la plataforma. Mientras que los grafos de plataforma (como el de GitHub) solo registran forks creados mediante acciones de la interfaz de usuario dentro de un periodo específico, este enfoque basado en commits recupera relaciones de fork que abarcan diferentes forges y sobreviven al desprendimiento del historial. El mapa captura familias de forks "solo de WoC" que los grafos de plataforma no pueden representar.

Los autores declaran explícitamente que el mapa sin límite (actualmente distribuido por WoC) debe permanecer intacto respecto al mega-clúster "residual", ya que el diagnóstico estructural demuestra que representa un historial integrado (vendored) genuino y no un artefacto; sin embargo, recomiendan el mapa con límite ($C=250$) para su adopción futura para eliminar la sobre-fusión de boilerplate, señalando que la versión sin límite que circula actualmente sufre de la sobre-fusión de proyectos no relacionados conectados por commits triviales.

Todos los artefactos, incluyendo los mapas de desforkado, las variantes con límite, las listas de exclusión de forks y el código de replicación, se liberan como un paquete autónomo e independientemente alojado, vinculado a la colección WoC V2604.