Infinite contributions,
finite maintainers.

A pull request is a proposal someone else has to live with. Before it becomes part of a project, somebody needs to understand the change, check its assumptions, test its behaviour, and decide whether maintaining it is worth the cost.

Generative AI changes the effort needed to produce that proposal. It does not automatically remove the work that follows. That gap is where I think the most important questions about AI and open source sit.

There are real opportunities here: help navigating unfamiliar code, faster experiments, and tools that find defects people missed. There are also costs that are easy to move out of sight when success is measured in generated code or submitted contributions.

This essay brings together research, maintainer accounts, and an exploratory analysis of 623 selected posts and comments. Those sources answer different questions. The research helps test specific effects; the accounts show what those effects can feel like in practice; the sample helps identify recurring concerns.

1. Productivity depends on what you measure

A study of GitHub Copilot by Yeverechyahu, Mayya, and Oestreicher-Singer used differences in early language support to examine its effect on open-source activity. The May 2026 revision estimates a 28–40% increase in contributions, with a larger increase in incremental work than in new functionality. It is evidence of a benefit in the setting studied, rather than a universal estimate for every project or current coding agent. Read the Copilot study.

Another result complicates the picture. In a randomized study of 16 experienced developers completing 246 tasks in familiar open-source repositories, METR found that allowing early-2025 AI tools made tasks take 19% longer. The participants still believed the tools had helped them move faster. The result concerns those developers, repositories, tasks, and tools. Read the early-2025 experiment.

That finding also needs its follow-up. In February 2026, METR reported that selection effects made its newer experiment an unreliable measure of current productivity: developers were increasingly reluctant to work without AI, and some excluded tasks they expected AI to help with. The researchers thought newer tools were probably more helpful, but could not confidently estimate the size of the improvement. Read the methodology update.

I take these studies as a reason to measure the whole task. Contribution volume, implementation time, correctness, and future maintenance are different outcomes. A project can receive more patches while becoming harder to maintain. It can also benefit from AI without producing more patches at all, if the same work arrives with better tests and clearer explanations.

2. Cheap submissions can create expensive review

Imagine a contributor asking an agent to fix an issue, then forwarding the result without reproducing the bug or understanding the patch. A maintainer now has two jobs: evaluate the proposed change and reconstruct the investigation that should have happened before submission.

Even a plausible patch leaves questions. Does it preserve compatibility? Does the test fail on the old implementation? Does it introduce a dependency the project wants to support? Is it fixing the root cause or hiding a symptom?

These questions existed before AI. The pressure grows when submitting work becomes much easier than checking it, especially if the submitter cannot answer follow-up questions. An explanation generated alongside a patch is useful only when somebody has verified it.

My preferred standard is responsibility for the contribution. The person submitting a change should be able to explain the problem, show evidence, and revise the patch. Projects can reasonably set different rules for AI assistance. A contributor should read those rules before asking volunteers to spend time on a submission.

There is a learning issue too. Reviewing a beginner can be an investment in a future maintainer. If tooling helps that person understand the system, the investment can pay off. If it lets them bypass understanding entirely, the project may receive a patch without developing another person who can support it. That is a risk to watch, not an outcome this dataset establishes.

3. Better security findings still require people

The curl project shows why this debate cannot stop at low-quality AI output. In January 2026, Daniel Stenberg announced the end of its bug bounty, citing a flood of poor reports and the effort needed to investigate them. That was a change to monetary rewards, not an end to accepting vulnerability reports. Read the announcement.

By May, his account described a different problem: a much higher volume of useful security reports. Confirming findings, assessing severity, producing patches, and coordinating disclosures were consuming the team’s time. Better reports improved the software while creating substantial pressure on the people responsible for it. Read Stenberg’s account.

This distinction matters. Finding a real vulnerability is valuable. Resolving it is additional work. A tool that improves discovery should be evaluated partly by what happens after the report: can someone reproduce the issue, understand the impact, review a fix, and ship it safely?

For companies funding automated discovery, I would like to see comparable support for triage and remediation. Funding reports without funding the capacity to act on them leaves a gap in the security process.

4. The shared knowledge also needs maintenance

Open source includes more than repositories. Documentation, discussions, examples, and explanations help people use and repair software. A private answer can solve one person’s problem without adding anything to that shared record.

A 2024 PNAS Nexus study estimated that Stack Overflow activity fell by about 25% within six months of ChatGPT’s release, relative to comparison platforms. This supports concern about a shift in public participation. It does not establish that AI caused every later decline in Stack Overflow traffic or that every documentation business faces the same outcome. Read the knowledge-sharing study.

The longer-term risk, in my view, is a feedback loop: people benefit from answers grounded in shared knowledge while contributing fewer corrections, examples, and explanations back to it. The size of that effect will vary. The practical response is to make returning useful knowledge part of the workflow.

If an AI-assisted investigation reveals a missing setup step, improve the documentation. If it uncovers a confusing API edge case, publish a minimal example. If a company depends on a library, fund maintenance or allocate engineering time to it. Tool access is useful, but it does not by itself pay for ongoing review and support.

5. What 623 posts can—and cannot—tell us

To explore the discussion, I examined a selected corpus of 623 relevant entries: 495 Hacker News comments and 128 X posts. The retained entries are dated September 29, 2023 through October 2, 2026. Each has an AI-assigned stance label and a primary theme.

This is an exploratory sample, not a survey of developers. Posts were selected through high-engagement threads and topic searches. The findings describe the collected entries; they do not estimate how the open-source community as a whole feels.

Of the 623 entries, 291 were labelled negative (46.7%), 134 positive (21.5%), 78 mixed (12.5%), and 120 neutral (19.3%). Hacker News accounts for nearly four-fifths of the sample, so it strongly influences the combined result.

The variation by theme is more useful to me than an overall mood score. Entries about productivity lean positive; entries about low-quality contributions lean negative. Those positions can coexist: a person can value assistance in their own work and dislike receiving unverified output from others.

Method and limitations

The collection notes describe 857 initial items, filtered to 623 relevant entries by a single language model using zero-shot classification. These calculations use the 623 retained rows. The original excluded items are not part of the retained dataset, so the relevance filter cannot be audited from this release.

Manual spot checks were used, but there is no quantified independent human agreement assessment. Model labels can misread sarcasm, context, or the target of a complaint. The model version, exact prompt, and full coding instructions are not included with this release, so this is not a fully reproducible classification study.

The sample also overrepresents controversy, contains multiple comments from the same conversations, and does not identify a unique set of respondents. Entries should not be treated as independent people. Changing topics and uneven coverage over time mean these counts cannot establish a sentiment trend or a causal effect of AI.

The dataset includes VADER scores as well. Those measure textual sentiment, which is different from a person’s stance on AI’s effect on open source. Disagreement between the two does not prove either method correct.

You can download the aggregate counts as CSV or JSON. These provide the underlying counts for the tables without republishing the collected third-party posts. The analysis is best used to identify questions worth investigating further.

6. What would help

The useful question for a project is whether a contribution leaves it better off after accounting for the work it creates. I would apply that through a few concrete practices.

• For contributors: read the project’s policy, reproduce the issue, keep the patch focused, and provide tests that demonstrate the change. Disclose AI assistance where required. Be able to explain and maintain what you submit.
• For maintainers: state what a reviewable contribution needs. Ask for reproduction steps and evidence early. Set intake limits that fit the team’s capacity, while leaving a clear path for newcomers who want to learn.
• For tool builders: help users verify output before sending it upstream. Make it easier to inspect a diff, run project checks, preserve provenance, and produce a concise explanation of what was actually tested.
• For organizations using open source: fund review, documentation, release work, and security remediation alongside new features. Treat the health of critical dependencies as an ongoing engineering responsibility.

I would measure success through review time, reproducible reports, escaped defects, and the number of people able to maintain the project. Submission counts can be part of the picture, but they should not define it.

AI can help people do excellent open-source work. Getting there requires paying attention to where the saved effort goes, who inherits the remaining work, and whether the project still has people willing and able to look after it.

A healthy commons needs contributions its maintainers can trust—and maintainers with the capacity to act on them.