Open Source is one person

software once "perfected" (working well enough long enough) needs NO maintenance. No cleaning. No calibrating/tunning.

updating is a systemic issue, not a per-project matter

Maybe we need a Linux distro based on "inactive" software and look how reliably it performs.

s/inactive/stable/

Well, when you talk about a distribution there's a different issue.

The entire Linux ecosystem is constantly shifting with each package releasing new versions, and therefore everything else must be updated to accommodate the changes in the dependency tree.

You could get away with some stuff being only stable versions, but things like mesa, x11, chrome, etc... would still be constantly changing as would their dependency trees.

Under a microscope, maybe.

But if you had a "perfect" piece of software that used Log4j in 2020, it wouldn't have been perfect for long.

Unfortunately, there's a lot of reasons that software needs maintenance, even if it was thought to be perfect when it was originally written.

Hardware changes. The software landscape changes. Dependencies are deprecated, or are found to have their own problems. Vulnerabilities are discovered. Vulnerabilities are found that aren't even the fault of your software, maybe they are a flaw in the hardware your software runs on, and the only way to fix it is via a software mitigation. These are all real things that happen to otherwise perfect software.

Ironically if you didn’t upgrade from 1.x you didn’t get the new features or the bug you’re referring to

2.x had been out for about six years by the time the vulnerability was discovered.

I was once forced to use older (but not deprecated) LTS Ubuntu and I hated it. New software come out and you're gonna want to use them (often forced to use them), and they of course use newer dependencies. I had to do the distribution maintainer job and package a bunch of software myself.

That is a hysterically wrong statement.

It is true of Solitaire, Minesweeper, Calculator, and Notepad, and probably about the same number of programs on other OSes. (Notepad has recently had an important expansion of functionality, but it didn't NEED that change.)

It's also true of some dinosaurs I have on my system, that copy DVDs and so forth.

It's not true of most other applications, nor can it be true, unless the app works in a sealed, unchanging environment.

Even then... Voyager 2 recently required a software upgrade, IIRC.

The point is everything require maintenance, the degree at which it does require it depends on how dependent you are on it and how resilient the system itself is.

You are but going to fundamentally be in distress if solitaire and minesweeper is not running, if your monitoring SW for some important infrastructure starts to exhibit some issues, you might want to take a look or two...

What sort of work do you do?

I only use LTS distributions, and this is not a problem I have encountered, so I wonder what accounts for the difference in our experiences.

Definitely varies with language/runtime/library choice. I have no problem using a clojure library that hasn’t been touched in 5 years. But back when I had a gatsby site (static site generator for react) I would end up in the dependency hell after literally a month of not touching it

LOL. As soon as Python 3.8 is deprecated/replaced by Python 3.9+ in most systems, python packages that depend on old APIs become useless until updated. Any half decent software engineer understands this.

I think this depends on how they are used.

If you are leaning on the package manager for managing things like Python, then they are really annoying.

If you are just skipping that and using something like UV, then you won’t care that LTS only has python 3.9 or similar.

If you are trying to use them interactively, then they can be annoying because everything new isn’t available. If you are using them as a server for running pre-packaged code, then they are fine.

Plenty of Clojure projects are "done" (the only community I'm aware of that actually believes in this) that presumably specified the vulnerable log4j versions. In reality, it's not an issue, because you can deal with it in your own deps.edn/project.clj/maven.xml, by excluding the dependency, or overriding it with a newer one.

> In reality, it's not an issue, because you can deal with it in your own deps.edn/project.clj/maven.xml, by excluding the dependency, or overriding it with a newer one.

This is maintenance. Maintenance is not an issue if you deal with it, if you don't deal with it, then it is an issue.

You'd think so, but you make something then it doesn't work on a new version of windows, or it doesn't work on a new version of python because one of your dependencies isn't available for that version of python, or it doesn't work on linux if it doesn't have a specific version of packages, or it doesn't work on the browser because they're ditching manifest v2, or it doesn't work on android because you need to provide more personal information or your app will be unpublished.

At this point I have a feeling "perfect" software only exists in hardware like consoles where updates just stop one day.

Nicely said, but the reality is that no software is "perfected", just abandoned.

Hell, even sysvinit had some big updates recently.

qmail

Also many common lisp packages, 15-20 years old and work perfectly fine.

qmail, djbdns, grep, awk, sed, TeX, SQLite, zlib, curl

You don't think Notepad needed AI, a subscription model, and interstitial ads?

Can you provide an example?

A perfected software that had existed >5 years with zero updates, tweaks, ports, or fixes?

And 1.x was and has been logging for a decade or more before that which is why I thought it relevant to the ‘no need to upgrade’ discussion

runit. Every other year someone forks it because they think its abandoned, make some commits for some weeks, and then find nothing else to change and start to look abandoned themselves.

The world didn't stop building new software for that 6 year period, is my point. One would have picked the latest version to build something during that time period.