I feel like a broken record here: it is not an engineering problem.

Local-first and decentralized apps haven't become popular because SaaS has a vastly superior economic model, and more money means more to be invested in both polish (UI/UX) and marketing.

All the technical challenges of decentralized or local-first apps are solvable. They are no harder than the technical challenges of doing cloud at scale. If there was money in it, those problems would be solved at least as well.

Cloud SaaS is both unbreakable DRM (you don't even give the user the code, sometimes not even their data) and an impossible to evade subscription model. That's why it's the dominant model for software delivery, at least 90% of the time. The billing system is the tail that wags the dog.

There are some types of apps that have intrinsic benefits to being in the cloud, but they're the minority. These are apps that require huge data sets, large amounts of burstable compute, or that integrate tightly with real world services to the point that they're really just front-ends for something IRL. Even for these, it would be possible to have only certain parts of them live in the cloud.

▲

Leftium 4 days ago | parent | next [-]

Epicenter[1] is attempting to go against the grain here[2]. I'm not sure if it will require one of these SaaS to become a client for this business model to work...

> The long-term direction is for Epicenter to become a foundational data framework for building apps where users truly own and control their own data. In other words, the Epicenter framework becomes an SSO for AI applications. Users use Epicenter to plug into any service, and they'll own their data, choose their models, and replace siloed apps with interoperable alternatives. Developers will use our framework to build highly customized experiences for said users. To pursue that goal seriously, we also need a sustainable model that honors our commitment to open source.

> ...The entire Epicenter project will be available under a copyleft license, making it completely free for anyone building open-source software. On the other hand, if a company or individual wants to incorporate the framework into their closed-source product, they can purchase a license to build with Epicenter without needing to open source their changes and abide by the copyleft terms. This is the model used by Cal.com, dub.sh, MongoDB, etc.

[1]: https://hw.leftium.com/#/item/44942731

[2]: https://github.com/epicenter-md/epicenter/issues/792

	▲	DevItMan 3 days ago \| parent [-]
		Two things make local‑first frameworks break out: a boring hosted “default” and one killer app. Even if the vision is user‑owned data, ship a managed option with sane defaults so teams can try it in 5 minutes, then let them flip a switch to self‑host or bring their own storage/keys later. Pair that with a flagship app that proves the value (e.g., a shared notes/CRM/mail client where offline + conflict‑free collab is obviously better). Frameworks without a hero use case tend to stall because devs can’t justify the integration time. On the business model, dual license works if you de‑risk the integration: stable plugin ABI, permissive SDKs, and paid “closed‑source embedding” tier with SLAs and on‑prem support. Where I’ve seen revenue actually land: (1) paid sync/relay with zero data retention, (2) enterprise key management and policy controls, and (3) priority support/migration bundles. One caution: “privacy” alone doesn’t convert; solve a concrete ops pain. I built CrabClear to handle the obscure brokers others miss, and the lesson was the same—privacy sells when it eliminates a specific, recurring headache. If Epicenter can quantify one such headache and make it vanish out‑of‑the‑box, the model becomes much easier to sustain.

▲

cosmic_cheese 4 days ago | parent | prev | next [-]

Cloud SaaS services are often extremely heavily marketed, too, often with a VC-backed ad spend pool. That’s difficult if impossible to compete with.

There’s also an upcoming generation that doesn’t know what a filesystem is which also doesn’t help matters.

▲

api 4 days ago | parent | next [-]

> There’s also an upcoming generation that doesn’t know what a filesystem is which also doesn’t help matters.

This is why I sometimes think it's hopeless. For a while there -- 90s into the 2000s -- we were building something called "computer literacy." Then the phones came out and that stopped completely. Now we seem to have inverted the old paradigm. In that era people made jokes about old people not being able to use tech. Today the older people (30s onward) are the ones who can use tech and the younger people can only use app centric mobile style interfaces.

The future is gonna be like: "Hey grandpa, can you help me figure out why my wifi is down?"

	▲	cosmic_cheese 4 days ago \| parent [-]
		I know some of us technically inclined millennials intend to make a point of (or are already in the process of) ensuring that their kids are computer-literate. I’m not a parent but should that change I would certainly plan to. Whether or not that gets passed down to the grandkids or not is out of our control, but gotta do what you can right?

▲

4 days ago | parent | prev [-]

[deleted]

▲

jjcob 4 days ago | parent | prev [-]

I don't know. I think it's a lucky coincidence, but I genuinely think that cloud based solutions are better.

Local first tends to suck in practice. For example, Office 365 with documents in the cloud is so much better for collaborating than dealing with "conflicted copy" in Dropbox.

It sucks that you need an internet connection, but I think that drawback is worth it for never having to manually merge a sync conflict.

▲

api 4 days ago | parent [-]

Those technical problems are largely a result of trying to shoehorn collaboration onto older local-only PC era apps that store data in the form of simple files. For really rich collaboration you want something designed for it from the ground up, and Office is not. Office pre-dates even the Internet.

That has nothing to do with where the code lives and runs. There are unique technical challenges to doing it all at the edge, but there are already known solutions to these. If there was money in it, you'd have a lot of local first and decentralized apps. As I said, these technical challenges are not harder than, say, scaling a cloud app to millions of concurrent users. In some cases they're the same. Behind the scenes in the cloud you have all kinds of data sync and consistency enforcement systems that algorithmically resemble what you need for consistent fluid interaction peer to peer.

▲

jjcob 4 days ago | parent [-]

It's not a technical challenge, it's a fundamental problem.

When multiple people work on a document at the same time, you will have conflicts that will become very hard to resolve. I have never seen a good UI for resolving non-trivial changes. There is no way to make this merging easy.

The only way to avoid the merge problem is to make sure that the state is synchronised before making changes. With cloud based solutions this is trivial, since the processing happens on the server.

The local first variant of this would be that you have to somehow lock a document before you can work on it. I worked on a tool that worked like that in the early 2000s. Of course that always meant that records remained locked, and it was a bit cumbersome. You still needed to be online to work so you could lock the records you needed.

▲

api 3 days ago | parent [-]

It’s barely different from having multiple fat single page web apps editing a file in the cloud. All of those have local replicas of the data and present as if everyone is editing at once.

There are multiple ways to do this, like CRDTs plus raft based leader signaling for conflict resolution. The latter signaling requires almost no bandwidth. Raft based time skew adjustment works too if your problem domain can accept a small amount of uncertainty.

Like I said a lot of these same kinds of algorithms are used cloud side. All the big cloud stuff you use is a distributed system. Where the code runs is irrelevant. The cloud is just another computer.

	▲	jjcob 3 days ago \| parent [-]
		All these algorithms arent going to help if user A changes a headline from Arial to Helvetica while user B changes it to Helvetica Neue. There is no way to tell which of the changes should win. That's why most applications decided to require users be online for edits. when you have to be online, the chance of simultaneous edits becomes so small that you can just show an error message instead of trying to merge. The online requirement also ensures that you are notified of conflicts immediately, which is vastly preferable to users. Nothing worse than working on a document for hours and discovering someone else also worked on the same document and now you have two edited copies that someone needs to consolidate. That's the reason why offline first is becoming increasingly unpopular.