Why isn't it proof that a subscription model produces more revenue than a sale model, rather than proof the sale model is essentially unsustainable?

I'd guess they were going with a theory such as "The subscription model out-competes the sales model on a few axes, therefore (all else being equal) a company relying on the sales model can't compete with a company relying on the subscription model. Sales companies fail, leaving only subscription companies."?

I thought about it some more, and realized a different issue.

I charge a fee to get the software, and renewal fee for support and upgrades.

That's essentially a subscription, right?

The main difference is that once my customer has the software, even under the proprietary license, there's no time limit to their continued use of their old versions.

So is EvanAnderson's point that only time-based subscription renewals are sustainable?

That's how I'd read it. For a while, computers and software were advancing so fast that anything over ~3 years old was obsolete and essentially useless anyway. The whole software industry is built around everyone throwing their computer in the bin every 3 years and starting over, buying all their software and hardware again.

Somewhere in the mid 2000s we reached a point where computers were "good enough" and so that upgrade cycle started stretching longer and longer. I'm still using a computer I built 5 years ago and (barring the spinning hard disk which died last year) there's no reason I shouldn't keep using it for another 5, along with all the software I run on it.

Hence the industry-wide switch to subscription models (and especially to cloud-based subscription models as they're essentially impossible to pirate). They had no other way to maintain their revenue streams.

Thanks. There are a few comparisons to my field which stand out as being different than an end-user software sales model.

First, like I said, most companies in my field (including me) already do a software subscription model. You write "there's no reason I shouldn't keep using it for another 5", but there are reasons to pay for chemfp upgrades even nowadays:

1) I track support for underlying toolkits, where new features are added and APIs change. For example, the most recent release of chemfp added support for Open Babel's 3.0's new circular fingerprints, and for a number of new structure formats in OEChem and RDKit.

2) The commercial version adds Python 3 support - if you stay with Python 2 then you build up technical debt. (#1 and #2 depend on other software advancing enough to need support.)

3) I added improved performance, new APIs, and Zstandard compression support, which resulted in better I/O performance over network file systems than gzip.

So while you could wait 5 years - and it would be cheaper for you to only buy a new copy every 5 years than a support contract - there are advantages to spending the money. And I can still budget for a 5-year update period; while Microsoft has to meet market growth expectations on their revenue streams.

Second, there's plenty of scientific software in my field which started decades ago, and which haven't become "essentially useless" in the meanwhile, making them counter-examples to your broad description.

Third, pharmaceutical companies keep their data close, and prefer to analyze things internally rather than on the clouds. Even the search queries may contain sensitive chemical structure information, which causes some companies to block access to chemical search services unless an NDA is in place with the search provider.

That's basically my thesis. Even entertainment software, which is, I think, the most amenable category to being a "product" is going the way of subscription services.

I commented in the parallel thread at https://news.ycombinator.com/item?id=23905523 . Basically, commercial scientific software has long had a software product model based on yearly support/upgrades, scientific software has a long history where even decades-old code bases are useful, and pharmaceutical research has a practice of doing their database searches and research in-house, in order to protect trade secrets.

So I think scientific software is more amenable to this sort of product+support model than you do.

Or rather, what I think of as a product sale includes a support contract or occasional re-purchase at full price, rather than a pure fire-and-forget model like embedded software.

That's my take on it. Recurring cash flow trumps one-time sales. When you consider that all of our computing platforms are in flux, and all of our software is effectively built on shifting sands, virtually every product will need some kind of long-term "maintenance", even if that just means the silly make-work of moving to new APIs / OS versions / CPU architectures for no benefit to the program's feature set. A subscription model is the only effective method I see to sustain that maintenance and keep the software relevant as time passes.