SoylentNews is people
SoylentNews
Vibe Coding Is Killing Open Source Software, Researchers Argue:
According to a new study from a team of researchers in Europe, vibe coding is killing open-source software (OSS) and it's happening faster than anyone predicted.
Thanks to vibe coding, a colloquialism for the practice of quickly writing code with the assistance of an LLM, anyone with a small amount of technical knowledge can churn out computer code and deploy software, even if they don't fully review or understand all the code they churn out. But there's a hidden cost. Vibe coding relies on vast amounts of open-source software, a trove of libraries, databases, and user knowledge that's been built up over decades.
Open-source projects rely on community support to survive. They're collaborative projects where the people who use them give back, either in time, money, or knowledge, to help maintain the projects. Humans have to come in and fix bugs and maintain libraries.
Vibe coders, according to these researchers, don't give back.
The study Vibe Coding Kills Open Source, takes an economic view of the problem and asks the question: is vibe coding economically sustainable? Can OSS survive when so many of its users are takers and not givers? According to the study, no.
"Our main result is that under traditional OSS business models, where maintainers primarily monetize direct user engagement...higher adoption of vibe coding reduces OSS provision and lowers welfare," the study said. "In the long-run equilibrium, mediated usage erodes the revenue base that sustains OSS, raises the quality threshold for sharing, and reduces the mass of shared packages...the decline can be rapid because the same magnification mechanism that amplifies positive shocks to software demand also amplifies negative shocks to monetizable engagement. In other words, feedback loops that once accelerated growth now accelerate contraction."
[...] According to Koren, vibe-coders simply don't give back to the OSS communities they're taking from. "The convenience of delegating your work to the AI agent is too strong. There are some superstar projects like Openclaw that generate a lot of community interest but I suspect the majority of vibe coders do not keep OSS developers in their minds," he said. "I am guilty of this myself. Initially I limited my vibe coding to languages I can read if not write, like TypeScript. But for my personal projects I also vibe code in Go, and I don't even know what its package manager is called, let alone be familiar with its libraries."
The study said that vibe coding is reducing the cost of software development, but that there are other costs people aren't considering. "The interaction with human users is collapsing faster than development costs are falling," Koren told 404 Media. "The key insight is that vibe coding is very easy to adopt. Even for a small increase in capability, a lot of people would switch. And recent coding models are very capable. AI companies have also begun targeting business users and other knowledge workers, which further eats into the potential 'deep-pocket' user base of OSS."
This won't end well. "Vibe coding is not sustainable without open source," Koren said. "You cannot just freeze the current state of OSS and live off of that. Projects need to be maintained, bugs fixed, security vulnerabilities patched. If OSS collapses, vibe coding will go down with it. I think we have to speak up and act now to stop that from happening."
He said that major AI firms like Anthropic and OpenAI can't continue to free ride on OSS or the whole system will collapse. "We propose a revenue sharing model based on actual usage data," he said. "The details would have to be worked out, but the technology is there to make such a business model feasible for OSS."
[...] "Popular libraries will keep finding sponsors," Koren said. "Smaller, niche projects are more likely to suffer. But many currently successful projects, like Linux, git, TeX, or grep, started out with one person trying to scratch their own itch. If the maintainers of small projects give up, who will produce the next Linux?"
arXiv link: https://arxiv.org/abs/2601.15494
(Score: 4, Insightful) by JoeMerchant on Monday February 09, @02:30PM (4 children)
I read an article with a similar headline a couple of months back, their premise was: because "Vibe Coding" moves so many projects into the capabilities of a single developer from what had previously been team efforts, those single developers have less incentive to open their code (to get team development participation).
Which I think is a load of bunk. Although, I must admit, when I _first_ started believing in AI agents' ability to help me with a hobby project, I switched briefly from the delusion that my project's open source license would attract development help from the world to the delusion that if I put a closed source license on it I might somehow profit. Both fantasies have no basis in my actual experiences of software devlopment for the past 40 years (and I never bothered to switch the hobby project's license off of GPL...) Your hobby project is your own, regardless of license - nobody is likely to significantly care about it unless you put 10x+ of the work into promotion of the maximum work I have ever put into coding a hobby project. If you want team participation, you need to put effort into team building. If you want commercial sales, you have to promote that while also competing in the open market. License? Virtually irrelevant to outcome for hobby level (Vibe Coding type investment) projects, in my experience.
🌻🌻🌻🌻 [google.com]
(Score: 3, Insightful) by Undefined on Monday February 09, @03:53PM (1 child)
I would mod you to +100 if I could for that.
The level of support for these is rock-bottom-low. Even putting that kind of work into promotion won't show much result, if any; because people can't be arsed to move away from (Photoshop, Word, Excel, etc., etc.) so unless your project is outright unique, don't quit your day job.
Because for anything significant, there's an end-user learning curve to (re-)climb, and the vast majority people just aren't likely to want to do that. Not to mention the fact that the number of developers who can (or are willing to) document well is such a tiny fraction that it typically makes the learning curve just that much steeper. If you could get people to read the documentation, of course.
For projects that aren't significant, it's even simpler: not enough people give a damn either way — consequently getting traction is just about impossible.
Should you manage to come up with something actually unique and valuable, that's the only time when promotion will do you any good. Until BigCompanyInc takes the idea, throws 100 interns at it, and out-promotes you. RIP Konfabulator, etc.
The only value for the vast majority of projects is in resumé boosting. Presuming you can get through the HR gauntlet to someone who cares, and of course at this point if you show up with serious coding chops, you are very likely to get triaged out by "Nah, this one's overqualified, let's get a wet-behind-the-ears collegecritter instead."
Let's not forget the NIH effect, either. You can write something really great, offer it up, and have it rejected for the dumbest (or no) reason(s.) ROI: zero.
I use a dedicated preprocessor to elaborate abbreviations.
Hover to reveal elaborations.
(Score: 3, Informative) by JoeMerchant on Monday February 09, @04:18PM
>Until BigCompanyInc takes the idea, throws 100 interns at it, and out-promotes you.
I worked, professionally, on a cutting edge software product from 1991 through 1996. Around about 1994, competitors were entering the market. Our product was DOS based, but had a mouse driven push-button / radio button type GUI. Somewhere in there was a basic, not very refined, file selector dialog. We were focused on the "science" end of things, but more than one user requested a better file dialog. Around about that time there was the product owner (a retired M.D.) + me + 1 tester / documentation developer on the project, and we got word of a competing company starting to develop a similar product - they had a team of 30 software engineers. I had to choose: add / refine a new innovative analysis algorithm, or make the file selection dialog more user friendly. With 30 software engineers those kinds of choices just aren't necessary.
🌻🌻🌻🌻 [google.com]
(Score: 2) by krishnoid on Monday February 09, @04:31PM (1 child)
Both require marketing, which, ironically (?), AI can help with in either scenario.
(Score: 3, Insightful) by JoeMerchant on Monday February 09, @04:58PM
> AI can help with in either scenario.
I agree, however... both scenarios are competitive in nature, you are trying to get support or attention or customers from a "market" filled with similar seekers. Unfortunately, those other seekers also have access to AI...
First response I expect would be along the lines of "but AI marketing is such a turn off..." and I agree, when it is done poorly. However, AI is a tool, like a chainsaw is a tool, and if you're whittling a marketing totem pole with a pen-knife you won't be very competitive, speed or efficiency wise, vs a skilled craftsman using a hammer and set of chisels, but then there are totem pole carvers who do their work with chain saws, and the good ones are very fast when compared with hammer and chisel, ridiculously fast when compared with pen-knife, but the bad chain-saw wielding totem pole carvers just make bad totem poles.
How do you "do AI marketing better"? Basically, invest more time in refining its outputs, don't accept garbage - spot the flaws and either have the AI fix them, or if that's too frustrating just fix them yourself with traditional tools.
I started "getting serious" about Claude code in July of 2025 (according to my billing history...) Back then Sonnet 4 was the latest and greatest thing. With each release since then (possible exception for Opus 4.1), the number of frustrating end-points has diminished, not dramatically, but significantly and consistently. I classified Sonnet 4 as "a helpful tool" back then, as compared to its predecessors which were barely better than a Google search. Today, Sonnet 4 looks like a clumsy toy compared with Opus 4.6 - it was still helpful, but Opus 4.6 is much more helpful, less frustrating / disappointing, far from perfect, but the models are improving at a rate I would call similar to many interns I have worked with - at least for software development tasks. I haven't used it for marketing, but I know a business owner who does and her flyers have gone from average/dull to pretty cool, interesting and venue specific/appropriate designs, in less than a year - and she spends less time making the new cool ones than she used to spend on the dull ones.
🌻🌻🌻🌻 [google.com]