The problem with not having solid infrastructure for updates is security issues. Of course, there is a class of software where this is not a problem, but determining whether software falls into that category is pretty difficult given the structure of modern OS and the propensity for things like static linking. You have 3 choices: * leave software vulnerable. * track security vulnerabilities is all your software and its dependencies and manually update. * Bite the bullet and have robust auto-update infrastructure.
I’d argue the bigger problem is that implementing robust, dependable and user configurable auto updates with easy rollbacks etc. is a complex problem, so every piece of software ends up implementing its own shitty variant that sacrifices user control and doesn’t distinguish between necessity and churn.
So very true, but the complexities can be considerably reduced by not forcing updates - whether security, dependability, or UX. So many updates I see nowadays are the very 'churn' you mention.
I don’t want to worry about waking up one day and finding that, because the company’s chief designer needed to do something to justify his salary, the whole UI of my software was redone and everything was moved around. I don’t want to find that it now runs 2x slower because an update brought unwanted features. It’s like buying a hammer and a week later the handle is shorter and it turned into a hatchet.