Is it a bad practice to stop providing support for outdated software if updates are free and easy?

Question

Providing support for outdated software is both unexciting and expensive. If people are still using the version which was sold ten years ago, it means that they will find bugs which do not exist in next versions, their software may not work as expected on a new hardware or operating system, etc. The support people must also be trained to use this old version.

This is unavoidable in several cases:

• When every next version of the software is paid, you can't force everyone to spend their money every two years to buy the next version. Example: Microsoft has still to support Windows XP, since it is understandable that people don't want to pay hundreds of dollars for Windows Vista, then Seven, then Windows 8.

• When the update is complicated. Example: when you know that installing SP2 of Microsoft SQL Server 2008 may render your server completely unusable, you may want to postpone installing updates and stay with and outdated version which has one strong point: it works.

• When legacy systems or security considerations are involved. Example: auto-updating a space shuttle software every week may have some disadvantages. In the same way, you can't update hardware if the legacy software requires the old hardware to run.

Now, let's say that the update process is as well done as in Google Chrome. The user doesn't have to bother with the updates; there are no security or legacy reasons to not to update, and the updates are free.

In this case, is it a bad practice, for a company, to stop providing any support for the versions outdated for a few months, and ask their customers to update their software first, then contacting the support if the problem persists?

Answer 1

If you set up the problem in the way you do by explicitly saying that there are no legacy reasons not to upgrade, everyone is going to agree that there is no reason to support older versions. Eliminating legacy reasons not to upgrade, however, is much easier said than done.

Does the new version make any change to the UI? If so, that may mean that the screen shots and screen recordings that a company has put together to show users how to perform a particular task need to be re-recorded. That may mean that users have to spend some time adjusting to the new UI in order to do the same things they've always done.

Can you really guarantee that upgrades are risk-free? You use the example of the SQL Server 2008 SP2 installer causing the server to become unusable. Microsoft spent a lot more time and money testing the SP2 installer than most companies can afford to spend testing every possible configuration that might affect the installer. SQL Server is an enterprise product so there is, generally, less variability in what people have installed on their servers than there is when you look at consumer boxes. And there is a ton of time between SQL Server service packs so there is little rush to get software out the door. And yet, in your example, Microsoft still failed to deliver. That should demonstrate how difficult it is to ship a 100% risk-free upgrade even if everything lines up in your favor. And even if you could deliver a completely 100% risk-free upgrade, how does your customer know that your upgrades, unlike every other upgrade they have to deal with, are risk-free?

Does the new version make any changes to existing functionality? Even if you're just fixing a bug, once you have enough customers, it's likely that someone somewhere will depend on that buggy behavior. Think of all the sites, for example, that have been optimized for some version of some browser that don't work or look terrible when the bugs in the old browser's handling of some HTML element are fixed.

If you recognize that there are valid legacy reasons not to upgrade, you're well within your rights to make a policy decision that ease of maintenance and streamlining support outweighs the legacy needs of customers. Whether that is the right decision will, of course, depend on how large the legacy problems are and how costly it is to support old versions. But you're much more likely to make the right trade-off if you approach the problem by assuming that there are many sources of legitimate legacy issues and figuring out how to quantify those issues than if you start from the assumption that there are no legacy issues.

Answer 2

You might want to support versions n-2 and n-1 (or just n-1) along with version n where n is the current version, just to give people a bit of time to upgrade. But you can't support something forever - it's just not realistic.

Answer 3

I think it largely depends on how your software is being used. If there is the chance that a user will incorporate your software in an automated system, be it a kiosk, a build script, a remote server, etc., then it is likely that those types of users will be resistant to upgrading no matter how "free" and "easy" it may seem to the developer.

The problem is that once software is entrenched in a mission critical[1] system, the risk of any change to a part of that system quickly mounts. Any change has the possibility of breaking something which means that "free" is no longer free.

The original question tries to rule out this type of "legacy" or "security" issue, but doing so requires a big leap of faith in terms of predicting the way that the software will actually be used. One only has to look at the number of strange Windows bugs that are maintained because various programs became dependent on the specific behavior to understand that real world use is not always usage as designed.

Having said all that, it probably comes down to more of a business decision than a programming one, barring the loss of critical information, resources, or code. Does the financial benefit of providing or being able to provide support for an outdated version outweigh the cost of the capacity to provide that support?

[1]: as defined by the user

Answer 4

I think what you are looking for here is a proper release and support process.

Obviously, all this needs to be defined according to your goals and market (eg, Consumer vs Enterprise).

First of would be setting up a proper Product Lifecycle for released software. For example you might want to have stages such as:

1. Generally Available - Able to be purchased, actively marketed, supported.
2. End of Marketing - Available on request, supported
3. End of Life - No longer Available, no longer supported (except under exceptional cases)

You will want to have a known process where by moving a product from one stage to the next is announced a certain amount of time in advance. In some cases and depending on contracts, this would be a legal requirement.

As pointed out by Scott's answer where by version n is GA, n-1 is EOM and n-2 is EOL. Adjust this according situation (eg, more previous versions still only in EOM).

From here, you would probably want to set up some form of ongoing maintenance agreement. That is to say, after someone purchases a product they are support for period 'x'. To remain supported they must pay an ongoing fee. There are several strategies for how to handle this fee and product upgrades, including:

1. Constant maintenance fee (such as % of original price)
2. Constant maintenance fee until period 'y' after a new release, then increasing 'z'% each period
3. Free upgrades
4. Discounted upgrades
5. Full price upgrades

There are several benefits in this for you. Firstly, it gives you a ongoing revenue stream that helps pay for support. Secondly, it can encourage your users to upgrade to newer versions.

Ultimately, it does highly depend on your situation, but it is almost always universally true that you should

1. Have a plan in place
2. Make sure your customers are aware of the plan
3. Have it in the contracts
4. Follow the plan

Lest you be accused of bad practice.

Answer 5

I personally think you need to announce, in advance (at least one year, but three is better) that you will discontinue support. It would also be good to say, with version of the software being sold, what the expected support horizon looks like. Unbuntu is like that.

Answer 6

Its not inherently bad practice, no. For my software, I only make 'fixes' for the current release. I'll help a user of an older version if there's a work-around. But I wont make code changes. Worst case, I'll give the user an upgrade to the new version.

But it really depends on the nature of your software and what support promises/contracts you have. Supporting only the current version may not be acceptable for certain software used by organizations. But for consumer grade software, its fine.

When it comes to free software (Chrome), its definately not bad practice. They are doing the user a favor by offering software for free. They owe the end user nothing.

Answer 7

To be honest with you, I thought about 10 minutes, and I didn't find any problem with stopping support for outdated versions and asking users to update. It's just too logical to have a problem with. I mean, new version is free, and what's better than using something free of charge?

Answer 8

This really depends on the circumstance. I think you can use your common sense to decide when it makes sense.

In most circumstances, I would say that giving old versions support for one year would be appropriate, as long as you make sure that the customer understands this.

I would also say that you should provide full support to the upgrade process from a version that is up to 5 years old or more.

Ie. you should support old versions enough to be able to upgrade them to a version that you can support. If you can't support the upgrade, you need to support the old version.