Why I don't think subscription-based charging gets you stability

November 19, 2016

In a comment on my entry on the problem of stability and maintenance (which talks about how this is a problem even in commercial software), Christopher Barts wrote in part:

It's an argument for subscription-based software, if anything: If the only guaranteed revenue stream for a piece of software is selling new versions, the software will never be done. If people pay simply to use the software, the software can be done when it's done, and the company isn't losing anything.

My impression is that this is a relatively common viewpoint and I certainly see the attraction of it, but as I sort of alluded to in my entry I don't think it's actually going to work in many situations and with many companies.

The core problem is that most companies are looking for growth, not just (revenue) stability or near stability. Growth almost always requires bringing in new customers; heck, even revenue stability requires some amount of that, since you always lose some amount of old customers over time. If you want to grow significantly, you obviously need a fairly decent number of new customers.

It's almost inevitable that your software offering will stop being quite state of the art almost as soon as you release it. The result is that the core attractiveness of an unchanging piece of software generally decreases over time; if you haven't changed your software for a few years, it's almost certainly not as attractive as other people's current offerings. To some degree you can make this up with good support and promises of long term stability and so on, but I don't think this lasts forever. So if you don't change your offering, it becomes less and less attractive to new customers as time goes by. In short, when you stand still while other people are moving forward, you fall behind.

(To a certain extent your offering also becomes less attractive even to your existing customers; some of them will want the new features they can get elsewhere, even at the cost of some change and so on, and will leak away over time if you do nothing.)

You can see where this is going. If you want growth, you need new customers. If you want new customers, you must change your software to keep it up to date with the alternatives so that new customers will choose you instead of those alternatives. And that goes straight against the desires of your current subscribers who just want stability and no changes apart from bugfixes. Most companies want growth (or in some cases absolutely need it, like startups), so they're going to opt for making enough changes to hopefully attract new customers without irritating too many of their existing subscribers.

(In theory companies could maintain two versions, one stable one that only gets bugfixes for existing subscribers, and one that gets new features to attract new customers. In practice you soon wind up maintaining N versions, one for each generation of customers who you promised that this version would be stable. This can be done, but it generally increases the costs more and more so those subscriptions aren't going to be cheap.)

A subscription based approach does have the great advantage that you aren't compelled to put out new releases (necessarily with new changes) every so often just to get any revenue; you get an ongoing revenue stream just from people continuing to like your software. With subscriptions, new 'releases' are no longer an existential necessity, but they're still important for most companies and for most software.

(There probably is some commercially appealing software that can basically be 'finished' and need no further significant development to remain attractive.)

Written on 19 November 2016.
« Unix shells and the problem of too-smart autocompletion
Is it time to not have platform-dependent integer types in languages? »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Nov 19 00:09:13 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.