AI-written contributions: help or new burden for volunteer projects?

The Short Version

Whether AI output helps a volunteer project depends on who has to check it. Guido van Rossum uses GitHub Copilot every day and finds it a real time-saver, because he reviews its suggestions himself before they go anywhere [3]. Jimmy Wales sees several ways AI could assist Wikipedia's editors, as long as its suggestions go to people who can verify them, since a model "doesn't really know or care about the truth." [2] The FFmpeg maintainers describe the other side: AI-generated security reports arriving from a large company, with a deadline attached, on the desks of unpaid volunteers [1]. The tools are the same in all three cases; what changes is whether the cost of verification falls on the person who used the AI or on someone else.

Table of contents

What They Said

Kieran Kunhya and Jean-Baptiste Kempf: reports at industrial scale, fixes by volunteers

Kunhya, a codec engineer and FFmpeg contributor, tells the story of a dispute with Google, and he is careful about how he begins: Google is one of the biggest supporters of open source and has been for a long time, he says, but some things went a bit overboard this time [1].

FFmpeg processes untrusted data, he explains, and security issues in that situation are normal; the project says so on its home page [1]. What changed recently was that Google started using AI to create security reports on an open source project, and FFmpeg's volunteers had to deal with them [1]. In his account, the company "provided very limited funding," applied a standard 90-day industry deadline "without really understanding the nature of volunteer driven development," and promoted its AI in the media before the issues could be fixed [1]. One vulnerability, he notes, "was on an obscure 1990s game codec" [1].

Asked by Fridman to make the other side's case, Kunhya does. Google has substantial resources working on the security of open source projects that are everywhere; it has used a lot of compute and very capable, expensive security researchers; and from its standpoint, he says, "they are contributing by doing that," which he adds is where opinions differ [1].

His own view comes through two comparisons. Part of the security community, he says, sees itself like "building architects that never have to go to site": they do their security work, and the day-to-day construction is someone else's problem [1]. And he compares a project's defenses to the lock on a house, which is not there to guard everything against every capability: "it's not there to protect nuclear secrets" [1]. Using AI at scale to pick such locks and then announcing that the lock is not secure, he suggests, puts the burden in the wrong place [1]. He also criticizes the security industry's aggressive language and its habit of labeling everything high severity [1]. The summary of the conversation records the later turn as well: Google began sending patches and rewarding fixes [1].

Kempf connects the episode to burnout. He now maintains many multimedia and other libraries himself because, in his words, "the maintainers got fed up" [1]. A maintainer needs a tough skin, he says; the messages are not really attacks, just a stream of reports that something is not working, "And you feel it personally." [1] That, he says, is why the Google episode was a problem: large companies do not realize that at the bottom of the stack there is "one random open source project that is maintaining the whole internet" [1]. The two men discuss burnout more widely, including the xz backdoor, in which a lone maintainer was worn down by attackers, and libxml losing its maintainer [1]. They also recount Microsoft Teams marking a bug as high priority on FFmpeg's volunteer tracker and then offering only a one-time payment of a few thousand dollars [1].

The background is who does the work. FFmpeg, Kunhya says, "is developed almost entirely by volunteers," people who come home from a day job tired and still care, but who may not be able to explain every subtle detail to every newcomer [1].

On AI as a contributor of code, the two are skeptical for technical reasons specific to their project. Kunhya notes that current language models struggle with FFmpeg's kind of handwritten assembly because there is not enough training data, and Kempf says low-level optimization for hardware is something that cannot simply be vibe-coded [1]. The contributors they celebrate are human; one FFmpeg tweet read that "teenagers have written more assembly in FFMPEG than Google engineers." [1]

Jimmy Wales: AI as an assistant to editors, not an author

Wales approaches the question as the co-founder of a project that has always depended on accepting contributions from strangers. Wikipedia took off, he recalls, when it dropped a seven-stage academic review process: "we got more work done in two weeks than we had in almost two years." [2] He chose to make the site forgiving of mistakes, and he stresses welcoming newcomers; one later Wikipedian of the Year started as a teenage vandal and changed course when someone gently explained what the project was trying to do [2].

Against that background he sees clear uses for AI: flagging biased wording, checking whether an article accurately reflects its sources, helping non-native speakers with grammar, and summarizing talk page disputes into warning banners [2]. His standard for usefulness is modest. Even imperfect suggestions are useful if enough of them are good [2]. Every item on that list is a prompt to a human editor, who still decides what changes.

He is blunt about why AI cannot simply write the encyclopedia. He describes a model that invented three entirely fictitious but plausible examples when he asked about sports analogies, and says it "doesn't really know or care about the truth." [2] He would like chatbots to report how much of an answer is unreliable [2].

He also knows what an unchecked error costs. A magazine once published that he enjoys playing chess with friends, a detail sourced from vandalism on his own Wikipedia page, a real instance of the citogenesis cycle [2]. Biographies of living people require special care because errors can hurt, and "human dignity really matters" [2].

On the larger relationship between AI companies and Wikipedia, Wales is relaxed about use and firm about credit. He is untroubled if people get Wikipedia's knowledge through assistants, since the content is a gift to the world, but he insists that proper attribution is simply good intellectual practice, and the foundation does worry about donations if users never learn where the knowledge came from [2]. He is encouraged by work on grounding answers in quality sources, and describes a weekend demo by Wikimedia's head of machine learning that retrieves relevant articles and answers only from them [2]. He expects Wikipedia in ten years to look similar, with AI-assisted search and major growth in smaller languages helped by better machine translation [2].

Guido van Rossum: a daily user who checks his own work

Van Rossum's view is that of an individual programmer, and it is positive. He uses GitHub Copilot every day [3]. Its suggestions are usually slightly wrong, he says, but they save him a lot of typing, often completing a whole line or a five-to-ten-line function if he names it well [3]. He does not think it threatens programmers any more than Stack Overflow did: "It helps you take care of the boring stuff." [3] It works best as a reminder of things you could look up, while the creative work of deciding what to build remains yours [3].

The detail that matters for this question is that the suggestions are usually slightly wrong [3]. Van Rossum is describing output that needs correcting, and he is the one correcting it before anyone else sees the code.

He also knows the receiving end, though he does not discuss AI contributions to Python. He says "software is a very social activity," written for other programmers as much as for computers [3]. He describes mypy as an open source project with a very small number of maintainers; when companies decided static type checking was worth investing in, Google, Facebook and later Microsoft built their own checkers instead of supporting it [3]. Maintainers of the C extensions behind data science and machine learning are, he says, many of them already short-staffed, which is one reason any breaking change to Python would need years of warning [3]. And he weighs new features by maintenance cost: of a faster multithreaded Python, he asks whether the core developers would be willing to maintain that code indefinitely [3].

Where They Agree, and Where They Don't

They agree that AI output needs a human check. Van Rossum's Copilot suggestions are usually slightly wrong [3]. Wales's model invents plausible examples [2]. Kunhya's volunteers had to deal with each AI-generated report [1].

They agree that maintainers are few and their time is the scarce thing. Kempf has inherited libraries from maintainers who got fed up [1]. Van Rossum describes small maintainer teams and short-staffed extension authors [3]. Wales locates Wikipedia's health in how its volunteers respond to complaints and newcomers [2].

They agree that companies take more than they give back. FFmpeg's stories about Google and Microsoft [1], van Rossum's account of companies building their own type checkers instead of supporting mypy [3], and Wales's concern about attribution and donations [2] all describe the same imbalance.

They differ on whether AI is, on balance, a help. Van Rossum says yes, for the boring parts of his own work [3]. Wales says yes for specific editorial tasks, with a human deciding [2]. Kunhya and Kempf describe a net burden in the case they lived through [1]. The difference is position, not temperament: van Rossum chooses when to use the tool and absorbs its errors himself [3], while FFmpeg's volunteers received output they did not ask for, on someone else's schedule [1].

They differ on whether a valid AI finding counts as a contribution. Kunhya states Google's view that finding vulnerabilities is contributing, and says that is where opinions differ [1]. His objection is not that the reports were false; the sources do not say they were. It is that they concerned an obscure codec, came with a deadline and publicity, and arrived without the resources to fix them [1].

They differ on how forgiving to be toward imperfect input. Wales built Wikipedia on tolerance for flawed first attempts [2]. The FFmpeg maintainers acknowledge they are sometimes terse because they cannot hold every contributor's hand [1]. A wiki page can be improved by the next visitor [2]; a security report in critical infrastructure lands on a specific small group [1].

Why It Works

Generating is cheap and verifying is not. Kunhya's lock-picking image is about scale: AI lets one party produce findings at a volume the other side must answer one by one [1]. Wales's fictitious sports examples show why each item needs checking: they were plausible [2].

The checker's position determines the cost. When the user is also the reviewer, as with van Rossum and Copilot, a slightly wrong suggestion costs a few seconds [3]. When the output is sent to a third party, the reviewer pays, and in volunteer projects the reviewer is unpaid [1].

Deadlines and publicity add pressure. A 90-day disclosure window assumes staff. Kunhya says it was applied without understanding volunteer development, and that the AI was promoted in the media before fixes existed [1].

Reports are felt personally. Kempf's explanation of burnout is that a steady flow of messages saying something is broken wears on the person receiving them, even when none is an attack [1].

Unchecked errors spread. Wales's citogenesis story shows a single false line passing from a wiki page into print [2].

Help works when it is shaped for the checker. Wales's proposed uses all produce a flag or a summary for an editor to accept or reject [2], and Google's later move to send patches addresses the same point from the other direction [1].

The evidence here is first-hand accounts. None of the three sources offers counts of AI-generated contributions or of time spent handling them.

Where It Applies, and Where It Doesn't

The burden is heaviest for small, critical projects maintained by volunteers, where a large outside party can generate work faster than the project can absorb it [1]. It is lightest for personal use, where the person prompting the AI is the person who reviews the result [3].

The benefits Wales describes apply to tasks with a clear human decision at the end, such as wording, grammar and source checks [2]. They do not extend to letting a model state facts on its own authority [2].

Some work is out of reach for current tools. FFmpeg's handwritten assembly is one example the maintainers give [1].

Two limits on the argument should be stated. Van Rossum is speaking as a user of Copilot, not about AI-written submissions to Python, so his optimism does not directly answer the maintainers' complaint [3]. And the FFmpeg dispute involved conduct beyond the use of AI, including the deadline, the publicity and the funding, so it is not evidence that AI-found vulnerabilities are worthless [1]. Kunhya himself grants Google's wider support for open source [1].

What To Do With It

1. Check AI output yourself before sending it to a project. Van Rossum's own experience is that suggestions are usually slightly wrong [3], and Wales's is that errors can be entirely plausible [2].
2. If you report a problem, bring the fix or the means to fix it. The FFmpeg dispute eased when Google began sending patches and rewarding fixes [1].
3. Match deadlines to the people who must meet them. A standard 90-day window was, in Kunhya's account, applied without understanding volunteer-driven development [1].
4. Do not publicize a finding before the maintainers can address it. Announcing the AI's success first was one of Kunhya's main complaints [1].
5. Rate severity honestly. Kunhya criticizes the habit of labeling everything high severity and notes that one issue was in an obscure 1990s game codec [1].
6. Use AI inside a project as an assistant to reviewers. Wales's list is a model: flag biased wording, compare articles with their sources, help with grammar, summarize disputes [2].
7. Credit your sources. Wales calls attribution simply good intellectual practice, and Wikipedia's funding depends on people knowing where knowledge came from [2].
8. If your company depends on a volunteer project, fund it in proportion. The maintainers' examples of limited funding and one-time payments are the pattern to avoid [1].
9. Keep AI for the boring parts of your own work. That is where van Rossum finds it most useful, with the decisions about what to build left to the person [3].
10. Remember there is a person at the other end. Kempf says maintainers feel reports personally [1], and Kunhya asks contributors not to take a tired volunteer's terseness personally either [1].

Sources

1. FFmpeg and VLC with Jean-Baptiste Kempf and Kieran Kunhya: Codecs, Assembly, and the Volunteers Behind Internet Video · Lex Fridman Podcast
2. Jimmy Wales on Building Wikipedia, Neutrality, Community Health and the Business of Trust · Lex Fridman Podcast
3. Guido van Rossum on Python 3.11's Speedup, Type Hints, the GIL and the Future of Programming · Lex Fridman Podcast