ESLint Ends Paid Contributor Program as AI Upends Open Source Collaboration

ESLint is retiring its contributor pool after five years, citing growing difficulties with AI-generated contributions and disputes over whether contributors deserved payment for work produced with AI assistance.

In a November 13 announcement, ESLint creator Nicholas C. Zakas said the program had paid outside contributors more than $51,000 and helped recruit several future team members. But the increasing volume of AI-generated issues and pull requests, along with accusations about undisclosed AI use, had made the program increasingly difficult to administer.

The decision comes as open source projects across the ecosystem are reconsidering how they accept, review, and reward contributions. Some are restricting outside pull requests, others are tightening their AI policies, and several are struggling with the additional review work created by AI-assisted development.

ESLint introduced its contributor pool in 2022 to compensate people outside the core team for meaningful contributions to the project. The program initially allocated $1,000 per month before switching to a model that reserved 10% of monthly income for contributors. Eligible work included code, documentation, answering questions in Discord, and other activities that benefited the project.

The experiment was successful by the team's own assessment. ESLint paid outside contributors $24,680 in 2025 alone, bringing its total payouts from 2022 through 2025 to $51,180. The program encouraged repeat contributions and helped attract people who eventually joined the ESLint team.

Zakas emphasized that the decision to retire the program was unrelated to its growing expense. In his conclusion, he acknowledged how much the contributor pool had accomplished and how dramatically the circumstances surrounding it had changed.

"The contributor pool was an approach designed for a completely different time in open source. A time when we were still making human-to-human connections through a shared goal of creating great software. It worked well for a time, and we’re grateful to everyone who made a meaningful contribution to ESLint in the last five years. It introduced us to many future team members who remain with the project today."

Beginning in 2025, ESLint noticed a growing number of AI-generated issues and pull requests. The team decided that contributions produced primarily through AI tools would not qualify for payment, reasoning that asking an assistant to implement a change did not represent the kind of effort the program was intended to encourage.

Contributors were asked to disclose AI assistance in their pull request descriptions, but not everyone complied. As coding models improved, maintainers found it increasingly difficult to distinguish human-authored contributions from AI-generated work.

The situation became more contentious when people Zakas called "AI monitors" began examining pull requests and contributor payment reports, publicly accusing some contributors of undisclosed AI use. Zakas said he also received private messages warning him about accounts suspected of submitting AI-generated work.

"All of this took the joy out of the contributor pool," he wrote.

With AI-generated pull requests now dominating the project's submissions, ESLint decided to discontinue the program effective immediately rather than continue investigating the origins of individual contributions.

The decision does not prohibit AI-assisted development. ESLint's AI usage policy still allows contributors to use these tools, provided they disclose their use, review the generated work, and remain responsible for their submissions. AI-generated pull requests must also address issues that the team has explicitly accepted.

According to GitHub's 2026 Oct overse report, more than 40% of pull requests on the platform began with an AI agent's first draft by September, up from 17% in March. GitHub reported 110 million agent-started pull requests in September alone.

Many of these submissions represent legitimate development work, and AI tools are helping experienced engineers implement changes more efficiently. For open source maintainers, however, the growing volume also complicates assumptions that have traditionally guided the contribution and review process.

In August, Rust contributor Jynn Nelson explained why five teams working on the rust-lang/rust repository had adopted new policies governing AI use. She emphasized that contributions have traditionally served a purpose beyond improving the code itself:

While the Rust project is a collection of technical artifacts, it is also a community of people who work together to build, maintain, and extend those artifacts. When we talk about 'contributing to the Rust project', we partly mean work on those artifacts, but we also mean joining that community and collaborating with the people already there.

Historically, a polished, well-tested pull request suggested that its author had invested time in understanding the codebase. Maintainers could reasonably expect that someone submitting substantial work might be interested in further contributions, making the review process an opportunity for mentorship.

AI-generated code has made those signals less reliable. A contributor can now produce an impressive-looking patch without necessarily understanding how it works, why the change is needed, or how it fits into the project's architecture.

The consequences are particularly evident at tldraw, where founder Steve Ruiz described an unusual problem in January involving AI-generated issues and the contributors attempting to resolve them.

Ruiz had created a Claude Code command that converted his rough notes about bugs and feature ideas into detailed GitHub issues. When the original instructions were sufficiently clear, the system worked well. When they were vague, the AI sometimes invented bugs or proposed solutions to problems that did not exist.

Outside contributors were then using their own AI coding assistants to implement those issues, producing pull requests that appeared technically sound but addressed problems the project never intended to solve.

Some of the submissions passed automated tests and initially looked like useful contributions. The underlying issue was that neither AI system had enough context to determine whether the work made sense. Ruiz's issue-writing assistant had generated misleading tasks, and contributors' coding assistants were implementing them without questioning the premise.

The experience led tldraw to announce that it would automatically close external pull requests, although it would continue accepting bug reports, issues, and discussions.

Ruiz questioned whether outside contributions still offered enough value to justify the review work they created:

I think this misses the point. We already accept code written with AI. I write code with AI tools. I expect my team to use AI tools too. If you know the codebase and know what you're doing, writing great code has never been easier than with these tools.

The question is more fundamental. In a world of AI coding assistants, is code from external contributors actually valuable at all?

If writing the code is the easy part, why would I want someone else to write it?

AI is changing the economics of code review. Even technically correct code can be a bad fit for a project, and maintainers still have to judge whether a change belongs, whether its author understands it, and whether anyone will take responsibility for it after it's merged.

Several major open source projects have responded by introducing stricter rules for AI-generated work and new contributors.

In June, the Godot Foundation announced changes to its contribution policies after struggling with a growing backlog of pull requests and a limited number of qualified reviewers.

Godot said AI-generated submissions had intensified an existing problem: producing a pull request had become considerably easier, while the effort required to review one had remained largely unchanged.

The project moved to prohibit autonomous AI agents, substantial AI-generated code, and AI-generated text in discussions between contributors. New contributors with three or fewer merged pull requests must also obtain maintainer permission before proposing new features or significant refactors.

Godot's announcement raised another concern beyond the immediate review burden. Maintainers traditionally invest time helping inexperienced contributors understand the codebase, partly because those contributors may eventually become reviewers and maintainers themselves.

When feedback is passed directly into an AI coding assistant without the contributor developing that understanding, reviewers may spend considerable time on an exchange that does little to strengthen the project's future maintainer base.

LLVM has adopted a more permissive policy that allows AI-assisted contributions with human oversight, but it explicitly prohibits using AI tools to complete issues labeled good first issue. Those tasks are reserved as learning opportunities for developers getting acquainted with the codebase.

LLVM also prohibits autonomous agents from participating in project discussions or submitting changes without human approval. Its policy places responsibility on contributors to understand and review AI-generated material before asking maintainers to evaluate it.

Node.js has introduced additional requirements for pull requests exceeding 5,000 lines, addressing the difficulty of reviewing unusually large changes.

The strain on reviewers has also become apparent in the Linux kernel.

On November 10, Linux kernel developer Lorenzo Stoakes submitted changes to remove himself from several memory-management and Rust-related reviewer roles, citing the volume of AI-generated patch series.

Stoakes, an Arm engineer who remains a maintainer in his own areas of responsibility, explained that the volume of incoming work had forced him to limit his review commitments.

Given the current throughput in the kernel resulting from AI-generated
series, I unfortunately lack the bandwidth to generally be able to offer
review except in those areas I maintain.

In the subsequent mailing-list discussion, he described encountering low-quality AI-generated submissions occasionally at first, then weekly, and eventually every few days. He estimated that such submissions now accounted for roughly half or more of the patches he encountered.

Stoakes clarified that he was primarily trying to reduce inbox noise and focus on his maintainer responsibilities. His account nevertheless offers a recent example of how the increasing volume of generated code is affecting experienced reviewers.

A Linux Foundation study published in October found that 59% of surveyed maintainers reported growing contributions associated with generative AI. Respondents estimated that 25% of incoming pull requests were low-quality AI-generated submissions.

ESLint isn't the only project reconsidering payments to outside contributors as AI makes it easier to generate submissions in large numbers.

In January, curl announced that it was shutting down its bug bounty program after maintainers were overwhelmed by low-quality vulnerability reports, including many generated with AI assistance.

Curl creator Daniel Stenberg said the project had experienced a sustained increase in reports that required investigation but produced few actionable findings. The project ended its financial rewards and stopped recommending HackerOne as its reporting channel, directing researchers to its own disclosure process instead.

The pressure continued beyond bug bounty submissions. In July, curl temporarily suspended vulnerability reporting for an entire month to give its maintainers time to address other work.

Stenberg later described the month-long break as one of the project's best decisions in recent memory:

The effect was almost immediate. Just a few days into the bliss, my fellow curl maintainers all agreed with me that we felt a sense of relief, of vacation and that a load had been taken off our chests. We felt free, unchained, and now suddenly able to do what we wanted.

We could now spend time reviewing some of the queued up pull-requests for features and changes we like.

GitHub has also expanded the options available to repository owners in response to these issues. In February, the platform introduced settings that allow maintainers to disable pull requests or restrict them to existing collaborators, giving projects more control over which contributions they accept.

For projects that rely on outside participation, restricting contributions creates its own difficulties. New developers need opportunities to learn unfamiliar codebases, receive feedback, and develop relationships with maintainers. Those interactions have historically helped sustain open source communities, even when reviewing a newcomer's first contribution required more effort than writing the code independently.

ESLint is ending a program that successfully recruited contributors because the effort required to distinguish qualifying work has become too burdensome. Other projects are making different choices, from imposing tighter contribution requirements to changing how they fund security work or limiting access to their repositories.

Restricting outside contributions may spare maintainers from a flood of AI-generated submissions, but it also threatens one of the ways open source projects have historically recruited and developed the people who keep them running.

"Whether or not AI-powered contributions will lead to the same type of dedication as human-authored contributions is yet to be seen," Zakas said. "All I can say at the moment is that open source has changed and we need to change with it."