arXiv:2609.07919v1 [cs.SE] 7 Sep 2026
You can contribute if you... An Empirical Framework of AI Contribution Policies in OSS Gregorio Robles
Daniel German
Universidad Rey Juan Carlos Madrid, Spain [email protected]
Department of Computer Science University of Victoria Victoria, BC, Canada [email protected]
Abstract—Artificial intelligence is reshaping open source software (OSS) contribution by lowering the cost of producing code, documentation, issue reports, and review interactions. This creates opportunities for broader participation, but also disrupts how maintainers assess contributor effort, competence, and accountability. In response, OSS projects are beginning to regulate AI-mediated contribution through contribution guidelines and other project documentation. This paper presents an empirical study of these emerging policies. We analyze project policies on AI-mediated contributions by evaluating their underlying rationales, rules, and expectations. Our analysis shows that these policies seek to protect scarce maintainer attention, preserve accountability, sustain meaningful review interactions, address legal and quality concerns, and maintain pathways for newcomer learning. Based on these findings, we introduce the AI Contribution Governance Framework, which organizes recurring concerns and governance mechanisms across projects. The framework helps OSS communities develop AI contribution policies and provides researchers with a vocabulary for studying how AI is changing collaborative software production. Index Terms—open source, artificial intelligence, software engineering
I. I NTRODUCTION Open Source Software (OSS) is commonly developed through public repositories in which people outside the maintainer group can propose and submit changes to a project. This form of participation allows projects to receive bug fixes, new functionality, documentation improvements, and other forms of work from a broad community of users and developers. Maintainers remain responsible for deciding which proposed changes become part of the project, which require revision, and which are rejected. Contribution policies support these decisions by stating how contributions should be submitted, what kinds of participation are acceptable, and what responsibilities contributors accept when they submit work [1]–[4]. As described in [5], generative AI is changing OSS development. We use the term AI-mediated contribution to refer to contributions whose production, explanation, revision, review, or evaluation is materially shaped by generative or agentic AI systems. Before widespread use of AI-mediated development, creating a contribution usually required an investment in time, effort, and project-specific engagement that many attempts never became submissions. This acted as a filter that reduced their volume and made submission itself evidence that the contributor had invested enough effort to make the contribu-
tion worth reviewing, and that, even if the contribution was weak, nurturing the contributor might be a good long-term investment [6]. The use of AI lowers the cost of producing contributions, increasing their volume, and weakens the signals that allowed maintainers to distinguish promising newcomers from low-commitment contributors. Maintainers must assess whether the proposed contribution is correct, useful, maintainable, and worth carrying forward as part of the project (including whether and how AI was used). Review is already shaped by limited maintainer attention, contributor reputation, and the costs of evaluating work from peripheral or unfamiliar contributors [2], [7], [8]. Recent empirical work shows that pull requests created with the help of AI are already observable at substantial scale in GitHub repositories [9], while studies of AI coding tools identify risks involving quality assurance, code complexity, and tool failure modes [10]–[12]. While the use of AI can have harmful consequences for project quality and maintainer workload, it can also benefit OSS. It can help contributors understand unfamiliar code, express ideas more clearly, and prepare submissions that would otherwise be difficult or time consuming for them to produce; and it can help maintainers in the triage and evaluation of submissions. This is already being observed [9]. The governance problem for OSS projects is therefore how projects can preserve accountability, maintainability, and community formation while allowing useful forms of AI mediation. As AI-mediated contribution makes external work harder to evaluate and incorporate, projects are beginning to update their contribution policies in different ways. Recent empirical work [13] measured this emerging policy landscape, showing that many AI contribution policies address permission, disclosure, and human-in-the-loop requirements. Furthermore, the mentioned study demonstrates that while the topic is widely debated nowadays within the OSS community, project positioning regarding AI-mediated contributions is still nascent. This is evidenced by the fact that only 118 of the 1,000 most active GitHub repositories that were studied have established some policy on this issue, many of which remain notably vague. We build on this line of work by analyzing the governance rationales encoded in these policies. This paper presents an empirical study of OSS project policies related to AI-mediated contributions. It is guided by
the following two research questions: • RQ1: How are OSS projects adapting their contribution policies to govern AI-mediated contributions? • RQ2: What governance dimensions emerge from these policies, and how can they be organized? RQ1 maps the emerging OSS policy landscape by examining the rules and expectations that projects introduce for AImediated contribution. RQ2 builds on this analysis to derive an AI Contribution Governance Framework that organizes the main concerns projects address when adapting contribution policy to AI. This paper makes two primary contributions. First, it provides an empirical analysis of how open-source software (OSS) projects manage AI-mediated contributions, categorizing the various rationales behind these policies. Second, it introduces the AI Contribution Governance Framework as a tool for explaining existing policies and for guiding projects that are creating or revising policies to address AI use in their own communities. II. R ELATED W ORK OSS contribution is shaped by a persistent tension between community growth and maintainer capacity. Projects depend on new contributors to sustain the community, replace lost knowledge, and develop future maintainers, but each contribution also requires maintainers to evaluate, integrate, and support work under limited time and attention. Prior work has shown that OSS projects fail, become abandoned, or struggle to survive for reasons that include maintainer overload, insufficient contributor retention, and loss of project knowledge [14]– [17]. Even successful projects operate under constraints: need for heterogeneous contributors, uneven support processes, and ongoing coordination challenges [7], while pull requests may be abandoned when contributors and maintainers fail to converge on a review outcome [18]. Retaining contributors and sustaining participation require active governance work, not merely technical infrastructure [19]. Studies of GitHub pull requests show that both social and technical factors shape contribution evaluation [20]–[22], and code review outcomes are influenced by developer reputation [2], trust and security expectations [23], and the social structure of OSS communities [1] and the reviewing process enhances knowledge sharing [24]. Other work has examined how core developers can be identified through observable project activity [25] and how social interactions shape developer initiation in OSS foundations [26]. A related body of work examines newcomers, mentoring, and peripheral participation. Newcomers face both technical and social barriers when making their first contributions [6], [27], [28], and projects have developed mechanisms to help them select appropriate tasks and overcome entry barriers [29], [30]. “Good first issue” labels are one such mechanism: they identify tasks that are suitable for onboarding and learning [31]. Mentoring programs such as Google Summer of Code show challenges of onboarding new contributors [32]–[35].
Studies of one-time, casual, episodic, and peripheral contributors show that OSS projects depend on multiple contributor types whose motivations and future trajectories differ [36]– [42]. Recent work further examines how first contributions can lead, or fail to lead, to longer-term contributors [43]. OSS communities govern participation through documented rules and norms. Prior research has studied the evolution of OSS governance practices [44], the adoption and effects of codes of conduct [45]–[47], and the ways codes of conduct change community engagement over time [48]. Research has shown that projects use these documents to communicate procedures, expectations, and norms for participation [3], [4]. Contributors may be driven by ideology, learning, reputation, employment, reciprocity, or commitment to a cause [49]–[54]. OSS communities govern participation through explicit documents, rules, and norms. Research has studied the evolution of OSS governance practices [44], the adoption and effects of codes of conduct [45]–[47], and the ways codes of conduct change community engagement over time [48]. At the same time, governance operates within communities whose members contribute for varied reasons, including ideology, learning, reputation, employment, reciprocity, and commitment to a cause [49]–[54]. Recent work has begun to examine generative AI and software engineering more directly. AI coding tools can increase short-term development velocity while introducing longer-term quality costs [10], and AI coding systems exhibit recurring engineering pitfalls [11]. At the same time, AI agents are becoming increasingly capable participants in software engineering workflows [12], and agent-authored or agentassisted pull requests are now observable on GitHub [9]. Recent empirical work on AI coding-agent adoption further suggests that these tools may reshape OSS participation by changing the relative share of human and newcomer activity while increasing the need and depth for review [55]. OSS foundations also frame AI-mediated contribution as a governance problem for open, peer-produced software communities. Linux Foundation Research identifies maintainer capacity as a central constraint in OSS, emphasizing that project growth must remain aligned with the coordination, review, and community-management work maintainers can sustain [56], [57]. Its generative AI guidance connects these concerns to disclosure, provenance, licensing, and human responsibility [58]. Mozilla and Wikimedia extend this framing to publicinterest and volunteer peer-production contexts, emphasizing accountable AI systems, human judgment, community oversight, transparency, and monitoring [59]–[62]. Fent et al. [5] describe how generative AI is disrupting OSS emphasizing how OSS communities should discuss and address the different aspects of this disruption. Closest to our work, Hora and Robbes studied how OSS contribution guidelines address generative AI, focusing on project stances toward AI-generated contributions, disclosure requirements, and human-in-the-loop responsibility [13]. They show how OSS projects specify rules for generative AI use in contribution processes. Our study builds directly on this line of work by
including their dataset in our analysis of AI contribution policies and by examining AI contribution policies as emerging governance responses to the capacity, signaling, onboarding, and community-management problems that already structure OSS participation III. M ETHODOLOGY To investigate how OSS projects are addressing the review of AI-mediated contributions, we have followed a dual approach inspired by the two main schools of thought in the philosophy of law: legal positivism and natural law (iusnaturalism). Legal positivism contends that law is an exclusively human and social creation, establishing a strict separation between law and morality. According to this current, the validity of a law does not depend on its level of justice or its alignment with universal ethical values, but solely and exclusively on its enactment by the competent authority following the formal procedures established by the State. In other words, a law is valid and must be complied with simply because it has been issued by the official legislator, regardless of whether its content is morally good or bad. On the other hand, natural law theory (or iusnaturalism) maintains that there are universal, immutable moral principles and standards of justice inherent to human nature that are prior and superior to any written regulation. From this perspective, law enacted by individuals or States is only truly valid, legitimate, and binding if it respects and aligns with these fundamental ethical values. In short, for a natural law theorist, a law that is profoundly unjust loses its moral essence and is not considered true law. This research is grounded in two research questions, one for each philosophical stance: • RQ1: How are OSS projects adapting their contribution policies to govern AI-mediated contributions? The goal of this research question is to identify the main concerns that OSS projects have and organize them into themes. • RQ2: What governance dimensions emerge from these policies, and how can they be organized? We aim to create a framework that is derived from the basic tenants surrounding participation in OSS that is capable of capturing and organizing the concerns found in RQ1. This framework should result in a set of principles that OSS projects should use to ground the discussion and enactment of policies regarding AI-mediated contributions by its members. RQ1 was conducted on the contribution guidelines that open-source software projects publish on their websites and repositories, specifically regarding how to collaborate using AI. This represents the positivist dimension, which methodologically relies on an empirical analysis of artifacts within software repositories. The following steps were taken to analyze the existing rules in OSS projects. First, lists of projects that have published such rules were identified, and the webpage with the policy regarding AI-mediated contributions downloaded. We found two sources: (i) an existing list of policies by OSS projects
about how to engage with AI-generated contributions, and (ii) a replication package from a pre-print short paper [13] that identified projects with such policies (their work focused on the categorization of projects into AI is welcomed, permitted and discouraged, and what requirements for disclosure they impose on contributors). Next, we attempted to identify the stance (permitted, regulated, prohibited) of the AI project and other regulations included in these guidelines, determining various types of characteristics. These additional characteristics included in the analysis (such as disclosure requirements, the scope, human responsibility) serve to clarify the rationale behind each project’s stance and may offer a more comprehensive view of the landscape. This process was performed manually for twelve randomly selected projects until saturation was reached, as no additional characteristics were found. This allowed us to construct an analysis template. This analysis template (shown in Table I) was then transformed into a prompt that was passed for every project, together with the webpage with the policy, to Claude Code (using Opus 4.7). The prompt that has been used is as follows “I am trying to analyze AI policies for following OSS projects. Inspect the content of the files with information on how to contribute and create a table based on following criteria:”, together with the analysis template. TABLE I AI P OLICY A NALYSIS C RITERIA .
Category
Possible Values / Options
permitted |regulated |prohibited |unclear yes |no |recommended |unclear explicit |implicit |absent everything |code |docs |tests |trans. |issues |props. Quality/testing yes |no Learning/understanding yes |no Security/legal yes |no Authorship/IP yes |no Sustainability yes |no Enforcement rejection |label |review |warning |none |ban Target actor contributor |maintainer |bot |student |org. Human interactions explicit |implicit |absent Overall stance Disclosure req. Human resp. Scope
In addition, at the end of the prompt, we added the following question “Are there other elements that are worth mentioning?”, in case there are other elements in the webpage worth noting. The results were grouped in a single list. Table II offers an excerpt (i.e., the first 6 analyzed projects; the full list is available in the reproduction package). To ensure the consistency of our findings, we compared the LLM-generated results with our manual analysis across the 12 selected repositories. While the LLM’s output closely aligned with our manual assessments, we identified some discrepancies, particularly regarding project categorization. As a result, we treated the LLM’s output as a preliminary baseline and conducted a comprehensive manual verification of every case. When ambiguity arose,
TABLE II S AMPLE OF CODED AI CONTRIBUTION POLICIES ( SIX EXAMPLE PROJECTS FROM THE UNIFIED DATASET; FULL LIST IN THE REPRODUCTION PACKAGE ). S TANCE : P ERM . = P ERMITTED , R EGU . = R EGULATED , P ROH . = P ROHIBITED . DATASET : HR = MERGED DATASET 1+2 ( DEDICATED POLICY FILES / CONTRIBUTING FILES ), MW = MELISSAWM CURATED LIST. D ISCLOSURE : Y = Y ES , N = N O , R = R ECOMMENDED . H UMAN R ESP. ( HUMAN RESPONSIBILITY ) AND H↔H ( HUMAN – HUMAN INTERACTION ): E = E XPLICIT, I = I MPLICIT, A = A BSENT. Q UALITY , L EARNING , S ECURITY , IP, C OMMUNITY ( SUSTAINABILITY MENTIONED ): Y = Y ES , N = N O . E NFORCEMENT : R EJ . = R EJECTION , BAN = P ERMANENT BAN , WARN = WARNING , E XT R = E XTRA REVIEW, N ONE = N O MECHANISM STATED . S COPE ABBREVIATIONS : C = C ODE , D = D OCS , T = T ESTS , I = I SSUES , T R = T RANSLATIONS , P = P ROPOSALS , A LL = E VERYTHING .
Project
Dataset
Stance
Disc.
Hum.Resp.
Scope
Qual.
Learn.
Sec.
IP
Comm.
Enforce.
H↔H
9001/copyparty
HR
Proh.
N
E
C, D, I
Y
Y
N
N
Y
Rej.
E
actualbudget/actual
HR
Perm.
R
E
C, I, D
Y
Y
N
N
Y
Rej., Ban
E
Adwaita
MW
Proh.
N
E
C, D
N
N
N
N
Y
Rej.
E
agno-agi/agno
HR
Perm.
N
I
All
N
N
N
N
N
None
A
anomalyco/opencode
HR
Perm.
N
I
All
N
N
N
N
N
None
A
anuken/mindustry
HR
Regu.
N
E
C
Y
Y
N
N
Y
Rej.
I
typically due to a lack of explicit policy information—we triangulated our findings with the perspectives of the original dataset authors, who also classify projects based on AI usage (though strictly on a binary ”Yes/No” basis). Our study focuses primarily on understanding the specific concerns of OSS communities and the methods they use to address them. The primary value of our study lies in the classification of concerns and the accompanying rationale, rather than in how many projects fall into each group. We do not aim to have a representative dataset of the most popular stances within the OSS community; rather, our objective is to curate a rich and diverse dataset that captures the full spectrum of existing viewpoints, including the ones that are currently in the minority. Consequently, as we categorized the projects, we documented the specific reasons provided for their positions; these were later synthesized to better understand the various perspectives surrounding policies on AI-mediated contributions. To answer RQ2, we performed an empirically grounded conceptual synthesis of the RQ1 results. We started by theorizing about the core principles of open-source collaboration and how AI affects them—without considering the existing rules in specific projects. Our starting point was the many papers that describe OSS collaboration before and after AI (see Section II). The dataset and the results of RQ1 became a solid foundation for our analysis. We treated these policies and the results of RQ1 as evidence of the practical governance concerns that projects are attempting to manage when regulating AI-mediated contributions. Specifically, we examined how projects rationalize their policy choices and how they implement those choices through restrictions, conditions, exemptions, and procedural mechanisms. Our focus was on identifying recurring concerns, rather than evaluating the correctness of individual policies. We then expanded this interpretation through a discussion among the authors, identifying gaps not seen in the policies, and ourselves asking how AI-mediated contribution changes
the different facets of the OSS collaboration and under what conditions those changes become governance concerns. This step allowed us to move from project-specific rationales to more general concerns about roles, resources, signals, costs, and responsibilities in AI-mediated contribution. Finally, we used the identified concerns as the basis for developing principles for acceptable AI-mediated contribution. This was an iterative synthesis process. We first translated recurring concerns into candidate acceptability conditions, then compared those conditions across the policy rationales and mechanisms identified in RQ1. Because our approach is naturalistic, we also considered the contribution process holistically, asking whether the candidate principles captured the roles, dependencies, and obligations that make OSS contribution and review possible, even if there not observed in policies under study. Through discussion among the authors, we refined the candidate principles by merging overlapping ideas, separating concerns that addressed different governance problems, and checking that each principle was either traceable to the empirical material or necessary to explain the governance relations revealed by it. We also revised the organization of the principles to make the resulting framework coherent. A major design requirement was that the framework remain formative rather than prescriptive. IV. DATASETS We have selected two distinct data sources to gain a more comprehensive understanding of our research topic, as they are inherently complementary. The HR dataset is derived from the replication package of recent work by Hora and Robbes [13]. They analyzed the 1,000 most-starred GitHub repositories that met specific criteria: a minimum of 100 commits, non-fork status, and at least one commit in 2026. Through this analysis, they identified 118 AI policies for AI-mediated contributions. The MelissaWM dataset of Contribution Policies comes from the melissawm/open-source-ai-contribution-policies
Fig. 2. Reasons in projects prohibiting AI-mediated contributions.
Fig. 1. General overview of the number of projects (and their position towards AI-mediated contributions) in the datasets used in this study.
GitHub repository [63], a community-curated list of 106 projects. This list is curated specifically around the discussion of how projects manage AI-mediated contributions and adapt their contribution policies accordingly and comes with a rich ideological and rationale diversity, including a list of projects that reject AI-mediated contributions. The datasets have 15 projects in common, resulting in a total of 209 projects. The analysis of the 209 unique projects reveals a clear distinction between the two source datasets as can be seen in Figure 1, with the HR dataset skewing heavily toward AI policies that allow the use of AI (69%) while the MelissaWM dataset exhibits a more restrictive stance, featuring a 36% that prohibit any AI use. We assume that the combined corpus maintains a diverse representation of policy approaches toward AI-mediated content in software development. V. R ESULTS : RQ1 H OW ARE OSS PROJECTS ADAPTING THEIR CONTRIBUTION POLICIES TO GOVERN AI- MEDIATED CONTRIBUTIONS ? To address the governance challenges introduced by AImediated development in OSS, we establish a classification of current contribution policies (RQ1). To this end, we have divided this question into two focused inquiries: a first question (RQ1.1) examines the specific rationales projects provide for prohibiting, regulating, or allowing AI-mediated contributions, while a second question (RQ1.2) investigates whether these contributions are treated equitably. Specifically, the latter addresses whether policies differentiate between contributors based on their tenure (new versus regular), or the nature of the submission (bug fix versus new feature). 1) Reasons by projects prohibiting AI: Figure 2 offers an overview of the reasons found in projects that prohibit AI. The dominant and near-universal rationale is the one we have called Maintainer burden (34 projects, 81%). AI elim-
inates the natural effort-based backpressure that previously limited low-quality submissions—generating large volumes of plausible-looking but broken contributions that consume reviewer time without adding value. Projects citing this reason treat it as an existential threat to sustainability. For example, Ghostty states that “The rise of agentic programming has eliminated the natural effort-based backpressure that previously limited low-effort contributions.” and in Zig we can read “LLM assistance breaks [the relationship between reviewer time and contributor learning] completely. . . the time the Zig team spends reviewing your work does nothing to help them add new, confident, trustworthy contributors.” Code quality & correctness (33 projects, 79%) comes second, arguing that AI-mediated code is frequently subtly wrong: it passes superficial review, fixes symptoms instead of causes, introduces new bugs, and can only be caught through careful line-by-line reading that defeats the purpose. Projects with high quality standards see AI as incompatible with their quality culture, not merely inconvenient. For example Jellyfin states that “Pure ‘vibe coding’ will be rejected. . . If the code looks terrible, it will be rejected as such. You must clean up the mess before submitting.” The third most frequent reason refers to Copyright, IP & licensing uncertainty (24 projects & 57%), as AI models trained on copyrighted code may reproduce verbatim excerpts of license-incompatible material in their output. This is especially dangerous for projects under copyleft licenses (GPL, MPL) or those operating at legal/regulatory risk. The provenance of generated code is fundamentally unknowable, making it impossible for contributors to honestly certify clean IP. For instance in Asahi Linux it can be read “There is ample evidence. . . of this training material including copyrighted material. . . It is not impossible for [LLMs] to have confidential or leaked material owned by Apple or its vendor partners in their training corpora.” The fourth rational is related to DCO / authorship certification (15 projects, 36%), as the Developer Certificate of Origin (DCO) requires contributors to legally certify they have the right to submit the code under the project’s license.
Thus, projects that mandate a DCO cannot accept contributions generated by AI that lack proper sign-off. OpenJDK points this out in their “Interim Policy on Generative AI” stating that contributors “may use generative AI tools privately to help comprehend, debug, and review OpenJDK code.”, meaning by privately that contributors “may use such tools on [their] own, without contributing the content that they generate.” Some projects argue that OSS is a social contract where Community trust & culture (15 projects, 36%) is fundamental. Contributions are a form of communication between humans—reviewer and author need to be able to have a genuine technical dialogue. When a contributor submits AI-mediated code they do not understand, maintainers are effectively reviewing the AI’s output, not engaging with a developer. This is seen as a betrayal of the human relationship at the core of collaborative software. Several projects explicitly frame this as a values issue, not merely a practical one. For instance, SciActive has a “Human Contribution Policy” where it states that “users of the project have an implicit trust that the maintainers of the project understand the code contained within the project’s code base”. The next most frequent reason given is Learning & contributor development (14 projects, 34%). These projects state that OSS contribution is itself a learning process: a pathway through which developers develop expertise, build relationships with maintainers, and eventually become maintainers themselves. AI short-circuits this entirely. Contributors who cannot explain their code cannot grow, cannot respond to feedback, and cannot be trusted with greater responsibility. Several projects frame human learning not just as a side benefit but as the core justification for accepting contributions at all. For instance, XScreenSaver’s maintainer states that “[n]o contributions built with, or mediated by, LLMs or any kind of “generative AI” tools will be considered. If you didn’t bother writing it, I’m not going to bother reading it. XScreenSaver is art by humans for humans.” The most politically explicit objections to AI are grouped under Ethics: labour exploitation, consent & environment (8 projects, 19%). Projects in this category explicitly oppose using AI tools as a matter of ethical and environmental responsibility, independent of the quality or legality of the output. This objection is grounded in several reasons, such as: training data of LLMs is obtained without creator consent; reliance on exploited low-wage annotators; exploitation of the commons, including OSS; and the cost of AI inference and training in terms of vast amounts of quantities of energy, water, and hardware. This category is a political position that makes AI contributions unacceptable regardless of their technical quality. The postmarketOS project exemplifies this concern: “Their models are built in part with heavily exploited workers in unacceptable working conditions, usually without consent from or compensation for creators of the source material.” and “AI tools require an unreasonable amount of energy and water to build and operate. . . These are harms that we do not want to perpetuate, even if only indirectly.” Finally, three projects (7%) specifically cite Security as
Fig. 3. Reasons in projects regulating AI-mediated contributions.
a primary concern, noting that AI-mediated code frequently contains subtle vulnerabilities capable of bypassing superficial review processes. This is especially an objection for the security-critical projects in our study (e.g., operating systems, password managers); the security risk is unacceptable for them regardless of quality. postmarketOS exemplifies this argument: “authors making use of generative AI tools oftentimes increase the maintainer burden and cause further problems by not ensuring the following: [...] Making sure their patches are unlikely to introduce bugs, especially security bugs.” 2) Reasons by projects regulating AI: Figure 3 offers an overview of the reasons found in projects that regulate AI. Code quality/correctness and Contributor understanding required (34 projects, 100%) are rationales present in every project that regulate AI contributions, and the one that distinguishes “regulated” from “prohibited” most clearly. The objection is not to AI tools per se, but to contributors who use them without being able to explain, defend, or take ownership of the output. The framing is consistently about the contributor failing to understand—not about the AI being untrustworthy in the abstract. This makes the bar conditional: AI is tolerated if understanding accompanies it, rejected if it does not. The badlogic/pi-mono project states it as follows: “Using AI to write code is fine; submitting AI-generated slop without understanding it is not. Human must fully understand and be able to explain changes.” The Maintainer burden & review cost reason (30 projects, 88%) is present in nearly all regulated projects, but it is expressed differently than in the prohibited group, with a more pragmatic rather than alarmed tone. Where prohibited projects describe a flood that threatens the project’s survival, regulated projects more often describe a more specific review asymmetry: AI lowers the cost of producing plausible pull requests, while the cost of evaluating, integrating, and maintaining them remains with maintainers. A major concern is that AI-mediated contributions may make it harder to tell whether the contributor understands the change and thus whether the submission is worth the required review effort. FastAPI expresses this concern as follows: “Do not send low-effort
or AI-generated PRs. Accounts may be blocked for repeated violations. Human must understand all submitted code.” A recurring concern in the “regulated” group is the degradation of the Human–human interaction & community dialogue (14 projects, 41%) when AI mediates the communication. When a contributor uses AI to draft the code, the PR description and the responses to review comments, the maintainer is no longer talking to a person but to an AI that is impersonating her. Several policies state that PR descriptions and review responses must be written by the contributor themselves (while AI generated code is acceptable). Jellyfin states that “LLM output is expressly prohibited for any direct communication, including issues or comments, feature requests, pull request bodies or comments, forum/chat posts.”. Several projects that regulate the use of AI express concern that AI bypasses the learning loop, the Contributor learning & development group, which is implicit in most projects but explicit only in 12. Contributors who use AI to generate code they cannot explain are not developing the skills that make future contributions valuable, and they are consuming maintainer time that would otherwise go to genuine mentorship. Learning is framed in the “regulated” group as an important outcome of understanding and getting integrated in a project. The “good first issue” protection seen in LLVM, similarly found in other projects, reserves beginner-friendly issues as genuine learning opportunities, is a direct expression of this concern: “AI tools must not be used to fix GitHub issues labelled good first issue. These issues are generally not urgent, and are intended to be learning opportunities for new contributors to get familiar with the codebase.” In the regulated group Copyright & IP concern is also present (9 projects, 26%), but it is typically expressed as a responsibility placed on the contributor (“you are accountable for the IP status of what you submit”) rather than as a reason to ban AI outright. Projects tend to address copyright implicitly through their disclosure requirements. attrs puts it this way: “Copyright must be owned line-by-line. No LLM bots in Coauthored-by.” 3) Reasons by projects allowing AI: Unlike projects that prohibit or regulate AI-mediated contributions, which typically provide a rationale for their stance, we found no such justification in projects that permit AI usage. These projects focus, if at all, on procedural requirements for contributing, primarily emphasizing disclosure, testing, understanding, and human-tohuman interaction. A. Are Contributions treated Equally? As policies often fluctuate based on a multifaceted set of criteria, we would like to investigate what factors are explicitly mentioned in the guidelines, in particular, (i) the contributor’s established history and reputation within the project, and (ii) the nature of the pull request: whether it addresses critical bug fixes or introduces new features. 1) New vs. regular contributors: Only a small number of projects explicitly distinguish between new and regular contributors (17 projects, 8%), The clearest example can be
found in Zig’s “Contributor Poker” essay1 . Although Zig adopts a universal ban rather than a role-specific rule, it explains why AI-mediated contributions are especially problematic for newcomers: first-PR review is an investment in a possible future contributor. AI-mediated first PRs consume that investment while weakening the signal that would make it worthwhile. Zig is therefore distinctive because it articulates the importance of the new-contributor dimension even though it does not formalize that distinction in its policy. Other projects operationalize the distinction through more specific mechanisms. Five projects, including Ghostty and Polars, allow maintainer exemptions for trusted contributors, which means that the strict rules for AI usage apply only to outside contributions; maintainers are exempt from these rules and may use AI tools at their discretion as they have proven themselves trustworthy to apply good judgment. Six projects, including ESLint and go-delve, use an accepted-issue gate to limit contributions to known or pre-discussed work, with substantial overlap between this category and maintainer exemptions. Six projects, including LLVM and Firefox, protect good-first issues by reserving them for newcomers. Three projects, including CPython and CCExtractor, apply stricter rules to mentorship-programme contributors such as GSoC participants. Finally, four projects, including the Linux Kernel and curl, rely on implicit trust: maintainers acknowledge differentiated expectations in practice, even when these distinctions are not formalized in the official policy. 2) Bug fix vs. new feature: Virtually no policy distinguishes between a bug fix (including addressing an open issue) and a new feature. DuckDB is the sole project in the entire 209 set that draws the line explicitly by name. Its logic, that bug fixes have a verifiable ground truth while features require design judgement, is the most coherent articulation of why contribution type could matter, although the final decision (“may be accepted”) puts it at the maintainer discretion, not as a rule. The most relevant finding is the inversion in the bug report dimension: projects that are permissive about AI-mediated code are often strictest about AI-mediated bug report text. NumPy, SciPy, SymPy, Matplotlib, Jellyfin, searxng, and Zulip all permit disclosed AI code but prohibit AI-written issue descriptions. The reason is that code can have testability gates that separates correct from incorrect; a bug report has no equivalent mechanism. A non-existent bug looks identical to a real report until someone spends time trying to reproduce it, consuming valuable maintainer effort2 . VI. R ESULTS : RQ2 W HAT GOVERNANCE DIMENSIONS EMERGE FROM THESE POLICIES , AND HOW CAN THEY BE ORGANIZED ? The results of RQ1 show a wide variety of stances regarding the use of AI, both in terms of the problems projects observe and the mechanisms they use to address them. One common 1 https://kristoff.it/blog/contributor-poker-and-ai/ 2 https://curl.se/dev/contribute.html#on-ai-use-in-curl
aspect they all share, however, is that they respond to the same broad challenge: AI can increase the volume of contributions, lower their quality, weaken their alignment with project needs, and place additional strain on the review process and on the maintainers responsible for it. Review is the procedure through which maintainers decide whether a contribution addresses a problem the project regards as worth solving, fits the project’s technical direction, preserves maintainability, and can be incorporated into the project’s long-term evolution. We model the review process as a capacity-constrained signaling problem in which review time is an investment under uncertainty. A contributor chooses whether to submit a change, and a maintainer must decide not only whether to begin reviewing it, but also whether to spend scarce review effort to decide whether to accept or reject the contribution. Before AI-mediated development, the work required to produce a plausible patch and follow through with review acted as a costly signal. This signal had two parts. First, effort could indicate contribution quality: the contributor had done enough work to make acceptance plausible. Second, for new contributors, effort could indicate contributor potential: even if the patch was weak, the contributor had shown enough interest to make mentoring potentially worthwhile. AI weakens both signals by making polished artifacts cheaper to produce and by allowing an AI operator to generate, not only the initial contribution, but also the surrounding materials and interaction such as the pull request text, the justification, the test scaffolding, the responses to review comments, and revised patches. As the apparent value of the contribution become less informative at time of submission, maintainers face a harder allocation problem, which is further strained by an increase in contributions due to AI (including PRs and bug reports). The framework we propose is naturalistic rather than prescriptive. Its first part identifies the concerns surrounding the governance problem that the review process faces trying to judge and decide whether the expected value of a contribution exceeds the expected upfront cost of its review (this threshold will vary across projects). As AI increases submission volume and weakens the signals that made review worthwhile, maintainers must devote more attention to triage. Review effort is justified when it produces at least one of three returns: i) it may improve the project directly by integrating a valuable contribution, ii) it may protect the project through stewardship of architecture, maintainability, and direction, or iii) it may also develop project capacity by helping an interested participant become a long-term contributor and potentially, a maintainer. This framework is derived from the structure of the OSS contribution system: the stakeholders involved, the resources they contribute, the signals they use, the costs they impose on one another, and the payoffs they seek and informed by the results of RQ1. Table III describes these concerns, organized around a set of dimensions. Each dimension identifies a major way in which AI-mediated participation changes the contribution process; each concern identifies an issue that contribution policies should consider and potentially address. This framing leads to three policy adaptations. First,
policies should protect maintainer attention through scope limits, pre-discussion requirements, throttles, or closure rules for low-return submissions. Second, policies should preserve mentoring pathways for newcomers and new maintainers. And third, policies should distinguish contribution types, since bug fixes, new features, refactorings, and speculative changes differ in expected value and review burden. Their balance is difficult to achieve: a policy that filters aggressively may protect maintainers while discouraging future contributors, whereas a policy that remains too open may preserve access while exhausting review capacity. Disclosing that AI was used, and how, is useful for transparency, but insufficient as a signal of contributor ownership. AI changes the value of contribution signals as they can be generated cheaply (using AI). Projects therefore may need to require signals with higher evidentiary value. These signals help maintainers determine whether AI-mediated work (if used) is owned by the contributor or instead leaves evaluation, explanation, and integration work to the project’s maintainers. Maintainer-side AI should also be considered as part of adaptation. Projects may use AI to increase review capacity through triage, summarization, testing, or analysis. AI can support review, but decisions about what the project accepts, rejects, or maintains must remain under human stewardship. The adaptations required for AI-mediated contributions require projects to specify, in their policies, what forms of AI use are acceptable and under which conditions. We call these conditions Acceptability Principles: role-specific requirements that AI-mediated participation must satisfy to remain compatible with the project’s contribution regime. They define the conditions under which AI use remains compatible with project stewardship, the central purpose of the project’s contribution policies. These are presented in Table IV. The acceptability principles are organized around the three stakeholders of OSS contribution governance: the project, the contributor, and the maintainer. The project defines the contribution regime and its boundaries; the contributor remains responsible for the submitted work; and the maintainer preserves stewardship over review and incorporation decisions. Every OSS project serves a particular need and user base, which gives it its own priorities and goals which shape the project’s stewardship commitments and, in turn, its contribution policy. Acceptable AI use therefore depends on how a project defines valuable contribution, acceptable risk, contributor responsibility, and maintainer stewardship. The acceptability principles provide a way to make those projectspecific conditions explicit. Variation in AI contribution policies (as we observed in RQ1) is expected because projects face different stewardship conditions: every OSS project serves a particular need and user base, with its own priorities and goals. VII. D ISCUSSION A higher level view of the results from RQ1 reveal that 42 projects prohibit the use of AI. These projects do so mainly for three distinct reasons: 18 prioritize code quality to avoid
TABLE III C ONCERNS FOR ADAPTING OSS CONTRIBUTION POLICIES TO AI- MEDIATED CONTRIBUTION Dimension Scarcity shift
Governance Concern Scarcity shifts from coding to reviewing Contribution value varies
What changed AI makes contributions cheaper to produce, but not cheaper to review, integrate, or maintain. Contribution value AI lowers production cost most for contributions whose correctness and scope are hard to evaluate, without reducing their review cost. Signal reliability Effort signals weaken AI reduces the effort needed to produce patches, explanations, tests, and revisions. Review dialogue must remain AI can generate responses and simulate engagement during review. informative Contribution debt AI creates multiple debts AI-generated contributions can appear correct at review while carrying technical, cognitive, and intention debt that surface during maintenance. Review effort allo- Burden shifting becomes easier Submissions can move verification and integration work to maintaincation under AI ers. Maintainers’ use of AI AI can triage, and evaluate contributions at scale, making it possible to make acceptance decisions without justification. Project values shape bound- Projects differ in how they value throughput, quality, learning, auaries thorship, and identity. Contributor Review is stewardship and in- Review integrates code, protects project direction, and develops future development vestment contributors and maintainers. Newcomer pathways are vul- AI can bypass the learning process that turns newcomers into longnerable term contributors. Need for future maintainers AI may bypass the learning, trust-building, and sense of giving back through which contributors become maintainers. Autonomous Agen- Accountability is unassignable Contributions can be initiated and submitted without a human directtic contributions ing the specific submission.
Policy adaptation Protect maintainer attention. Set expectations by contribution type. Require evidence of understanding and project fit. Require substantive human ownership of review dialogue. Address technical, cognitive, and intention debt separately. Permit closure, throttling, or pre-discussion when review burden is excessive. Allow maintainer-side AI with accountable human decisions. State which values the policy protects. Preserve review for work with technical, stewardship, or contributor-development value. Protect good-first issues and mentorship contexts. Preserve pathways through which contributors earn trust, develop judgment, and assume long-term responsibility. Require a human operator to accept accountability, or reject fully autonomous submissions outright.
TABLE IV P RINCIPLES FOR ACCEPTABLE AI- MEDIATED CONTRIBUTION Layer Project governance
Contributor
Maintainer
Principle Project autonomy Interpretive fairness
Acceptability condition Each project may define valid and invalid AI-mediated contribution practices. AI use should be judged by its effects, not by reflexive pro-AI or anti-AI assumptions. Project risk boundaries Any contribution must fall within the project’s accepted boundaries for security, uncertainty, maintenance burden, and provenance. Inclusive participation Policies must not exclude contributors for whom AI mediation enables participation that would otherwise be inaccessible due to technical, linguistic, or knowledge barriers. Autonomous agentic Each project explicitly defines whether autonomous agent submissions are perboundary mitted, and if so, under what conditions. Accountability The human contributor understands the contribution well enough to explain, revise it defend its rationale and justify relevant AI use; and to respond to review with genuine human judgment: revise or withdraw the submission, and address problems that arise from it. No burden shifting AI use must not shift unreasonable verification, debugging, explanation, provenance, or long term maintenance costs to maintainers. Evidence for acceptance The contributor provides enough rationale, evidence, tests, and responsiveness for maintainers to form justified trust in the contribution, even when they do not fully reconstruct or understand every part of it. Signal integrity AI use must not mislead maintainers about effort, understanding, or risk. Provenance discipline The contribution has acceptable authorship, origin, and licensing status. Accountability Maintainers remain responsible and accountable for review, triage, rejection, and incorporation decisions. Review integrity The maintainer directly evaluates the contribution; AI may summarize or flag but acceptance, rejection, and incorporation decisions must reflect the maintainer’s own assessment.
maintenance burdens (i.e., quality first), 16 cite legal uncertainty surrounding copyright of AI generated code (i.e., avoid the legal void), and 8 reject AI usage as a matter of ethical principles (i.e., AI negative impact on society and nature). Improvements in AI-generated output, clearer evidence of its reliability, or greater legal clarity may lead some projects to revisit their bans. However, projects that reject AI on ethical or community-value grounds may be less likely to change their position solely because the technology improves. Another relevant reflection stemming from the results is that “regulated” is not a soft version of “prohibited”; it has a distinct and internally consistent logic that sets it apart. Prohib-
Governance function Preserves local governance authority. Prevents both blanket suspicion and uncritical acceptance. Guides screening, review and merge decisions. Ensures AI governance preserves rather than narrows the contributor base. Defines the boundary for autonomous submissions and accountable human oversight. Ensures that maintainers engage with a human participant who is responsible and accountable for the contribution. Protects scarce review capacity. Enables maintainers to make an acceptance, rejection, or revision decision without having to reconstruct the contribution. Preserves the informativeness of contribution signals. Reduces security and licensing risks. Keeps the use of maintainer-side AI subordinate to human stewardship. Ensures review decisions reflect genuine human judgment.
ited projects state AI-mediated contributions are categorically unacceptable; regulated projects find AI acceptable under the condition that the contributor demonstrates full understanding and responsibility for the contribution (most policies focus only on the contributor). Consequently, regulated policies are defined by conditionality (e.g., ‘if you use AI...’). A. Implications for researchers Fent et al provide a roadmap of [5]. The cite the importance of studying how Governance in OSS communities is adapting to the use of AI. The first part of our study shows the wide diversity in which OSS projects are addressing this (including
complete banning). Because we have studied only projects that have adapted their policies to AI, we do not know if those who have not are also struggling with AI and accept them. Plenty of research is needed in this direction. Our framework can be used as a foundation for further research that studies how OSS communities are adapting their contribution policies to AI. Contribution policies are living documents. They are shaped by the communities that create them and by the software those communities steward. The projects that are changing their policies in response to AI-mediated contribution are at the forefront of this transition, as they work out how best to adapt their governance practices. However, most OSS projects have not yet adapted their contribution policies to AI, and we do not know whether they are considering doing so, whether they are already managing AI-related problems informally, or whether AI has not yet become a salient governance issue for them. Further research is needed to answer these questions. B. Implication for practitioners AI contribution policies are project-governance instruments through which OSS communities decide what they value, what burdens they are willing to accept, what forms of human accountability they require, and which forms of participation they want to preserve. The AI Contribution Governance Framework supports this process as a policy design aid rather than a prescription for a single AI policy. Communities can use the framework to identify the challenges AI creates in their specific context and to translate those challenges into concrete policy mechanisms, procedures, and enforcement practices. In doing so, the framework helps communities deliberate about the values their policies should protect and make those values explicit and operational in their contribution policies. VIII. T HREATS TO VALIDITY Following the main types of threats to validity in Experimental Software Engineering proposed by Wohlin et al. [64], the following three types that affect our study are discussed: internal, external and construct threats. Our analysis is subject to several threats to internal validity stemming from the construction and verification of the dataset itself. While many project policies were verified against primary sources like CONTRIBUTING.md or AI POLICY.md files, others lacked formal documentation. In such cases, the most consequential statements often appeared in informal channels, such as blog posts or public statements (e.g., curl and LadybirdBrowser). In addition, many policy texts were remarkably brief or sparse, making it difficult to interpret their intent. The authors conducted a manual verification supported by a triangulation process to compare their findings against the original dataset authors’ classifications, identifying those discrepancies that necessitated the reclassification of projects and the refinement of their underlying rationales. A threat to external validity is that our results should not be interpreted as estimating the prevalence of AI contribution policies, policy types, or governance mechanisms across the
entire OSS universe. Although we combine two complementary sources—one based on policies identified among the 1,000 most-starred GitHub projects and another based on a handcurated collection of publicly visible OSS AI contribution policies—these sources do not support statistical generalization to all OSS projects. Our findings therefore should not be read as claims about how common particular policy positions are in OSS as a whole. Instead, the results identify the range of governance issues, policy mechanisms, and tensions that appear in current AI contribution policies. We use these results as the empirical basis for developing our framework for acceptable AI-mediated contribution. The main construction-validity threat is the conceptual leap from policy evidence to framework construction. The goal of RQ1 is to classify what current OSS AI contribution policies say; thus these policies become the starting point for answering RQ2: identifying the broader governance problems that AI-mediated contribution creates for OSS projects. This means that some framework dimensions go beyond the explicit wording of the policies. The risk is that the framework may either remain too close to the data, becoming a catalog of current policy features, or move too far from the data, becoming a theoretical account that is not sufficiently grounded in observed policy responses. We mitigate this by keeping a clear distinction between the policy mechanisms we observed and the governance issues we infer from them, and by presenting the framework as an empirically grounded conceptual tool that can be revised as OSS AI governance evolves. IX. C ONCLUSIONS Communities manifest their values in the software they create, while the software itself shapes the values of the community that forms around it. This creates a feedback loop: an OSS project attracts contributors through the software it offers, but once a community forms, its values influence how the software evolves. In this study, we show that many OSS communities are regulating AI-mediated contribution in widely different ways, including restriction and outright bans. Their rationales also differ. Some policies are pragmatic, focusing on quality, review burden, maintainability, and legal uncertainty. Others are more philosophical, emphasizing authorship, human participation, community identity, or the broader social and environmental effects of AI. This diversity reflects the heterogeneity of OSS: projects serve different purposes, face different constraints, and form different communities. AI contribution policies should therefore be understood as adaptations to a changed contribution environment. If AI lowers the cost of submitting work, policies must protect the scarce capacity needed to evaluate and absorb it. If AI weakens traditional signals of effort, understanding, and commitment, policies must require stronger evidence of project fit and human accountability. The purpose is not to maximize or minimize AI use, but to preserve the conditions under which review remains a worthwhile investment in both the codebase, and the contributor and maintainer community.
The AI Contribution Governance Framework supports OSS communities in this process. Rather than prescribing a single policy position, the framework helps communities identify the AI-related pressures that matter in their context, connect those pressures to the values they want to protect, and translate those values into concrete policy mechanisms. Ultimately, as AI reshapes contribution, the central challenge is for the OSS ecosystem to keep adapting without losing the conditions that allow its projects and communities to thrive. R EFERENCES [1] K. Crowston and J. Howison, “The social structure of free and open source software development,” First Monday, vol. 10, no. 2, 2005. [Online]. Available: http://dx.doi.org/10.5210/fm.v10i2.1207 [2] A. Bosu and J. C. Carver, “Impact of developer reputation on code review outcomes in oss projects,” in Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 9 2014, pp. 1–10. [Online]. Available: http://dx.doi.org/10.1145/2652524.2652544 [3] M. Gaughan, K. Champion, S. Hwang, and A. Shaw, “The introduction of README and CONTRIBUTING files in open source software development,” in Proceedings of the 2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE), 2025, pp. 191–202. [4] B. Falcucci, F. Gomide, and A. Hora, “What do contribution guidelines say about software testing?” in Proceedings of the 2025 IEEE/ACM 22nd International Conference on Mining Software Repositories (MSR), 2025, pp. 434–438. [5] Z. Feng, R. Milewicz, E. Murphy-Hill, T. Menezes, A. Serebrenik, I. Steinmacher, and A. Sarma, “Charting uncertain waters: a sociotechnical roadmap for sustaining open source communities in the age of genAI,” ACM Transactions on Software Engineering and Methodology, vol. (accepted, pending publication), p. 3789210, 2026. [Online]. Available: http://dx.doi.org/10.1145/3789210 [6] S. Balali, I. Steinmacher, U. Annamalai, A. Sarma, and M. A. Gerosa, “Newcomers’ barriers. . . is that all? an analysis of mentors’ and newcomers’ barriers in oss projects,” Computer Supported Cooperative Work (CSCW), vol. 27, no. 3-6, pp. 679–714, 2018. [Online]. Available: http://dx.doi.org/10.1007/s10606-018-9310-8 [7] M. Guizani, A. Chatterjee, B. Trinkenreich, M. E. May, G. J. NoaGuevara, L. J. Russell, G. G. Cuevas Zambrano, D. Izquierdo-Cortazar, I. Steinmacher, M. A. Gerosa, and A. Sarma, “The long road ahead: Ongoing challenges in contributing to large OSS organizations and what to do,” Proceedings of the ACM on Human-Computer Interaction, vol. 5, no. CSCW2, October 2021. [8] M. Guizani, A. Chatterjee, B. Trinkenreich, M. E. May, G. J. Noa-Guevara, L. J. Russell, G. G. C. Zambrano, D. Izquierdo-Cortazar, I. Steinmacher, M. A. Gerosa, and A. Sarma, “The long road ahead: Ongoing challenges in contributing to large oss organizations and what to do,” Proceedings of the ACM on Human-Computer Interaction, vol. 5, no. CSCW2, pp. 1–30, 2021. [Online]. Available: http://dx.doi.org/10.1145/3479551 [9] H. Li, H. Zhang, and A. E. Hassan, “Aidev: Studying ai coding agents on github,” 2026. [Online]. Available: https://arxiv.org/abs/2602.09185 [10] H. He, C. Miller, S. Agarwal, C. Kästner, and B. Vasilescu, “Speed at the cost of quality: How cursor ai increases short-term velocity and longterm complexity in open-source projects,” in Proceedings of the 23rd International Conference on Mining Software Repositories, ser. MSR ’26. New York, NY, USA: ACM, 2026, pp. 1–19. [11] R. Zhang, W. Dai, H. V. Pham, G. Uddin, J. Yang, and S. Wang, “Engineering pitfalls in ai coding tools: an empirical study of bugs in claude code, codex, and gemini cli,” 2026. [Online]. Available: https://arxiv.org/abs/2603.20847 [12] Y. Wang, W. Zhong, Y. Huang, E. Shi, M. Yang, J. Chen, H. Li, Y. Ma, Q. Wang, and Z. Zheng, “Agents in software engineering: Survey, landscape, and vision,” Automated Software Engineering, vol. 32, no. 2, p. 70, 2025. [Online]. Available: http://dx.doi.org/10.1007/s10515-025-00544-2
[13] A. Hora and R. Robbes, “AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI?” May 2026, arXiv:2605.16706v1 [cs.SE]. [Online]. Available: https://arxiv.org/abs/2605.16706 [14] J. Coelho and M. T. Valente, “Why modern open source projects fail,” in Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, 8 2017, pp. 186–196. [Online]. Available: http://dx.doi.org/10.1145/3106237.3106246 [15] G. Avelino, E. Constantinou, M. T. Valente, and A. Serebrenik, “On the abandonment and survival of open source projects: An empirical investigation,” in 2019 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). IEEE, 2019, pp. 1–12. [16] H. Hata, T. Todo, S. Onoue, and K. Matsumoto, “Characteristics of sustainable oss projects: A theoretical and empirical study,” in 2015 IEEE/ACM 8th International Workshop on Cooperative and Human Aspects of Software Engineering, 5 2015, pp. 15–21. [Online]. Available: http://dx.doi.org/10.1109/CHASE.2015.9 [17] M. Rashid, P. M. Clarke, and R. V. O’Connor, Exploring Knowledge Loss in Open Source Software (OSS) Projects, ser. Communications in Computer and Information Science. Springer International Publishing, 2017, pp. 481–495. [Online]. Available: http://dx.doi.org/10.1007/ 978-3-319-67383-7 35 [18] Z. Li, Y. Yu, T. Wang, G. Yin, S. Li, and H. Wang, “Are you still working on this? an empirical study on pull request abandonment,” IEEE Transactions on Software Engineering, vol. 48, no. 6, pp. 2173–2188, 2022. [Online]. Available: http://dx.doi.org/10.1109/TSE.2021.3053403 [19] Z. Feng, K. Kimura, B. Trinkenreich, I. Steinmacher, M. A. Gerosa, and A. Sarma, “Addressing oss community managers’ challenges in contributor retention,” ACM Transactions on Software Engineering and Methodology, vol. 35, no. 7, pp. 1–38, 2026. [Online]. Available: http://dx.doi.org/10.1145/3769012 [20] P. C. Rigby, D. M. German, L. Cowen, and M.-A. Storey, “Peer review on open-source software projects,” ACM Transactions on Software Engineering and Methodology, vol. 23, no. 4, pp. 1–33, 2014. [Online]. Available: http://dx.doi.org/10.1145/2594458 [21] J. Tsay, L. Dabbish, and J. Herbsleb, “Influence of social and technical factors for evaluating contribution in GitHub,” in Proceedings of the 36th International Conference on Software Engineering, ser. ICSE 2014. New York, NY, USA: Association for Computing Machinery, 2014, pp. 356–366. [22] D. M. German, G. Robles, G. Poo-Caamaño, X. Yang, H. Iida, and K. Inoue, “Was my contribution fairly reviewed?” in Proceedings of the 40th International Conference on Software Engineering, 5 2018, pp. 523–534. [Online]. Available: http://dx.doi.org/10.1145/3180155. 3180217 [23] D. Wermke, N. Wöhler, J. H. Klemmer, M. Fourné, Y. Acar, and S. Fahl, “Committed to trust: A qualitative study on security & trust in open source software projects,” in 2022 IEEE Symposium on Security and Privacy (SP), 5 2022, pp. 1880–1896. [Online]. Available: http://dx.doi.org/10.1109/SP46214.2022.9833686 [24] P. C. Rigby and C. Bird, “Convergent contemporary software peer review practices,” in Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, ser. ESEC/FSE 2013. New York, NY, USA: Association for Computing Machinery, 2013, pp. 202–212. [25] T. Bock, N. Alznauer, M. Joblin, and S. Apel, “Automatic core-developer identification on github: a validation study,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 6, pp. 1–29, 2023. [Online]. Available: http://dx.doi.org/10.1145/3593803 [26] M. Gharehyazie, D. Posnett, B. Vasilescu, and V. Filkov, “Developer initiation and social interactions in oss: a case study of the apache software foundation,” Empirical Software Engineering, vol. 20, no. 5, pp. 1318–1353, 2014. [Online]. Available: http://dx.doi.org/10.1007/ s10664-014-9332-x [27] I. Steinmacher, T. Conte, M. A. Gerosa, and D. Redmiles, “Social barriers faced by newcomers placing their first contribution in open source software projects,” in Proceedings of the 18th ACM Conference on Computer Supported Cooperative Work & Social Computing, 2 2015, pp. 1379–1392. [Online]. Available: http://dx.doi.org/10.1145/2675133.2675215 [28] I. Steinmacher, M. Gerosa, T. U. Conte, and D. F. Redmiles, “Overcoming social barriers when contributing to open source software projects,” Computer Supported Cooperative Work (CSCW),
vol. 28, no. 1-2, pp. 247–290, 2018. [Online]. Available: http: //dx.doi.org/10.1007/s10606-018-9335-z [29] I. Steinmacher, T. U. Conte, and M. A. Gerosa, “Understanding and supporting the choice of an appropriate task to start with in open source software communities,” in 2015 48th Hawaii International Conference on System Sciences, 1 2015, pp. 5299–5308. [Online]. Available: http://dx.doi.org/10.1109/HICSS.2015.624 [30] I. Steinmacher, T. U. Conte, C. Treude, and M. A. Gerosa, “Overcoming open source project entry barriers with a portal for newcomers,” in Proceedings of the 38th International Conference on Software Engineering, 5 2016, pp. 273–284. [Online]. Available: http://dx.doi.org/10.1145/2884781.2884806 [31] X. Tan, M. Zhou, and Z. Sun, “A first look at good first issues on github,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 11 2020, pp. 398–409. [Online]. Available: http://dx.doi.org/10.1145/3368089.3409746 [32] J. Silva, I. Wiese, D. M. German, C. Treude, M. A. Gerosa, and I. Steinmacher, “A theory of the engagement in open source projects via summer of code programs,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, 11 2020, pp. 421–431. [Online]. Available: http://dx.doi.org/10.1145/3368089.3409724 [33] X. Tan, M. Zhou, and L. Zhang, “Understanding mentors’ engagement in oss communities via google summer of code,” IEEE Transactions on Software Engineering, vol. 49, no. 5, pp. 3106–3130, 2023. [Online]. Available: http://dx.doi.org/10.1109/TSE.2023.3242415 [34] Z. Feng, K. Kimura, B. Trinkenreich, A. Sarma, and I. Steinmacher, “Guiding the way: a systematic literature review on mentoring practices in open source software projects,” Information and Software Technology, vol. 171, p. 107470, 2024. [Online]. Available: http: //dx.doi.org/10.1016/j.infsof.2024.107470 [35] Z. Feng, I. Steinmacher, M. Gerosa, T. Menezes, A. Serebrenik, R. Milewicz, and A. Sarma, “The multifaceted nature of mentoring in oss: Strategies, qualities, and ideal outcomes,” in 2025 IEEE/ACM 18th International Conference on Cooperative and Human Aspects of Software Engineering (CHASE), 4 2025, pp. 203–214. [Online]. Available: http://dx.doi.org/10.1109/CHASE66643.2025.00031 [36] A. Lee, J. C. Carver, and A. Bosu, “Understanding the impressions, motivations, and barriers of one time code contributors to FLOSS projects: A survey,” in 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE). IEEE, 2017, pp. 187–197. [37] A. Lee and J. C. Carver, “Are one-time contributors different? a comparison to core and periphery developers in floss repositories,” in 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM), 11 2017, pp. 1–10. [Online]. Available: http://dx.doi.org/10.1109/ESEM.2017.7 [38] G. Pinto, I. Steinmacher, and M. A. Gerosa, “More common than you think: An in-depth study of casual contributors,” in 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering (SANER), 3 2016, pp. 112–123. [Online]. Available: http://dx.doi.org/10.1109/SANER.2016.68 [39] A. Barcomb, A. Kaufmann, D. Riehle, K.-J. Stol, and B. Fitzgerald, “Uncovering the periphery: a qualitative survey of episodic volunteering in free/libre and open source software communities,” IEEE Transactions on Software Engineering, vol. 46, no. 9, pp. 962–980, 2020. [Online]. Available: http://dx.doi.org/10.1109/TSE.2018.2872713 [40] A. Barcomb, K.-J. Stol, B. Fitzgerald, and D. Riehle, “Managing episodic volunteers in free/libre/open source software communities,” IEEE Transactions on Software Engineering, vol. 48, no. 1, pp. 260–277, 2022. [Online]. Available: http://dx.doi.org/10.1109/TSE.2020.2985093 [41] B. Trinkenreich, M. Guizani, I. Wiese, A. Sarma, and I. Steinmacher, “Hidden figures: Roles and pathways of successful oss contributors,” Proceedings of the ACM on Human-Computer Interaction, vol. 4, no. CSCW2, pp. 1–22, 2020. [Online]. Available: http://dx.doi.org/10.1145/ 3415251 [42] M. Gerosa, I. Wiese, B. Trinkenreich, G. Link, G. Robles, C. Treude, I. Steinmacher, and A. Sarma, “The shifting sands of motivation: Revisiting what drives contributors in open source,” in 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 2021, pp. 1046–1058. [43] A. K. Turzo, S. Sultana, and A. Bosu, “From first patch to long-term contributor: Evaluating onboarding recommendations for oss newcomers,” IEEE Transactions on Software Engineering, vol. 51,
no. 4, pp. 1303–1318, 2025. [Online]. Available: http://dx.doi.org/10. 1109/TSE.2025.3550881 [44] I. D. Noni, A. Ganzaroli, and L. Orsi, “The evolution of oss governance: a dimensional comparative analysis,” Scandinavian Journal of Management, vol. 29, no. 3, pp. 247–263, 2013. [Online]. Available: http://dx.doi.org/10.1016/j.scaman.2012.10.003 [45] P. Tourani, B. Adams, and A. Serebrenik, “Code of conduct in open source projects,” in 2017 IEEE 24th International Conference on Software Analysis, Evolution and Reengineering (SANER), 2 2017, pp. 24–33. [Online]. Available: http://dx.doi.org/10.1109/SANER.2017. 7884606 [46] V. Singh, B. Bongiovanni, and W. Brandon, “Codes of conduct in open source software-for warm and fuzzy feelings or equality in community?” Software Quality Journal, vol. 30, no. 2, pp. 581–620, 2021. [Online]. Available: http://dx.doi.org/10.1007/s11219-020-09543-w [47] H. Frluckaj and J. Howison, Codes of Conduct in Open Source, ser. Equity, Diversity, and Inclusion in Software Engineering. Apress, 2024, pp. 295–308. [Online]. Available: http://dx.doi.org/10.1007/ 978-1-4842-9651-6 17 [48] J. Sun, H. Fang, J. Zhang, J. Shi, R. Lai, A. Ihuman, R. Littauer, and S. Zhou, “Beyond adoption: Examining the evolution and impact of codes of conduct on open source communities,” in 2026 IEEE/ACM 48th International Conference on Software Engineering (ICSE ’26). New York, NY, USA: Association for Computing Machinery, 2026. [Online]. Available: https://www.eecg.utoronto.ca/ ∼shuruiz/forcolab/paper/ICSE2026-Beyond Adoption.pdf [49] M. A. Rossi, “Decoding the free/open source software puzzle: A survey of theoretical and empirical contributions,” in The Economics of Open Source Software Development, J. Bitzer and P. J. H. Schröder, Eds. Elsevier, 2006, pp. 15–55. [50] S.-W. Chou and M.-Y. He, “Understanding OSS development in communities: The perspectives of ideology and knowledge sharing,” Behaviour & Information Technology, vol. 30, no. 3, pp. 325–337, 2011. [51] P. N. Sharma, U. The University of Alabama, S. L. Daniel, U. University of Cincinnati, T. R. Chung, U. College of William & Mary, V. Grover, and U. University of Arkansas, “A motivation-hygiene model of open source software code contribution and growth,” Journal of the Association for Information Systems, vol. 23, no. 1, pp. 165–195, 2022. [Online]. Available: http://dx.doi.org/10.17705/1jais.00712 [52] J. Taylor and R. Dantu, “For love or money? examining reasons behind oss developers’ contributions,” Information Systems Management, vol. 39, no. 2, pp. 122–137, 2021. [Online]. Available: http: //dx.doi.org/10.1080/10580530.2021.1879323 [53] L. Jahn, P. Engelbutzeder, L. K. Michel, S. Prost, M. B. Twidale, D. Randall, and V. Wulf, “Blending code and cause: Understanding the dynamic motivations of volunteer developers in community-driven foss projects,” in Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems, 4 2025, pp. 1–17. [Online]. Available: http://dx.doi.org/10.1145/3706598.3713416 [54] J. Coelho, M. T. Valente, L. L. Silva, and A. Hora, “Why we engage in floss,” in Proceedings of the 11th International Workshop on Cooperative and Human Aspects of Software Engineering, 5 2018, pp. 114–121. [Online]. Available: http://dx.doi.org/10.1145/3195836.3195848 [55] W. Zhang, B. Jiang, and A. Koziolek, “Augmentation with dilution: A large-scale empirical study of human contributor ecosystems after ai coding agent adoption,” 2026. [56] A. Salkever, “Open source maintainers,” Linux Foundation Research, Tech. Rep., 2023, with a foreword by Shuah Khan. [Online]. Available: https://www.linuxfoundation.org/research/open-source-maintainers [57] M. Gerosa and A. Lawson, “The state of global open source 2025,” Linux Foundation Research, Tech. Rep., 2025. [Online]. Available: https: //www.linuxfoundation.org/research/world-of-open-source-global-2025 [58] The Linux Foundation, “Guidance regarding use of generative ai tools for open source software development,” Linux Foundation policy guidance, n.d. [Online]. Available: https://www.linuxfoundation.org/ legal/generative-ai [59] M. Surman, A. Bdeir, L. Dodson, A.-B. Felix, and N. Marda, “Accelerating progress toward trustworthy ai,” Mozilla Foundation, Tech. Rep., 2024, v.09 for Public Comment. [Online]. Available: https://www.mozillafoundation.org/en/research/ library/accelerating-progress-toward-trustworthy-ai/whitepaper/ [60] Mozilla Foundation, “Trustworthy artificial intelligence,” Mozilla Foundation web page, n.d. [On-
line]. Available: https://www.mozillafoundation.org/en/internet-health/ trustworthy-artificial-intelligence/ [61] C. Albon and L. Zia, “Our new ai strategy puts wikipedia’s humans first,” Wikimedia Foundation News, Apr. 2025. [Online]. Available: https://wikimediafoundation.org/news/2025/04/30/ our-new-ai-strategy-puts-wikipedias-humans-first/ [62] Wikimedia contributors, “Artificial intelligence/guidelines,” Meta-Wiki, 2026. [Online]. Available: https://meta.wikimedia.org/wiki/Artificial intelligence/Guidelines [63] M. W. Mendonça, “open-source-ai-contribution-policies,” https://github. com/melissawm/open-source-ai-contribution-policies, gitHub repository. Accessed: 2026-06-28. [64] C. Wohlin, P. Runeson, M. Host, M. C. Ohlsson, B. Regnell, and A. Wesslen, Experimentation in software engineering. New York: Springer Science and Business Media, 2012.