Small bespoke personalized on the spot apps are the future with LLMs.
The future will absolutely not be "How things are today + LLMs"
The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?
Something I've noticed is that AI code generation makes it easier/faster to generate code while shifting more work of the work of keeping code correct and maintainable to the code review stage. That can be highly problematic for open source projects that are typically already bottlenecked by maintainer review bandwidth.
It can be mitigated by PR submitters doing a review and edit pass prior to submitting a PR. But a lot of submitters don't currently do this, and in my experience the average quality of PRs generated by AI is definitely significantly lower than those not generated by AI.
> When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers entry and sharing, reduces the availability and quality of OSS, and reduces welfare despite higher productivity. Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.
I can't think of even a single example of OSS being monetized through direct user engagement. The bulk of it just isn't monetized at all, and what is monetized (beyond like a tip jar situation where you get some coffee money every once in a while) is primarily sponsored by enterprise users, support license sales, or through grants, or something like that. A few projects like Krita sell binaries on the steam store.
There's some irony in the fact that LLMs are in large part possible because of open source software.
From the tools which were used to design and develop the models (programming languages, libraries) to the operating systems running them to the databases used for storing training data .. plus of course they were trained mostly on open source code.
If OSS didn't exist, it's highly unlikely that LLMs would have been built.
I'm completely blind. I like Linux. I've started to love Android since getting a Samsung and getting rid of OnePlus, cause accessibility. Termux is cool, but it's accessibility wasn't. So, I had Gemini rangle it up a bit into my fork of Termux [1]
Now it reads (usually) only newly incoming text, I can feel around the screen to read a line at a time, and cursor tracking works well enough. Then I got Emacs and Emacspeak working, having Gemini build DecTalk (TTS engine) for Termux and get the Emacspeak DecTalk speech server working with that. I'm still amazed that, with a Bluetooth keyboard, I have Linux, and Emacs, in my pocket. I can write Org and Markdown, read EPUB books in Emacs with Nov.el, look at an actual calendar not just a list of events, and even use Gemini CLI and Claude Code, all on my phone! This is proof that phones, with enough freedom, can be workstations. If I can get Orca working on a desktop environment in Termux-GUI. But even with just Emacs and the shell, I can do quite a bit.
Then I decided to go wild and make an MUD client for Emacs/Emacspeak, since accessible ones for Android are limited, and I didn't trust my hacks to Termux to handle Tintin++ very well. So, Emacs with Emacspeak it was, and Elmud [2] was born.
Elmud has a few cool features. First of all, since Emacspeak has voice-lock, like font-lock but for TTS, Ansi colors can be "heard", like red being a deeper voice. Also a few MUD clients have sound packs on Windows, which make them sound more like a modern video game, while still being text-based. I got a few of those working with Elmud. You just load one of the supported MUD's, and the sound pack is downloaded and installed for you. It's easy and simple. And honestly, that's what I want my tools to provide, something I, or anyone else who chooses to use them, that is easy to get the most out of.
None of this would have been possible without AI. None of it would have been done. It would have remained a dream. And yes, it was all vibe-coded, mostly with Codex 5.2 on high thinking. And yes, the code may look awful. But honestly, how many closed-source programs look just as bad or even worse under the covers of compilation?
I am a huge proponent of using AI tools for software development. But until I see a vibe coded replacement for the Linux kernel, PostgreSQL, gcc, git or Chromium, I am just going to disagree with this premise. If I am on a system without Python installed, I don't see Claude saying, oh, you don't need to download it, I'll write the Python interpreter for you.
Related but not sure how much attention it's getting:
GPL is a dead man walking since you can have any LLM cleanroom a new implementation in a new language from a public spec with verifiable "never looked at the original source" and it can be more permissively-licensed however you wish (MIT, BSD etc).
"validate" is a project that currently validates over 100 file formats at the byte level; its goal is to validate as many formats as possible, for posterity/all time.
Why did I avoid GPL (which I am normally a fan of) since this is open-source? I have an even-higher-level project I'm working on, implementing automatic light parity protection (which can proactively repair data without a RAID/ZFS setup) which I want to make for sale, whose code will (initially) be private, and which uses this as a dependency (no sense in protecting data that is already corrupted).
Figured I'd give this to the world for free in the meantime. It's already found a bunch of actually-corrupt files in my collection (note that there's still some false-positive risk; I literally released this just yesterday and it's still actively being worked on) including some cherished photos from a Japan trip I took a few years ago that cannot be replaced.
It has Mac, Windows and Linux builds. Check the github actions page.
I asked Claude several times to resolve this ambiguity and it suggested various prioritisation strategies etc. however the resulting changes broke other functionality in my library.
In the end I am redesigning my library from scratch with minimal AI input. Why? because I started the project without the help of AI a few years back, I designed it to solve a problem but that problem and nuanced programming decisions seem to not be respected by LLMs (LLMs dont care about the story, they just care about the current state of the code)
I think LLMs also kill off most programming languages. I think we’ll end up with a handful of languages that LLMs most proficient at writing for and the languages required for device or processor compatibility.
The cost improvement for an LLM to emit a feature (with an engineer in the loop) is too much of an improvement. We’ll look at engineers coding in C the same way we look at engineers today who code in assembly. LLM enabled development becomes the new abstraction; probably with a grammar and system for stronger specification formalization.
I believe we will see a new huge wave of useful open source software. However don't expect the development model to stay the same. I was finally able to resurrect a few projects of mine, and many more will come. One incredible thing was the ability to easily merge what was worth merging from forks, for instance. The new OSS will be driven not much by the amount of code you can produce, but from the idea of software you have, how the software should look like, behave, what it should do to be useful. Today design is more important than coding.
Generative AI is a major setback to OSS licensing. I've been on projects where we needed to do a "cleanroom" implementation and vet the team has never viewed the source code of competing products. Now in the gen AI era, coding agents are IP laundering machines. They are trained on OSS code, but the nuances of the original licenses are lost.
On the whole, I think it is a net gain for civilization, but if we zoom into OSS licensing... not good.
Does it seem to anyone else that author's have created a definition for 'vibe coding' that is specifically designed to justify their paper? Also that their premise is based on the assumption that developers will be irresponsible about the use of these tools ("often without users directly reading documentation, reporting bugs, or otherwise engaging with maintainers") so that it would actually be people killing open source not 'Vibe Coding'? Just a guess on my part, but once developers learn to use these tools and we get over the newness I think this will be great for open source. With these tools open source projects can compete with an army of corporate developers while alleviating some of the pressure on overworked under-rewarded maintainers.
No problem! Just give the agents the ability to autonomously report issues, submit patches, and engage with library authors. Surely nothing can go wrong.
As the maintainer of a handful of small projects, what I have seen for better or worse is tickets and pull requests completely dry up.
My guess is instead of Googling "library that does X" people are asking AI to solve the problem and it's regurgitating a solution in place? That's my theory anyway.
I am not sure if it kills open source, but it probably kills open core. You can just take a project like GitLab and ask an LLM, conveniently trained on the GitLab enterprise edition source code, to generate you a fresh copy of whatever features of EE you care about, but with the license laundered.
I think it is not killing opensource. It is changing it. There are more smaller scoped projects created for specific purposes instead of creating a huge project that has gazillion features supporting everything. At least this is my experience.
Open source software, by the admission of this article, is a critical input to AI agents useful for code generation. So the way I see it is that there is now an entire industry that is incentivized to financially support open source software for entirely new reasons. To keep the models trained on new languages, libraries, and developments in computer science, they need to make sure that high quality modern code is still freely available, forever.
Vibe coding eventually creates more value for FOSS, not less.
Vibecoding is great for open source. Open source is already dominated by strong solo programmers like antirez, linus, etc. People with very strong motivations to create software they see as necessary. Vibecoding makes creating open source projects easier. It makes it easier to get from an idea to "Hey guys check this out!" The only downside to open source is the fly by PRs vibecoding enables which are currently draining maintainer time.
Not an answer to all of our problems, but I wonder if we will see a wider adoption of more complex contribution models. Like "Lieutenants Workflow" Linux was known for, for example. Many possible workflows are explored in the Git Book [1].
All this talk about how you can vibecode all your apps now, "why use OSS?" is making me laugh. Sure for a little website or a small tool, maybe even a change to your somewhat complex codebase that you thoroughly check and test.
Is anyone replacing firefox, chromium, postgres, nginx, git, linux, etc? It would be idiotic to trade git for a vibe coded source control. I can't even imagine the motivations, maybe "merges the way I like it"?
Not sure, but anyone who's saying this stuff hasn't even taken the basic first level glance at what it would entail. By all means, stop paying $10 a month to "JSON validator SaSS", but also don't complain with the little niggling bugs, maintenance and organization that comes with it. But please stop pretending you can just vibe code your own Kafka, Apache, Vulkan, or PostGRES.
Yes, you can probably go faster (possibly not in the right direction if inexperienced), but ultimately, something like that would still require very senior, experienced person, using the tool in a very guided way with heavy review. By why take on the maintenance, the bug hunting, and everything else, unless that is your main business objective?
Even if you can 10x, if you use that to just take on 10x more maintenance, you haven't increased velocity. To really go faster, that 10x must be focused on the right objective -- distinctive business value. If you use that 10x to generate hundreds of small tools you now have to juggle and maintain, that have no docs or support, no searchable history of problems solved, you may have returned yourself to 1x (or worse).
This is the old "we'll write our own inhouse programming language" but leaking out to apps. Sure, java doesn't work _exactly_ the way you want it to, you probably have complaints. But writing your own lang will be a huge hit to whatever it was you actually wanted to use the language for, and you lose all the docs, forums, LSP / debugging tools, ecosystem, etc.
Looking for solo devs testing AI continuation tool which i have built and need honest feedback if it is usefull or garbage if you are intersted in checking out - DM me
I think corporate cloud killed opensource, AI is simply a nail in its coffin. OpenAI's recent announcement did more for software patents than anyone could have ever done when they floated they own of your ideas.
I think corporate cloud killed opensource, AI is simply a nail in its coffin. OpenAI's recent announcement did more for software patents than anyone could have ever done when they floated thy own of your ideas.
This study seems flawed at the assumptions and from the start
"most" maintainers make exactly zero dollars. Further, OSS monetization rarely involves developer engagement, it's been all about enterprise feature gating
I reject the assertion that AI Vibe Coding has to have any affect on how OSS maintainers get paid (or not). Most of those that are paid, are paid because their job is related but the OSS library/project itself is not directly monetized. I don't see AI/Vibe coding changing this... except that now the maintainer can choose or not to accept or use those tools on their project or not.
But the assertion that everything needs to change is absurd. Articles like this are similar in my mind to arguments for communism because every artist deserves a living wage... that's just not how society can sustain itself in reality. Maybe in a world without scarcity, but I don't see scarcity going away any time soon.
On the contrary, I hope vibe coding revives Linux desktop into a truly usable platform.
e.g. Vibe coding defeats GNOME developers' main argument for endlessly deleting features and degrading user experience - that features are ostensibly "hard to maintain".
Well, LLMs are rapidly reducing development costs to 0.
The bottleneck for UI development is now testing, and here desktop Linux has advantage - Linux users have been trained like Pavlov's dogs to test and write detailed upstream bug reports, something Windows and macOS users just don't do.
I wonder how many OSS projects are using AI to actively squash bugs so their projects are more rock-solid than before.
Also, seems to me if your project underwent a full AI standardized code-quality check (using 2 or 3 AI models), it would be considered the "standard" from which other projects could use. For example, if you needed a particular piece of code for your own project, the AI tooling could suggest leveraging an existing gold-standard project.
"Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns."
I think the title is clickbait.
The conclusion is:
"Vibe coding represents a fundamental shift in how software is produced and consumed. The productivity gains are real and large. But so is the threat to the open source ecosystem that underpins modern software infrastructure. The model shows that these gains and threats are not independent: the same technology that lowers costs also erodes the engagement that sustains voluntary contribution."
The dangers I see rather in projects drowning in LLM slop PR's, instead of less engagement.
And the benefits of LLMs to open source in lowering the cost to revive and maintain (abandoned) projects.
I have written so many small scripts and apps that do exactly what I want. The general purpose OSS projects are always a compromise. I believe if LLMs mature some more years we will see a decline in these general purpose projects and will see a rise in personal apps. I dont think its something to worry about.
I think vibe coding would greatly struggle with large open source projects unless your planning was exceptional and your comments on optimal coding style was exceptional, however...... For those small open source tools that many of us use daily and find invaluable, I actually think vibe coding is ideal for that. It can make a functional version quickly and you can iterate and improve it, and feel no loss for making it free to use.
I was very sceptical but I will admit I think vibe coding has a place in society, just what it is yet is still to be determined. It can't help most for sure but it can help some in some situations.
It is effective but once cost of creating something is down, then you have less reason to collaborate and depend on each other vs asking your own LLM to build your own bubble.
When paired with new-found cognitive laziness and lack of motivation when you then use no AI it's not sure of the second order effects.
There's a balance between coding by hand and vibe coding that is important. The less you understand the code, the more boring maintaining the software becomes. It's OK for throw away code, but not for serious open source projects. Use it as a powerful tool rather than your replacement.
> When OSS is monetized only through direct user engagement (...) Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.
interesting as an econ thought experiment .. but it assumes OSS revenue comes from direct developr engagement .. In practice .. most successful OSS is funded by enterprises .. cloud vendors .. or consulting engagements .. where broader adoption, including AI mediated usage, often increases demand of said OSS project
I don't really read papers and haven't read this one either but that summary.
> In vibe coding, an AI agent builds software by selecting and assembling open-source software (OSS),
Are they talking about indirectly due to prior training of the model? No agent I use is selecting and assembling open source software. That's more of an integration type of job not software development. Are they talking about packages and libraries? If yes, that's exactly how most people use those too.
I mean like this:
> often without users directly reading documentation, reporting bugs, or otherwise engaging with maintainers.
and then,
> Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns.
Maintainers who earn "returns" must be such a small niche as to be insignificant. Or do they mean things like github stars?
> When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers entry and sharing, reduces the availability and quality of OSS, and reduces welfare despite higher productivity.
Now the hypothesis is exactly the opposite. Do agents not "select and assamble" OSS anymore? And what does this have to do with how OSS is "monetized"?
> Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.
Sustaining OSS insofar as maintainers do it for a living requries major changes. Period. I don't see how vibe coding which makes all of this easier and cheaper is changing that equation. Quality is a different matter altogether and can still be achieved.
I am seeing a bunch of disjointed claims taken as truth that I frankly do not agree with in the first place.
What would the result of such a study even explain?
For me spending time on my open source projects doesn't make sense anymore.
People (the community and employers) previously were impressed because of the amount of work required. Now that respect is gone as people can't automatically tell on the surface if this is a low effort vibe code or something else.
Community engagement has dropped. Stars aren't being given out as freely. People aren't actively reading your code like they use to.
For projects done before llms you can still link effort and signal but for anything started now.. everyone assumes it's llm created. No one want to read that code and not in the same way you would read other humans. Fewer will download the project.
Many of the reasons why I wrote open source is gone. And knowing the biggest/only engagement will come from llms copying your work giving you no credit.. what's the point?
perhaps also more forking (not only absolute but also relative)
contribution dynamics are also changing
I'm fairly optimistic that generative ai is good for open source and the commons
what I'm also seeing is open source projects that had not so great ergonomics or user interfaces in general are now getting better thanks to generative ai
this might be the most directly noticeable change for users of niche open source
Vibe coding kills open source
(arxiv.org)316 points by kgwgk 26 January 2026 | 275 comments
Comments
The future will absolutely not be "How things are today + LLMs"
The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?
It can be mitigated by PR submitters doing a review and edit pass prior to submitting a PR. But a lot of submitters don't currently do this, and in my experience the average quality of PRs generated by AI is definitely significantly lower than those not generated by AI.
I can't think of even a single example of OSS being monetized through direct user engagement. The bulk of it just isn't monetized at all, and what is monetized (beyond like a tip jar situation where you get some coffee money every once in a while) is primarily sponsored by enterprise users, support license sales, or through grants, or something like that. A few projects like Krita sell binaries on the steam store.
From the tools which were used to design and develop the models (programming languages, libraries) to the operating systems running them to the databases used for storing training data .. plus of course they were trained mostly on open source code.
If OSS didn't exist, it's highly unlikely that LLMs would have been built.
Now it reads (usually) only newly incoming text, I can feel around the screen to read a line at a time, and cursor tracking works well enough. Then I got Emacs and Emacspeak working, having Gemini build DecTalk (TTS engine) for Termux and get the Emacspeak DecTalk speech server working with that. I'm still amazed that, with a Bluetooth keyboard, I have Linux, and Emacs, in my pocket. I can write Org and Markdown, read EPUB books in Emacs with Nov.el, look at an actual calendar not just a list of events, and even use Gemini CLI and Claude Code, all on my phone! This is proof that phones, with enough freedom, can be workstations. If I can get Orca working on a desktop environment in Termux-GUI. But even with just Emacs and the shell, I can do quite a bit.
Then I decided to go wild and make an MUD client for Emacs/Emacspeak, since accessible ones for Android are limited, and I didn't trust my hacks to Termux to handle Tintin++ very well. So, Emacs with Emacspeak it was, and Elmud [2] was born.
Elmud has a few cool features. First of all, since Emacspeak has voice-lock, like font-lock but for TTS, Ansi colors can be "heard", like red being a deeper voice. Also a few MUD clients have sound packs on Windows, which make them sound more like a modern video game, while still being text-based. I got a few of those working with Elmud. You just load one of the supported MUD's, and the sound pack is downloaded and installed for you. It's easy and simple. And honestly, that's what I want my tools to provide, something I, or anyone else who chooses to use them, that is easy to get the most out of.
None of this would have been possible without AI. None of it would have been done. It would have remained a dream. And yes, it was all vibe-coded, mostly with Codex 5.2 on high thinking. And yes, the code may look awful. But honestly, how many closed-source programs look just as bad or even worse under the covers of compilation?
[1] https://github.com/devinprater/Talking-termux-app
[2] https://github.com/devinprater/elmud
GPL is a dead man walking since you can have any LLM cleanroom a new implementation in a new language from a public spec with verifiable "never looked at the original source" and it can be more permissively-licensed however you wish (MIT, BSD etc).
case in point, check out my current deps on the project I'm currently working on with LLM assist: https://github.com/pmarreck/validate/tree/yolo/deps
"validate" is a project that currently validates over 100 file formats at the byte level; its goal is to validate as many formats as possible, for posterity/all time.
Why did I avoid GPL (which I am normally a fan of) since this is open-source? I have an even-higher-level project I'm working on, implementing automatic light parity protection (which can proactively repair data without a RAID/ZFS setup) which I want to make for sale, whose code will (initially) be private, and which uses this as a dependency (no sense in protecting data that is already corrupted).
Figured I'd give this to the world for free in the meantime. It's already found a bunch of actually-corrupt files in my collection (note that there's still some false-positive risk; I literally released this just yesterday and it's still actively being worked on) including some cherished photos from a Japan trip I took a few years ago that cannot be replaced.
It has Mac, Windows and Linux builds. Check the github actions page.
However trying to get it to do anything other than optimise code or fix small issues it struggles. It struggles with high level abstract issues.
For example I currently have an issue with ambiguity collisions e.g.
Input: "California"
Output: "California, Missouri"
California is a state but also city in Missouri - https://github.com/tomaytotomato/location4j/issues/44
I asked Claude several times to resolve this ambiguity and it suggested various prioritisation strategies etc. however the resulting changes broke other functionality in my library.
In the end I am redesigning my library from scratch with minimal AI input. Why? because I started the project without the help of AI a few years back, I designed it to solve a problem but that problem and nuanced programming decisions seem to not be respected by LLMs (LLMs dont care about the story, they just care about the current state of the code)
The cost improvement for an LLM to emit a feature (with an engineer in the loop) is too much of an improvement. We’ll look at engineers coding in C the same way we look at engineers today who code in assembly. LLM enabled development becomes the new abstraction; probably with a grammar and system for stronger specification formalization.
On the whole, I think it is a net gain for civilization, but if we zoom into OSS licensing... not good.
My guess is instead of Googling "library that does X" people are asking AI to solve the problem and it's regurgitating a solution in place? That's my theory anyway.
Vibe coding eventually creates more value for FOSS, not less.
[1] https://git-scm.com/book/en/v2/Distributed-Git-Distributed-W...
Is anyone replacing firefox, chromium, postgres, nginx, git, linux, etc? It would be idiotic to trade git for a vibe coded source control. I can't even imagine the motivations, maybe "merges the way I like it"?
Not sure, but anyone who's saying this stuff hasn't even taken the basic first level glance at what it would entail. By all means, stop paying $10 a month to "JSON validator SaSS", but also don't complain with the little niggling bugs, maintenance and organization that comes with it. But please stop pretending you can just vibe code your own Kafka, Apache, Vulkan, or PostGRES.
Yes, you can probably go faster (possibly not in the right direction if inexperienced), but ultimately, something like that would still require very senior, experienced person, using the tool in a very guided way with heavy review. By why take on the maintenance, the bug hunting, and everything else, unless that is your main business objective?
Even if you can 10x, if you use that to just take on 10x more maintenance, you haven't increased velocity. To really go faster, that 10x must be focused on the right objective -- distinctive business value. If you use that 10x to generate hundreds of small tools you now have to juggle and maintain, that have no docs or support, no searchable history of problems solved, you may have returned yourself to 1x (or worse).
This is the old "we'll write our own inhouse programming language" but leaking out to apps. Sure, java doesn't work _exactly_ the way you want it to, you probably have complaints. But writing your own lang will be a huge hit to whatever it was you actually wanted to use the language for, and you lose all the docs, forums, LSP / debugging tools, ecosystem, etc.
"most" maintainers make exactly zero dollars. Further, OSS monetization rarely involves developer engagement, it's been all about enterprise feature gating
---
Concrete example of a no: I set up [1] in such a way that anyone can implement a new blog -> rss feed; docs, agents.md, open-source, free, etc...
Concrete example of a yes: Company spends too much money on simple software.
--- Our Vision ---
I feel the need to share: https://grove.city/
Human Flywheel: Human tips creator <-> Creator engages with audience
Agent Flywheel: Human creates creative content <-> Agent tips human
Yes, it uses crypto, but it's just stablecoins.
This is going to exist in some fashion and all online content creation (OSS and other) will need it.
---
As with everything, it Obvious
[1] https://github.com/Olshansk/rss-feeds
But the assertion that everything needs to change is absurd. Articles like this are similar in my mind to arguments for communism because every artist deserves a living wage... that's just not how society can sustain itself in reality. Maybe in a world without scarcity, but I don't see scarcity going away any time soon.
e.g. Vibe coding defeats GNOME developers' main argument for endlessly deleting features and degrading user experience - that features are ostensibly "hard to maintain".
Well, LLMs are rapidly reducing development costs to 0.
The bottleneck for UI development is now testing, and here desktop Linux has advantage - Linux users have been trained like Pavlov's dogs to test and write detailed upstream bug reports, something Windows and macOS users just don't do.
I think the title is clickbait.
The conclusion is:
"Vibe coding represents a fundamental shift in how software is produced and consumed. The productivity gains are real and large. But so is the threat to the open source ecosystem that underpins modern software infrastructure. The model shows that these gains and threats are not independent: the same technology that lowers costs also erodes the engagement that sustains voluntary contribution."
The dangers I see rather in projects drowning in LLM slop PR's, instead of less engagement.
And the benefits of LLMs to open source in lowering the cost to revive and maintain (abandoned) projects.
I was very sceptical but I will admit I think vibe coding has a place in society, just what it is yet is still to be determined. It can't help most for sure but it can help some in some situations.
A recent discussion on a related topic, apparently following the same misguided idea of how OSS is motivated:
https://news.ycombinator.com/item?id=46565281
(All my new code will be closed-source from now on: 93 points, 112 comments)
> When OSS is monetized only through direct user engagement (...) Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.
so it applies to narrow slice of OSS
> In vibe coding, an AI agent builds software by selecting and assembling open-source software (OSS),
Are they talking about indirectly due to prior training of the model? No agent I use is selecting and assembling open source software. That's more of an integration type of job not software development. Are they talking about packages and libraries? If yes, that's exactly how most people use those too.
I mean like this:
> often without users directly reading documentation, reporting bugs, or otherwise engaging with maintainers.
and then,
> Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns.
Maintainers who earn "returns" must be such a small niche as to be insignificant. Or do they mean things like github stars?
> When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers entry and sharing, reduces the availability and quality of OSS, and reduces welfare despite higher productivity.
Now the hypothesis is exactly the opposite. Do agents not "select and assamble" OSS anymore? And what does this have to do with how OSS is "monetized"?
> Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.
Sustaining OSS insofar as maintainers do it for a living requries major changes. Period. I don't see how vibe coding which makes all of this easier and cheaper is changing that equation. Quality is a different matter altogether and can still be achieved.
I am seeing a bunch of disjointed claims taken as truth that I frankly do not agree with in the first place.
What would the result of such a study even explain?
People (the community and employers) previously were impressed because of the amount of work required. Now that respect is gone as people can't automatically tell on the surface if this is a low effort vibe code or something else.
Community engagement has dropped. Stars aren't being given out as freely. People aren't actively reading your code like they use to.
For projects done before llms you can still link effort and signal but for anything started now.. everyone assumes it's llm created. No one want to read that code and not in the same way you would read other humans. Fewer will download the project.
Many of the reasons why I wrote open source is gone. And knowing the biggest/only engagement will come from llms copying your work giving you no credit.. what's the point?
more open source, better open source
perhaps also more forking (not only absolute but also relative)
contribution dynamics are also changing
I'm fairly optimistic that generative ai is good for open source and the commons
what I'm also seeing is open source projects that had not so great ergonomics or user interfaces in general are now getting better thanks to generative ai
this might be the most directly noticeable change for users of niche open source