> 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.
> "security updates at the very least" is correct, and sometimes that happens to also be the very most updates that should be made.
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...
Man I dunno. This sounds right and all, but after years of seeing security issues that don't seem to have anything to do with unnecessary attack surface, I have to say that this just seems unrealistic to me. The problem is that no software runs on a machine without an internet connection, and you can't control the attack surface of other software on the machine.
> 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.