💻 computer science

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

Este artigo introduz um mapa de "deforking" curado para o Mundo do Código que reconstrói famílias de projetos entre diferentes forks ao colapsar históricos de git compartilhados em clusters unificados, corrigindo assim a inflação de popularidade e revelando milhares de relações de fork — incluindo famílias de múltiplos forks e raízes não provenientes do GitHub — que são invisíveis para grafos específicos de plataforma.

Autores originais: Audris Mockus

Publicado 2026-06-30

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Audris Mockus

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine toda a história do desenvolvimento de software como uma biblioteca enorme e caótica. Nesta biblioteca, existem milhões de livros (repositórios). Mas aqui está o detalhe: muitos desses livros são apenas fotocópias da mesma história original.

No mundo da programação, isso é chamado de forking (bifurcação). Um desenvolvedor pega um projeto existente, o copia e inicia sua própria versão. Ele pode alterar algumas linhas aqui ou ali, mas o núcleo da história é idêntico.

O problema que o artigo aborda é que, se você tentar contar o quão "popular" é um pedaço de código apenas contando cada um dos livros na biblioteca, você obterá um número absurdamente inflado. Se uma história popular foi copiada 10.000 vezes, parece que 10.000 histórias diferentes estão sendo lidas, quando, na verdade, é apenas uma história sendo lida em 10.000 lugares diferentes.

Este artigo apresenta um novo mapa (uma ferramenta) que limpa esta biblioteca. Ele agrupa todas as fotocópias de volta à sua fonte original, para que os pesquisadores possam ver a história real, não o ruído das cópias.

Aqui está como eles fizeram isso, usando analogias simples:

1. O Detetive da "Página Compartilhada"

Os autores perceberam que, no mundo digital, você não consegue facilmente falsificar um histórico. Se dois livros compartilham a mesma página exata (um "commit" ou alteração específica no código), eles devem estar relacionados.

O Jeito Antigo: Eles tentaram vincular cada livro que compartilhava uma página. Mas isso era como dizer: "Se dois livros têm uma página que diz 'Copyright 2024', eles são a mesma história". Isso está errado! Muitos livros não relacionados têm a mesma página de direitos autorais. Isso fazia com que o mapa colasse histórias completamente diferentes em um grande bloco confuso e bagunçado.
O Jeito Novo: Eles construíram um mapa mais inteligente. Eles procuraram por muitas páginas compartilhadas, não apenas uma. Se dois livros compartilham um capítulo inteiro, eles são definitivamente relacionados.

2. O Filtro de "Limite de Tamanho" (O Cap)

Mesmo com o mapa mais inteligente, algumas páginas gigantes e entediantes (como contratos de licença padrão ou modelos iniciais vazios) ainda estavam atuando como pontes, conectando histórias não relacionadas.

A Correção: Os autores colocaram um limite de tamanho nessas pontes. Se uma página compartilhada aparece em mais de 250 livros, eles assumem que é apenas um modelo genérico (como uma página padrão de "Termos de Serviço") e a ignoram.
O Resultado: Isso quebrou os grandes blocos confusos. De repente, o mapa mostrava famílias distintas de histórias em vez de um único superaglomerado gigante e confuso. Isso não desfez famílias reais; apenas removeu a cola que estava grudando coisas não relacionadas.

3. A Verificação da "História Real"

Os autores se preocuparam que, ao cortar esses grandes blocos, eles pudessem ter acidentalmente cortado uma história real e complexa que naturalmente tinha muitas partes (como uma história que foi traduzida em vários idiomas e depois recombinada).

O Teste: Eles olharam para o maior grupo restante em seu mapa. Descobriram que não era um erro; era uma história real e complexa onde um grande projeto havia genuinamente absorvido partes de outros projetos famosos (como um sistema operacional importante incorporando código de um navegador web).
A Decisão: Como esse grupo "residual" era feito de uma história real e profunda, e não de uma cola barata, eles decidiram não cortá-lo mais. Eles o deixaram intacto porque ele representa um relacionamento verdadeiro e complexo no mundo do software.

4. Verificando Contra a "Lista Oficial"

Para garantir que seu mapa fosse preciso, eles o compararam com a "Lista de Forks" oficial do GitHub (uma lista onde os usuários clicam manualmente no botão "Fork").

A Correspondência: Quando olharam para projetos que existiam tanto em seu mapa quanto na lista do GitHub, eles coincidiram 99% das vezes.
A Surpresa: O mapa deles encontrou coisas que a lista do GitHub deixou passar!
- Famílias de Cross-Forge: Eles encontraram famílias de projetos que começaram no GitHub, mas foram copiados para o GitLab, Bitbucket e outros sites. A lista do GitHub só vê o lado do GitHub; este mapa vê toda a árvore genealógica através da internet.
- Forks Desconectados: Eles encontraram projetos que começaram como cópias, mas depois reescreveram completamente seu histórico, de modo que não estão mais conectados ao original. O mapa identificou corretamente esses projetos como entidades separadas, enquanto a lista oficial poderia ainda considerá-los conectados.

5. Por Que Isso Importa

Antes deste mapa, se você quisesse saber quantos projetos diferentes um único programador trabalhou, você poderia obter um número falso como "5.000 projetos" apenas porque ele trabalhou em um projeto popular que teve 5.000 cópias.

A Correção: Este mapa corrige isso. Ele diz que o programador realmente trabalhou em 5 projetos distintos, não 5.000.
O Resultado: Ele fornece uma visão limpa e precisa do mundo do software, separando as histórias originais das fotocópias e, até mesmo, detectando histórias que abrangem diferentes sites.

Em resumo: Os autores construíram uma ferramenta que desembaraça a rede confusa de códigos copiados. Eles usaram um "limite de tamanho" para impedir que projetos não relacionados grudem uns nos outros, verificaram seu trabalho contra registros oficiais e descobriram que o mundo do software é ainda mais interconectado entre diferentes sites do que sabíamos anteriormente. Eles lançaram este mapa para que qualquer pessoa possa usar, garantindo que estudos futuros sobre a história do software não sejam enganados pelo volume massivo de cópias.

Resumo Técnico: Desforkando o Mundo do Código

Definição do Problema
A mineração de repositórios de software em escala global é fundamentalmente comprometida pelo forking (bifurcação). Quando um único histórico upstream é copiado para milhares de repositórios derivados, as métricas padrão baseadas em contagens brutas de repositórios (como dispersão de autores, tamanho do projeto e fan-out de dependências) tornam-se infladas em ordens de magnitude. Uma abordagem ingênua de "desforkar" — fundir repositórios que compartilham o histórico git — falha catastroficamente porque funde excessivamente softwares não relacionados. Isso ocorre quando grupos de commits trivialmente compartilhados (ex: commits vazios, scaffolding inicial idêntico ou arquivos de licença/CI de boilerplate) atuam como "hubs" que conectam famílias de forks disjuntas em clusters gigantes e sem sentido. Este fenômeno espelha os problemas de fusão excessiva encontrados na desambiguação de identidade de autores.

Metodologia
O artigo apresenta um mapa de desforkagem curado para a coleção World of Code (WoC) V2604, estendendo uma abordagem anterior de commits compartilhados para um conjunto de dados de 5,87 bilhões de commits e 116 milhões de repositórios. A metodologia envolve três estágios primários:

Codificação de Hub-Node por Star Encoding: Em vez de conectar repositórios que compartilham um commit como um clique quadrático ( $O(N^2)$ ), os autores materializam a relação de commit compartilhado como um grafo bipartido. Para cada conjunto distinto de repositórios que compartilham um commit idêntico, um único nó "hub" é criado, conectado via arestas a todos os repositórios participantes. Isso lineariza a codificação para $O(N)$ .
Clustering de Louvain Paralelo: O grafo bipartido resultante é agrupado usando Louvain Paralelo (PLM) para identificar comunidades. O representante canônico de cada comunidade (excluindo os nós hub) torna-se o projeto desforkado $P$ .
Capping Estrutural (Limitação de Tamanho): Para evitar a fusão excessiva causada pelos hubs de boilerplate, os autores introduzem um limite de tamanho determinístico ( $C$ ). Durante a construção do grafo, qualquer grupo de commits compartilhados que exceda o tamanho $C$ é descartado antes da atribuição de nós. Isso remove "hubs gigantes" que servem de ponte entre famílias não relacionadas, preservando famílias de forks genuínas conectadas por muitos grupos menores de commits compartilhados. Os autores testam valores de $C$ (especificamente $C=250$ e $C=500$ ) para determinar o limiar ideal.

Principais Descobertas e Contribuições

O Problema do Mega-Cluster e o Limite (Exp. D1): Sem o limite (capping), o maior cluster absorve 861.948 repositórios. Aplicar um limite de $C=250$ reduz o maior cluster para 183.654 repositórios (uma redução de 78,7%) e colapsa a cauda de clusters massivos (de 13 clusters $\ge 10^5$ membros para apenas 1). Crucialmente, este limite não destrói famílias de forks genuínas; a contagem de famílias de múltiplos repositórios permanece estável (aumentando ligeiramente de 14,34M para 14,35M), indicando que o limite corta as pontes entre famílias em vez de despedaçar as próprias famílias.
Análise Residual (Exp. D2): Um diagnóstico estrutural usando centralidade de intermediação (betweenness centrality) no maior cluster limitado revela que o "residual" restante não é um artefato de agrupamento, mas sim um histórico compartilhado genuíno. Os nós de alta intermediação são repositórios agregadores (ex: qtwebengine-chromium, mono-repos do Debian) que genuinamente incorporaram (vendored) históricos upstream. Diferente de grafos de identidade de autor onde um corte estrutural dissolve o mega-cluster, cortar os principais nós de intermediação no grafo de projetos reduz o cluster em apenas ~20%, confirmando que o residual é uma teia densa de histórico compartilhado real que não deve ser removida cirurgicamente.
Impacto nos Sinais de Desenvolvedor (Exp. D3): O limite restaura significativamente o sinal de "dispersão" (spread) (o número de projetos distintos que um autor toca). O desforking sem limite colapsa a média de dispersão de 89,6 para 4,4, efetivamente apagando o sinal para autores prolíficos de múltiplos projetos. O limite de $C=250$ restaura a média de dispersão para 38,2 e recupera a contagem de autores com $>1.000$ projetos de 15 para 2.213, enquanto ainda colapsa os forks genuínos.
Validação Externa (Exp. D4): O mapa é validado contra o grafo de forks declarado do GitHub (reconstruído a partir de GHArchive ForkEvents). Dado que ambos os endpoints existem no WoC, há um acordo de aresta de 99,01% entre o desforking baseado em commits e os forks declarados pelo GitHub. A divergência restante de 0,99% consiste em forks que divergiram completamente ou nunca compartilharam um commit, o que é o comportamento correto para um método baseado em commits. A análise também identifica 11,04% dos pais de forks declarados que o WoC ainda não ingeriu, servindo como uma métrica de completude.
Cross-Forge e Detached Forks: Como o mapa depende de commits compartilhados e não de metadados de plataforma, ele identifica famílias de forks invisíveis para grafos de plataforma única.
- Famílias Cross-Forge: 5,41% das famílias de forks abrangem múltiplas forges (ex: GitHub, GitLab, Bitbucket).
- Raízes Não-GitHub: 1,51% das famílias de forks possuem uma raiz canônica não hospedada no GitHub.
- Detached Forks: A análise identifica 455.550 arestas "hard-detached" onde um fork declarado não possui histórico de commit compartilhado com seu pai no WoC. Destas, 240.441 representam origens independentes genuínas que desenvolveram suas próprias árvores descendentes.
Lista de Exclusão Atualizada: Os autores lançam uma lista de exclusão de forks atualizada contendo 134,1 milhões de filhos (3,4× maior que a lista anterior da era GHTorrent), refinada para excluir apenas aqueles forks que não estão destacados (detached).

Significância e Alegações

O artigo afirma que este mapa de desforkagem fornece uma construção pré-requisito necessária para qualquer análise de repositórios de software em escala global, corrigindo a inflação de métricas de popularidade e dispersão causada pela multiplicidade de forks.

Os autores enfatizam que sua abordagem é complementar aos metadados de plataforma. Enquanto os grafos de plataforma (como o do GitHub) registram apenas forks criados via ações de interface dentro de uma janela específica, esta abordagem baseada em commits recupera relações de fork que abrangem diferentes forges e sobrevivem ao desprendimento do histórico. O mapa captura famílias de forks "apenas do WoC" que os grafos de plataforma não podem representar.

Os autores declaram explicitamente que o mapa sem limite (atualmente distribuído pelo WoC) deve permanecer intacto em relação ao mega-cluster "residual", pois o diagnóstico estrutural prova que ele representa um histórico incorporado (vendored) genuíno e não um artefato; no entanto, eles recomendam o mapa com limite ( $C=250$ ) para adoção futura para eliminar a fusão excessiva de boilerplate, observando que a versão sem limite atualmente em circulação sofre com a fusão excessiva de projetos não relacionados conectados por commits triviais compartilhados.

Todos os artefatos, incluindo os mapas de desforkagem, variantes com limite, listas de exclusão de forks e código de replicação, são liberados como um pacote autossuficiente e hospedado de forma independente, vinculado à coleção WoC V2604.

1. O Detetive da "Página Compartilhada"

2. O Filtro de "Limite de Tamanho" (O Cap)

3. A Verificação da "História Real"

4. Verificando Contra a "Lista Oficial"

5. Por Que Isso Importa

Mais como este