by on April 15, 2026
Update: This blog post received significant immediate response — with strong reactions in multiple directions. Everyone on SFC's Copyleft Team has carefully considered for four years (i.e., since our policy fellow Bradley's 2022 article) what policies might make sense given the advent of LLM-assisted coding tools. We're now looking toward formulating formal policy recommendations with input from you. We believe movements are best built not by one person's proclamations, but rather through collaborations and planning for the best way forward together.
Below, I get us started by sharing my personal thoughts. Please come to a video chat session on one of the following days to discuss with us if you can (more details on the chats at the end of the post):
$ date -d '2026-04-21 15:00 UTC'
$ date -d '2026-04-28 23:00 UTC'
If you cannot attend these chats, and are already in personal contact with any SFC staffer, we all welcome you to chat with them or book a call — they would be happy to discuss. You can also reach out to <info@sfconservancy.org> and someone from our staff will engage in a slower email thread with you. As always, SFC never dictates mandatory policies on our member projects or our community. We look forward to hearing what you think at the sessions! My initial ideas follow:
Many people may recall Eternal September (in 1993) — when Usenet membership increased overwhelmingly — marking the annual September rush of student joins. The ensuing moderation challenges changed the culture of Usenet (the largest Internet discussion fora back then). Many early Usenet adopters left quickly. While this onslaught of “newbies” knew little of Usenet's traditional cultural norms, they nonetheless benefited greatly from these novel connections to discuss and learn together with people worldwide. The times were turbulent then, but eventually revised cultural norms emerged that benefited both the Eternal September arrivals and the old guard who stuck it out. Usenet (while less popular than it once was) survives today as the only widespread store-and-forward discussion fora optimized for low-bandwidth, spotty connectivity.
Today, another similar cultural change is afoot. I call it Eternal November. November 2025 — the month of Opus 4.5's release — has been widely identified as a similar inflection point: LLM-backed generative AI coding tools made a substantial leap to increased usefulness. A new wave of software developers — unfamiliar with traditional FOSS development culture — are adopting these systems quickly and making many (sometimes disastrous) mistakes. Some refuse to learn historical cultural norms, and others are genuinely confused (like all newbies) at the hostile responses.
We're all tempted — as some were in 1993 — to shun these “newbies” and reject their contributions aggressively. But what is really going on here? As in 1993, good and well-intentioned people just discovered newly interesting and hitherto unexplored ways to interact and engage with computing. FOSS's old guard reasonably feels angst, concern, and legitimate fear. We curated our norms over decades. But these norms are not sacrosanct. I urge us to reluctantly but seriously embrace this opportunity. We have much to teach these newcomers, and we must resist our arrogance of experience and assumptions that they've nothing to teach us.
I encourage all of us in the FOSS community to welcome the new software developers who've adopted these tools, investigate their motivations, and seriously consider cautiously and carefully discussing their workflows and consider if they may ultimately benefit FOSS. Seasoned software developers understand the benefits and limitations of LLM-assisted coding tools: we've studied for a few years the maintainability costs they incur, and the dangers of their flagrant, undisciplined use. We should give a try at explaining this to the newcomers. For example, if it comes from an individual (i.e., not a bot), an AI slop pull-request often offers an opportunity to educate a newcomer as to what they did wrong. Indeed, most FOSS developers that I know submitted a human-written-slop as their first contribution to a project. The ones who stayed are the ones who had an experienced developer explain what they did wrong — so they could improve and try again.
FOSS maintainers have decried for decades how few upstream contributions they receive. Maintainers today mostly bemoan the “AI slop”, and I agree that the slop is (at its absolute best) raw material to help make an actual contribution and (at its worst) tantamount to spam. Nevertheless, we must seek the goal of engagement to increase human collaboration (and thus maintainability). It is our job to recognize these opportunities, to communicate them, and to help new software developers build maintainable projects with us. It's a tall order: since the inception of FOSS, we've always needed to perpetually service the airplane while flying it: maintain the projects we have, while also creating the FOSS communities of the future for those projects. Only this approach has ensured FOSS will thrive and flourish. This is no time to give up that time-honored and documented successful approach.
The tiresome onslaught of slop (at least that presented by real humans) stems from a fundamental newbie confusion — but we can help newbies understand! We've always accepted (and encouraged) folks to keep private forks if they really like a patch that upstream determined was slop. My friend and colleague Bradley told me years ago that he maintained a personal fork of rsync for most of the 1990s because his extremely sloppy first-of-his-life submitted patch was rejected by upstream. Users who make a sloppy change that “works for them” should never be shunned; instead, they should be educated to make their own Git repository and rebase off upstream to their heart's content.
This is not to say we shouldn't encourage people to improve their behavior so they can contribute to and join FOSS projects. However, we do need to recognize when someone is ready and interested in doing that (and willing to put in a bit of extra time to help others), and when they just want to do a thing on their own, and that's fine for them. In the latter cases, we have always simply asked them to please stop sending us what they've got.
By recognizing what new technologies can do well, and what they can't, and how this differs from the technologies of the past, we can not only adapt our communities to these changes, but also take advantage of the new wave of people who are excited about our craft. It took time, but we adapted to the Eternal September. We can learn from that experience and do it again. The first steps are to recognize rapid changes, consider how they can benefit society, and then patiently and open-mindedly bring our ideals and extensive knowledge to the table to accelerate that positive change — while politely warning of the drawbacks (which are obvious to us but not to the newcomers).
There are many issues with LLM-backed generative AI coding tools; this blog post puts forward a few ideas about one of dozens of issues we now face (or will face in the near future). But every hope of improvement must begin somewhere. Therefore, if you help lead a FOSS project, or if you are using LLM-backed generative AI coding agents and want to learn to help rather than hinder upstream, please join us to discuss your concerns and the need to help welcome these new people to your communities in a manner that is productive. We will be running a series of interactive video chats, starting on April 21 at 15:00 UTC and April 28 at 23:00 UTC, in this room. SFC staff and volunteers will discuss these issues with the public. We'll consider how we can adapt FOSS projects to improve pro-AI contributor onboarding and how to better understand how newcomers are using and making software these days. Please also follow us using the linksa at the bottom of the page to learn about future such chats. SFC has dedicated 20 years already to successfully making FOSS the best it can be. We plan to do the same for the next 20 years, by understanding the needs of billions of new software developers, and welcoming them to our community with grace and education.