upvote
Because

1. Physical dongle tends to break, and when it does, they expect us to give them replacing parts

2. They do expect bug fixes-- especially calculation bug fixes-- as the bugs are discovered. It's hard to leave their production critical apps broken like that once you know that the bugs can cause monetary or even life loss.

reply
> They do expect bug fixes-- especially calculation bug fixes-- as the bugs are discovered.

Maybe I'm the weird one to expect reasonably bug-free software, and if a bug is found, an eventual bugfix "for free"? ESPECIALLY if they cause monetary or life loss!

A bug means the developer did not do their job. Let's not pretend this is OK.

reply
I'd argue software isn't even special in this regard either. If your battery burns down someone's house you better recall all units and replace them with better ones. If you feel that is a reasonable thing to expect your industry, insurance is the solution to that. If anything, your job is easier as a software engineer given that you can deploy fixes remotely and immediately, not harder. Expecting people to pay a subscription as if this is somehow the only solution to a novel problem doesn't make sense, as I see it.
reply
Wanting to say in business makes sense, bug fixes make sense.

But the actual dongle... look, something like that should have a 30+ year warranty. There should be a plan for how to replace it a couple times before making the initial sale.

reply
They actually have this solved with iLok... You can move the license to new dongles at will. And they have a relatively inexpensive annual service where they'll issue you temporary licenses for what was on the ilok while you ship it back the defective dongle to them. Mostly used for DAW software and plugins, but apparently a few other things have used it for licensing.
reply
If my car’s brakes have a design flaw and don’t stop my car reliably, I don’t expect to have to keep paying for my car to get them fixed. The manufacturer’s warranty covers that, and bugs in your software fall into the same bucket.
reply
Honestly, if they never need anything more from the developer, a perpetual license and never spending another dime seems fine. However, in modern times, OS vendors (especially one named after fruit) tend to break a ton of APIs and change rules with every "major release," meaning developers have to invest a ton of effort to at minimum meet all those new requirements every year (!) or else the app will at best look out of place, more likely look totally screwed up and exhibit sudden "bugs" due to the unexpected OS changes, or at worst, crash.

Then users are suddenly all over the developer to provide an update "so I can use this on Tahoe" or whatever, and unless the application is in its honeymoon period where new sales suffice to keep money flowing, the developer is gonna need recurring revenue in order to do recurring development.

reply
Right, but then you're providing tangible value to the customer and thus it's warranted to charge again.

The fairest thing to do is when a customer buys the software, they're entitled to that exact version forever. Or maybe 1 year of updates and bug fixes if you're feeling nice. If they want the next version that supports the next OS, it's fair to charge some more.

This what IntelliJ does. When I buy their IDE I can use it forever, and then they offer discounts for renewing. Pricing seems reasonable even though I'm currently generating $0 from my software development so I keep paying.

reply
> Why should users upgrade or keep paying you when they already bought what they need and don't need anything else?

Because things evolve and inevitably, hardware dies, and you can't get a replacement.

With an old "dumb" piece of machinery, when something breaks you can either repair the broken part itself (i.e. weld it back together, re-wind motor coils), make a new part from scratch, have a new part be made from scratch by a machining shop, or you adapt a new but not-fitting part. It can be a shitload of work, but theoretically, there is no limits.

With anything involving electronics - ranging from very simple circuitry to highly complex computer controls - the situation is much, much different. With stuff based on "common" technology, aka a good old x86 computer with RS232/DB25 interfaces, virtualization plus an I/O board can go a long way ensuring at least the hardware doesn't die, but if it's anything based on, say, Windows CE and an old Hitachi CPU? Good fucking luck - either you find a donor machine or you have to recreate it, and good luck doing that without spec sheets detailing what exactly needs to be done in which timings for a specific action in the machine. If you're in really bad luck, even the manufacturer doesn't have the records any more, or the manufacturer has long since gone out of business (e.g. during the dotcom era crash).

And for stuff that's purely software... well, eventually you will not find people experienced enough to troubleshoot and fix issues, or make sure the software runs after any sort of change.

reply