Should be called The Planned Obsolescence Shaming Site.
If developers want to put a time limit on how long they're willing to maintain a project that's all fine and useful. Coders have lives to get back to and new interests to look forward to.
But the very idea of software having a pre-defined lifespan is not sensible. Do we put expiry dates on mathematical theorems?
Indeed it's a good argument for why all software should be FOSS, because it's ultimately the users of a program, not the developers that decide whether code has continuing utility.
As soon as money comes into development people start noticing the long tail is a precipice of diminishing returns, We act like landlords who can't be bothered to decorate crumbling buildings we rent out. Easier to knock it down and build anew, regardless the disruption for the tenants.
When software is built and maintained by the community that use it, they're more like homeowners, for whom maintenance is adding value to an asset.
I bought a perfect, will never deteriorate houseboat twenty years ago (it is now 2043) and moved it across the world. But now in the harbor of Hong Kong I won’t get a permit to stay there because there is (1) no onboard emergency manual in either Cantonese or Mandarin, and (2) it is not up to code for sustained quarantine due to the novel airborne virus that became a pandemic some years ago, and (3) there is no mounted non-lethal (because animal welfare) protection against a hull-eating[1] marina pest that migrated from the Equator ten years ago because of climate change.
Software obsolescence is all about the world changing around the software.
[1] The boat might be perfect but apparently creatures can still eat it if determined enough.
IMO it made a lot of sense when the hardware was changing rapidly - when the speed of new hardware doubled every year or two, maintaining existing hardware for more than a decade or two was often just a bad idea. And new hardware usually means porting or rewriting the software.
Nowadays though, hardware has largely peaked - CPUs are getting faster, but not that much faster. We won't see five doublings of CPU speed (64x increase) in our lifetimes, let alone in a decade. Security issues and repairability aside, today's hardware and operating systems will be perfectly serviceable in, say, 30 years.
Brian Lunduke once talked about GNU/Hurd and said they should do the following release cycle:
1. Spend a few months working on it and then declare that the 1.0 release.
2. Spend 2-3 years getting Hurd to work on as many architectures and systems as possible. Get all graphics cards types that you can working. Release 2.0.
3. Spend the next 10-15 years squashing as many bugs as possible. Continue working on getting as many drivers as necessary to get it working on as many platforms as possible. Then release 3.0.
4. At this point be done. For the next 100 years GNU/Hurd 3.0 is it. Just do security and driver updates.
I thought the idea of a “forever” OS was interesting. It would then never become “obsolete”.
Yes, I do think that is not enough. An OS should be thought of as scaffolding where parts of it are replaced but never the whole. And preferably while it is running, including all of the core.
If individual packages or services have to restart does not qualify for your requirements then I don’t think any system could truly provide that without having it run multiple instances of each service/itself.