Comment by fauigerzigerk

I don't think the idea is that software should never change. If requirements change then software obviously has to change as well.

But over the course of 10 years a lot of things can change that have nothing to do with changing requirements.

Open source projects are abandoned or change direction. Commercial software gets discontinued. Companies get acquired. App Store / Play Store rules change. APIs go away or change pricing in ways that render projects economically unviable. Toolchains, frameworks and programming languages, paradigms and best practices change.

I think the point is that you don't want external changes that are unrelated to your requirements to force change on you. It's a good principle but as always there are trade-offs.

There is stable and then there is obsolete. The difference is often security.

And what if an important new requirement is easy to meet, but only if you bump a vendored library by seven major versions causing all sorts of unrelated breakage?

What if there aren't enough people left who are familiar with your frozen-in-time toolset and nobody wants to learn it any longer?

I think careful and even conservative selection of dependencies is a good idea, but not keeping up with changes in that hopefully small set of dependencies is one step too far for me.