I don't agree with that quote being used to define software rot, and I don't think the examples illustrate rot either. I'm just fundamentally opposed to the terminology of the rotting metaphor when it's applied to projects that receive active upkeep, even if the project drifts further from its original scope and vision. For that, we need a name for that that alludes to scope creep and refactoring, but one that isn't suggestive of decomposition at the mercy of the environment of things immobile and abandoned.

I've always understood software rot to refer only to cases where the dependencies, including libraries and platform APIs, are changed so that an already-delivered copy of the software can no longer function, and the maintainers have since abandoned it, or can't do a quick fix to get it working again.

A recent example is the removal of support for NPAPI plugins in Firefox [1] in 2017. Firefox is in the role of the 'platform API' here, and this change of theirs broke any extension that didn't update. And, the replacement API differs in features, so the effort of updating an extension approaches that of a rewrite.

Another example is the game 'Star Wars Episode I: Racer', the podracing game from 1999. Newer versions of Windows and DirectX have changed things so that the game's original executable doesn't run [2].

Even open source isn't a remedy. Random projects one can find on a source repo, last updated x years ago, are code that are susceptible to this. Sometimes they're shipped without dependency management, pinned to old versions that themselves no longer work, or track the latest when they should be pinned instead. If more work is required to get it running than just the instructions provided by the author (assuming those were sufficient at some point), then it has suffered software rot.

[1] https://support.mozilla.org/en-US/kb/npapi-plugins [2] https://www.play-old-pc-games.com/2013/12/02/star-wars-episo...