The reviewed record of science sign in
Pith

arxiv: 2607.06471 · v1 · pith:MQQ3YONI · submitted 2026-07-07 · cs.SE

Domain-Driven Design in Practice: A Large-Scale Empirical Characterisation of the Open-Source Ecosystem

Ozan \"Ozkan , \"Onder Babur , Mark van den Brand This is my paper

Reviewed by Pith2026-07-08 04:34 UTCglm-5.2pith:MQQ3YONIopen to challenge →

classification cs.SE
keywords repositoriesadoptionpracticecharacterisationcontextdesigndomain-drivenempirical
0
0 comments X

The pith

2,502 GitHub repos reveal DDD as mature practice, not theory

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

This paper argues that Domain-Driven Design (DDD), a software architecture paradigm introduced in 2004 to align code structure with business domain logic, has crossed the threshold from academic concept to stable industrial practice in the open-source world. The authors mined 11,742 candidate GitHub repositories using keyword and topic searches, then built an automated GPT-4o pipeline that inspected source code and directory structures to verify which projects genuinely implement DDD patterns, yielding 2,502 confirmed repositories. The central empirical claims are that DDD adoption accelerated sharply after a 2017 inflection point, that verified projects live far longer than typical GitHub repositories (median 340 days versus 9.9 days), that C# and TypeScript rather than Java dominate implementation, and that Layered and Clean Architecture are the prevailing structural patterns while CQRS and Event Sourcing recur in distributed, data-intensive systems. The paper also reports that 25.3% of verified projects record no explicit business domain in their metadata, which the authors interpret as a persistent gap between architectural intent and what version control systems capture.

Core claim

The paper's central object is the 2,502-repository validated dataset, produced by a triplicate GPT-4o semantic validation pipeline that achieved Cohen's kappa = 0.77 against two human expert raters on a 50-repository benchmark. Using this dataset, the authors establish that DDD in open source is characterized by sustained engineering maturity (long-lived projects, organizational ownership at 23%, 11.15 average contributors), a 2017 inflection point in adoption, C# dominance at 34.17% challenging the Java-centric academic assumption, and a concentration of Layered (28.9%) and Clean (22.78%) architectural styles. The pipeline itself is presented as a transferable methodological contribution: a

What carries the argument

GPT-4o agentic semantic validation pipeline with triplicate majority-vote (kappa=0.77 vs. human experts; 94.75% unanimous agreement across runs)

If this is right

  • Researchers studying software evolution, technical debt, or architectural decay now have a curated set of 2,502 verified DDD repositories as a benchmark corpus of engineered, long-lived projects.
  • The 78.7% overall noise rate in keyword-based repository discovery provides a concrete calibration point for future domain-specific mining studies, especially for ambiguous abbreviations like 'ddd'.
  • The dominance of C# and TypeScript over Java in verified DDD repositories suggests academic curricula and textbooks may be misaligned with industrial adoption patterns.
  • The 25.3% of projects with no identifiable business domain in metadata exposes a structural limitation of Git-based version control for capturing architectural intent, motivating lightweight traceability standards.

Load-bearing premise

The GPT-4o pipeline's agreement with human experts, measured on a 50-repository sample, is assumed to hold across the full 4,206-repository candidate pool spanning all languages, sizes, and architectural styles, even though source-file inspection was limited to seven language extensions covering 95.29% of repositories and the validation sample is small relative to the candidate set.

What would settle it

If the GPT-4o pipeline has systematic language-specific or size-specific biases not captured in the 50-repository benchmark, the composition of the 2,502-repository dataset could be skewed, undermining downstream claims about language distribution, architectural styles, and longevity.

Figures

Figures reproduced from arXiv: 2607.06471 by Mark Van Den Brand, \"Onder Babur, Ozan \"Ozkan.

Figure 1
Figure 1. Figure 1: Overview of the data collection and verification pipeline, comprising topic-based [PITH_FULL_IMAGE:figures/full_fig_p013_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The agentic GPT-4o classification pipeline. Each repository undergoes up to [PITH_FULL_IMAGE:figures/full_fig_p020_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Annual creation of verified DDD repositories on GitHub (bars, left axis) and [PITH_FULL_IMAGE:figures/full_fig_p028_3.png] view at source ↗
read the original abstract

Context: Domain-Driven Design (DDD) is a leading paradigm for managing software complexity, yet research remains largely theoretical; our prior work found nearly 39% of DDD studies lack rigorous empirical evaluation, leaving practical adoption largely unexamined at scale. Objective: We provide the first large-scale characterisation of the DDD landscape on GitHub, a data-driven baseline for how the paradigm is implemented and sustained in practice. Method: Using a Mining Software Repositories (MSR) approach with a hybrid strategy (topics and README keywords), we identified 11,742 candidate repositories. To address label noise, we built a novel semantic validation pipeline using GPT-4o with a triplicate majority-vote strategy, yielding 2,502 verified repositories. Validation against a manually labelled sample showed substantial agreement with human experts (kappa = 0.77). Results: DDD adoption accelerated sharply after a 2017 inflection point, and the resulting projects are notably long-lived: their median lifespan exceeds the typical GitHub project by over an order of magnitude, indicating sustained, professional-grade engineering rather than short-lived experiments. Layered and Clean Architecture dominate, while CQRS and Event Sourcing recur in distributed, data-intensive systems. Notably, the data challenge the Java-centric assumption of much academic work: C# and TypeScript, not Java, lead practical adoption. Conclusions: DDD has matured into a stable, professional-grade practice adopted across diverse languages and domains. However, a quarter of projects (25.3%) record no explicit business context, revealing a persistent gap between how domain intent is designed and how it is preserved in version control. We call for lightweight architectural traceability standards and offer guidance for teams reusing these repositories as reference implementations.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 8 minor

Summary. This paper presents a large-scale Mining Software Repositories (MSR) study characterising Domain-Driven Design (DDD) adoption on GitHub. The authors mine 11,742 candidate repositories using a hybrid topic- and README-keyword strategy, apply inclusion/exclusion criteria to obtain 4,206 candidates, and then use a GPT-4o-based agentic pipeline with triplicate majority voting to semantically validate 2,502 repositories as genuine DDD implementations. The pipeline is validated against a manually labelled sample of 50 repositories (reported κ = 0.77). The paper then characterises the verified dataset along six dimensions: temporal evolution, architectural styles, exemplary projects, ownership, technology/business ecosystems, and community engagement. Key findings include a 2017 inflection point in adoption, C# dominance (34%), Layered/Clean Architecture prevalence, and median project longevity of 340 days.

Significance. The paper addresses a genuine gap: prior DDD research is overwhelmingly theoretical, and no large-scale empirical characterisation exists. The use of an agentic LLM pipeline for semantic validation at scale is a methodologically interesting contribution that goes beyond keyword matching. The noise rate benchmarks per discovery query (Table 4) are a useful, transferable contribution for future MSR studies. The dataset and code are stated to be available, and the triplicate majority-vote design with internal consistency reporting (κ ≥ 0.96) is a reasonable approach to mitigating LLM non-determinism. The finding that C# and TypeScript, not Java, dominate practical DDD adoption is a concrete, falsifiable claim that challenges the academic status quo.

major comments (3)
  1. §3.7.2, Table 3: The paper headlines κ = 0.77 as the agreement between the LLM pipeline and human experts, but Table 3 reveals that this value holds only when Assessor 1 (A1) is the reference. Against Assessor 2 (A2), the LLM achieves only κ = 0.54 (moderate agreement), with F1 dropping from 92.5% to 85.3%. The paper does not justify why A1 is treated as the ground-truth reference rather than A2, or rather than a reconciled label. Since the two human raters themselves agree at only κ = 0.77 (with 5 disagreements on 50 cases), the choice of reference is not innocuous. All downstream findings — language distribution, architectural style breakdowns, longevity statistics — depend on the 2,502-repository dataset produced by this pipeline. The paper should either (a) justify the choice of A1 as reference with explicit criteria, or (b) report results against the reconciled ground-truth labels (
  2. §3.7.2: The 50-repository validation sample is drawn randomly from the 4,206 candidate pool, but the paper does not report whether the sample was stratified by language, repository size, or discovery source. Two known structural asymmetries in the pipeline create risk that unstratified validation overestimates performance: (a) source files were inspected only for 7 language extensions (.java, .cs, .ts, .js, .py, .php, .go), with the remaining ~4.7% of repositories assessed from metadata and directory structure alone (Table 2 note); and (b) for 16.7% of repositories exceeding the 300-file path cap, only the first 300 paths in database storage order were visible to the model (§3.6). If the validation sample underrepresents these harder cases (non-top-7 languages and large repositories), the κ = 0.77 may not generalise. The paper should report the composition of the 50-sample by language, (
  3. §3.6, §4.2: The architectural style classification is produced by the same GPT-4o pipeline and validated only indirectly. The paper reports a unanimous agreement rate of 88.05% for architectural labels across the three LLM runs (§3.7.1) but does not report LLM-vs-human agreement for the architectural style label specifically — only for the binary isDDD label. Since RQ2's central finding (Layered Architecture at 28.9%, Clean Architecture at 22.78%) is load-bearing for the paper's architectural characterisation, the absence of human validation for the multi-class architectural label is a gap. The paper should either add human-validated architectural labels for the 50-sample or explicitly downgrade the RQ2 claims to
minor comments (8)
  1. §1, Introduction: The phrase 'first large-scale characterisation' is used multiple times. Consider softening to 'first large-scale MSR characterisation of DDD on GitHub' to be precise about scope.
  2. §3.6: The temperature is fixed at 0 and random seed at 42. It would help to note whether the Azure OpenAI API guarantees deterministic output at temperature 0, as some providers do not.
  3. Table 4: The 'Other specific topics' row aggregates three low-frequency queries. Consider listing them individually in a footnote for full reproducibility, as is partially done in the caption.
  4. §4.1.3: The minimum longevity of -1,697.07 days is reported without explanation in the results section (it is explained later in §7.4). Consider adding a brief parenthetical note at first mention.
  5. §4.5.2: The business domain classification uses a 'rule-based keyword classification' (§3.8) but the exact keyword-to-domain mapping is not provided. Consider including it as supplementary material.
  6. §3.7.1: The Disagreement Rate is reported as 5.20%, but the Majority Agreement Rate is 99.95%. These should sum to 100% if they are complementary; clarify whether the 5.20% refers to the rate of 2-1 splits among all repositories or among the subset that did not reach unanimous agreement.
  7. Figure 2: The caption mentions 'up to eight conversation turns' but the text does not specify what happens if the model does not reach a verdict within eight turns. Clarify.
  8. §4.6.1: The comparison to automotive software medians (24 stars, 9 forks) cites [18, 19], but [19] is Cosentino et al., a systematic mapping study, not a landscape study reporting star/fork medians. Verify the citation.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for a careful and constructive review. All three major comments identify legitimate methodological gaps that we will address in the revision. Specifically: (1) we will report results against reconciled ground-truth labels rather than a single assessor, and justify the reference choice; (2) we will report the composition of the 50-repository validation sample by language, repository size, and discovery source, and discuss stratification implications; (3) we will add human-validated architectural labels for the 50-sample and, where LLM-vs-human agreement for the multi-class architectural label is insufficient, explicitly downgrade RQ2 claims to indicative rather than definitive.

read point-by-point responses

  1. Referee: §3.7.2, Table 3: κ=0.77 holds only against Assessor 1; against Assessor 2, κ=0.54. The paper does not justify why A1 is the ground-truth reference. Should either justify A1 or report against reconciled labels.

    Authors: The referee is correct. The choice of A1 as the sole reference was not justified, and the discrepancy between κ=0.77 (vs. A1) and κ=0.54 (vs. A2) is material. We will revise the paper to report LLM performance against the reconciled ground-truth labels (the 50 cases resolved through joint discussion between A1 and A2) as the primary reference, rather than a single assessor. We will retain the per-assessor breakdown in Table 3 for transparency. This is a straightforward revision: the reconciled labels already exist in our data, and we will recompute agreement, precision, recall, and F1 against them. We expect the reconciled-reference metrics to fall between the two assessor-specific values, and we will report them honestly regardless of where they land. We will also add an explicit sentence acknowledging that the two human raters themselves agree at only κ=0.77, which bounds the ceiling of any LLM-vs-human validation on this sample. revision: yes

  2. Referee: §3.7.2: The 50-repository validation sample was drawn randomly without reported stratification by language, size, or discovery source. Known structural asymmetries (non-top-7 languages assessed from metadata alone; 16.7% of repositories exceeding the 300-file cap) create risk that unstratified validation overestimates performance.

    Authors: The referee raises a valid concern. We did not stratify the 50-repository validation sample, and we did not report its composition. We will address this in two ways. First, we will report the composition of the 50-sample by primary language, repository size (file count), and discovery source (topic-based vs. README-based), so readers can assess representativeness. Second, we will add an explicit discussion in Section 7 (Threats to Validity) acknowledging that if the sample underrepresents the harder cases — non-top-7-language repositories (assessed from metadata and directory structure alone) and large repositories exceeding the 300-file path cap — the reported κ may overestimate pipeline performance on those subpopulations. We cannot retroactively stratify the existing sample without relabelling a new stratified set, which would require additional manual annotation beyond the scope of this revision. We will therefore be transparent about the limitation and frame the κ=0.77 as a best-case estimate for the harder cases, while noting that the top-7 languages cover 95.29% of the candidate pool, limiting the practical impact of this concern for the majority of the dataset. revision: partial

  3. Referee: §3.6, §4.2: Architectural style classification is produced by the same GPT-4o pipeline and validated only indirectly (88.05% unanimous agreement across LLM runs). No LLM-vs-human agreement is reported for the multi-class architectural label, only for the binary isDDD label. RQ2 findings (Layered 28.9%, Clean 22.78%) are load-bearing and lack human validation.

    Authors: This is a fair and important point. The binary isDDD label was validated against human judgement, but the multi-class architectural style label was not. We will add human-validated architectural labels for the 50-repository sample. Both assessors already inspected these repositories for the binary DDD judgement; we will extend the existing labelling to include the dominant architectural style for each repository, compute LLM-vs-human agreement for the multi-class label, and report the results in a revised Section 3.7.2. If the agreement is substantially lower than for the binary label — which is plausible given the greater subjectivity of multi-class architectural classification — we will explicitly downgrade the RQ2 claims from definitive distributional findings to indicative of dominant structural tendencies, consistent with the hedging language already present in Section 3.7.1. We note that the manuscript already states: 'We therefore treat the resulting distribution as indicative of dominant structural tendencies within the ecosystem rather than definitive architectural ground truth' (Section 3.7.1). We will strengthen this framing in the RQ2 results section itself, not only in the reliability discussion. revision: yes

Circularity Check

1 steps flagged

No significant circularity; one minor self-citation chain that is not load-bearing for the empirical findings

specific steps
  1. self citation load bearing [Section 1, paragraph 3; Section 2, paragraph 1; Section 5.1]
    "Our prior Systematic Literature Review (SLR) revealed that approximately 39% of DDD studies lack rigorous empirical evaluation, relying instead on subjective observations rather than data-driven baselines [3]. ... Our trend analysis (RQ1) identifies 2017 as a critical turning point for the DDD paradigm in open source. ... This trend aligns with our systematic literature review, which noted a peak in research interest starting in 2017 as the community shifted focus toward modern architectural challenges like microservices [3]."

    Reference [3] is the authors' own prior SLR (Özkan, Babur, van den Brand). It is cited to motivate the research gap (39% lack empirical evaluation), to justify the keyword set (Table 1), and to corroborate the 2017 inflection point. However, this self-citation is not circular in the formal sense: the present paper's empirical findings (2,502 repositories, language distribution, longevity metrics, architectural styles) are derived from the GPT-4o pipeline and GitHub data, not from the SLR. The SLR provides context and motivation, but the results stand independently. The 2017 inflection point in the SLR concerned research interest; the present paper's 2017 inflection point concerns repository creation — related but not identical claims. This is normal scholarly continuity, not circularity.

full rationale

This is an empirical MSR study whose central claims are derived from an independent data pipeline (GitHub API mining + GPT-4o semantic validation), not from theoretical premises or self-citations. The main potential concern — that the GPT-4o pipeline both defines the dataset and is validated against it — is not circular in the formal sense because the 50-repository manual validation (Section 3.7.2) uses independent human expert labels, not the pipeline's own output. The noise rate analysis (Table 4) does compare candidates to the pipeline's verdict, but this is presented as a characterization of discovery-source quality, not as a prediction or first-principles derivation. The self-citation to the authors' prior SLR [3] is motivational and contextual, not load-bearing for any empirical result. The κ=0.77 agreement metric is computed against an independently constructed ground truth. No step in the derivation chain reduces to its own inputs by construction. The paper is self-contained against external benchmarks (GitHub population statistics from [7], language popularity from TIOBE, organizational ownership rates from prior landscape studies). Score of 2 reflects the minor self-citation chain that, while not circular, does provide some of the framing for the study.

Axiom & Free-Parameter Ledger

5 free parameters · 4 axioms · 0 invented entities

No new entities are postulated. This is an empirical study that characterizes existing software artifacts.

free parameters (5)
  • Temperature = 0
    Fixed GPT-4o temperature to eliminate non-deterministic variance (Section 3.6).
  • Random seed = 42
    Fixed seed for reproducibility of GPT-4o runs (Section 3.6).
  • File path limit = 300
    Cap on source file paths visible to the LLM per repository (Section 3.6).
  • Minimum commits threshold = 10
    Inclusion criterion for engineered systems (Table 2, I4).
  • Keyword set = 11 keywords (Table 1)
    Curated DDD-specific search terms derived from Evans [1] and the authors' SLR [3].
axioms (4)
  • domain assumption GitHub topics and README keywords are reasonable proxies for discovering DDD repositories
    Section 3.3: the hybrid discovery strategy assumes that repositories implementing DDD will use DDD-related topics or keywords in their README. The authors acknowledge recall bias from inconsistent topic labeling.
  • ad hoc to paper GPT-4o can serve as a reliable proxy for expert architectural classification of DDD patterns
    Section 3.6: the entire dataset depends on the LLM's ability to identify structural DDD intent from source code. Validated on 50 repositories (Section 3.7.2) but applied to 4,206.
  • domain assumption Repository metadata (stars, forks, commits, longevity) are valid indicators of project maturity and professional-grade engineering
    Section 4: longevity, contributor count, and PR merge latency are used as proxies for engineering rigor, following prior MSR literature [7, 18, 35].
  • domain assumption The 16-domain business taxonomy of Saeedi Nikoo et al. [21] is applicable to DDD repositories
    Section 3.8.2: business domains are mapped to an externally validated taxonomy, but the keyword-to-domain mapping is hand-crafted (Section 7.2).

pith-pipeline@v1.1.0-glm · 26826 in / 3692 out tokens · 232051 ms · 2026-07-08T04:34:21.035136+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

45 extracted references · 45 canonical work pages · 2 internal anchors

  1. [1]

    Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, Boston, 2004

    E. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, Boston, 2004

    work page 2004

  2. [2]

    Spinellis, P

    D. Spinellis, P. Louridas, M. Kechagia, Software evolution: The lifetime of fine-grained elements, PeerJ Computer Science 7 (2021) e372. doi:10. 7717/peerj-cs.372

    work page 2021

  3. [3]

    Özkan, Ö

    O. Özkan, Ö. Babur, M. van den Brand, Domain-driven design in software development: A systematic literature review on implementa- tion, challenges, and effectiveness, Journal of Systems and Software 230 (2025) 112537. doi:10.1016/j.jss.2025.112537

    work page doi:10.1016/j.jss.2025.112537 2025

  4. [4]

    Vernon, Implementing Domain-Driven Design, Addision-Wesley, Up- per Saddle River, NJ, 2013

    V. Vernon, Implementing Domain-Driven Design, Addision-Wesley, Up- per Saddle River, NJ, 2013

    work page 2013

  5. [5]

    Özkan, Ö

    O. Özkan, Ö. Babur, M. Van Den Brand, Refactoring with domain- driven design in an industrial context: An action research re- port, Empirical Software Engineering 28 (2023) 94. doi:10.1007/ s10664-023-10310-1

    work page 2023

  6. [6]

    Güemes-Peña, C

    D. Güemes-Peña, C. López-Nozal, R. Marticorena-Sánchez, J. Maudes- Raedo, Emerging topics in mining software repositories: Machine learn- ing in software repositories and datasets, Progress in Artificial Intelli- gence (2018)

    work page 2018

  7. [7]

    Kalliamvakou, G

    E. Kalliamvakou, G. Gousios, K. Blincoe, L. Singer, D. M. German, D. Damian, An in-depth study of the promises and perils of mining github, Empirical Software Engineering 21 (2016) 2035–2071. doi:10. 1007/s10664-015-9393-5

    work page 2016

  8. [8]

    How are Software Repositories Mined? A Systematic Literature Review of Workflows, Methodologies, Reproducibility, and Tools

    A. Tutko, A. Mockus, A. Z. Henley, How are Software Repositories Mined? A Systematic Literature Review of Workflows, Methodologies, Reproducibility, and Tools, arXiv preprint arXiv:2204.08108 (2022). URL:https://arxiv.org/abs/2204.08108

    work page internal anchor Pith review Pith/arXiv arXiv 2022

  9. [9]

    X. Hou, Y. Zhao, Y. Liu, Z. Yang, K. Wang, L. Li, X. Luo, D. Lo, J. Grundy, H. Wang, Large language models for software engineering: A systematic literature review, ACM Transactions on Software Engi- neering and Methodology 33 (2024) 1–79. doi:10.1145/3695988. 42

    work page doi:10.1145/3695988 2024

  10. [10]

    Gamma, R

    E. Gamma, R. Helm, R. E. Johnson, J. Vlissides, Design patterns: el- ements of reusable object-oriented software, Addison-Wesley, Reading, MA, 2009

    work page 2009

  11. [11]

    Buschmann (Ed.), Pattern-oriented software architecture: a system of patterns, Wiley, Chichester ; New York, 1996

    F. Buschmann (Ed.), Pattern-oriented software architecture: a system of patterns, Wiley, Chichester ; New York, 1996

    work page 1996

  12. [12]

    Brandolini, Introducing eventstorming âĂŞ an explosive model- ing technique for lean discovery,https://ziobrando.blogspot.com/ 2013/11/introducing-eventstorming.html, 2013

    A. Brandolini, Introducing eventstorming âĂŞ an explosive model- ing technique for lean discovery,https://ziobrando.blogspot.com/ 2013/11/introducing-eventstorming.html, 2013

    work page 2013

  13. [13]

    Uludağ, M

    Ö. Uludağ, M. Kleehaus, F. Matthes, Supporting large-scale agile de- velopment with domain-driven design, in: Agile Processes in Soft- ware Engineering and Extreme Programming (XP 2018), volume 314 ofLecture Notes in Business Information Processing, Springer, 2018. doi:10.1007/978-3-319-91602-6\_16

    work page doi:10.1007/978-3-319-91602-6 2018

  14. [14]

    Krause, C

    A. Krause, C. Zirkelbach, W. Hasselbring, S. Lenga, D. Kröger, Mi- croservice decomposition via static and dynamic analysis of the mono- lith, in: 2020 IEEE International Conference on Software Archi- tecture Companion (ICSA-C), IEEE, 2020, pp. 9–16. doi:10.1109/ ICSA-C50368.2020.00011

    work page arXiv 2020

  15. [15]

    Maddodi, S

    G. Maddodi, S. Jansen, M. Overeem, Aggregate architecture simu- lation in event-sourcing applications using layered queuing networks, in: Proceedings of the ACM/SPEC International Conference on Perfor- mance Engineering (ICPE ’20), ACM, 2020, pp. 238–245. doi:10.1145/ 3358960.3375797

    work page arXiv 2020

  16. [16]

    Robles, M

    G. Robles, M. R. V. Chaudron, R. Jolak, R. Hebig, A reflection on the impact of model mining from GitHub, Information and Software Technology 164 (2023) 107317. doi:10.1016/j.infsof.2023.107317

    work page doi:10.1016/j.infsof.2023.107317 2023

  17. [17]

    Hebig, T

    R. Hebig, T. Ho-Quang, M. R. V. Chaudron, G. Robles, M. A. Fernán- dez, The quest for open source projects that use UML: Mining GitHub, in: Proceedings of the ACM/IEEE 19th International Conference on Model Driven Engineering Languages and Systems (MODELS), ACM, 2016, pp. 173–183. doi:10.1145/2976767.2976778

    work page doi:10.1145/2976767.2976778 2016

  18. [18]

    Kochanthara, Y

    S. Kochanthara, Y. Dajsuren, L. Cleophas, M. van den Brand, Painting the landscape of automotive software in github, in: Proceedings of the 43 19th International Conference on Mining Software Repositories, MSR ’22, Association for Computing Machinery, New York, NY, USA, 2022, pp. 1–12. URL:https://doi.org/10.1145/3524842.3528460. doi:10. 1145/3524842.3528460

    work page doi:10.1145/3524842.3528460 2022

  19. [19]

    Cosentino, J

    V. Cosentino, J. L. Cánovas Izquierdo, J. Cabot, A systematic mapping study of software development with github, IEEE Access 5 (2017) 7173–

    work page 2017

  20. [20]

    doi:10.1109/ACCESS.2017.2682323

    work page doi:10.1109/access.2017.2682323 2017

  21. [21]

    E. S. Rigas, M. Papoutsoglou, G. M. Kapitsaki, N. Bassiliades, Min- ing software repositories to identify electric vehicle trends: The case of GitHub, in: Proceedings of the 2023 IEEE/ACM International Confer- ence on Software Engineering, 2023

    work page 2023

  22. [22]

    Saeedi Nikoo, S

    M. Saeedi Nikoo, S. Kochanthara, O. Babur, M. van den Brand, An empirical study of business process models and model clones on github, Empirical Software Engineering 30 (2025). doi:10.1007/ s10664-024-10584-z

    work page 2025

  23. [23]

    Industry classification taxonomy origi- nally developed in 1999

    MSCI and S&P Dow Jones Indices, Global industry classifica- tion standard (GICS) methodology,https://www.msci.com/indexes/ index-resources/gics, 2024. Industry classification taxonomy origi- nally developed in 1999

    work page 2024

  24. [24]

    Originally the Reuters Business Sector Scheme (2004)

    Refinitiv (London Stock Exchange Group), The refini- tiv business classification (TRBC) methodology,https: //www.lseg.com/en/data-analytics/financial-data/indices/ trbc-business-classification, 2020. Originally the Reuters Business Sector Scheme (2004)

    work page 2020

  25. [25]

    Hindle, N

    A. Hindle, N. A. Ernst, M. W. Godfrey, J. Mylopoulos, Automated topic naming to support cross-project analysis of software maintenance activities, in: Proceedings of the 8th Working Conference on Mining Software Repositories, ACM, Waikiki, Honolulu HI USA, 2011, pp. 163–

    work page 2011

  26. [26]

    doi:10.1145/1985441.1985466

    work page doi:10.1145/1985441.1985466

  27. [27]

    Panichella, B

    A. Panichella, B. Dit, R. Oliveto, M. Di Penta, D. Poshynanyk, A. De Lucia, How to effectively use topic models for software engineering tasks? An approach based on Genetic Algorithms, in: 2013 35th Inter- national Conference on Software Engineering (ICSE), IEEE, San Fran- cisco, CA, USA, 2013, pp. 522–531. doi:10.1109/ICSE.2013.6606598. 44

    work page doi:10.1109/icse.2013.6606598 2013

  28. [28]

    AlMarzouq, A

    M. AlMarzouq, A. AlZaidan, J. AlDallal, Mining github for re- search and education: challenges and opportunities, International Journal of Web Information Systems 16 (2020) 451–473. doi:10.1108/ IJWIS-03-2020-0016

    work page 2020

  29. [29]

    Ralph, N

    P. Ralph, N. bin Ali, S. Baltes, D. Bianculli, J. Diaz, Y. Dittrich, N. Ernst, M. Felderer, R. Feldt, A. Filieri, B. B. N. de França, C. A. Furia, G. Gay, N. Gold, D. Graziotin, P. He, R. Hoda, N. Juristo, B. Kitchenham, V. Lenarduzzi, J. Martínez, J. Melegati, D. Mendez, T. Menzies, J. Molleri, D. Pfahl, R. Robbes, D. Russo, N. Saarimäki, F. Sarro, D. Ta...

    work page doi:10.48550/arxiv.2010.03525 2020

  30. [30]

    Accessed 2025

    GitHub, About github,https://github.com/about, 2025. Accessed 2025

    work page 2025

  31. [31]

    A. Liew, K. Mueller, Using Large Language Models to Generate En- gaging Captions for Data Visualizations (2022). doi:10.48550/ARXIV. 2212.14047

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv 2022

  32. [32]

    Chabert, P.-A

    L. Chabert, P.-A. Jouve, T. D’Hondt, O. Mégret, X. Blanc, Mining experienced developers in open-source projects, in: Proceedings of the 17th International Conference on Mining Software Repositories (MSR), 2022, pp. 23–34. doi:10.1109/MSR55620.2022.00010

    work page doi:10.1109/msr55620.2022.00010 2022

  33. [33]

    D. Maia, C. Spinu, F. Anós, A systematic literature review on data cleaningandfilteringinminingsoftwarerepositories, EmpiricalSoftware Engineering 27 (2022) 1–53

    work page 2022

  34. [34]

    T. O. Kvålseth, Note on Cohen’s Kappa, Psychological Reports 65 (1989) 223–226. doi:10.2466/pr0.1989.65.1.223

    work page doi:10.2466/pr0.1989.65.1.223 1989

  35. [35]

    J. R. Landis, G. G. Koch, The measurement of observer agreement for categorical data, Biometrics 33 (1977) 159–174. doi:10.2307/2529310

    work page doi:10.2307/2529310 1977

  36. [36]

    Z. Liao, B. Zhao, S. Liu, H. Jin, D. He, L. Yang, Y. Zhang, J. Wu, A Prediction Model of the Project Life-Span in Open Source Software Ecosystem, Mobile Networks and Applications 24 (2019) 1382–1391. doi:10.1007/s11036-018-0993-3. 45

    work page doi:10.1007/s11036-018-0993-3 2019

  37. [37]

    Munaiah, S

    N. Munaiah, S. Kroh, C. Cabrey, M. Nagappan, Curating github for engineered software projects, Empirical Software Engineering 22 (2017) 3219–3253. doi:10.1007/s10664-017-9512-6

    work page doi:10.1007/s10664-017-9512-6 2017

  38. [38]

    com/2020/, 2020

    GitHub, The state of the octoverse 2020,https://octoverse.github. com/2020/, 2020

    work page 2020

  39. [39]

    Hippchen, P

    B. Hippchen, P. Giessler, R. H. Steinegger, M. Schneider, S. Abeck, Designing microservice-based applications by using a domain-driven de- sign approach, International Journal on Advances in Software 10 (2017) 432–445

    work page 2017

  40. [40]

    Kapferer, O

    S. Kapferer, O. Zimmermann, Domain-driven service design: Con- text modeling, model refactoring and contract generation, in: Service- Oriented Computing (SummerSoC 2020), volume 1310 ofCommunica- tions in Computer and Information Science, Springer, 2020, pp. 189–

    work page 2020

  41. [41]

    doi:10.1007/978-3-030-64846-6\_11

    work page doi:10.1007/978-3-030-64846-6

  42. [42]

    Accessed: 2026-07-07

    TIOBE Software BV, TIOBE index,https://www.tiobe.com/ tiobe-index/, 2026. Accessed: 2026-07-07

    work page 2026

  43. [43]

    A. Ait, J. L. Cánovas Izquierdo, J. Cabot, An empirical study on the survivalrateofgithubprojects, in: Proceedingsofthe19thInternational Conference on Mining Software Repositories (MSR), IEEE/ACM, 2022, pp. 365–375. doi:10.1145/3524842.3527941

    work page doi:10.1145/3524842.3527941 2022

  44. [44]

    M. I. Josélyne, D. Tuheirwe-Mukasa, B. Kanagwa, J. Balikuddembe, Partitioning microservices: A domain engineering approach, in: Pro- ceedings of the International Conference on Software Engineering in Africa (SEiA), ACM, 2018, pp. 43–49

    work page 2018

  45. [45]

    Wohlin, P

    C. Wohlin, P. Runeson, M. Höst, M. C. Ohlsson, B. Regnell, A. Wesslén, Experimentation in Software Engineering, Springer Science & Business Media, 2012. 46

    work page 2012