Pith. sign in

REVIEW 3 major objections 5 minor 3 cited by

To Ban or not to Ban? How Open Source Projects Govern GenAI Contributions

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

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

Pith's one-line read Open source projects are not simply banning or allowing generative-AI contributions; they are building governance regimes that combine admissibility rules, disclosure and accountability requirements, verification gates, workflow protections

desk verdict A well-executed qualitative taxonomy of GenAI governance in OSS that delivers a useful 'beyond banning' frame, but the corpus screen for explicit AI mentions means the orientation counts and strategy map speak mainly to projects that name AI. read the letter →

arxiv 2603.26487 v2 pith:RPRDNQJZ submitted 2026-03-27 cs.SE cs.HC

Wenhao Yang , Runzhi He , Minghui Zhou This is my paper · ORCID
classification cs.SEcs.HC
keywords generativeAIopensourcesoftwarecontributiongovernancemaintainerworkloadreviewbottleneckorientationsdisclosurepolicycodeprovenance
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

This paper tries to establish that open source software (OSS) projects are not answering a simple 'ban AI or not' question when they regulate generative-AI contributions. Based on a qualitative analysis of public governance texts from 67 highly visible projects, it argues that maintainer concerns fall into seven recurring areas—review bottlenecks, low-value AI text, issue triage costs, security-report noise, adversarial incentives, provenance and licensing uncertainty, and platform or tooling limits—and that project responses cohere into three governance orientations: prohibitionist, boundary-and-accountability, and quality-first. These orientations are implemented through 12 reusable strategies, from disclosure rules and evidence gates to PR queues and platform migration. The value is that it converts scattered community practices into a conceptual map that maintainers can use to match policy to their specific bottleneck, and it redirects research away from 'ban or not' toward a multi-surface governance problem.

What carries the argument

The strategy-orientation map, built through iterative qualitative coding of public governance texts from 67 projects, cross-tabulates three governance orientations—prohibitionist, boundary-and-accountability, and quality-first—against 12 strategies in four functional groups: entry admissibility and input qualification, responsibility and evidence restoration, review burden and workflow protection, and infrastructure and institutional adjustment. This map carries the argument by showing that each orientation is realized by a distinct combination of strategies, that the same strategy plays different roles under different orientations, and that no single device such as disclosure or templates s

What would settle it

A replication that applies the same coding to projects without explicit AI-named policies—for example, a random sample of smaller or lower-activity repositories with strict general review rules—and finds that their governance cannot be sorted into the three orientations, or that a fourth orientation emerges, would refute the claim that the taxonomy covers the OSS governance space. Alternatively, a maintainer survey showing that private enforcement contradicts the public policy in a majority of sampled projects would falsify the public-text premise.

Watch

Extended reading notes

Core claim

The central claim is that GenAI governance in OSS is a multi-surface design problem, not a binary policy decision. Across 67 project-level cases, the paper identifies three governance orientations—prohibitionist (refusing certain AI inputs at the door), boundary-and-accountability (admitting AI only under explicit disclosure, human accountability, and verification), and quality-first (absorbing AI into existing quality and maintainer-cost thresholds)—and shows that boundary-and-accountability is the dominant orientation, appearing in about 60% of cases. These orientations are operationalized through 12 strategies grouped into four functions: entry admissibility, responsibility and evidence,

Load-bearing premise

The whole map rests on treating publicly written, explicitly AI-naming governance texts as the right and sufficient evidence of how a project governs GenAI; projects that govern AI through general quality rules or private maintainer enforcement are invisible to the corpus, so the taxonomy and orientation shares could shift if they were included.

Editorial extensions

If this is right

  • GenAI governance in OSS should be diagnosed by bottleneck: projects worried about fake security reports can reach for verification and evidence gating, while projects worried about long-term quality can reach for accountability reinforcement and scope control; there is no one-size-fits-all AI policy.
  • The practical mainstream is not banning AI but requiring disclosure, human ownership, and evidence: boundary-and-accountability is the dominant orientation in the corpus.
  • The load-bearing shift is upstream: projects are moving admission control before review—pre-approved issues, proof-of-concept gates, and PR limits—to protect maintainer attention as the scarcest resource.
  • Repository-level rules have limits, so governance is beginning to move to infrastructure: projects escalate to suspending external contributions or changing venues, implying platform designers must take on intake control and traceability.

Reading between the lines

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

  • If the taxonomy is sound, a project's primary bottleneck—legal uncertainty, review capacity, or security-channel noise—should predict its orientation; this diagnostic mapping is implicit in the paper and could be tested on new projects before they write policy.
  • The sampling design, which requires texts that explicitly name GenAI, likely undercounts quality-first governance, since projects that fold AI expectations into general quality rules without naming AI are excluded; the reported 19.4% share for that orientation is probably a lower bound.
  • A concrete next experiment would track whether mandatory AI disclosure actually changes review time or contributor mix in projects that adopted it, comparing with matched projects that did not; the paper identifies disclosure compliance as an open question.
  • The generation-versus-review asymmetry suggests a measurable 'attention tax': review hours spent per merged contribution or per issue before and after agentic tools could quantify the pressure the paper describes and evaluate whether governance strategies restore balance.
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 reports a qualitative document analysis of public GenAI governance materials from 67 highly visible OSS projects. It identifies seven recurring maintainer concerns across contribution workflows, derives three governance orientations—prohibitionist, boundary-and-accountability, and quality-first—and abstracts 12 governance strategies organized into four functional groups. The central claim is that governing GenAI in OSS is not a binary ban-or-allow decision but a multi-surface design problem involving accountability, verification, review capacity, provenance, and platform infrastructure. The methodology uses a two-phase corpus construction (top-800 star seed + snowball sampling), iterative open coding, project-level memoing, constant comparison, and inter-rater reliability assessment (κ = 0.742 for orientations, 0.745 for concerns, 0.840 for strategies). Limitations are acknowledged in §6.

Significance. If the proposed taxonomy is robust, it provides a useful structured map of an emerging and scattered governance practice, with practical value for maintainers and platform designers and a conceptual baseline for future research. The study's strengths include a transparent audit trail, direct quotations from primary sources, inter-rater reliability reporting, and an honest limitation section. The main risk to the contribution is the corpus inclusion screen, which requires texts that explicitly regulate GenAI-assisted contribution behavior; this may limit the completeness and generalizability of the 12-strategy map and the reported orientation proportions.

major comments (3)
  1. [§3.1–3.2, §6.1] The corpus screen requires texts that 'explicitly regulated GenAI-assisted contribution behavior,' which is narrower than the paper's own governance definition in footnote 1 (any rules/interfaces regulating contribution intake). Projects that govern AI-mediated contributions through general-purpose quality gates without naming GenAI are systematically excluded. Because the abstract and RQ2 claim a 'reusable strategy space' and report orientation proportions (O1 20.9%, O2 59.7%, O3 19.4%), this selection effect is load-bearing: the taxonomy may be missing an 'implicit absorption' mode, and the percentages cannot be read as characterizing GenAI governance in OSS broadly. Please either scope the claims to explicit GenAI governance or conduct a supplementary check on a sample of high-visibility projects without explicit AI mentions to test whether new strategies or orientations emerge.
  2. [§5.1, Contributions (p. 2)] The paper states that the three orientations 'explain why projects facing similar GenAI pressures develop markedly different institutional responses.' The design is cross-sectional and descriptive; no measure of 'pressures' is used, and orientations are derived from the same governance texts that define the strategies. This supports an interpretive account or association, not a causal explanation. Please soften the language (e.g., 'account for' or 'are associated with') or add evidence that projects with similar pressure profiles differ systematically by orientation.
  3. [§3.2, §4, Table 1] The corpus mixes 58 repository-hosted sources and 9 project-adjacent policy texts into a single project-level case analysis, but Table 1 appears to report demographics for only 55 projects (the language counts sum to 55). The paper should clarify whether the 9 project-adjacent texts are counted as cases equivalent to whole projects, and report the breakdown by source type. This matters because the orientation percentages and strategy prevalences are case-level counts, and mixing organizational types may affect the reported distributions.
minor comments (5)
  1. [Figure 1] The figure is difficult to parse in the provided rendering: 'Capacity & Queue Control' has no prevalence entries, and the column-major layout is unclear. Please ensure the figure renders all 12 strategies with their three orientation values, or provide a machine-readable table.
  2. [Table 1] The 'Policy adoption' row is garbled, and the demographic counts do not reconcile with the corpus size. Please clean the table and state explicitly which subset of cases it covers.
  3. [§3.4] The coding codebook is not included. Since the 12 strategies and seven concerns are the main results, a supplementary codebook with example quotes per code would improve reproducibility and reader confidence.
  4. [§5.1] Minor typo: 'independent if AI is used or not' should be 'independent of whether AI is used or not'.
  5. [§6.3, Abstract] The abstract reports orientation percentages without qualification; §6.3 warns they are approximate patternings. Consider adding a pointer to the limitation or softening the abstract's numerical presentation.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the taxonomy is an inductive qualitative synthesis with no fitted inputs presented as predictions.

full rationale

The paper makes no predictive or derivation claim of the kind that can be circular. It collects 67 public governance texts screened for explicit GenAI governance content (§3.2), iteratively codes maintainer concerns (§3.4), assigns each project a dominant orientation by 'comparing its dominant governance logic across documents' (§3.4), and abstracts 12 strategies 'only when it was analytically distinct in governance function, behavioral target, and implementation pattern' (§3.4). The orientations and strategies are outputs of the coding, not inputs that generate the corpus; no parameter is fitted to a subset of data and then used to predict a related quantity. The percentages in Figure 1 are descriptive within-corpus prevalences, and the paper explicitly cautions they are 'approximate patterning rather than sharp natural groupings' (§6.3) and not 'a prevalence estimate for the entire OSS ecosystem' (§6.1). The self-citations to prior work by the authors (e.g., [33], [63], [64], [69]) appear only in the related-work baseline and are not load-bearing. The acknowledged limitation—that public explicit-AI governance texts may underrepresent projects that govern via general quality rules—is a coverage/transferability threat, not circularity, because the taxonomy is not used to define the corpus. No equation or step reduces to its own input by construction.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No numeric free parameters were fitted; the three orientations and 12 strategies are analytical outputs, not input parameters. The central claim rests on domain assumptions about corpus representativeness, the sufficiency of public texts, and the validity of qualitative coding—all acknowledged in the paper's threats-to-validity section. No new physical or technical entities (particles, forces, protocols in the sense of invented artifacts) are introduced; Vouch and Agent-Trace are cited external projects, not invented by this paper.

assumptions (4)
  • domain assumption The top-800 Gitstar repository leaderboard is a suitable seed for finding highly visible OSS projects with mature, explicit governance surfaces.
    Phase 1 corpus construction (§3.2) uses this leaderboard as the seed frame. If the leaderboard overrepresents GitHub-centric, English-speaking, or policy-rich projects, the resulting taxonomy may miss other governance modes.
  • domain assumption Publicly encoded governance texts are a sufficient representation of a project's GenAI governance.
    Stated in §3.1 and §3.3: the analysis focuses on 'publicly encoded governance.' The authors acknowledge in §6.2 that private maintainer discussions, discretionary triage, and informal enforcement are excluded. The taxonomy's completeness depends on this premise.
  • domain assumption The coding categories (concerns, orientations, strategies) capture meaningful structure rather than arbitrary researcher-imposed labels.
    The coding procedure (§3.4) relies on two authors' iterative coding and inter-rater agreement. Reported kappa values (0.742–0.840) support reliability but do not validate the category set against an external standard.
  • domain assumption Snowball sampling until 'newly added sources no longer materially changed' categories yields analytic saturation.
    Phase 2 stopping rule in §3.2. This is a standard qualitative assumption, but the paper provides no independent check that saturation was reached outside the authors' judgment.

how reviews work

0 comments
Cite this review

Pith. "Pith review of To Ban or not to Ban? How Open Source Projects Govern GenAI Contributions." pith.science (2026). https://pith.science/paper/RPRDNQJZ

@misc{pith2026260326487,
  author       = {Pith},
  title        = {Pith review of: To Ban or not to Ban? How Open Source Projects Govern GenAI Contributions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RPRDNQJZ}},
  note         = {Machine review of arXiv:2603.26487}
}
read the original abstract

Generative AI (GenAI) is playing an increasingly important role in open source software (OSS). Beyond completing code and documentation, GenAI is increasingly involved in issues, pull requests, code reviews, and security reports. Yet, cheaper generation does not mean cheaper review - and the resulting maintenance burden has pushed OSS projects to experiment with GenAI-specific rules in contribution guidelines, security policies, and repository instructions, even including a total ban on AI-assisted contributions. However, governing GenAI in OSS is far more than a ban-or-not question. The responses remain scattered, with neither a shared governance framework in practice nor a systematic understanding in research. Therefore, in this paper, we conduct a multi-stage analysis on various qualitative materials related to GenAI governance retrieved from 67 highly visible OSS projects. Our analysis identifies recurring concerns across contribution workflows, derives three governance orientations, and maps out 12 governance strategies and their policy instruments. We show that governing GenAI in OSS extends well beyond banning - it requires coordinated responses across accountability, verification, review capacity, code provenance, and platform infrastructure. Overall, our work distills dispersed community practices into a structured overview, providing a conceptual baseline for researchers and a practical reference for maintainers and platform designers.

Figures

Figures reproduced from arXiv: 2603.26487 by the authors.

Figure 1
Figure 1. Governance strategies mapped by functional group (rows) and governance orientation (columns). Shading intensity [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

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

    cs.SE 2026-08 conditional novelty 6.0 of 10

    Adopting AI governance policies in open source projects is associated with more AI disclosure, more maintainer engagement, and better code quality metrics, but the causal estimates rest on measurement and identificati...

  2. Making Agent-Mediated Contributions Governable: A Project-Level Governance Manifest for Open-Source AI Collaboration

    cs.SE 2026-07 conditional novelty 6.0 of 10

    A repository file called the Agent Governance Manifest, linking risk zones, evidence obligations, human confirmation, and review gates, raised exact risk-label recovery from 40.5% to 97.4% in a 75-output controlled te...

  3. Quick Build, Careful Check? Generative AI Use in Hackathons

    cs.SE 2026-07 conditional novelty 5.0 of 10

    Even without team rules, hackathon participants reported wanting to check generative AI output, but time pressure and limited domain knowledge often stopped them from truly verifying it.

Reference graph

Works this paper leans on

72 extracted references · 3 canonical work pages · cited by 3 Pith papers

  1. [1]

    Adam Alami, Raúl Pardo, Marisa Leavitt Cohn, and Andrzej Wąsowski. 2022. Pull request governance in open source communities.IEEE Transactions on Software Engineering48, 12 (2022), 4838–4856. doi:10.1109/TSE.2021.3128356

    arXiv 2022

  2. [2]

    Matthew Baird, Mar Carpanelli, Brian Xu, and Kevin Xu. 2024. Early evidence on the impact of generative AI on software engineers’ employment outcomes. LinkedIn Economic Graph. https://economicgraph.linkedin.com/blog/early-ev idence-on-the-impact-of-generative-ai-on-software-engineers-employment- outcomes Accessed: 2026-03-26

    2024

  3. [3]

    Ruben Branco, Paulo Canelas, Catarina Gamboa, and Alcides Fonseca. 2026. LGTM! characteristics of auto-merged LLM-based agentic PRs. InProceedings of the 23rd International Conference on Mining Software Repositories (MSR ’26). Association for Computing Machinery, New York, NY, USA, 1–5. https://pc anelas.com/assets/papers/2026-msr-lgtm.pdf Accepted at MSR...

    2026

  4. [4]

    CloudNativePG Contributors. 2026. CloudNativePG AI Contribution Policy. GitHub repository file. https://github.com/cloudnative-pg/governance/blob/m ain/AI_POLICY.md Accessed: 2026-03-26

    2026

  5. [5]

    CloudNativePG Contributors. 2026. Proposal: Adoption of Official AI Contri- bution & Copyright Policy. GitHub Issue. https://github.com/cloudnative- pg/governance/issues/45 Accessed: 2026-03-26

    2026

  6. [6]

    Matteo Collina. 2026. Virtual File System for Node.js. GitHub Pull Request #61478, nodejs/node. https://github.com/nodejs/node/pull/61478 Accessed: 2026-03-26

    2026

  7. [7]

    curl Contributors. 2026. On AI use in curl. GitHub repository file. https: //github.com/curl/curl/blob/master/docs/CONTRIBUTE.md Accessed: 2026-03-26

    2026

  8. [8]

    Cursor Contributors. 2026. Agent Trace. Open specification, version 0.1.0 (RFC). https://agent-trace.dev/ Accessed: 2026-03-27

    2026

Show all 72 references
  1. [9]

    Docusaurus Contributors. 2026. Contributing to Docusaurus: AI-assisted PRs. GitHub repository file. https://github.com/facebook/docusaurus/blob/main/C ONTRIBUTING.md Accessed: 2026-03-26

    2026

  2. [10]

    2020.Working in Public: The Making and Maintenance of Open Source Software

    Nadia Eghbal. 2020.Working in Public: The Making and Maintenance of Open Source Software. Stripe Press, South San Francisco, CA, USA

    2020

  3. [11]

    Storey, Neil A

    Omar Elazhary, Margaret-Anne D. Storey, Neil A. Ernst, and Andy Zaidman. 2019. Do as I do, not as I say: do contribution guidelines match the GitHub contribution process?. In2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, Los Alamitos, C...

    2019

  4. [12]

    Bruna Falcucci, Felipe Gomide, and André Hora. 2025. What do contribution guidelines say about software testing?. In2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR). IEEE, Los Alamitos, CA, USA, 434–438. doi:10.1109/MSR66628.2025.00073

    2025

  5. [13]

    Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Yoo, and Jie M Zhang. 2023. Large language models for software engineering: survey and open problems. In2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineerin...

    2023

  6. [14]

    FastAPI Contributors. 2026. Contributing to FastAPI: Automated Code and AI. GitHub repository file. https://github.com/fastapi/fastapi/blob/master/docs/en /docs/contributing.md#automated-code-and-ai Accessed: 2026-03-26. Beyond Banning AI: A First Look at GenAI Governance in O...

    2026

  7. [15]

    Ahmed Fawzy, Amjed Tahir, and Kelly Blincoe. 2025. Vibe coding in practice: motivations, challenges, and a future outlook – a grey literature review. arXiv preprint arXiv:2510.00328. doi:10.48550/arXiv.2510.00328 [cs.SE]

    2025 doi

  8. [16]

    Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. 2021. The SPACE of developer productivity: there’s more to it than you think.ACM Queue19, 1 (2021), 20–48. doi:10.1145/34 54122.3454124

    2021

  9. [17]

    Haoyu Gao, Peerachai Banyongrakkul, Hao Guan, Mansooreh Zahedi, and Christoph Treude. 2026. On autopilot? An empirical study of human-AI team- ing and review practices in open source. arXiv preprint arXiv:2601.13754. doi:10.48550/arXiv.2601.13754 [cs.SE]

    2026 doi

  10. [18]

    Gitstar Ranking. 2026. Repositories Ranking - Gitstar Ranking. Website. https: //gitstar-ranking.com/repositories Accessed: 2026-03-26

    2026

  11. [19]

    Thibaud Gloaguen et al . 2026. Evaluating AGENTS.md: are repository-level context files helpful for coding agents? arXiv preprint arXiv:2602.11988. doi:10 .48550/arXiv.2602.11988 [cs.SE]

    2026 doi arXiv

  12. [20]

    Georgios Gousios, Martin Pinzger, and Arie van Deursen. 2014. An exploratory study of the pull-based software development model. InProceedings of the 36th International Conference on Software Engineering. Association for Computing Machinery, New York, NY, USA, 345–355. doi:10....

    2014

  13. [21]

    Mitchell Hashimoto and Vouch Contributors. 2026. Vouch. GitHub repository. https://github.com/mitchellh/vouch Accessed: 2026-03-27

    2026

  14. [22]

    Hao He, Courtney Miller, Shyam Agarwal, Christian Kästner, and Bogdan Vasilescu. 2026. Speed at the cost of quality: how Cursor AI increases short- term velocity and long-term complexity in open-source projects. InProceed- ings of the 23rd International Conference on Mining So...

    2026

  15. [23]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large language models for software engineering: a systematic literature review.ACM Transactions on Software Engineering and Methodology33, 5 (2024), 1–41. d...

    2024 doi

  16. [24]

    Immich Contributors. 2026. Object storage. GitHub Discussion. https://github.c om/immich-app/immich/discussions/23745 Accessed: 2026-03-26

    2026

  17. [25]

    Fedor Indutny. 2026. No AI Code in Node.js Core. Change.org petition. https: //www.change.org/p/no-ai-code-in-node-js-core Accessed: 2026-03-26

    2026

  18. [26]

    Fedor Indutny. 2026. No AI in Node.js Core: A Petition to Disallow Acceptance of LLM-Generated Pull Requests. GitHub Repository. https://github.com/indut ny/no-ai-in-nodejs-core Accessed: 2026-03-26

    2026

  19. [27]

    JabRef Contributors. 2026. AGENTS.md — JabRef. GitHub repository file. https: //github.com/JabRef/jabref/blob/main/AGENTS.md Accessed: 2026-03-26

    2026

  20. [28]

    Jaeger Contributors. 2026. Contributing Guidelines: AI Usage Policy. GitHub repository file. https://github.com/jaegertracing/jaeger/blob/main/CONTRIBU TING_GUIDELINES.md#ai-usage-policy Accessed: 2026-03-26

    2026

  21. [29]

    Jaeger Contributors. 2026. Introduce PR limits for new contributors. GitHub Pull Request. https://github.com/jaegertracing/jaeger/pull/7880 Accessed: 2026-03-26

    2026

  22. [30]

    Sushawapak Kancharoendee, Thanat Phichitphanphong, Chanikarn Jongy- ingyos, Brittany Reid, Raula Gaikovina Kula, Morakot Choetkiertikul, Chaiyong Ragkhitwetsagul, and Thanwadee Sunetnanta. 2025. On categorizing open source software security vulnerability reporting mechanisms o...

    2025

  23. [31]

    Kornia Contributors. 2026. Kornia AI and Authorship Policy. GitHub repository file. https://github.com/kornia/kornia/blob/main/AI_POLICY.md Accessed: 2026-03-26

    2026

  24. [32]

    Hao Li, Haoxiang Zhang, and Ahmed E Hassan. 2025. The rise of AI teammates in software engineering (SE 3.0): how autonomous coding agents are reshaping software engineering. arXiv preprint arXiv:2507.15003. doi:10.48550/arXiv.2507. 15003 [cs.SE]

    2025 doi arXiv

  25. [33]

    Zhixing Li, Yue Yu, Minghui Zhou, Tao Wang, Gang Yin, Long Lan, and Huaimin Wang. 2022. Redundancy, context, and preference: an empirical study of duplicate pull requests in OSS projects.IEEE Transactions on Software Engineering48, 4 (2022), 1461–1476. doi:10.1109/TSE.2020.3018726

    2022

  26. [34]

    Johan Linåker, Georg J. P. Link, and Kevin Lumbard. 2024. Sustaining mainte- nance labor for healthy open-source software projects through human infras- tructure: a maintainer perspective. arXiv preprint arXiv:2408.06723. doi:10.485 50/arXiv.2408.06723 [cs.SE]

    2024 doi arXiv

  27. [35]

    llama.cpp Contributors. 2026. AI Usage Policy. GitHub repository file. https: //github.com/ggml-org/llama.cpp/blob/master/CONTRIBUTING.md Accessed: 2026-03-26

    2026

  28. [36]

    llama.cpp Contributors. 2026. Security Policy. GitHub repository file. https: //github.com/ggml-org/llama.cpp/blob/master/SECURITY.md Accessed: 2026-03-26

    2026

  29. [37]

    Matplotlib Contributors. 2026. [PERF] Replace np.column_stack with np.vstack().T. GitHub Pull Request. https://github.com/matplotlib/matp lotlib/pull/31132 Accessed: 2026-03-26

    2026

  30. [38]

    METR. 2025. Measuring the impact of early-2025 AI on experienced open-source developer productivity. arXiv preprint arXiv:2507.09089. doi:10.48550/arXiv.250 7.09089 [cs.SE]

    2025 doi arXiv

  31. [39]

    Dao Sy Duy Minh, Huynh Trung Kiet, Nguyen Lam Phu Quy, Pham Phu Hoa, Tran Chi Nguyen, Nguyen Dinh Ha Duong, and Truong Bao Tran. 2026. Early- Stage Prediction of Review Effort in AI-Generated Pull Requests. InProceedings of the 23rd International Conference on Mining Software ...

    2026

  32. [40]

    Seyedmoein Mohsenimofidi, Matthias Galster, Christoph Treude, and Sebastian Baltes. 2025. Context engineering for AI agents in open-source software. arXiv preprint arXiv:2510.21413. doi:10.48550/arXiv.2510.21413 [cs.SE]

    2025 doi

  33. [41]

    mpv Contributors. 2026. AI-assisted Contributions. GitHub repository file. https://github.com/mpv-player/mpv/blob/master/DOCS/contribute.md#ai- assisted-contributions Accessed: 2026-03-26

    2026

  34. [42]

    NetBSD Developers. 2026. NetBSD Commit Guidelines. NetBSD Project Website. https://www.netbsd.org/developers/commit-guidelines.html Accessed: 2026-03-26

    2026

  35. [43]

    NewPipe Contributors. 2026. NewPipe Contributing: AI policy. GitHub reposi- tory file. https://github.com/TeamNewPipe/NewPipe/blob/dev/.github/CONT RIBUTING.md Accessed: 2026-03-26

    2026

  36. [44]

    Nhan Nguyen and Sarah Nadi. 2022. An empirical evaluation of GitHub Copilot’s code suggestions. InProceedings of the 19th International Conference on Mining Software Repositories (MSR ’22). Association for Computing Machinery, New York, NY, USA, 1–5. doi:10.1145/3524842.3528470

    2022

  37. [45]

    pandas Contributors. 2026. Automated Contributions Policy. GitHub repository file. https://github.com/pandas-dev/pandas/blob/main/doc/source/developmen t/contributing.rst#automated-contributions-policy Accessed: 2026-03-26

    2026

  38. [46]

    Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer. 2023. The impact of AI on developer productivity: evidence from GitHub Copilot. arXiv preprint arXiv:2302.06590. doi:10.48550/arXiv.2302.06590 [cs.CY]

    2023 doi arXiv

  39. [47]

    Python Developers. 2026. Generative AI. Python Developer’s Guide. https: //devguide.python.org/getting-started/generative-ai/ Accessed: 2026-03-26

    2026

  40. [48]

    PyTorch Contributors. 2026. AI-Assisted Development. GitHub repository file. https://github.com/pytorch/pytorch/blob/main/CONTRIBUTING.md#ai- assisted-development Accessed: 2026-03-26

    2026

  41. [49]

    QEMU Contributors. 2026. Code Provenance: Use of AI-generated content. QEMU Documentation. https://github.com/qemu/qemu/blob/master/docs/deve l/code-provenance.rst Accessed: 2026-03-26

    2026

  42. [50]

    Rapid7 Metasploit Contributors. 2026. Contributing to Metasploit Framework: Vibecoding, AI, and LLM. GitHub repository file. https://github.com/rapid7/me tasploit-framework/blob/master/CONTRIBUTING.md Accessed: 2026-03-26

    2026

  43. [51]

    Robby Russell. 2026. Humans in the Loop. Robby on Rails. https://robbyonrails .com/articles/2026/01/20/humans-in-the-loop/ Accessed: 2026-03-26

    2026

  44. [52]

    Spec Kit Contributors. 2026. AI Contributions in Spec Kit. GitHub repository file. https://github.com/github/spec-kit/blob/main/CONTRIBUTING.md#ai- contributions-in-spec-kit Accessed: 2026-03-26

    2026

  45. [53]

    Igor Steinmacher, Marco Aurélio Graciotto Silva, Marco Aurélio Gerosa, and David F Redmiles. 2015. A systematic literature review on the barriers faced by newcomers to open source software projects.Information and Software Technology59 (2015), 67–85. doi:10.1016/j.infsof.2014.11.001

    2015 doi

  46. [54]

    Daniel Stenberg. 2026. The end of the curl bug-bounty. daniel.haxx.se blog. https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ Accessed: 2026-03-26

    2026

  47. [55]

    Emre Sülün, Metehan Saçakçı, and Eray Tüzün. 2024. An empirical analysis of issue template usage in large-scale projects on GitHub.ACM Transactions on Software Engineering and Methodology33, 5 (2024), 117:1–117:28. doi:10.1145/36 43673

    2024 doi

  48. [56]

    tldraw Contributors. 2026. Contributions policy. GitHub Issue. https://github.c om/tldraw/tldraw/issues/7695 Accessed: 2026-03-26

    2026

  49. [57]

    typescript-eslint Contributors. 2026. AI Contribution Policy. GitHub repository file. https://github.com/typescript-eslint/typescript-eslint/blob/main/docs/cont ributing/AI_Contribution_Policy.mdx Accessed: 2026-03-26

    2026

  50. [58]

    typescript-eslint Contributors. 2026. Docs: Establish and document expectations around use of AI in contributions. GitHub Issue. https://github.com/typescript- eslint/typescript-eslint/issues/11416 Accessed: 2026-03-26

    2026

  51. [59]

    Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H

    Xingyao Wang, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, et al. 2025. ...

    2025

  52. [60]

    Mairieli Wessel, Joseph Vargovich, Marco A Gerosa, and Christoph Treude. 2023. GitHub Actions: the impact on the pull request process.Empirical Software Engineering28 (2023), 131. doi:10.1007/s10664-023-10369-w

    2023 doi

  53. [61]

    Jiaqi Wu, Lingfeng Bao, Xiaohu Yang, Xin Xia, and Xing Hu. 2024. A large- scale empirical study of open source license usage: practices and challenges. In Proceedings of the 21st International Conference on Mining Software Repositories Wenhao Yang, Runzhi He, and Minghui Zhou ...

    2024

  54. [62]

    Tao Xiao, Youmei Fan, Fabio Calefato, Christoph Treude, Raula Gaikovina Kula, Hideaki Hata, and Sebastian Baltes. 2025. Self-admitted GenAI usage in open- source software. arXiv preprint arXiv:2507.10422. doi:10.48550/arXiv.2507.1042 2 [cs.SE]

    2025 doi arXiv

  55. [63]

    Jialiang Xie, Minghui Zhou, and Audris Mockus. 2013. Impact of triage: a study of Mozilla and Gnome. In2013 ACM / IEEE International Symposium on Empirical Software Engineering and Measurement, ESEM ’13. IEEE, Los Alamitos, CA, USA, 1–10. doi:10.1109/ESEM.2013.62

    2013 doi

  56. [64]

    Weiwei Xu, Kai Gao, Hao He, and Minghui Zhou. 2025. LiCoEval: evaluating LLMs on license compliance in code generation. In2025 IEEE/ACM 47th In- ternational Conference on Software Engineering. IEEE, Los Alamitos, CA, USA, 1665–1677. doi:10.1109/ICSE55347.2025.00052

    2025

  57. [65]

    Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press

    John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. SWE-agent: agent-computer inter- faces enable automated software engineering. InAdvances in Neural Information Processing Systems, Vol. 37. Curran Associates, I...

    2024 doi

  58. [66]

    Haruhiko Yoshioka, Takahiro Monno, Haruka Tokumasu, Taiki Wakamatsu, Yuki Ota, Nimmi Rashinika Weeraddana, and Kenichi Matsumoto. 2026. Let’s make every pull request meaningful: an empirical analysis of developer and agentic pull requests. InProceedings of the 23rd Internation...

    2026

  59. [67]

    Quanjun Zhang, Chunrong Fang, Yang Xie, Yaxin Zhang, Yun Yang, Weisong Sun, Shengcheng Yu, and Zhenyu Chen. 2026. A survey on large language models for software engineering.Science China Information Sciences69, 4 (2026), 141102. doi:10.1007/s11432-025-4670-0

    2026 doi

  60. [68]

    Songwen Zhao et al . 2025. Is vibe coding safe? Benchmarking vulnerability of agent-generated code in real-world tasks. arXiv preprint arXiv:2512.03262. doi:10.48550/arXiv.2512.03262 [cs.CR]

    2025 doi

  61. [69]

    Minghui Zhou, Qingying Chen, Audris Mockus, and Fengguang Wu. 2017. On the scalability of Linux kernel maintainers’ work. InProceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2017. Association for Computing Machinery, New York, NY, USA,...

    2017

  62. [70]

    Shurui Zhou, Bogdan Vasilescu, and Christian Kästner. 2019. What the fork: a study of inefficient and efficient forking practices in social coding. InProceedings of the 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Softw...

    2019 doi

  63. [71]

    Zig Contributors. 2025. github: add link to issue template list warning against LLMs. GitHub Commit. https://github.com/ziglang/zig/commit/d238078ae87f 1beb565d42caee01ebd6a7a00d43 Accessed: 2026-03-26

    2025

  64. [72]

    Zig Contributors. 2025. Migrating from GitHub to Codeberg. Zig News. https: //ziglang.org/news/migrating-from-github-to-codeberg/ Accessed: 2026-03-26

    2025

Pith tools

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