{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"maintainers-and-the-flood","title":"The commons under a flood of free submissions","url":"https://addaly.com/learn/how-software-changed/maintainers-and-the-flood","position":78,"of":87,"minutes":9,"answer":"Producing a plausible report costs seconds while disproving one costs a maintainer half an hour, so sustainable policy filters on evidence (a reproduction, passing tests.","keyIdea":"Producing a plausible report costs seconds while disproving one costs a maintainer half an hour, so sustainable policy filters on evidence (a reproduction, passing tests, the ability to answer a question) rather than on guessing how a submission was written."},"body":{"format":"markdown","text":"## The same asymmetry, with unpaid reviewers\n\nEverything 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.\n\nInside 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.\n\n## What actually happened to curl\n\nThe 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.\n\nThe 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.\n\nIn 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.\n\n## The same pattern elsewhere\n\n- **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.\n- **Issues filed without reproduction.** \"The parser fails on nested arrays\" with no version, no input, no output.\n- **Documentation pull requests that rewrite prose into something more generic**, losing the specific warning the sentence existed to give.\n- **Low-quality CVE submissions**, which impose a cost on every downstream user whose scanner now reports something.\n\nThe common feature: the submission has the form of a contribution without the part that took the work.\n\n## If you are contributing\n\nThe bar to clear is simple and it is about respect for somebody else's time.\n\n**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.\n\n**Run the project's tests before you open the pull request.** All of them, locally, on your change.\n\n**Read CONTRIBUTING, and follow it even where it seems fussy.** Those rules are a record of previous pain.\n\n**Disclose assistance if the project asks.** Increasingly they do, and an undisclosed submission that is obviously generated will be closed and remembered.\n\n**Never submit a security report you cannot demonstrate.** This is the one with lasting consequences. Maintainers remember names.\n\n**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.\n\n## If you are maintaining\n\n**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.\n\n**Make CI run before a human does.** Tests, linting, format. If the machine can reject it, it should, before it costs anyone attention.\n\n**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.\n\n**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.\n\n**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.\n\n## Do not overcorrect\n\nSome 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.\n\nThe 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."},"check":{"question":"Why is a policy of \"reject contributions that appear AI-generated\" worse than \"reject contributions without a reproduction\"?","options":[{"text":"Detecting generated text is unreliable and misfires on clean, conventional writing, while a reproduction is checkable.","correct":true},{"text":"Maintainers have no legal standing to ask about how a contribution was produced.","correct":false,"tempting":"Projects set their own contribution terms; the problem is that the test does not work, not that asking is impermissible."},{"text":"Generated contributions are usually higher quality than hand-written ones from newcomers, so rejecting them loses value.","correct":false,"tempting":"Overclaims quality; the argument is about which test is enforceable, not which source is better."},{"text":"A provenance rule is unenforceable because contributors can simply decline to answer the disclosure question.","correct":false,"tempting":"Non-answers can be handled by policy; the deeper failure is that the detection itself is unreliable."}]},"prev":{"slug":"copyright-and-training-unresolved","title":"The disagreement, laid out without a verdict","url":"https://addaly.com/learn/how-software-changed/copyright-and-training-unresolved"},"next":{"slug":"essence-and-accident","title":"The distinction that keeps being right","url":"https://addaly.com/learn/how-software-changed/essence-and-accident"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The commons under a flood of free submissions', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/maintainers-and-the-flood (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The commons under a flood of free submissions","courseTitle":"How Software Development Changed","module":{"index":8,"slug":"provenance-security-and-law","title":"Provenance, security and the unsettled law"},"answer":null,"keyIdea":"Producing a plausible report costs seconds while disproving one costs a maintainer half an hour, so sustainable policy filters on evidence (a reproduction, passing tests, the ability to answer a question) rather than on guessing how a submission was written.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-same-asymmetry-with-unpaid-reviewers","runs":[{"text":"The same asymmetry, with unpaid reviewers"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"what-actually-happened-to-curl","runs":[{"text":"What actually happened to curl"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-same-pattern-elsewhere","runs":[{"text":"The same pattern elsewhere"}]},{"t":"ul","items":[[{"text":"Pull requests that compile and miss the point.","b":true},{"text":" 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."}],[{"text":"Issues filed without reproduction.","b":true},{"text":" “The parser fails on nested arrays” with no version, no input, no output."}],[{"text":"Documentation pull requests that rewrite prose into something more generic","b":true},{"text":", losing the specific warning the sentence existed to give."}],[{"text":"Low-quality CVE submissions","b":true},{"text":", which impose a cost on every downstream user whose scanner now reports something."}]]},{"t":"p","runs":[{"text":"The common feature: the submission has the form of a contribution without the part that took the work."}]},{"t":"h2","id":"if-you-are-contributing","runs":[{"text":"If you are contributing"}]},{"t":"p","runs":[{"text":"The bar to clear is simple and it is about respect for somebody else’s time."}]},{"t":"p","runs":[{"text":"Reproduce it before you report it.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Run the project’s tests before you open the pull request.","b":true},{"text":" All of them, locally, on your change."}]},{"t":"p","runs":[{"text":"Read CONTRIBUTING, and follow it even where it seems fussy.","b":true},{"text":" Those rules are a record of previous pain."}]},{"t":"p","runs":[{"text":"Disclose assistance if the project asks.","b":true},{"text":" Increasingly they do, and an undisclosed submission that is obviously generated will be closed and remembered."}]},{"t":"p","runs":[{"text":"Never submit a security report you cannot demonstrate.","b":true},{"text":" This is the one with lasting consequences. Maintainers remember names."}]},{"t":"p","runs":[{"text":"Start by triaging, not by submitting.","b":true},{"text":" 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."}]},{"t":"h2","id":"if-you-are-maintaining","runs":[{"text":"If you are maintaining"}]},{"t":"p","runs":[{"text":"Require a reproduction before triage.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Make CI run before a human does.","b":true},{"text":" Tests, linting, format. If the machine can reject it, it should, before it costs anyone attention."}]},{"t":"p","runs":[{"text":"Add a disclosure question.","b":true},{"text":" Not to reject generated work, but because an honest answer changes how you read the submission, and a dishonest one is useful information."}]},{"t":"p","runs":[{"text":"Consider a reputation ladder for first-time contributors.","b":true},{"text":" Many projects now require manual approval before CI runs for new accounts, which also defends against pipeline abuse."}]},{"t":"p","runs":[{"text":"Say no faster.","b":true},{"text":" Maintainer burnout comes from the queue, not from any single item. A short, kind, immediate no costs less than a thoughtful no next month."}]},{"t":"h2","id":"do-not-overcorrect","runs":[{"text":"Do not overcorrect"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"The defensible line is about "},{"text":"evidence, not provenance","b":true},{"text":". 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."}]}],"check":{"question":[{"text":"Why is a policy of “reject contributions that appear AI-generated” worse than “reject contributions without a reproduction”?"}],"options":[{"text":[{"text":"Detecting generated text is unreliable and misfires on clean, conventional writing, while a reproduction is checkable."}],"correct":true,"tempting":null},{"text":[{"text":"Maintainers have no legal standing to ask about how a contribution was produced."}],"correct":false,"tempting":[{"text":"Projects set their own contribution terms; the problem is that the test does not work, not that asking is impermissible."}]},{"text":[{"text":"Generated contributions are usually higher quality than hand-written ones from newcomers, so rejecting them loses value."}],"correct":false,"tempting":[{"text":"Overclaims quality; the argument is about which test is enforceable, not which source is better."}]},{"text":[{"text":"A provenance rule is unenforceable because contributors can simply decline to answer the disclosure question."}],"correct":false,"tempting":[{"text":"Non-answers can be handled by policy; the deeper failure is that the detection itself is unreliable."}]}],"order":[1,3,2,0],"why":null},"prev":{"slug":"copyright-and-training-unresolved","title":"The disagreement, laid out without a verdict","minutes":10},"next":{"slug":"essence-and-accident","title":"The distinction that keeps being right","minutes":9}}}