Free upgrades for life?

There’s an interesting discussion about offering free upgrades "for life". Slava Karpenko started it here, saying that it’s a bad idea:

If you’re a user, sure, free upgrades for life sound great, but come to think of it - if a certain software title promises you that, expect the maker to exit the business or abandon that particular product sooner or later. They simply can’t support themselves and justify adding features when they know they will never get that additional cash in. So why bother making a 2.0 if you know all the hundreds of hours of your hard work are going to be not paid off? I know too many examples of that to count.

Michael Tsai more or less agrees.

It’s true. I don’t like it when I’m asked to upgrade every few months or even once a year, but on the other hand if a product claims to include free upgrades forever I also tend to stay away.

Andrew Stone strongly disagrees:

Be just like the NON-indies - do what they do - charge for your bugs and call it an upgrade. And you still call yourself an INDY? Ok to THIN [sic] different but not BE different

The truth is that I agree with parts of what all three developers say. Here are my thoughts on the "free upgrades for life" question:

It’s a mistake to offer free upgrades for life

It’s not going to drive you out of business; there are millions of Mac users out there after all and most of them are connected to the Internet. Even the most wildly successful piece of shareware could never hope to reach "saturation" (where there were no more users left to purchase licenses).

But it’s still a mistake because working for free doesn’t pay the bills. Every free upgrade you offer costs you time, an ever-increasing bandwidth bill as your user base grows, and you have more users to support. Your costs grow exponentially but your income continues to come in linearly. You can survive offering free upgrades but you’ll make more money if you charge for them. And if you make more money then be able to hire more programmers (if you’re a multi-programmer shop) or spend more time on writing the software; it’s a win-win situation because the extra money provides the motivation and the means to deliver better software to the customer.

Once you’ve made the promise you’ve got to stick by it

Nothing leaves a fouler taste in one’s mouth than the when you get burnt by a developer who promises free upgrades and later changes policy and starts charging for them. Once you’ve made a statement on the public record like that — where it will remain forever preserved in the Google cache, or in the ˝Wayback machine" at web.archive.org, or most importantly in the minds of your customers — you must abide by it.

I made this mistake when I released Synergy in 2002, promising free upgrades for life. I did that because I had no idea it would become what it has become. Since then — nearly four years now — I’ve been providing free upgrades at the rhythm of about one per month. I know that if I’d not had that upgrade policy that Synergy would be an even better product than it is today (it comes back to what I said above: motivation and means).

There are a small number of Mac developers who have earned places in my mental "Hall of Shame" for making promises and then breaking them, and I will never purchase a license from those companies again, nor will I recommend them to anyone else. Developers like that might rake in a bit of extra cash, but they also burn any good will that they might have built up.

Do it fairly, don’t get greedy

In order to strike a balance between increased revenue (motivation and means) and customer satisfaction you need to make sure that:

  • Paid upgrades should be few and far between.
  • Paid upgrades should be reasonably priced (not like buying the software all over again).
  • Paid upgrades should be major upgrades incorporating new features.
  • You should offer a lenient grace period (if a user purchases version 2.0 a couple of weeks before 3.0 comes out he or she most likely won’t be too happy at the idea of being forced to pay for the upgrade); I think that at least 3 and as many as 6 months is about right.
  • Free upgrades should be often, but not so often as to annoy customers.
  • Bug fixes should be free.
  • Compatibility updates should be free.

Those latter two points are important. Customers will feel resentful if they are forced to pay for bug fixes (if you sold them the software with bugs in the first place, it is by definition defective and you should therefore not seek to profit from fixing that defect). They’ll also feel resentful if the software won’t run on the next version of Apple’s OS, or Apple’s new hardware, and you try to get money out of them in exchange for working versions. One day it worked, the next day it didn’t: why should they have to pay you again? This is why I’ve offered Universal Binary versions of my applications as free upgrades, even though it cost me money to prepare those versions (the $999 Developer Transition Kit and the $500 ADC membership).

And finally, a comment about new features in paid upgrades: they should be significant, useful new features, not mere window dressing. The worst and most visible offender in this department is probably Adobe, which seems to be doing nothing more than churning the money-making handle by offering annual "major" upgrades which contain no meaningful improvements and charging massive upgrade prices for them. Every year we see a new version of Photoshop come out with the version number bumped up by a whole number, the application gets slower and more bloated, but is anything useful really added? There aren’t too many new things that have been added to Photoshop since version 4 (the first I ever saw), yet if you had purchased every upgrade since then you would be literally thousands of dollars out of pocket. Some time ago Adobe stopped being a company that made great software and turned into an money-making machine responsive only to it’s shareholders.