3 ms·

> But, what if I don't want future changes? For almost all software I've ever paid for, as a user, I just want the goddamn software exactly how it is today, for

by prirun 5y ago

> But, what if I don't want future changes? For almost all software I've ever paid for, as a user, I just want the goddamn software exactly how it is today, forever. I'd maybe be willing to pay for security updates, but that's it. Problem is, most software doesn't exist in a vacuum; it is part of an ecosystem. Security updates that you might pay for are not enough, because the ecosystem is constantly changing around the program you bought. I'm author of HashBackup. It uses remote object storage services so if there are incompatible changes made on the storage side, the software has to adapt. What if IP4 is no longer supported? Adapt. A library like Boto2 gets rewritten and the old version loses support. Adapt. Google Sites decides to force you to migrate to a new version that looks like shit. This just happened to me, and it's so bad I'm having to do a whole new documentation site. Just keeping software working has become a big challenge because of ecosystem changes.

ryandrake 5y ago
Great point! It's an ecosystem-wide problem. I'd go even further to argue it's a problem baked into the very psyches of software developers. Your remote storage service should not be changing, particularly in ways that break backward compatibility. Nobody should be dropping IPv4. Nobody should be rewriting a library in such a way the new one is incompatible unless the old one retains support. Nobody should be forcing you to migrate to some crappier version that looks like shit. Stop changing things just to change them. But if you're actually changing for a good reason, consider the downstream effects of your changes. I can take a bash script from 20, maybe 30 years ago, and know that it will still do what it's supposed to do, and all the standard commands it calls, like sed, awk, and grep will also do what they are supposed to do. Bits don't rot by themselves. Careless developers in the ecosystem make changes and don't consider backward compatibility, and we euphemistically call it "bit rot."

by prirun 5y ago

ryandrake 5y ago

Great point! It's an ecosystem-wide problem. I'd go even further to argue it's a problem baked into the very psyches of software developers. Your remote storage service should not be changing, particularly in ways that break backward compatibility. Nobody should be dropping IPv4. Nobody should be rewriting a library in such a way the new one is incompatible unless the old one retains support. Nobody should be forcing you to migrate to some crappier version that looks like shit. Stop changing things just to change them. But if you're actually changing for a good reason, consider the downstream effects of your changes. I can take a bash script from 20, maybe 30 years ago, and know that it will still do what it's supposed to do, and all the standard commands it calls, like sed, awk, and grep will also do what they are supposed to do. Bits don't rot by themselves. Careless developers in the ecosystem make changes and don't consider backward compatibility, and we euphemistically call it "bit rot."