While I agree with the sentiment of the article most users do not even know what a server is, much less capable of self-hosting. Syncing a folder over Dropbox or Google Drive, though, is simple enough.
[0]: https://nestful.app
For your app, how do notifications of changes get propagated? Does it depend on the backend (Google Drive, etc) supporting that, or does it just do polling or something?
Yes, I agree this is not an end-all be all solution, but the tradeoff is often worth it.
> Local-first software enables greater longevity because your data, and the software that is needed to read and modify your data, are all stored locally on your computer.
There are many ways to achieve this goal - open document standards, open source servers, a escrowed release of the server, or this idea of a bail out system for taking the current version and self hosting it. All are commendable.
Actually achieving all seven ideals is hard, and there isn't much modern software that does it. But in my view anyone trying to achieve even a few of the ideals is making strides towards a worthy goal.
There is a lot of exciting stuff happening in the local-first software movement at the moment, and a lot of that is related the sync engines that are being built (disclaimer: I work for ElectricSQL, we are building one). These sync engine don't inherently make your software local-first, fitting all the ideals, but they do make it a lot easer to do so. They are an important building block. But there is more needed, we need more open document standards - Automerge, Yjs, Loro and the other CRDT data structures are perfect lower level data structures to build these higher level abstractions on. Martin Kleppmann has talked quite a bit about sync engines that are disconnected from the underlying application, essentially pluggable sync engine, you choose who to use to sync you copy of a document or application - I'm excited to see where this goes.
But, we also need to free up the application distribution platform. The app stores are walled gardens that prevent some business models, native apps (while performant) are tied to a specific platform (or even version!), and the web is inherently tied to servers and browsers. The web platform though, i.e. JS, HTML, CSS, is perfect for building high longevity software that runs anywhere, on any device, the issue is the distribution. We need a middle ground, an application package that built on web standards, but isn't tied to a server. I want to download a bundled app to my machine and have a copy, email to a family member, or even open and hack on it. Thats the final missing piece.
A downloadedable app, with an open and pluggable sync engine would achieve the same goles of this ejectable idea.
The primary barrier to an entirely server-free or server-agnostic webapp ecosystem is browser vendors choosing to seal the newest JavaScript APIs behind "secure contexts" which are only available to documents served over HTTPS.
The average internet user could be exploited fairly easily if every HTML file had immediate access to all the lower level APIs being introduced[0], and we end up looping back around to some sort of signing or alternative install method (pwa).
Curious to find the balance between distributable and "safe" enough to achieve wide adoption.
0: https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
Somehow, this thing is still not available for testing yet. Not hating but isn’t this supposed to be the category where new solutions launch every single day? While I am still very much interested, I’ve lost any hope that this will become a real thing to try out any time soon.
We're very much still working on it though and it's finally at the point where it's just some polish, so pretty sure next Q.
- They don't get backed up or synced between devices.
- It's very easy to delete them (e.g, you clear browsing data) or lose them (e.g., you get a new computer).
- Users barely know about them, so they don't know they should "preserve them". For users PWAs are basically just a way to get a launcher for the app, and they have no visibility over locally-stored data.
I think browsers right now are not the right platform to give a future-proof guarantee. Disclaimer: I say this while working on a product that wants to become that platform¹, so I've had the chance of thinking about this problem quite a lot in the past few months.
¹ I wrote a bit about it at https://pscanf.com/s/340/, if you're interested.
In their current state, I personally don't find PWAs + local databases ergonomic enough. So actually what I'm hoping to get out of the platform I'm building is - somewhat egotistically - an alternative that works for me personally and possibly for a few others like-minded individuals, not a browser replacement to take over the world.
I would love to see another way to deploy local software, aside from building dedicated Windows and MacOS apps. There are efforts in the Docker container world to provide smaller deployment frameworks. There are efforts in the WASM world to replace containers with WASM deployment (which works well in browser, BTW).
Is it still?
From what I saw personally, Azure is eating through this market. They give enough of the right guarantees that mutlinational corporations are fine with processing all their (and their customers') data in it, and from some quick research I've been involved in, it's the one (and AFAIK the only one) big cloud provider you can use in EU with sensitive data in a compliant way, up to and including medical data.
Beyond that, what's really left that most business users wouldn't just prefer to stuff into Azure and stop worrying about handling it?
I agree as well here, and from that complement I hope to be able to draw a small community around my product. Still, I pessimistically feel that it's too small a share of users to make browser vendors take notice and build features for them. But of course I'd love if they'd prove me wrong. :)
You can always start with the cloud version and then transfer to self-hosted if you change your mind and continue right where you left off. Not just that, you can also move from self-hosted back to cloud. That makes it easier to get start with a service because you're free to change your mind without lock-in or risk of painful migrations.
As software updates, the shape of data changes. This would make a significantly harder problem to solve.
Is anyone not just me hesitant to run their own servers? I think about patching and it becomes a full on devops job to set up something safe and stay on top of upgrades etc.
One idea Ive had is that if the web facing part of the software is just a form saver. It persists the form to disk for retrieval by the local-first server that I run on my laptop after pulling all records.
Would like to talk to persons about this topic: local first and low-maintenance service design SAAS
I wrote about an imaginary cloud service that would be about hosting forms for batch processing later this is similar to the workspace.zip in this article but this is used for the app itself.
https://www.halfbakery.com/idea/Secure_20Form_20Endpoint_20S...
The "server executable" is where basically all of the value provided by these kinds of companies exists. If it were freely downloadable and self-hostable by customers, then the company would be giving away its main value prop, and would only be able to generate revenue by, I dunno, acting as a hosting provider? Those margins are tiny and always getting smaller. It doesn't make sense.
The main thrust here is if you buy a “lifetime” license, it should be your lifetime, not the lifetime of the company that sold it to you.
If you sell a lifetime license for your software, then the customer provides a single one-time payment (essentially CapEx) which obliges you to indefinite long-term work and support and maintenance (costs). But you can't support indefinite future costs with a single payment from a customer. The math doesn't work.
Again, if the data is small enough that it can be downloaded and self-hosted in the first place, then almost certainly hosting costs are statistically zero, compared to the R&D costs of building and maintaining and evolving the .exe file that's actually providing the business value.
You could run an ejectable server with other funding models. For instance, you pay yearly subscription and get updates within that year, but you get to keep your version forever if you want.
Or your server phones home for a license, but perhaps with an escrow license key if the company goes bankrupt and you have to pay subscription.
Either way, the business model is somewhat independent of the ejection mechanism.
EDIT: whoops, I missed the second part of your question ("...how can it be maintained and enhanced over time..."). I've already implicitly answered that in my original reply, by claiming that the attractiveness of "optional hosted services" is higher than the average HN reader - who is predisposed to be a tinkerer, a self-hoster, someone who cares about DIY and learning - would assume. There are plenty of existing companies who make their base software available for free, but make a healthy income off of hosting and support. This article doesn't propose anything radically new in that regard - just extending it to "ejectability".
Someone else comes along, downloads your server.exe, and offers hosting and professional services themselves, as a competitor. To a customer there is no difference between you.com and competitor.com, they're hosting the same thing on different domains. And the competitor gets their revenue the same way you do, but they don't have to spend anything on server.exe, because you're doing all that work already.
Again, this math doesn't work out, at least not for you. The competitor will always come out ahead.
If the claim is that you have some unique ability to produce revenue that isn't available to third parties that download and use your server.exe, then whatever that is, it's not part of the server.exe, just by definition! You've got the server.exe you offer freely, and a different my-server.exe that only you can operate and which has value that only you can extract. So we're back to square one.
I still don't think this is an intractable problem, though - there are still some properties that provide a moat to allow you to survive:
* the experience of having developed the server.exe means that you have some institutional knowledge that makes you better able to offer support - you don't have to "learn it from scratch"
* you can offer upcoming features to your paid subscribers earlier than they get released in the free version
* name/brand recognition is A Thing - there is some non-zero dollar value that customers will assign to the comfort and security of buying from "the real source"
But I do recognize and agree that those are slim and not _necessarily_ decisive. In some cases, the differential revenue accrued by those things will be enough to continue development on the product that is otherwise given away for free; in others, it won't. A careful balancing act, to be sure!
Maybe the margins aren't as high as some would like, but it's definitely viable. Example: Email.
If you're curious, check out this app: https://umai.noeldemartin.com/