☁ “Local-first software: You own your data, in spite of the cloud”

[pathall]

Any article with a cuneiform tablet in it is worth reading in my book, but this would one be even without one!

Local-first software: You own your data, in spite of the cloud

Here’s the PDF:

https://www.inkandswitch.com/media/local-first/local-first.pdf

Kleppmann, Martin, Adam Wiggins, Peter van Hardenberg & Mark McGranaghan. 2019. Local-first software: you own your data, in spite of the cloud. Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software , 154–178.

This article is not about language documentation, per se, at all, but it is a timely idea, and I think it’s very relevant to many issues in archiving and (potential) online collaboration in documentation (with some provisos, mentioned below). The article introduces a useful term, Local-first software. As accustomed as we are doing “doing everything on the web”, there are some serious drawbacks to putting everything in the cloud. “Local-first” is perhaps best understood in terms of the seven ideals that the authors list:

In this article we propose local-first software, a set of principles for software that enables both collaboration and ownership for users. Local-first ideals include the ability to work offline and collaborate across multiple devices, while also improving the security, privacy, long-term preservation, and user control of data

Seven Ideals for Local-first Software

1. No Spinners: Your Work at Your Fingertips
2. Your Work Is Not Trapped on One Device
3. The Network Is Optional
4. Seamless Collaboration with Your Colleagues
5. The Long Now
6. Security and Privacy by Default
7. You Retain Ultimate Ownership and Control

It’s interesting to think about how these principles compare with Bird & Simon’s Seven dimensions of portability for language documentation and description (hey, there are even seven of them, cosmic):

Seven Problems for Portability

1. Content - terminology, accountability, richness.
2. Format - openness, documentation, machine-readable, human-readable
3. Discovery - existence, relevance
4. Access - complete, unimpeded, universal
5. Citation - credit, provenance, persistence, immutability, components
6. Preservation - long-term, complete
7. Rights - documentation, research

Yes, these are very different concerns, but there is certainly overlap and, I would argue, similar motivations. The Rights and Access categories in this context are interesting to compare with what Kleppmann et al. refer to mostly as security, privacy, and collaboration. As Bird & Simons recognize, rights and access in language documentation and description may have may present particular complexities in the context of language communities, and Kleppmann et al. may not be thinking in those terms.

Still, if we are going to implement software for language documentation, practical problems like the ones they are addressing require solutions (even hard problems like conflict resolution in real-time collaboration.)

[lgessler]

This article is so exciting for its vision of the future, and at the same time rather frustrating–it’s clear we have the technical means to begin shifting towards local-first apps, yet there is little economic incentive for big companies to do so. Socialize Google, imo.

I’ve been watching CRDTs very anxiously for the past year or so–in theory they promise the developers who use them worry-free offline support and data synchronization (incl. real-time), and many people do use them in production, but (I’ve read) they’re complicated to implement and existing implementations for JS are somewhat feature-limited and reportedly sometimes suffer from performance issues. In my personal evaluation I feel like they’re not quite far along yet to the point where I’d use them in a high-stakes project, but wow, may the future come soon.

[pathall]

Hi @lgessler! I agree that data synchronization is a huge problem, but the implementation details are above my pay grade. It sounds like you are familiar with this topic, you are therefore hereby declared (among all your other illustrious titles) Docling Minister of Synchrony . Don’t let it go to your crown!

To me real-time collaboration is still in the blue-sky department — we have to figure out good web-based user interfaces for building structured documentation before we can think about how to get multiple people working on the same data simultaneously. The dominoes certainly exist, but I don’t think they’re set up yet.

There something about the term “local first” that really speaks to me, partly because it expresses a crucial feature of the web platform that is simultaneously awesome and really weird: the web platform has turned into an application development platform that doesn’t require a network. You can write “local first” software that can run on your laptop just as if it were a compiled app in Java or C++ or whatever.

But that capability is still wearing client/server, request/response clothes, and the browser that runs such apps still has a URL bar, and doing File > Open in a browser (for instance) is still kind of bizarre, frankly — I have seen a lot of people go “huh, why would you do that?” if you even point out that it’s possible.

Explaining this stuff is so hard. I mean, even understanding it is hard. Sample explanation:

Programmer: You know what a browser is, right?
Friend: Of course, duh.
Programmer: So how would you describe what a browser does?
Friend: You use it to get stuff off the web, and send information to websites for finding and sharing stuff.
Programmer: Right ok, so, that’s how the web was, originally, but did you know that it can do other stuff now?
Friend: Uh, what do you mean?
Programmer: You can run programs inside a web browser, on your computer.
Friend: Well, obviously — I mean, I do my email in a web browser, and that’s a program inside my computer.
Programmer: But not exactly, because you’re sending information back and forth to gmail.com or whatever when you’re doing your email. I’m talking about programs that don’t necessarily have to send information to a server at all.
Friend: Well, why would you use a browser to do that, when you could just use some other program — like, if you’re going to have a text editor or something, why not just use a text editor? What’s the point?
Programmer: Well, because the web is a really good system for making cool applications now, better even than some of the old systems that people used to make things like text editors.

So at this point the Friend is already like, this makes no sense. Normal people think of web pages and “programs” (applications) as being s and es. Or something. why is there no orange emoji?!

Programmer: I guess I’m saying that it’s helpful to rethink what an application is in the first place. If we think of an application as just “an interface that helps you do stuff with data”, where ‘data’ can be whatever kind of information, then making an application that “lives” inside a web browser makes sense.
Friend: Okay, but browsers are for doing stuff on the internet.
Programmer: Yeah, that’s true historically. But I’m talking about “new school” internet stuff. You can write a program that has the same “shape” as you would use to send info off to a server, but you can also use it with data that you manage “locally” — on your own computer.
Friend: Okay. I mean, I don’t see why that is so great, but ok.
Programmer: It’s great because building applications that live in the browser is easy and flexible, and the web has all kinds of capabilities that can be easily programmed into an application, like media, graphics, all kinds of interactivity…
Friend: Well I guess that sounds nice. So how would I try one of these things?
Programmer: Well, here’s a URL…
Friend:

Because why do you need a URL to do something which is only online? I mean, and then you have to explain that sometimes you really want a local server too, and you go to to a local host, and you run a… I mean, that stuff just gets weird.

I’m not sure what the answer to this sort of thing is. Maybe it’s something where a subset of people who are willing to endure weirdness try offline apps for a while. Maybe the terminology will evolve (“tab apps” or something?). It’s not easy yet, and even when all the parts are working, it’s still unfamiliar to most people.