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 ye

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.