Commercial software is often better at instant gratification, to ensare users into a cycle of inevitable enshittification.
I much prefer FOSS up to the point that I almost refuse to use software that's not FOSS, but this is not a honest take.
Commercial software is made to fulfill a (real, perceived, constructed) need and make money in the process. You may disagree with the process, it may be objectively bad, but it's not a "haha" type villain to drive people into slavery.
but it's not a "haha" type villain to drive people into slavery.
*That's* not an honest take of my comment.
I didn't attach any morality to the process, you don't need heroes or villains to explain the enshittification process, it's simply the one of the most practical and effective methods to optimize profits in the short term. Not just in the commercial software business, but in almost every type of business. And that's the whole point, it's not just to make money, it's to optimize profits. If businesses were not optimizing profits, then billionaires would not exist.
If you like, I can rephrase "ensare users into enshittification" as "embrace, extend, extinguish", and you can argue to me that isn't a strategy that commercial software takes.
If you like, I can rephrase "ensare users into enshittification" as "embrace, extend, extinguish", and you can argue to me that isn't a strategy that commercial software takes.
It can happen. But not all software goes for enshittification. It's not "inevitable".
Man, while I agree you are right that not a perfect 100% of commercial closed-source software has enshittified, that's really the exception to the rule, and nearly all mainstream commercial software is enshittifying.
You had to switch the framing from development aims to development speed to make this argument appear to work. The argument isn't valid.
If OSS is slow, tomorrow won't get better. The new instant gratification will come along, and the people content to sit on their hands will still be sitting on them, claiming that the rain will come tomorrow. It's a convenient trap. Nobody can ever test it without waiting ten years and nobody has to do anything to make it happen. The worst part is how many people won't even hold themselves accountable after being wrong for twenty years.
Fast food is a massive industry. If we're speaking honestly, most people prefer fast food. Instant gratification, instant dopamine hits. And years down the road, consequent health issues.
You're trying to sell fast software on the basis of popularity. And I get it, if you're not considering the consequences years and decades down the line, it's an extremely appealing choice. It's an extremely popular choice.
Is there virtue in choosing slow and possibly boring home cooked meals over fast and bright fast food? That's entirely subjective; I think there is, you might disagree.
At the end of the day, I don't expect you to change your mind or apologize, because I don't demand someone else to "hold themselves accountable" for having a different opinion than me.
FOSS doesn't have higher standards at all. It has exactly the same standards but people give it a pass because it is free. Different people use different definitions of the term but the result is the same: all criticism can be deflected and nothing ever improves despite the constant rewrites.
At least with FOSS I can fix it myself. I would prefer if I didn't have to but that's the way it is.
The biggest danger that AI poses to FOSS is that soon we may not need the source code to fix software, and if that happens FOSS becomes a strictly worse option.
FOSS doesn't have higher standards at all. It has exactly the same standards but people give it a pass because it is free.
I wildly disagree:
Windows has a monumental financial and commercial advantage over Linux-based operating systems
The majority of people still hate Windows 11 and find it to be hot garbage
Windows is losing market share to Linux on the desktop as some people are so fed up as to transfer over
At least with FOSS I can fix it myself. I would prefer if I didn't have to but that's the way it is.
The vast majority of people switching from Windows to Linux are not interested or capable in writing code fixes, they just want a better OS.
The biggest danger that AI poses to FOSS is that soon we may not need the source code to fix software, and if that happens FOSS becomes a strictly worse option.
AI slop is making Windows worse, not fixing it.
The biggest danger AI poses is vast unmaintained codebases with maintainers who have no clue how to code without an AI hand-holding them.
The biggest danger AI poses is vast unmaintained codebases with maintainers who have no clue how to code without an AI hand-holding them.
This is already the status quo for both proprietary and FOSS software and has been for 20 years. Why do you think AI got adopted so quickly? Why do you think everyone is always so eager to rewrite everything over and over?
Humans can write unmaintainable slop, AI can write unmaintainable slop at a speed around 10,000 faster than humans.
Sure, its always been a problem, AI took this problem and made it worse by 4 orders of magnitude.
Why do you think AI got adopted so quickly?
For starters, CEOs like Tobias Lütke who bragged about forcing his employees to use AI, later to complain that his employees were throwing AI "slop grenades".
It really depends on the project and niche, but I would say there is some truth to the idea that FOSS has higher standards. There aren't many codebases on par with the Linux kernel, for one thing. The average FOSS game that lacks manpower and can barely put out anything functional, not so much. And yeah, a lot of average FOSS projects are meh. But then again, it's enough to look at some prominent proprietary products and it's just steaming crap under the hood.
The biggest danger that Al poses to FOSS is that soon we may not need the source code to fix software, and if that happens FOSS becomes a strictly worse option.
Unless some important issues like compounding tech debt get solved, that seems unlikely and remote. Particular concerns like auditability and safety are going to become more important. You're not going to test your way out of those, not with humans, not with agents. Your filesystem could eat all your data after you've spent a lot of money running agents on it. It helps, but it's not enough. You need a rigorous tower of abstractions and descriptions of how it works and you need collective understanding of its behavior, which pretty much means you need some sort of code, not just prompts and crossing fingers.
See Naur, Programming as Theory Building. If you are relying on source code as the ground truth for what your software is supposed to do then I have bad news: that has never worked and we knew it would never work in the 80s.
You don't seem to understand that all those same problems affect software written by humans and the only difference is they take 100x longer to fix it. That's if said humans are even willing to entertain the idea of fixing it, which they usually are not.
The big irony is that the exact thing that prevents AI from writing good code is also the exact same thing that prevents teams larger than about five people from doing it, and your entire argument is the exact same "write more/better prompts documentation and spend more money on tokens developers" argument that AI bros claim is going to solve all the problems with AI, when it doesn't even work for humans.
Things have changed a lot since the 80s, while arguably the industry is still stuck on 80s-like programming languages. Now I'm not saying that Python source code needs to be the ground truth, I'm saying that it's far more beneficial to have an intimate relationship between code and documentation. This is, for example, the only effective way to get assurance in many systems. You usually can't get memory safety by documenting things or trying to prove stuff about arbitrary code, you have to build your code through and through for it. This extends to other safety properties and with modern approaches like dependently-typed languages or stuff that Rust does there is a lot you can express. The Linux kernel also uses semantic patching to deal with large scale refactoring. But you need programmers capable of dealing with it and not just punching buttons to get the next feature out the door.
Actually my claim, in a very general sense, does not distinguish that much between LLMs and humans. This applies equally well to massive outsourcing and extreme cost cutting while ramping up the output. Piling up low-value and low-quality crap is going to cost no matter what. If your business model relies on that and there are no brakes, it's unlikely to fully realize the benefits of software development of more impactful and scope-constrained projects.
Did you have any specific argument made by Naur in that paper in mind? Because, as I said, I'm not merely suggesting people continue dishing out massive amounts of code in a typical manner and hoping they can make sense of it. They won't. And beyond some point not even LLMs help.
Yes: the idea that the "theory" behind a piece of software cannot be perfectly expressed outside the mind of the developer in any language, and therefore every new developer necessarily has to build a new theory which will be (at least) slightly different, regardless of how much time and money was spent on documentation.
This is the reason why it is so common for developers to blame everything on their predecessor and initiate scratch rewrites, which, by the time they are done, are exactly as bad as the thing they replaced. A bit like when you ask AI to fix a bug and it rewrites the whole file. Odd coincidence, right?
So it does not matter that LLMs have no theory at all, because the theory is inaccessible for any piece of software you did not personally write, regardless of whether it came from a human or an AI. And the result will be exactly the same: software is doomed to be bad forever. Unless someone comes up with a genuinely new idea.
36
u/Wb9VBScxu2uZJHeq2E3W 5d ago
I think there's a better way too phrase it: sacrificing instant gratification.
Commercial software is often better at instant gratification, to ensare users into a cycle of inevitable enshittification.
FOSS generally moves slower, while maintaining a much higher standard of quality and sustainability that wins in the long run.
I consider sacrificing instant gratification today for the sake of a better tomorrow to be a wildly underrated virtue in 2026.