Subscription Software = Better Programmer-User Alignment (?)(!)

IEEE Spectrum ran a short interview with Thomas Knoll, the creator of Photoshop, who made a very interesting point about the move to subscription-based software rather than one-time buys plus upgrades. His point is that if you are building based sold using the “upgrade model”, developers have to create features that cause users to upgrade.  In his opinion, that means you have to focus on flashy features that demo well and catch people’s attention – but that likely do not actually help users in the end.

In the article, Knoll summarizes the position like this:

Engineers [working on Photoshop] were very much in favor of the transition. Previously, they had to come up with new features every two years, and these features had to demo well, because you had to convince someone to buy a new version based on those features. […]

It also changes incentive for engineers. Previously, the incentive was to create features that demo’d well. Now the incentive is to create features people actually use and don’t want to do without.

This does make a ton of sense and is a good insight into the user value of subscription-based software. I have worked with subscription-based software (Simics) for a long time, and I would agree that such a model made it easy for us to roll out improvements and small new features immediately rather than trying to “save up” for a big release. Subscription-based continuously updated software does help users in the end, and it can create natural customer-focus and alignment for developers. I rather have a continuous stream of little improvements than big bags of changes every few years.

In a way, subscription software gives users more power to influence developers: “if you do not solve my problem I quit”, while in the past you had already made the sale.

Everybody on the Latest Version?

However, there is one aspect that has to be extensively qualified in the full quote from Knoll:

Then some percentage of user base would upgrade, some wouldn’t, so we had to support multiple versions with bug fixes and adding new camera support. The new model encourages users to stay current with the newest versions of software, and engineers like that because when they create a feature it gets to users right away

This is true in some ways, but the whole “everyone is on the latest version all the time” story just does not ring entirely true to me. There are surely lots of graphics artists out there who are happy to always update to the latest release of a tool like Photoshop… but there are also cases where auto-updates are kind of out of the question.

A subscription model with continuous updates is a big no-no in certified and safety-critical workflows. There, you really need to lock down versions and avoid change at all costs. You always need to give users a reliable option to freeze their tools for a decade or more. You can still sell this offer as a support subscription, but expect the users to be happier with clever workarounds that do not change the underlying tool than with fixes to the tool itself.

If your product has an API (and most non-trivial products do), changes to the API will impact the customer’s custom code. Then, changing the product to add features or fix problems might break user’s code. Automatic updates can only be done when you do not change the behavior -otherwise, users will need time to check and verify that you do not break existing possibly mission-critical code and workflows. Adding stuff is usually easy, but removing is almost impossible. There is a big risk to end up like Windows, where you just stay compatible all the time, accruing old APIs and features to keep old customer code working.

Every once in a while, you need to clean out old stuff and create a major version upgrade that changes things and drops features. And then you have to maintain an old version along with the new until users have moved up – which can take a significant time.

It Would be Great…

I would love to work more with continuous updates, but the reality is that it is rather often not possible in professional settings. It works well for consumer products and “fun stuff”, but when we talking about tools that power million-dollar projects, people tend to get very concerned about changes.

Still, I think It can be done, and part of it comes down to a general change in expectations and attitudes. As time goes on, and we use more web applications and mobile applications where constant change is common, we slowly start to expect and accept change. Over time, the careful rigid staging of updates starts to look a bit old and slow, and users will tend to gravitate towards a position where they want more change. It is still a challenge for certified systems, but at some point the value from constant improvement might be worth more than the stability from no change at all.

On the product side, we need to get better at handling backwards compatibility alongside new features, especially in APIs.

As a Consumer

As a consumer, I am bit more skeptical to move from pay-once to subscriptions. For most of the software that I own and use personally, a constant flow of new features and tweaks does not seem particularly important. I have a mix of Microsoft Word 2010, 2013, and the constantly-updating 2016 on my home machines… The newer ones are nicer, but not all that much nicer to motivate the additional cost of subscriptions.

If the price over a period of say five years is several times higher than the old “buy once” price, it does not feel right. The value I get from little improvements to essentially stable products is pretty minimal. It takes more money from me for no additional added value. I am not using the software to make money, which makes the value equation very different from what I do at work.

Summary

Overall, I agree with Knoll’s assertion. It is a nice benefit of moving professional software onto a subscription model (where most of it already is and has been for a very long time), and I like working with a stream of updates rather than major version steps. I had not thought about it that starkly before, and it is an important point to keep in mind when designing (software) products.

Leave a Reply

Your email address will not be published. Required fields are marked *