People updated software before they started using subscription models.
Paying for software meant they had to make more compelling updates.
Paying for software meant they had to make more compelling updates.
That being said, security updates shouldbe part of the price you already paid, since a security flaw is a flaw in their original software.
Security vulnerabilities generally aren’t considers latent defects under warranty laws (at least not in NA). I’m not sure what the tech world would look like if it were - for one thing, software teams would probably need a P.Eng. on their teams to ship. For another, using open source software would be even harder to do without an intermediary like Red Hat who would be willing to accept tort liability.
At any rate, your software vendor has no legal responsibility to provide you with security updates. Maybe they should. But you’ll pay for that anyways. How do you want to amortize those security updates? By paying the dividend discount price of the updates up front and risk having the product abandoned in a few years (cheating you out of your ‘dividend’), or by paying directly through a subscription?
If you are paying for a subscription there isn’t necessarily an incentive to provide security updates even more, since they have the functionality of your app hostage if you decide to cancel and the automatic monthly billing has no ties to the quantity or wuality of updates they push out.
That makes no sense - you have it completely backwards. Their incentive to provide me with timely security updates is my continued subscription fees. On the other hand, if you pay the dividend discount price for those security updates up front, they have every incentive to stop releasing updates and cheat you out of your update ‘dividend’.
You pay one subscription fee for both "I can use my app at all" and "security updates" together. Once there is enough inertia for you to not want to switch off, you'll probably keep paying (to use the app at all) even if they don't provide security updates.
If there were two fees - #1 a one time lifetime usage fee and #2 a security updates subscription fee then maybe that would make sense, but I don't think so otherwise
Yes, those costs will ultimately be embedded in product pricing and borne by the customer, but that's good. It gives vendors a financial incentive to develop more secure software and reduce their security update costs (and earn more profit). (Nothing is perfectly secure, but a culture change and following certain practices can help. Think Microsoft pre-trustworthy computing memo and Microsoft today.)
I'm not so sure - it'd be much easier to write the email saying "Sorry, we screwed up and got a critical security but wrong, but here's an update that fixes it." if a significant portion of your users are paying a subscription - compared to writing that same email just as marketing are preparing to try and convince everybody to pay for a new upgrade...
> That being said, security updates should be part of the price you already paid, since a security flaw is a flaw in their original software.
If that was how everything worked - our industry would be _very_ different. If everybody who ever charge money fo a piece of software was on the hook forever for all flaws it might have, you'd only ever be able to buy software from Apple or Oracle or Microsoft - there would need to be almost as any lawyers as developers in any software company.
I understand your idea - but it's the same idea as people who call up my work saying "Hey, the app you made us doesn't work any more, you need to fix it!" and everybody here is like "Who the hell are _they???_ Never even heard of them." and it turns out its a 32 bit iOS app that they paid for in 2013 and we haven't heard from since (and there's only 3 people left in the whole company who were around in '13, and none of them are iOS devs). We do not fix that for them as "part of the price they paid".
- It's unreasonable to expect people to pay the full price for minor security fixes that still need to go out
- Because security upgrades are invisible to the user, it may be harder for the customer to see their value v. new features
- The timeline of when security updates need to go out is less predictable than that of feature upgrades, resulting in unpredictable revenue and expenditure for both the vendor and the customer and the customer may not have the budget to pay for an unexpected security fix
- Customers often want to take time to consider whether it is worth paying for upgrades, whereas security fixes should be applied as soon as possible
- The vendor must invest a lot of resources in testing the security of their software even when no security upgrades are warranted
The ideal model for locally-run software, in my opinion, is to sell perpetual licenses to each major version for a one-time cost and promise security and maintenance updates for a certain period. New features can go into new major versions that users have to pay for (sometimes with discounted upgrade pricing), or, on a discretionary basis, as free updates.
This used to be the typical business model for locally-run software. Microsoft, for example, sold Windows versions for a one-time cost, promised security and some other level of updates until a certain year (and new features could be added on a discretionary basis), and provided upgrade pricing for new major versions that added new features. This kept control in users' hands, as their paid-for software could be used forever (at least until and unless external factors, like hardware incompatibilities, prevented it from working), though of course it would be very dumb to use, say, XP today on an Internet-connected machine. I am generally against subscription models for local software where there is no legitimate reliance on an outside service, and also against the trend of trying to create such a reliance for no legitimate reason ("We've added cloud sync and that's what the subscription is for. Servers cost money every month, which is why we're charging you every month." - except I can handle my own file storage and don't want your sync service).
It's only become a big thing after iOS and it's lack-of-a-filesystem and lack of inter-app data flows locked users out of their own devices.
Quite often I don't want many of the "new features". For me, bug fixes and security fixes are the main thing, followed by compatibility updates. I'm quite happy to pay for the latter when it was me that caused the issue by updating my OS/hardware in the first place. I'd quite like some amount of the former to be included in the original cost.
Manually dealing with files is a sign of poor software design for simple use cases, in my opinion. I quite like the iOS model that abstracts the idea of a filesystem away from the user because the user never cared about the file system anyways. They just had to deal with it to do whatever they really wanted to do.