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.
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.
> 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.
> 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.
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.
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.
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.
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.