There is a good chance that you have never heard of software collapse before, for the simple reason that it's a term I have made up myself two years ago in a blog post. However, if you have been doing computational science for a few years, there is a good chance that you have experienced software collapse, and probably it was not a pleasant experience. In this article, I will explain what software collapse is, what causes it, and how you can manage the risk of it happening to you. What I call software collapse is more commonly referred to as software rot: the fact that software stops working eventually if is not actively maintained. The rot metaphor has a long history, the first documented reference being the 1983 edition of the Hacker's Dictionary [1]. Back then, it was used jokingly by a small community of computer experts who understood the phenomenon perfectly well, and therefore a funny but technically inaccurate metaphor was not a problem. Today, it is being discussed in much wider circles, for example in the context of reproducible research. In my opinion, it is appropriate to introduce a useful metaphor in place of the traditional humorous one, because good metaphors contribute to a better understanding of what's actually going on. The main issue with the rot metaphor is that it puts the blame on the wrong piece of the puzzle. If software becomes unusable over time, it's not because of any alteration to that software that needs to be reversed. Rather, it's the foundation on which the software has been built, ranging from the actual hardware via the operating system to programming languages and libraries, that has changed so much that the software is no longer compatible with it. Since unstable foundations resemble how a house is destroyed by an earthquake, rather than how spoiling food is transformed by fungi, I consider collapse an appropriate metaphor. Fig. 1. A typical scientific software stack