I'd say at the very most it needs security updates. Too much software changes just to change. UI redesigns for the sake of redesign, cramming features that nobody wants so a product owner can get promoted, adding telemetry and analytics to chase metrics that no user cares about, adding annoying notifications and popups to juice "engagement". I pine for the days of desktop software, where I can wake up in the morning and not be worried that some developer 1,000 miles away from me changed my product out from under me because developers gotta develop.
Another benefit of software that doesn't change every week is you can charge one time for it rather than these awful subscription pricing that most software are switching to. They justify subscriptions because "we have to keep paying developers to develop." Not a problem that the user has, so why should the user have to pay for it?
Old, unchanged software is not obsolete. It's mature. Bugfixes only, please.
It makes sense though, if software companies could make just as much money doing less work, they certainly would.
And then there are the "upgrades" that try to force you to pay more.
There was a dev tool that I purchased a couple years ago. Don't remember the name. It was reasonably priced and came with 1 year of support. A bit over a year later I got a notification that they had put out an update, so I downloaded it to take a look, only to find out that it had deleted the version I had bought and my license wouldn't transfer over. If I didn't now buy this new version, not only could I not use it past the trial period, but I'd lost the version I had before.
Yeah, I was pissed. And the company really had trouble understanding why I was so pissed off by this behavior. I did finally find out where I could download the version I had before, but there went my entire workday. And the product that previously I would recommend became something I cautioned people to avoid!
Any successful piece of software cannot realistically just stay still. It has to keep evolving with the trends of user interface. The difficult part is doing it well. BBEdit has managed it.
Many people I know in my industry have been looking to dump the service contracts for CAD software for 10+ years. No useful added features, no improvements in stability, and no service to speak of through the VARs. What is the point of paying?
> Too much software changes just to change.
But it doesn't imply this:
> I'd say at the very most it needs security updates.
What the parent said about "security updates at the very least" is correct, and sometimes that happens to also be the very most updates that should be made. And sometimes it's that but a little bit more. And sometimes it's that and a lot more.
The hard part is figuring out the right balance. And then, figuring out how to staff in order to achieve that balance.
The "only security updates" approach turns out to be among the hardest to figure out how to staff for. Because the idea is that this software is essentially complete upon release, so the natural business model is to sell it that way, for a one-time fixed price. And then with that revenue structure, the natural cost structure is to move all the staffing to a new project (or to build these kinds of products with project-based contracts to begin with).
But once you've accepted that you should at least be doing updates for security (and I think this is correct in almost all cases), well, now who is going to do those? You have a recurring cost with a non-recurring revenue stream. You can push down the recurring costs as far as possible, but eventually this model just struggles to pencil out. At that point, you'll probably decide to just stop all updates, including security patches.
This phenomenon is why most people making software seek a business model with a recurring revenue stream. It's not an accident that the days of boxed software were also the days of rampant insecurity.
But, you're totally right that the next step in this is often, "well if we have to have ongoing staffing and recurring revenue, we need something for them to do besides maintenance, so let's do UI refreshes and metrics and stuff I guess". It's a test of leadership, to avoid that temptation. Better products have better leadership that is making better decisions about when it makes sense to do more on a product and when it makes sense to mostly leave it be.
And a lot of those updates wouldn't be necessary of software and tools wouldn't offer so much attack surfaces, that they wouldn't need if they cared less about those things as necessary features...
This assumes a waterfall approach to development which implies multiple 6 month to year long development cycles.
In reality, a mature stable project can receive monthly updates, and an immature half-working project can be in maintenance mode. Furthermore this may work for software that should be seen and not heard doing its job in the background without much user interaction, but for software that users interact with regularly, the design needs to be periodically refreshed to match current trends or users will leave for the newer sexier product with fewer features. We've seen this time and again. I have absolutely experienced a mature product that was "finished" (abandoned) like 4 OS version ago that just doesn't run/work on the current OS version because the platform has added new security controls, APIs, and/or UX expectations, etc. No amount of security updates would fix that.
So while I understand where you're coming from opining for a world where we ship mature software and security updates only, I don't think it's remotely realistic given the way humans operate.
Software that gets frequent updates isn't "mature and stable" by definition. It's constantly changing.
That's simply not universally true and it's incredibly naïve to try and assert that it is. Obviously there are examples of immature unstable software that receives monthly updates, but it's not a tautology that monthly updates imply immaturity. You either don't work in software or haven't really thought this through.
Stable means the software run reliably without major issues and mature means it is a solution well adapted to the problem domain and solves a problem with grace, tried and true. Monthly updates might be "integrate support for new technology/service (that didn't exist 6 months ago)" or "support latest changes in macOS 14" or even "fix issue that happens 0.01% of the time". Other software changes and you have to adapt, and no software ships bug free. Being mature and stable means you have the time to work on things that aren't existential for your product/business, like adding convenient support for some sexy new service as a nice value bump or making sure those 0.01% of your users aren't occasionally encountering an annoying or frustrating issue.
You're touching on the real problem, here. Software isn't broken, it's just that the inherent issues in capital are starting to become painfully clear in this context.
I've been trying to find a term for "behavior focused on maintaining your job when the need wouldn't exist without such behavior". It's kinda tangential to artificial scarcity but broader in scope, and if we don't have a term for it, we need one badly. So much of our society's resources are committed to solving problems that don't exist, because the actual problem is "you need money to live and for whatever reason the thing you do in the place and time you are isn't necessary or desired".
The concept of self-preservation or calling it superfluous self-preservation probably works here. But perhaps saying auto-preservation conveys better the sometimes lack of conscious intention that goes on in these situations.
How do you pay developers to continuously fix bugs, provide security updates and update their software when the underlying hardware and operating system changes?
Have we really strayed so far that everyone's forgotten how this is done? Security fixes and serious bug fixes should always be free (At least going back N-1. You price that work into the sale price to begin with), and you get ongoing revenue by selling new versions.
They will still need to buy a new version or should that be free?
If the author of BBEdit never added a feature since 1991. You would have still had to pay for new versions to run on your PPC/Classic MacOS, OS X PPC, x86 Mac and now your ARM Mac.
Back in the “good old days” MS Office cost $595 for each version if you had a Mac and Windows PC.
Now it’s $99/year for five users and you can run on your Mac, Windows, iPad, iPhone, web, or Android device.
The same for Photoshop.
And you get continuous features added as the platform vendor and software vendor add more capabilities.
This works exactly up until the moment that your software is good enough that most of your userbase stops paying to upgrade. Then you are dead in the water, and the software becomes abandonned by design.
As a user-developer, I'd also be happy with being provided the source (or un-linked object files, or the equivalent for whatever language being used) after the maintenance period was over, so I could continue applying dependency security patches myself.
and then you move the bar a little (although I agree):
> Bugfixes only, please.
I would also add updating to work with the current OS / hardware. (I have unusable games that are a recompile away from being usable.)
But I agree with the rest of your points. Especially when, in addition to asking you to fund new features, the new features make the app worse for your use cases.
However I don't know if the root cause is more accurately described as "developers gotta develop" or "product managers gotta produce".
Software degradation is much like hardware degradation: it happens with time as underlying platforms change.
Most people in engineering roles think the job is done when the engineering is done, and the maintenance is unnecessary unless it's necessary for stability or security. That's not limited to software, either. The fact is, to the vast majority of non-developer software users, an improved workflow, more intuitive, or yes, even more attractive interface makes more of a difference than moderate performance upgrades or minor stability improvements.
To a developer, interfaces are a way to interact with with software, like an API for humans. To everyone else, the interface is the software. Old interfaces are as or more usable to you because you have a sophisticated mental model of software and a high tolerance for logical complexity. These dreaded designers' profession is figuring out how people who don't have those things can most easily solve their problem with the tool you built.
Car controls would look a lot different if the engineers maintained control over the available controls without designer input. They might intuitively understand that the array of controls that change fuel injection parameters should only be used in certain instances, but they liked having them right there just in case. When told that they'd just confuse average drivers and should probably be hidden, they might argue, "I explained to my 6 year old nephew how more or less air can affect engine preformance." Multiply that by the dozen internal systems they want to control or get real time data from. A designer world recognize that this would confuse most drivers for little benefit and hide everything but the things most drivers need to find and parse instantly... And they would be met with the same heavy sighs and eyerolls that software designers regularly get from developers.
Designers are in the organization because they can do things that developers can't. They make developers work vastly more useful to the world because the way someone solves their problem is as or more important than it being optimally solved using the smallest amount of available resources with 5 9s of reliability instead of 3.
And that's why, in the overwhelming majority of cases, end-user-facing commercial software with professionally designed UIs and someone looking at UX on a whole will dominate FOSS alternatives while tools targeted at developers and other technical people do as well or better, and the commercial equivalents.
It is really easy to get caught in the trap that YOU are the end-user, but a couple user interviews will quickly shatter that reality.
Now people use it in very interconnected ways.
"Security" patches are something only checklist-driven corporate IT (i.e. people who can't consider use-case) ought to care about. For individuals, they're mostly a cudgel to justify abusive practices and should be ignored.
