Comment by IceDane
3 months ago
This is a uniquely terrible article that doesn't bother with any kind of nuance. If you are using my service and I need to make backwards incompatible changes to my system, you can bet I'm going to force you to update. I'm not going to carry around legacy baggage forever so that I can accommodate luddites with loud opinions and too many Twitter followers.
Long ago, users looked forward to updates. Users were positively excited about updates. Users were willing to pay for updates.
What changed?
> If you are using my service and I need to make backwards incompatible changes to my system, you can bet I'm going to force you to update.
Now, users universally understand that updates solve your problems, not theirs.
The article kinda covers that already:
> If I need an update, I will know it: I’ll encounter a bug or a lack of functionality. Then I’ll go and update.
What if security updates?
The author probably doesn't care.
To be clear I don't think the author's point on updates is such a good idea and that's an example of why, but I understand they require a level of trust on the developer that many, many companies haven't earned.
Inform the user in a minimal way. Probably this means some kind of flag that can be clicked on in order to see a list of what was done and what problems that might address. If the fixes relate to unused features then they can be pended and there is no need to interrupt workflow.
Sometimes I ponder how we could split security updates, bug fixes and new features.
It's a fun puzzle but to hard for me.
Perhaps a 4th kind is needed (needed by the developers)
If the updates are split into small chunks some users could review it before installing. Read the div in the dialog.
Exactly ! Instead of writing good modular programs, pack "features" and security fixes in a nice bundle so users can choose to have their app enshittified or being vulnerable and I sure know which one of the two users don't care. It's a so popular strategy Microsoft uses, Windows even forces it only allowing you to delay it for some weeks.
Not really.
The solution is elsewhere: let me update my programs centrally without the program deciding. Like the App Store or the apt repository.
It’s fair if devs don’t accept reports unless the user runs the latest version.
If you care about security, like a company, you’re probably also doing that on a schedule, and more or less globally, not in the program itself anyways. If the security fix is critical, I’d argue the user does need to install it asap, and then letting them know does make sense.