> Every piece of technology faces a time of obsolescence.
That is true for most technologies that experience entropy and the problems of real world. Real physical devices of any kind will eventually fail.
However, anything build upon Claude Shannon digital circuits do not degrade. The digital CPU and the software that runs it are deterministic. Some people see a lack of updates in a project as "not maintained", but for some projects that lack of updates means the project is finished.
> obsolescence
What you label as obsolete I consider "the last working version". The modern attitude that old features need to be removed results in software that is missing basic features.
> replacing dependencies is no longer feasible without manual intervention to mitigate problems
This is simply not true. Have you even tried? I replaced a library to get proprietary software working last week. In the past, I've written my own replacement library to add a feature to a proprietary program. Of course this required manual intervention; writing that library took more than a week of dev time. However, at least it was possible to replace the library and get the program working. "Market opportunities" suggests you think I should have bought replacement software? I'm not sure that even exists?
> ABIs and APIs are not as stable as you'd think.
I'm very familiar with the stability of ABIs and APIs. I've been debugging and working around this type of problem for ~25 years. Experience suggests that interface stability correlates with the quality of the dev team. A lot of packages have been very stable; breaking changes are rare and usually well documented.
That is true for most technologies that experience entropy and the problems of real world. Real physical devices of any kind will eventually fail.
However, anything build upon Claude Shannon digital circuits do not degrade. The digital CPU and the software that runs it are deterministic. Some people see a lack of updates in a project as "not maintained", but for some projects that lack of updates means the project is finished.
> obsolescence
What you label as obsolete I consider "the last working version". The modern attitude that old features need to be removed results in software that is missing basic features.
> replacing dependencies is no longer feasible without manual intervention to mitigate problems
This is simply not true. Have you even tried? I replaced a library to get proprietary software working last week. In the past, I've written my own replacement library to add a feature to a proprietary program. Of course this required manual intervention; writing that library took more than a week of dev time. However, at least it was possible to replace the library and get the program working. "Market opportunities" suggests you think I should have bought replacement software? I'm not sure that even exists?
> ABIs and APIs are not as stable as you'd think.
I'm very familiar with the stability of ABIs and APIs. I've been debugging and working around this type of problem for ~25 years. Experience suggests that interface stability correlates with the quality of the dev team. A lot of packages have been very stable; breaking changes are rare and usually well documented.