But one would like to be able to still play Half Life 2 today, even if Valve weren't helpfully around to update it. One would like to be able to read an old Word document or display an old blog post along with its scripts. So either you support the old standards and, for active content, the old APIs, or you lose access to anything that doesn't emit enough cash to pay a person to keep it current.

I think the requirement for constant progress, and the expectation that all software be able to change arbitrarily with a year or so of notice, is in fact a problem with software development.

I do software development all the time, and I find this to be an impediment to my work. I also make the kind of breaking changes that cause this problem.

The difference is that software nowadays is interconnected. Sync doesn't exist on its own, nor does Lemmy. And if one of these links changes, chances are, that something else needs to change to keep up. You're talking about standalone software that that exists entirely on its own. But that's not what this post is about.

Games are a good example. One might want to publish a game and then work on the next game, not go back to the first game again and add dynamic permission prompts for the accelerometer or recompile with the new SDK or whatever. But someone also might want to play Space Grocer I before Space Grocer II-X to get the whole story.

The fewer breaking changes there are, the lower the burden of an app being "supported" is. Someone might be willing to recompile the app every couple years, or add a new required argument to a function call, but not really able to commit to re-architecting the program to deal with completely new and now-mandatory concepts.

Even on software I actively work on that is "supported" by me, I struggle with the frequency of e.g. angry messages demanding I upgrade to new and incompatible versions of Node modules. Time spent porting to new and incompatible versions of a framework is time not spent keeping the app worth using.