You can contribute if you... An Empirical Framework of AI Contribution Policies in OSS

I. INTRODUCTION

• AI lowers contribution-production costs, increasing submission volume and weakening signals of contributor effort and commitment.Before widespread AI use, the investment involved in producing contributions acted as a filter, and submission itself could signal effort.Source: §I · p. 1
• Projects must balance AI’s potential benefits for contributors and maintainers against concerns about accountability, maintainability, and community formation.AI can help contributors understand code and prepare submissions, and help maintainers triage and evaluate them.Source: §I · p. 1
• Prior work found that only 118 of 1,000 highly active GitHub repositories had AI contribution policies, many of which remained vague.That study examined permission, disclosure, and human-in-the-loop requirements; this paper focuses on the governance rationales encoded in policies.Source: §I · p. 1
• The study asks how OSS projects adapt policies for AI-mediated contributions and what governance dimensions emerge from those policies.It analyzes project rules and expectations, then derives the AI Contribution Governance Framework to organize the concerns they address.Source: §I · pp. 1–2
• The paper contributes an empirical analysis of project rationales and a framework intended to explain existing policies and guide projects creating or revising them.The framework is presented as a tool for projects addressing AI use in their communities.Source: §I · p. 2

II. RELATED WORK

• OSS projects balance community growth and contributor retention against the limited maintainer time needed to evaluate, integrate, and support contributions.Prior work links project survival challenges to maintainer overload, insufficient retention, and loss of project knowledge –.Source: §II · p. 2
• Prior studies examine newcomers’ technical and social barriers, onboarding and mentoring, and the differing motivations and trajectories of peripheral contributors, –.Good first issue labels and mentoring programs are examples of mechanisms and settings studied in this literature –.Source: §II · p. 2
• Research treats OSS participation as governed through documented rules and norms, including codes of conduct, within communities whose members contribute for varied reasons [3], [4], –.Those motivations include ideology, learning, reputation, employment, reciprocity, and commitment to a cause.Source: §II · p. 2
• AI software-engineering research reports short-term velocity alongside quality risks, engineering pitfalls, capable agents, and observable agent-assisted pull requests [9]–.Other work suggests AI-agent adoption may reshape human and newcomer activity while increasing review needs.Source: §II · p. 2
• Closest prior work studied project stances, disclosure, and human-in-the-loop requirements for generative AI contributions; this study examines the rationales behind policies.The study also includes the dataset from that prior work and examines policies as responses to OSS capacity, signaling, onboarding, and community-management concerns.Source: §II · pp. 2–3

III. METHODOLOGY

• The methodology combines a positivist analysis of published policy artifacts with a naturalistic synthesis of governance principles.The two approaches are framed through legal positivism and natural law, respectively.Source: §III · p. 3
• For RQ1, the researchers manually analyzed twelve projects to develop a template, then used it with an LLM to analyze policies across the project set.The criteria included stance and policy characteristics such as disclosure, scope, and human responsibility; the LLM output was treated as preliminary and manually verified in every case.Source: §III · pp. 3–4, Table I · p. 3
• The study prioritizes a diverse account of community concerns over a representative estimate of how common policy positions are.The reasons documented during project categorization were later synthesized to capture varied perspectives on AI-mediated contributions.Source: §III · p. 4
• For RQ2, the authors used RQ1 findings as evidence of practical governance concerns, then extended their interpretation through discussion of AI’s effects on OSS collaboration.They considered restrictions, conditions, exemptions, and procedural mechanisms, focusing on recurring concerns rather than judging individual policies.Source: §III · p. 4
• The authors iteratively translated concerns into acceptability principles, compared them with observed rationales and mechanisms, and refined the framework through discussion.They aimed for a formative framework that could include principles needed to explain governance relations even when those principles were not observed in the policies.Source: §III · p. 4

IV. DATASETS

• The Hora and Robbes dataset identified 118 AI policies among 1,000 highly starred GitHub repositories, while the MelissaWM list contains 106 projects.The first source is from the replication package of Hora and Robbes; the second is a community-curated list focused on AI contribution policies.Source: §IV · pp. 4–5
• The unified dataset contains 209 unique projects, with 15 projects shared by the two sources.The sources are a repository-based dataset and a community-curated list of contribution policies.Source: §IV · pp. 4–5
• The HR dataset skews toward policies allowing AI (69%), while the MelissaWM dataset includes a 36% share that prohibits AI use.The authors assume the combined corpus maintains a diverse representation of policy approaches.Source: §IV · p. 5, Figure 1 · p. 5

• The study classifies current contribution policies addressing AI-mediated development in OSS.Source: §V · p. 5
• RQ1.1 examines why projects prohibit, regulate, or allow AI-mediated contributions.Source: §V · p. 5
• RQ1.2 examines whether policies differentiate by contributor tenure or submission type, including bug fixes versus new features.Source: §V · p. 5

• Maintainer burden was the dominant rationale, cited by 34 projects (81%), with AI-mediated submissions described as consuming reviewer time without adding value.Source: 1) Reasons by projects prohibiting AI · p. 5
• Code quality and correctness ranked second, cited by 33 projects (79%), with concerns that subtly wrong code can evade superficial review.Source: 1) Reasons by projects prohibiting AI · p. 5
• Copyright, IP, and licensing uncertainty was cited by 24 projects (57%), while 15 projects (36%) cited DCO or authorship-certification requirements.Projects with DCO requirements may reject AI-generated contributions lacking proper sign-off.Source: 1) Reasons by projects prohibiting AI · pp. 5–6
• Community trust and culture (15 projects, 36%) and contributor learning and development (14 projects, 34%) were also reasons for prohibiting AI.The concerns center on human technical dialogue and contribution as a pathway to expertise and future project responsibility.Source: 1) Reasons by projects prohibiting AI · p. 6
• Ethics, including labor exploitation, consent, and environmental harms, was cited by 8 projects (19%), while security was cited by 3 (7%).Security concerns were especially salient for security-critical projects, which considered the risk unacceptable regardless of code quality.Source: 1) Reasons by projects prohibiting AI · p. 6

• All 34 projects regulating AI cited code quality or correctness and contributor understanding, making understanding the key condition distinguishing regulation from prohibition.AI use is tolerated when contributors can explain, defend, and take ownership of its output.Source: 2) Reasons by projects regulating AI · p. 6
• Maintainer burden and review cost appeared in 30 projects (88%), reflecting the asymmetry between cheaper production of plausible pull requests and maintainer evaluation and integration costs.Policies also question whether the contributor understands the change and whether it merits review effort.Source: 2) Reasons by projects regulating AI · pp. 6–7
• Human interaction and community dialogue was a concern in 14 projects (41%), with some policies requiring contributors to write direct communications themselves.Source: 2) Reasons by projects regulating AI · p. 7
• Contributor learning and development was explicit in 12 projects, including restrictions on using AI for good-first issues intended as learning opportunities.Source: 2) Reasons by projects regulating AI · p. 7
• Copyright and IP concerns appeared in 9 projects (26%), generally framed as contributor responsibility for submitted material rather than grounds for an outright ban.Source: 2) Reasons by projects regulating AI · p. 7

3) Reasons by projects allowing AI:

• Projects permitting AI provide no rationale for that stance; where they specify procedures, they emphasize disclosure, testing, understanding, and human-to-human interaction.Source: 3) Reasons by projects allowing AI · p. 7

A. Are Contributions treated Equally?

• The study examines whether policies differentiate by contributor history and reputation or by whether a pull request fixes a critical bug or adds a feature.Source: A. Are Contributions treated Equally? · p. 7

1) New vs. regular contributors:

• Only 17 projects (8%) explicitly distinguish new from regular contributors; mechanisms include trusted-contributor exemptions, accepted-issue gates, protected good-first issues, stricter mentorship rules, and implicit trust.Zig explains newcomer-specific concerns even though its ban is universal: first-PR review invests in a possible future contributor, while AI weakens that signal.Source: 1) New vs. regular contributors · p. 7

2) Bug fix vs. new feature:

• Among 209 projects, DuckDB alone explicitly distinguishes bug fixes from features, while several projects permit disclosed AI code but prohibit AI-written issue descriptions.The distinction reflects bug fixes’ verifiable ground truth versus the design judgment required for features; acceptance remains at maintainer discretion.Source: 2) Bug fix vs. new feature · p. 7

VI. RESULTS: RQ2 WHAT GOVERNANCE DIMENSIONS EMERGE FROM THESE POLICIES, AND HOW CAN THEY BE ORGANIZED?

• AI increases submission volume and weakens effort as a signal, making review a capacity-constrained allocation problem under uncertainty.Maintainers weigh whether reviewing a contribution is worth the upfront effort and triage it accordingly.Source: §VI · p. 8
• The framework organizes concerns about AI-mediated participation and review as a naturalistic, rather than prescriptive, account of governance.Review effort may return value through integrating contributions, protecting project stewardship, or developing participants into long-term contributors or maintainers.Source: §VI · p. 8
• Policies should protect maintainer attention, preserve mentoring pathways, and distinguish contribution types, while balancing access against review capacity.Aggressive filtering may discourage future contributors; remaining too open may exhaust review capacity.Source: §VI · p. 8
• AI-use disclosure supports transparency but does not establish contributor ownership of AI-mediated work.Projects may need stronger evidence to determine whether contributors own the work or leave evaluation, explanation, and integration to maintainers.Source: §VI · p. 8
• Projects can use AI for triage, summarization, testing, or analysis, but human stewards must retain acceptance, rejection, and maintenance decisions.Source: §VI · p. 8
• Acceptability principles specify role-specific conditions for AI use, organized around the project, contributor, and maintainer, and vary with each project’s stewardship priorities.The project sets contribution boundaries, contributors remain responsible for their work, and maintainers retain review and incorporation decisions.Source: §VI · p. 8

VII. DISCUSSION

• 42 projects prohibit AI: 18 cite code quality, 16 legal uncertainty around copyright, and 8 ethical principles.Quality concerns center on avoiding maintenance burdens; ethical concerns include AI’s impacts on society and nature.Source: §VII · pp. 8–9
• Some projects may revisit bans if AI output improves, reliability evidence strengthens, or legal uncertainty clears; ethically motivated projects may be less swayed by technology improvements alone.Source: §VII · p. 9
• Prohibited policies reject AI-mediated contributions categorically; regulated policies allow them conditionally when contributors demonstrate understanding and responsibility.Source: §VII · p. 9

A. Implications for researchers

• The study cannot determine whether projects without AI-adapted policies are managing AI informally, considering policy changes, or do not yet see AI as salient.Further research is needed to distinguish these possibilities.Source: A. Implications for researchers · p. 10

B. Implication for practitioners

• The framework helps communities identify context-specific AI pressures, connect them to protected values, and translate them into concrete policy mechanisms and practices.It is a policy-design aid, not a prescription for one policy.Source: B. Implication for practitioners · p. 10

VIII. THREATS TO VALIDITY

• Informal documentation and sparse policy texts made intent difficult to interpret, although the authors manually verified findings and triangulated them against prior classifications.Discrepancies led to project reclassification and refinement of rationales.Source: §VIII · p. 10
• The source collections do not support statistical generalization to all OSS projects, so findings identify observed governance issues rather than their prevalence across OSS.The sources combine policies from highly starred projects with a hand-curated collection.Source: §VIII · p. 10
• Framework construction requires a conceptual step beyond explicit policy wording, so the authors distinguish observed mechanisms from inferred governance issues and present the framework as revisable.The framework may otherwise remain too close to policy features or become insufficiently grounded in observed responses.Source: §VIII · p. 10

IX. CONCLUSIONS

• Project software attracts contributors, while community values in turn influence how that software evolves.The paper describes this as a feedback loop.Source: §IX · p. 10
• OSS communities regulate AI-mediated contributions in varied ways, including restrictions and outright bans, with pragmatic and philosophical rationales reflecting project heterogeneity.Projects differ in purpose, constraints, and the communities they form.Source: §IX · p. 10
• As AI lowers submission costs and weakens effort signals, policies should protect scarce evaluation capacity and require stronger evidence of project fit and human accountability.The stated purpose is to keep review worthwhile for the codebase and its contributor and maintainer community.Source: §IX · p. 10
• The framework helps communities connect context-specific AI pressures to protected values and concrete policy mechanisms without prescribing a single policy position.Source: §IX · p. 11
• The central challenge is adapting as AI reshapes contribution without losing the conditions that allow OSS projects and communities to thrive.Source: §IX · p. 11