FlowingRiver
9 hours ago
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.
rurban
8 hours ago
No pain, more fun! Much more interactions, much more reports, much more new features planned for years. Head of dozens of Libre/Open projects.
FlowingRiver
8 hours ago
That's good to hear. Looks like you have a nice sweet spot. Very nice.
edelbitter
8 hours ago
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).
FlowingRiver
8 hours ago
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.
aaron_m04
9 hours ago
> 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? It works for Dusk OS!
FlowingRiver
8 hours ago
Dusk OS and Collapse OS, with every global event their reasoning for existing seems much more plausible.
johnnyanmac
9 hours ago
> 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.
FlowingRiver
8 hours ago
More a case of, maybe shoot a little higher than a 486. Maybe a Pentium 3 so you get SSE in there.
ranger_danger
8 hours ago
> Don't do that
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.
FlowingRiver
8 hours ago
The paradox of choice in action. Sometimes a limited possibility is better as you can only choose and benefit from a limited amount, but with unlimited choices opportunity losses that can stack indefinitely.