Ahh yes, the fix is to regress to mailing lists...
They kind of did acknowledge this when they said the answer is smaller more trusted circles.
This has been what I look for recently. I prefer projects that are coordinating over discord or similar and have 50-100 total members but with decent activity.
There is also the fact that Maintainers simply don't need contributions any more. This I've noticed also happens at work. Everyone is maintaining their own mini stacks of things. Contribution is up cooperation is down. Why go talk to a colleague when you can talk to Claude? Change is everywhere.
Right, I feel like this is more of the forcing function here rather than generic spam. Open source used to work because operational code was expensive, and it made sense to share. Now, operational code is dirt cheap. Furthermore, you can customize anything to your hearts content now with zero additional effort, so it’s more desirable to make your own solution.
And even if a contribution is helpful (like a feature you hadn’t thought of or a bug you hadn’t encountered) you’re better off writing the change yourself.
Something that I've noticed within the modded Minecraft community I'm a part of is that it's highly iterative, and upstreaming is exceptionally rare. Each server is a fork, or a fork of a fork, etc, functioning more like a family tree. It's typical for multiple servers to encounter the same (or similar) problems and create their own solutions.
There was an attempt to start upstreaming changes but it immediately failed: whoever owns upstream will naturally want a say in what gets upstreamed. The best case scenario is that you're creating a whole bunch of work for yourself to conform your code to whatever arbitrary requirements upstream demands or; the worst case is that you've effectively ceded control over what gets run on your server. But that begs the question: why doesn't upstream just pull from downstream? It's all open source... yet it almost never happens.
This has gotten worse in that servers are no longer accepting many (if any) code contributions anymore, instead relying on in-house developers. In a sense, these mods are no longer open source, but rather source available. The vast majority of updates come when the sole dev-admin has one of those code-binge days.
I think something similar is happening here, with open source more generally, particularly with the advent of AI: any outside contribution is just creating work for you, so you might as well go to an LLM where all your particular preferences can be met without complaint, and without much delay.
Thanks for that perspective! I think that dynamic is present in quite a lot of other communities too, especially the ones who have not traditionally embraced open source. You also see it a lot around creative / artsy work where it almost seems to be a faux pas to share anything but the final product. People do recreate things or just are inspired by other work. Coming from open source software it always seemed like wasted potential to me, but that's probably just my bias.
> In a sense, these mods are no longer open source, but rather source available
I understand what sense you mean, but the terms "open source" and "source available" have very clear definitions, and it has nothing to do with accepting contributions or not, only with the license the code is published under. So in a sense only about downstream effects; upstream effects are still a courtesy also with open source.
Cheap development is not equal to cheap maintenance. It is easy to generate the code but verification, acceptance criteria, documentation and maintenance are the real cost.
I could not imagine the pain being being the head of a Libre/Open project nowadays.
It used to suck when there was almost nobody contributing because it felt isolated. Worse was if your project did become popular, you would be managing loads of code AND spending loads of time managing the community than the code.
Nowadays, you probably don't have the community to push back and converse with, just a flood of code with few people you can't actually question it with. So back to isolation but with a million lines of code.
It feels like you would have to have a project with an direct artificial limit to increase the quality of submissions. Like, all submissions must be able to run on a 486 25Mhz and 4MB of RAM, this would keep the code small and manageable. Don't do that, but you get the idea.
Why not? I've been at workplaces where a PR needed to be less than X lines of code without approval from some skip level contributor vouching for it. It's usually an absurdly high limit that you'd realistically never hit in a legacy codebase, but maybe that limit would work fine to filter out massive vibecode PRs.
The goal wasn't to add bureaucracy, but to stop this precise problem: stopping a potentially rushed engineer from pushing in a massive change without oversight. Even large, quality PRs can cause all kinds of long term maintenance issues down the line, so I have no clue why vibecode is getting such grace.
The old hardware approach is still king when it comes to effortlessly catching someone "optimizing" something in a way that will break again in just a few generations of whatever Intel is doing. Unfortunately 486 is now gone from linux upstream (better/worse: all TSC-less or CX8-less cpus are dropped).
I get why project like Linux do that, it allows them to drop some old code and provide optimizations for more modern processors without having to worry about 30 year+ legacy chips, but you do lose something with that.
At least, others usually take up the job and keep it going with a fork.
I quite like the idea though... I would love to see a real resurgence in retro computing app development that actually brings it all past the "niche of a niche" stage. Even if it's just "make this fast on a XX MHz CPU" and not even targeting a retro OS... embedded could use a lot of extra talent there too.
After all, restrictions are exactly what sparks creativity in people.
I also think the Linux desktop could definitely do with a lot more restriction, which would also help with the decision paralysis people are often faced with.
> Nowadays, you probably don't have the community to push back and converse with
Why do you think this? People still use open source software and most of them don't immediately turn to a LLM if things aren't working for them, or they want additional features. They have to ask.
What has changed immensely is support. Stack Overflow sites are dead. Forums still get traffic but the impetus to sign up used to be "help me!". LLMs are doing all this work now.
The drive is going remain engaging with people, getting donations, taking about stuff. But I suspect the route into these communities is going to have to evolve.
The last couple of months I've found it easier to just open up the Hermes app on my phone and just tell it to clone a project and build my features into it and then build the app and push it to my phone. 99% of the time I don't bother upstreaming my changes. If it's a project I use regularly I typicallt send the creator $25-50 for all the work they put into the project and for making it open source.
I think this will become commonplace over the next decade, the ability to customize something to your own needs within minutes is immensely powerful once you learn that it's possible to do.
It sounds like part of the problem is that AI tools are machine generated content acting like humans in a comment forum designed for humans. GitHub already has a variety of CI tools which generate huge volumes of machine generated text, and that text is appropriately buries for those that want it without spewing all of it in a developer’s discussion forum.
While it is more challenging to stop genuine imposters, we could also add new features to places like GitHub so that maintainers who do run automated tools can make automated analysis available to PR creators without drowning out human discussion threads. It sounds like part of the problem is that new tools have popped up so fast that we haven’t figured out how to integrate them properly yet.
I think the answer is straightforward. You complain that a substantial PR is no longer evidence of good faith. What is evidence? Participation in the community.
I think mailing lists (or an equivalent) are coming back. In a big way.
> It was the people. It was fixing a typo in a README and having someone say thanks. It was a stranger on the other side of the world finding a bug in my code and sending a fix before I'd even woken up.
All of this still happens in a world where people aren’t typing the individual code lines by hand.
You just have to adjust and move on. Don’t let your code quality decrease, fight off those that submit vibe coded bullshit and push forward. You’ll find there’s people still behind the prompts.
It’s not totally equivalent but there was a time where all programmers wrote assembly or the like. They’d look at JavaScript with disdain if they saw it in their day. Yet people kinda just.. moved on.
I personally find it better than ever, even with the current issues outlined in the post. We'll work through them, the linux kernel team has, the rest of us can too. But never has been easier to work on or hack up unfamiliar projects to learn from, build on, and extend. Many projects have more refined features with fewer bugs. It's not all bad stuff happening.
There was a time before programming, hacking, open source, and related communities. These things did not exist even 60 years ago. There will be a time after them, and we’ll move on to something else.
open source as the name suggests has never been unambiguously about open contribution. It's the code that's open, not the automatically the community that builds it. SQLite is sometimes brought up for its idiosyncratic developer code of conduct. Openness especially of very popular software with high reliability requirements has usually been on the user side.
I'm not too surprised by the recent problems but I see them as intensifications, not a new problem. As development platforms became larger, low quality contributors and people who wanted something on their CV became more and more common. That there's never been any kind of trust system makes these issues inevitable.
We just banned gen-AI PRs, it seems to be working so far.
Commercial dev is about results and money, and that makes AI almost impossible to resist.
OSS has always been about process. The pleasure is in tinkering with code, collaborating with friends on a fun new idea, and helping people. I don't care about speed.
One has to hope that this is mostly just the "uncanny valley" of AI as it climbs up the ladder of general intelligence.
At some point I think AI technology available to us will be advanced enough that "slop" is largely a thing of the past. Some of the issues here will still remain, but hopefully at that point a PR review could be largely automated, in a trustworthy way.
Ah, is it September[0] again already? Yes, our fun little clubs get popular, and the posers move in, and they're cheating or, well, they're not really cheating per se, but they're just no fun to play with, and they seem to be having fun without us, so we're going to take our ball and go home.
I can't really blame anyone involved in either side of the equation--Sindre Sorhus doesn't blame AI, and OP doesn't blame maintainers--this is just the natural evolution of.. everything! That which does not go extinct... evolves.
Part of me is wondering, maybe it’s time for part of open source to move from code to just words or prose? Since it’s possible to use AI to fix bugs and add features arguably more easily than before, what we could share with each other are ideas, thoughts, additions to each other’s prompts or skills that could be reviewed by the community.
And in this case carefully crafted, clear, and expressive words that are not too verbose would be the contributions of tomorrow.
I keep going back to LLM Wiki. It has found itself in so many other skills because of its fundamental value. Maybe we don’t have as many pull requests. But that one skill has proliferated in so many other skills because of its value.
> We are now instructing our agents to leave comments, having the agents respond to those comments, even long threads where the agents debate technical decisions either both human author and human reviewer almost totally removed from the loop.
I'm sorry, this is totally ridiculous. Agents can't "debate" or have an opinion any more than your toaster can. They will generate opposing views of whatever you ask them to, regardless of its merit.
I’m starting to think the ones that “adapt” the most are the ones most likely to burn out, as their productivity collapses under the weight of code and related artifacts that neither they nor their “interns” are qualified to understand.
My project exists for the concrete purpose of helping the community get things done, not for the abstract goal of making good software. (It actually isn't very good software, to be honest.)
If you're a real human being who needs help fixing a bug or implementing a feature, I will gladly take the time to help you. But if you're a bot that is just trying to tidy up my software in accordance with some ideal design pattern, unrelated to the specific needs of any human being, then you can just go help yourself.
Open source projects have had gatekeeping mechanisms for decades. Remember ESR's popular (and exaggerated) posts about how to fit in with hacker communities? It's the same thing. New contributors must prove that they know how to be a good member the community they're trying to enter. There is no abstract ideal of openness-to-all that we must somehow all strive for. Follow the needs of the actual community that you care about. Don't feel sorry for spammers.
It's sad when a technology so thoroughly changes what you love. It's life as a human I guess. I hope people like this can still find a way to enjoy themselves, differently. Usually humans do, given time.
I dunno. I've been making free software for 3 decades and I still think it's fun. While I do get slop PRs sometimes, it's not frequent. And when I want to land a patch in someone else's project, I haven't really been having difficulty doing so.
The main change for me has been... if I want to send someone a patch, it's more important now to talk to them about it first. But I was doing that anyway. Join the chatroom, let people know I found an issue and am working on fixing it, maybe get their advice on how they think it should be solved (to make sure it fits with their project and goals), and then send code. And stick around to help with testing and stuff. It's not much different than how things were before everything moved to GitHub.
Talk to people. Be a part of the community. That's what made free software work in the past, and it's what makes free software work now. As the article said, it was never just the code.
52 comments
[ 1.6 ms ] story [ 17.5 ms ] threadThey kind of did acknowledge this when they said the answer is smaller more trusted circles.
This has been what I look for recently. I prefer projects that are coordinating over discord or similar and have 50-100 total members but with decent activity.
There was an attempt to start upstreaming changes but it immediately failed: whoever owns upstream will naturally want a say in what gets upstreamed. The best case scenario is that you're creating a whole bunch of work for yourself to conform your code to whatever arbitrary requirements upstream demands or; the worst case is that you've effectively ceded control over what gets run on your server. But that begs the question: why doesn't upstream just pull from downstream? It's all open source... yet it almost never happens.
This has gotten worse in that servers are no longer accepting many (if any) code contributions anymore, instead relying on in-house developers. In a sense, these mods are no longer open source, but rather source available. The vast majority of updates come when the sole dev-admin has one of those code-binge days.
I think something similar is happening here, with open source more generally, particularly with the advent of AI: any outside contribution is just creating work for you, so you might as well go to an LLM where all your particular preferences can be met without complaint, and without much delay.
> In a sense, these mods are no longer open source, but rather source available
I understand what sense you mean, but the terms "open source" and "source available" have very clear definitions, and it has nothing to do with accepting contributions or not, only with the license the code is published under. So in a sense only about downstream effects; upstream effects are still a courtesy also with open source.
It used to suck when there was almost nobody contributing because it felt isolated. Worse was if your project did become popular, you would be managing loads of code AND spending loads of time managing the community than the code.
Nowadays, you probably don't have the community to push back and converse with, just a flood of code with few people you can't actually question it with. So back to isolation but with a million lines of code.
It feels like you would have to have a project with an direct artificial limit to increase the quality of submissions. Like, all submissions must be able to run on a 486 25Mhz and 4MB of RAM, this would keep the code small and manageable. Don't do that, but you get the idea.
Why not? I've been at workplaces where a PR needed to be less than X lines of code without approval from some skip level contributor vouching for it. It's usually an absurdly high limit that you'd realistically never hit in a legacy codebase, but maybe that limit would work fine to filter out massive vibecode PRs.
The goal wasn't to add bureaucracy, but to stop this precise problem: stopping a potentially rushed engineer from pushing in a massive change without oversight. Even large, quality PRs can cause all kinds of long term maintenance issues down the line, so I have no clue why vibecode is getting such grace.
At least, others usually take up the job and keep it going with a fork.
I quite like the idea though... I would love to see a real resurgence in retro computing app development that actually brings it all past the "niche of a niche" stage. Even if it's just "make this fast on a XX MHz CPU" and not even targeting a retro OS... embedded could use a lot of extra talent there too.
After all, restrictions are exactly what sparks creativity in people.
I also think the Linux desktop could definitely do with a lot more restriction, which would also help with the decision paralysis people are often faced with.
Why do you think this? People still use open source software and most of them don't immediately turn to a LLM if things aren't working for them, or they want additional features. They have to ask.
What has changed immensely is support. Stack Overflow sites are dead. Forums still get traffic but the impetus to sign up used to be "help me!". LLMs are doing all this work now.
The drive is going remain engaging with people, getting donations, taking about stuff. But I suspect the route into these communities is going to have to evolve.
I think this will become commonplace over the next decade, the ability to customize something to your own needs within minutes is immensely powerful once you learn that it's possible to do.
While it is more challenging to stop genuine imposters, we could also add new features to places like GitHub so that maintainers who do run automated tools can make automated analysis available to PR creators without drowning out human discussion threads. It sounds like part of the problem is that new tools have popped up so fast that we haven’t figured out how to integrate them properly yet.
I think mailing lists (or an equivalent) are coming back. In a big way.
All of this still happens in a world where people aren’t typing the individual code lines by hand.
You just have to adjust and move on. Don’t let your code quality decrease, fight off those that submit vibe coded bullshit and push forward. You’ll find there’s people still behind the prompts.
It’s not totally equivalent but there was a time where all programmers wrote assembly or the like. They’d look at JavaScript with disdain if they saw it in their day. Yet people kinda just.. moved on.
Nobody cares anymore, because literally everyone on the planet can literally make their own mini stacks of things, as another commenter just said.
It's sad, but I don't see any way to put the bunny back in the box.
At first i thought it was going to be a pure counter-AI rant, but no, the author admits using AI everyday in a variety of ways.
Another argument, maybe OSS of smaller packages is on its way out as we get to generate whatever is needed on the fly?
You said it was dead. How could there be any fix?
I'm not too surprised by the recent problems but I see them as intensifications, not a new problem. As development platforms became larger, low quality contributors and people who wanted something on their CV became more and more common. That there's never been any kind of trust system makes these issues inevitable.
Commercial dev is about results and money, and that makes AI almost impossible to resist.
OSS has always been about process. The pleasure is in tinkering with code, collaborating with friends on a fun new idea, and helping people. I don't care about speed.
At some point I think AI technology available to us will be advanced enough that "slop" is largely a thing of the past. Some of the issues here will still remain, but hopefully at that point a PR review could be largely automated, in a trustworthy way.
I can't really blame anyone involved in either side of the equation--Sindre Sorhus doesn't blame AI, and OP doesn't blame maintainers--this is just the natural evolution of.. everything! That which does not go extinct... evolves.
Or is it the other way around?
0. https://en.wikipedia.org/wiki/Eternal_September
And in this case carefully crafted, clear, and expressive words that are not too verbose would be the contributions of tomorrow.
I keep going back to LLM Wiki. It has found itself in so many other skills because of its fundamental value. Maybe we don’t have as many pull requests. But that one skill has proliferated in so many other skills because of its value.
Google eh
I'm sorry, this is totally ridiculous. Agents can't "debate" or have an opinion any more than your toaster can. They will generate opposing views of whatever you ask them to, regardless of its merit.
My project exists for the concrete purpose of helping the community get things done, not for the abstract goal of making good software. (It actually isn't very good software, to be honest.)
If you're a real human being who needs help fixing a bug or implementing a feature, I will gladly take the time to help you. But if you're a bot that is just trying to tidy up my software in accordance with some ideal design pattern, unrelated to the specific needs of any human being, then you can just go help yourself.
Open source projects have had gatekeeping mechanisms for decades. Remember ESR's popular (and exaggerated) posts about how to fit in with hacker communities? It's the same thing. New contributors must prove that they know how to be a good member the community they're trying to enter. There is no abstract ideal of openness-to-all that we must somehow all strive for. Follow the needs of the actual community that you care about. Don't feel sorry for spammers.
Enabled this feature.
Earlier in the days, PR was better than issue, now, I prefer and issue, as Codex with my guidance can create a much better PR.
The main change for me has been... if I want to send someone a patch, it's more important now to talk to them about it first. But I was doing that anyway. Join the chatroom, let people know I found an issue and am working on fixing it, maybe get their advice on how they think it should be solved (to make sure it fits with their project and goals), and then send code. And stick around to help with testing and stuff. It's not much different than how things were before everything moved to GitHub.
Talk to people. Be a part of the community. That's what made free software work in the past, and it's what makes free software work now. As the article said, it was never just the code.