Web applications are inherently delivered to users in an adhoc fashion and users have to just accept that they might receive a different version of the software every time they use it. In the spirit of “move fast and break things”, but also in the spirit of being “agile”, software vendors routinely change their applications whereas traditional software releases have become somewhat rare. From the developer’s point of view this is great for the sake of fast iteration and quickly approximating the version of the product that users will actually like to use. From a user’s perspective however this can be extremely frustrating if the software changes without their approval.

There are a number of reasons why users might prefer to use a specific version of an application: Newer versions of the software might change the UI, remove functionality, introduce bugs, add surveillance telemetry, require newer versions of supplementary software like an OS version, randomly crash, or drop support for supplementary hard- or software all together. Developers think that they only ever improve their software, but users regularly disagree.

That is why ==users have a legitimate interest in running older versions== of some software more or less indefinitely. The only reason against doing so is a potential lack of access to security fixes, but that is exactly why developers should try their best to backport fixes to older version (or let the user do it for them¹). Developers say they “put the user first” and do everything to please their users, but that is completely hypocritical if at the same time they prevent users from running the version of the software that users actually prefer.

How can developers force users to upgrade to a newer version of the software? Depending on the specific application developers might:

• Mandate auto-updates (e.g. by building a service rather than a self-sufficient application)
• Break compatibility to older versions (e.g. via breaking APIs and file formats)
• Withhold security fixes (i.e. not backporting fixes and/or not offering an LTS version)

Some developers are accommodating enough to build software that allows for a wide range of customization and that never breaks compatibility. In such a case, the reasons for sticking with an older version are not as urgent. I would still make the argument that this is a more general issue of control over the software: ==Users deserve complete control over the software that runs on their systems!==

As a developer it sure seems attractive to always force all users to use the latest version of your software.

• Backporting fixes is more work. Very simple. Keeping different code branches around and porting changes to older versions of the code can be annoying. The patches to the latest version might not cleanly apply to the old one and manual labor is required to modify them. This can quickly get out of hand if there are too many older versions to be maintained that way. Supporting only a handful of LTS releases is usually a good compromise.
• Sometimes developers want to make changes that they anticipate to be unpopular. Users don’t like change. If a developer wants to redesign the UI to reflect an updated branding or something like that, they don’t want the older, in their opinion uglier, version to stick around. In my opinion, the aesthetic whims of a design team should not interfer with the user’s preference and expection of how the software looks.
• Removing functionality from a piece of software is not uncommon for vendors who want to upsell their users to more expensive versions or tiers of their software offering. When the high-end software is not all that desireable and fails to sell, the less pricey options are neutered to nudge users to purchase the premium tier and weaken the competition for the high-end product. Needless to say this is rarely appreciated by users.
• Forcing specific versions or even just individual changes to users is often done as part of experiments being conducted on users. Developers are interested e.g. in which UI variant achieves the highest number of clicks on a certain button, highest conversion rate, highest engagement or something like that. The ethics of this are somewhat unclear. As a user, I don’t want to be experimented on and I certainly don’t want things to randomly change just to see what I will do. This is just outsourcing beta-testing to users. Not only is this cheaping out on inhouse QA, but it also does not indicate any respect for the user. Together with recommender systems, these UI studies normalize the idea that every user sees a different reality, which can have horrendous impact on society.

The developer perspective might be somewhat understandable but these reasons are not entirely convincing. In some cases the tradeoff to annoy or exploit users might be somewhat reasonable, but more often than not it isn’t.

How does this relate to the web? After all you can have well- and misbehaving applications both on the web and native. You can save a web application to disk and then run it as-is whenever you want. Similarly, native applications can force or nudge updates in the ways mentioned above. The reason why this relates to the web is that the defaults change when going from native to the web.

Web applications are often not self-contained application that cant function without a network connection. Some do, and that is great, but they are not the default. Web applications are usually intertwined with some networked API that they interact with. Even if the client-side script can technically be run anytime, the remote service can be changed unilaterally by the software vendor. This usually breaks the old version of the client application leaving users with no other option than to use the latest client.

Again: This is not inherent to how the web works. The web doesn’t suck by design, it just sucks because of how software vendors use it.

Software freedom is about having control over the software you run. That includes the decision to keep using a specific version of some application. Developers don’t have an obligation to do free work for their users of course, but they should not make it needlessly difficult for users to exercise their freedoms.