Identifying unique developers in OSS projects: A family of models Ruoyu Su1 # University of Oulu, Finland
Alexander Bakhtin # University of Oulu, Finland
Matteo Esposito # University of Oulu, Finland
Davide Taibi #
arXiv:2606.08096v1 [cs.SE] 6 Jun 2026
University of Southern Denmark, Vejle, Denmark University of Oulu, Finland
Valentina Lenarduzzi # University of Southern Denmark, Vejle, Denmark University of Oulu, Finland
Abstract Organizational and logical coupling metrics require reliable identification of unique developers. In OSS, commit metadata is limited to names and emails, and the same developer may appear under multiple aliases, which can distort coupling measurements if de-duplication is missing. We aim to build a scalable and accurate pipeline for OSS developer de-duplication and to provide guidance on choosing a model based on precision vs. computational effort. We use Indel similarity as a baseline, then run an LLM-assisted matching process with manual validation to create a large dataset of duplicate identities. Using this dataset, we train and compare classical ML models of different complexity, evaluating precision along with training and inference time and energy. We expect a high-quality dataset and a benchmark of approaches that clarifies which solutions offer the best trade-off between accuracy and cost for large-scale OSS mining. 2012 ACM Subject Classification Computing methodologies → Machine learning; Human-centered computing → Open source software; Information systems → Deduplication Keywords and phrases software developers, OSS, AI, LLM, ML, de-duplication Digital Object Identifier 10.4230/LIPIcs... Funding Research Council of Finland (grants no. 359861 and 349488 - MuFAno), Business Finland (grant 6GSoft), and FAST, the Finnish Software Engineering Doctoral Research Network.
1
Introduction
Recent research in software architecture has increasingly emphasized the socio-technical dimension of systems, highlighting how developer collaboration structures influence architectural properties such as coupling, cohesion, ownership, and system evolution. A growing body of empirical work has investigated organizational and logical coupling in service-oriented and microservice-based systems by mining developer collaboration networks and contribution histories [20, 21, 24, 25]. These studies demonstrate that architectural quality cannot be fully understood without accounting for how developers interact with architectural elements over time.
1
Corresponding author © R. Su, A. Bakhtin, M. Esposito, D. Taibi, and V. Lenarduzzi; licensed under Creative Commons License CC-BY 4.0 Leibniz International Proceedings in Informatics Schloss Dagstuhl – Leibniz-Zentrum für Informatik, Dagstuhl Publishing, Germany
XX:2
Identifying unique developers in OSS projects: A family of models
Subsequent investigations have explored architectural implications of developer allocation strategies, ownership patterns, and collaboration dynamics, showing how organizational factors may either amplify or mitigate architectural degradation [1, 7, 8, 22, 23, 26]. Across these works, developer-centric metrics are repeatedly used as first-class inputs for architectural analysis, optimization, and decision-making. However, all such analyses fundamentally rely on the assumption that developer identities extracted from version control systems accurately represent unique natural persons. In open-source software repositories, this assumption rarely holds: the same developer may appear under multiple name–email combinations due to configuration changes, role-based accounts, or inconsistent identity usage. When left unresolved, duplicate developer identities introduce systematic noise into collaboration networks and coupling metrics, potentially distorting architectural interpretations and downstream empirical conclusions. Despite its importance, developer identity de-duplication is often handled heuristically [9, 19], performed manually on small datasets [3, 21, 25], or omitted altogether [1, 4, 24, 26], implicitly treated as a secondary data-cleaning concern. As architectural research increasingly targets large-scale systems and longitudinal analyses, the lack of scalable, precise, and reproducible identity resolution mechanisms becomes a critical methodological limitation. In this registered report, we aim to systematically investigate whether modern Large Language Models and classical Machine Learning approaches can provide accurate, scalable, and energy-aware solutions for duplicate developer identification in large-scale open-source projects, thereby strengthening the methodological foundations of developer-centric software architecture research. Henceforth, we expect this registered report to provide the following contributions: A systematic empirical evaluation of Large Language Models for duplicate developer identity identification in open-source software repositories; A comparative assessment of classical ML-based approaches trained on LLM-curated data, focusing on precision, scalability, and computational efficiency; An analysis of time and energy consumption trade-offs between LLM-based and ML-based solutions in large-scale mining scenarios; An empirical investigation of how training data volume affects the precision of ML-based identity resolution approaches; An assessment of whether developer activity similarity (via cosine similarity) improves duplicate identity detection; A reusable and openly available experimental protocol and replication package to support future architectural and socio-technical mining studies.
2
Background and Related Work
Mining commit data provides us with the name and email of the author/committer as they were set in that user’s git configuration. This creates an issue of duplicate developer identities in the data, since the same person might forget to properly configure this data on different machines or simply change emails. For instance, the organizational coupling metric by Li et al. [25] involves counting contribution switches done between a pair of components by each developer, and weighing this count by the harmonic mean of churn incurred to both components by the same developer. Such a non-linear metric will yield different values when two identities, A and B, and their churns are used separately, compared to when all the churn incurred by A and B is attributed to the same merged identity. Thus, given the full
R. Su, A. Bakhtin, M. Esposito, D. Taibi, and V. Lenarduzzi
list of developer names and emails from mined commit data, we are required to perform developer de-duplication. Many existing works constructing developer social networks through mining software repositories do not deal with this issue and do not address it as a threat to the validity of the work [1, 24, 26], apparently treating each unique record as a unique developer, with some works acknowledging it openly [4]. Some authors leveraged proprietary industrial data, where arguably more strict rules regarding configurations and committing to projects were in place and identity of each developer can be reliably established [16, 28, 35, 36], while others gathered data from official database dumps, which include a users table acting as a foreign key for other records involving users [9, 19]. Finally, some works only gathered a small set of developers, so identification of inconsistencies and merging of identities were performed manually [3, 21, 22, 25]. The heuristic by Bird et al. [5] is the most commonly cited method for identifying unique (name, email) pairs, although it was proposed for email lists [30, 33]. It leverages Levenshtein similarity [17], which is a string similarity metric that counts the number of additions, deletions, and substitutions necessary to transform one string into the other. To our knowledge, this is the first attempt to apply Large Language Models to the problem of unique developer identification in OSS projects.
3
Empirical study design
The empirical study design follows the guidelines defined by [34]. In this section, we describe the goals and research questions with hypotheses, the study context, the execution plan, and the data analysis. Due to space constraints in the registered report, we uploaded the extended methodology, which includes a Figure describing the entire process and introducing LLM integration, design, and validation in the online appendix2 .
3.1
Goal, Research Questions, and Hypothesis
The goal of this empirical study is to construct a family of ML models for duplicate developer identification for the purpose of developer identity de-duplication with respect to the precision and effort of the model inference, from the point of view of researchers in the context of mining OSS repositories. In particular, we first investigate whether LLMs can reliably identify duplicate developer identities and generate labeled identity pairs. Then we use labeled pairs to support the training and evaluation of ML-based approaches for scalable duplicate developer identification. Therefore, we define the following Research Questions (RQs): RQ1 : Can LLMs identify duplicate developer identities in OSS projects? Identifying unique developer identities is a prerequisite for accurately computing organizational and logical coupling in OSS projects [26]; however, the developer identity de-duplication is complex and challenging due to the lack of authoritative identity information [13]: inconsistent names and emails in the submission record; and traditional string-based heuristics rely on superficial similarity and can not identify the semantic variations, such as nickname, email format, and naming convention. Recent advances in LLMs suggest they may be able to
2
https://doi.org/10.5281/zenodo.19472235
XX:3
XX:4
Identifying unique developers in OSS projects: A family of models
resolve ambiguous developer identities by leveraging contextual and semantic information beyond traditional string-based heuristics [14,18]. This RQ aims to investigate whether LLMs can identify duplicate developer identities. Incorrectly identifying two different developers as the same person would undermine developer-based analysis, such as organizational coupling and collaboration network. In this study, LLMs serve as the decision-maker that receives the developer identity pair (name, email) to determine whether they are the same natural person. Considering the increasing popularity of diverse LLMs, we plan to leverage multiple LLMs to complete the duplicate developer identification task and examine whether the outcomes show statistically significant differences. Therefore, we conjecture the following null hypothesis (H0 ) and alternative hypothesis (H1 ): H01 : There is no significant difference between LLMs in duplicate developer identification. H11 : There is a significant difference between LLMs in duplicate developer identification. RQ2 : Can ML-based approaches provide a practical and scalable solution for duplicate developer identification in OSS projects? RQ2.1 : Can ML-based approaches identify duplicate developer identities? RQ2.2 : Can ML-based approaches outperform LLMs in terms of time and energy consumption? RQ2.3 : Does the precision of ML-based approaches depend on the amount of training data? While LLMs may identify duplicate developer identities (RQ1 ), their computational cost, limited scalability, and energy consumption may hinder their direct adoption in large-scale mining studies [12, 31]. In practice, OSS repositories often contain thousands of contributors and millions of commits, with vast amounts of data [27]. RQ2 aims to investigate whether classical ML-based approaches trained on LLM-curated data can provide a practical and scalable solution for duplicate developer identification. RQ2 mainly focuses on evaluating whether ML-based approaches can effectively identify developers while being more efficient and easier to deploy at scale. RQ2.1 aims to determine the effectiveness of classical ML-based approaches in identifying duplicate developer identities. Different from LLMs, ML-based approaches rely on supervised learning with labeled identity pairs [6]. Therefore, their performance depends on the quality of the labeled dataset of developer duplicate pairs, which we aim to obtain as the result of RQ1 . Thus, in this sub-question, we aim to see which ML models pre-trained on the LLM-provided labels are good enough for developer de-duplication. Availability of pre-trained models as a result of this RQ will remove the burden of data curation and model training for those wishing to leverage our approach in the future, requiring time and resources only for the inference of the provided new data. RQ2.2 investigates the performance of ML-based approaches in terms of time and energy consumption. Even if ML-based approaches can identify developer identities, their practical applicability depends on their computational and energy efficiency [32]. Therefore, facing massive amounts of data, training and inference costs become important factors in determining whether a method is practically deployable. RQ2.2 evaluates the time and energy consumption of different ML-based approaches through quantifying these factors, compares them to the LLM-based plan (RQ1 ), and determines their suitability for large-scale empirical mining studies. RQ2.3 examines the relationship between training data volume and the precision
R. Su, A. Bakhtin, M. Esposito, D. Taibi, and V. Lenarduzzi
of using ML-based approaches for duplicate developer identification. The availability of labeled data is another key limitation in developer identity resolution [2]. Creating large, manually validated datasets is expensive and time-consuming, and it is unclear how much training data is required to achieve stable and reliable performance. RQ2.3 explores whether the precision of ML-based approaches is associated with the the amount of training data: increasing, remaining unchanged, or decreasing. So, we conjecture the following null hypotheses (H0 ) and alternative hypotheses (H1 ): H02 : There is no significant difference between ML-based approaches in identifying duplicate developer identities. H03 : There is no significant difference in time and energy consumption between ML-based approaches and LLMs for duplicate developer identification. H04 : There is no significant association between the amount of training data and the precision of ML-based duplicate developer identification. H12 : There is a significant difference between ML-based approaches in identifying duplicate developer identities. H13 : There is a significant difference in time and energy consumption between ML-based approaches and LLMs for duplicate developer identification. H14 : There is a significant association between the amount of training data and the precision of ML-based duplicate developer identification. RQ3 : Can cosine similarity between developers improve the quality of duplicate developer identification? While the basic data we focus on in this work is the names and emails of developers, mining the commit history allows us to obtain information about the file modifications they made. Jermakovics et al. [16] proposed constructing a matrix indicating which developers committed to which files and using cosine similarity between developers’ activity vectors to cluster them based on similar activity. Cosine similarity refers to the similarity between developers’ activity profiles derived from their file modification histories. We suspect that the same person, committing under several identities, would nonetheless touch related files, and thus the activity patterns of these identities would be very similar. Thus, we can leverage this cosine similarity as an additional feature to provide to the considered methods for identifying duplicates and evaluate whether providing this feature results in a significant improvement in the methods’ quality. RQ3 investigates whether adding cosine similarity information can improve the quality of identifying duplicate developer identities. This question is crosscutting and applies to both LLM-based (RQ1 ) and ML-based approaches (RQ2 ). Through the comparison, we can evaluate whether adding this complexity is reasonable in largescale empirical mining studies. So, we conjecture the following null (H0 ) and alternative hypothesis (H1 ): H05 : There is no significant difference in the quality of duplicate developer identification when cosine similarity between developers is incorporated, compared to when it is not. H15 : Incorporating cosine similarity between developers has a significant difference in the quality of duplicate developer identification.
XX:5
XX:6
Identifying unique developers in OSS projects: A family of models
3.2
Study Context
As context, we plan to use the Linux kernel3 as the data source of developer identities for our study. According to the project’s GitHub mirror, the Linux kernel is one of the largest OSS software projects, with over a million commits and 15,000 contributors. Developers worldwide contribute to this project, ensuring the dataset of developer names and email addresses includes representative names from diverse cultural backgrounds and naming conventions. This enables us to evaluate the effectiveness of developer deduplication solutions across a diverse dataset. While the Linux kernel project is the primary study context, our evaluation focuses on the reliable precision estimates. If the Linux kernel data does not provide sufficient duplicate identity cases to support robust precision analysis or model training, we will also mine other large-scale OSS projects with diverse contributor bases.
3.3
Study Execution
We describe our study execution plan, including the data collection and analysis strategies. 1) Linux Kernel Data Collection: We clone the Linux kernel repository via GitHub mirrors. Each commit in Git version history contains a committer identity and an author identity, and we extract the developer identity from both. We represent each developer identity as a (name, email) format in the commit metadata. We record the total number of commits and unique identities included in the study. After extraction, we obtain a set of (name, email) identities. 2) Developer Identity Data Preprocessing: After collecting developer identity information, we perform data preprocessing steps to clean and standardize the extracted identity data. This step aims to remove minor inconsistencies and non-informative entities. Specifically, we standardize developer names and email addresses by cutting leading and ending spaces. We exclude developer identities with missing or empty email fields; we retain entries with missing or empty name fields, as emails may still contain identifiable naming information. This stage does not involve any semantic transformation operations (extension or merging). 3) Identity Pair Generation: We generate a complete set of all pairs of mined identities for the subsequent duplicate developer identification. Considering the number of unordered identity pairs grows quadratically with the number of developer identities, it may be computationally infeasible to evaluate all possible combinations in large OSS repositories. Therefore, if the computational load is excessive, we apply a blocking strategy to determine the set of candidate pairs for which LLM processing is required, using low-cost string-based heuristics, such as Levenshtein similarity [17], for names and emails. For instance, the names of present authors “Ruoyu Su” and “Davide Taibi” do not share any letters of the alphabet, and thus their similarity would be close to 0. Thus, such pairs can be filtered before LLM processing if necessary, significantly decreasing the number of pairs passed to LLMs. The final filtered identity pairs after blocking will be used for all the subsequent analyses. 4) Computational Environment and Execution Setup: We run all experiments on the supercomputer hosted by CSC4 , the Finnish IT Center for Science. Roihu5 is a highperformance computing system from CSC designed for compute- and data-intensive research with a total of 486 CPU nodes and 132 GPU nodes. It has a heterogeneous architecture that
3
https://github.com/torvalds/linux https://csc.fi/ 5 https://docs.csc.fi/computing/systems-roihu/
4
R. Su, A. Bakhtin, M. Esposito, D. Taibi, and V. Lenarduzzi
each GPU node has 4 NVIDIA GH200 Grace Hopper superchips, and each GH200 superchip comprises one Hopper (H100) GPU and one Grace CPU with 72 ARM CPU cores. Roihu can have efficient and scalable execution for demanding AI and data-intensive applications. 5) LLM-Based Duplicate Developer Identification (RQ1 ): We employ multiple LLMs as independent decision-makers for duplicate developer identification. Each LLM receives the same input, the developer identity pair (name, email), and determines whether these two identities belong to the same natural person. We use the same prompt and consistent LLM parameters when performing duplicate developer identification with different LLMs to ensure fairness in cross-model comparisons. Each LLM generates a binary decision for each candidate identity pair. We collect and compare outputs from different LLMs to test whether there is a significant difference in their duplicate developer identification decisions. To evaluate identification quality, human experts assess the correctness of selected LLM outputs. Human judgments are only for evaluation purposes (e.g., precision) and do not influence LLM outputs and comparisons between LLMs. To mitigate the bias introduced by evaluators’ own experiences and uncertainty, such as different developers sharing similar names or emails, evaluators will be instructed to follow a conservative approach, where any uncertainty in duplicate detection should result in a pair being labeled as non-duplicate. 6) ML-based Approaches Duplicate Developer identification (RQ2 ): We evaluate practical and scalable solutions that leverage ML-based approaches for duplicate developer identification. We train ML models via supervised learning, using curated and labeled identity pairs from the LLMs’ outputs in RQ1 . ML-based approaches rely on the structural characteristics of developers’ names and emails and are applied to the same identity pairs as in RQ1 to maintain consistency across experiments. We consider multiple classical ML-based approaches, including record linkage libraries (e.g., Dedupe), string similarity-based approaches, and string embedding-based approaches. For each approach, we follow the same procedure for training and application independently. To examine the effectiveness of ML-based approaches (RQ2.1 ), we train ML models using the LLM-curated labeled identity pairs and perform duplicate developer identification. To evaluate time and energy consumption (performance) (RQ2.2 ), we record the training and computational costs, including execution time and resource utilization, under the same computational environment described above, following CSC guidelines for GPU utilization monitoring6 . In addition, to investigate the dependence of ML-based approaches on training data (RQ2.3 ), we set different amounts of training data to run the same training procedure and explore whether the scale of the training data affects identification precision. 7) Cosine Similarity Augmentation (RQ3 ): We investigate whether adding cosine similarity based on developers’ activity profiles could improve the precision of duplicate developer identification. We extract the developers’ activity profiles and calculate the cosine similarity between developer activity pairs. We integrate cosine similarity as an additional feature into both LLM-based (RQ1 ) and ML-based (RQ2 ) duplicate developer identification experiments. For LLM-based identification, we add cosine similarity as a contextual input alongside the (name, email) identity pair. For ML-based identification, we include cosine similarity as an additional input feature during training and inference. We keep all conditions consistent except for adding cosine similarity to ensure a controlled comparison in the experiment. Consequently, we can evaluate whether adding cosine similarity information improves precision without additional confounding factors.
6
https://docs.csc.fi/support/tutorials/gpu-ml/#gpu-utilization
XX:7
XX:8
Identifying unique developers in OSS projects: A family of models
3.4
Data Analysis
Since this is a registered report, we did not execute the study and cannot know a priori whether the collected data follow the normal distribution. Consequently, we define the data analysis protocol for both normal and non-normal cases in this section. 1) LLM-Based Duplicate Developer Identification (RQ1 ): We analyze the results of duplicate developer identification between LLMs. We consider precision as the primary evaluation metric because it directly reflects the false-positive error rate. We also measure other standard metrics like recall and F1 score as complementary indicators. To evaluate the correctness of LLMs for duplicate developer identification, we employ Cochran’s formula [15] to obtain a sample size of developer identity pairs with a 95% confidence interval and a 5% error margin. Human experts independently label them as the evaluation benchmark. For each identity pair, human experts label whether the two developer identities are duplicates. P For each LLM, the precision calculation formula is: P = T PT+F P . TP represents the number of correctly identified duplicate identity pairs, while FP represents the number of incorrectly identified duplicate identity pairs. We also compute recall and F1 score based on the same labeled identity pairs. All LLMs evaluate the same identity pairs and generate paired binary decisions. Therefore, we use McNemar’s paired statistical test [10] to assess whether there is a significant difference between LLMs in duplicate developer identification. We conduct the hypothesis testing at a significance level (e.g., α = 0.05). The null hypothesis (H01 ) states that there is no significant difference between LLMs in duplicate developer identification, while the alternative hypothesis (H11 ) states that at least one LLM differs significantly from others. 2) ML-based Approaches Duplicate Developer identification (RQ2 ): We analyze the results of duplicate developer identification between different ML-based approaches (RQ2.1 ). Consistent with RQ1 , we consider precision as the primary evaluation metric, recall and F1 score as complementary indicators, and the same calculation formula. We evaluate the ML-based judgments on identity pairs that are not used for model training. And the precision is computed as the proportion of identity pairs identified as duplicates by the ML model that are confirmed as true duplicates according to the evaluation reference. We still adapt the McNemar’s test, and conduct the same significance level for hypothesis testing. The null hypothesis (H02 ) states that there is no significant difference between ML-based approaches in duplicate developer identification, while the alternative hypothesis (H12 ) states that at least one ML-based approach differs significantly from others. Moreover, we analyze the execution time and energy resource utilization of ML-based approaches (RQ2.2 ). We compare them with the cost of LLM-based approaches, and the goal is to explore whether ML-based approaches can provide a cost difference for duplicate developer identification, and determine their practical suitability for large-scale empirical mining studies [11]. We compute the costs for model training and inference. We aggregate execution time and system-level resource utilization metrics for each approach under the same computational environment. To assess whether ML-based approaches outperform LLMs in terms of time and energy consumption, we compare the distributions of computational costs across the two categories. We conduct the paired t-test analysis [29] to evaluate whether there is a significant difference in execution time and resource utilization. We perform hypothesis testing at a significance level (e.g., α = 0.05). The null hypothesis (H03 ) states that there is no significant difference in time and energy consumption between ML-based approaches and LLMs for duplicate developer identification, while the alternative hypothesis (H13 ) states that ML-based approaches differ significantly from LLMs.
R. Su, A. Bakhtin, M. Esposito, D. Taibi, and V. Lenarduzzi
Additionally, we analyze how the precision of ML-based approaches changes with the amount of training data (RQ2.3 ). The objective of this analysis is to evaluate the data dependence of ML-based approaches on training data and determine whether increasing the volume of data can have a significant difference in precision. For different predefined training data sizes, we compute the precision and compare the precision distributions. We conduct the hypothesis testing at a significance level (α = 0.05). The null hypothesis (H04 ) states that there is no significant association between the amount of training data and the precision of ML-based duplicate developer identification, while the alternative hypothesis (H14 ) states that the precision of ML-based approaches differs with the amount of training data. 3) Cosine Similarity Augmentation (RQ3 ): We analyze whether adding cosine similarity based on developers’ activity profiles could improve the quality of duplicate developer identification. We conduct this analysis on both LLM-based (RQ1 ) and ML-based (RQ2 ) identification. We set two conditions: (i) without cosine similarity (baseline setting) and (ii) with cosine similarity (augmented setting). We compute precision under these two conditions and compare its distributions to evaluate whether including cosine similarity affects precision. To compare precision between the baseline and augmented settings, we use a paired t-test. For RQ3 , quality refers to the precision of ML-based duplicate developer identification. To ensure comparability, we set only one variable, whether to increase cosine similarity, and keep all other conditions unchanged. We conduct the hypothesis testing at a significance level (e.g., α = 0.05). The null hypothesis (H05 ) states that there is no significant difference in the quality of duplicate developer identification when cosine similarity between developers is incorporated, compared to when it is not. The alternative hypothesis (H15 ) states that incorporating cosine similarity between developers has a significant difference in the quality of duplicate developer identification.
4
Threats to Validity
We discuss the threats to validity following the classification proposed by Wohlin et al. [34]. Construct validity In this work, developer identity is represented as a (name, email) pair extracted from Git commit metadata. Such data cannot fully represent a natural person, as developers may change names, email addresses, or, conversely, developers with similar names can be encountered in a large project. Thus, the notion of a “duplicate developer identity” relies on human expert judgments used for precision estimation, which may be subjective in borderline cases (e.g., common names or ambiguous email patterns). To mitigate this threat, we rely on expert validation using a statistically grounded sampling strategy and focus on precision, which directly penalizes false positive merges that would introduce structural distortions in subsequent analyses. Moreover, we will leverage a conservative approach in which any uncertainty should result in pairs labeled as non-duplicate. Internal validity A key threat arises from the blocking strategy used to reduce the number of candidate identity pairs, which may exclude true duplicate pairs that do not satisfy the initial string-based heuristics. While this could affect recall, our study explicitly prioritizes precision over completeness, as false positives are more harmful for organizational and architectural analyses. ML-based approaches are trained on labels curated from LLM outputs, which introduces the risk of propagating systematic biases from LLMs into downstream models. Thus, our hypotheses do not deal with direct comparison of ML and LLM deduplication performance, focusing instead on the time and effort required to obtain the results.. To reduce the risks, human experts are involved in validating sampled outputs, and all ML models are evaluated on held-out identity pairs not used during training.
XX:9
XX:10
Identifying unique developers in OSS projects: A family of models
External validity The primary study context is the Linux kernel, which is a large-scale, long-lived OSS project with a diverse and global contributor base. While this makes it a strong benchmark for scalability and heterogeneity, results obtained on this project may not directly generalize to smaller projects, projects with stricter contribution policies, or proprietary industrial settings. However, the focus of this work is on OSS mining scenarios where authoritative identity information is unavailable. If insufficient duplicate cases are observed in the Linux kernel, additional large OSS projects will be included to strengthen generalizability across different contributor ecosystems. Conclusion validity Since this is a Stage 1 Registered Report we do not report threats to conclusion validity.
5
Conclusion
This study aims to address a key challenge in the Software Architecture (SA) mining field: accurately identifying duplicate developers in OSS projects. Since organizational and logical coupling metrics rely on developer-centric data, duplicate developer identities introduce systematic noise into collaboration networks and coupling metrics, potentially distorting architectural interpretations and downstream empirical conclusions. To this end, we propose LLM-based and classical ML-based approaches for duplicate developer identification, considering precision, scalability, computational cost, and energy efficiency, and aim to construct a family of ML models for duplicate developer identification in OSS mining scenarios. The contribution of this work is to give a scalable developer identity deduplication pipeline based on ML and LLM approaches, strengthening the developer-centric organizational and logical coupling analysis in the SA community. Declaration on the use of generative AI We used ChatGPT for suggestions on improving textual clarity. All research design, data analysis, interpretations, and manuscripts were created by the authors themselves.
References 1
Dario Amoroso d’Aragona, Xiaozhou Li, Tomas Cerny, Andrea Janes, Valentina Lenarduzzi, and Davide Taibi. One microservice per developer: is this the trend in oss? In European Conference on Service-Oriented and Cloud Computing, pages 19–34. Springer, 2023.
2
Sadika Amreen, Audris Mockus, Russell Zaretzki, Christopher Bogart, and Yuxia Zhang. Alfaa: Active learning fingerprint based anti-aliasing for correcting developer identity errors in version control systems. Empirical Software Engineering, 25(2):1136–1167, 2020.
3
Alexander Bakhtin, Xiaozhou Li, and Davide Taibi. Temporal community detection in developer collaboration networks of microservice projects. In European Conference on Software Architecture, pages 174–182. Springer, 2024.
4
Flore Barcellini, Françoise Détienne, and Jean-Marie Burkhardt. User and developer mediation in an open source software community: Boundary spanning through cross participation in online discussions. International Journal of Human-Computer Studies, 66(7):558–570, 2008.
5
Christian Bird, Alex Gourley, Prem Devanbu, Michael Gertz, and Anand Swaminathan. Mining email social networks. In 2006 international workshop on Mining software repositories, pages 137–143, 2006.
6
Peter Christen. The data matching process. In Data matching: concepts and techniques for record linkage, entity resolution, and duplicate detection, pages 23–35. Springer, 2012.
R. Su, A. Bakhtin, M. Esposito, D. Taibi, and V. Lenarduzzi
7
Dario Amoroso d’Aragona, Xiaozhou Li, and Andrea Janes. Understanding the causes of microservice logical coupling: an exploratory study. In 1st International Workshop on New Trends in Software Architecture, SATrends ’24, page 14–17, 2024.
8
Dario Amoroso d’Aragona, Luca Pascarella, Andrea Janes, Valentina Lenarduzzi, and Davide Taibi. Microservice logical coupling: A preliminary validation. In 2023 IEEE 20th International Conference on Software Architecture Companion (ICSA-C), pages 81–85, 2023.
9
Barnita Das, Bikromadittya Mondal, and Rahul Sinha. Exploring fusion centrality in developer social networks. In 2024 International Conference on Big Data Analytics in Bioinformatics (DABCon), pages 1–6, 2024.
10
Thomas G Dietterich. Approximate statistical tests for comparing supervised classification learning algorithms. Neural computation, 10(7):1895–1923, 1998.
11
Jesse Dodge, Taylor Prewitt, Remi Tachet des Combes, Erika Odmark, Roy Schwartz, Emma Strubell, Alexandra Sasha Luccioni, Noah A Smith, Nicole DeCario, and Will Buchanan. Measuring the carbon intensity of ai in cloud instances. In Proceedings of the 2022 ACM conference on fairness, accountability, and transparency, pages 1877–1894, 2022.
12
Jared Fernandez, Clara Na, Vashisth Tiwari, Yonatan Bisk, Sasha Luccioni, and Emma Strubell. Energy considerations of large language model inference and efficiency optimizations. arXiv preprint arXiv:2504.17674, 2025.
13
Tanner Fry, Tapajit Dey, Andrey Karnauch, and Audris Mockus. A dataset and an approach for identity resolution of 38 million author ids extracted from 2b git commits. In Proceedings of the 17th international conference on mining software repositories, pages 518–522, 2020.
14
Qianyu Huang and Tongfang Zhao. Leveraging large language models for entity matching. arXiv preprint arXiv:2405.20624, 2024.
15
Glenn D Israel et al. Determining sample size. 1992.
16
Andrejs Jermakovics, Alberto Sillitti, and Giancarlo Succi. Mining and visualizing developer networks from version control systems. In 4th International Workshop on Cooperative and Human Aspects of Software Engineering, page 24–31, 2011.
17
Vladimir Iosifovich Levenshtein. Binary codes capable of correcting deletions, insertions, and reversals. In Doklady Akademii Nauk, volume 163, pages 845–848. Russian Academy of Sciences, 1965.
18
Huahang Li, Longyu Feng, Shuangyin Li, Fei Hao, Chen Jason Zhang, and Yuanfeng Song. On leveraging large language models for enhancing entity resolution: a cost-efficient approach. arXiv preprint arXiv:2401.03426, 2024.
19
Ning Li, Wenkai Mo, and Beijun Shen. Task recommendation with developer social network in software crowdsourcing. In 2016 23rd Asia-Pacific Software Engineering Conference (APSEC), pages 9–16, 2016.
20
X. Li, A.S. Abdelfattah, R. Su, J. Lee, E. Aponte, R. Koerner, T. Cerny, and D. Taibi. Metrics and models for developer collaboration analysis in microservice-based systems. a systematic mapping study. CEUR Workshop Proceedings, 2023.
21
Xiaozhou Li, Amr S Abdelfattah, Jorge Yero, Dario Amoroso d’Aragona, Tomas Cerny, and Davide Taibi. Analyzing organizational structure of microservice projects based on contributor collaboration. In 2023 IEEE International Conference on Service-Oriented System Engineering (SOSE), pages 1–8, 2023.
22
Xiaozhou Li, Noman Ahmad, Tomas Cerny, Andrea Janes, Valentina Lenarduzzi, and Davide Taibi. Toward organizational decoupling in microservices through key developer allocation. In 2025 IEEE 22nd International Conference on Software Architecture Companion (ICSA-C), pages 16–20, 2025.
23
Xiaozhou Li and Michele Albano. A framework for microservice organizational structure optimization. In 1st International Workshop on New Trends in Software Architecture, pages 18–21, 2024.
XX:11
XX:12
Identifying unique developers in OSS projects: A family of models
24
25
26
27 28
29 30
31
32
33
34 35
36
Xiaozhou Li, Fabio Calefato, Valentina Lenarduzzi, and Davide Taibi. Toward collaboration optimization in microservice projects based on developer personalities. In 2024 IEEE 21st International Conference on Software Architecture Companion (ICSA-C), pages 95–99, 2024. Xiaozhou Li, Dario Amoroso d’Aragona, and Davide Taibi. Evaluating microservice organizational coupling based on cross-service contribution. In International Conference on Product-Focused Software Process Improvement, pages 435–450. Springer, 2023. Xiaozhou Li, Dario Amoroso d’Aragona, Tomas Cerny, Valentina Lenarduzzi, Davide Taibi, and Andrea Janes. Exploring microservice ownership and organizational coupling in open-source projects: an empirical study. Computing, 107(4):1–35, 2025. Manuel Maes Bermejo, Jesus M. Gonzalez-Barahona, Miguel Gallego, and Gregorio Robles. A dataset of linux kernel commits, 2024. doi:10.5281/zenodo.10654193. Andrew Meneely, Laurie Williams, Will Snipes, and Jason Osborne. Predicting failures with developer networks and social network analysis. In 16th ACM SIGSOFT International Symposium on Foundations of Software Engineering, page 13–23, 2008. Douglas C Montgomery and George C Runger. Applied statistics and probability for engineers. John wiley & sons, 2019. Kawin Ngamkajornwiwat, Dongsong Zhang, A Gunes Koru, Lina Zhou, and Robert Nolker. An exploratory study on the evolution of oss developer communities. In 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), pages 305–305, 2008. Emma Strubell, Ananya Ganesh, and Andrew McCallum. Energy and policy considerations for deep learning in nlp. In 57th annual meeting of the association for computational linguistics, pages 3645–3650, 2019. Arya Tschand, Arun Tejusve Raghunath Rajan, Sachin Idgunji, Anirban Ghosh, Jeremy Holleman, Csaba Kiraly, Pawan Ambalkar, Ritika Borkar, Ramesh Chukka, Trevor Cockrell, et al. Mlperf power: Benchmarking the energy efficiency of machine learning systems from µwatts to mwatts for sustainable ai. In 2025 IEEE International Symposium on High Performance Computer Architecture (HPCA), pages 1201–1216. IEEE, 2025. Song Wang and Nachiappan Nagappan. Characterizing and understanding software developer networks in security development. In 2021 IEEE 32nd International Symposium on Software Reliability Engineering (ISSRE), pages 534–545, 2021. Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson, Björn Regnell, and Anders Wesslén. Experimentation in software engineering. Springer Science & Business Media, 2012. Timo Wolf, Adrian Schroter, Daniela Damian, and Thanh Nguyen. Predicting build failures using social network analysis on developer communication. In 2009 IEEE 31st International Conference on Software Engineering, pages 1–11, 2009. Shengyu Zhao, Xiaoya Xia, Brian Fitzgerald, Xiaozhou Li, Valentina Lenarduzzi, Davide Taibi, Rong Wang, Wei Wang, and Chunqi Tian. Openrank leaderboard: motivating open source collaborations through social network evaluation in alibaba. In 46th International Conference on Software Engineering: Software Engineering in Practice, pages 346–357, 2024.