[JonChesterfield]

A lot of software has dependencies that will have changed over time. Likewise a lot of software fails to pin down exact versions of said dependencies. That makes code that hasn't been committed to for a few years relatively likely to be broken.

Older C or C++ projects may be "standalone", but when built with the latest GCC or clang produce lots of warning messages and may be miscompiled courtesy of programmer vs optimiser. Older python programs may refuse to run under python3.

So while code does not rot, the GitHub project is unlikely to contain all the code for the project, and those external dependencies changing has much the same effect as rotting.

A still running CI would be a better indicator that the project works, but failing that, recent commits are the same signal.

[biofox]

This is the one thing I hate about software. I don't want to have to re-learn how to use a re-invented wheel every couple of years. I just want to use robust, time-tested tools to solve problems, like in virtually every other field of engineering.

[MauranKilom]

I'm not under the impression that e.g. pressure vessel design or bridge building follows the same safety rules now as it did 40 or 80 years ago. You might learn the same basics in university, but in practice the rules and tools are also evolving all the time.

So the "robust, time-tested tools to solve problems" also become obsolete in other fields of engineering. I think this is not unlike "compiler warns about more unsafe practices nowadays".

[layer8]

The velocity (aka churn) is a lot higher in software though, for questionable benefit.

[pie_flavor]

Yeah, but people still do it in, say, Rust, where that's not the case.