Beyond Banning AI: A First Look at GenAI Governance in Open Source Software Communities

Bey ond Banning AI: A First Look at GenAI Governance in Open Source Sowar e Communities W enhao Y ang Peking University Beijing, China yangwh@stu.pku.edu.cn Runzhi He Peking University Beijing, China rzhe@pku.edu.cn Minghui Zhou ∗ Peking University Beijing, China zhmh@pku.edu.cn Abstract Generative AI (GenAI) is playing an increasingly important role in open source software (OSS). Beyond completing code and docu- mentation, GenAI is increasingly involv ed in issues, pull requests, code reviews, and security reports. Y et, cheaper generation do es not mean cheaper review — and the resulting maintenance bur- den has pushed OSS projects to experiment with GenAI-spe cic rules in contribution guidelines, security policies, and repository instructions, even including a total ban on AI-assisted contributions. Howev er , governing GenAI in OSS is far more than a ban-or-not question. The responses remain scattered, with neither a shared governance framew ork in practice nor a systematic understanding in research. Therefore, in this paper , w e conduct a multi-stage anal- ysis on various qualitative materials related to GenAI governance retrieved fr om 67 highly visible OSS projects. Our analysis identies recurring concerns across contribution workows, derives three governance orientations, and maps out 12 governance strategies and their implementation patterns. W e show that gov erning GenAI in OSS extends well beyond banning — it requires coordinated re- sponses across accountability , verication, review capacity , code provenance , and platform infrastructure. Overall, our work distills dispersed community practices into a structured overview , provid- ing a conceptual baseline for researchers and a practical reference for maintainers and platform designers. CCS Concepts • Software and its engineering → Open source model ; Soft- ware de velopment pr o cess management ; Collaboration in softwar e development ; Empirical software validation. Ke y words generative AI, open source software , contribution workows, con- tribution governance 1 Introduction Generative AI is actively reshaping the future of OSS communities. It is increasingly acting as a community contributor—submitting issues, pull requests, code reviews, and security r eports [ 13 , 23 , 67 ]. Recent coding agents take this further by navigating repositories, generating full patches, and executing pipelines with greater au- tonomy [ 32 , 59 , 65 ]. With the rise of GenAI, how developers enter , participate in, and evolve community collaboration is undergoing a fundamental shift. ∗ Corresponding author . Howev er , the unprecedented spe ed of generating contributions comes at a cost. A prosperous and sustainable open source com- munity depends not only on active contribution, but also on the capacity to revie w , triage, and maintain incoming w ork [ 1 , 10 , 20 , 34 , 53 , 60 , 70 ]. As a maintainer of matplotlib observed, AI “changes the cost balance between generating and reviewing code” [ 37 ]. The surge of AI generated contributions grew beyond the maintenance capabilities of many well-known open source projects, causing chaos and debates within the cornerstones of the modern digital infrastructure. The asymmetry can be stark: when a Node.js TSC member submitted a 19,000-line PR generated with Claude Code [ 6 ], the incident triggered a petition by over 80 developers [ 25 , 26 ] call- ing for a project-wide ban on AI-assisted contributions. In response, projects have begun to establish GenAI-sp ecic rules across contribution guidelines, security p olicies, issue and PR templates, AI directives (such as AGENTS.md ), and public an- nouncements. The range of these responses is wide: some projects categorically reject AI-generated contributions on provenance and licensing grounds; others require disclosur e of AI use and impose accountability conditions on contributors; still others constrain AI tool b ehavior directly through repository-level instructions; and some have gone further , suspending external PRs or e ven migrating their primary collab oration venue . At the same time, many projects acknowledge the productivity benets and recognize that “ continu- ously rejecting LLM-generated code is not a good approach” [ 24 ]. These diverse responses suggest that governing 1 GenAI in OSS extends well beyond a binary question of permitting or prohibiting AI—yet current practices remain scattered across heterogeneous governance channels, with no shared framework or established best practice in sight. This gap is both practical and academic. Prior r esearch has ex- tensively studied GenAI’s technical capabilities across software engineering tasks [ 13 , 23 , 67 ], its adoption and eects on devel- oper productivity and OSS collaboration [ 2 , 15 , 38 , 46 , 68 ], and the long-standing governance mechanisms of OSS contribution management [ 10 , 20 , 53 , 70 ]. Howev er , these streams have not yet converged on the question of how OSS projects govern GenAI within contribution workows. W e still lack a systematic under- standing of what concerns GenAI raises across dierent stages of OSS contribution workows, and how projects organize their responses into governance approaches and concr ete strategies. In this paper , we present the rst systematic analysis of GenAI governance in OSS. W e collected repositor y-embedded governance materials (e.g., CON TRIBU TING, SECURI TY, issue and PR tem- plates, AGENTS.md ) and surrounding justicator y materials (e .g., 1 Following prior work on OSS contribution governance [ 1 , 10 , 11 ], we use governance here to refer to the rules, proce dures, and collaboration interfaces through which projects regulate contribution intake, revie w , accountability , and maintenance. W enhao Y ang, Runzhi He, and Minghui Zhou announcements, discussion threads) from 67 highly visible OSS projects. Through iterative qualitative coding, w e identied recur- ring concerns, governance orientations, and cross-project strategies. Specically , we answer the following research questions: RQ1. What concerns do GenAI raise across OSS contribution work- ows? Result: W e identie d seven recurring concern areas dis- tributed across code contribution, communication, issue entry , se- curity reporting, incentive structures, provenance and licensing, and platform infrastructure. RQ2. What governance approaches do OSS projects develop for GenAI contributions? Result: W e derived three governance orien- tations: prohibitionist, boundary-and-accountability , and quality- rst—operationalized through 12 recurring governance strategies. Our main contributions in this paper are: • W e provide a structured account of how GenAI-related con- cerns are distributed across OSS contribution workows; • W e derive three governance orientations that explain why projects facing similar GenAI pressures develop markedly dierent institutional responses; • W e abstract a reusable strategy space of 12 governance strategies and their implementation patterns, showing how the strategies serve dierent roles under dierent orienta- tions. Overall, our work oers b oth a conceptual baseline for future research on GenAI and software collaboration, and a practical refer- ence for maintainers, communities, and platform designers seeking to establish or evaluate their own gov ernance approaches. 2 Related W ork In this se ction, we review prior work on: 1) GenAI for software engineering; 2) The adoption and inuence of GenAI in the scope of OSS; 3) how OSS communities re view , moderate, and maintain contributions. 2.1 GenAI for Software Development Since the rise of large language models, we have observed and mea- sured the eect of this te chnology in various software engineering tasks, including code generation, testing, repair , and broader de- velopment assistance [ 13 , 23 , 67 ]. Researchers have evaluated the code quality and found limitations of code completion products like GitHub Copilot [ 44 ]. More recently , resear chers have shifted focus to coding agents (e.g., SWE-A gent [ 65 ], Op enHands [ 59 ]) that navigate repositories, generate full patches, and execute pipelines with greater autonomy . Recent OSS-facing work also examines context-engineering practices and AGENTS.md les used to provide repository-specic instructions to such agents [ 19 , 40 ]. Through large-scale mining of agent-assisted pull requests, researchers [ 32 , 59 , 65 ] investigate the status and draw the technical boundaries of GenAI in software development. 2.2 GenAI Use and Impact in Software and OSS Collaboration Researchers have also noted the inuences of GenAI in other dimen- sions of software engineering, specically in developer productivity , software quality , and collaboration. Prior studies observed signi- cant productivity gain from the use of GitHub Copilot [ 46 ], along with higher validation and coordination costs in realistic dev elop- ment settings [2, 16, 38]. In OSS contexts, recent work has further explored self-admitted GenAI usage, vibe coding, Cursor AI, auto- merged agentic PRs, and human-AI revie w practices, revealing im- plications for vulnerability e xp osure, complexity , co de survival, and review dynamics [ 3 , 15 , 17 , 22 , 62 , 66 , 68 ]. Related w ork also begins to surface compliance and prov enance risks around AI-generated code, especially license uncertainty and compatibility in OSS set- tings [ 61 , 64 ]. Overall, this stream explains how GenAI is used and what eects it has on software work and OSS collaboration. 2.3 OSS Contribution Governance, Maintainer W orkload, and Moderation Our study builds most directly on prior work on OSS contribu- tion governance and maintainer w orkload. Pull-base d development, PR review , triage, and newcomer barriers have long b een recog- nized as central issues in OSS collab oration [ 20 , 53 , 70 ]. More ne- grained studies have examined the governance interfaces through which projects manage these pressures: contribution guidelines often diverge from actual contribution processes [ 11 ], issue tem- plates shap e the processability of incoming reports [ 55 ], and testing- related guidance in contribution do cuments remains une ven across projects [ 12 ]. Related work has also shown that issue triage, main- tainer scalability , duplicate submissions, review styles, automation infrastructure, and security reporting mechanisms are not merely coordination details, but important governance mechanisms for ltering inputs, allocating attention, and sustaining order in OSS projects [ 1 , 10 , 30 , 33 , 34 , 60 , 63 , 69 ]. This literature provides an important baseline for our work: the signicance of GenAI lies not only in accelerating content generation, but also in intensifying and reshaping long-standing OSS problems around input ltering, accountability , review capacity , and maintainer overload. 2.4 The Knowledge Gaps Existing work has mapped GenAI’s technical capabilities, devel- oper adoption patterns, and individual productivity gains, while also establishing the importance of contribution go vernance and maintainer burden in traditional OSS. What r emains missing is a systematic account of how the tide of AI generated content drives projects to recongure their gov ernance interfaces. Our study ad- dresses this gap by moving bey ond individual performance metrics to explore the r ecurring concerns, strategic orientations, and con- crete policy instruments. 3 Methodology 3.1 Research Design and Scope W e conducted a comparative qualitative document analysis of pub- licly visible governance materials that OSS projects use to regulate GenAI-mediated contribution workows. W e did not aim to es- timate policy prevalence or test a predened the ory . Instead, we sought to explain how OSS projects articulate GenAI-related prob- lems, organize them into broader governance orientations, and express them through concr ete governance strategies. Beyond Banning AI: A First Look at GenAI Governance in Open Source Soware Communities W e therefore focused on publicly encoded governance : texts that explicitly conne ct GenAI-r elate d inputs to rules about admissibility , disclosure, accountability , verication, revie w , reporting, sanctions, or infrastructural arrangements. W e treated a text as e vidence of GenAI governance only when it explicitly regulated GenAI-assisted contribution behavior rather than merely mentioning AI, automa- tion, or code quality . Document analysis ts this goal because contribution guides, security policies, templates, AI policies, and tool-facing instructions are visible collaboration interfaces rather than post hoc commen- tary . For readability , we continue to use the term “OSS projects” throughout the pap er , although the corpus also includes a small number of project-adjacent foundation-, community-, organization- , and ecosystem-level policy texts that directly gov ern OSS contri- bution practices. 3.2 Corpus Construction T o combine broad initial coverage with the oretically motivated follow-up sampling, we constructed the corpus in two stages. Phase 1: broad repository screening. W e created the see d frame from the top 800 starred repositories listed on Gitstar Ranking’s repository leaderboard [ 18 ]. This choice gave us a high-visibility set of projects with relatively mature governance surfaces and ac- tive external contribution w orkows. T wo authors independently screened these repositories for public text that tied GenAI-related inputs to contribution rules, r eview e xpectations, security handling, channel restrictions, or sanctions. General references to AI, au- tomation, or code quality w ere excluded unless they w ere explicitly connected to OSS contribution governance. Disagreements were resolved through discussion. This stage yielded 37 OSS projects with explicit GenAI governance content. Phase 2: snowball expansion. W e then extended the corpus through targeted snowball sampling to capture relevant sources not well represented in the seed set. W e followed three expansion paths: (1) project-linke d external guidance or policy texts, (2) adjacent projects or governance ecosystems referenced by sampled projects, and (3) additional governance surfaces that app eared important during comparison, such as standalone AI policies, AI-specic secu- rity reporting rules, AGENTS.md , and platform-migration announce- ments. Candidate sources were included only if they containe d explicit GenAI governance content, directly governed OSS contri- bution practices, and extended coverage b eyond the see d set by adding underrepresented governance surfaces, linked governance ecosystems, or boundar y cases. Materials that merely repeated a stance already captured within the same OSS project were retained as contextual evidence rather than counted as new corpus sources. Snowball expansion proceeded iteratively alongside analysis and stopped when newly added sources no longer materially changed the emerging concern, orientation, or strategy categories. This stage added 30 sources and brought the nal corpus to 67 sources: 58 repository-hosted sources and 9 project-adjacent policy texts. 3.3 Data Sources and Units of Analysis For each source, we collecte d up to two kinds of public materials. The primary evidence consisted of repositor y-embedded governance T able 1: Demographics of the sample d GitHub projects. Statistics Mean Median Distribution # of Stars 49,197.95 45,304.00 1 0 3 1 0 4 1 0 5 # of Commits 45,523.98 15,540.00 1 0 2 1 0 3 1 0 4 1 0 5 1 0 6 # of Contributors 1,666.12 1,045.50 1 0 1 1 0 2 1 0 3 1 0 4 Age (y ears) 9.86 10.03 5 0 5 10 15 20 Policy adoption 2025-07 2025-11 2023-03 2023-07 2023-11 2024-03 2024-07 2024-11 2025-03 2025-07 2025-11 2026-03 Language Python (10), Go (8), C++ (8), JS (5), TS (4), others (20) materials : README les, CON TRIBU TING les, GO VERNANCE les, SECURI T Y les, issue and PR templates, relevant les under .github/ , standalone AI policy pages, and tool-facing les such as AGENTS.md or Copilot instructions. The second kind of material consisted of surrounding justica- tory materials , such as maintainer-author e d announcements, policy- related commit messages, linked issue or discussion thr eads, and project-linked external policy pages. These materials were treated as contextual evidence rather than standalone policy types: orien- tation assignments and strategy coding were anchored in stable governance text and only rened through justicatory materials when the two were consistent. W e analyze d the latest stable public version of each core go ver- nance text available as of Februar y 2026 and use d earlier discussions or commits to interpret policy formation and adoption context. For each source, we r ecorded the URL, access date, source type, gover- nance surfaces, and the versioned location of the cor e p olicy text when available in a corpus sheet used as an audit trail. Our analysis operated at two levels. At the project level, each OSS project or project-adjacent source formed a project-lev el policy case, consolidating all relevant documents fr om that source into a single unit, ensuring that the same stance expressed across multiple les was not counted as separate p olicies. At the text level, we code d strategy-bearing text segments: passages that expressed rules or judgments about admissibility , disclosure, r esp onsibility , verica- tion, provenance , reporting channels, sanctions, or infrastructural adjustment. 3.4 Coding Procedure W e analyze d the corpus through iterative qualitative co ding with constant comparison. Stage 1: op en coding of maintainer concerns. T wo authors indepen- dently conducte d open coding on an initial heter ogene ous subset of OSS projects to dev elop a shared codebook for r ecurring maintainer concerns. W e then used the rened co debook to independently code the full corpus. Stage 2: project-level memoing and gov ernance orientations. After concern coding be came stable, we wrote project-level memos sum- marizing each OSS project’s main governance problem framing and relevant governance surfaces. On this basis, we assigned each OSS project a primary governance orientation by comparing its domi- nant governance logic acr oss documents. Orientation was treated as a project-level interpr etive abstraction rather than a document W enhao Y ang, Runzhi He, and Minghui Zhou label. When a project displayed mixed signals, we re-re viewed the relevant texts jointly and assigned orientation based on the dom- inant governance judgment while retaining mixed or escalator y elements in the strategy analysis. Stage 3: strategy abstraction and implementation analysis. W e then compared coded OSS projects across the corpus to abstract cross-project governance strategies. W e retained a strategy only when it was analytically distinct in governance function, behavioral target, and implementation pattern. Throughout this stage, we repeatedly moved between project-level cases, coded segments, and emerging categories to rene strategy boundaries and clarify how strategies played dierent roles across go vernance orientations. T o strengthen analytic credibility , two authors independently performed both se ed screening and full-corpus coding, and we assessed inter-rater agreement at the case level b efore resolving disagreements through discussion and adjudication. For governance orientation, which assigned one dominant label to each project-level case, Cohen’s kappa was 0.742. For concern and strategy coding, which allowed multiple co des per case, we calculated code-wise Cohen’s kappa on binar y presence/absence de cisions and report the macro-average acr oss codes; macro-average kappa was 0.745 for concerns and 0.840 for strategies. All concern and strategy counts reported below are case-level pr esence counts rather than mention frequencies, so repeated expressions within the same case were counted once . Most orientation disagr eements cluster e d at the O2/O3 boundar y . For the same OSS project, we compared multiple governance surfaces whenever possible and revisited b orderline cases during adjudication. 4 RQ1: Maintainer Concerns Our corpus shows that GenAI enters OSS w orkows well beyond code generation, including co de contribution, discussion, issue triage, security reporting, and platform-level entry p oints. Main- tainer concerns therefore span seven recurring concern areas: 1) review bottlenecks and contributor responsibility in code contribu- tion, 2) low-value AI text in communication, 3) rising triage costs at issue entr y , 4) pressure on high-priority security channels, 5) ad- versarial incentiv es, 6) cop yright/licensing/provenance uncertainty , and 7) platform defaults and tooling limits. 1. Code contribution. In code contribution, maintainers most consistently describe a review bottleneck . GenAI makes PRs easier to generate without making them easier to revie w , explain, or validate. This concern appears in four closely related manifestations: (1) Intent and context. A rst recurring pressur e is that AI makes it easier to submit changes whose scope outruns shar ed prob- lem denition. Docusaurus warns that projects now receive “1k LOC PRs that are obviously AI-generated and implement unso- licited features” [ 9 ]. It also r eminds contributors that signicant changes require prior issue-based approval. The problem is not PR size alone, but that maintainers are pushed to de cide during review whether the change should e xist at all. (2) Surface completeness and correctness. A second recurring concern is that surface completeness no longer signals correct- ness. AI can produce polished, plausible-looking changes with test coverage that still fail at the semantic level. The Metas- ploit project describ ed this pattern bluntly: some AI-assisted submissions were “w ell-formatted, looked really neat, and did nothing it said it did” [ 50 ]. Review therefor e cannot shift from correctness checking to style checking. (3) A uthorship and responsibility . A third concern is whether a contributor actually understands, explains, and owns the change. typescript-eslint captures this especially sharply: maintainers do not want review to be come “eectively babysitting some- one’s Claude instance via the code review process” [ 58 ]. The issue is not AI use alone, but whether a human author remains accountable. (4) Review capacity . A fourth concern is that review capacity becomes the rst b ottleneck. Projects therefore describe AI con- tribution primarily as a review problem rather than a generation problem. Oh My Zsh summarizes the asymmetry succinctly: “re- view is the bottleneck. Not code generation. ” [ 51 ]. FastAPI makes the same point even more forcefully , describing low-eort AI submissions as “a Denial-of-ser vice attack on our human ef- fort” [14]. 2. Communication. In communication and discussion, the same responsibility problem appears as low-value AI text and weaker hu- man exchange. typescript-eslint states this directly: AI-generated PR descriptions are often “nearly-v erbatim descriptions of the code di, which add no value to the PR” [ 57 ]. Jaeger states the cor- responding expe ctation for review interaction just as succinctly: “Code review is a discussion between p eople, not bots” [ 28 ]. The objection is therefore not simply to verbosity , but to generated text that adds little context and displaces direct human exchange. 3. Issue triage. At issue entry , the problem is triage costs : AI makes reports lo ok plausible without making them more actionable. NewPipe encodes this problem explicitly by banning AI-written issue and PR templates, stating that “Those texts are often lengthy and miss critical information” [ 43 ]. What matters at this stage is whether a report contains the specic information ne eded for triage. 4. Security reporting. Security reporting is the same triage prob- lem in high-priority channels . curl states this concern particularly clearly: because se curity reports are investigated with priority , “fake and otherwise made up security problems eectively pre- vent us from doing real pr oject work and make us waste time and resources” [7]. Fabricated or unveriable AI reports are especially costly because they immediately consume scarce security-handling time. 5. Adversarial incentives. In some contexts, maintainers frame the problem as adversarial incentives. When rewards remain in place, AI lowers the cost of producing bad-faith or low-value reports. curl provides the clear est example in the context of bug bounties: “ A bug b ounty gives people too strong incentives to nd and make up ‘problems’ in bad faith that cause overload and abuse ” [ 54 ]. Here the concern is not mere noise, but noise made worthwhile by institutional incentives. 6. Provenance and licensing. For some projects, the concern is not output quality but copyright/licensing/provenance uncertainty . Beyond Banning AI: A First Look at GenAI Governance in Open Source Soware Communities QEMU states the legal uncertainty directly: with AI content gener- ators, “the copyright and license status of the output is ill-dened with no generally accepted, settled legal foundation” [ 49 ]. NetBSD operationalizes the same concern even more bluntly by treating LLM output as “presumed to be tainted code” [ 42 ]. Here the issue is not ordinar y review quality , but whether such inputs can be admitted at all. 7. P latform and tooling. Finally , some projects lo cate part of the problem in platform defaults/to oling limits that amplify the concerns above. Zig’s maintainers describe GitHub’s Copilot issue composer as taking a user’s “simple explanation of a bug” and rewriting it into “a multi-paragraph monologue with no interesting details and added false information” [ 71 ]. tldraw links its temporary closure of external PRs directly to infrastructure limits, calling it “a temporary p olicy until GitHub provides better tools for managing contributions” [ 56 ]. Here the issue is not only what contributors do, but what platforms make easy and what projects still cannot control. 5 RQ2: Governance Orientations and Strategies T o answer RQ2, we rst identify three governance orientations that explain why projects facing similar GenAI pressures develop markedly dierent institutional responses. W e then derive 12 con- crete governance strategies through which these orientations are operationalized across collaboration surfaces. 5.1 Governance orientations After op en-coding maintainer concerns, w e compared how projects interpreted these problems, where they located core risks, and how they allocated governance responsibility . W e found that cross- project variation cannot b e explained simply in terms of whether a project “allows AI. ” Instead, through iterative comparison, we de- rived three recurring governance orientations—higher-order judg- ments, not static lab els or maturity rankings—that reect three distinct ways of framing the governance problem: whether certain inputs should enter the workow at all; whether they may enter under explicit boundaries of accountability , visibility , and verica- tion; or whether they should be absorb ed into existing quality and maintainer-cost controls. Organizational form and domain context function as boundar y conditions that shape where pressure rst arises, but do not reliably predict which orientation a project adopts. Across the 67 cases, O2 was the most common dominant orienta- tion (40 cases, 59.7%), follo wed by O1 (14, 20.9%) and O3 (13, 19.4%). T wenty-three cases displayed mixed governance logics, combining a dominant orientation with material elements of a se condary one. O1: Prohibitionist / zero-tolerance . The core judgment behind O1 is that certain GenAI-related inputs present structural, non- absorbable risk —including provenance uncertainty , copyright and licensing incompatibility , or taintedness—and should therefore not be absorb ed into the existing review process. The prior question is not how to revie w such inputs more eectively , but whether they should enter the workow at all. QEMU states that it will “DECLINE any contributions which are b elieved to include or derive from AI generate d content” [ 49 ]. NetBSD similarly states that LLM- generated code “is presumed to be tainted code, and must not be committed without prior written approval by core” [ 42 ]. These texts dene AI-generated code as a class of input whose admissibility is in question from the outset. O2: Boundary-and-accountability . The core judgment behind O2 is that GenAI-related inputs may enter the workow , but only under explicit conditions of accountability , visibility , and verica- tion. Rather than excluding AI-me diated input categorically , this orientation treats AI as a distinct governance object requiring ex- plicit rules across multiple collaboration surfaces ( multi-surface boundary governance ). CloudNativePG states that the goal is “not to ban AI entirely , ” but to shift “the burden of proof back to the con- tributor , ” requiring “full human accountability for any AI-assisted work” [ 5 ]. llama.cpp draws the boundary more explicitly: AI tools may be used “solely in an assistive capacity , ” and “all AI usage requires explicit disclosure ” [35]. O3: Quality-rst / tool-agnostic. The core judgment behind O3 is that projects prefer to absorb AI-related inputs into existing expec- tations around contribution quality , maintainability , and maintainer cost, rather than building AI-specic governance rules ( reasserting existing quality thresholds under cheaper generation conditions ). The key question is not whether AI was used, but whether the input is reviewable , maintainable, and worth maintainers’ limited time. Oh My Zsh expresses this clearly: “Not a moral stance. Not a ban. Just clarity around expectations and accountability” and “W e’re not in- terested in policing to oling. W e ’re interested in accountability . ” [ 51 ]. curl articulates the same logic: licensing and quality obligations apply “independent if AI is used or not” [7]. Boundary conditions. The boundaries among the three orienta- tions lie in higher-order judgments ab out what kind of governance problem GenAI presents, not in any single device such as disclo- sure or templates. The O2/O3 boundary was the least sharp, so we distinguished O2 from O3 by asking whether projects introduced AI- specic governance mechanisms, treated disclosur e as a gate rather than a calibration aid, and targeted AI-specic non-compliance rather than general quality control. The three orientations should therefore be read as ideal-typical governance logics rather than static labels or a ranking of policy strictness. 5.2 Governance strategies While go vernance orientations capture why projects r espond dier- ently , governance strategies capture how those orientations are op- erationalized across contribution workows. Thr ough cross-project comparison, we derived 12 strategies that cluster into four func- tional groups: entry admissibility and input qualication , responsi- bility and evidence restoration , review burden and workow protec- tion , and infrastructure and institutional adjustment . Figure 1 maps their within-orientation prevalence . In broad terms, O1 concentrates on front-gate and infrastructural controls, O2 carries the broadest AI-specic governance layer , and O3 relies more heavily on general- purpose quality controls while adopting fewer explicit AI-specic mechanisms. W enhao Y ang, Runzhi He, and Minghui Zhou O1: Prohibitionist (n=14) O2: Boundar y & Accountability (n=40) O3: Quality-First Proceduralist (n=13) A. Entry admissibility and input qualication What may enter , and on what terms? B. Responsibility and evidence restoration Who is responsible, and what must be shown? C. Review burden and workow protection How is maintainer capacity protected? D. Infrastructure and institutional adjustment What must change beyond repository rules? Boundary Exclusion (93%) Boundary Exclusion (43%) Transparency & Disclosure (7%) Transparency & Disclosure (83%) Transparency & Disclosure (31%) Compliance & Provenance (29%) Compliance & Provenance (43%) Compliance & Provenance (15%) Accountability Reinforcement (7%) Accountability Reinforcement (88%) Accountability Reinforcement (77%) V erication & Evidence Gating (50%) V erication & Evidence Gating (31%) AI Tooling Governance (23%) Scope & Intentionality Control (35%) Scope & Intentionality Control (23%) Capacity & Queue Control (3%) Moderation & Sanctions (7%) Moderation & Sanctions (60%) Moderation & Sanctions (54%) Security Channel Governance (8%) Channel & Platform Recong. (14%) Channel & Platform Recong. (3%) Incentive Redesign (3%) ≥ 70% 35–69% 15–34% < 15% Empty = not observed Figure 1: Governance strategies mapped by functional group (rows) and governance orientation (columns). Shading intensity reects within-orientation prevalence using four bands ( ≥ 70%, 35–69%, 15–34%, and < 15%). Percentages in parentheses show the share of cases within that orientation that exhibit the strategy , while orientation totals are reported in the column headers. Empty cells indicate that the strategy was not observed in that orientation. Function A. Entr y admissibility and input qualication. These strategies move governance toward the point of intake, addressing what kinds of inputs may enter the system and what qualifying information must accompany them. A1. Boundary Exclusion / Reject-or-Ban. Boundary exclusion governs the b ehavior of excluding certain classes of GenAI-mediated input from the acceptable contribution surface altogether . Unlike disclosure, accountability , or verication, this strategy does not ask how to re view GenAI-related input more eectively . It asks a prior admissibility question: whether such input should be treated as r eviewable at all. A ccordingly , its clearest expressions are not r e quests for explanation, but statements such as “will not accept, ” “does not allow , ” “decline, ” or “must not be committed. ” As illustrated by QEMU’s and NetBSD’s e xplicit exclusion lan- guage (see O1 abov e), boundary exclusion operates not as a stricter review rule, but as a refusal to treat certain inputs as ordinarily admissible. The main benet is front-loading the forms of uncertainty main- tainers most want to avoid at the stage of admissibility judgment, reducing the need to repeatedly re-litigate boundaries during review . The cost is equally clear: projects narrow the surface of acceptable participation. Boundary exclusion is near-universal in O1 (93%) but also appears in 43% of O2 projects, where it typically applies selec- tively to specic contribution surfaces—such as fully generated PRs or unveried security reports—rather than as a blanket prohibition. A2. Transparency and Disclosure. Disclosure seeks not to determine whether AI may be used, but to turn AI use from a hidden practice into a visible, discussable, and Beyond Banning AI: A First Look at GenAI Governance in Open Source Soware Communities reviewable input signal. Its immediate target is contributors’ report- ing behavior when submitting issues, PRs, comments, or reports. What maintainers need is not abstract transparency for its own sake, but a way to calibrate expectations once inputs become longer , more polished, and more contribution-like. Disclosure helps them distinguish between what appears to come from the contributor’s own understanding and what depends heavily on mo del-generated output. Spec Kit states that if a contributor uses “any kind of AI assis- tance, ” it “must be disclosed in the pull request or issue, ” and adds that failure to disclose makes it harder “to determine how much scrutiny to apply” [ 52 ]. This captur es disclosure not as moral signal- ing, but as review calibration. In more formalize d settings, the same logic is pushed into templates or dedicated elds so that AI use becomes intake information rather than an after-the-fact suspicion. The main b enet of disclosure is that it reduces maintainers’ up-front information-disco very cost. The y do not need to rst infer how an input was produced before deciding how to process it. At the same time, the trade-o is concrete: contributors must bear additional metadata-reporting costs, and explicit AI marking may generate concerns about dierential treatment. For this reason, many projects pair disclosur e requirements with explicit statements that they do not intend to police tools per se, but to use disclosure as a more rational revie w-calibration signal. A3. Compliance and Prov enance Safeguarding. Unlike boundary e xclusion, compliance and provenance safeguards do not necessarily require direct prohibition. More often, they ap- pear in projects that allow some degree of AI use while insisting that contributors retain responsibility for redistributability , license compatibility , and lawful prov enance. The central behavior being governed is therefore the contributor’s obligation to make these judgments before submission, rather than leaving them for main- tainers to reconstruct case by case during review . mpv states that AI-assiste d contributions “ar e not forbidden, ” but the submitter “takes full responsibility” and must conrm that the code can be submitted under the relevant license; curl similarly insists that “the burden is on them to ensure no unlicense d code is submitte d” [ 7 , 41 ]. The core move is to push provenance and redistributability checks back onto contributors before te chnical review begins. The b enet is reallocating legal and prov enance uncertainty away from maintainers. The cost falls on contributors, who must evaluate not only whether the content works but whether it can be redistributed under clear provenance . This strategy’s role varies sharply by orientation: in O1, provenance uncertainty ser ves as a rationale for categorical exclusion; in O2, it becomes a contributor- facing compliance obligation; in O3, it is folded into general licens- ing responsibility . Function B. Resp onsibility and evidence restoration. These strategies address how projects restore accountability , explanation, and evidence where GenAI makes them thinner . B1. Accountability Reinforcement. Accountability reinforcement seeks to pull responsibility back from the tool to the named human contributor . It does not primarily regulate whether AI was used. Instead, it regulates whether the submitter understands the content, can explain it during review , and is willing to remain responsible for revising, defending, and maintaining it. In this way , the strategy r edenes authorship as a responsibility relation rather than a mere act of submission. CloudNativePG states that “The human contributor is the sole party responsible for the contribution, ” and that “The AI generated it” is “never an acceptable answ er”; Jaeger echoes the same expec- tation with “Y ou own everything you submit” and “Code review is a discussion between pe ople, not bots” [ 4 , 28 ]. These policies treat authorship less as the act of opening a PR than as the continuing duty to explain, revise , and stand behind it. The principal benet is reducing maintainers’ uncertainty about who really understands the change and will remain responsible for it. The trade-o is substantial: this strategy raises the bar for participation by tying admissibility to explainability and sustained responsibility . In O2, accountability reinforcement forms part of an explicit AI-specic b oundary regime (“The AI generate d it is never an acceptable answer”), whereas in O3 it is more often absorbed into general contribution-quality expectations. B2. V erication and Evidence Gating. V erication and evidence gating seeks to change contributor be- havior by requiring sucient supporting material b efore an input is processed further . This may include local test logs, proof-of-concept artifacts, reproduction steps, references, or e xplicit human valida- tion notes. The key governance move is not to ask revie wers to be more careful, but to shift the burden of demonstrating veriability toward the submitter . Kornia encodes verication as an explicit gate: “Every PR in- troducing functional changes must include a paste d snippet of the local test logs, ” and implementations must cite an “ existing li- brary reference” for verication [ 31 ]. In security reporting, similar hard evidence thresholds apply (see Security Channel Governance below). These rules shift the burden from revie wer inference to submitter-provided evidence. The benet is reducing se condary verication cost during review; the trade-o is a clear increase in submission preparation cost. V erication is more prevalent in O2 (50%) than O3 (31%), reecting O2’s tendency to add evidence requirements as part of its AI-spe cic boundary regime, whereas O3 projects more often rely on pre- existing quality gates without adding new AI-motivated evidence thresholds. B3. AI T o oling Governance . AI tooling governance belongs in this group be cause it also seeks to restore responsibility and control, but does so at the tool layer rather than only at the human layer . Compared with accountability and verication, it is a further step: projects do not mer ely r egulate how humans should use AI, but begin to regulate AI tools and agents directly through les such as AGENTS.md , Copilot instructions, or other tool-facing repository rules. JabRef ’s AGENTS.md makes the tool-facing nature of this strategy explicit: agents must “Never commit generated code without human review , ” must not “W rite entire PRs, ” and must not “ A utomate the submission of code changes” [ 27 ]. The result is governance that W enhao Y ang, Runzhi He, and Minghui Zhou addresses not only human conduct, but the expe cted behavior of the tools themselves. The b enet of tooling governance is that it allows some gov- ernance work to happen before low-quality or poorly attributable inputs reach r eview , by constraining the tool’s role dir ectly . It there- fore shifts some control fr om ex post evaluation to ex ante interface design. Its costs are also distinctive. First, it depends heavily on whether tools and agent ecosystems actually r ead and comply with repository-level instructions. Se cond, projects themselves must maintain a layer of policy text written for machine consumption and keep it aligned with ordinar y contributor-facing rules. The challenge here is therefore not only rule design, but the stability of the interface between repository p olicy and tool behavior . Function C. Review burden and workow protection. These strategies protect maintainer time, review queues, and high-priority channels once inputs hav e already entered the system. C1. Scope and Intentionality Control. Scope and intentionality control governs not only PR size, but whether a contribution is framed within the right problem context. Projects use this strategy to require small, focuse d, issue-linked, and intentionally scoped submissions, thereby discouraging broad, speculative, or misaligne d PRs that arrive b efore the underlying problem has been accepted. CloudNativePG states “Design First” for non-trivial changes and warns that PRs arriving “ out of the blue ” may be closed if they do not align with project context [ 4 ]. PyT orch formalizes the same logic upstream by stating that “PRs must have an associated actionable Issue” [ 48 ]. In both cases, the point is to ensure that review does not b ecome the place where maintainers must rst reconstruct why the work should exist. The benet of this strategy is that it lowers the cost of problem redenition during review . Maintainers are less often forced to ask why a contribution exists, why it takes its current scope, and whether it ts the project’s priorities. The trade-o is that more ltering work moves upstream into issue triage and proposal stages, reducing the space for drive-by contributions and fast exploratory participation. C2. Capacity and Queue Control. Capacity and queue control treats the review queue itself as a scarce resource in ne ed of governance. Instead of fo cusing on the technical content of an individual submission, it regulates input rate, concurrency , and re view load. This strategy makes explicit a practical reality of OSS maintenance: ev en when contributors act in good faith, review bandwidth remains limite d, and GenAI can signicantly increase the rate at which revie wable-lo oking inputs are produced. Jaeger states that “we limit the numb er of simultaneous open PRs for new contributors” and that e xcess PRs may be labeled “on-hold” or closed [ 29 ]. Here the governance target is not the correctness of any single patch, but how much simultane ous review er attention a contributor may occupy . The benet is making maintainer time gov- ernable as a resource; the cost is that waiting time and participation friction are reallocated to contributors, especially newcomers. C3. Moderation and Sanctions. Moderation and sanctions govern what happens once certain classes of input have already been judged low-eort, repeatedly non-compliant, adversarial, or not worth further processing. Rather than trying to improve such inputs, this strategy denes more con- sistent ways to close, reject, block, or ban them, thereby reducing the cost of repeated case-by-case negotiation. pandas states that maintainers may “ban users from contribut- ing” if they violate the guidelines repeatedly; CPython likewise notes that unproductive AI-generated issues or PRs may be closed and repeat submitters “may b e blocked”; curl goes further in se- curity contexts: “W e ban users immediately who submit made up fake reports” [ 7 , 45 , 47 ]. Moderation is widespread in both O2 and O3 but functions less as a standalone governance logic than as an enforcement amplier whose eectiveness depends on other strategies—disclosure, verication, or scope control—already being in place. C4. Security Channel Governance. Security channel governance belongs in this group b ecause it pro- tects a particularly scarce and high-value workow: vulnerability handling. Unlike ordinary PRs or general issue reports, security sub- missions often receive elevated pr ocessing priority . This strategy therefore gov erns what counts as an actionable security input and what level of evidence , disclosure, and reproducibility is required before high-priority maintainer resources are engaged. curl warns that it is “rarely a go od idea to just copy and paste an AI generated report” and instead tells reporters to “write the report yourself ” after verifying the problem [ 7 ]. llama.cpp adds a hard evidence threshold by r equiring that “Y our report must include a working Proof-of-Concept” [ 36 ]. The shared logic is to front-load actionability before scarce security attention is engaged. The benet of this strategy is that it prevents fabricated, specu- lative, or unv eriable inputs from cr owding out r eal vulnerabilities. The trade-o is a higher r eporting threshold: weaker but potentially useful leads may be ltered out if they do not me et the required stan- dard of evidence . Projects thus exchange lower waste in se curity triage for a narrower and mor e demanding reporting interface. Function D. Infrastructure and institutional adjustment. When repositor y-level rules are insucient, some projects adjust the surrounding infrastructure or institutional conditions under which contributions enter the system. D1. Channel, V enue, and P latform Reconguration. Channel, venue, and platform reconguration governs not primar- ily what contributors submit, but wher e and thr ough which interface they are allowed to submit it. When maintainers conclude that repository-level rules can no longer control the relevant problems, they may suspend external PRs, redirect reporting channels, or even migrate their main collaboration venue. tldraw states that it is “not accepting pull requests from external contributors” and that such PRs “will be automatically closed” un- til GitHub provides b etter tools for managing contributions [ 56 ]. Zig represents a str onger infrastructural move: after migrating to Codeberg, it explicitly expected “fewer violations” of its strict no-AI policy because GitHub had b een pushing AI-assisted entr y points Beyond Banning AI: A First Look at GenAI Governance in Open Source Soware Communities so aggressiv ely [ 72 ]. Here the governance response is not to review inputs dierently , but to change the channel thr ough which they arrive. The benet of this strategy is that it changes the entr y architec- ture itself rather than asking maintainers to repeate dly interpret and enforce the same boundaries after the fact. Its costs, ho wever , are substantial. Contributors must adapt to new channels or platforms, and projects assume new infrastructural burdens and potential ecosystem friction. For this reason, reconguration typically ap- pears as an escalation strategy when repository-level governance is judged insucient. D2. Incentive Redesign. Incentive redesign is one of the least frequent but most r evealing strategies in the corpus. It do es not regulate how a particular input is written or revie wed. Instead, it targets the broader r eward structure that makes certain kinds of harmful input worth producing in the rst place. In this sense, it governs not content quality directly , but the institutional conditions that generate p ersistent low-value or adversarial submissions. curl makes this logic unusually explicit: it removed re wards “to remove the incentives for submitting made up lies” and later gener- alized that “A bug bounty gives people too strong incentives to nd and make up problems in bad faith” [ 54 ]. By addressing harmful input at the level of institutional reward rather than do wnstream l- tering, this strategy functions as a high-cost governance escalation that may also discourage some good-faith participation. 6 Threats to V alidity and Limitations 6.1 Coverage and Transferability Our corpus intentionally privileges visible OSS projects and policy- rich governance environments. The seed frame began with the top- ranked repositories on Gitstar Ranking’s repository leaderboard and was then extended through theoretically motivated snowball sampling, resulting in a varied and reasonably size d corpus. Ac- cordingly , the ndings should be interpreted as an analytically transferable account of publicly visible GenAI go vernance rather than a prevalence estimate for the entire OSS ecosystem. Smaller projects, low-activity repositories, non-GitHub communities, and non-English communities may encode similar pr essures less explic- itly or govern them dierently . 6.2 Publicly Enco ded Gov ernance vs. Enacted Practice This study analyzes governance as it is publicly expr essed and institutionally encoded in project materials. Actual governance may also depend on private maintainer discussions, discretionary triage, informal coordination, moderation practices, or security workows that are not visible in repositor y texts. Our ndings should therefore be read as an account of public governance interfaces rather than a complete account of every path through which OSS projects actually process AI-related contributions. W e also do not directly evaluate the causal eectiveness of these rules or whether they are enforced uniformly . 6.3 Interpretive and T emporal Limits These categories remain interpretive abstractions rather than natu- rally given classes. The three orientations are best understood as ideal-typical dominant logics, and orientation counts should there- fore be read as appro ximate patterning rather than sharp natural groupings, especially near the O2/O3 boundar y . Strategy ndings are less sensitive to that boundary because strategy presence was coded independently of orientation. In addition, GenAI-related governance is changing quickly: plat- forms, tools, and project rules continue to shift over short periods of time. Our analysis is thus a cross-sectional account of one time window , and later governance changes may alter how particular OSS projects are best interpreted. 7 Discussion 7.1 GenAI Reshap es and Front-loads OSS Governance Our results demonstrate that GenAI governance is rarely a from- scratch invention. Instead, it represents a front-loading redesign of existing governance me chanisms. Pull-based development has always faced “review friction” [ 20 ], and the open source communi- ties have invented strategies, including contribution and se curity guidelines, issue and PR templates, proposal and approval work- ows, to gate control external contributions, balance maintainer workload, and coordinate collaboration eorts. GenAI creates a radical socio-technical asymmetry , where the cost of producing a plausible, complete-looking PR approaches zero, while the cost of reviewing it remains high or even incr eases. Consequently , we observe a shift from downstream code review to upstream admission control . Strategies like Scope and Intentionality Control (requiring pr e-approved issues) or V erication and Evidence Gating (requiring proof-of-concept before review) ar e attempts to protect the most scarce resource in OSS: maintainer attention [ 10 ]. By forcing contributors to justify the “why” and “how” before main- tainers look at the “what, ” projects are eectively moving the triage line further up the workow to sur vive “ denial-of-service attack” of AI-assisted inputs. 7.2 From Repositor y to Infrastructure-Level Governance While most projects in the corpus have shown agility in up dating governance policies in markdown les, our results reveal the limits of repository-level governance. T ext-based rules (CON TRIBU TING, SECURI T Y) are often reactiv e and might easily bypassed by coding agents or low-eort human submitters. The platform-and-tooling concern identied in RQ1 suggests that as long as platforms provide “one-click” AI generation path without corresponding identication or intake controls, repository rules will remain under siege. W e are beginning to see the emergence of infrastructure-level countermeasures that bypass the repository ruleset entirely . For ex- ample, Vouch [ 21 ] reframes entr y as a web-of-trust problem, where contributions are ltered based on endorsement before revie w: participants may need to be vouched for b efore interacting with selected project surfaces, and pr oje cts can extend this further into a web-of-trust model across repositories. Similarly , Agent-Trace [ 8 ] W enhao Y ang, Runzhi He, and Minghui Zhou proposes a machine-readable provenance format of AI contribu- tions, conversation links, and le- or line-level attribution, to shift the burden of “proof of work” from human disclosure to tool-lev el transparency . These shifts suggest that the future of OSS gover- nance lies not just in writing better markdown les, but in recong- uring the infrastructure itself to make GenAI contributions legible and governable by default. 7.3 Implications for Maintainers and Platform Designers For maintainers , the immediate implication is that there is no “one- size-ts-all” AI policy . Eective governance requires rst diagnos- ing the specic bottlene ck: is it legal uncertainty , revie w capacity , or security channel noise? Our strategy-orientation map (Figure 1) provides a menu for this diagnosis. For example, a project strug- gling with “ AI slop” in security reports might prioritize V erication and Evidence Gating , whereas a project concerne d with long-term code quality might double down on A ccountability Reinforcement and Scope & Intention Control . By matching specic strategies to their primary bottlene ck, maintainers can craft policies that protect the project without blocking valuable human- AI collaboration. For platform designers , the fo cus must shift from “generation power” to “intake control” and “traceability . ” Shipping featur es that encourage “eortless-to-pr oduce but expensive-to-validate” contri- butions without providing the tools to detect, prioritize, or block them creates an unsustainable burden on the community . Platforms must facilitate higher-information collaboration interfaces—such as machine-readable AI metadata—to ensure that the productivity gains of GenAI do not come at the cost of OSS community burnout. 7.4 Future W ork Ecacy of Disclosure Policies. While Transparency and Disclosure is a dominant and seemingly approachable strategy , little is known about its actual compliance rate. Future work may empirically measure the eectiveness of disclosure rules – specically , how often AI use is self-admitte d versus hidden, and whether mandator y disclosure leads to systemic bias in how maintainers treat certain contributions. A utomate d Triage. As the volume of agent-assisted PRs increases, maintainers ne ed pr oactive tools to manage the “attention tax” [ 39 ]. Researchers may develop triage methods to identify low-quality agentic contributions with possibly high maintenance cost, enabling maintainers to fast-fail costly “ghosting” attempts. Long-term Code and Community Health. The rise of agentic cod- ing may translate into a signicant “ow-debt tradeo ” . He et al. [ 22 ] nd that the adoption of Cursor can transiently b oost de- velopment velocity , while leading to a persistent increase in static analysis warnings and code complexity . Futur e longitudinal studies are needed to assess whether GenAI governance regimes success- fully maintain long-term software quality , or if they inadvertently accelerate technical debt. 8 Conclusion This paper pro vides a systematic account of how OSS projects govern GenAI in contribution workows. Drawing on a corpus of public governance materials from 67 OSS projects, we showed how GenAI enters OSS collaboration at multiple workow stages, what maintainer concerns it raises across these stages, and what governance responses projects articulate. Our results show that GenAI governance in OSS is not reducible to a simple question of whether projects permit or prohibit AI. Instead, projects confront a broader set of governance problems concerning admissibility , contributor responsibility , verication, re- view bottlenecks, triage costs, provenance uncertainty , and platfor- m/tooling limits. W e identied three governance orientations that explain how projects interpr et these problems dierently , and we abstracted a cross-project strategy space of gov ernance responses and implementation patterns. T aken together , these ndings provide a comparative account of GenAI governance in OSS and clarify how dispersed project prac- tices form a broader gov ernance landscape. W e hope this account can support future research on GenAI and software collaboration, while also helping maintainers, communities, and platform design- ers better understand where governance support is most needed. References [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 Engineering 48, 12 (2022), 4838–4856. doi:10.1109/TSE.2021.3128356 [2] Matthew Baird, Mar Carpanelli, Brian Xu, and K evin 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. [3] Ruben Branco, Paulo Canelas, Catarina Gamboa, and Alcides Fonseca. 2026. LGTM! characteristics of auto-merged LLM-based agentic PRs. In Pr oceedings of the 23rd International Conference on Mining Software Rep ositories (MSR ’26) . Association for Computing Machiner y , New Y ork, N Y, USA, 1–5. ht tp s:/ /p c anel as.c om/as sets /pap ers/ 2026 - msr- lgtm. pdf Accepted at MSR 2026 Mining Challenge; preprint available online. Accessed: 2026-03-26. [4] CloudNativePG Contributors. 2026. CloudNativePG AI Contribution Policy. GitHub repository le. https://github.com/cloudnative- pg/governance/blob/m ain/AI_POLICY .md Accessed: 2026-03-26. [5] CloudNativePG Contributors. 2026. Proposal: Adoption of Ocial AI Contri- bution & Copyright Policy . GitHub Issue. ht tp s :/ /g it hu b. co m/ cl ou dn at ive - pg/governance/issues/45 Accessed: 2026-03-26. [6] Matteo Collina. 2026. Virtual File System for Node.js. GitHub Pull Request #61478, nodejs/no de. https: //g ith ub. com /no dej s/ node /pu ll/ 614 78 Accessed: 2026-03-26. [7] curl Contributors. 2026. On AI use in curl. GitHub repositor y le. h t t p s : / / g i t h u b . c o m / c u r l / c u r l / b l o b / m a s t e r / d o c s / C O N T R I B U T E . m d Accessed: 2026-03-26. [8] Cursor Contributors. 2026. Agent Trace. Open specication, version 0.1.0 (RFC). https://agent- trace.dev/ Accessed: 2026-03-27. [9] Docusaurus Contributors. 2026. Contributing to Docusaurus: AI-assisted PRs. GitHub repository le. https://github.com/f acebook/docusaurus/blob/main/C ONTRIBU TING.md Accessed: 2026-03-26. [10] Nadia Eghbal. 2020. W orking in Public: The Making and Maintenance of Open Source Software . Stripe Press, South San Francisco, CA, USA. [11] Omar Elazhar y , Margar et- 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? . In 2019 IEEE International Conference on Software Maintenance and Evolution (ICSME) . IEEE, Los Alamitos, CA, USA, 286–290. doi:10.1109/ICSME. 2019.00043 [12] Bruna Falcucci, Felip e Gomide, and André Hora. 2025. What do contribution guidelines say about software testing?. In 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR) . IEEE, Los Alamitos, CA, USA, 434–438. doi:10.1109/MSR66628.2025.00073 [13] Angela Fan, Beliz Gokkaya, Mark Harman, Mitya Lyubarskiy, Shubho Sengupta, Shin Y oo, and Jie M Zhang. 2023. Large language mo dels for software engine ering: survey and open problems. In 2023 IEEE/ACM International Conference on Software Engineering: Future of Software Engineering (ICSE-FoSE) . IEEE, IEEE, Los Alamitos, CA, USA, 31–53. doi:10.1109/ICSE- FOSE59343.2023.00008 [14] FastAPI Contributors. 2026. Contributing to FastAPI: A utomate d Code and AI. GitHub repository le. https://github.com/f astapi/f astapi/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 Open Source Soware Communities [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] [16] Nicole Forsgren, Margaret- Anne Storey , Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler . 2021. The SPA CE of developer productivity: there’s mor e to it than you think. ACM Queue 19, 1 (2021), 20–48. doi:10.1145/34 54122.3454124 [17] Haoyu Gao, Peerachai Banyongrakkul, Hao Guan, Mansooreh Zahe di, and Christoph Treude . 2026. On autopilot? An empirical study of human-AI team- ing and review practices in open source. arXiv preprint doi:10.48550/arXiv.2601.13754 [cs.SE] [18] Gitstar Ranking. 2026. Repositories Ranking - Gitstar Ranking. W ebsite. https: //gitstar- ranking.com/repositories Accessed: 2026-03-26. [19] Thibaud Gloaguen et al . 2026. Evaluating AGENTS.md: are repository-level context les helpful for coding agents? arXiv preprint arXiv:2602.11988. doi:10 .48550/arXiv.2602.11988 [cs.SE] [20] Georgios Gousios, Martin Pinzger , and Arie van Deursen. 2014. An explorator y study of the pull-based software development model. In Proceedings of the 36th International Conference on Software Engineering . Association for Computing Machinery , New Y ork, N Y, USA, 345–355. doi:10.1145/2568225.2568260 [21] Mitchell Hashimoto and V ouch Contributors. 2026. V ouch. GitHub repository. https://github.com/mitchellh/vouch Accessed: 2026-03-27. [22] Hao He, Courtney Miller , Shyam Agarwal, Christian Kästner, and Bogdan V asilescu. 2026. Sp eed at the cost of quality: how Cursor AI increases short- term velocity and long-term complexity in op en-source projects. In Proceed- ings of the 23rd International Conference on Mining Software Rep ositories (MSR ’26) . Association for Computing Machinery , New Y ork, NY, USA, 1–19. https: //arxiv .org/abs/2511.04427 Accepted at MSR 2026 Mining Challenge; preprint available at arXiv . Accessed: 2026-03-26. [23] Xinyi Hou, Y anjie Zhao, Yue Liu, Zhou Y ang, Kailong W ang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu W ang. 2024. Large language models for software engineering: a systematic literature review . ACM Transactions on Software Engineering and Methodology 33, 5 (2024), 1–41. doi:10.1145/3695988 [24] Immich Contributors. 2026. Object storage. GitHub Discussion. https://github.c om/immich- app/immich/discussions/23745 Accessed: 2026-03-26. [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. [26] Fedor Indutny . 2026. No AI in No de.js Core: A Petition to Disallow Acceptance of LLM-Generated Pull Requests. GitHub Repositor y . https://github.com/indut ny/no- ai- in- nodejs- core Accessed: 2026-03-26. [27] JabRef Contributors. 2026. AGENTS.md — JabRef. GitHub repository le. https: //github.com/JabRef/jabref /blob/main/AGEN TS.md Accessed: 2026-03-26. [28] Jaeger Contributors. 2026. Contributing Guidelines: AI Usage Policy . GitHub repository le. https://github.com/jaeg ertracing/jaeger/blob/main/CON TRIBU TING_GUIDELINES.md#ai- usage- policy Accessed: 2026-03-26. [29] Jaeger Contributors. 2026. Introduce PR limits for new contributors. GitHub Pull Re quest. h tt ps: // gi th ub .co m/ ja eg ert ra ci ng /ja eg er /p ul l/7 88 0 Accessed: 2026-03-26. [30] Sushawapak Kanchar oendee, Thanat Phichitphanphong, Chanikarn Jongy- ingyos, Brittany Reid, Raula Gaikovina Kula, Morakot Choetkiertikul, Chaiyong Ragkhitwetsagul, and Thanwade e Sunetnanta. 2025. On categorizing open source software security vulnerability reporting mechanisms on GitHub. In 2025 IEEE In- ternational Conference on Software Analysis, Evolution and Reengineering (SANER) . IEEE, Los Alamitos, CA, USA, 751–756. doi:10.1109/SANER64311.2025.00076 [31] Kornia Contributors. 2026. Kornia AI and A uthorship Policy. GitHub repository le. http s://g ithub .com/ korn ia/ko rnia/ blob/ main /AI_P OLICY .md Accessed: 2026-03-26. [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] [33] Zhixing Li, Y ue Yu, Minghui Zhou, T ao W ang, Gang Yin, Long Lan, and Huaimin W ang. 2022. Re dundancy , context, and preference: an empirical study of duplicate pull requests in OSS projects. IEEE Transactions on Software Engineering 48, 4 (2022), 1461–1476. doi:10.1109/TSE.2020.3018726 [34] Johan Linåker , Georg J. P. Link, and K evin 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] [35] llama.cpp Contributors. 2026. AI Usage Policy. GitHub repository le. https: //github.com/ggml- org/llama.cpp/blob/master/CON TRIBUTING.md Accessed: 2026-03-26. [36] llama.cpp Contributors. 2026. Security Policy. GitHub repositor y le. https: / /g i t h u b . c om / g g m l - or g / l l a m a . cp p / b l o b / m as t e r / S E C U RI T Y . m d Accessed: 2026-03-26. [37] Matplotlib Contributors. 2026. [PERF] Replace np.column_stack with np.vstack(). T . GitHub Pull Request. ht t p s : / /g i t h u b . c o m / m a t p l o t l i b/ m a t p lotlib/pull/31132 Accessed: 2026-03-26. [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] [39] Dao Sy Duy Minh, Huynh T rung Kiet, Nguyen Lam Phu Quy , Pham Phu Hoa, Tran Chi Nguyen, Nguyen Dinh Ha Duong, and T ruong Bao Tran. 2026. Early- Stage Prediction of Review Eort in AI-Generated Pull Requests. In Procee dings of the 23rd International Conference on Mining Software Rep ositories (MSR ’26) . doi:10.1145/3793302.3793609 arXiv preprint [40] Seyedmoein Mohsenimodi, 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] [41] mpv Contributors. 2026. AI-assisted Contributions. GitHub repository le. ht tps :/ /g it hub .c om /m pv- p lay er /m pv/ bl ob /m as ter /D OC S/ con tr ib ut e.m d# ai- assisted- contributions Accessed: 2026-03-26. [42] NetBSD Developers. 2026. NetBSD Commit Guidelines. NetBSD Project W ebsite. h t t p s : / / w w w. n e t b s d . o r g / d e v e l o p e r s / c o m m it - g u i d e l i n e s . h t m l Accessed: 2026-03-26. [43] NewPipe Contributors. 2026. NewPipe Contributing: AI policy . GitHub reposi- tory le. https://github.com/TeamNewPipe/NewPipe/blob/dev/.github/CON T RIBUTING.md Accessed: 2026-03-26. [44] Nhan Nguyen and Sarah Nadi. 2022. An empirical evaluation of GitHub Copilot’s code suggestions. In Proceedings of the 19th International Conference on Mining Software Repositories (MSR ’22) . Association for Computing Machinery, New Y ork, NY, USA, 1–5. doi:10.1145/3524842.3528470 [45] pandas Contributors. 2026. Automated Contributions Policy . GitHub repositor y le. https://github.com/pandas- dev/pandas/blob/main/doc/source/developmen t/contributing.rst#automated- contributions- p olicy Accessed: 2026-03-26. [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] [47] Python Developers. 2026. Generative AI. Python Developer’s Guide. ht tp s: //devguide.python.org/getting- started/generative- ai/ Accessed: 2026-03-26. [48] Py T orch Contributors. 2026. AI- Assisted Development. GitHub repository le. ht t p s : // g i t hu b . c o m/ p y t or c h / p yt o r c h/ b l o b /m a i n /C O N T R IB U T I NG . m d # ai - assisted- development Accessed: 2026-03-26. [49] QEMU Contributors. 2026. Code Provenance: Use of AI-generated content. QEMU Documentation. https://github.com/qemu/qemu/blob/master/do cs/deve l/code- provenance.rst Accessed: 2026-03-26. [50] Rapid7 Metasploit Contributors. 2026. Contributing to Metasploit Framework: Vibecoding, AI, and LLM. GitHub repository le. https://github.com/rapid7/me tasploit- framework/blob/master/CON TRIBUTING.md Accessed: 2026-03-26. [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. [52] Spec Kit Contributors. 2026. AI Contributions in Spec Kit. GitHub repositor y le. htt ps://gi thub.co m/githu b/spec - k it/blob /main/C ON TRIBU TING.md #ai- contributions- in- spec- kit Accessed: 2026-03-26. [53] Igor Steinmacher , Marco Aurélio Graciotto Silva, Marco A uré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 T echnology 59 (2015), 67–85. doi:10.1016/j.infsof .2014.11.001 [54] Daniel Stenberg. 2026. The end of the curl bug-b ounty . daniel.haxx.se blog. ht t p s: / /d a n ie l . ha x x .s e / bl o g/ 2 0 26 / 0 1/ 2 6 /t he - e n d - of - th e - c u rl - b u g- b o un t y / Accessed: 2026-03-26. [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 Engine ering and Metho dology 33, 5 (2024), 117:1–117:28. doi:10.1145/36 43673 [56] tldraw Contributors. 2026. Contributions policy . GitHub Issue. https://github.c om/tldraw/tldraw/issues/7695 Accessed: 2026-03-26. [57] typescript-eslint Contributors. 2026. AI Contribution Policy . GitHub repositor y le. https://github.com/typescript- eslint/typescript- eslint/blob/main/do cs/cont ributing/AI_Contribution_Policy .mdx Accessed: 2026-03-26. [58] typescript-eslint Contributors. 2026. Docs: Establish and document expe ctations around use of AI in contributions. GitHub Issue. https://github.com/typescript- eslint/typescript- eslint/issues/11416 Accessed: 2026-03-26. [59] Xingyao W ang, Boxuan Li, Y ufan Song, Frank F. Xu, Xiangru T ang, Mingchen Zhuge, Jiayi Pan, Y ueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Y anjun Shao, Niklas Muennigho, Yizhe Zhang, Binyuan Hui, Junyang Lin, et al . 2025. OpenHands: an op en platform for AI software developers as generalist agents. In The Thirteenth International Conference on Learning Representations (ICLR 2025) . Op enReview .net, Singapore, 38 pages. https://openreview.net/f orum?id=OJd3ayDDoF [60] Mairieli W essel, Joseph V argovich, Marco A Gerosa, and Christoph T reude. 2023. GitHub Actions: the impact on the pull request process. Empirical Software Engineering 28 (2023), 131. doi:10.1007/s10664- 023- 10369- w [61] Jiaqi Wu, Lingfeng Bao, Xiaohu Y ang, 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 W enhao Y ang, Runzhi He, and Minghui Zhou (MSR ’24) . Association for Computing Machinery , New Y ork, N Y, USA, 595–606. doi:10.1145/3643991.3644900 [62] T ao Xiao, Y oumei Fan, Fabio Calefato, Christoph Treude, Raula Gaikovina Kula, Hideaki Hata, and Sebastian Baltes. 2025. Self-admitte d GenAI usage in open- source software. arXiv preprint arXiv:2507.10422. doi:10.48550/arXiv.2507.1042 2 [cs.SE] [63] Jialiang Xie, Minghui Zhou, and Audris Mockus. 2013. Impact of triage: a study of Mozilla and Gnome. In 2013 ACM / IEEE International Symposium on Empirical Software Engine ering and Measurement, ESEM ’13 . IEEE, Los Alamitos, CA, USA, 1–10. doi:10.1109/ESEM.2013.62 [64] W eiwei Xu, Kai Gao, Hao He, and Minghui Zhou. 2025. LiCoEval: evaluating LLMs on license compliance in co de generation. In 2025 IEEE/A CM 47th In- ternational Conference on Software Engineering . IEEE, Los Alamitos, CA, USA, 1665–1677. doi:10.1109/ICSE55347.2025.00052 [65] John Y ang, Carlos E. Jimenez, Alexander W ettig, Kilian Lieret, Shunyu Yao , Karthik Narasimhan, and Or Press. 2024. SWE-agent: agent-computer inter- faces enable automated software engineering. In Advances in Neural Information Processing Systems , V ol. 37. Curran Associates, Inc., Red Hook, N Y, USA, 50528– 50652. doi:10.52202/079017- 1601 [66] Haruhiko Y oshioka, T akahiro Monno, Haruka T okumasu, Taiki W akamatsu, Y uki Ota, Nimmi Rashinika W eeraddana, and Kenichi Matsumoto . 2026. Let’s make every pull request meaningful: an empirical analysis of developer and agentic pull requests. In Proceedings of the 23rd International Conference on Mining Software Repositories (MSR ’26) . Association for Computing Machiner y , New Y ork, NY , USA, 1–5. ht tp s: / /a rx iv.or g/ a bs /2 60 1. 18 749 A ccepte d at MSR 2026 Mining Challenge; preprint available at arXiv . Accessed: 2026-03-26. [67] Quanjun Zhang, Chunrong Fang, Y ang Xie, Y axin Zhang, Y un Y ang, W eisong Sun, Shengcheng Y u, and Zhenyu Chen. 2026. A survey on large language models for software engineering. Science China Information Sciences 69, 4 (2026), 141102. doi:10.1007/s11432- 025- 4670- 0 [68] Songwen Zhao et al . 2025. Is vibe co ding safe? Benchmarking vulnerability of agent-generated code in real-world tasks. arXiv preprint doi:10.48550/arXiv.2512.03262 [cs.CR] [69] Minghui Zhou, Qingying Chen, A udris Mockus, and Fengguang Wu. 2017. On the scalability of Linux kernel maintainers’ work. In Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2017 . Association for Computing Machinery , New Y ork, N Y , USA, 27–37. doi:10.1145/3106237.3106287 [70] Shurui Zhou, Bogdan V asilescu, and Christian Kästner . 2019. What the fork: a study of inecient and ecient forking practices in so cial coding. In Proceedings of the 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE) . Association for Computing Machinery , New Y ork, N Y , USA, 350–361. doi:10.1145/3338906. 3338918 [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. [72] Zig Contributors. 2025. Migrating from GitHub to Codeberg. Zig News. https: //ziglang.org/news/migrating- from- github- to- codeberg/ Accessed: 2026-03-26.