Version 6.99 Forever
There's an airfoil analysis program still running on a release from December 2013. Fortran, written in the eighties for a human-powered aircraft project, and the "similar software" list around it is mostly other people's ports: a MATLAB version, a Java rewrite, a GUI wrapped around the original solver. Nobody's been maintaining the core in over a decade. Nobody seems bothered.
The instinct is to read that as neglect. Frozen software is supposed to rot: the OS moves, the compiler moves, the libraries move, and one day the thing just won't build, or builds and gives you a wrong answer nobody notices until it's expensive. That's the standard story, and it's usually right. It's right because the environment underneath the code keeps changing while the code stands still, and eventually the gap between them stops being cosmetic.
But that story has a hidden premise: that the domain the code is modeling is also moving, or at least that the code's correctness depends on staying synced to something external. Take that premise away and the whole decay mechanism stops applying. Subsonic airfoil aerodynamics in 2026 is the same problem it was in 1986. The equations didn't get an update. A program that solved them correctly then solves them correctly now, and freezing it doesn't cost you anything, because there's nothing moving for it to fall out of sync with.
What changes instead is everything around the code that isn't the domain: the language people want to write in, the platform they want it to run on, the interface they want to poke it through. None of that touches whether the physics is right. So instead of the software needing rescue, it becomes a fixed point other things get retargeted onto. Someone wants it in MATLAB, they port it. Someone wants a GUI, they wrap it. Someone, apparently, wanted it running in a browser tab, so an agent read the original algorithm closely enough to reproduce it faithfully in JavaScript and shipped that.
That last one is the case that made me actually notice the pattern instead of just nodding at it. A forty-year-old piece of numerical code got a browser port not because someone dug up the maintainer and begged, and not because anyone reverse-engineered a black box. It's legible. The algorithm is written down clearly enough that reading it is porting it. The original author isn't a bottleneck because the original author already did the only hard part, which was getting the physics right and writing it down plainly enough to survive being read by someone, or something, with zero context decades later.
That's a different kind of durability than "well-maintained." Maintenance implies a person keeping pace with a moving world on the code's behalf. This is closer to a reference document that happens to be executable. Nobody has to keep it alive because it was never dying, it was just sitting there, correct, waiting for the next runtime to come check its answer against.
The distinction that actually matters, then, isn't "was this kept up to date." It's "does the thing this models hold still." Most software fails that test immediately, because most software encodes business rules, user expectations, or some other target that drifts on its own schedule regardless of what the code does. But the software modeling something fixed, some piece of math or physics that isn't going anywhere, gets to skip the whole maintenance treadmill. It just has to be clear enough that whoever shows up next can read it.