Who gets credit for upkeep?
AI coding tools have made it cheap to produce new code and expensive to review it. The people who review, test and fix are mostly unpaid and uncounted. We propose a way to record that work and give it weight in how a project is run, without turning it into money.
The problem
Most shared software is kept alive by a few people doing work that produces nothing new: triaging bug reports, reviewing changes, fixing flaky tests, updating dependencies and answering newcomers. Researchers who study open-source projects call this invisible labour, because the usual measures (commits, features, downloads) don't capture it.1
AI tools have widened the gap. Generating a pull request now costs almost nothing, and reviewing one still costs a person's time. Developers describe the result as "an endless stream of AI slop".2 Projects have started writing policies just to limit AI-generated contributions.3
Why paying per task tends to backfire
The obvious fix is to pay for the work: bounties for closed issues, or tokens for maintenance points. The risk is Goodhart's law. Once a measure becomes a target, people optimise the measure.4 Bounties attract trivial fixes and changes split up to earn more payouts. Tradable tokens add a second problem: anyone who buys them gets influence they didn't earn.
Money still has a place. Grants and salaries for maintainers help. The trouble comes from paying per countable unit, and from making recognition something you can sell.
What we propose
A contribution receipt: a signed record that a person did a specific piece of work, on a specific date, and that someone else checked it. Three rules:
- Someone else verifies it. That can be a reviewer, a test that now passes, or a bug that stays fixed.
- It can't be sold or transferred. It stays with the person who did the work.
- It counts inside the community where the work happened. It gives standing to review and merge, weight in decisions about the project's direction, and a record the person can show elsewhere.
The third rule is the point. A record nobody uses is a certificate on a wall. We propose that people who keep a shared resource working get more say in how it's run. Long-lived commons have tended to work this way, with rules set by the people who use and maintain the resource.5
What's unsolved
- Weighing different work. Is a week of triage worth more than one hard bug fix? We don't have a formula, and any fixed formula will be gamed.
- Collusion. Two people can approve each other's trivial work. Rotating or randomly assigned reviewers make this harder without ruling it out.
- Privacy. A detailed record of someone's work can also be used to monitor them. People should control who sees theirs.
- Income. Receipts give standing, not money. Maintainers still need funding.
What you can do now
- If you run a project, count review and triage in your contributor lists and in who gets a say, not only commits.
- If you fund open source, fund maintainer roles rather than per-issue bounties.
- If you're a researcher, the weighting and collusion problems are open. See Open problems.
Sources
1. John Meluso, Amanda Casari, Katie McLaughlin and Milo Z. Trujillo, "Invisible Labor in Open Source Software Ecosystems," arXiv:2401.06889 (2024).
2. Sebastian Baltes, Marc Cheong and Christoph Treude, "'An Endless Stream of AI Slop': How Developers Discuss the Burden of AI-Assisted Software Development," arXiv:2603.27249 (2026).
3. Gregorio Robles, Daniel M. German et al., "You can contribute if you… An Empirical Framework of AI Contribution Policies in OSS," arXiv:2609.07919 (2026).
4. C. A. E. Goodhart, "Problems of Monetary Management: The U.K. Experience," in Monetary Theory and Practice (Macmillan, 1984), 91–121, doi:10.1007/978-1-349-17295-5_4.
5. Elinor Ostrom, Governing the Commons: The Evolution of Institutions for Collective Action (Cambridge University Press, 1990), doi:10.1017/CBO9780511807763.
