Over the last several years DotNetNuke has maintained a policy of providing an upgrade path for users running previous versions of the platform. Only in rare instances will we intentionally break a feature or an API or do something that would cause 3rd party extensions to break. Customers have expressed to us over the years how important it is to maintain an upgrade path. This concept is not unique to DotNetNuke. Various projects and companies will take a different stance on the topic. I was reminded of this recently with the Windows 7 launch where XP users were forced to make a tough decision – go through the hassle of installing a clean version of Windows 7 and then installing all of their old software and migrating their data (I hope grandpa had good backups), just stick with Windows XP, or move to a competitor. Even Apple recognized the problem with the Windows 7 approach as evidenced by their Mac vs PC commercials.
Providing backwards compatibility is not something provided by every CMS. In fact I was recently reading a couple of posts where Dries Buytart discusses the Drupal philosophy as it relates to backwards compatibility. This is a radically different approach than what is taken by the DotNetNuke project. The reason that I think the DotNetNuke approach is the better approach is that content management systems and web platforms do not exist in a vacuum. DotNetNuke is popular in large part because of the rich API that it provides which has allowed 3rd party developers to create 10’s of thousands of extensions for the platform. The real power in the platform lies in the ecosystem that is built up around the platform. Taking actions which discourage development on or use of the platform is counterproductive. Likewise, customers invest a huge amount of time, energy and money into developing their sites or web applications built on our platform. It is unheard of for a site to run without at least one 3rd party or in-house extension. At a minimum, your site is going to use a skin that was not delivered with the platform. Providing an upgrade path for the core that doesn’t maintain backwards compatibility for 3rd party extensions is ignoring reality. A site that can’t upgrade due to 3rd party dependencies is likely to never upgrade, or to require a huge expense when they are finally forced to make the leap. I believe that you maintain stronger customer loyalty when you do not put roadblocks in their way; when the cost of upgrading is vastly cheaper than the cost of moving to another platform.
Maintaining backwards compatibility and providing an upgrade path for users of previous versions is not something that is easy to pull off. In fact, I would argue that it is one of the biggest technical challenges that any software company will face. How do you continue to innovate and enhance your product without killing off the ability to allow users to seamlessly upgrade to the latest versions – with their entire site intact (including all of their 3rd party extensions)? I don’t believe that the two are mutually exclusive goals. Architecting and planning for backwards compatibility and a smooth upgrade process requires effort just like that required for every other feature in your software. If you are sloppy in your initial architecture or you fail to do sufficient planning it can make the next version more difficult to implement. The same is true of every feature though.
Providing upgrade paths and supporting backwards compatibility does require more planning by the project architects and you do have to be creative about ensuring that you are not paying a huge performance penalty as a result of the backwards compatibility. These goals can be achieved as evidenced by the thousands of companies and products that deal with this challenge every day. It is often sufficient to maintain partial backwards compatibility where you sunset support for older features and don’t provide a direct upgrade path for users past a certain version. If users wait too long, they may need to upgrade to an intermediate version of the software before upgrading to the latest and greatest version. But a path still exists – the users can move forward.
Ultimately, every software company must face this decision – make it easy for your users or make it easy for your developers. Give your developers a green field to develop new features or make it easy for your existing customers to upgrade and take advantage of your new features. DotNetNuke has always tried to take the path that made it easiest for our users. We believe that ultimately this allows our developers more time to focus on our current platform rather than trying to implement bug fixes in 2 or 3 different branches of our product. Not only does this free up our developers, it also frees up our QA/Testing team who don’t need to perform build-verification and regression testing on multiple versions of our software. Instead we can focus all of our development resources on our current platform. The other benefit of this approach is that we have a much better security posture as a result. Whenever a security issue is found, we can apply and test the fix in our latest release. If customers ask about how they get a security fix – the answer is always the same – upgrade. We do our best to make this as seamless and painless as possible. That is not to say we are always perfect and that we don’t occasionally have bugs in the upgrade process, only that we make every effort to provide this feature in as robust a manner as possible.
At the end of the day, I believe that the backwards compatibility issue comes down to how best to serve the customer. From the customers I have spoken to, the answer is easy – allow them to protect their investments and amortize the cost of implementation over a long period of time. Make it an easy decision for them to continue using our platform. Unlike in the cell phone industry where new customers are treated like kings and old customers are treated like a nuisance, we want all of our customers – past, present and future – to be able to benefit from our latest and greatest platform.