In my previous post, I’ve discussed what it means for software to be backward-compatible. Software manufacturers usually come down firmly on this issue one way or the other. An example of a software company that traditionally strives to maintain backward compatibility almost to the point of insanity is Microsoft. Apple (arguably a hardware company), on the other hand, strives to break backward compatibility where it deems it necessary. Of course, most software companies eventually do decide to break backward compatibility; it’s just a question of when. And no software company deliberately makes its every major release incompatible with its previous version (for instance, while Joomla! doesn’t guarantee backward compatibility between major releases, it doesn’t guarantee incompatibility either).
So what would make even a company like Microsoft, much less the Joomla core developers (who, let’s be honest, have less to lose) decide to throw away backward compatibility? What reasons could there be? Here are a few issues that may be factored in when deciding whether to maintain or break compatibility with previous versions of the software in question.
Increased complexity and costs
Backward compatibility can be very hard to maintain. In the case of Microsoft Windows, for instance, many of the smaller developers (and some of the larger ones!) have grown used to poking around its undocumented (internal) functions and data structures in ways that worked for one particular version – but then subsequently had to be maintained or emulated in all subsequent versions of Windows to come. The Sega MegaDrive (Genesis in the USA) could run Sega Master System (its predecessor) games… by including the main Master System processor as a co-processor.
At some point, the overhead associated with backward compatibility outweighs the benefits of maintaining it, and that is when the decision to break it should be taken. For an entrenched OS like Windows with millions if not billons of installs, that may take years or even decades. For something agile like Joomla, that point comes around much quicker.
Security concerns
In the earlier years of PC development, every application could (and often did) consider the entire PC (and by extension, all of DOS, and later, Windows) as its sandbox, and freely manipulated it as it saw fit. Even when Windows NT became the mainstream OS, developers remained quite happy to write applications in such a way as to require Administrator privileges (the Windows equivalent of UNIX-like systems’ root access). Today, such untrammelled freedom is unthinkable, given the massive security breach it would represent. Or at least, that’s how it should be. In practice, given the need to maintain backward compatibility with such applications, workarounds have to be put in place in order to fool them into thinking they could still do things in the same bad old ways. As it turns out, security is now a more important issue in everyone’s eyes, so sacrificing backward compatibility is easier when explained in those terms.
Stifled Innovation
When creating a new version of its software, Microsoft’s primary goal is not to create something innovative and groundbreaking; instead, it is to firstly ensure that it will do no harm to existing systems running the old version(s), and then add new features. For Apple, innovation and usability and delighting the customer comes first; if the price is breaking backward compatibility, it’s not even an agenda item for them to discuss – they just go ahead and do it. However, if the choice was to innovate or die, even Microsoft will throw backward compatibility to the back burner.