The commons under a flood of free submissions

The same asymmetry, with unpaid reviewers

Everything in this course about production outrunning verification applies to open source, with one difference that changes the outcome: the reviewers are volunteers who can stop.

Inside a company, an overloaded reviewer is a delivery problem. In a project maintained by two people in their evenings, an overloaded reviewer is a project that gets archived.

What actually happened to curl

The clearest documented case is the curl project’s bug bounty. Daniel Stenberg wrote publicly about receiving a stream of security reports that were fluent, well-formatted, cited real-looking function names and line numbers, and described vulnerabilities that did not exist. Each one had to be read by a human, because a report that looks like a serious finding cannot be dismissed unread: that is exactly how a real one gets missed.

The economics are brutal and worth stating in the plain form. Generating a plausible report costs a few seconds. Disproving it costs a maintainer perhaps thirty minutes of careful reading. A bounty programme that pays for valid findings creates a direct incentive to produce volume, and the project absorbs the triage cost.

In 2025 the project changed its policy, requiring reporters to disclose AI use and warning that submitting slop could result in a ban. That is a well-run project with resources reaching for a blunt instrument, which tells you how bad the arithmetic had become.

The same pattern elsewhere

• Pull requests that compile and miss the point. Correct-looking, conventionally formatted, addressing a real issue in a way that does not fit the project’s design. Reviewing these is slower than writing the fix, because the maintainer must reconstruct the reasoning that was never there.
• Issues filed without reproduction. “The parser fails on nested arrays” with no version, no input, no output.
• Documentation pull requests that rewrite prose into something more generic, losing the specific warning the sentence existed to give.
• Low-quality CVE submissions, which impose a cost on every downstream user whose scanner now reports something.

The common feature: the submission has the form of a contribution without the part that took the work.

If you are contributing

The bar to clear is simple and it is about respect for somebody else’s time.

Reproduce it before you report it. Actually run it. Minimal input, exact versions, expected and actual output. A minimal reproduction is the single most valuable thing a reporter provides and is the clearest evidence that a human did the work.

Run the project’s tests before you open the pull request. All of them, locally, on your change.

Read CONTRIBUTING, and follow it even where it seems fussy. Those rules are a record of previous pain.

Disclose assistance if the project asks. Increasingly they do, and an undisclosed submission that is obviously generated will be closed and remembered.

Never submit a security report you cannot demonstrate. This is the one with lasting consequences. Maintainers remember names.

Start by triaging, not by submitting. Reproducing somebody else’s bug report is helpful, costs a maintainer nothing, and is the fastest way to become somebody whose pull requests get read.

If you are maintaining

Require a reproduction before triage. State it in the template and enforce it. Closing an issue with “please add a minimal reproduction and reopen” is not rude; it is the only sustainable policy.

Make CI run before a human does. Tests, linting, format. If the machine can reject it, it should, before it costs anyone attention.

Add a disclosure question. Not to reject generated work, but because an honest answer changes how you read the submission, and a dishonest one is useful information.

Consider a reputation ladder for first-time contributors. Many projects now require manual approval before CI runs for new accounts, which also defends against pipeline abuse.

Say no faster. Maintainer burnout comes from the queue, not from any single item. A short, kind, immediate no costs less than a thoughtful no next month.

Do not overcorrect

Some generated contributions are good. People who could not previously contribute, because of language, or because the codebase was in an unfamiliar stack, can now file a clear report and a working fix. A blanket ban loses those, and disproportionately loses them from people who were already least likely to contribute.

The defensible line is about evidence, not provenance. Did you reproduce it? Did the tests pass? Can you answer a question about your own change? Those apply equally to everyone, they filter on the thing that actually matters, and they do not require anybody to guess how a submission was written, which, as the provenance lesson showed, nobody can do reliably anyway.