Longbet: By 2027, software will be metered/sold by the second
longbets.org
longbets.org
Or, more than likely, every major software company in a certain domain will coincidentally release metered software in the same time period and small indie developers will be trying to compete with products that have 30+ years of familiarity (and not really succeeding).
Then other software industries will adopt the system within months and it'll be inescapable.
This is precisely what happened with subscription services.
The deliverable is a single docker container (not a desktop app!) and right from the start, nearly three years now, we've been selling on the AWS Marketplace for 0.16c/hr:
https://aws.amazon.com/marketplace/pp/prodview-5jvke6codhrsm
We have a couple of pricing models, but on the consumption based model we stick to that clear, transparent hourly price. It's good for customers that choose that model, and good for us because we're engineers and we don't care for opaque enterprise sales practices.
We do a fair number of enterprise sales too, they require a negotiation because metering usage at an enterprise level is rarely practical. Even then the price is some calculation of usage/value + support. Keeps it simple, lets us attack a big market as a small team and stay focused on technical delivery, shortens the sale/negotiation time, and our customers know they're basically paying the same price as anyone else.
Azure and AWS already can bill by the second.
As of right now, the cloud versions don't have all of the features of the desktop versions.
But, cloud Office is absolutely abysmal if you get away from the core line features or need to do anything semi-difficult.
Online Word fails to faithfully reproduce complex layouts. Dealing with asian languages results in weird font inconsistencies as well as layout errors.
Online Excel also fails in non-ASCII text. Complex Excel books that are already slow are even slower online. Of course, you can't access local resources if any book reaches outwards like that.
I wouldn't be too surprised if it still all moves to subscription pricing though.
This might make sense for services like aws but not user software..
When it's someone else's dollar... most people don't sweat it too hard.
To be clear though, this isn't wrong. The number of times I've gotten into shouting matches with people over deallocating cloud resources is not insignificant.
> The first software was designed for, or sold to individual hardware manufacturers and distributed free with the hardware. In the next stage it was sold directly to end users. Next, it was sold under a subscription model to end users. In five years, it will be metered by the nanosecond to end users. This is not only predictable, but inevitable.
The kind of software they are talking about (operating systems, word processors and other enterprise productivity software) was never given out for free, and the volume sold directly to end users was (and is) negligible. It was always a per-user license negotiated between sales and procurement teams since back when business software first became a thing, and will be so for the foreseeable future.
Based on what? Obviously the price per second will be higher than a fixed monthly rate. See Lambda vs EC2 pricing for example. AWS’ whole infrastructure is pay-per-use and they’re banking.
Look at the gym industry, which makes its money off people not using their memberships.
Whether this makes sense though depends on the software.
For me personally I would not terribly mind to pay Photoshop by the minute because I would need it an hour per year. That’s extra cash that Adobe now just does not see. Most professionals though would still keep paying monthly because they use it a lot.
Is the amount of work it would take to implement a metered rate at a rate users would pay worth it to capture the people who don't use it as a regular part of their job?
There are other options/build your own but the cost to reintegrate or quality.
Most software runs locally. "What you say, jerf? It's 2022, man, keep up." By that I mean, in terms of resource consumption, most software uses mostly local resources. Your Slack server footprint is tiny compared to the resources eaten by your slack client. Websites explode in RAM and CPU compared to what it took to serve the resources to your browser. Streamed video is expensive to encode once, but will be decoded somewhere locally millions of times. Especially for systems large enough to be worth optimizing and where they're not some guy's first Ruby on Rails project (built before he really got how not to make 15,000 queries per web page) or something. Servers for Slack or Office 365 or a streaming video service are certainly Big Iron and expensive, but compared to the sum total of resources sitting on the client side they're tiny.
Charging by the second for Office 365 wouldn't be smart, because their marginal costs aren't all that related to how many seconds of use there is. (They're certainly correlated, obviously, but I can find you signals that are much more strongly correlated than simply seconds of use, like document size and how many times they reload the page.) So you get all the disadvantages of your user sitting there thinking "How fast can I get this done? Every second I delay I'm paying more!", but you're not saving the resources or anything.
Pure time-based costs make sense if you're selling truly time-based resources, but are questionable in other places. For a lot of services, if not the majority, the true nature of the marginal costs are really hard to divine, and the users don't much care anyhow, and the marginal costs are much smaller than you want to charge anyhow, so it's much easier to just charge them $10/month and get on with it, rather than do all the complicated math to discover that this user's marginal cost was $0.33 this month.
(If my choice of example numbers confuses you, be sure you know what a marginal cost is: https://www.shopify.com/encyclopedia/marginal-cost . There's a lot more to pricing a cloud service than marginal costs. With modern hardware, networking, and even a cursory stab at some optimization by the developers, the marginal cost of a lot of useful cloud services can be tiny. There's useful cloud services out there where the marginal cost of a user is probably less than a penny per month. All the other costs can be quite non-trivial, though!)
That’s completely irrelevant for “most software.” What I pay as a company is for the value it provides (and for the people who work on it). For Office specifically the resources are minimal on both sides but it still generates millions for Microsoft, whether it’s native or web based.
It benefits someone who just uses Excel for a short time to do their budgeting each month (because it saves them money), but it also decreases the value of that customer so much that Microsoft probably doesn't care that they get (wild guess) 5x as many of them.
Purchasing access to exclusive content with pre-paid minutes is not a new thing after all, but most people want either buy-once-pay-once or "manageable monthly/annual rate", not a highly variable and potentially very spendy financial timebomb ticking away on their computers.
You get freemium usage every month. In that case, everyone gets to use Microsoft Office for free. And that is a huge lock in if it isn't already.
You have caps, just like AWS, the cap will be cheaper than actually billing per second.
The subscription per month stays in place. Because companies like OpeX, but the usage model gives them a lot of flexibility. Especially in terms of cross selling to other software within the same company.
The only problem is I only see this being possible if the software is run on server and streamed to clients. Otherwise I dont see how they could meter it and we are just back to the old crackz or warez era.
This is just price comparison. There are other reasons, convenience, visibility, integration with other services, to choose lambda sometimes and EC2 other times.
It's important to profile and know what your use case is!
Disclaimer: I work at Cloudflare on R2 and Workers is even cheaper than Lambda@Edge (provided your workload fits within the compute envelope). Billing is based on CPU time not wall time [3]. Workers Bundled pricing can be more cost effective in some cases if you only need <= 50ms of compute.
[1] https://lumigo.io/blog/aws-lambda-vs-ec2/ [2] https://www.trek10.com/blog/lambda-cost [3] https://blog.cloudflare.com/introducing-workers-unbound/
However you are paying for the energy required to run the software, and energy prices may also spike and become non-negligable. So technically, you are paying by the second.
People will absolutely buy inferior products if it's cheap enough and marketed well enough.
This is why plain text matters.
1. The vendor has a choice of what they offer me. They can decide to offer only networked, for-rent versions. That's their choice.
2. I have a choice what I purchase or rent. I can decide to only buy (not rent) software that resides on my own machines. That's my choice.
They can pursue a direction that I don't want if they choose to. I can still choose not to go along.
The (unfortunate) idea is that network latency will be low enough, and rendered interfaces will be good enough, that companies can make "streaming software" a compelling enough experience for the masses, to the point where it becomes normalised.
The only people working at nanosecond precision are likely to want a long-term project budget to allow for budget planning.
> [..] specifically MS Office for business and Avid Pro Tools for film, will be metered in seconds, rather than distributed in a sales or monthly subscription model.
Businesses have budgets to manage, and those are typically allocated on the order of months or years. Not only this, but the seconds interacted with these pieces of software would incentivize users to keep closing them, breaking workflow.
I suspect we will see more license pools shared at companies for expensive software, with the possibility of pulling out additional licenses on-the-fly at an additional cost.
On the other hand, an industry that may want per-minute billing is lawyers, who typically bill their clients per minute. That said, it's hardly worth the effort and is just considered part of the operational overhead of an employee.
Metering hardware by the minute makes way more sense though, as is roughly correlates with wear. Things like electric scooters now charge per minute. But this is essentially the taxi model and this is obvious.
The answer to future shitty software that sucks ass is to use or write different software. I understand that lots of companies use Outlook/Exchange and won't switch anytime soon.
> "... In five years, it will be metered by the nanosecond to end users. This is not only predictable, but inevitable."
And that's the extent of the rationale for the prediction. The right thing to do when people insist their unfounded conclusions are "inevitable" is to take their money, but that's not an option here (the Long Now foundation keeps what they make on investing any "bet" for the duration, and the capital is paid to a charity of the winner's choice).
office <-> avid is a pretty broad spectrum. I'm sure there are ways in which office is not a commodity available for free on every platform, and as a libreoffice user I feel the limitations of libreoffice sometimes, but office software is mostly a commodity.
video + graphics software OTOH doesn't have a strong oss contender IMO
also unclear how AI will change the game -- will we sell software or trained models. will plugins from different training sets be 'incompatible' in some way that favors one-stop-shop vendors
Now, I'm not saying it's 100% impossible. But if it happens, (ever), we can effectively declare "general purpose computing" dead.
This favors the challenger because they’re more likely to get a clear win.
If I were this person I’d do a lot of clarification.
Also why avid pro tools? That choice of something so niche makes me feel like the author knows something on that one.
If your OS is uncontrolled, so is the software.
I guess you'd also not be allowed to value your time or effort, either.
As a thought experiment, imagine how the modern web might've played out if KHTML was released under the MIT license instead of the LGPL?
Bearing in mind: Google has other ways of controlling the market (search, android, youtube, gmail, "switch to chrome" everywhere... don't call it anti-competitive...), but they've had to work much harder to exert control than they would've -- IMO -- if blink/webkit/khtml had a more "corporate friendly" license.
Maybe I'm off base with my reasoning, but I see it as being about friction. We can't stop the inhuman profit-seeking machine from doing what it does, but we do have some (underutilized) tools to slow it down.
You gotta wait for the service to come back online, you lose a bunch of screen real estate, the context menu is slow and unpredictable.
Obviously there is benefits, but couldn't networking be easily built into desktop apps as well?
The web version is, but it does have a lot of drawbacks.
Maybe in some decentralized world lol.
Disclaimer: I am working on exactly this notion of a decentralized PaaS
Printers appear to be an unusual niche in that everyone needs them cheaply, but they also need to be highly precise to print documents and graphics well. So you have these cheap devices that pull off something very difficult -- thousands of tiny tiny droplets of ink per inch, precisely aligned, again and again, very quickly. But with plastic shells, mass-produced injection-moulded mechanics, and a few high cost, enclosed components.
This is why they tend to have no replaceable parts, and integrated print heads. Because user-replaceable parts mean human-level tolerances, not factory machine tolerances, and human-level tolerances mean badly calibrated prints.
In short, nobody wants to have to learn to tune their document printer the way everyone with a 3D printer expects to have to do.
There are a few things that your EPC printer could focus on -- standardised ink delivery, standardised print heads, modular linear rails. But it will be difficult because it is difficult to solve for all of those things cheaply.
If we could go back to e.g. the limitations of a golfball printer, we'd have ethical/open/modular implementations left, right and centre. Otherwise, be careful what you wish for, unless you really want to tinker with your printer.
I'm glad to see this development
Personally I think this long bet is questionable, not least because computing power that can be sold by the second effectively already is (serverless functions, or cloud hosting, which is already sold in fractions of hours), but also because many of our computation requirements will be able to be satisfied by the dirt cheap microcontrollers of 2027, let alone the phones.
The specific software in his bet has a large enough setup and configuration burden that it seems unlikely to me there's much value in selling it in units of time shorter than a month.
Office applications in particular have an inevitable outright purchase or long term subscription model. You need them for all the things you do; this cost is baked into very ordinary overheads.
There are some narrow functions _in_ applications that you might want to pay for per use or per short burst of time. I can see the relevant app developers lowering the cost of their applications so they can sell CPU time for specific AI-driven or database-driven functions (advanced autotracers in Illustrator, advanced video processing calculations). But not the applications themselves.
We've started to see something similar with all the paywalls that have gone up in the last decade.
A good example are wireless companies. Cell phone companies could have gone the unlimited subscription model route many years ago but yet they continue to limit the use. It's not a straight per minute model but you can divide the monthly charges by the minutes and it works out the same way.
The way to fight it is to go open source and the expansion of community projects like Wikipedia and such. But getting people to do work for the public good without compensation in the long term is next to impossible.
Charging by the period of time is coming. I'm 100% sure.
If you charge per second then they will find alternatives, they’ll have to think of ways to pause and resume the software when they are in between tasks. This adds real costs and disincentives for the customer to use your product. When they compare billing to a per user license, they might perceive the per user license as lower cost.