In a previous post of mine, I mentioned that we would look at some of the pros and cons of maintaining backward compatibility. In this post, I take a look at some of the reasons software companies choose, like Microsoft, to make their new products as backward compatible as possible.
Most software companies are for-profit organisations; that is to say, either they make money from licencing their software (rarely is software outright sold), renting their software (the SaaS model) or from selling support services (especially if the software in question is FOSS). In all of these cases, the commercial sector is where the real money is, which the home consumer market can have a massive influence on.
The business market
One of the core reasons why software (and indeed, other) companies decide to allocate resources on backward compatibility is because customers – especially business customers – are generally resistant to change. The less change there is, the better it is – especially if the change has a quantifiable dollar cost attached to it (which would be the case if upgrading one piece of software also required you to upgrade other pieces of software which used to work well with the earlier version but not with the new one). Furthermore, many corporate users of software platforms would also have made their own customisations and installed business-critical add-ins and extensions, so they would be much less willing to buy and install a new version if they could not keep their customisations intact.
In addition, many large organisations have internal IT procurement processes that require regression testing of software upgrades against their standard set of software installed on user machines. A software upgrade that did not break the other software in use has a much greater chance of being approved for purchase (in the case of proprietary software) in a quicker timeframe and deployed in production environments.
Another reason why software vendors – especially enterprise software vendors – maintain backward compatibility is to support customers who rely on custom-made line-of-business applications or modules that relied on the particular set of quirks and behaviours (both explicitly defined and internally) of a specific software version. Many times, the developers of such applications are no longer around to maintain or update their creations, and the source code may have been lost or otherwise unavailable. Breaking backward compatibility is not an option for these customers, who might represent a large chunk of a vendor’s market.
The Catch-22
An interesting scenario occurs once a software platform becomes sufficiently popular and entrenched in a global market, and a healthy ecosystem of independent software vendors (ISVs) develop applications that run on that platform. When that happens, backward compatibility becomes a high priority for both the platform manufacturer as well as its ISVs. For the software platform’s developers, they have to ensure that their next version continues to allow all (or virtually all) of the existing ISV software products to keep running with no changes. The ISVs in turn have to ensure that their next-generation software continues to run on the existing versions of the software platform with next to no changes. In this case, both platform and ISV vendors have a vested interest in maintaining backward compatibility with each other’s current- and previous-generation products.
So what about Joomla, which is itself a software platform? How does it handle backward compatibility? That is a matter for a future post.