Pith. sign in

REVIEW 3 major objections 5 minor 47 references

Making AI Visible, Not Vanished: How AI Policies Reshape Developer Experience on GitHub

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Open-source AI policies regulate rather than prohibit AI-assisted development, and adopting them improves disclosure, review, and code quality.

desk verdict Large-scale map of AI policies is a real contribution, but the causal estimates collapse on the carry-over labeling rule. read the letter →

arxiv 2608.03329 v1 pith:GIP7MXIQ submitted 2026-08-04 cs.SE

Yunqi Chen , Thomas Zimmermann , Bianca Trinkenreich This is my paper · ORCID
classification cs.SE
keywords AIgovernanceopensourcesoftwareGitHubdifference-in-differencesdeveloperexperienceTRACEframeworkAI-assisteddevelopmentpropensityscorematching
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

Open-source projects are starting to write policies for AI-assisted contributions, and this paper asks what those policies do. The authors claim that such policies mostly regulate rather than prohibit AI-assisted development, and that adoption itself changes behavior: after a policy lands, maintainers engage more, developers disclose AI use more often, reviews become more interactive, and code quality metrics improve, while AI-assisted contributions keep growing. They reach this using 29,624 GitHub repositories, 385 actual policy adoptions, and a matched-control difference-in-differences design. If true, it means OSS communities can deliberately shape AI use through governance choices, and that transparency-and-responsibility-oriented policies work better than restriction alone.

What carries the argument

The TRACE framework, which codes each policy on five ordered dimensions—Transparency, Responsibility, Attribution, Constraints, and Enforcement—plus a rule-based classification of policies into five governance families. The causal estimates come from a staggered difference-in-differences design with propensity-score matched never-treated controls, event-study parallel-trend tests, and 19 outcomes organized by the SPACE developer-productivity lens.

What would settle it

Recompute the headline outcomes labeling AI-assisted PRs only by explicit structural signals (agent branches, co-author trailers, self-disclosure) and not by carry-over author history. If the post-adoption increase in AI-assisted PR share and throughput shrinks to zero or reverses specifically in repositories whose policies mandate disclosure, the causal claim would be falsified; if the increase persists, the carry-over assumption is not the driver.

Watch

Extended reading notes

Core claim

Policy adoption is best described as governed permission, not prohibition. Across 385 projects, disclosure requirements and human-validation mandates are the most common provisions, while strict bans are a minority family. Quasi-experimental estimates show that after adoption, maintainer-responded PR share rises, AI-disclosure share and AI-assisted PR share both rise, review turns and reviewers per PR increase, and static-analysis quality metrics (vulnerabilities, duplicated lines, code smells, cognitive complexity) improve. The effects vary systematically with policy content: higher Transparency levels amplify disclosure and participation, Responsibility level 4 improves review engagement a

Load-bearing premise

The load-bearing assumption is that a developer who ever shows an AI signal continues to use AI in all later pull requests: without that carry-over label, the measured AI-assisted share and throughput growth after policy adoption could be an artifact of new disclosure markers rather than a real change in AI use.

Editorial extensions

If this is right

  • Adopting any explicit AI policy appears to increase maintainers' attention: maintainer-responded PR share rises and LOC per reviewer falls.
  • Requiring AI disclosure does not suppress AI use; AI-assisted PR share and disclosure share rise together after adoption.
  • Transparency and responsibility provisions produce stronger community and quality gains than restrictive provisions alone.
  • Strict prohibition reduces AI-assisted throughput but not to zero, and is associated with the largest quality improvements, suggesting bans filter rather than eliminate.
  • Silence has a cost: quiet policies are the only family with a net reduction in AI-assisted activity, and opaque restriction lowers engagement.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Carry-over labeling: the paper labels every later PR by a developer as AI-assisted once that developer shows any AI signal; if policies themselves trigger new disclosure markers, part of the measured increase in AI-assisted share could reflect detector sensitivity rather than behavior. A sensitivity analysis using only explicit structural signals would test this.
  • The 8-week post-treatment window means the results are short-run; whether policies cool off, harden, or get revised after longer exposure is untested.
  • The TRACE dimensions map naturally onto enterprise AI governance, so a comparable matched-cohort study inside firms could test whether transparency-plus-responsibility beats restriction there too.
  • Policy formation is left unstudied; tracing whether policies emerge from maintainer mandates or contributor deliberation would separate legitimacy effects from mere rule effects.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper studies AI governance policies in open-source software by analyzing 29,624 GitHub repositories and identifying 385 projects that adopted an AI policy between February 2025 and April 2026. It introduces the TRACE framework (Transparency, Responsibility, Attribution, Constraints, Enforcement), classifies policies into five families, and estimates treatment effects using propensity-score matching and staggered difference-in-differences on 19 SPACE-inspired outcome variables. The headline findings are that policy adoption is associated with increased maintainer engagement, more AI disclosure, richer review interactions, improved code-quality metrics, and continued growth of AI-assisted contributions, with specific dimension- and family-level heterogeneity. The paper argues that AI governance mostly regulates rather than prohibits AI-assisted development.

Significance. If the estimates are valid, this is a valuable first large-scale empirical account of AI governance in OSS, with a reusable taxonomy (TRACE) and a plausible causal framework. The paper's strengths include its large corpus, manual validation and inter-rater reliability checks, a replication package, propensity-score matching, staggered DiD modeling, event-study pre-trend tests for all 19 outcomes, and multiple post-treatment windows. However, the central AI-activity and disclosure outcomes are measured in ways that are entangled with the policy treatment itself, so the headline magnitudes are not yet credible. The paper is a solid empirical contribution that needs substantial robustness work before its policy conclusions can be accepted.

major comments (3)
  1. [Section III-G; Table II] The AI-assisted PR outcome is defined by direct structural signals (agent branches/labels, co-author trailers, self-disclosure) plus a carry-forward rule: once an author is identified as using AI, all subsequent PRs by that author are labeled AI-assisted. Several treatment policies (e.g., vLLM, Ghostty) explicitly require disclosure phrases or Co-authored-by trailers, so a compliant PR triggers the carry-over and all later PRs by that author count as AI-assisted regardless of actual AI use. The estimated +6.8pp AI-assisted PR share and +10% throughput (Table II) may therefore reflect increased detector sensitivity rather than a behavioral increase in AI tool use. Section VI varies the post-treatment window but never sensitivity-tests the labeling rule. Please add analyses that (i) restrict the outcome to signals not mandated by policy text, (ii) remove or cap the carry-forward component,
  2. [Section III-G; Table II] The AI-disclosure PR count and share are keyword matches for phrases such as "generated by" and "AI-assisted" in PR descriptions. For policies that mandate specific disclosure language, this outcome largely measures compliance with the policy itself, not an independent behavioral response. The +11% disclosure count and +4.2pp disclosure share could arise even if developer behavior were unchanged. The paper should reframe this outcome as compliance with transparency mandates and add robustness checks, e.g., excluding policies that prescribe exact disclosure wording, or measuring disclosure with phrases not mentioned in the policy text. As it stands, the disclosure results are partly circular with the treatment definition.
  3. [Section III-B; Section V] There is an inconsistency in the post-treatment window: Section III-B says the sample is restricted to ensure "an 8-week pre-treatment and a 4-week post-treatment time window," but Section V reports the main effects using an 8-week post-treatment window and calls the 4-week version a robustness check. This matters for the adoption cutoff: the data are described as spanning January 2025 to May 2026, and adoptions through April 30, 2026 cannot all have eight post-treatment weeks within that span. Please state the exact post-treatment horizon used in Tables II–IV and reconcile it with the adoption date restriction and data-end date.
minor comments (5)
  1. [Throughout] There are several typos and grammatical errors: "specilized," "qualtitive," "introduing," "Rs" for pull requests, and "The each family ATT" in Section III-H. A careful proofreading pass is needed.
  2. [Figure 2] The event-study figure shows only 10 of the 19 outcome variables, while the text states that all 19 passed the parallel-trends test. Please indicate where the remaining outcomes are shown or add an appendix figure; also clarify whether any multiple-comparison adjustment was applied across the 19 pre-trend tests.
  3. [Table III] The header "/banCommunication" should be "/banConstraints" or similar. Also, the family column header "Disclosed Soft-Enforced" should match the family name "Disclosed but Soft-Enforced" used in Section IV-B.
  4. [Section III-B] The abbreviation "SEART-GHS" appears inconsistent with the SEART-GitHub name in the reference [27]. Please verify the tool name and capitalization.
  5. [Section IV; Table I] In Observation 1, the text says "T3–T4, 66.0%," which is arithmetically correct (116+138 = 254; 254/385 = 65.97%), but the phrase "no disclosure required" at T1 and "encouraged/voluntary" at T2 could be more clearly distinguished from the ordinary review process; consider adding example quotes for T2 and T3 as is done for other levels.

Circularity Check

2 steps flagged · score 6.0 of 10

Partially circular: AI-assisted activity and disclosure outcomes are measured via the same structural signals that the policies mandate; carry-over labeling inflates the headline 'AI-assisted contributions continue to grow.'

  1. self definitional [Section III-G (Outcome Variables, Performance and Activity); results in Section V-A Table II and Observation 3]
    "We identified AI-assisted PR with direct structural signals (agent branches or labels, co-author trailers, or self-disclosure) [29]. Assuming developers continue to use AI tools after initial adoption, we labeled all subsequent PRs by the same author as AI-assisted."

    The outcome is detected from co-author trailers and self-disclosure, and the treatment policies mandate exactly those signals: vLLM 'requires contributors to disclose AI assistance in PR descriptions and attribute AI tools via commit trailers such as Co-authored-by' (Section IV-B), and Ghostty requires 'All AI usage in any form must be disclosed' (Section IV-A). A single compliant PR triggers the carry-over rule, so every later PR by that author is counted AI-assisted regardless of actual tool use. The reported gains in AI-assisted PR share (+6.8pp) and throughput (+10%) in Table II are therefore at least partly manufactured by the outcome definition; robustness checks vary the time window but never sensitivity-test the labeling rule.

  2. self definitional [Section III-G (Communication & Collaboration outcomes); results in Section V-A Table II; policy text in Section IV-A]
    "AI-disclosure PR count counts PRs containing AI self-disclosure phrases (“generated by,” “written by AI,” “AI-assisted,” and similar phrases), detected via keyword-based matching on PR descriptions."

    The outcome is a keyword match for disclosure phrases, and the treatment consists of policies that require those phrases. Repositories such as Coder require contributors to 'disclose AI involvement in the pull request description whenever these guidelines apply,' and Ghostty requires 'All AI usage in any form must be disclosed. You must state the tool you used along with the extent that the work was AI-assisted' (Section IV-A). The estimated +11% disclosure count and +4.2pp disclosure share (Table II) are thus the mandated behavior encoded into the outcome metric; the 'effect' reduces by construction to the policy's own disclosure requirement.

full rationale

The paper is not globally circular. The TRACE framework and family taxonomy are derived directly from policy texts via open coding, and many outcomes (maintainer-responded share, core-developer count, review turns, reviewers/PR, SonarQube quality metrics) are measured independently of the policy text and are not defined in terms of the treatment. No load-bearing self-citation is present: the cited prior work on AI-assisted signal detection [29] is external, and the authors' own prior DiD study [36] is not used to justify a premise. However, two outcome families in the paper's causal claim reduce by construction: AI-disclosure count/share is keyword-matching for phrases that the policies mandate, and AI-assisted PR share/throughput is detected via co-author trailers/self-disclosure combined with a carry-over rule, both of which are directly triggered by policy content. The headline that 'AI-assisted contributions continue to grow' (Table II, Observation 3) therefore is at least partly an artifact of detector sensitivity rather than evidence about actual AI tool use. Since the central 'regulates rather than prohibits' claim relies on these contaminated metrics, the score is 6: partial circularity, while the remaining independent outcomes prevent a higher score.

Assumptions & free parameters 5 free parameters · 6 assumptions · 0 invented entities

No new physical entities are postulated. The TRACE framework and the five governance families are coding schemes, not invented entities in the physics sense. All quantitative assumptions above are unverified domain assumptions that the causal estimates depend on.

free parameters (5)
  • Core-developer top-80% threshold and 12-week rolling window = 80% / 12 weeks
    Hand-chosen thresholds that define which contributors count as core developers, affecting satisfaction and engagement outcomes.
  • 20-treated-policy minimum for reporting TRACE level cells = 20
    Author rule to suppress sparse cells (T2, A2, E2, A4) in Model II.
  • PSM caliper = 0.2 SD
    Standard but arbitrary caliper for nearest-neighbor matching.
  • Adoption time window = Feb 1 2025 to Apr 30 2026
    Chosen to allow pre/post windows, but inconsistent with the 8-week post window actually reported.
  • Post-treatment window length = 8 weeks
    Reported as 8 weeks despite the data description stating a 4-week post-treatment window.
assumptions (6)
  • domain assumption Parallel trends assumption holds for all 19 outcomes after PSM matching.
    Untestable counterfactual; the paper supports it with an event-study test over weeks -8 to -2, but does not report test statistics or multiple-comparison corrections.
  • domain assumption An author flagged once as AI-assisted continues to use AI for all subsequent PRs.
    Section III-G carry-over labeling; directly inflates AI-assisted PR share and throughput after adoption.
  • domain assumption Policy adoption timestamp equals PR merge time (or commit time) of the policy file.
    Section III-B; policies may have been discussed or enforced before the merge, and merged PRs can be edited later, biasing the event time.
  • domain assumption Maintainer identity is recoverable from repository activity data.
    Section III-G defines maintainer-responded outcomes but never gives an operational definition of 'maintainer'.
  • domain assumption SonarQube scans at the last commit of each week are representative of code quality.
    Section III-G; 8% treated and 13% control repos failed to scan, and missingness is not modeled.
  • domain assumption Keyword-based matching on PR descriptions is a valid detector of AI disclosure.
    Section III-G; the keyword list is not reported and the detector's precision/recall are not evaluated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Making AI Visible, Not Vanished: How AI Policies Reshape Developer Experience on GitHub." pith.science (2026). https://pith.science/paper/GIP7MXIQ

@misc{pith2026260803329,
  author       = {Pith},
  title        = {Pith review of: Making AI Visible, Not Vanished: How AI Policies Reshape Developer Experience on GitHub},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/GIP7MXIQ}},
  note         = {Machine review of arXiv:2608.03329}
}
read the original abstract

Generative AI is rapidly reshaping Open Source Software (OSS) software development,prompting projects to introduce policies governing AI-assisted contributions. However, little is known about how these policies differ or whether they influence developer experience. We present the first large-scale empirical study of AI governance policies in OSS. Analyzing 29,624 GitHub repositories, we identify 385 projects that adopted AI policies and derive TRACE, a framework capturing five governance dimensions: Transparency, Responsibility, Attribution, Constraints, and Enforcement. We further classify policies into five governance families and estimate their effects using propensity-score matching and longitudinal difference-in-differences analysis. Our results show that AI governance primarily regulates rather than prohibits AI-assisted development. Policy adoption brings maintainer engagement, increased AI disclosure, richer review interactions, and improved code quality while AI-assisted contributions continue to grow. Governance design matters: policies emphasizing transparency and responsibility produced stronger community and quality outcomes than restrictive approaches alone. Our findings show how different AI governance strategies shape developer experience and provide evidence to help OSS communities design effective AI policies.

Figures

Figures reproduced from arXiv: 2608.03329 by the authors.

Figure 1
Figure 1. Overview of the research design for this paper for [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Event Study of 10 representative outcome variables (mean with 95% CI), treated (solid) and matched control (dashed) repositories over ±8-week [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Monthly/Cumulative adoption trend of AI policies [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: (a) TRACE dimension level distribution across the 385 policies. (b) [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 35 canonical work pages

  1. [1]

    The impact of ai on developer productivity: Evidence from github copilot,

    S. Peng, E. Kalliamvakou, P. Cihon, and M. Demirer, “The impact of ai on developer productivity: Evidence from github copilot,”arXiv preprint arXiv:2302.06590, 2023

    arXiv 2023

  2. [2]

    Measuring github copilot’s impact on productivity,

    A. Ziegler, E. Kalliamvakou, X. A. Li, A. Rice, D. Rifkin, S. Simister, G. Sittampalam, and E. Aftandilian, “Measuring github copilot’s impact on productivity,”Communications of the ACM, vol. 67, no. 3, pp. 54–63, 2024

    2024

  3. [3]

    Large language models for software engineering: A systematic literature review,

    X. Hou, Y . Zhao, Y . Liu, Z. Yang, K. Kocaguneli, D. Demaszy, P. Cian- carini, M. Massolo, M. Marsdenet al., “Large language models for software engineering: A systematic literature review,”ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 33, no. 8, pp. 1–79, 2024

    work page 2024

  4. [4]

    Eghbal,Roads and bridges: The unseen labor behind our digital infrastructure

    N. Eghbal,Roads and bridges: The unseen labor behind our digital infrastructure. Ford Foundation, 2016

    work page 2016

  5. [5]

    Pull request gov- ernance in open source communities,

    A. Alami, R. Pardo, M. L. Cohn, and A. W ˛ asowski, “Pull request gov- ernance in open source communities,”IEEE Transactions on Software Engineering, vol. 48, no. 12, pp. 4838–4856, 2022

    work page 2022

  6. [6]

    Sustaining maintenance labor for healthy open source software projects through human infrastructure: A maintainer perspective,

    J. Linåker, G. Link, and K. Lumbard, “Sustaining maintenance labor for healthy open source software projects through human infrastructure: A maintainer perspective,” inProceedings of the 18th ACM/IEEE Interna- tional Symposium on Empirical Software Engineering and Measurement, 2024, pp. 37–48

    work page 2024

  7. [7]

    Speed at the cost of quality: How cursor ai increases short-term velocity and long-term complexity in open-source projects,

    H. He, C. Miller, S. Agarwal, C. Kästner, and B. Vasilescu, “Speed at the cost of quality: How cursor ai increases short-term velocity and long-term complexity in open-source projects,” inProceedings of the 23rd International Conference on Mining Software Repositories (MSR), 2026

    work page 2026

  8. [8]

    Beyond banning ai: A first look at genai governance in open source software communities,

    W. Yang, R. He, and M. Zhou, “Beyond banning ai: A first look at genai governance in open source software communities,”arXiv preprint arXiv:2603.26487, 2026

    arXiv 2026

Show all 47 references
  1. [9]

    Self-admitted genai usage in open-source software,

    T. Xiao, Y . Fan, F. Calefato, C. Treude, R. G. Kula, H. Hata, and S. Baltes, “Self-admitted genai usage in open-source software,”IEEE Transactions on Software Engineering, 2026

    2026

  2. [10]

    Licoeval: Evaluating llms on license compliance in code generation,

    W. Xu, K. Gao, H. He, and M. Zhou, “Licoeval: Evaluating llms on license compliance in code generation,” in2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE). IEEE, 2025, pp. 1665–1677

    2025

  3. [11]

    Promises, perils, and (timely) heuristics for mining coding agent activity,

    R. Robbes, T. Matricon, T. Degueule, A. Hora, and S. Zacchiroli, “Promises, perils, and (timely) heuristics for mining coding agent activity,” inProceedings of the 23rd International Conference on Mining Software Repositories (MSR), 2026

    2026

  4. [12]

    Unveiling ChatGPT’s usage in open source projects: A mining-based study,

    R. Tufano, A. Mastropaolo, F. Pepe, O. Dabi ´c, M. Di Penta, and G. Bavota, “Unveiling ChatGPT’s usage in open source projects: A mining-based study,”arXiv preprint arXiv:2402.16480, 2024

    2024 arXiv

  5. [13]

    An empirical study on automatically detecting AI-generated source code: How far are we?

    H. Suh, M. Tafreshipour, J. Li, A. Bhattiprolu, and I. Ahmed, “An empirical study on automatically detecting AI-generated source code: How far are we?” inProceedings of the IEEE/ACM 47th International Conference on Software Engineering (ICSE), 2025, pp. 859–871

    2025

  6. [14]

    Who is using AI to code? global diffusion and impact of generative AI,

    S. Daniotti, J. Wachs, X. Feng, and F. Neffke, “Who is using AI to code? global diffusion and impact of generative AI,”Science, vol. 391, no. 6787, pp. 831–835, 2026

    2026

  7. [15]

    LGTM! charac- teristics of auto-merged LLM-based agentic PRs,

    R. Branco, P. Canelas, C. Gamboa, and A. Fonseca, “LGTM! charac- teristics of auto-merged LLM-based agentic PRs,” inProceedings of the 23rd International Conference on Mining Software Repositories (MSR), 2026

    2026

  8. [16]

    On autopilot? an empirical study of human-AI teaming and review practices in open source,

    H. Gao, P. Banyongrakkul, H. Guan, M. Zahedi, and C. Treude, “On autopilot? an empirical study of human-AI teaming and review practices in open source,”arXiv preprint arXiv:2601.13754, 2026

    2026

  9. [17]

    A large-scale survey on the usability of AI programming assistants: Successes and challenges,

    J. T. Liang, C. Yang, and B. A. Myers, “A large-scale survey on the usability of AI programming assistants: Successes and challenges,” inProceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE), 2024, pp. 1–13

    2024

  10. [18]

    Measuring the impact of early-2025 ai on experienced open-source developer productivity,

    J. Becker, N. Rush, E. Barnes, and D. Rein, “Measuring the impact of early-2025 ai on experienced open-source developer productivity,”

    2025

  11. [19]

    The effects of generative ai on high-skilled work: Evidence from three field experiments with software developers,

    K. Z. Cui, M. Demirer, S. Jaffe, L. Musolff, S. Peng, and T. Salz, “The effects of generative ai on high-skilled work: Evidence from three field experiments with software developers,”Management Science, 2026

    2026

  12. [20]

    The impact of generative ai on collaborative open-source software development: Evidence from github copilot,

    F. Song, A. Agarwal, and W. Wen, “The impact of generative ai on collaborative open-source software development: Evidence from github copilot,” 2026. [Online]. Available: https://arxiv.org/abs/2410.02091

    2026 arXiv

  13. [21]

    Death by a thousand slops,

    D. Stenberg, “Death by a thousand slops,” https://daniel.haxx.se/blog/ 2025/07/14/death-by-a-thousand-slops/, 2025, curl project maintainer blog; reports that AI-generated security-vulnerability reports made up a large share of 2025 curl submissions

    2025

  14. [22]

    The flood: AI slop as a DDoS on attention,

    P. Benson, “The flood: AI slop as a DDoS on attention,” Neural Horizons (Substack), 2026, retrieved May 13, 2026. [Online]. Available: https:// neuralhorizons.substack.com/p/the-flood-ai-slop-as-a-ddos-on-attention

    2026

  15. [23]

    Academic journals’ AI policies fail to curb the surge in AI-assisted academic writing,

    Y . He and Y . Bu, “Academic journals’ AI policies fail to curb the surge in AI-assisted academic writing,”Proceedings of the National Academy of Sciences (PNAS), vol. 123, no. 9, p. e2526734123, 2026

    2026

  16. [24]

    Beyond adoption: Examining the evolution and impact of codes of conduct on open source communities,

    J. Sun, H. Fang, J. Zhang, J. Shi, R. Lai, A. Ihuman, R. Littauer, and S. Zhou, “Beyond adoption: Examining the evolution and impact of codes of conduct on open source communities,” inProceedings of the IEEE/ACM 48th International Conference on Software Engineering (ICSE), 2026

    2026

  17. [25]

    Why modern open source projects fail,

    J. Coelho and M. T. Valente, “Why modern open source projects fail,” in Proceedings of the 2017 11th Joint meeting on foundations of software engineering, 2017, pp. 186–196

    2017

  18. [26]

    Replication package — making ai visible, not vanished: How ai policies reshape developer experience on github,

    A. Anonymous, “Replication package — making ai visible, not vanished: How ai policies reshape developer experience on github,” Jun. 2026. [Online]. Available: https://doi.org/10.5281/zenodo.21059330

    2026 doi

  19. [27]

    Sampling projects in github for msr studies,

    O. Dabic, E. Aghajani, and G. Bavota, “Sampling projects in github for msr studies,” in2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE, 2021, pp. 560–564

    2021

  20. [28]

    What the fork: A study of inefficient and efficient forking practices in social coding,

    S. Zhou, B. Vasilescu, and C. Kästner, “What the fork: A study of inefficient and efficient forking practices in social coding,” inProc. ACM/IEEE 27th Europ. Software Engineering Conf./Foundations of Software Engineering (ESEC/FSE), 2019, pp. 350–361

    2019

  21. [29]

    Agentic much? adoption of coding agents on github,

    R. Robbes, T. Matricon, T. Degueule, A. C. Hora, and S. Zacchiroli, “Agentic much? adoption of coding agents on github,”ArXiv, vol. abs/2601.18341, 2026. [Online]. Available: https://api.semanticscholar. org/CorpusID:285050722

    2026 arXiv

  22. [30]

    Autobahn|js: Wamp for browsers and nodejs,

    Crossbar.io Project, “Autobahn|js: Wamp for browsers and nodejs,” https: //github.com/crossbario/autobahn-js, 2026, accessed: 2026-06-29

    2026

  23. [31]

    Wamp ai policy (ai_policy.md),

    W AMP Proto Project, “Wamp ai policy (ai_policy.md),” https://github. com/wamp-proto/wamp-ai/blob/main/AI_POLICY .md, 2024, accessed: 2026-06-29

    2024

  24. [32]

    The measurement of observer agreement for categorical data,

    J. R. Landis and G. G. Koch, “The measurement of observer agreement for categorical data,”biometrics, pp. 159–174, 1977

    1977

  25. [33]

    Minimum wages and employment: A case study of the fast-food industry in New Jersey and Pennsylvania,

    D. Card and A. B. Krueger, “Minimum wages and employment: A case study of the fast-food industry in New Jersey and Pennsylvania,”The American Economic Review, vol. 84, no. 4, pp. 772–793, 1994

    1994

  26. [34]

    J. D. Angrist and J. Pischke,Mostly Harmless Econometrics: An Empiricist’s Companion. Princeton University Press, 2009

    2009

  27. [35]

    “this is damn slick!

    H. Fang, H. Lamba, J. Herbsleb, and B. Vasilescu, ““this is damn slick!”: Estimating the impact of tweets on open source project popularity and new contributors,” inProceedings of the IEEE/ACM 44th International Conference on Software Engineering (ICSE), 2022, pp. 2116–2129

    2022

  28. [36]

    How does core contributor disengagement impact open source project activity? a quasi-experiment,

    Y . Chen, K.-J. Stol, F. M. De Abreu Santos, D. M. German, and B. Trinkenreich, “How does core contributor disengagement impact open source project activity? a quasi-experiment,” inProceedings of the IEEE/ACM 48th International Conference on Software Engineering (ICSE), 2026

    2026

  29. [37]

    Difference-in-differences with variation in treat- ment timing,

    A. Goodman-Bacon, “Difference-in-differences with variation in treat- ment timing,”Journal of Econometrics, vol. 225, no. 2, pp. 254–277, 2021, special issue: Treatment effects 2

    2021

  30. [38]

    Difference-in-differences with multiple time periods,

    B. Callaway and P. H. C. Sant’Anna, “Difference-in-differences with multiple time periods,”Journal of Econometrics, vol. 225, no. 2, pp. 200–230, 2021

    2021

  31. [39]

    The central role of the propensity score in observational studies for causal effects,

    P. R. Rosenbaum and D. B. Rubin, “The central role of the propensity score in observational studies for causal effects,”Biometrika, vol. 70, no. 1, pp. 41–55, 1983

    1983

  32. [40]

    GH Archive: Archiving the public GitHub timeline,

    I. Grigorik, “GH Archive: Archiving the public GitHub timeline,” https: //www.gharchive.org/, 2012, accessed: 2026-06-27

    2012

  33. [41]

    Constructing a control group using multivariate matched sampling methods that incorporate the propensity score,

    P. R. Rosenbaum and D. B. Rubin, “Constructing a control group using multivariate matched sampling methods that incorporate the propensity score,”The American Statistician, vol. 39, no. 1, pp. 33–38, 1985

    1985

  34. [42]

    The space of developer productivity: There’s more to it than you think

    N. Forsgren, M.-A. Storey, C. Maddila, T. Zimmermann, B. Houck, and J. Butler, “The space of developer productivity: There’s more to it than you think.”Queue, vol. 19, no. 1, pp. 20–48, 2021

    2021

  35. [43]

    Sonarqube official documentation,

    SonarSource, “Sonarqube official documentation,” https: //docs.sonarqube.org/latest/, accessed: 2026-06-28

    2026

  36. [44]

    Cognitive complexity: An overview and evaluation,

    G. A. Campbell, “Cognitive complexity: An overview and evaluation,” inProceedings of the 2018 international conference on technical debt, 2018, pp. 57–58

    2018

  37. [45]

    A general and simple method for obtainingR 2 from generalized linear mixed-effects models,

    S. Nakagawa and H. Schielzeth, “A general and simple method for obtainingR 2 from generalized linear mixed-effects models,”Methods in Ecology and Evolution, vol. 4, no. 2, pp. 133–142, 2013

    2013

  38. [46]

    Extension of Nakagawa & Schielzeth’sR 2 to random slopes models,

    P. C. D. Johnson, “Extension of Nakagawa & Schielzeth’sR 2 to random slopes models,”Methods in Ecology and Evolution, vol. 5, no. 9, pp. 944–946, 2014

    2014

  39. [2025]

    Available: https://arxiv.org/abs/2507.09089

    [Online]. Available: https://arxiv.org/abs/2507.09089

    arXiv

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.