Ian Murdock covers an awkward situation that forces backward compatibility. Changes in Vista are causing problems for a third-party software that works on Intuit Quickbooks. The backward compatibility can always be guaranteed within a scope. This scope is usually the interface offered, usually in the form of an API or a framework. If anyone uses anything other than this interface should expect problems with upgrades.
Backward compatibility has to be considered when one software out of an ecosystem upgrades. If there is no value associated with the upgrade, it usually ends up as a forced upgrade, and backward compatibility can really hurt in such cases. In reality, there are many such ecosystems out there, and it is tough to maintain them through an upgrade. The best way is to guarantee conformance to that interfaces with other softwares, so that anyone else on the other side of these interfaces is not affected.
However, I think that one should not have an extremist approach towards backward compatibility. For example, what happens if the performance is terribly affected because of the backward compatibility? Or if development on the new version becomes incredibly difficult because of it? There has to be a balance between value of the upgrade and the benefit of backward compatibility.
Lack of backward compatibility can affect everyone involved in the ecosystem, it is very important. However, care should be taken that providing backward compatibility does not introduce new problems, or hinder developments important to the ecosystem.
