There's a difference between software that's "done" (it never needs updates, ever) and software that's done (it only needs maintenance for security and platform churn).
The former is extremely rare; platform churn alone will usually demand updates, even if your code is otherwise airtight. Forces generally beyond your access will demand that your code is able to conform to platform standards. The demand this places can be very variable and depends more on the platform than you. (Windows has low platform churn since it's possible to futz with compat features, Linux is extremely variable on your codebase, MacOS is fairly constant and from what I know about mobile phones, you're basically signing up to forever maintenance duty).
The latter is much more common; sure, sudo still gets updates but most of those won't be new features. Specification wise, sudo is "done". It does what it needs to, it's interface is defined and there aren't going to be any strange surprises when I run sudo between any system made in the past 10 years or so.
The problem is that when you're selling software, demanding compensation for the former is a hard sell since it's things customers won't see or necessarily care about. Demanding compensation for the latter is much more obviously acceptable.
Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention. Heck, I even have tools I no longer use that people asked me to keep available because they do, and they’ve been chugging along for over a decade, no bugs or maintenance necessary.
Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
> Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
Yeah, I'm sure the reason stated by the customer support is the real one, and not the lack of profitability from that tool among a shift of focus towards AI[0] as reported everywhere.
> for over a decade, no bugs or maintenance necessary
I'll believe it when I see it. Keeping something running for a long time is a lot easier task than building something that can be run in an ever changing world.
Given that it's that old I'd wager that it isn't runnable on/compileable for ARM64 without some kind of maintenance. And if it's written in an interpretable language there is a good chance that the underling interpreter/runtime are EOL by now.
> A lot of the time, failing to to finish software indicates a badly defined scope.
And a lot of the time finished software becomes unused because it sticks to scopes that don't match up with reality/user needs anymore.
There's a difference between software that's "done" (it never needs updates, ever) and software that's done (it only needs maintenance for security and platform churn).
The former is extremely rare; platform churn alone will usually demand updates, even if your code is otherwise airtight. Forces generally beyond your access will demand that your code is able to conform to platform standards. The demand this places can be very variable and depends more on the platform than you. (Windows has low platform churn since it's possible to futz with compat features, Linux is extremely variable on your codebase, MacOS is fairly constant and from what I know about mobile phones, you're basically signing up to forever maintenance duty).
The latter is much more common; sure, sudo still gets updates but most of those won't be new features. Specification wise, sudo is "done". It does what it needs to, it's interface is defined and there aren't going to be any strange surprises when I run sudo between any system made in the past 10 years or so.
The problem is that when you're selling software, demanding compensation for the former is a hard sell since it's things customers won't see or necessarily care about. Demanding compensation for the latter is much more obviously acceptable.
Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention. Heck, I even have tools I no longer use that people asked me to keep available because they do, and they’ve been chugging along for over a decade, no bugs or maintenance necessary.
Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
https://mastodon.social/@grishka/116005782128372247
“Software is never done” is a myth they tell to keep extracting money from you.
A lot of the time, failing to to finish software indicates a badly defined scope.
> Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
Yeah, I'm sure the reason stated by the customer support is the real one, and not the lack of profitability from that tool among a shift of focus towards AI[0] as reported everywhere.
https://techcrunch.com/2026/02/02/adobe-animate-is-shutting-...
> for over a decade, no bugs or maintenance necessary
I'll believe it when I see it. Keeping something running for a long time is a lot easier task than building something that can be run in an ever changing world.
Given that it's that old I'd wager that it isn't runnable on/compileable for ARM64 without some kind of maintenance. And if it's written in an interpretable language there is a good chance that the underling interpreter/runtime are EOL by now.
> A lot of the time, failing to to finish software indicates a badly defined scope.
And a lot of the time finished software becomes unused because it sticks to scopes that don't match up with reality/user needs anymore.
That tool, BTW, is essentially the authoring side of Flash rebranded.
wireguard is relatively "done"
Of all the things to pick, software which needs to be secure and is actively attacked is the worst one.
So like sudo
"relatively" is just a word added to done and the fact that there is a qualifier precludes the word from bearing truth.
Out of curiosity, what changes would it have at this point?
3 replies →