News · 2026-11-11

Open-source projects are writing very different rules for AI contributions

Open-source projects including QGIS, Servo and QEMU have adopted different restrictions on AI-generated contributions, ranging from code rules to limits on generated discussion. A study of 281 selected published policies found most allowed or encouraged AI use for code, showing that prominent restrictions do not establish a universal ban.

Key facts

• A selected-policy preprint found 83.3% permitted or encouraged AI in code and 14.9% prohibited it.
• QGIS’s accepted policy and its main contributor guide contain conflicting agent instructions.
• Project rules differ on code, reports, comments, research and translation.
• Primary source: QGIS’s accepted policy.

A patch may be cheap to generate, but a maintainer still has to understand it, verify that it fixes a real problem and own the result after merging. The situation resembles receiving a stack of unsolicited repair estimates: producing them is easy, while checking each one takes attention from the person responsible for the building.

The QGIS policy limits generated text and AI-assisted code in its main repository. A developer proposed a “moratorium” during the project’s mailing-list discussion; replies also raised concerns about access and process. The accepted policy file uses the number 408, while its pull-request title uses 428. The contributor guide’s conflicting language shows that adoption and implementation are separate work.

Servo’s policy bars generated material across contributions and discussions. QEMU’s provenance rules allow research or debugging assistance if generated output is not included in the submission. Immich allows translation while restricting generated pull requests and other material. These boundaries should not be collapsed into one rule.

The policy study analyzes written policies in selected popular active projects, not a random sample of all open source. A second study finds maintainer burden commonly cited in restrictive policies, but does not show whether bans reduce that burden. Some contributors argue automation can help under-resourced projects, while others report costly low-context submissions; neither individual account establishes a population-wide effect.

For a contributor, the actionable rule is to read the target project’s policy before submitting and be able to explain and test the work. For observers, the change is a governance debate about review, ownership and trust, not a referendum with a single result.

Why policies differ

Projects differ in their governance as well as their technical needs. A browser engine may emphasize difficult correctness and security review; a project that requires contributors to certify the origin of patches may focus on licensing and provenance; a small volunteer team may focus on the time spent responding to reports that are incorrect or cannot be reproduced. Some policies also state broader ethical objections. Each rationale can produce a different boundary around code, issue reports and discussion.

The accepted QGIS document is a useful example of the gap between an adopted rule and the paths through which contributors encounter it. Its policy process records discussion, voting and acceptance, while a separate change to the main repository’s contributor-facing template was reverted. The current guide still contains a direction to automated agents. Contributors facing inconsistent documents should look at the current policy and the project's own process; observers should not present the inconsistency as proof that the accepted policy does not exist.

The preprint’s percentages use policies as the denominator. That means projects without written AI rules do not appear in the reported proportions. The sample also selects popular and active repositories. It cannot tell us what fraction of all maintainers oppose a particular tool, how often contributors actually comply, or whether a rule improves a project's outcomes.

The second study’s interviews and policy analysis identify maintainer burden as a recurring rationale in its restrictive subset. That does not establish that every generated patch is low quality, or that human-written patches never impose review costs. Nor does it settle whether a blanket restriction, a disclosure rule or conventional review performs best. Those questions require outcome data about submissions, review time and contributor retention.

A proposed directory of restrictive policies was part of the day's signal, but its own page could not be checked in the dossier. The reporting here uses the individual project documents and the studies directly instead of treating the unverified directory’s roster or reach as a population measure.

Primary source, verified: read the paper →

Ground Truth. (2026, November 11). Open-source projects are writing very different rules for AI contributions. Ground Truth. https://groundtruth.day/news/open-source-projects-ai-contribution-rules.html

@misc{groundtruth:open-source-projects-ai-contribution-rules,
  title  = {Open-source projects are writing very different rules for AI contributions},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {nov},
  url    = {https://groundtruth.day/news/open-source-projects-ai-contribution-rules.html}
}

Topics: open-source · coding-agents · policy