Mm. I think "any" update would be sufficient for 95% of cases, doesn't have to be high-quality.

Even if it's just the copyright date changing at least once per year, that tells you one specific named entity is claiming to care about it: when nobody does even that much, everyone automatically has the right to do whatever they want with the software.

Which reminds me, I need to update the copyright date on my website…

> If you don't publish high-quality updates for your software for one year,

I don't think that Microsoft or Google will like this.

Forced enshittification?

All the way I was thinking the same.

Why patch the binary to get the correct "system identity" value, to match the license/serial-key you've got? Instead patch the serial-check out of the software entirely.

I've worked on parts of a training platform for a specific professional group... There's literally been widespread hacks to bypass the need to watch mandated training material. You'd be surprised the efforts people will go through to get to/through something they need.

If you use something like Win32 it probably will remain usable into the far future, especially with WINE and/or VMs. I have 30+ year old utilities that were originally written for Win95 but still work on Win11.

> is it realistic these days to just expect software to write once and run forever?

Yes, but you have to put a bit of effort to make it so. For example, if you write your software as a ROM for an early game console (SNES/GBA/etc.), you can probably expect it to run for a very long time, as there will likely be people who want to play Final Fantasy 6 and Pokémon Silver for as long as computers are around.

That's one extreme, but you don't have to go that far. I have some HTML/CSS/JS projects (meant to run locally) from the 2000s that still work totally fine today. Same for Python code from 2010, etc. I wouldn't be surprised if those still worked just fine 50 years from now.

All I do is write code that is meant to run locally first, with very minimal dependencies, only choosing to use conservative/proven technologies.

Some software does. If you've worked on SCADA gear it's expected to go into production and then run for 20-30 years without being patched once a month, or, actually, ever.

Someone once asked the author of an at the time widely-used security utility why it hadn't been updated since 1996, and whether it was abandonware. His response: "No, some people just get it right the first time". Just had a quick check and there's a single CVE for it from 25 years ago, possibly from a third-party mod rather than the original code.

I'd reasonably expect software to run forever insofar as the environment it's run in doesn't change. Essentially, no OS or dependency updates - network is inevitably going to get broken.

Anecdata: My Wii (2006) console has had a few hardware issues I've fixed, but the software is just as responsive as a decade ago (though many external networks/servers have shut down). Homebrew community is very much alive and has expanded its utility.

> But is it realistic these days to just expect software to write once and run forever?

From an engineering perspective, yes. From the current mindset in SW development (reinventing the wheel every couple of years) no. Almost all current SW is throw away software. For most of it you need a particular version of an OS, particular versions of libraries and a particular planet alignment, just to be able to run it.

I've used plenty of Common Lisp code from 30 even 40 years ago without issue.

You can get close. I have personal app and production systems in past jobs that are just running along year after year doing what they were designed to.

You can never escape security patches, but your theory of limiting to a free stable dependencies usually works really well for me.

I was a beta tester for Freehand/MX, and used Freehand and Altsys Virtuoso for decades before that --- it still running on Windows is why I still use Windows, and I despair of what I will use for vector drawing when it stops running.

None of the Inkscape devs are invested in Freehand's keyboard shortcuts and working techniques, Graphite doesn't even work with a stylus, Cenon is clunky beyond words and hasn't been upgraded in decades last I checked, Krita is pixel-oriented, and none of the note-taking programs really work for technical drawing/vector editing....

You seem to be describing how the web dev worked after JQuery but before React. It wasn’t prettier than now.

I agree that the wider NPM ecosystem is a morass of slop and that is technical debt for anyone who wanders into that minefield. But the solution isn’t to assume that there are no bad / unmaintained GoLang libraries. It’s to realize that maintenance, quality, and sustainability need to be first class attributes of every library you choose to allow your project to depend on.

Your proposal will yield lots of LLM near-slop (basically code that works given the original prompt requirements, but will fail to continue working well once some requirement changes, some original assumption is violated, some browser changes are implemented.

Ultimately, the sustainable solution is to have a subset of NPM libraries be extremely high quality, vetted via robust tests and security audits, and are visibly different than the average slop on NPM. Basically a very visible delineation between untrustworthy code and very trustworthy code. Then you should be able to tell the LLM to use only dependencies from that vetted subset.

I agree with you. If the source code is there, theoretically is not abandonware, but handed to the community.

To be fair, GitHub code rots much faster these days. I would assume anything with a specific job to do (not games) that is untouched for 8 months is circling the drain and expiring in another 8 months.

You could give someone permission to crack it.

It's pretty clear that the program has utility, otherwise people wouldn't ask.

Giving it to computer cracking groups as a real world program that they can use as a teaching tool has some value too.

I mean, if you you're not willing to take the money for the program anymore, then you have little to lose with this.

(Unless there's some other reason not to do it, brand harm for example, or third-party code that's licensed and that you do not have permission to subgrant reverse engineering work)

Or you could have AI figure out how to crack it.

Easier said than done.

- It's risk for them with basically no upside.

- Someone at their company needs to do a deep-dive into the code and verify that there aren't licensed third-party libraries and possibly remove them. Even companies that genuinely want to open source software that they've acquired may spend a year doing this sort of due diligence.

> Might be illegal to break someone else's proprietary software, no matter how abandoned it is.

Oh no!

Anyway

Snark aside, what you do locally on your own PC in your own home is kinda nobody else’s business, especially when you aren’t cracking it to share it with others. Pretty sure all the arguments were already hashed out in the ‘80s when VCR companies tried to block recording television to cassette tapes.

Literally nobody cares.