A Global Author-Identity Map for the World of Code: 62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits Audris Mockus University of Tennessee, Knoxville Knoxville, TN, USA [email protected]
arXiv:2607.06183v1 [cs.SE] 7 Jul 2026
Abstract Mining software repositories at global scale founders on author identity: the same developer commits under many name/email strings, and the same string is reused by many developers. We release a curated author-identity map for the World of Code (WoC) version V2604, covering all 5,866,595,698 commits in the collection. The release has four co-versioned artifacts: (i) a global alias map, a2AFullSUG, that folds 106,826,059 raw author/committer strings into canonical identities; (ii) a per-identity classification, A2clsFull, tagging each id as good, bad-by-attribute, local, bot, or partial; (iii) a within-project resolution table, P2aAFull, that recovers low-quality ids inside the single project where their reuse is unambiguous; and (iv) a commit-to-identity table, c2AFull, that tags every commit with the provenance of its resolution. The map is mega-cluster free; its largest cluster is 6,910 ids, a single GitHub noreply identity. It resolves 73.5% of all six billion commits into a multi-id identity, raising human-id commit coverage to 98.17%. The central design problem is clumping rather than recall: the naive transitive union over shared-attribute edges welds three million unrelated people into one cluster, an over-merge that recall-only benchmarks price at zero. We therefore report both error families (splitting and clumping) and show that the high precision claimed by global-scale union maps can be an artifact of never measuring the conflated region. Against the ALFAA human-rated gold set the released map scores recall 0.70 / precision 0.88 with a largest cluster of 6,910, where the prior WoC map’s apparent precision of 0.95 collapses to 0.52 once its 3,006,318-id mega-cluster is counted. Finally, a canonical software-author identity is a join key across corpora: we discuss linking these 6.3 × 107 canonical developer identities (folded from 108 raw ids) to scholarly author graphs (1.1 × 108 Semantic Scholar and the OpenAlex authors), a setting where clumping, not recall, is again the binding constraint. All artifacts ship with the WoC V2604 release and a self-contained replication package.
Keywords author identity, alias resolution, mining software repositories, World of Code, data set
1
Introduction
Authorship is the join key of empirical software engineering: contribution counts, bus-factor estimates, developer-network studies, and provenance analyses all key on who authored a commit. In a single repository the author string is a serviceable key. Across the whole of public version control it is not. A developer signs commits as Jane Doe <[email protected]>, jdoe <[email protected]>, and
Jane <[email protected]>; conversely a thousand strangers all commit as root@localhost or Your Name <you@ example.com>. Resolving these (merging the aliases of one person without welding strangers together) is the author de-aliasing problem, and it grows qualitatively harder with scale: at 108 identities a single careless transitive merge can fuse millions of unrelated people into one “mega-cluster.” The World of Code (WoC) [12] is a periodically updated census of public version control, deduplicated at the git-object level. Its V2604 release records 5,866,595,698 commits authored under 106,826,059 distinct author/committer strings. We release a curated author-identity map over this collection and the supporting tables a consumer needs to use it correctly: a per-identity quality classification, a within-project resolution layer for the ids the global map cannot safely merge, and a commit-level table that records, for every one of the six billion commits, how its author was resolved. This paper is a data description. Section 2 specifies the four artifacts: their schemas, sizes, and access. Section 3 describes the production pipeline that builds them. Section 4 is the paper’s argument: every non-obvious choice in that pipeline was forced by a measured failure of the simpler alternative, and we summarize the eighteen-experiment record (logged in full in the companion methodology paper [13]) that establishes them. Section 5 reports external validation, develops the splitting/clumping distinction, and argues that the precision claimed by global-scale union maps is unmeasured clumping. Section 6 quantifies how the choice of map shifts downstream analytics—developer counts, productivity, team resilience, and centrality. Section 7 turns to broader impact: using the map as a join key across corpora to link software authors to their scholarly publications. Sections 8–10 give usage, limitations, and conclusions. What is new relative to prior WoC identity maps. Earlier WoC releases shipped alias maps built by string-similarity union (the ALFAA lineage [1, 8]). Those maps achieved high recall but at the cost of large over-merged clusters that silently corrupt any perauthor aggregate (Section 4). The map released here is the first WoC author map that is simultaneously (a) mega-cluster free by construction, (b) shipped with a per-id quality classification and a within-project fallback, and (c) validated on two independent ground truths read jointly for precision and recall. Research questions. Beyond releasing the artifacts, the paper answers four questions about author identity at global scale: RQ1 What does it take to build a global author map that is simultaneously high-recall and free of over-merge? (Section 4)
Conference’17, July 2017, Washington, DC, USA
Audris Mockus
Table 1: Released artifacts (WoC V2604). Artifact
Record (;-separated)
a2AFullSUG A2clsFull P2aAFull c2AFull
rawId;canonicalId member;canonical;class project;rawId;A;rule commit;A;prov
Rows / size
Class
106,826,059 ids 106,826,059 ids 5,359,181 asgmts 5,866,595,698 cmts
RQ2 How should a disambiguation result at this scale be evaluated, given that the dominant benchmarks measure only one of the two error families? (Section 5) RQ3 How much, and in which direction, does the choice of identity method change the downstream developer analytics that consume it, across realistic scenarios (head-count, productivity, bus factor, collaboration networks, centrality, reviewer/successor recommendation)? (Section 6) RQ4 Can a calibrated, mega-cluster-free map serve as a join key across corpora, linking software authors to the scholarly record, where clumping, not recall, is the binding constraint? (Section 7) RQ3 is the question a practitioner faces when deciding whether aliasing is worth the trouble; we answer it by comparing three method archetypes (under-merge, over-merge, calibrated) on the same corpus and showing the first two err in opposite directions on every task.
2
Table 2: Per-id quality classes (A2clsFull).
The Dataset
The release comprises four gzip-compressed, ;-separated, LC_ALL=C sorted tables, all keyed to WoC version V2604 and sharded for parallel access. Table 1 summarizes them. (1) Global alias map a2AFullSUG.. The core artifact (the SUG suffix records its edge composition: shingle union plus ghid, defined in Section 3). Each row maps a raw author/committer string to its canonical representative A (the highest-quality member of its identity cluster, selected by a deterministic rule favoring a real name and a non-generic email). An id that is its own representative maps to itself. The map induces an equivalence relation: two raw ids are the same person iff they share a canonical A. The map is mega-cluster free (largest cluster 6,910 ids, itself a single GitHub noreply identity, and the >10k size bin is empty), so per-author aggregates computed over it are not silently contaminated by an over-merge. (2) Per-identity classification A2clsFull. For every id, its canonical representative and a quality class under a five-way taxonomy (Table 2). The class tells a consumer why an id is or is not a global representative: good ids carry a real name and email; bad-byattribute ids carry a generic name or a shared/placeholder attribute; local ids carry a machine-local address with a real username; bot ids are automated accounts; partial ids are otherwise-good but carry only one of name/email. The three non-good, non-bot classes are the 5.46M ids the global map declines to merge across projects and instead maps to self: the pool the within-project layer targets.
Ids
Share
good bad-by-attribute local bot partial
100,814,372 2,652,369 2,562,118 553,736 243,464
94.37% 2.48% 2.40% 0.52% 0.23%
total
106,826,059
100%
Commit−resolution provenance (human coverage 98.17%)
g global map 91.53%
0%
20%
40%
B bot 1.59% 1.74% 5.14%
60%
80%
100%
Share of 5.87B V2604 commits
Figure 1: How every one of the 5,866,595,698 V2604 commits is resolved, by provenance tag. The global map carries the bulk; the within-project layer adds the harder ids it cannot safely merge, lifting human-id coverage to 98.17%.
(3) Within-project resolution P2aAFull. An id that is ambiguous across projects (root, ubuntu, user@laptop) is usually unambiguous within the single deforked project where it appears, because reuse there is local. This table assigns such an id to a canonical person inside one project, with the rule field recording how: anchor (a unique lowercased full-name or email-local-part match to exactly one already-resolved person in the project) or solo (the project has a single committing person). It holds 5,359,181 assignments (2,355,347 anchor + 3,003,834 solo), recovering 47.8% of the low-quality commit pool the global map leaves unresolved. (4) Commit-to-identity table c2AFull. The consumer-facing join: for every one of the 5,866,595,698 V2604 commits, its resolved author A and a one-character provenance tag recording how the resolution was obtained: g global map, B bot, p within-project, s self/unresolved. The provenance distribution is 𝑔 = 91.53%, 𝐵 = 5.14%, 𝑝 = 1.59%, 𝑠 = 1.74%. The tag lets a study filter to the resolution quality it needs (e.g. drop B, keep g+p, treat s as unknown) without re-deriving anything (Figure 1). Access and format. All tables are part of the WoC V2604 release and follow WoC conventions: gzip, ;-separated, LC_ALL=C sorted on the first field, section-sharded 0..127 (maps) or 0..31 (derived) by a stable hash of the key for parallel scans. A self-contained replication package (Section 3) accompanies the release.
3
Construction
The map is built by a six-stage pipeline over the WoC V2604 commit data (Figure 2). We state the pipeline here as the data description; Section 4 justifies each stage. (1) Link generation. From every commit, emit candidate sameperson edges between author/committer strings that share evidence (exact email, exact name, or a shared rare handle). The transitive closure of these edges is the raw union.
A Global Author-Identity Map for the World of Code: 62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
Conference’17, July 2017, Washington, DC, USA
shingle-expansion variants contribute on disjoint margins and compose (Exp. 17), each admitted at a separately tuned threshold: the pairwise expansion v1 at 𝜏=0.9 (the largest single recall gain in the record) and the map-level expansion v2.1 at 𝜏=0.8 (at 0.9 the map-level variant sacrifices GitHub recall). This is the production edge set: [email protected] ∪ [email protected] ∪ ghid, whose composition is what the map’s SUG suffix records (shingle union + ghid). (6) Representative selection and classification. Choose a canonical representative per cluster by a quality rule (streaming, to bound memory); emit a2AFullSUG and A2clsFull. Resolve the self-mapped low-quality pool inside individual projects (P2aAFull); tag every commit with provenance (c2AFull).
commits (V2604): author/committer strings
1. Link generation shared email/name/handle → raw union (transitive closure)
2. Value gating neutralize bad-attribute bridges (name-spread + blacklist)
precision: cut over-merge
3. Structural gating betweenness cut of bridge ids → dissolves the mega-cluster
4. Edge classification logistic, 2.6M free ghid labels admit + prune homonym welds
recall: buy it back
5. Recall recovery shingle [email protected] ∪ [email protected] ∪ ghid (the SUG edge set)
6. Representative selection + within-project resolution
a2AFullSUG · A2clsFull P2aAFull · c2AFull
Figure 2: The six-stage construction. Value, structural, and edge gating (orange) attack over-merge; recall recovery (green) then admits the shingle and ghid edges that the precision work held out, yielding the released a2AFullSUG map and its companions.
(2) Value gating. Neutralize ids whose attributes cannot identify a person (generic names, placeholder and shared emails, bot accounts) so they do not act as merge bridges. Detection is by name-spread and a frequency/blacklist battery. (3) Structural gating. On the exact union graph, compute sampled betweenness and cut the small set of high-betweenness “bridge” ids that weld otherwise-disjoint communities. This dissolves the over-merged mega-cluster that value gating alone cannot. (4) Edge classification. Score every candidate within-group pair with a logistic edge classifier (features: shared-attribute spread, name↔handle patterns, given-name-homonym flag, deforked project overlap), trained on 2.6M free within-handle GitHub-id labels. Admit confident pairs; prune residual homonym welds. (5) Recall recovery. Expand the dormant cross-project shingle layer (candidate same-person links proposed by shared name/email token shingles but held out of the base union) into member pairs, score each with the classifier, and admit confident pairs as new union edges; union with GitHub’s own noreply same-account assertions. Two
The pipeline runs as WoC SLURM jobs over the section-sharded commit tables. The replication package ships the complete script set: link generation and gating, bad-attribute detection, the C++ structural toolchain (betweenness/bridge cut), the classifier training and scoring, the union and map builders, the within-project matcher, and the evaluation harness.
4
Design Rationale
Every non-default choice above replaced a simpler alternative that we measured to fail. The full record is eighteen experiments [13]; Table 3 maps each production decision to the experiment that forced it. Two findings frame the rest: at 108 ids de-aliasing is two problems, precision (do not over-merge) and recall (do not miss aliases), and they must be solved in that order, because a recall mechanism applied to an over-merged graph only makes the mega-cluster worse. The over-merge phenomenon. The naive transitive union over all shared-attribute edges produces a single cluster of roughly three million identities: real people fused by a mesh of generic strings. Any per-author metric computed over such a map is meaningless for everyone in the cluster, and the cluster is invisible to recall-only evaluation. Removing it is the precision problem, and it resisted every mechanism that acts on nodes or values: information-score cutoffs collapsed recall (Exp. 2); project-spread and link-degree gates preserved recall but slow-peeled, each threshold merely exposing the next moderate bridge (Exps. 3–4); and exhaustive neutralization of every detectable bad attribute left the mega 94% intact, because a redundant mesh of moderately-bad values re-closes around each removed weld (Exps. 8–10). Two changes of object. What worked was changing the unit of analysis. First, from nodes to topology: a sampled-betweenness cut of the exact union graph located the ∼2,000 load-bearing ids whose removal disconnects the welded communities, 98% of them attribute-clean and so invisible to any value rule (Exp. 11). Second, from values to edges: a classifier trained on 2.6M free within-handle GitHub-id labels scored candidate pairs and pruned the residual given-name homonym fragments the cut had isolated (Exps. 6, 12). Only with the mega gone was recall safe to attack: the same classifier, filtering the pairwise expansion of the previously dormant cross-project shingle layer, recovered in one experiment more recall than the entire record had spent, and composing it with GitHub’s
Conference’17, July 2017, Washington, DC, USA
Table 3: Production decisions and the experiment that justifies each (full log in [13]). Production decision
Justifying finding
Gate before unioning
Ungated union welds a 3M-id mega-cluster. Score cutoffs destroy recall (Exp. 2). Spread/degree gates slow-peel; neutralizing every bad attribute still leaves the mega 94% intact (Exps. 3–4, 8–10). Sampled betweenness finds ∼2k bridge ids, 98% attribute-clean, and dissolves the mega (Exp. 11). A classifier on 2.6M GitHub-id labels prunes the homonym fragments the cut isolates (Exps. 6, 12). Largest single recall gain in the record; precision rises (Exp. 14). At 𝜏=0.5 the mega returns: a cut certifies the edge set it saw, not the design (Exp. 14). v1, v2.1, and ghid gains live on disjoint margins and compose (Exp. 17). Recovers 47.8% of the low-quality pool the global map declines (Exp. 18). A recall-only GT prices a 3M mega at zero and ranks maps in reverse of a precision audit (Exps. 13, 16).
Do not gate on information score Value gating is necessary but insufficient
Add a structural cut
Resolve residue with an edge classifier, not more value rules Recover recall by classifier-filtered shingle expansion at 𝜏=0.9 Re-check structure after adding edges Compose multiple edge sources
Add a within-project layer
Grade on two benchmarks jointly
own noreply account assertions finished the job (Exps. 14, 17), while precision rose. Transferable lessons. Four findings generalize beyond this dataset and motivate the artifacts we ship. (i) Structural certificates do not transfer: a cut computed on one edge set silently fails on an augmented one, so the production pipeline re-checks the mega-cluster histogram after every new edge source. (ii) Constructed labels embed shortcuts: a gradient-boosted classifier read the users.noreply. github.com substring out of the label construction and collapsed on human labels (0.999 in-distribution AUC, 0.56 transfer), where a linear model on the same feature was benign; the shipped classifier is therefore logistic, selected by out-of-distribution transfer, not in-distribution accuracy. (iii) Bad values split by intent: privacy masks and homonym defaults demand the same non-merge action for opposite reasons, and only the former may never be relinked, hence the bad-by-attribute/local distinction in A2clsFull. (iv) Benchmarks are directional: a precise-but-small human gold and a recall-only GitHub-scale GT rank maps oppositely, so we grade on both and ship provenance tags that let consumers choose their own precision/recall operating point.
5
Quality and Validation
We validate against two independent ground truths read jointly, plus a direct commit-coverage census. We report both error families
Audris Mockus
Table 4: Splitting and clumping on the ALFAA gold. “V3 (excl. mega)” is the prior map evaluated with its 3M-id mega-cluster removed first: the protocol that reports high precision by not counting clumping. “V3 (as shipped)” counts it. Splitting = 1−recall; clumping = 1−precision. Map
Prec.
Recall
Clump.
Largest
V3 (excl. mega) V3 (as shipped) This map (a2AFullSUG)
0.949 0.522 0.879
0.915 1.000 0.703
0.051 0.478 0.121
— 3,006,318 6,910
a partition admits, because each is invisible to a benchmark that measures only the other. Splitting vs. clumping. A clustering can fail two ways. It can split: scatter one person’s ids across several clusters (a fragmentation error); the splitting rate is 1 − recall. Or it can clump: merge distinct people into one cluster (an over-merge or conflation error); the clumping rate is 1 − precision. The two are not symmetric in how they are reported. Splitting is exposed by any within-person recall benchmark; clumping is exposed only by a benchmark that contains, and weights, the conflated region. A large literature on author disambiguation reports near-perfect precision while leaving clumping effectively unmeasured: by evaluating on curated samples that never reach the over-merged region, by reporting recall-only ground truths on which an over-merge costs nothing, or by sampling pairs in a way that under-weights a single giant cluster (whose false-pair mass grows quadratically in its size). We therefore report splitting and clumping side by side, and add a distribution-level clumping diagnostic, the largest cluster, that a pairwise average can hide. ALFAA human gold (both axes). The ALFAA pairs [1] are 469k human-rated id pairs (label 2 = match), OpenStack-centric. Table 4 (visualized in Figure 3) scores the production map against the prior WoC production map (V3) on this gold. The contrast drives this section. V3 reports recall 1.000 (zero splitting); measured after excluding its over-merged region, the protocol that “ignores clumping”, it reports a mindboggling precision 0.949. Measured on the partition as shipped, the same map’s precision is 0.522 and its largest cluster is 3,006,318 ids: 7.7% of all gold ids fall inside that one mega-cluster and 94.6% of V3’s false-positive pairs are produced by it. The “mindboggling precision” is an artifact of not counting the clumping. The production map released here trades a little recall for an honest clumping profile: splitting 0.297, clumping 0.121, largest cluster 6,910 (itself a single GitHub noreply identity). An audit of its disagreements shows the gold itself carries ∼26 mislabels (exact-email pairs rated “different”), placing its true precision nearer 0.90. GitHub ground truth (recall = splitting only). A complementary, large-scale recall benchmark derives within-handle alias labels from single-account GitHub repositories (9.57M handles over 21.5M commit ids; an independent within-handle ground truth, Bock et al., under submission [4]). It is the empirical mirror of the preceding point: it is recall-only, measuring splitting while structurally blind to clumping, because it only contains ids already known to share
A Global Author-Identity Map for the World of Code: 62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
Gold−arbiter score (clumping: lower is better)
Shipped map trades recall to crush clumping 0.949
raises this to 98.17% (+1.68 percentage points), leaving a residual unresolved fraction of 1.83%. Relative to a value-gated union (the baseline before the structural cut), gold recall rose 0.44 → 0.70 and precision rose 0.87 → 0.88, with the largest cluster down from 170,431 to 6,910.
V3 (as shipped)
1.000
1.00
V3 (excl. mega)
0.915 0.879
This map (a2AFullSUG) 0.75
0.703
0.522
0.50
0.478
6 0.25
Downstream Impact: How Aliasing Changes Developer Analytics
0.121 0.051
0.00
Precision
Recall
Clumping
Figure 3: Gold-arbiter precision, recall, and clumping (lower is better) for the shipped a2AFullSUG map against the two V3 framings (Table 4): “as shipped” counts V3’s mega-cluster, “excl. mega” removes it first.
one handle, so an over-merge (even a 3M-id mega) is priced at zero and the metric even reports the over-merge as a perfect score. Read in isolation such a benchmark ranks the mega-laden V3 above a mega-free map; read jointly with the clumping axis it is informative. On it the released map recovers recall 0.60 under the benchmark’s max9 scoring and 0.56 under its stricter FullyMerged scoring, the two recall conventions that benchmark defines [4]. This is the recall a global map can reach without local repository context; the residual gap is the within-repository evidence a global map forgoes by design, not over-merge.
5.1
Conference’17, July 2017, Washington, DC, USA
Validation (Section 5) characterizes the map’s matching quality: its splitting and clumping rates against two ground truths; this section asks a different question: how much does it matter, and to whom? We recompute a battery of standard developer-analytics measures at three points on an ablation ladder over the full World of Code commit corpus (5,866,595,698 V2604 commits), so the cost of getting identity wrong is read off directly rather than argued. Three method archetypes, two opposite errors. This section shows that the two ways of getting identity wrong distort realistic downstream analyses in opposite directions, so a consumer who picks either extreme is misled, in a predictable direction, on every task. Section 5 graded matching quality (splitting vs. clumping); here we trace those two failure families into the analytics built on top of the map. Three archetypes bracket the design space: • Under-merge (𝐿0 , raw author string 𝑎 = name+email exact): the analyst default of keying on the commit’s author string with no resolution at all. It splits one person across aliases, so it over-counts people and under-counts each person’s work. • Over-merge (naive transitive union over shared-attribute edges; the prior WoC map V3 is its shipped instance, with a 3,006,318-id mega-cluster, Table 4). It clumps strangers, so it under-counts people and welds unrelated work onto a few giant phantom identities. • Calibrated (𝐿2 , the released map): splitting and clumping both bounded, largest cluster 6,910.
Comparison with Prior Approaches
The dominant prior VCS name-disambiguation tools are stringsimilarity merges validated on small, manually disambiguated corpora, and they are the published home of the “mindboggling precision” this section cautions against. The email-network heuristic of Bird et al. [3], the merge algorithms compared by Goeminne and Mens [9], and the LSA-based identity merge of Kouters et al. [11] are evaluated on single-project or single-community corpora. The most explicit recent example is the gambit tool of Gote and Zingg [10], which reports an F1 of 0.985, on a single manually disambiguated project (Gnome GTK). The number is not in dispute; what it cannot reveal is clumping. An evaluation on a corpus that never contains a global mega-cluster measures splitting while leaving clumping untested, because the over-merged region that a 108 -id union produces is not in the sample. The same caution applies to the global WoC maps of the ALFAA lineage [1, 8]: as Table 4 shows for the ALFAA-lineage map V3, their headline precision is computed off the conflated region and so does not reveal the 3,006,318-id over-merge sitting in the same partition. We make the opposite methodological commitment (report splitting and clumping jointly, and ship a largest-cluster diagnostic), and we contend that any disambiguation result at scale that reports only one axis is, at present, untestable on the other. Commit coverage (census). Computed directly over all 5,866,595,698 commits via the c2AFull provenance tags: 73.5% of all commits resolve into a multi-id identity (up from 66.3% for the prior baseline map). Restricted to human (non-bot) commits, the global map alone covers 96.49%; adding the within-project layer
The under-merge archetype is what our 𝐿0 ablation measures directly; the calibrated archetype is 𝐿2 ; the over-merge archetype is characterized quantitatively for matching in Table 4 and its downstream direction follows from its mechanism (collapsing 𝑁 people onto one node moves every per-developer aggregate the opposite way from splitting them into 𝑁 ). Table 5 summarizes the direction of the error each archetype induces on five common downstream questions; the rest of this section supplies the measured magnitudes for the two endpoints we run end-to-end (𝐿0 and 𝐿2 ).
6.1
Developer population and productivity
Without aliasing the developer population is inflated by +66.6%: 104,394,428 raw ids collapse to 62,670,110 resolved developers (the 𝐿0 ids that author commits; fewer than the 106,826,059 author/committer strings of Table 2, because committer-only strings author nothing), so 40.0% of all raw ids are duplicate identities of someone already counted. The core map removes the bulk (−37.8%); the within-project layer folds a further 2,245,942 local ids the global map cannot place. The bias is concentrated, not uniform (Table 7): the median developer is untouched (5 commits and 1 project under raw ids or production alike), so the cost of skipping aliasing falls on the prolific tail, whose work is split
Conference’17, July 2017, Washington, DC, USA
Audris Mockus
Table 5: How each identity-method archetype distorts five realistic downstream analyses, relative to correct (calibrated) identity. “↑” = over-states the quantity, “↓” = under-states it. Under-merge and over-merge err in opposite directions on every row.
Table 8: Raw-id population stratified by class (no aliasing, 𝐿0 ). Illegitimate = bad-attribute + local + bot. Class
Downstream question
Under-merge (𝐿0 )
Over-merge (V3 union)
Calibrated (𝐿2 )
Developer head-count Commits per developer Bus/truck factor (SPOF risk) Collaboration-network density Centrality top-ranked devs
↑ +66.6% ↓ −40% ↑ (reassuring) ↓ (fragmented) bots/bad ids
↓ ↑ ↓ (alarmist) ↑ (phantom hub) the mega-cluster
≈ ≈ ≈ ≈ real devs
6.2 Table 6: Ablation ladder. Each level is recovered per commit from the provenance tag in c2AFull rather than rebuilt as a separate map. Level
Resolution
Ablates
𝐿0 𝐿1 𝐿2
raw author string 𝑎 core/global map (Exp. 17) core + within-project (Exp. 18)
all aliasing within-project layer nothing (production)
Table 7: Developer metrics under ablation. “Raw bias” compares the no-aliasing 𝐿0 view against production 𝐿2 . Perdeveloper quantities are reported as median and p90 rather than the mean, because the distributions are power-law. Metric
𝐿0 raw
𝐿1 core
𝐿2 final
Raw bias
distinct developers median commits/dev p90 commits/dev median projects/dev p90 projects/dev median span (days) p90 span (days) 1-commit “devs”
104.39M 5 65 1 7 8.1 822 25.02M
64.92M 5 95 1 9 8.0 1207 15.82M
62.67M 5 99 1 9 9.3 1243 14.92M
+66.6% ≈ −34% ≈ −22% −13% −34% +67.7%
across alias fragments, rather than on typical contributors. At the 90th percentile a raw-id study understates output by 34% (p90 commits/dev 65 vs. 99) and careers by 34% (p90 span 822 vs. 1,243 days, ∼14 months), and it invents 10.1M one-commit “developers” that are really alias fragments of established contributors. The median span moves only trivially across 𝐿0 –𝐿1 (8.1 to 8.0 days, a sub-day difference within rounding for the short-lived bulk of ids) and lifts to 9.3 only once the within-project layer stitches a person’s repeated local commits into one career; the career-extension effect of aliasing is a tail phenomenon, visible at p90, not at the median. (Per-developer means are omitted by design: with a maximum of 114.7M commits on a single id, the distribution is power-law and its mean reflects bot and mega-cluster placement, not a representative developer.)
Ids
Id %
Commit %
good bot bad-attribute local (privacy) partial
98,492,759 541,186 2,602,192 2,519,593 238,698
94.35 0.52 2.49 2.41 0.23
91.10 5.13 2.72 0.61 0.45
illegitimate
5,662,971
5.42
8.46
Bad, privacy, and bot identities
A second hazard is that the bad-attribute, privacy-local, and bot ids the map neutralizes (the last flagged with the WoC bot detector of Dey et al. [7]) would, untreated, be counted as legitimate developers. They are only 5.42% of raw “developers” but 8.46% of commits (over-represented 1.56×) and they dominate the head of any productivity ranking (Table 8): 23 of the top 100 and 169 of the top 1,000 most-prolific raw ids are illegitimate. The single busiest “developer” by commits is dependabot[bot] (114.7M commits over 5.32M projects); others masquerading as prolific humans include Your Name <[email protected]> (9.1M), Automated (6.7M), and GitHub Action (5.9M). This is the concrete payoff of the badattribute, blank, and bot guards.
6.3
The developer collaboration network
Identity errors miscount individuals, but they also deform the structure of the collaboration graph that an enormous social-network and mining literature is built on. We construct the co-project developer network at each ablation level (an undirected edge joins two developers who share at least one project), capping fan-out at 1,000 distinct developers per project to exclude the ∼3,000 mega-projects whose 𝑁 2 cliques are not meaningful collaboration (the largest raw project alone names 1,017,654 ids). The graph is large: 2.34B undirected edges at 𝐿0 . The raw network systematically overstates collaboration (Table 9). Aliasing removes 32% of all edges and cuts the apparent collaborating population from 70% to 49% of developers, because in the raw data one person’s several ids co-occurring in a project link “to themselves”: a spurious edge that vanishes once the ids merge. Among the developers who remain connected, the typical node is unchanged (median degree is 3 at every level), but the connectivity of the active tail rises (p90 degree 98 → 231) as the low-degree alias fragments that surround each real person are absorbed into a single, better-connected node. The most-connected raw node has 10.6M neighbors; after aliasing the maximum falls to 6.0M. The last row is a finding in its own right: 36.3% of projects look multi-developer in raw ids, but only 16% are after aliasing: roughly half of all apparent “collaborations” are a single person committing under several identities. The same pattern on the finer co-file network. Sharing a project is a loose notion of collaboration; co-editing the same file is a stricter one. We rebuild the network with an edge between two developers only when they both touch the same (project, file) pair (cap 1,000
A Global Author-Identity Map for the World of Code: 62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
Table 9: Co-project network under ablation (fan-out cap 1,000).
nodes (developers) connected isolated unique edges median degree (conn.) p90 degree (conn.) max degree single-dev projects
Table 11: Degree by id class in the raw (𝐿0 ) network. “Hub” = degree ≥ 1,000.
𝐿0 raw
𝐿1 core
𝐿2 final
Class
104.39M 70.0% 30.0% 2.34B 3 98 10.63M 63.7%
64.92M 52.3% 47.7% 1.61B 3 196 6.24M 82.1%
62.67M 49.0% 51.0% 1.59B 3 231 6.04M 84.0%
good bot bad-attr local
Table 10: Co-file network under ablation (edge = shared (project, file), fan-out cap 1,000). Same node universe as Table 9.
nodes (developers) connected isolated unique edges median degree (conn.) p90 degree (conn.) max degree
Conference’17, July 2017, Washington, DC, USA
𝐿0 raw
𝐿1 core
𝐿2 final
104.39M 62.3% 37.7% 2.83B 3 96 5.77M
64.92M 48.0% 52.0% 1.95B 3 198 3.58M
62.67M 45.6% 54.4% 1.92B 3 231 3.50M
co-editors per file), over the same node universe, and run the identical ablation (Table 10). The co-file graph is sparser, as expected from the stronger join: 62.3% of developers are connected at 𝐿0 against 70.0% on the co-project graph. Every aliasing effect reappears with the same sign and nearly the same magnitude. Aliasing again removes 32% of edges (2.83B→1.92B), drops the connected population from 62.3% to 45.6%, raises the active-tail p90 degree (96 → 231) as alias fragments coalesce, and lowers the maximum degree (5.77M→3.50M). That a structurally distinct, more conservative collaboration graph reproduces the co-project result rules out the deformation being an artifact of the project-membership edge rule. Bad ids hide in low-degree space. A natural objection is that the deformation is confined to a few obvious hubs that a degree threshold could delete. It cannot. Table 11 stratifies node degree in the raw network by id class: across every illegitimate class the hub fraction (degree ≥ 1,000) is under half a percent (0.38% of bots, 0.49% of bad-attribute, 0.12% of local ids), while 70–84% sit at degree ≤ 10 and a large share are fully isolated (62.5% of bots). The handful of bot hubs (the maximum-degree node in the whole graph is a bot) are what makes “bots are hubs” intuitive, yet the bot population is overwhelmingly peripheral. A centrality cutoff would miss 99.5% of each bad class; separating them requires the attribute- and name-based classifier, not a structural threshold.
6.4
Ids
isol. %
deg≤10 %
hub %
98.49M 541K 2.60M 2.52M
30.3 62.5 25.8 15.4
81.9 69.9 78.7 83.9
0.78 0.38 0.49 0.12
Centrality measures
Who, structurally, are the most important developers? Centrality on the collaboration network answers this for influence studies, key-developer detection, and knowledge-broker analyses. We rank developers in the raw (𝐿0 ) network by five standard measures (𝑘core, PageRank, eigenvector, Katz, and approximate betweenness) and inspect the class composition of the top of each ranking (Table 13). The finding is that on the un-aliased network the top of the ranking is mostly not real developers: of the 50 highest-betweenness nodes 50% are bots or bad-attribute placeholders, rising to 60% for PageRank, 64% for eigenvector, and 68% for Katz centrality: the shared-placeholder ids (root, your-name, CI bots) sit between otherwise unconnected projects and so look like the graph’s most important brokers. The one exception is 𝑘-core, whose top 50 are all legitimate: degeneracy ordering rewards dense mutual collaboration, which placeholder hubs (high degree but tree-like, not clique-like) do not have, a useful robustness contrast. This is the centrality-space face of the same contamination Table 11 shows in degree space: illegitimate ids are not removable by a degree threshold, and on four of five centrality measures they dominate the top ranks an analyst would read first. Running the same rankings on the aliased networks (𝐿1 , 𝐿2 ) shows that aliasing reduces but does not eliminate the contamination, and reveals why (Table 13). Where the residue is bad-attribute placeholders the merge clears them: approximate betweenness falls from 50% to 38% non-legitimate and eigenvector from 64% to 48% as the shared your-name-style ids that bridged unrelated projects coalesce. But the bulk of the residue is bots, and a CI bot is a genuinely distinct automated account, not a human alias, so the map correctly does not merge it: the bot count in the betweenness top 50 falls only from 16 to 13, and on PageRank and Katz, where bots already dominate, the non-legitimate share barely moves (60% → 58%, 68% → 62%). The lesson reinforces the degree-space one: the alias map fixes the human-fragmentation half of the problem, but cleaning a centrality ranking still needs the bot/bad-attribute classifier, not the map alone and not a structural threshold. The headline holds throughout: centrality on raw identities ranks the noise above the signal. Centrality on the co-file network. Repeating the centrality ablation on the finer co-file graph (Table 12) shows the same contamination, generally milder: co-editing a file is a stronger collaboration signal than sharing a project, so placeholder ids that merely cooccur in projects rarely co-edit the same file. Two measures are already robust at 𝐿0 : 𝑘-core (0%) and, unlike on the co-project graph, eigenvector (2%), whose mass concentrates on dense file-coediting
Conference’17, July 2017, Washington, DC, USA
Audris Mockus
Table 12: Illegitimate-id share of the top-50 developers on the co-file network across the ablation ladder (cf. Table 13 for co-project). Contamination is milder than on the co-project graph and eigenvector is robust here. Centrality measure
𝐿0
𝐿1
𝐿2
𝐿0 make-up
𝑘-core (degeneracy) Eigenvector PageRank Katz Approx. betweenness
0% 2% 60% 58% 50%
4% 4% 50% 38% 36%
0% 4% 50% 38% 28%
50 good 49 good, 1 bad-attr 20 good, 20 bot, 10 bad-attr 21 good, 23 bot, 6 bad-attr 25 good, 14 bot, 11 bad-attr
Table 13: Illegitimate-id share of the 50 top-ranked developers on the co-project network under five centrality measures, across the ablation ladder. “Non-legit. %” counts bot and badattribute ids among the top 50; the last column gives the raw (𝐿0 ) make-up. Centrality measure
𝐿0
𝐿1
𝐿2
𝐿0 make-up
𝑘-core (degeneracy) Approx. betweenness PageRank Eigenvector Katz
0% 50% 60% 64% 68%
2% 42% 62% 48% 62%
0% 38% 58% 48% 62%
50 good 25 good, 16 bot, 9 bad-attr 20 good, 21 bot, 9 bad-attr 18 good, 28 bot, 4 bad-attr 16 good, 26 bot, 8 bad-attr
teams rather than placeholder stars. PageRank and Katz are contaminated in the raw network (60%, 58%) and aliasing reduces both (to 50% and 38% at 𝐿2 ), with the same bot-dominated residue as on the co-project graph. Approximate betweenness on this 2.83billion-edge network starts at the same 50% contamination at 𝐿0 but cleans further than on the co-project graph as aliasing proceeds, falling to 36% at 𝐿1 and 28% at 𝐿2 ; the raw top-50 holds 14 bots and 11 bad-attribute placeholders, and the map clears the placeholders while the bots, not an aliasing target, persist.
6.5
Team resilience: bus/truck factor, reviewers, and successors
Three of the most common operational questions a project-analytics system answers are: who are the few people the project cannot afford to lose (bus or truck factor [2]), who is qualified to review a change (reviewer recommendation), and who could take over a departing contributor’s work (successor recommendation). All three are computed from the same substrate (how commits concentrate on developers) and all three are distorted in the same direction by identity fragmentation. We compute a commit-concentration bus factor for all 189.9M projects at each ablation level: the minimum number of developers whose cumulative share first reaches 50% of the project’s commits. Under-aliased ids (𝐿0 ) split one person’s work across several identities, so each holds fewer commits and the project appears to spread its knowledge over more people than it really does: an inflated, falsely reassuring bus factor. Because merging identities can only concentrate commits onto fewer developers, the bus factor is monotone non-increasing along the ablation ladder: every change is a correction in the same direction (Table 14).
Table 14: Bus/truck factor under ablation. bf=min developers covering 50% of a project’s commits; solo=projects with one distinct developer; SPOF =single point of failure (bf= 1).
projects SPOF (bf= 1) solo (1 developer) projects with bf≥ 2
𝐿0 raw
𝐿1 core
𝐿2 final
189.86M 90.15% 63.71% 18.71M
189.86M 96.05% 82.15% 7.49M
189.86M 96.48% 83.97% 6.68M
Table 15: Bus/truck factor at the file granularity, over all 7.49B (project, file) pairs. solo=files touched by one distinct developer; multi=files that appear to have ≥ 2.
spof (bf= 1) solo (1 developer) apparent multi-dev
𝐿0 raw
𝐿1 core
𝐿2 final
91.14% 85.06% 14.94%
94.84% 90.19% 9.81%
95.07% 90.58% 9.42%
The correction is large and one-directional. The share of projects resting on a single indispensable developer rises from 90.15% to 96.48%, and the count of projects that appear to have a bus factor of two or more falls from 18.71M to 6.68M. Equivalently, 12.0M projects (64.3% of every project the raw data rates as collaborative) collapse to a single point of failure once aliases are merged: projects an analyst would wrongly judge “safe.” Most of the correction comes from the global core map (𝐿0 → 𝐿1 , solo 63.7% → 82.2%), with within-project matching adding the rest (𝐿1 → 𝐿2 , → 84.0%). The solo-project share, reached here from commit concentration, independently matches the 84.0% obtained from the collaboration graph (§6.3). Two different computations converge on the same fact: roughly a fifth of all projects that look multi-developer are one person under several identities. File-level resilience. The project-level bus factor is a coarse instrument: reviewer and successor recommendation operate at the granularity of the individual file, not the whole project. We therefore recompute the same concentration measure over every (project, file) pair in WoC (7.49 billion units) at each ablation level (Table 15). The pattern is identical in direction and, because files have far fewer touching developers than projects, even more sharply concentrated: the share of files edited by a single developer rises from 85.06% (𝐿0 ) to 90.58% (𝐿2 ), and the apparent multi-developer share is nearly halved, 14.94% → 9.42%. As at the project level the correction is overwhelmingly the global core map (𝐿0 →𝐿1 ), with within-project matching trimming the residue. Reviewers and successors. The same fragmentation that inflates the bus factor degrades reviewer and successor recommendation, because both rank candidates by accumulated experience on the relevant files or project. When a contributor’s history is scattered across aliases, three failures follow. (i) A genuine expert can be passed over: each of their aliases looks like a newcomer below the experience threshold, so a less-qualified “whole” id is recommended instead. (ii) A recommended reviewer and the author can be the
A Global Author-Identity Map for the World of Code: 62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits
same person under two emails, a self-review the system cannot detect. (iii) For successor recommendation the error is sharpest: a developer who merely changed their email looks like they left while a stranger arrived, firing a spurious succession event and proposing a successor for work whose author never departed. The file-level ablation lets us put a number on each of these failures rather than merely assert them. (i) Of the 1.12 billion files that appear multi-author in the raw data (ndev𝐿0 > 1), 36.95% (413.6M files) resolve to a single person once aliases are merged: a “whole” expert who, before aliasing, presents as several sub-threshold newcomers. (ii) Of the 4.56 billion adjacent author hand-offs in file histories (consecutive commits attributed to different raw ids), 28.10% (1.28B) are phantom self-reviews (the same canonical developer under two emails), and only 71.90% (3.28B) are real hand-offs that survive aliasing. (iii) 307M files (4.10%) fire a phantom succession event: the apparent last author before the project’s most recent contributor is, after aliasing, that very contributor, so the successor model would propose replacing a developer who never left. These are not corner cases; they are the dominant failure mode of file-history analytics run on raw identities. Consistent with the within-project matching that produces them (§3), which alone reattributes 93.4M commits (47.8% of the low-quality pool) to a developer already active in the same project, correct identity is a precondition, not a refinement, for any of these tasks.
6.6
Threats to validity (downstream comparison)
The directional claim of Table 5 (that under-merge and over-merge bias every analysis in opposite directions) rests on two kinds of evidence with different strength, and we are explicit about which is which. Construct. The two endpoints we run end-to-end are 𝐿0 (under-merge) and 𝐿2 (calibrated); their magnitudes are measured over the full corpus. The calibrated reference 𝐿2 is itself imperfect (at recall 0.70 it still leaves some of one person’s aliases split), so every under-merge bias reported against it is a conservative lower bound: the gap to error-free identity is at least as large as shown, never smaller (a still-split 𝐿2 over-counts developers, so the true head-count inflation exceeds the measured +66.6%). The over-merge column is directional, not a re-run of V3 through the same analytics: its sign follows deductively from its mechanism (collapsing 𝑁 distinct people onto one identity moves each perdeveloper aggregate monotonically opposite to splitting one person into 𝑁 aliases), and its one anchored magnitude is the 3,006,318-id mega-cluster of Table 4. Materializing the numeric over-merge column by pushing V3 through this same ablation is the natural next step and would convert each “↑/↓” into a number. Internal. 𝐿1 is recovered per commit from the provenance tag rather than rebuilt as a separate map, so a commit resolved only by within-project matching reverts to its raw id under 𝐿1 (Table 6); this is exact, not an approximation, but it means 𝐿1 is a lower bound on what a core-only map recovers. External. The collaboration network uses a fan-out cap of 1,000 co-developers per project (Table 9), which truncates the few mega-projects and so under-states, not over-states, the density gap; the centrality ablation is complete across 𝐿0 /𝐿1 /𝐿2 on both the co-project (Table 13) and co-file (Table 12) networks. None of these
Conference’17, July 2017, Washington, DC, USA
threatens the sign of the comparison, which is the paper’s claim; they bound its magnitude.
7
Broader Impact: Linking Software Authors to Scholarship
A canonical software-author identity is useful inside software engineering, but its larger promise is as a join key across corpora. The people who write code also write papers, datasets, and documentation; tying a developer’s WoC-scale software identity to their scholarly record would let us trace research-software provenance, measure the scientific impact of code, credit research-software engineers, and study how software and the literature that describes it co-evolve. Two large scholarly author graphs make this concrete. OpenAlex and the Semantic Scholar author graph each enumerate on the order of 108 authors with names, affiliations, external identifiers (ORCID, DOI/DBLP linkages), and publication/citation counts. A local extract of the Semantic Scholar graph holds 111,255,251 authors (authorid, name, aliases, affiliations, paper/citation counts, ℎ-index), the same order of magnitude as the WoC identity space released here (1.07 × 108 raw ids, folding to 62.67M canonical developers). Linking the two is an entity-resolution problem at the 108 scale [5], which aliasing first reduces on the WoC side to those 62.67M canonical identities — matching the raw strings directly would reintroduce exactly the clumping the map exists to prevent. Clumping, again, is the binding constraint. A prototype match of WoC author strings to OpenAlex authors by name and email produces 20,658,243 candidate links, of which only 14.6% carry an ORCID and 41.6% point to a scholarly author with a single recorded work: the signature of a spurious match to a near-empty profile. Single-token or generic names (P, 00, bare given names) match scholarly homonyms wholesale. The Semantic Scholar side is no richer: of its 111,255,251 authors, 99.8% carry no affiliation, 95.8% no ORCID/DBLP external id, and 50.1% a single recorded work, so attribute matching there collapses to name alone, and names are catastrophically ambiguous, with 57,850,738 distinct normalized names, one fifth (20.8%) shared by two or more authors, and the most common name held by 148,190 distinct authors. This is the clumping failure of Section 5, now across corpora and with the multiplicative blow-up of two large namespaces: a name shared by 𝑘 developers and 𝑚 researchers admits 𝑘 ×𝑚 false links, and a single careless transitive step fuses an entire WoC cluster into one scholar, or one scholar into a WoC mega-cluster. Cross-corpus linking is thus the most precision-hostile setting we have encountered, and a recall-oriented evaluation would again hide the damage. Why the released map is the right substrate. Two properties of this release make it the prerequisite for honest cross-corpus linking. First, mega-cluster freedom: links flow through WoC identities, so a WoC over-merge propagates directly into the scholarly graph; linking through a 3M-id mega would attach three million people to whatever paper any one of them coincidentally name-matches. Second, the per-id quality classification and provenance tags let a linker restrict to the high-confidence good ids that carry a real name and email (the only ids on which a match to a scholarly author is
Conference’17, July 2017, Washington, DC, USA
even meaningful) and weight down or discard the bad-by-attribute and local ids that generate most spurious links. A DOI-anchored pilot. To show that the released map makes honest cross-corpus linking tractable, not merely possible, we ran a pilot that anchors each candidate link on independent corroboration rather than name agreement alone, the same “corroboration de-clumps” principle that drives the within-corpus construction. Many repositories cite the literature they implement: we extracted DOIs from README/CITATION blobs, yielding 1,322,124 distinct DOIs across 164,655 projects, of which 53.0% resolve to a paper in the Semantic Scholar crosswalk (DOI → paper → {authorId, name}, 4.6 × 108 rows). We key on the canonical author A, building an idealized record (name variants and organizational email domains) from the union of all of A’s raw member ids, and accept a link only when a project’s WoC author and a Semantic Scholar author of a DOI that project cites agree on name. This yields 7,626 confident links over 7,246 canonical WoC authors (74.6% of which carry an organizational email) and 7,574 scholarly authors. The anchoring is what makes the result trustworthy. The matched authors would, under name-only matching, each map to an average of 63.8 Semantic Scholar authors (the most ambiguous to 35,835); requiring a shared DOI collapses this to 1.05 scholarly authors per WoC author. The resulting bipartite graph has no mega-cluster (its largest connected component spans 25 nodes) and is almost perfectly 1:1: only 301 WoC authors link to two or more scholarly ids (candidates for splits within Semantic Scholar) and only 51 scholarly ids to two or more WoC authors (residual homonyms). For the 301 candidate within-corpus splits, paper-level SPECTER v2 embeddings [6] corroborate the merge: the mean pairwise cosine among an author’s linked papers is 0.884 versus a 0.808 random-pair baseline, an independent recall lever that cannot re-clump because it fires only inside an already DOI-anchored group. The cost of this precision is coverage (7,246 authors is small against the WoC scale, bounded by the 53% DOI-in-corpus rate and the in-project name-agreement requirement), the trade a clumping-graded evaluation is meant to expose. We release the map as the substrate for this linking; the pilot establishes that DOI co-occurrence (and, inside its anchored groups, embeddings and organizational email) is a precise, scalable join, and scaling it (graded explicitly for clumping) is ongoing work.
8
Usage and Research Opportunities
Basic use. To attribute a commit, look it up in c2AFull for its resolved author A and provenance tag; or, starting from a raw author string, look it up in a2AFullSUG for its canonical A. A study chooses a quality bar by filtering on the provenance tag or the A2clsFull class, e.g. “human, globally resolved” is prov∈ {𝑔, 𝑝} and class≠bot. Opportunities. The release enables (i) bias-corrected contribution and bus-factor studies that no longer inherit a 3M-id over-merge; (ii) developer-network and migration analyses at full-WoC scale with an explicit, per-commit resolution-quality signal; (iii) study of the remaining hard cases (same person, disjoint rare emails), which are the natural territory of behavioral fingerprinting [1] layered over
Audris Mockus
this map; and (iv) reuse of the construction as a template: the gatethen-cut-then-classify ordering, and the two-benchmark grading, transfer to identity resolution in other large heterogeneous graphs.
9
Limitations
The map is global and so omits within-repository evidence that a repository-local resolver can use; the residual 1.83% unresolved human commits and the “same person, disjoint rare emails” misses are its known recall frontier. Quality classes are heuristic (namespread plus a frequency/blacklist battery) and inherit the usual false-positive/false-negative trade of attribute heuristics. The map is a snapshot of WoC V2604; identities accrue new aliases over time, so the map is re-derived each WoC release. Finally, the GitHub ground truth covers only within-handle pairs and the ALFAA gold is OpenStack-centric, so neither benchmark is a complete oracle, which is why we report both and ship per-commit provenance rather than a single quality verdict.
10
Conclusion
We release a mega-cluster-free author-identity map for the World of Code V2604, resolving 106,826,059 raw strings over 5,866,595,698 commits, together with a per-id quality classification, a withinproject fallback, and per-commit provenance. The design is an ordering rather than a single algorithm (gate, then cut topology, then classify edges, then recover recall, then resolve locally), each step forced by a measured failure of the simpler alternative. The result resolves 73.5% of all six billion commits and 98.17% of human commits into a multi-id identity, at recall 0.70 / precision 0.88 on human gold. The choice of map is not cosmetic: left unaliased, the same corpus inflates the developer head-count by 66.6% and skews productivity, team-resilience, and centrality measures, with undermerge and over-merge distorting them in opposite directions. The artifacts and a self-contained replication package ship with the WoC V2604 release. Future work. The map is the substrate for cross-corpus author linking (Section 7): resolving these 62.67M canonical software identities (folded from 108 raw ids) against the 108 -scale OpenAlex and Semantic Scholar author graphs, so that software artifacts can be tied to their academic provenance and vice versa. A DOI-anchored pilot already links 7,246 canonical authors at 1.05 scholarly ids each (mega-cluster-free where name-only matching would average 63.8), so the open problem is scaling coverage beyond the DOIcited subset without surrendering that precision. Because this is the most clumping-hostile setting we have met, the contribution there will be as much the evaluation discipline (grading the linkage for over-merge, not recall) as the linkage itself.
References [1] Sadika Amreen, Yuxia Zhang, Chris Bogart, Russell Zaretzki, and Audris Mockus. 2019. ALFAA: Active Learning Fingerprint Based Anti-Aliasing for correcting developer identity errors in version control systems. Empirical Software Engineering 25, 2 (2019), 1136–1167. doi:10.1007/s10664-019-09786-7 [2] Guilherme Avelino, Leonardo Passos, Andre Hora, and Marco Tulio Valente. 2016. A novel approach for estimating truck factors. In Proceedings of the 24th International Conference on Program Comprehension (ICPC). 1–10. doi:10.1109/ ICPC.2016.7503718 [3] Christian Bird, Alex Gourley, Premkumar Devanbu, Michael Gertz, and Anand Swaminathan. 2006. Mining Email Social Networks. In Proceedings of the 3rd
A Global Author-Identity Map for the World of Code: 62.7M Developer Identities from 106.8M Author Strings over 5.87B Commits International Workshop on Mining Software Repositories (MSR). 137–143. doi:10. 1145/1137983.1138016 [4] Thomas Bock, Aakanksha Agarwal, Mitchell Atkisson, Audris Mockus, and Bogdan Vasilescu. 2025. Between Accuracy and Privacy: Rethinking DeveloperIdentity De-Aliasing in Git Repositories. Empirical Software Engineering (2025). Under submission. Tool: GitAuthority, https://github.com/bockthom/ gitauthority. [5] Peter Christen. 2012. Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection. Springer. doi:10.1007/978-3-642-311642 [6] Arman Cohan, Sergey Feldman, Iz Beltagy, Doug Downey, and Daniel S. Weld. 2020. SPECTER: Document-level Representation Learning using Citationinformed Transformers. In Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics (ACL). 2270–2282. doi:10.18653/v1/2020.aclmain.207 [7] Tapajit Dey, Sara Mousavi, Eduardo Ponce, Tanner Fry, Bogdan Vasilescu, Anna Filippova, and Audris Mockus. 2020. Detecting and Characterizing Bots that Commit Code. In Proceedings of the 17th International Conference on Mining Software Repositories (MSR). 209–219. doi:10.1145/3379597.3387478 [8] Tanner Fry, Tapajit Dey, Andrey Karnauch, and Audris Mockus. 2020. A dataset and an approach for identity resolution of 38 million author ids extracted from 2B
Conference’17, July 2017, Washington, DC, USA git commits. In Proceedings of the 17th International Conference on Mining Software Repositories (MSR), Data Showcase. 518–522. doi:10.1145/3379597.3387500 [9] Mathieu Goeminne and Tom Mens. 2013. A Comparison of Identity Merge Algorithms for Software Repositories. Science of Computer Programming 78, 8 (2013), 971–986. doi:10.1016/j.scico.2011.11.004 [10] Christoph Gote and Christian Zingg. 2021. gambit – An Open Source Name Disambiguation Tool for Version Control Systems. In Proceedings of the 18th International Conference on Mining Software Repositories (MSR). 80–84. doi:10. 1109/MSR52588.2021.00021 [11] Erik Kouters, Bogdan Vasilescu, Alexander Serebrenik, and Mark G. J. van den Brand. 2012. Who’s Who in GNOME: Using LSA to Merge Software Repository Identities. In Proceedings of the 28th IEEE International Conference on Software Maintenance (ICSM). 592–595. doi:10.1109/ICSM.2012.6405329 [12] Yuxing Ma, Tapajit Dey, Chris Bogart, Sadika Amreen, Marat Valiev, Adam Tutko, David Kennard, Russell Zaretzki, and Audris Mockus. 2021. World of Code: Enabling a Research Workflow for Mining and Analyzing the Universe of Open Source VCS Data. Empirical Software Engineering 26, 2 (2021), 22. doi:10.1007/ s10664-020-09905-9 [13] Audris Mockus. 2026. Scaling Author Identity Disambiguation to the World of Code: A Methodology. Companion methodology log; full experimental record (Exps. 1–18).