It worked all the way through the 80s, 90s, and most of the 00s. It brought Adobe, Ableton and many others to their dominant market positions, despite rampant piracy. It works for a lot of games, still.
What’s changed?
There's a large spectrum of extreme profits before every getting to that point.
In any case, folks are free to try local apps for their business and post results.
Revenue maximization given mission constraints is usually the goal. SaaS is simpler, more economic and generally aligns incentives between parties better.
There are many things where a one time cost makes sense, though.
To clarify the conversation, "local-first" vs "cloud-based" is inadvertently getting muddied up with revenue models such as single-payment vs ongoing subscriptions. Those are 2 separate concepts.
Adobe/Ableton/Quicken desktop software still run locally on the users computer. Adobe Photoshop can save ".psd" files locally on the computer. But they have ongoing subscription fees and if users don't keep up the payments, they lose functionality or stop working.
Instead, what people often mean by local-first is "local _data_ stored on my computer as a 1st-class concept". The Single-Source-Of-Truth of data is preferably on my home computer and the cloud is just a convenient replica for backup or sharing. Ideally, the local-first data is also a an open format instead of a proprietary opaque blob. Examples would be local-first Obsidian (markdown files stored locally on computer) -- vs -- Notion (notes stored in the cloud). Or local-first NextCloud instead of cloud-based DropBox.
As your examples showed, local-first software can be monetized via subscriptions.
1. Users expect apps to keep working in the face of platform regressions and policy changes, for "free" (no unexpected extra charges). In the 90s Microsoft went through heroics to make buggy apps work on Windows 95 because if someone bought Windows 95 and an app broke, the user returned Windows to the store and got a refund. In 2024 if Microsoft or Apple ship a buggy OS update and it breaks your app (which they do), the user returns your app to the store and gets a refund. They don't see the platforms changing around them, they just know that your thing worked yesterday, today it doesn't, it's your fault, fix it.
This lack of 100% solid backwards compatibility means it's not feasible to sell a program once and let users keep it forever. They won't keep up their end of the bargain and, by the way, governments will always take their side and not yours so don't think you can just wash your hands of such problems via a EULA. Open source apps can get away with this because there was no purchase to begin with, commercial apps cannot.
2. App Stores happened. That means users can leave reviews and star ratings. In the 90s if you sold an app that happened to crash regularly if you pressed a certain combination of buttons, well, maybe three months later a magazine reviewer would notice or maybe they wouldn't. At any rate it hardly mattered unless you had some kind of unusually high level of bugginess and that fact spread through word of mouth.
In 2024 if you ship a version with even very obscure bugs users affected by it will immediately start leaving negative reviews. You have to fix this or else your app will become unpopular and you'll lose money, but again, this means a continuous stream of updates which everyone gets, which requires ongoing revenue to pay for it.
3. Collaboration happened. In the 90s networks were weak and most computer users worked alone. If Fred bought Office 2000 and you were still using Word 95, then it was expected that Fred would just know this somehow and also know how to use the "Save as" dialog box to save in Word 95 format. It was also expected that Fred's employer would provide a synchronous LAN fileshare using SMB where Fred could store a file. This was OK because remote work wasn't really a thing, and people tended to work in the same physical building. Because apps did releases so rarely and file writes were all synchronous/SMB supported file locks, this complexity was just about tractable albeit only as long as users had a high tolerance for computer nonsense. In the modern era collaboration is expected to Just Work without users having to phone up their mates to find out what app version they're using. That means everyone has to be on the same version, which means everyone has to get all the updates all the time, which means they all benefit from ongoing work by the company, which means a subscription. Plus we expect to be able to work from anywhere in the world, and from devices that don't support synchronous networked filesystems like iPads which means a custom per-app server farm. Those costs also matter here, see my other comment for why the Dropbox trick doesn't really work that well.
You ask why games don't seem to be affected by this. They are affected by this and they adopt a few strategies:
• Primarily target games consoles. Way more stable platforms with way fewer regressions.
• Adopt subscription payments too. See: MMORPGs.
• Keep costs low and hope they can cover them from the sales revenue as the player base expands.
• Just don't support games for more than a few months after they launch. That works because games are short-lived things usually. If the game is broken a year after release a few hard-core fans will care but most people have completed the game or moved on, and won't notice.
For consumers projects - especially desktop - it's more difficult. Many would rather pirate software than pay a few hundred dollars a year for a licence. However, the advent of highly controlled app stores has mitigated this somewhat.
I would like to make open core software for a living but local first would take away the last reasonable venue for monetisation in those cases.
Users will refrain from paying a subscription if their app version works and they don't need updates. The good old buy-a-license with 1 year of updates will likely make a big comeback. Local-first software, at least in lix universe [0], does not have fixed recurring maintenance costs like running servers. The elimination of fixed recurring maintenance costs will lead to a proliferation of "hobby apps" that are undercut by price/make it free altogether.
[0] https://github.com/opral/monorepo/blob/main/lix/README.md
Maybe. Doesn't change the fact that software will be more commoditized.
If software switching costs get close to 0 [because data is owned and can be opened by any other app], pricing pressure will get intense. Investors love cloud SaaS because they can rent-seek and extract margins of >80%. It's unlikely that apps that do not own and lock-in customer data can rent-seek to such a degree. If they do that, users will switch to the next best solution.
The hope is that the markets are large enough that niche apps can carve out a healthy revenue with a more personal, "homegrown" experience. This is where my product lives, and so far it's worked well enough.
Also, switching cost is never zero or even close to it. The user still has to click a button. I know it sounds like I'm being facetious, but coming from a large-scale B2C industry, a single button click is an enormous obstacle.
The internet is rife with stories of hobbyists who would love to give adobe $500 to just buy their software outright. Many Adobe competitors offer exactly this!
It's not like many professional services manage the long-lived part, either, is it?
I have much more confidence in my WebDAV server still being around in a decade than pretty much any cloud-based service.
If somebody is taking money for something, it isn’t really a hobby, it is a job. It might be a poorly paid one, but they still have an ethical obligation to their customers, to meet some standards of merchantability and provide some level of customer service.
But if you mean, “apps that hobbyists use” then that makes more sense. There’s nothing wrong with producing a toolkit that a hobbyist can use to write their own apps of course. It is like producing hand tools—you have an ethical obligation to make sure the tools themselves are reasonably free of defects but of course you don’t have to provide customer support for the treehouse!
Distribution (specifically maintenance) becoming cheaper will enable those people to compete/provide enough value to customers that larger companies face downward pricing challenges.
IMHO, the problem isn't with local-first application themselves. The problem is that our economic system rewards players responsible for vendor-locking (and any sort of similar practices), while providing no support (or even livelihood) for folks focusing on delivering a great product free of artificial restrictions.
Is any company making money in software without an enterprise revenue channel, aside from games? Do regular people “buy software” anymore?
Edit: I also recently bought Sublime text, several Jetbrains products and some other utilities.
Off the top of my head Topaz Labs is a company that offers a suite of photo tools for purchase. They are aimed at both professionals and high end hobbyists.
I bought iExplorer which lets me sanely treat my iPhone like an external disk … and I bought Mountain Duck which lets me mount remote sftp as a disk in Finder …
… and some other things…
That repo is long abandoned https://github.com/gritzko/swarm
Did CRDTs and local-first advance much since 2014? There is a bunch of research, way more CRDT libs on GitHub, but (somewhat) successful businesses you can count on one hand.
I guess, that is the actual challenge - figure out the business model.
> but I struggle with how to monetize truly local-first applications.
Their business model was give away and capture. Give away much of the possible revenue stream in order to lock in students, learning centers, governments, offices, and hobbyists.
That method of success has been well documented and replicated world wide.
The above method is how Google’s horrible products are currently winning.
Google is a serial murderer of its own products and services yet governments, schools, and companies fall over themselves to use Google products.
Capture is a valid, and proven, revenue strategy.
I doubt Gmail is going anywhere anytime soon, even more so on the workspace plans and for our company anyway that's the biggest Google product we bought into, ignoring Adsense, which is also going nowhere anytime soon.
Google drive also seems like one of those long support products but regardless for enterprise trusting a single cloud provider to host all your data is a disaster waiting to happen and most have on prem plus two clouds
It's easier to build a cloud based subscription business.
However a collaborative software is of course useless in the long term if you can't collaborate anymore.
When users subscribe they should be purchasing a license that renews periodically. Local-first apps should validate the license (based on its expiry) by connecting to the internet to ensure users are subscribed. If they're not subscribed or they don't have internet access, they cannot use pay-walled features. You should offer a free, fair, and robust export tool for those not subscribed, though unfortunately not many companies do this.
What am I missing here? The drawback is of course when customers don't have internet access but are still valid subscribers, so they lose access to pay-walled features. One option would be to only offer annual licenses (infrequent license checking), another would be to offer a complementary 7 day license extension for the short-term until the user reconnects to the internet (grace period).
Stop giving away your value proposition for free. Get paid fairly.
Why would one sell permanent ownership of a networked product? I've been seeing the rise of "lifetime" subscription levels (pay once) for SaaS products, but I'm curious as to what the actual long-term economics of it are.
If your cost of operations is not a one-time cost per user, I don't see how you can avoid a subscription model.
You wouldn't. Maybe TFA has an extreme interpretation of local-first, but the entire point of the article is eliminating the last vendor-controlled server from certain kinds of apps so that the user can own the software forever.
Obviously this doesn't work for all apps, and it sounds like OP may have one that needs some form of network component. In that case what you propose would work very well.
I am not too worried about piracy, as that is a battle you'll never win (games have been fighting this game for a long time). Create a good product that solves a real issue, get in front of people, and provide a good service, so that they are happy to support you in the future (either for updates on this product or for building new products).
Lately, I've also switched who I target. Before I was going more for basic website owners, that maybe don't even have a business. There were many problems with this: those customers don't really need such detailed analytics, they maybe don't have the technical expertise to self-host, they don't care about privacy as much, they would rather go for free or very cheap solutions, etc. Now I'm focused more on business and web agencies, which also enables the higher price (for them this is actually cheap, as Hotjar for example has plans starting at $800/month, while this is a one-time payment).
Going for the big customers is a lot easier than B2C, unless you have good distribution or get lucky to get viral.
Obsidian's model seems nice: base app is free, and then payment for the networked portions like sync+publish. However, there's little data available on how well this works and how big of a TAM you need to make it sustainable. Or if it's even possible without an enterprise revenue channel.
For those interested in building robust local-first + collaborative apps, I've been using Yjs for a few years now and have overall really enjoyed it. Multi-master collaboration also poses some stimulating technical and design challenges if you're looking for new frontiers beyond the traditional client-server model.