Local-first software (2019)

For some reason, "cloud computing" has become a bogeyman and therefore corporations paying for it are clueless "sheeple".

To help prevent the phrase "cloud computing" from distorting our thinking, we have to remember that companies have been paying others for off-premise computing without calling it "cloud" or "SaaS" for decades before Amazon AWS, Salesforce, etc existed.

Examples...

In the 1960s, IBM's SABRE[1] airline reservations system was the "cloud" for companies like American Airlines, Delta, etc.

In the 1980s, many companies used to process payroll in-house accounting software and print paychecks on self-owned dot-matrix printers. But most companies eventually outsourced all that to specialized companies such as ADP[2].

Companies tried to manage employees' retirement benefits on in-house software but most outsource that to companies like Fidelity[3]. Likewise, even companies that self-fund their own healthcare benefits will still outsource the administration to a company like Cigna[4]. Don't install a bunch of "healthcare management software" on your own on-premise servers. Just use the "cloud/SaaS" computers that Cigna has.

Some companies (really old ones) used to print their own stock ownership certificates and mail them out to grandma. Now, virtually every company outsources that to another company. Most companies that have Employee Stock Purchase Plans outsource the administration of it to a company like Computershare[5].

The major difference with "cloud" terminology taking hold is that services like AWS is offering generic compute (EC2) and non-vertical industry solutions. Otherwise, the so-called "cloud" has been going on for decades. Amazon AWS made "cloud" really convenient by allocating off-premise resources via a web interface (dashboard or REST api) instead of calling a salesperson from IBM/ADP/Fidelity/Cigna/etc.

That doesn't mean it's always correct to buy into everything the cloud offers. Pick and choose the tradeoffs that make financial sense. Netflix got rid of their datacenters and moved 100% of the customer billing to the cloud. But Dropbox did the opposite and migrated from AWS to their own datacenter. They're both correct for their situations.

>, when some of the bigger service providers will eventually fall over (which they will).

The big established vendors like AWS, Azure, and GCP ... all have enough business that they will be around for decades. If anybody will exit, I'd guess it would be the smaller players like Oracle Cloud.

[1] https://en.wikipedia.org/wiki/Sabre_(computer_system)#Histor...

[2] https://en.wikipedia.org/wiki/ADP_(company)

[3] https://www.fidelityworkplace.com/

[4] https://www.cigna.com/assets/docs/business/medium-employers/...

[5] https://www.computershare.com/us/business/employee-equity-pl...

This article also quickly moves past "local-first" software to conflict resolution which, in my opinion, is a distinctly different issue. It's certainly not reason enough to hold off offering users a local-first option.

At this point I believe that since it can be done it should be done. I'll even go so far as to say it's a necessity. At some point users will understand it's a necessity and demand it. All that really needs to happen to convince them is one big incident where they lose access to their data for an extended period of time, or worse yet, lose all their data forever, and it won't matter why or how.

Aside from that, as more app makers start offering local-first options and users begin to see the benefits of that they will begin to demand it. That could take some time, but I expect it's inevitable.

There are other benefits to a local-first approach for developers. Take a "Contacts" app for example. If we have a standard for saving contacts data on the client side that any app could access this would give users and developers options to create and use new apps and features that all use the same data.

CouchDB & PouchDB.js provide a pretty solid and easy way to do this right now. Installed on the user's desktop PC, CouchDB provides the missing link to a robust client side web app runtime environment.

There may be other ways of achieving this right now, but I am not aware of them.

https://martin.kleppmann.com/papers/pushpin-papoc20.pdf

You can also try PushPin for yourself: https://github.com/automerge/pushpin/

likely outdated binaries are available here: https://automerge.github.io/pushpin/

Also, we're currently in the midst of a new project called Cambria, exploring some of the consequences and data demands for a new Cambrian-era of software here: https://inkandswitch.github.io/cambria/