It's one thing to rail about the varios psychotics or psychopathics of this that or another. That's not the same as understanding the dynamics through which a situation emerges. What's particularly disturbing is when it appears that the outcome is inevitable.
I.F. Stone, writing in 1967 on the Arab-Israeli crisis:
The essence of tragedy is a struggle of right against right. Its catharsis is the cleansing pity of seeing how good men do evil despite themselves out of unavoidable circumstance and irresistible compulsion. When evil men do evil, their deeds belong to the realm of pathology. But when good men do evil, we confront the essence of human tragedy.
http://www.nybooks.com/articles/1967/08/03/holy-war/
Let's look at the problem here.
In a commercial software world, there's a mismatch between cash flows and development. Worse, there's also a conflict between market mechanims based on marginal-cost pricing, and the long-run average costs of development. There's also the tremendous variance in customers' ability to pay -- price discrimination -- particularly for enterprise software.
If you sell shrinkwrap, or some other form of buy-once software, then sustaining the development efforts for the next version is ... difficult.
The two largest consumer softare companies of the 20th century, Microsoft and Apple, both sponsored that development through hardware sales. Apple did so directly, by selling its own hardware. Microsoft did it indirectly by way of per-CPU licensing of IBM-compatible PCs. Both companies avoided the significant costs of direct software sales.
The concept of recurring-subscription revenue is usually associated with periodicals, though that is a relatively modern development. The term doesn't emerge until the 19th century (previous usage was generally in a religious context), and it generally referred to stock subscriptions. Another variant was the subscription library.
(See links below.)
In a magazine subscription, you pay for the right to receive fresh material, but continue to possess any previously received issues.
The model for software subscriptions was in large part IBM's practice of leasing rather than selling computer hardware. Phone systems often followed similar practices. Hardware and software occupy different worlds in that hardware is fairly intrinsically limited: you have a computer, or perhaps a rack, or aisle, or datacentre. But these are unitised, and you're not individually leasing, say, hard drives, CPUs, memory cards, or capacitors, within the computers.
My Debian systems typically have a few thousand individual software packages installed. For a proprietary OS, that number falls, but is still considerable.
Dealing with individual software packages on a subscription basis from here to eternity is itself a major complexity problem I'd, frankly, rather not have to deal with. It may work in instances, but not at scale.
At the same time, there are the financing and cash-flow problems of software developers.
How do you bridge those divides?
https://books.google.com/ngrams/graph?content=*_NOUN%20subsc...
https://books.google.com/ngrams/graph?content=subscription+*...