OCTO Speaker Series #7: Peter van Hardenberg

[idan]

Hello everyone! Welcome to the seventh installment of the OCTO Speaker Series, featuring Peter van Hardenberg! (@pvh on twitter and github)

@idan will be hosting Q&A following the talk. We are using this discussions thread for questions — if you'd like our hosts to discuss a topic, add it to this thread! We'll keep this thread around and link the recording of the talk when it's ready.

Be kind and thoughtful — we take our code of conduct seriously.

[jgaehring]

A significant feature of collaborative, cloud-based software is the ability to define fine-grained roles and permissions for who can read and write data. Examples include creating shareable links in Dropbox, setting protected ranges in Google Sheets, or even just creating roles for a WordPress site. How can local-first software achieve the same level of granularity, while remaining safe and secure?

[pvh]

Briefly, for those who come later, my theory here is that it's about attention, not permission. Don't disclose data you don't want to share, and if you do disclose it, ignore changes from people whose input you are uninterested in. This is a more scalable solution than trying to control and secure who can write: let everyone write, but be choosy about who you read and republish.

[jgaehring]

This really "clicked" for me during the talk. I can see there being some interesting UX consequences that fall out of this model*, but it seems like the correct framing. So thanks again for presenting this!

* eg, Alice allows Bob to read field_1 and field_2 in a document but only accepts writes for field_1. Bob pulls fields 1 & 2, modifies both, then tries to send both back to Alice. If we're treating the document as atomic, then Alice rejects both changes; if we treat the fields themselves as atomic, then Alice accepts field_1 and rejects field_2. In either case, what do you tell Bob? How does Bob get back to a state that can be reconciled with Alice, or how do you guard against broken states? etc...

[pvh]

This is an excellent question! I will only be guessing in my response, but broadly I suspect that the answer is to use document boundaries as intuitive attention-scapes. If you don't want someone to know it, don't put it in a document they can read. If you don't want someone to change something, don't listen to edits from them on that document.

I'm sure you could articulate a more sophisticated approach, but I think this would cover most cases and be easy to reason about.

[bjtitus]

I've heard Jason Fried, of Basecamp, mirror your thoughts about keeping old versions available to avoid "messing up the workshops/workflows" of users. Given that the mobile App Stores only make the latest version available, do you have any thoughts about shipping multiple versions of software, like Muse, without dramatically increasing complexity?

[pvh]

I didn't get into this in the session (we were already so over time) but I want to say that making interop between different software versions is just the beginning. If software interoperability is something both developers and end users can add to our built environments then we believe that could unleash a Cambrian era of software where software divergence (forking) becomes no obstacle to collaboration and interoperability and vast quantities of specialized programs could exist that would not be feasible today.

We talk a bit about this in the conclusion of the Cambria paper.

[cafca]

I think good tools for collaboration are the way to go if you want to extend the mind. I guess you made the issue tracker example for a reasson, it's something really useful that can be made better like a tool.

What other tools do you think knowledge workers are missing right now that can be made better as distributed software?

[pvh]

I'm going to avoid being too prescriptive here, and I gave some thoughts on the call but I want to say that I think I would encourage tool-makers to think about tools, processes, and material. Trello is compelling because it behaves like a tool: it can be adapted to many processes. The material of Trello is a "card". These cards can be comfortably adopted into many processes. You can use Trell for issue tracking, or recruiting, or a personal reading list.

The challenge is that, like a chisel, Trello is not self-describing. You can use it in many ways, and so it's possible to use it in effective or ineffective ways. The processes around Trello are cultural artifacts propagated through teaching and collaboration.

The natural tendency of modern design culture is to view this behaviour as a deficiency and engineer it away in order to "improve onboarding" or whatever. I think that's a real shame.

[brianjoseff]

What do you see as the path to widespread marketplace adoption of these ideas and architectures?

[pvh]

Developers will pick tools that let them make a living building great software for users they care about. Local-first software has a number of structural advantages over classic 3-tier webapps that should make it appealing.

First and foremost, it's cheaper and easier to build. You can ship a single codebase, you don't have to learn how to operate Zookeeper, and it doesn't cost you a heap of money when a free user starts dumping mountains of data into the system.

Second, local-first software should be better to use. That was the main thrust of my talk, so I won't reiterate the case.

The economic and cultural challenge, of course, is that our industry is currently oriented to building and funding backend-heavy SaaS businesses. The solution to getting great software is not to assume open source communities will come together around products. The relatively poor quality of Linux desktop software has basically demonstrated that. Instead, I would encourage local-first developers to think like SaaS businesses or shareware developers and figure out when and how to ask their users to become customers. I believe that because local-first software has favorable scaling costs it should be possible for a small team to run a very high margin business without having to build a massive team just to operate. (As a fun aside successful freemium businesses and 90s shareware companies both have similar conversion rates (4-5%) but the shareware companies were mad about piracy and the SaaS businesses are happily paying for all their free users as a marketing cost. Go figure!)