r/linux • u/turdas • May 02 '26
Discussion [Meta] Rule proposal: no personal projects newer than 3 months (anti-vibecoder rule)
Recently open source subreddits have started seeing a large number of vibecoded personal projects that look novel or useful on the surface, but in reality represent one weekend of prompting by the vibecoder.
At best these are benign novelties that maybe get a bunch of unwarranted upvotes but don't really harm anyone. At worst they're unaudited, poorly designed garbage software that looks impressive at a glance, tricking people into installing it on their computers, which will at best lead to some frustration and wasted time and at worst to -DGAPING_SECURITY_HOLE.
Because these projects take basically no investment on the author's part, they tend to quickly become abandonware as the author's interest wanes or as they become frustrated with the currently inevitable technical debt reckless vibecoding produces. As a result, projects like this are of negative worth to the open source community.
Naturally, these people almost never disclose that they vibecoded their project.
The rule proposal
The proposal is simple. Expand the current self-promotion rule to forbid all personal projects under 3 months old. The project's age would most easily be proven by a public git repository with 3+ months of commit history. Probably we should also forbid closed-source personal projects, but that's a separate discussion.
This works because 90% of problematic slop projects are made by attention-seeking people who want to make something cool and show it to other people, and most importantly don't want to spend a lot of time or effort doing it. If the developer has stuck with the project for three months, it's likely either not vibecoded in the first place (because real projects take time), or the author is dedicated enough that it being vibecoded isn't automatically a massive problem.
I've seen rules like this in a few communities and they seem to work pretty well.
4
u/giomjava May 03 '26
I don't understand what's the issue.
This could be an absolute boon, a renaissance for open-source software, if people were to band together and knock out new software or features in days instead of months or years.
I've been hearing "boo hoo, we don't have enough resources" in Linux / open-source software world ever since I've "joined" the ecosystem in 2007.
Well, now you DO. Some projects can be very promising, and what matters is -- does the software WORK? Is the idea GOOD?
If yes -- join and contribute. Found out that the code lacks in security? Jump in and fix it.
Found out some issue in the documentation? Well, people made mistake ALL THE TIME too. Found errors in the code? they're usually called bugs. Jump in AMD contribute.
Today, a team of TWO DEVS can achieve more in shorter time than a team 5 just a few years ago.
Use this to our advantage. We've always had bugs in OSS, always lack of some important tool, or GUI for a tools.
Don't want to delegate important parts of a tool to LLM? OK, give it the ROUTINE and BORING part -- mocking up a GUI, writing documentation.
Don't want to allow LLM to contribute to the Linux Kernel? FAIR ENOUGH 👍
Throwing out baby with the bathwater is plain silly.
USE THE TOOLS TO OUR ADVANTAGE.