Open source has always welcomed contributions. It has been less explicit about whether the contribution must improve something other than the contributor’s profile.
At the end of June, maintainer Neil Alexander described an increase in AI-assisted submissions and questioned whether some were primarily aimed at accumulating visible credit. His account included small, technically correct changes that he declined because they did not justify the project’s attention. This is one maintainer’s experience, not a measured rate across open source.1
Generating a contribution has become cheap enough to reveal who pays to receive it. The maintainer still has to read the thing.
The patch is not the whole transaction
A contribution arrives with obligations. Someone needs to understand it, decide whether it belongs, check its effects, and possibly maintain it afterward.
For the submitter, generating a patch may take little time. For the maintainer, the evaluation remains connected to the project’s history and responsibilities. A change that looks harmless in isolation can interact with conventions or constraints the submitter has not encountered.
Even when the change is genuinely harmless, reviewing it consumes attention. That attention has an alternative use. It could address a difficult bug, support a release, or allow the maintainer to spend an evening elsewhere.
A profile is not a project
Beginners need a way in. Maintainers need contributions they can evaluate without first reconstructing what the contributor was trying to do. A clear question can be more welcome than a large, unexplained patch.
The difference is participation in the project’s needs. Has the contributor read the guidance? Do they understand the change? Can they explain why it matters? Are they willing to respond when the maintainer asks a question?
A small contribution made with care can establish trust. A large automated submission made without understanding can consume it.
The easiest metric gets the most enthusiasm
A contribution count is legible. Long-term stewardship is harder to condense into a small green square.
One possible response is to change what counts as evidence. A thoughtful issue report, a reproducible test case, documentation that addresses a real confusion, or sustained help to users may tell us more than a sequence of unrelated patches.
Ask the contributor to explain the change and demonstrate the problem it solves. A generated explanation can imitate confidence; answering a specific review question puts that confidence to work.
Maintainers are not an unpaid admissions committee
A project can welcome outsiders without accepting responsibility for everyone’s career development. It can decline a contribution because the change is outside its priorities or because the review burden exceeds the benefit.
A project can set acceptance criteria before the inbox fills. Without them, the maintainer negotiates the standard anew with each person who has discovered a faster way to submit work.
An excellent use for the new tools
The strongest use keeps the human responsible for the submission. The contributor can explain the problem, the reasoning, the tests, and the remaining uncertainty. They do not disappear when the assistant’s first answer meets a question.
Keep enough of those people willing to log back in tomorrow.