This is something I repeatedly encountered in corporate environments: A software is built, using one or more third-party libraries. The software is released and rolled out, and then people freeze the environment.
"Our software is tested to work with XYZ version 1.4."
I do understand why managers wish to cut back on costs. But not keeping your environment up-to-date is not the way to do it. Let's have a look at what happens:
People know that that XYZ library is available. They use its features. Heck, other projects start to use its features, since it's installed on the machine anyway. And all those people rely on version 1.4, its quirks and peculiarities. Most people will even be completely and blissfully unaware that there are quirks and bugs in that version. No-one is testing the whole shebang against versions 1.5, 1.6 and 2.0, because it has been decreed that it shall be version 1.4.
Then someone does do the test against 2.0, because there are new features and fixes of old bugs that would benefit his work. And lo and behold, things break. "You should use version 1.4, as it has been decreed it shall be 1.4 and nothing else."
And then comes the fateful day when it turns out that it cannot be 1.4 any longer. There can be many reasons. Support for the old compiler is running out, and there is no build support for the new compiler in 1.4. There could be bugs in 1.4 that have to be fixed. (Management could get the idea of patching 1.4 instead of updating. When that happens, leave.) There could be new hardware that isn't supported by 1.4. (64 bit multicore CPUs, anyone?) There could be some other third-party library that is required by some other project, which requires XYZ library 2.0 minimum.
And there you are, with dozens of projects that have to be fixed now, even though project A is in code freeze, project B had its funding withdrawn, and there's no-one to be found knowing how to fix project C because all the developers have left. You are in deep trouble.
You might not believe it, but it has been this way in most maintenance projects I worked on. It would be so easy to keep abreast of third-party updates. Some minor changes here, some patches there. Little things. Things easily done on a small maintenance budget, things that don't endanger deadlines. All it takes is a management that realizes that change is inevitable. You either change right away, or you will feel pain (and significant maintenance cost) when that inevitable day comes and you have to leap several third-party releases at once.
A special treat is when you cannot even update a single third-party library, because they are interdependent, and you have to update them all at once. I tell you, I have been there. It is not a beautiful sight.
There. I had to get that out of my system.
