💻 computer science

A Global Author-Identity Map for the World of Code:62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits

This paper introduces a curated, high-precision global author-identity map for the World of Code (V2604) that resolves 106.8 million author strings into 62.7 million canonical identities across 5.87 billion commits by prioritizing the prevention of erroneous "clumping" over simple recall, thereby significantly improving the reliability of large-scale software repository analysis and scholarly author graph joins.

Original authors: Audris Mockus

Published 2026-07-08

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Audris Mockus

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the entire history of software development as a massive, chaotic library containing nearly 6 billion books (code commits). In this library, every time someone writes a page, they sign their name. But here's the problem: the signatures are a mess.

One person might sign as "Jane Doe," then "j.doe," then "jane.doe@work.com," and later as "jane@personal.org." Meanwhile, a thousand different strangers might all sign their pages as "root" or "user" or "Your Name."

If you tried to count how many unique authors there are just by looking at these signatures, you would get a wildly wrong answer. You'd think there are millions more people than there actually are (because one person looks like ten), or you'd miss that some "people" are actually just robots or bots.

This paper presents a Giant Identity Map that cleans up this library. It takes 106 million messy signatures and organizes them into 62.7 million real people.

Here is how they did it, using simple analogies:

1. The Problem: The "Mega-Cluster" Trap

The authors explain that previous attempts to fix this problem were like trying to glue together puzzle pieces based on color alone. If you just say, "If two names share a common letter or email, they must be the same person," you eventually glue millions of unrelated people into one giant, monstrous blob.

They call this a "Mega-Cluster." Imagine a library where, because everyone used the word "The" in their title, the librarian decided that every single book in the building was written by the same person. That's what happened in previous maps: they accidentally fused 3 million unrelated developers into one giant "super-author."

2. The Solution: A Six-Step Detective Pipeline

To fix this, the authors built a six-stage detective process to sort the signatures without making that giant mistake:

Step 1: The Initial Clue: They start by linking signatures that share obvious things, like the exact same email address.
Step 2: The "Bad Actor" Filter: They ignore names that are clearly generic (like "root" or "admin") or belong to robots. These are like "ghosts" in the library; they shouldn't be used to connect real people.
Step 3: The Structural Cut (The Magic Trick): This is the most important step. They looked at the connections like a map of bridges. They found a few specific "bridge" signatures that were holding together huge, unrelated groups of people. They cut those bridges. This instantly dissolved the giant "Mega-Cluster" into smaller, manageable groups.
Step 4: The Smart Classifier: They used a computer program (trained on millions of real examples) to decide if two similar-sounding names are actually the same person or just a coincidence (like two people named "John Smith").
Step 5: The Recall Recovery: After cutting the bad connections, they carefully added back some connections they had previously ignored, using a different method (looking at how names are spelled in chunks) to make sure they didn't miss too many real friends.
Step 6: The Final Labeling: They picked the "best" version of each name (usually the one with a real name and a real email) to be the official ID for that person.

3. Why This Matters: The "Bus Factor" and Productivity

The paper shows that if you don't fix these names, your math is broken. They ran several experiments to show the difference:

Counting People: Without fixing names, the library looks like it has 66% more authors than it really does. It's like counting the same person 10 times because they signed 10 different ways.
Team Safety (The Bus Factor): Imagine a project where you need to know: "If one person gets hit by a bus, does the project die?"
- Without fixing names: The project looks safe because the work is spread across 10 different "names."
- With fixing names: You realize all 10 names belong to one person. The project is actually in huge danger.
- The Result: The paper found that 96% of projects actually rely on a single person (a "Single Point of Failure"), whereas the messy data made it look like only 90% did.
Centrality (The "Most Important" People): In the messy data, the "most important" people in the network were often robots or generic accounts (like "root"). Once they fixed the names, the "most important" people were actual human developers.

4. The "Gold Standard" Check

The authors didn't just guess; they tested their map against two different "answer keys":

Human Review: A small group of humans checked if the map was correct.
GitHub Data: They used data from GitHub accounts to see if they found all the aliases.

They found that their new map is 88% precise (it rarely mixes up strangers) and 70% complete (it finds most aliases). Crucially, they proved that the old maps looked perfect (95% precise) only because they ignored the giant "Mega-Clusters" where the mistakes were hiding.

5. Connecting Code to Science

Finally, the paper suggests this map can be used as a "universal key" to connect software developers to academic researchers. Since many people write both code and scientific papers, this map could help link a developer's code to their research papers. However, they warn that this is very hard because names are so common (e.g., "John Smith" in code and "John Smith" in a paper), and you must be extremely careful not to accidentally link the wrong people.

Summary

The paper is a guidebook for cleaning up a massive, messy database of software authors. It proves that ignoring the mess leads to wrong conclusions about who is working, how productive they are, and how safe projects are. Their new map is the first one that successfully avoids the trap of gluing millions of strangers together into one giant, fake identity.

Technical Summary: A Global Author-Identity Map for the World of Code

1. Problem Statement

The paper addresses the fundamental challenge of author identity resolution in global-scale software repositories. In the "World of Code" (WoC), a single developer often commits under multiple name/email strings (aliases), while a single string (e.g., root@localhost or Your Name <you@example.com>) is frequently reused by thousands of distinct developers.

The core difficulty lies in balancing recall (merging all aliases of one person) with precision (avoiding the "over-merge" of unrelated people). The authors argue that naive transitive union over shared attributes (e.g., sharing an email or name) creates "mega-clusters"—single clusters containing millions of unrelated identities. These clusters silently corrupt downstream analytics (e.g., developer counts, productivity, bus factors) and render precision metrics meaningless if the conflated region is not measured. Previous global maps achieved high recall but suffered from massive over-merging, while recall-only benchmarks failed to penalize this conflation.

2. Methodology

The authors present a six-stage construction pipeline designed to produce a mega-cluster-free identity map. The process is driven by a sequence of "gating" and "cutting" operations to eliminate over-merging before attempting to recover recall.

Link Generation: Candidate "same-person" edges are generated based on exact matches of email, name, or rare shared handles. The transitive closure of these edges forms a raw union graph.
Value Gating: Identities with non-identifying attributes (generic names, placeholder emails, bot accounts) are neutralized so they cannot act as merge bridges. This is done via name-spread analysis and frequency/blacklist checks.
Structural Gating (The Critical Step): To dissolve the remaining mega-cluster, the authors compute sampled betweenness centrality on the exact union graph. They identify and cut a small set of high-betweenness "bridge" identities (approx. 2,000 IDs) that weld otherwise disjoint communities. Crucially, 98% of these bridges are "attribute-clean," meaning they cannot be removed by value-based rules alone.
Edge Classification: A logistic classifier, trained on 2.6 million free GitHub ID labels, scores candidate pairs within the remaining components. It prunes residual homonym welds (e.g., different people named "John Smith") that the structural cut isolated.
Recall Recovery: With the mega-cluster dissolved, the pipeline safely expands recall. It activates a dormant "shingle" layer (links based on shared name/email tokens) and GitHub's noreply assertions. These edges are scored by the classifier and admitted at tuned thresholds (e.g., $\tau=0.9$ for pairwise expansion, $\tau=0.8$ for map-level expansion).
Representative Selection & Classification: A canonical representative is selected for each cluster based on quality rules (favoring real names and non-generic emails). A per-identity classification is assigned (good, bad-by-attribute, local, bot, partial). Finally, a within-project resolution layer resolves low-quality IDs that are ambiguous globally but unambiguous within a single project.

3. Key Contributions and Artifacts

The paper releases WoC V2604, a curated author-identity map covering 5.87 billion commits and 106.8 million author strings, folded into 62.7 million canonical identities. The release includes four co-versioned artifacts:

a2AFullSUG (Global Alias Map): Maps raw strings to canonical IDs. It is mega-cluster free; the largest cluster contains 6,910 IDs (a single GitHub noreply identity), compared to the prior map's 3-million-ID mega-cluster.
A2clsFull (Per-Identity Classification): Tags each ID with a quality class:
- Good: Real name and email.
- Bad-by-attribute: Generic names or shared/placeholder attributes.
- Local: Machine-local addresses with real usernames.
- Bot: Automated accounts.
- Partial: Good attributes but missing one component (name or email).
P2aAFull (Within-Project Resolution): Resolves 5.3 million ambiguous IDs within the specific project where they appear, recovering 47.8% of the low-quality commit pool left unresolved by the global map.
c2AFull (Commit-to-Identity Table): Tags every commit with its resolved author and a provenance tag (g for global, B for bot, p for within-project, s for self/unresolved), allowing consumers to filter by resolution quality.

4. Results and Validation

The authors validate the map against two independent ground truths: a human-rated gold set (ALFAA, OpenStack-centric) and a large-scale recall benchmark (GitHub within-handle labels).

Precision vs. Recall Trade-off: The released map achieves Recall 0.70 and Precision 0.88 on the human gold set.
Clumping vs. Splitting: The paper introduces a distinction between splitting (failing to merge aliases) and clumping (merging strangers).
- The prior WoC map (V3) reported a precision of 0.95, but this collapsed to 0.52 when its 3-million-ID mega-cluster was counted as a single error.
- The new map reduces the largest cluster from 3,006,318 to 6,910, effectively eliminating the "unmeasured clumping" that plagued previous benchmarks.
Commit Coverage: The map resolves 73.5% of all commits into multi-ID identities. When restricted to human commits, coverage reaches 98.17% (global map + within-project layer).

5. Downstream Impact

The paper demonstrates that the choice of identity method fundamentally alters developer analytics. The authors compare three archetypes: Under-merge (raw strings), Over-merge (naive union), and Calibrated (this map).

Developer Population: Raw strings inflate the developer count by 66.6% (104M vs. 62.7M).
Productivity: Under-merging understates the output of prolific developers (p90 commits drop by 34% in raw data).
Collaboration Networks: Raw data creates spurious edges where a single person's aliases link to themselves. Aliasing removes 32% of edges in the co-project network and reveals that 36.3% of projects appearing multi-developer are actually single developers using multiple identities.
Centrality: In raw networks, top centrality nodes are often bots or placeholder IDs (e.g., root, CI bots). The calibrated map shifts these rankings to real developers, though bots remain a challenge for centrality measures.
Team Resilience: Raw data creates a "false sense of security" regarding bus factors. Merging identities reveals that 96.48% of projects rely on a single indispensable developer (vs. 90.15% in raw data), and 12 million projects previously rated as collaborative collapse to a single point of failure.

6. Significance and Broader Impact

The paper argues that clumping is the binding constraint for global-scale identity resolution, not recall. The significance of this work lies in:

Methodological Shift: Moving from "recall-only" benchmarks to a joint evaluation of splitting and clumping, explicitly measuring the size of the largest cluster.
Data Integrity: Providing a "mega-cluster-free" substrate that prevents the silent corruption of per-author aggregates.
Cross-Corpus Linking: The map serves as a necessary join key for linking software authors to scholarly records (e.g., Semantic Scholar, OpenAlex). The authors demonstrate that without mega-cluster freedom, linking software identities to academic papers results in catastrophic false positives (e.g., linking 3 million people to one paper). A pilot study using DOI anchoring successfully linked 7,246 canonical authors with high precision (1.05 scholarly IDs per author), proving the map's utility as a foundation for cross-domain entity resolution.

The authors conclude that the design choices (gate, cut topology, classify, recover recall) were forced by measured failures of simpler alternatives, and that the resulting artifacts enable bias-corrected analytics at a scale previously unattainable.