Yet more on the importance of backward compatibility

David Berlind: “With barely five days to go before long-anticipated January 30 launch of Vista is history, a familiar problem and the linchpin to adoption of any major operating system upgrade (Windows Vista qualifies) is crashing the party: backwards compatibility. Intuit, developer of one of the world’s most popular accounting applications used in small, medium and large businesses (Quickbooks), has notified its customers by email that Windows Vista is incompatible with some of the features of Quickbooks 2006.”

Mary Jo Foley: “Is it Intuit’s fault that its older products don’t work on Vista? Or Microsoft’s fault for changing the operating system in a way that it breaks them?”

George Ou: “As it turns out, it isn’t QuickBooks 2006 itself that has the problem with Vista but all the Intuit and third party add-on software that communicates with QuickBooks 2006 that’s the problem. More to the point, it’s the intercommunication between all those applications and the fact that they’re using forbidden techniques that have been banned since 2001 with Windows XP certification requirements that’s the issue. Intuit admitted to me that they declined to seek Windows XP certification for all these years and they’re just now making the necessary modifications for QuickBooks 2007. The reason this is relevant is because most software that is certified for Windows XP will automatically be compatible with Windows Vista.”

David Berlind: “So, while Microsoft’s response doesn’t point the finger directly at Intuit as the culprit in this situation, it makes it clear that its certification programs — programs that Intuit has apparently eschewed since 2001 — are the centerpiece of its efforts to guarantee backwards compatibility.”

Interesting discussion. Whose fault is it? It doesn’t really matter, as the end result is the same—Microsoft potentially loses customers (those who won’t upgrade to Vista because QuickBooks will break), and Intuit potentially loses customers (those who won’t upgrade to QuickBooks 2007 but rather will move to an on demand solution like NetSuite—customers tend to dislike forced upgrades).

David Berlind’s observation is interesting though, namely that Microsoft has been using its certification programs to limit the scope of the backward compatibility problem to a well defined subset around which it can presumably do thorough compatibility testing. Note that Red Hat too only guarantees backward compatibility for a subset of its platform, and that the LSB doesn’t cover the entire Linux platform either, just the subset that’s import for application portability.

What are the lessons here, from my point of view? First of all, and not surprisingly, backward compatibility matters, and it matters (or should matter) to both sides. Second, to achieve that backward compatibility, both sides have to work at it, and because a typical platform has so many moving parts, limiting the scope is key to understanding the “contract” between OS and application. Finally, some formal way of stating “I am following the contract”, such as a certification program, can make compatibility a lot easier to articulate to mutual customers.

Related: On the importance of backward compatibility, More on the importance of backward compatibility

8 Responses to “Yet more on the importance of backward compatibility”

  1. The thing about Linux is, if one wishes to run software that uses different mutually-incompatible libraries, then one can virtualise or multiboot on the same box. The cost remains zero, so the ‘punishment’ incurred by lack of backward compatibility is low(er).

  2. Bob says:

    Q: What would you like for lunch, Sir?
    A: Umm. Online accounting with industrial espionage on the side.
    Q: Excellent choice, Sir. May I suggest a sprinkle of BigBrother with it?
    A: Yeah, wouldn’t it be tasty?

  3. Don Marti says:

    Another lesson might be to have lighter weight certification programs. Why didn’t Intuit go for the certification that would have revealed the problem? Too much expense and bureaucracy? (LSB’s

  4. Bob says:

    Certification with Microsoft? They can’t get Word do its thing without crashing, and they want others to certify with them? Oh dear….

  5. [...] 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. [...]

  6. Ewan Marshall says:

    If you upgrade due to the free software philosophy Developers generally upgrade software to still be compatible very quickly. Hence it is not as much of a problem anyway.

    e.g. Amarok are looking to move to new KDE4 libraries as soon as KDE4 is released but both will continue to support Arts and DCOP until the last line of the new code is written.

  7. David says:

    Back in 1985 or 1986, a whole bunch of Macintosh software quit working on new systems.

    A major C-compiler violated Apple’s guidelines and every application compiled with it wouldn’t work with the new Macintosh Plus.

    It was an early and expesive lesson in “rules are there for a reason.”

  8. Mael says:

    Ewan Marshall said:
    Developers generally upgrade software to still be compatible very quickly. Hence it is not as much of a problem anyway.

    This can also be a huge problem for some users. I use Linux distro known as Scientific Linux CERN 4 (essentially a distro built using RHEL4 sources + some modifications) on my laptop because of my work. Generally everything that is bundled with the system works really well but whenever I need to install extra software (something that is not bundled with the system or new version of some tool with new functionality I need) I’m in trouble. Desktop software (things like graphics programs e.g. Inkscape come to mind) is really difficult to install. There are no readily available binaries for RHEL4 and building new versions from source is difficult because I have to upgrade shitload of libraries (not available in RPM-format for RHEL4 so ./configure && make && make install is the only way) and their dependencies as well. The reason for this seems to be that some (actually most) desktop software developers seem to think that everyone has the latest version of libraries. So the compatibility with new library versions comes quickly but at the same time old distros become obsolete too fast.

Additional comments powered by BackType