Larry Osterman's WebLog : Turning the blog around - End of Life issues.
The problem is that you have to decide whether you can afford to break something or not. Determining that is hard. With infrastructure relative stuff, it means downtime. You can not run/integrate your app, work with the upgraded system, whatever. The important question is whether the price of breaking infrastructure/code is smaller now compaired to the maintainence of legacy infrastructure/code cost in the future.
I think a "three step phase out" plan for its API. Customers/developers should be warned that with each new release of something, this and this will break. The developers should be given enough time to start using the replacing API, in the interim release which has the old and new API. Then with the third release the old API should be phased out. This will force people to make the change. Looking at the way businesses work, they will just not update unless forced to. But why should they be forced to? Because if they do not its the rest of the world that suffers.
For instance, consider the boot up times of Windows versus Mac OS X or BeOS. I have read in places that Windows is so much slower because of the legacy code that Microsoft has to support. Why do I have to wait for a 3 GHz machine. Its such a shame that we are not able to really take advantage of the newer hardware because of this legacy code.