Agreed. Linux and GNU did and still do so well because of the GPL. Red Hat built a billion dollar business on GPL software. Tons of Linux developers are payed great salaries by competing corporations that otherwise collaborate on Linux, because none of them are allowed by the GPL to make proprietary changes to the code
Implement rigid supply chain auditing.
Formalize an open source contribution and patronage budget.
Well none of these help my bottom line directly so my boss will not approve.
Software that is not open source, is proprietary software. Open weight models, are not open source. Binary blobs in a repo with an Apache license, is not open source.
Am I a retro-grouch? Probably. I guess it doesn't matter anymore what I think about it.
Since when? Open source projects have for decades offered paid support. Projects like Red Hat, Snort, Security Onion and others. I don't know anyone that has ever thought this. It's always been generally accepted that someone has to support it, either paid professional services or a full time employee with expertise.
The copyright and IP maximalism approaches aren't important to me. The world where everyone can have software written easily is much more appealing. The user freedom is better met.
The enthusiasm and optimistic view of open source and the future of software and craftsmanship. Looking at it in 2026.. incredibly sad.
Forget the bazaar. Back to the cathedral.
Either the LLM public capability is not sufficient to positively contribute, or it is.
If it is not sufficient to positively contribute, open source projects become drowned in low quality contributions.
If it is sufficient to positively contribute, we end up with multiple implementations of open source projects.
Actually maybe it only goes one way.
An OCD dream but you need to embrace it and configure it or you would get "AI slop".
Trying to explain how the global economy and welfare of most of humanity is hugely dependent on free software production labor, without the advent of actually seeing a world where this actually happens, is just like when we try to explain something like consciousness. There is no explanation that makes sense. So predictions about new avenues of doom (like "MIT licensing was a huge mistake! we should have all been GPL!") similarly dont carry a lot of weight, because of course these predictions make perfect sense in the abstract, yet real world results don't line up at all.
Basically open source software is an emergent phenomenon, like consciousness or evolution, or perhaps even how very large language models suddenly seemed like real people. It's something that would never be predictable in its own absence, which means it will remain largely unpredictable how it will respond to ongoing changes such as "the open source authors and contributors now use programs themselves to produce more code".
Eh yes and no. The problem is I am not somebody who is comfortable building their own software, so I depend on the generous communities that create free, open source software I can reliably run on my computer. There are lots of people like me! So the benefit isn’t being able to adjust the software to my liking, it’s the knowledge that I can’t have the rug pulled out from under me as easily since I know in theory I can run the software locally, but realistically (hopefully!) somebody else is going to fork and maintain it.
I guess these are not the top items in the societal problems list, but they really don't help.
I keep a directory of open-source alternatives and just in the past month, I've replaced applications I've used for years with open-source alternatives.
Here's my thoughts on this. It's back to open source, not open maintainer or open usage. I am producing lots of new code, i am publishing it. I am NOT interested in starting a project or having other people contribute. It's a cambrian explosion, the cost of adding features is basically zero. I'm going with "patching software is more common and we need tools around patching" rather than using other peoples stuff, just take what you want and fix it.
One stupid one is XRDP required some hack to go through VNC to connect to an existing session. I now have it built into xrdp and lets you pick the X11 session you on dial up and you're good to go. Why is this not a feature I dont know, but xrdp does it all now without vnc or anything. good stuff. i published it sure, i dont care if anyone uses it though.
That is neither the incentive of AI companies nor the truth.
Availability of Open Source where stealing and illegal relicensing is not being litigated, is a perfect ecosystem for AI to work in.
Maintainer exhaustion is totally a secondary effect, not intended. The maintainer economy was already not working out, AI amplified the asymmetry at play.
People are applying that label to anything that has the taint of AI on it. I get why.
I realize there are a lot of reasons why people hate AI, but one that is frequently cited is that it's dehumanizing. It's kind of ridiculous to see those same sort of people call something "slop" when I've put tens of hours into guiding the AI tooling. Talk about dehumanizing!
a deterministic build system for prompts is a called a compiler.
The commits are in my fork if anyone wants them but I can’t imagine why anyone would.
On the other hand a couple weeks ago I found an annoying bug in a coding agent project and had my agent fix it. It was a very small fix so I could tell it was correct with very little effort. I didn’t open a PR because that required a vouch, but I documented an issue (mostly on my own) and included the patch. I also referenced it in a downstream issue. Then I went to bed. The next morning, I saw a note from downstream thanking me - they’d updated to latest version and the issue was fixed.
The projects bot had reproduced the issue based on my description, tested the fix, validated it, and opened a PR. The maintainer merged it an hour later (it was two lines and obviously correct - easy call with the bots validation) and released it.
It felt like progress.
(Also, I'm never gonna give up my em dashes.)
This recently happened with solvespace (I am a maintainer). Someone posted a link to a fork with a bunch of goodies added. I think they just had AI implement some big features that had already been discussed and were either rejected or far future/maybe. That fork still exists but looks to be dead, as there hasn't been any new development since it first appeared. I had a good look at all the commits but I don't see any that I really want to grab as-is. Some of it looked a bit promising though.
I recommend you at least make upstream aware of your fork if there is anything in it that they might want.
They’re killing “programmer”, not “code”.
> I don't see how they wouldn't take out open source with it as a consequence
An analogy: the automobile industry sought to make working horses redundant, not to go door-to-door and kill horses. Horses getting chopped was an indirect economic consequence.
> If nobody even looks at code why would anyone bother to publish a library, much less care about making it maintainable?
For the exact same reasons as before. Agentic programming still integrates well with the existing ecosystem; I’ll tell agents which libraries to use, so I know what to expect.
While I don’t read the implementation of anything any more unless there’s a hard algorithmic problem, I do make an effort to read and document APIs thoroughly.
Interfacing is exactly the same, it’s just agents doing it.
> if everybody is vibe coding how long before your "average" dev has no idea what a library even is or why you'd want one?
That is a very good question.
Note: I can’t code. Not a line.
While, simultaneously, an abundance of slop is being made.
The narrative is not friendly to communities of people owning complex software by sharing work now, but neither was it then. If you believe it was all wrong, an incorrect formulation, then disregard it and do not despair to move on. If you think ESR got something right that nobody can see anymore, then your hope should be rooted in the knowledge of how much less than what's possible we are currently achieving
I've known many people who have thought that. None of them were programmers, and many of them were managers.
But the flipside is of course users that are clueless won't now be stopped by "can't make a PR", they will throw prompt at AI and send it when the AI decides it's good enough
Adding features was always the easy part. Maintaining the code OTOH is not going to be easier.
I see this with an experimental project I’m consciously vibecoding. The code base tends towards a spaghetti coded mess.
Of course you can put in some refactoring prompts and the AI will reorganize the code. But that makes it worse actually.
You have no mental model of the code and after a large refactoring even less.
Both of these are true: we’re witnessing an unprecedented amount of slop, while also the tools get better and better.
So when talking about Open Source maintainer exhaustion, it’s because of the slop, not because of the great tooling.
AI is an amplifier, and in this case it amplifies the great asymmetry between contributor and maintainer.
There has been ever increasing consolidation in the hardware world along with an ever growing acceptance of restrictions by the public 'for our safety'.
Everything that everyone who believed in free software worked towards is being destroyed. There is no way to fight back unless we figure out how to fab computers in garages. It was all for nothing. The future is bleak.
And I’m testing Helium Browser[2]. It’s based on Chromium, but has changed a lot under the hood and I’ve been daily driving it.
Also replacing CapCut with OpenCut[3].
I’ve also completely ditched Codex CLI with Pi[4] and now am trying OMP[5].
0. https://github.com/ospfranco/sol
1. https://github.com/SuperCmdLabs/SuperCmd
2. https://github.com/imputnet/helium
3. https://github.com/OpenCut-app/OpenCut
Kind of like going to the app store and picking the app with the most downloads because the other option is looking at 400 different apps that may or may not do the same thing.
>Gell-Mann Amnesia effect
We're very familiar with this effect when it comes to the news, but since a lot of people are now looking at older information as some kind of escape it seems prudent to point out that old books themselves are of varying quality.
Moreso, how do you track said quality of old books in the modern age where their will be incentives to game the system (for example those that own publishing rights to said books). Some books will be high quality, but the information in them will be outdated due to changes in understanding. Other books might as well have been written by AI and transported to the past they hold so many bullshit claims.
The pareto distribution will cover the most popular books, but once you step into the long tail of research you've hit another no mans land of is it true or not.
I'm curious how you found my comment mentioning TypeWhisper.
I was also wondering about clarification about the apple speech services. Because in the app it says they are on device (I have an m series Mac latest version) but in keyboard settings in MacOS it says many things would be shared with Apple.
It's not a huge issue because I'll just use that other model, which is fantastic, but I'm curious.
The structural fragility of modern software engineering is intimately bound to the legal frameworks we designed to protect it. Our current licensing models have inadvertently created an extraction economy, forcing a critical re-evaluation of the foundational philosophies separating "permissive" open-source licenses (such as MIT and Apache) from copyleft agreements (like the GPL).
The historical consensus championed permissive licensing as the ultimate catalyst for widespread software adoption. By reducing friction and stripping away compliance barriers, licenses like MIT and Apache allowed code to propagate globally.
Yet this friction-free distribution became a double-edged sword. One participant at the retreat noted that permissive licensing was a profound collective mistake, serving as a legal mechanism that enabled the world’s largest corporations to cannibalize volunteer labor, transforming independent maintainers into unpaid, load-bearing pillars of multi-billion-dollar enterprise infrastructures.
The alternative — restrictive or dual-licensing models — frequently introduces an entirely different set of operational failures:
The procurement bottleneck. Attempting to protect code via non-commercial or "free for hobbyists" clauses often serves as a death sentence for project adoption. One practitioner shared that restricting a project to non-monetized use completely paralyzed its growth. Corporate developers abandoned the tool entirely, not due to a lack of utility, but because the licensing shift triggered complex enterprise procurement reviews and administrative paperwork that engineers simply refused to navigate.
The corporate boycott. Even when dual-licensing thresholds are calibrated carefully, such as Akka’s transition to a license targeting organizations with over $100 million in revenue, enterprises routinely choose boycott over compliance. In one cited case, an enterprise explicitly chose to abandon a critical dependency it could easily afford, purely to avoid setting a precedent of paying the open-source community.
The enforcement burden. For some purists, any license restriction introduces an administrative liability. From this perspective, adding commercial restrictions forces the maintainer to become an enforcer, transforming an act of creative expression into a legal chore.
Bypassing by reimplementing software. Not only is this ethically dubious (although some may disagree), there are also practical issues here: reimplementing requires time and money and may also introduce new security or reliability issues.
The industry has largely collapsed the distinction between software that’s free to change and software that’s free at the point of consumption — what’s often described as the difference between ‘free beer’ and ‘free speech’.
The open-source definition originally emerged precisely because traditional free software was not deemed business-friendly enough. By optimizing entirely for business friendliness, we’ve arrived at a landscape where corporate patronage is treated as an optional charity rather than a fundamental structural obligation.
Compounding this crisis is the emotional and psychological toll levied on maintainers who attempt to correct course. When a load-bearing project undergoes a defensive licensing shift, the community response is frequently hostile. Maintainers face severe reputational and psychological backlash from the very ecosystems they supported for years. We are left with an environment where changing the license is viewed as an act of aggression, while exploiting the license is viewed as standard business practice.