In the 80s Ian Sommerville wrote about the "long tail" of maintenance
accounting for >75% of the lifecycle costs of a program. I remember
being surprised at this, but my SE prof saying "all successful
projects tend toward 100% maintenance."
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.
Sure, you can maintain it if you want. And they ought to give you the means to. But that’s a bad comparison.
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.
Love the hull eating creatures that must only be humanely killed.
Yeah, things never stand still. And those best equipt and informed to
make changes for changing times are end-users in whatever context they
find themselves, post-apocalypse or otherwise :)
>But the very idea of software having a pre-defined lifespan is not sensible. Do we put expiry dates on mathematical theorems?
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.
In the case of operating systems, do you think 10 or so years of support is not enough?
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”.
> In the case of operating systems, do you think 10 or so years of support is not enough?
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.
I know there are features to hotpatch the kernel, don’t know if that’s limited to Red Hat or Ubuntu or if something like Arch can do it too.
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.
Huh never knew that was their plan, such a shame Hurd isn't completed! I wonder if such a vision could be possible with a simpler os like FreeRTOS or similar
Most of stuff there still works just not supported. You are free to run Java 2 or Windows 95, just you won't get any free support for it forever. Check with MS for right money they may even support it.
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.