But, there’s a dark side.
When you update software to a new version, you normally do a regression test, which means you go back through all the old funcitonality to make sure it all still works. If the software has been completely written within your organization, this isn’t a normally problem since you have the whole codebase. But if there are plugins and extensions that are written elsewhere — some that you may not even know exist — how do you test those?
Well, you don’t. What this means is that different things break for different people when you upgrade. Case in point — I ran an automatic update to Firefox this morning, and I lost four extensions that weren’t compatible with the new versions. I hope that sometime in the future, compatible versions come out for those extensions, but until then, I’ve lost some functionality.
What gets worse for software developers is when someone writes a “killer extension” for your system — an extension that everyone uses. You may find yourself in a position of not releasing upgrades until you’re sure they’re compatible with all the killer extensions lest you really irrritate your users or they just refuse to upgrade rather than lose their beloved extension.
The same can be said of the relationship between OS and software, I guess. I remember reading that when Windows XP came out, Microsoft had to insert thousands of hacks and special cases for specific software titles (SimCity, for instance), to ensure they didn’t break. If they did break, Windows would take the blame, although in most cases, the problems were because the software developers were doing very unorthodox and unsupported things.
As people write stuff (software, plugins, extensions, etc.) for your platform, you start to lose a little control. Some of this can become critical to people, and your users may look to you to make sure it keeps running after you upgrade.