there's a group, and this is what I call the Barefoot Developer Group, who really
do want more agency over their computers.
They're, like, currently using Airtable and Notion and like
spreadsheets and like doing really crazy, complex things with them.
But they also hit the limits of these apps.
And they keep being like, well, how do I make it like do this thing?
And I'm like, well, you can't, like this other company controls that software.
You can't.
add that feature onto it.
but these people, if given access to a language model, and kind of taught
how to prompt it in a way where they can clearly ask for what they want,
it can write the code for them.
welcome to the Local First FM podcast.
I'm your host, Johannes Schickling, and I'm a web developer, a
startup founder, and love the craft of software engineering.
For the past few years, I've been on a journey to build a modern, high quality
music app using web technologies.
And in doing so, I've been falling down the rabbit hole of local first software.
This podcast is your invitation to join me on that journey.
In this episode, I'm speaking to Maggie Appleton, a designer, anthropologist,
and developer who's recently explored the world of local first software
by giving the closing keynote of the first local first conference.
In this conversation, we dive deep into the topics of her talk, including home
cooked software, the ideas behind barefoot developers, and how AI complements
local first software development.
Before getting started, also a big thank you to Rosicorp and
Expo for supporting this podcast.
And now my interview with Maggie.
Cool.
Hey, welcome, Maggie.
Thank you so much for making time today to come on the show.
How are you doing?
Hey, yeah, I'm really good.
I'm excited to be here.
Thank you so much for having me on.
So for the few in the audience who don't know yet who you are, would you
mind briefly introducing yourself?
Sure.
Uh, I am a product designer slash developer of some sort.
and I've been working in developer tooling.
for I think my entire career at this point, so pretty much 10 years, and I do
a lot of work that's like doing designs for development tools, but most recently
I was a designer at a company called Elicit where we were using language
models to make software for scientists and researchers, so that dropped me into
the world of language models and AI and machine learning, so I've been thinking
a lot about that for the past two years.
Amazing.
I want to give a little bit of background since we just had
the local-first conference in Berlin a couple of weeks ago.
And I've been getting in touch with you, must have been at the beginning
of this year and through some common friends we've been introduced.
And I was hoping to get you somehow interested in speaking at the conference.
And when you and I were on a Zoom call and I've been suggesting this topic to you.
You seem super polite, but you weren't quite sure what you should say about
local-first since you haven't really been building something with local-first.
And now a few weeks later, you got back to me, said, okay,
you're, you're down to do it.
And you've delivered the closing keynote and I think it was hands down
by most people, their favorite talk of the day and really blew me away.
so we want to go into the talk, momentarily, but maybe starting
first, like what convinced you to do the talk and what has since
seemingly local-first pilled you?
Yeah, um, So yeah, when you first reached out, I mean, I had heard of
what, I had heard of local-first, mostly from Ink And Switch's famous
essay, like, I follow a lot of Ink And Switch's research, and I had read it,
but at the time was like, okay, this has a lot to do with databases, and I,
I like, I do front end web development, so I know nothing about back end.
I hadn't even thought to look into it, or it just never appealed to me, because
Most of my motivation for development is often, like, I want to make a
cool thing animate on, a screen, or, like, I want to see, something move.
I like the reactivity, but, you know, I'm, like, JavaScript.
so I'd never thought of backend as an interesting area or really
understood, like, why I would want to be interested in it.
so I'd read the essay, been like, cool, that's not my thing.
I'm not one of these backend people.
Um, so when you reached out, I had to go Googling again and be
like, what, what is local-first?
Like, what is this concept?
Like, why would I care?
because I was compelled by a lot of the people who I saw, were going to
go to this event, or were involved in the local-first community, were
people who I knew were working on really interesting stuff and who had
really interesting original thoughts about ways we should build software.
Not just from a technological perspective, but from like a
cultural, social perspective.
Which is really the thing I love, is thinking about, like, who's building these
tools, who are they building them for, what are their implications in society,
like, how does this affect equality and economics and, like, everything else
that is not just, like, what code are we writing and, like, you know, how
do we architect the app kind of stuff.
so once he reached out and I started googling and thinking about it, I saw this
connection in things that I care about.
with things that I saw that the local-first community cared about,
which is things like data ownership, people being able to kind of own
and control their own software.
and things working offline for me is, it's quite important in like a very sort of
banal personal way in that, like I spend a lot of time on the tube, like doing stuff
on my phone where there's no wifi, like a lot of time on the tube and a lot of
time in airplanes where there's no wifi.
So just personally, I like need a lot of stuff to work offline first and, and I
had also an understanding that in a lot of the world there's very limited internet
connection or it's very slow, like the vast majority of people like might not
have constant stable fast internet access all the time, and I hate the idea that
we're always designing for a context where we do have that, and so we assume
that everyone does, but this is like, like, Gets into the inequality stuff
and the like, you know, designing for everyone in the world, you need to have
different systems than if you're designing on a 16 inch MacBook in San Francisco.
Yeah, totally.
I've lived briefly for a year or so in London as well.
And I do remember that I think you had some connectivity, at
stations, but maybe not in between.
And sometimes you're also like, as you're leaving this, the station,
your device thinks, Oh, I have some connectivity and it tries to do
stuff, but this is actually the worst.
So I feel like a lot of software works more reliably on a plane where usually
you're just entirely offline, but on a train, it's much more tricky because
you have sort of this intermittent, and unreliable connectivity.
And I think this is where software really struggles.
So I know exactly what you're talking about there.
But as you were preparing for the talk, how did you find sort of like the, the
topic that you wanted to talk about?
It was definitely quite hard.
I mean, I liked this because right when you kind of reached out and then
I liked that you said, you know, you can talk about whatever you want.
I mean, it needs to be about local-first, but like take
whatever spin on it you want.
That's really nice because I like that kind of freedom in conference talks or
doing any kind of research where I can go, Okay, I'm going to think about the
things that I think are interesting trends that are unfolding or that
are topics that I care a lot about.
And I'll just find a way to like weave them in because most of the
time everything is interconnected.
Like this is all one, you know, one like software development philosophy
that we're all trying to figure out.
and it was once I figured out how that local-first, I felt like had a strong
connection to the world of, what, um, Robin Sloan came up with this phrase
called home cooked apps or home cooked software that I had been collecting
information on for like a year at that point, I have this note taking system.
I will just like collect examples of every single time I see someone building
something that is just for them or just for their family or just for their local
neighborhood, this very like local, you know, just for me and my people,
not meant to scale, never going to be a VC startup, just like I'm solving
my own problems kind of software.
I'd written essays on this before.
Like I wrote one called folk interfaces about people kind of like reusing existing
interfaces to make these kinds of apps.
So I had a ton of content and a lot of thoughts on this topic.
And it was when I looked at it and I was like, Oh, like local software.
If you take that like at face value, that is like local to me, my family, my
community, my neighborhood, my country, whatever it is like near and close to me.
it might also mean the data lives on my device and the way that we
use it in local-first software.
But I realized there was like, Oh, there's this interesting interplay
where we can say local as in data or local as in culture and community.
And once I figured out that connection, I went, Oh, this totally can work.
Like I can build an argument around this, that actually connects
these two together and can make.
a bit of a, an ask to the local-first community to also care about this other
version of local that I care about.
So you didn't just go for software for yourself and like your local
context, but you found a way to pose the question in a much more globally
impactful way by, I'm not sure, I think you introduced and like you came up
with a new concept with a new term that you call like the Barefoot Developer.
And put that into perspective and into context with local-first software, home
cooked software, would you, for, for those in the audience who haven't seen
your talk yet, highly, highly recommend watching the talk also, like not just
hearing the talk, but watching it.
You've, as a designer, I think there's no one out there who's able to as a visually
compelling and clear way, find visual narratives that makes this even clearer.
So I highly recommend watching the talk, but would you mind briefly
giving the idea of the talk?
Sure.
Um, so yeah, I came up with this concept called Barefoot Developers.
and this, name comes from the concept of barefoot doctors,
which was this initiative in Maoist China in the 1950s and 60s.
It was not actually run by Mao, you know, he's a bad person, etc.
But like, probably someone else in his cabinet who was very smart
started this movement of barefoot doctors where they would take
people from very rural villages.
And this was at a time where there was very low health
care access in rural China.
There's just tons of people spread out.
There's not a lot of expertise in these local places.
And they would pick, like, one person from each village, bring them into
the cities, and train them up in, kind of, basic medical healthcare
practices, like, immunization, right?
Like, treating basic ailments, just, like, giving people
nutrients, and this kind of thing.
And then send them back to their villages, where they are, like,
local, everyone trusts them, everyone knows them, and then they provide
healthcare for the people around them.
And this worked really well.
It, like, raised life expectancy a ton, and the whole philosophy of it
was, like, we're taking, the power, not away from, but we're distributing
the power from these, like, very urban centers where they have all the medical
expertise out to everyone, out to all these very rural, poor villagers who
now can have a better quality of life because we're giving them access to,
to proper health care in a sustainable way, this is kind of a famous project.
And people ended up using this phrase of barefoot.
Insert your profession here in a number of different ways.
There's like barefoot designers, there's barefoot architects, and
the whole philosophy is redistribute the power away from the urban elite
and into like the rural masses.
So, People advocate for this in all kinds of ways, but I kind of looked
around and was like, no one's advocated for this in development so far.
And it's the same philosophy as end user programming, as the other word we would
usually use for this philosophy, is like, normal people should be able to program
and have agency over their computers to the same degree that programmers do.
Now, In reality, we know that's really, that's a hard, like, difficult ask, right?
As programmers, we deal with all this, like, complexity.
There's a reason it's a profession.
There's a reason it's a highly paid profession.
There's a reason that not many people, like, have enough skills and knowledge
to do it at a really high level.
It's just, it's incredibly hard, right?
Computers are super complex.
It's all these edge cases.
We know it.
Just like layers of complexity, just 60, 000 layers of complexity in every app.
Like we are struggling to make the apps work well, let
alone some end user doing it.
but the argument is, you know, maybe they don't have to be able to build
Facebook by themselves, but surely they could build some software, some
programs that serve their needs, that solve their problems in a way that no
giant VC funded corporation in California ever would or would ever think to,
because people who are far away in very rich urban areas don't understand the
problems of people all around the world in all kinds of different communities.
And probably shouldn't try because it's usually quite, uh, I don't know,
like colonialist in a certain way.
Right.
Trying to say like, Hey, you know, whatever it is, a street seller in
Turkey or like a homemaker in Tokyo.
Some like bro, California, VC guy shouldn't be trying to solve their
problems because he can't, he can't, there's not enough Zoom interviews that
are going to give him the context to solve their problems well, and they
should have the power and the tools and the agency to solve their own problems.
, and you know, sure in the areas of design and architecture and healthcare,
but also software, computers are part of everyone's lives and they should
have more agency and control over them.
So, sorry, that was the long version, but like, that is, that is the concept
of Barefoot Developers are, people who are part of local communities who
have enough programming knowledge and skills to build software for their
communities and solve problems for them.
It's not everyone, right?
Like, not everyone, like, nurses and teachers and whatever,
don't need to learn to program.
But if you can have one person, like, who's in their neighborhood or in their
school who can, then you get that person to build all the software for them.
I love that idea and, uh, I agree that this is thoroughly needed.
and I think most software that we use on a daily basis is , by a super wide margin
built by folks in San Francisco or New York or like in some like Western hub.
but this is where not everyone in the world is living.
And so if you're just also look, looking at the density.
and distribution of datacenters If you're looking into the global south,
you don't have, nearly, nearly, uh, as many data centers, et cetera.
And you can only think about like how poorly the Western
made software is running there.
But we could.
from a technological perspective, built as an entirely different way.
So this maybe leads to a question I'm curious about.
why hasn't the idea of a barefoot developer, why hasn't
that been a thing before?
Why hasn't that existed before?
And why can't this change now?
See, it's interesting.
I think, it probably did exist before in the earlier days of computing.
When, in a way, like, before GUIs, and before, like, we got all the complexity,
all the wonderful complexity of, like, the web, and, like, more sophisticated,
more complex software engineering stacks, right, before we all had, like, Node and
NPM, like, I don't know, just backends, and just, we were able to build much
more impressive stuff in, like, the maturity and rise of personal computing
and software, but it did mean that it became such a highly specialized, complex,
professionalized, thing, versus I think in like, let's try to figure out if these
are the right years, but the 80s to 90s when it was still the command line, like a
lot of people could build their own little things in like Linux, or just like little
command line scripts, it was probably a lot more accessible that if you did on a
computer, you probably knew how to program it versus now, that's not true at all.
so, and even I think in the early days of the web, like, you know when
WordPress was still the hot thing?
I mean, it is still the vast majority of the web is WordPress, right?
Still, vast majority of websites.
But I think early on, it was like, you could just kind of get in there and like,
tinker on your own site in a way that now feels a lot more inaccessible, like
now that we have, like, bigger build chains, right, and all these frameworks.
It feels a little bit illegitimate to just, like, spin up a WordPress
site to try to build an app.
You're probably going to reach for React if you know what you're doing.
I mean, you should just reach for, like, HTML and CSS, sure, like,
but most of us reach for React.
in a way that if you're just, like, a, you know, someone in your neighborhood
trying to build something, like, set up a community newsletter or, like, help
build some script for your local library.
you probably don't know what tools to use or like how to use them well.
You probably are like just using something like Airtable or Notion,
which is great, but you don't really have the same agency and power as
someone writing command line scripts.
So, I have some sense that we had more of this earlier on in computing, and
as it's gotten more complex, it's like we, maybe we're on like a little bit
of a curve where it needs to come back down the other side of complexity, or
we need to build tools that simplify it for people to be able to build their
own software, but we're in some, what I call like the high modernism industrial
phase, where everything's done in these like big centralized hubs and it's not
distributed across everyone's tool set.
Yeah.
So just from the perspective of a software developer, I can think of so
many use cases where I would love to build a little tool for myself, but with
the stacks that we have available for the last 10 years or so, there's like,
Just my mind is typically approaching it the same way as like how I would
build a software product for a startup.
And that is like way overkill.
There's like so many layers of complexity that by now we're just
used to, like there's like the hammer that we're used to using, that it
sort of like kills the entire idea.
In the initial phase where I don't even get to build it because
I already know like, Oh, I've, but I know all the implications.
I need to build this.
I need to deploy that.
And like, if that thing changes, then, this will ruin all my weekends to come.
So we, we have like done so much innovation.
That, was always adding more functionality, cooler stuff, but it always
came at the price of complexity, just like layering on and like compounding.
And I think where I see local-first enabling this age of the barefoot
developer is by bringing down the, the complexity in a massive way that you can,
with a much simpler technology stack build very interesting things that don't need to
scale to Mark Zuckerberg Facebook scale.
but if it works for your family and you build it when you want it, and
then you don't really, it doesn't break constantly because you depend
on all so many other external things.
I think not just for, use cases that I can't think about, but just for, for
my own personal context in a, my family stuff that I might as a Barefoot developer
build for my friends and extended family, but also what other people in
extended parts of the world can build.
I think this is what's changing now that the complexity is coming massively.
But there's another thing happening now that you've also, built in as
sort of the second layer of your talk, which is AI is happening now.
so it seems like that is also a fundamental aspect that's also ushering
in a new era of end user programming.
So maybe we briefly shift gears a little bit and, talk about that aspect.
Yeah, so this was kind of, like, the big claim I tried to make in the talk,
which I do believe, but it's definitely a claim that, like, needs a lot of
evidence and a lot of, like, questioning.
But at the moment, I think I'm still pretty firmly in this camp, where
I genuinely believe language models make a significant difference to end
user programming being more possible.
when language models first started getting popular, and, like, we realized they were
really good at code assistance, like, They're questionably good at other things.
I'm not going to say that they generate, like, useful articles for the web.
I don't believe they do.
But for code assistants, it's like, anyone who uses Copilot regularly, or
Curso, or any of these other assistants, I think you would have to be crazy to
claim that they are not, like, speeding you up, like, helping you debug things.
I know a lot of senior developers are like, well, I could just do that.
myself.
And it's like, well, yes, you are a senior developer.
you understand the bugs in the way that I do not.
like, I've started to joke, I'm kind of a mediocre developer without
language models, but with them, I'm, like, almost a full developer.
I'm, like, actually, I can pretty much do anything you assign me to.
Like, in the world of front end, like, a little bit of making, you know, back end
calls, but, like, it just, it just knows, you know, I just ask what I want it to do.
And it pretty much gives me working code.
Sometimes I do have to go in and debug it or like, ask it to do revisions, but like,
the amount it can do that I could not do on my own is really just astonishing.
it's very much a sort of subjective, personal qualia.
Everyone that I talk to, like, feels this way, especially people who aren't
great programmers, like more experienced programmers are more skeptical, like,
oh, this is causing more bugs, but I don't know, if you're more on the
junior end, you just feel like you've just been given a superpower and you
can like, make way more than you could.
so this big claim is that like, not, I'm not saying all normal people, right?
As I said in my talk, there are a bunch of normal people out in the world who just
don't, they don't care about programming and we shouldn't force them to.
Like, I think there was this moment where we were like, everyone
needs to learn to code, right?
Every nurse needs Every, like, accountant, every teacher,
you all have to learn to code.
And they were like, well, we don't want to learn to code, like,
why are you making us do this?
So I feel like we should just leave people alone who don't want to code.
Like, let them do their other very important jobs in the world that
have nothing to do with computers.
but there's a group, and this is what I call the Barefoot Developer
Group, who really do want more agency over their computers.
They're, like, currently using Airtable and Notion and like
spreadsheets and like doing really crazy, complex things with them.
But they also hit the limits of these apps.
Like, I feel like I have a lot of friends in this category who have a lot of
software needs and the software doesn't meet their needs and they keep being like,
well, how do I make it like do this thing?
And I'm like, well, you can't, like this other company controls that software.
You can't.
add that feature onto it.
but these people, if given access to a language model, and kind of taught
how to prompt it in a way where they can clearly ask for what they want,
it can write the code for them.
It can build the app for them.
If we, like, get the infrastructure right, it could set up some kind of
local-first database, ideally, but some kind of database, put it on a
URL, let, let people log in, store data somewhere, let, you know, figure
out a way where we can have language models set up, the schema for them.
It's like, It doesn't have to be super complex stuff, it might just be
something like, Hey, help me organize a trip for 12 people for a week.
Like, that involves a lot of logistics and ops and planning, or like, you know,
help me plan meal prep and groceries.
There's a thousand apps for this, but what if you could just prompt your
own, tweak every single feature that you wanted, like make it work just the
way that you want the thing to work.
These are not complex situations, but tons of people have these basic
needs and language models could easily get them to working local
apps that they own and control.
Right.
That makes a lot of sense.
And I think this kind of puts it nicely into two compounding steps.
Step number one is even for more experienced engineers like myself, Like
even for me, it would be too much to build all of like these ideas that I
have in my mind, because I know like, okay, this is easy enough to think about,
but to build, you need to wrestle with all of those layers of complexity that
will just like drown you at some point.
And this is where step one is local-first, simplifies everything to the core again,
that it becomes feasible, but it's feasible, but you still need to have
quite a bit of experience to build it.
And now step number two is LLMs that just bring down the barrier to entry
by so much, by having someone who knows what they want to build and
having a little bit of an intuition, how computers work, et cetera, and how
to put those things together, who are not afraid to get some autocomplete.
Sure, I have no idea what it is, but let me try and then, like, iterate from there.
And this is the second part where LLMs bring down the barrier to entry and now,
like, make this possible on a wider scale.
Did I get this correctly?
Yeah, yeah, exactly.
I think I should add on too that, I just, I showed in my talk some demos from both
Vercel's V0 and TLdraw drawing interface.
Because as much as I was saying, you know, of course you'll describe and text what
you want, You can do that, but often it's sometimes hard, or there's an ambiguity.
but with TLdraw, and with, uh, B0 from Vercel, you're drawing a visual interface.
Like, in TLdraw, you can, like, draw boxes, right?
And you can, like, point to a button and say, when I click this button,
you know, increment this counter.
And, like, when I click this button, start a timer for three minutes.
And you can just sketch out what you want with these instructions.
And then they have this make real button, so you select what you're drawing.
You click make real and it makes the app for you.
And like, it doesn't work a hundred percent of the time, but
like 90 percent and these models are only going to get better.
So we would hope if you get closer to a hundred percent, it just builds exactly
what you told it to build and it works.
And it's like, it's on a URL.
It's like, it's a real app.
You can click it, all the things work.
it's hard to look at that and still be skeptical that we're not at some
step change in end user programming.
Definitely.
and I think this is like this going beyond the medium of auto completing
code, but that you have like the modality of like a visual modality where you
can draw a napkin sketch and from that napkin sketch, you have like some working
React code that you now like I feel like the next step in the evolution of
putting together all of those systems.
It would be something like TLdraw, make it real, but for your local-first
data model that you basically describe like your, your use cases, or you
could even use your, your visual sketches that you've made through
TLdraw, feed it into an LLM and say like, Hey, can you suggest to me Data
stuff that I'll probably need for this.
And it might spit out some code or it might spit out like some,
some other artifacts that you can now use to iterate from there.
So I think that multimodality just brings down the barrier to
entry even more, as well as making experienced people more productive.
So now it really clicks how the, that answers the question of like, why now?
Since I think the idea was compelling before as well.
But with all of that complexity and, with all of the learning curve that needs to
be done before, that wasn't feasible.
So, uh, I love that.
Like I had also cited in my essay, uh, an essay written by, well, I guess more
of a short post written by Clay Shirky in I don't want to mess up the year.
Was it 20 2004 or 2014?
I want to bet 2014.
called Situated Software, which was about which was the same
claim as Barefoot Developers.
Like, software should be situated in the local environment that where,
like, it's the people that it serves, it should have been made there.
He made this idea at a time where it was, like, completely infeasible.
Just, like, No one could build sophisticated software, which
didn't have the tooling, like we hadn't gotten this far.
And, like, what would be the interface for normal people to build this program?
It was one of those, like, wouldn't this be nice kind of concepts.
And now it does feel like, yeah, we've reached this point where it's like, wow.
The coming together of like better tooling, like reducing complexity,
like better abstractions, plus language models trained on all those
abstractions and all that tooling.
It is like, Oh, this is possible.
Yeah, that, that makes so much sense.
I can't wait to see like how quickly that's going to unfold.
This was also a big part of what we try to do with the conference is, not
just get the, people who are already excited about local-first from, and who
are trying to figure out how to build it in the best way, but also people
who've maybe heard about local-first before, or haven't heard about it before,
and that they get to understand what could be the possible impact of that.
And I think this is where you've just knocked it out of the park
with, at the end of the day, with your talk, where I think before.
Your talk, everyone was already excited about like, Oh, this is going
to make software development so much easier, brings down the level of
entry for people to build local-first.
And it also enables next generation user experience, like Linear, et cetera.
And that's also why I initially got excited about local-first to build sort
of like a really cutting edge, next generational products with Overtone.
But I think you really expanded the horizon even further, what
on a kind of societal level, local-first could have an impact for.
So, do you have some theory of like, what are some, like milestones
that you would like to see happen there as sort of success stories?
Yeah, um, I talked about a bit at the end of my talk that we're
missing a few bits of like tooling or infrastructure, I think, to make
this work, because at the moment, what you can do easily with language
models is prompt front end code, right?
It's mostly what people are doing, like even a 4.
3.
5 Sonic came out, I think, a week ago, and it's really,
really good at code generation.
People are making crazy stuff, and I have this whole fat collection on Twitter
every time someone makes something.
I'm just, like, saving all this stuff as evidence of, like, here's where we're at.
Here's the current state of things.
But it's just making front end code, right?
It's giving you React components, interactive, it
looks cool, it looks capable.
But it's not connected to a back end.
Connecting it to a back end would be like a whole different thing.
Um, user authentication and logging in would be a whole different thing.
Like security, like multiplayer collaboration.
Like, there's just, there's all this other stuff to have a real working product.
Like, deployed to a real domain.
Imagine if you're not a software developer, like, you would never figure
out how to glue that stuff together.
No matter how much you have, like, chat GPT helping you and, like, you
asking it questions and trying to put together a working piece of software.
You wouldn't even know those things exist, right?
Like, no one knows what a database is if you don't work in software.
so we're missing, all these other pieces of tooling.
I think what I'm waiting to see is, like, I don't know, you know, I've kind
of tried to put this idea out into the world, tried to make more people aware
of like, hey, we should be trying to build things to serve these developers.
and I know of two projects, Jazz and DXOS, who are both at local-first, Jess
and, um, Anselm are hopefully building this kind of thing, which is like some
sort of full stack local-first, like, framework for people to build within.
I think if you could train a model on those kinds of things, where it's like,
You're talking to a language model, but its whole goal is to get you to
build a full stack local-first app.
That would be the goal for me.
That's like, oh, I want to come in, I want to be able to sketch, I want
to be able to prompt things in it.
and I want it to sort of be architected and trained in a way where it's
acting like a product manager, like helping me move towards my final goal.
Like, you know, it's It gets me to tell it the requirements and
it gets me to tell it what I want.
And then it's doing, it's making technical decisions for me, right?
It's like, hey, I'm just going to figure out how to model this data.
I'm going to figure out how to make this front end code.
All you have to worry about is looking at the end result and telling me,
yes, no, you know, what should I edit?
What needs to change?
And just looping.
Like that, that's, that's what I'm waiting for someone to build, honestly.
I agree.
I think there's sort of the, this gap in going from A to B where like, A,
where we're right now, where I think we have the conceptual right ideas,
how things can be simpler, and a few pioneers such as the folk from linear.
And a few other products who have already had those right ideas, but
they're technically very savvy so that they could like build that new
hammer, that new framework themselves so they can live in the future.
And, then you have the, the other group, what you've described with like
DxOS, Jazz, and there's many other technologies who are not primarily
building it for their own apps.
But to kind of build this for developers, so that the next Linear
has a much easier time, can focus on the product and doesn't need to
build off like the underlying tech.
So that's coming along, and once that is there, then we're kind of
halfway there, since at that point, now the AI also needs to pick this up.
Since, I think this is why the AIs are so great at bringing down
the barrier to entry for things like React development, et cetera.
There's already a lot of training data out there, whereas for local-first,
this is all like very little training data, all like very, very new.
So I think once we have those ingredients and the AIs can also integrate that into
their more encompassing, solution corpus, then I think we've, I guess like to, to
a much more comprehensive degree enable a Barefoot developer, since I guess
right now a Barefoot developer already lives in the future by, things like
front end React programming, et cetera.
That already works super well for them.
And then they get sort of this glimmer of hope, Oh, a local-first
is going to make everything simpler.
But the, the fact of reality today is you either need to use a very
Early technologies such as jazz, et cetera, and where you still need to
be a bit more on the more expert y end, or you need to wait a little
bit until all of that is AI ready.
But I, I like the way how you think about that sort of like as
a big next step function change.
Yeah, I expect they might meet in the middle.
Like what I think will happen is, like, people will build these kind of like
full stack language model helpers, which are not local-first, of course, right?
They will just build one that like uses cloud databases entirely.
And it's like, all like not, doesn't work offline.
and then the local-first tools will get more mature and maybe in a few
years, like these come together in the middle so that you have.
You know, something for barefoot developers that just has natural
language inputs and visual inputs for them to define what they want.
and the stack is, like, mature enough, right?
We have, like, stable enough technologies that they get all the stuff around
local-first, like, CRDTs, all the fancy stuff for free, just because we,
like, have enough training data and we figured out the complexities of it.
I don't want to put too many timelines on it, but I'm like, five years?
Maybe less.
I don't know.
Some people think that we're all going to die from AGI in five years.
So maybe just speed up timelines, like, but I think reasonably five years.
, I think a very frequent philosophical question that one can entertain
is like, my life as a programmer has certainly become a lot better
over the past couple of months and years with things like Copilot and
Cursor and, ChatGPT, et cetera.
I can like take a screenshot of an error message and it gives me some useful clues.
so that is.
Definitely getting better, but is this just like a very nice time before, I
don't have to do my, anyway, this is not a question to debate here, but
it's certainly also, I'm not immune to, to those sort of thoughts as
well, but I'm, I'm choosing to see the world as like glass half full.
and, I'm a tool builder, so I'm excited for new tools that make me more productive
and, make me more capable in doing stuff.
Yeah.
I mean, I was gonna say, if we, if we automate all the code,
we'll all just become designers and product managers, you know?
Like, we'll just, we'll just help.
Help the AIs, like, write the code and we'll just be like,
Hey, you know, focus on this.
This is your priority.
You know, this usability piece isn't working very well.
I still think it would scratch the same itch that a lot of developers have
around like building beautiful systems and like solving like logical puzzles.
Cause it's still design.
You're solving a lot of logical puzzles.
I don't know.
So maybe that's why I'm not as afraid of like the whole.
Automation fears, but I also think they're ridiculous.
Like we'll never get to a hundred percent code automation and it seems crazy.
Yeah, definitely.
So I want to shift gears slightly, and not just look at AI as an enabling
technology to make us more productive.
But if we put ourselves into the shoes of a product builder,
possibly of a tool builder, how.
Can AI be a ingredient that we can put into possibly local-first powered apps?
and so given that you've worked at Elicit, which is maybe you can briefly
give a summary what Elicit is about and what you've done there, but after that,
maybe we could explore a little bit of.
maybe you have thoughts on how to best bring AI into products and how is that
a challenge or an even better benefit to do it in a local-first context?
yeah, I actually, this is funny, like, after I had written the talk and was
talking to more people, I had that realization of, like, oh, language models
and local-first go really well together.
I think this is actually Jeffrey Litt, who's at Ink and Switch, that kind of
got me onto realizing this, how they're, like, actually perfect for each other.
but I'll back up a bit and talk about Elicit.
So, yeah, I was the designer there for two years, It is a tool that helps
scientists and researchers do this thing called systematic literature review,
which is this frankly very long manual boring process that no human wants
to be doing, but they're sort of like forced to do because they have to.
where let's say they want to do a study on like, vitamin D
deficiency or something like this.
They have to read every single paper that's ever been done on
like vitamin D deficiency studies.
And like, what do we know?
What's already been tested?
What needs to be tested in the future?
Just like read tens of thousands of papers and extract all this data from it.
Like how many people did they study in each paper?
And like, what were the results?
, what was the effect size in the population?
Like just all this stuff.
And usually humans, Open up PDFs one by one and type this data into a spreadsheet.
They're just like sitting there for, it takes six months usually,
it takes a couple people six months to do one of these.
And you have to do it for every like new drug release to market
or any new medical device.
So there's this whole consultancy whose whole job is to do manual data entry.
and it turns out language models are quite good at extracting
structured data from these PDFs.
Or if you prompt them in the right way and you have Frankly, at times, quite
sophisticated architectures to make them accurate, but you can build them, which
is what we focused on at Elicit, is like, raising accuracy rates and making sure
models got the right data out of papers.
But you can get them to do it to over 95 percent accuracy, which is what humans
roughly get out of doing this process.
So you just speed up this thing, used to take six months, you can do it in
a couple days, maybe a week, of you just going through and reviewing all
the answers that the models extracted.
So, yeah, working there for two years, I learned a lot about, both
just like prompt techniques and architectures for making models accurate.
It's actually quite hard, but, but good to know it can be done.
That was like really useful to learn.
it definitely made me very skeptical of most use cases of language
models, I think, in that we found one that was really appropriate.
It's like, okay, you There's data and a bunch of text.
Get the data out of the text.
That's like quite straightforward.
But there's a lot of stuff people are trying to use them for where
I'm like, is a language model the right hammer for this nail?
Like, I don't know.
You're trying to write marketing copy for your company.
I don't know that you want the most generic, predictable text to
really be the thing that you're like putting out into the world.
Or like, okay, some people are like, yeah, I want to write 10, 000 SEO keyword
stuffed articles to like get to the top of Google, but and everyone does
that and then there's no point in like you, you doing that because you're not
actually going to get any traffic from it.
So, I'm strangely quite skeptical or like negative on a lot of uses
of language models, but the data extraction, like summarization,
like getting it to do very small structured things over text, I actually
think they're really good at that.
And code generation and debugging is actually one of those, right?
Like, that's one of the things where like, okay, we've proven
they're actually useful for this, so like, we should use them for this.
This is like, they are shining here and like, ignore the areas where they're
not shining, like all the other, like, everything turns into a chatbot kind
of stuff, which we don't really need.
yeah, so that's, that's the long version of like, that was, that
was what I realized at Elicit.
but the thing with local-first and language models that makes
them go really well together.
Language models perform better when you have lots of really specific data
for them to run things over, right, to summarize or to extract data from.
And if all the data is local on your machine already, and you're
not having to, like, go up to the cloud, or it's not trapped in someone
else's app to run a model over it, You can just run a model locally.
You don't need to be making a call to OpenAI or to Anthropic,
which gets really expensive.
You could just be doing this all on your machine with no delay,
which is like, why are local-first makes perfect sense if you want to
actually be doing language model work.
Yeah.
So thank you so much for, for the background, on, Elicit.
I was not as aware of like the entire, process that researchers
need to go through and just hearing the word manual data entry.
it gives me shivers.
So that sounds like a well needed thing and whatever , makes
research and truth easier.
that is very welcome.
also your insights in regards to where LMs are a good fit versus not to.
I've coming to on a much smaller scale, but I'm coming to similar
conclusions, for example, when I'm writing documentations for, for some
technologies that I'm working on.
And this is where I typically disable LLMs because like what they typically suggest
to me is exactly not what I'm doing.
I'm building a different thing that challenges the status quo
for very particular reasons.
So I found it actually, it increases my cognitive overhead of like trying to.
like come up with a thought and like a very fuzzy process.
And then like, it's basically constantly like slapping me in the face.
Like, do you want to say this?
No, exactly not.
So, there's like use cases for it, where it's good and where it's not good.
but, I think also that giving it more contextual information is exactly
the, the key to make it feasible and maybe make it even so that I do
want to have it enabled for docs.
So if I imagine that I give it access to all of my source code.
then it could actually draw, draw the right conclusions.
So , this use case where you have your source code and you want to
generate documentation, I think is a much simpler one from a technical
perspective because everything is static.
I, don't need , my source code, sure, maybe some of it, I don't
want to have leaked, but a lot of it's going to be public.
So privacy concerns are not as much of a concern.
But where that is the context, if we're now talking about the health
app, this is where my context is possibly very, very sensitive
data or financial data, et cetera.
So this is where the contextual data is even more important to
drive good results for the AI, but it's so much more sensitive.
And I think this is going to be a huge challenge and a huge question, how
different AI systems will be built.
And that's a key.
topic that I'm interested in, this is where I think where
we've seen with Apple's recent AI announcements, where they hijack the
term AI to mean Apple intelligence.
Well done.
And now what Apple has announced at the latest WWDC is where they
basically shared their AI strategy.
and what I like about it is that most of the AI stuff is also
happening locally on device.
And I think the, the way how to do that is, an approach that
hopefully more technologies follow.
And I think this will be sort of like a bit of a dividing line, whether
you're gonna do it locally or whether you're going to do it in a cloud.
And I hope that more products, more technologies will enable
all of that to happen locally.
Since if I can keep my most sensitive data locally on the device, and if I
can run the AI model locally, it's not just gonna give me the fastest results,
but it's also, in my perspective, kind of like the only sane way
how to respect the user's privacy.
It was more of a coin flip to go with Google versus Apple before
in terms of products, et cetera.
But if Google's only way in the future is to drive everything into the cloud
and do AI there, and Apple's is to do it locally, that's a very clear call for me.
But I think that's a major question overall.
Like how do we run AIs locally and how do we drive the right contextual data there?
Yeah, this is something that I haven't seen yet come up as like a SaaS or
a service of any kind, or I guess it'd be more of developer tooling.
Like, there's plenty of, wherever it is, like, toolchains on top of the, all
the foundation model APIs, and like, you know, analytics and, visibility
and, like, tracking and all this stuff, like, coming up around, around
doing language models and product.
But I'm waiting for someone to just be like, hey, We help you run LLAMA locally
on the user's device and then only when needed, like, when, like, as Apple said
in their presentation, only when you need something that's more compute intensive
do they send it up to a cloud server.
Something that allows you to do hybrid, local, and uh, remote, so that at least
ideally the user, I mean, this is probably more likely to happen in a B2B case, could
say only do these kind of like, functions on this kind of data, uh, locally, maybe
this is more sensitive data, maybe this is more sensitive stuff, but stuff that's
maybe more complex or stuff over here, you can send to OpenAI if needed, or to
a cloud, I mean, to Anthropic if needed.
So I haven't seen that happen yet.
I don't know what that is.
That's like hybrid language model prompting, but that seems
like a very obvious piece of infrastructure we could build in.
I'm wondering, like, what will be the thing that wins the
argument one way or another?
one possible path could be, Oh, it gives you the best performance or that it needs
to work offline in certain scenarios, whereas like, I think with local-first,
we already see that the, the works offline case is kind of like a, Argument that
is not as compelling for many or not as intuitive for many as you might think.
but I think what I would hope will be the winning argument is privacy.
But I'm saying that as a European, and I know that other people might, uh, not
value privacy as much, but do you have thoughts on what will be like a big
lever in terms of one way or another?
Yeah, I mean, I also agree on the privacy bit, but I also know a lot of
people who just, I don't know, doesn't, don't, they don't care, or it's just
like, oh, this is just whatever.
This is like my, you know, notes on my product development app.
Why do I care, about privacy?
But I think it's speed.
Like, one of the biggest UX challenges of the list that we faced
is just that loading times are Or just on a whole different level.
It's just, it's, we're so used to quick, quick loads, right?
At the most one, two seconds.
And even then users are getting, you know, antsy and like, oh, this feels slow.
This app isn't working.
Sometimes you have a load time with a language model.
If it's doing a complex call of like three minutes, like, What do
you do with a user for 3 minutes?
Like, there's only so many animations you can play on the screen.
Like, there's only so many minigames you can have them
play while this thing loads in.
so having models locally on your machine that could run language model functions
faster would be a huge UX benefit.
A lot of the time we're just waiting for the OpenAI API to
reply, or like, Maybe we're doing multiple, you know, a hundred calls.
So every single time there's a couple seconds of delay on each one, this is just
adding up into a huge, huge time sink.
so that would be a big benefit, but I of course agree on the privacy front,
especially for companies will care about this, right, for proprietary data,
but yeah, individual uses for finance to health and anything where you just
don't want it going off your machine.
Yeah, so this is a topic I'm highly interested in, want to
explore also in future episodes.
I think luckily there's so much momentum and so much good stuff
happening on the AI capability side where models are getting more powerful,
but also more efficient that makes it possible to run them locally.
I think Google announced or released, uh, Recently, like a Google, uh,
Google Chrome version, I think a Canary version where you have, I think,
Gemini Nano working actually already locally where it can say window.
ai and run some little prompts.
So this shows some first, building blocks in that direction.
But, I'm more interested in exploring and figuring out a path.
How can we.
Figure out the contextual data side, since I think this is where I'm less
concerned about a AI model that runs locally, temporarily having, some
contextual information about me that it has like flushed again, like in a few
seconds, what I'm more interested in is exploring all of that contextual data
that is highly personalized, that might be text messages I'm sending to my close
friends or to my family, that might be health information, that might be my
emails, that might be my personal notes I'm taking after a nightmare, or whatever.
Like, all of that stuff needs to be accessible to the AI in a local way.
And that is much easier to do if, some entity, for example, Apple
controls the overall ecosystem and can do it in a way that is
secure, privacy respecting and fast.
But where we are all building things for, for the web, this is
where our playing field is much more constrained to the browser.
So one possible path That I could imagine where this is going is
that the browser takes even more responsibilities of an operating system
and where a lot of my contextual data lives in the browser, which raises
the stakes and the risks even further.
That now like some cross site scripting could access even more personal data.
Since right now, with the stuff that we have really saved in the
browser is like close to nothing.
This is actually one of the problems we tried to solve with local-first
that Right now we treat the web browser like it's not capable to do
anything, but we need to flip that.
We need to store a lot in it to make that happen, which brings
up a lot of privacy questions.
So lots of interesting questions to explore there.
Well, okay, wait, I have a good, a good dumb question for you as
like a non backend person, like a non, like, databasey person.
Could you just make either an Electron app or web app that just accesses,
like, a bunch of local files?
Like, let's say, like, you've got 10, 000 local markdown files
that, like, your personal notes, and a lot of them very sensitive.
Maybe you're, like, journaling or nightmares or whatever's in there.
Is there a way for some web app to just access those without it being uh,
at risk of like cross site scripting or some other attack like this.
So, I mean, there's always risk and there's always like the figuring out the
right balance between making something possible, making something convenient and
keeping it secure and privacy respecting.
So I think one capability that browsers already offer that could enable
that would be Chrome extensions.
But this is also, I think in a parallel universe, Chrome extensions
would be even more common.
and we'd use them maybe even more, maybe in a parallel universe,
Electron wouldn't have taken off as much as it did and Chrome extensions
instead would have been that medium.
So, Chrome extensions could, or browser extensions, generally,
could be a bridge towards local data, and I think that will be a, a
mechanism that might be used for that.
I'm actually building a Chrome extension over the last couple
of weeks for LiveStore, the staff tool that I'm building.
And it's, really complex to build.
And one of the big reasons why it's complex to build is because the
browsers are already very intentional about trying to minimize the,
the sort of like security risks.
And I think this will be even more important.
And I think we need to, strike like an interest, find a nice balance
where it's secure, but still gives you the capabilities and in
a way that a end user is able to make the right decision for them.
And so I think, yeah, that's going to be interesting balance to strike.
Okay.
That gives me more hope.
Cause yeah, I'm in the phase of experimenting with, um, you
know, Obsidian, local-first, like note taking tools.
Yeah.
Right.
So like all my All my notes are in there.
I was in something else before that was all cloud based and
actually going to local-first.
I was already on the edge of being like, Oh, personal notes should really be, Oh,
you should own that on your own machine.
That should be marked down.
That shouldn't be stored in someone else's cloud server.
so went through the process of moving them all into this
like local-first Obsidian app.
and then now exploring building plugins to like build on top of that,
like integrate language models, like do more interesting things with this
like huge database of notes I have.
but it made me realize all I needed was some sort of like, Interface or
runtime or primitives in place, which is what the browser gives you, or what
something like Obsidian gives you.
And then people being able to build things on top of that.
That's when you get into the more interesting stuff.
But making sure that base layer of like somewhere to store data, some security
and making sure it's local-first.
Like once that's in place, people can build much more capable things.
So maybe this is a good time to shift gears again a little bit.
you've been mentioning Obsidian and in the past, and I think still
today, you're a very active person in the tools for thought space and
Obsidian, obviously being one of the prominent tools in that space.
Do you have thoughts on how local-first could be an interesting
lever to make those experiences even better, both in terms of like end
user apps that you're using, but also in terms of you as a builder?
Yeah, yeah, I mean, I kind of had this like, I've been so dumb moment, I guess,
with the, with the tools for thought note taking thing, or realization, I
should say, like around, around the time of the local-first conference, where
for years I had been using, I was like early to roam research, and I moved to
this app called Tana, which is like, Gorgeously designed, like, totally acts
like a really flexible database, and they have a really beautiful outliner, things
where everything has types and schemas, and it's just the sort of thing I love.
Like, types and schemas everywhere, super structured data.
and their product is great, but it's not local-first.
I don't think it's ever going to be.
It's nowhere near their roadmap.
And I just had this moment of realizing, like, After, after going to the conference
and like hearing all the arguments against it, I mean, for it and against it.
And I was like, Oh, I, even if there's a UX cost to switch into something that's
local-first, I like absolutely have to.
This is like crazy that I've been using something that doesn't work on airplanes.
That is my note taking database.
It's just like nuts.
Doesn't work on that too, but it's wild.
Well, you just don't think about, you just don't think during airplanes.
No, no, I know, I know, because you kind of go, oh that's just, you know,
all software doesn't work offline, of course, this is just the way of the
world, like I just have to accept this reality, it was like my mindset before,
and then had this switch of like, oh no, like that's totally unacceptable,
I absolutely cannot use, like, Software that doesn't work online anymore.
That's just like nuts.
even Figma is sometimes on the edge of it.
It doesn't always work like perfectly offline.
If you're trying to finish like a huge design presentation on the flight on the
way over to your job, it's like, this needs to, this needs to work, you guys.
You can't have this not work when I go offline.
so anyway, I made the big switch to Obsidian.
It was like a fair amount of work.
Something only someone who like really cares a lot about.
notes and structured notes and like knowledge bases, I guess would enjoy
doing it, but it was worth it for me.
and it opened up my mind to what was possible now that I had my
whole giant notes database local.
And now I could, and as I said, they have this plugin ecosystem
where anyone can build plugins.
It's all in JavaScript on top of it.
And I was like, oh, wow, I can extend this now.
This is my environment.
Like, This is not just my data.
I now have control over the functionality of this thing.
This is totally malleable software.
This is end user programming.
Like, I'm going to build my own spaced repetition language model
like crazy, Zettelkasten reviewer system on top of this thing.
Um, but no one else, I don't, well, other people might want it.
We'll see if I get them to work properly.
But, um, It just, it just was like, oh, so much more is possible in
this really exciting, empowering way where I went, oh, I own this.
Like I fully have control of this in a way that I didn't with the previous tools.
I was always checking the change log.
What have they just released?
Like, are they going to prioritize my feature?
Are they going to make the changes I want?
I would often write crazy CSS stuff to hack the interface to
make it the way I wanted, right?
Just removing elements, moving elements, changing the, the size and
structure of things for my preferences.
And again, not, most people do not do this, but I am someone
that wants it to work and feel the way I want it to work and feel.
so it was very liberating, and that made me realize like, oh, local-first
software is actually much more about the user having more agency
and control over the software.
They can like write their own hacks around it in a way that's just not
possible with cloud based apps.
Yeah.
And I think this is another way to think about the, the affordances that enable
the Barefoot developer movement, is that also for the experienced folks who
build, much more sophisticated products, they have now much more capacity that
they don't need to put into running massive Kubernetes backend systems.
if they want to go a little bit more ambitious about the products
they're building, they could now put those resources, that capacity
into facilitating more end user programming inside of that software.
I think unfortunately, it's like more the exception, than the norm that software
facilitates that, because it is quite difficult to find the, what is the, the
right interface, the right modalities, If there's a plugin system or those
sorts of things, you need to be very intentionable of like, how far do we go?
How flexible do we want to make this?
It was like, if you want to go even more flexibility, you might as well
just like throw up your hands and say, okay, you built this as a web
app and we only give you an SDK.
and so I think there's an interesting spectrum there.
And, I think.
Building things local-first can free up capacity that can
be reinvested into making more software end user programmable.
So I love those, um, those use cases and like your recent success stories
that you found with, sort of the local-first mindset, bringing that
into the tools for thought space.
Is there, any other thing in regards to local-first where you wish or you hope
that local-first enables a certain thing.
what is like on your local-first wishlist?
Ooh, I mean, I definitely want the quick spin up an app.
I mean, I know this is like, we mentioned like things like Jazz and DxOS are trying
to do this, just develop a tooling that makes building a local-first app easy.
Does not exist.
I tried.
I tried to build a local-first app a couple of times.
And it was just that the, the developer experience is not quite there yet.
So I think there's a lot to do around DX and UX of just people being
able to build these kind of apps.
in terms of things they enable, I don't know if they have that many more.
I mean, I certainly have specific examples where I'm like, there's lots of personal
things that I would want to build my own little apps for and I just want easy ways
to do that and that's like I mentioned things like, I always want to do trips
with people like, you know, like groups of like a dozen or even more but it's so hard
to just do all these small things in the middle that like software so far doesn't
enable in these weird ways like Find out when everyone's free during the same week
in an entire year and then figure out all the flights and all the like finances
and the cooking and find like an airbnb somewhere that would fit everyone You It's
just like a big ops and logistics problem.
And there's tons of these examples in everyone's personal lives.
it's the kind of thing that like, if it was local-first, who knows
if you're going to have like phone signal out in the middle of wherever
you're going, and you're still going to want to have access to all your
like timetables and finance sheets and who's cooking dinner that night.
that's just the kind of smaller examples that I think I'd, I'd like pull on is
there's always those for personal stuff.
So let me say what, once we are reaching that point where it is super easy for
front end developers to build local-first, home cooked software, I think your close
friends can be very happy to and very much looking forward to be traded to
some locally cooked software from you.
Yeah, I will host a local-first software retreat if we ever
manage to get those apps working.
If you could just make that easier, I'd just be like, great, we're just getting
whole groups of people together to do these weird camping weeks where we all
just build home cooking software together.
I think that's a, that's a nice goal to aspire to.
And luckily there's many, many smart folks like some of the ones that you've
mentioned who are working towards that.
It's just, yeah, to, to absorb as much complexity as possible and to build it in
a way that developer experience is nice and where it's not a leaky abstraction.
That is quite the undertaking and takes a little bit of time,
but I think it's on, on its way.
Maybe as a last question.
Given that you've come to Berlin to the local-first conference and there
were so many interesting people there, I'm wondering whether besides kind of
opening the eyes for you, in regards to local-first software and not
local-first software and ruining some non local-first software for you, where
there's some other takeaways, some other insights from conversations with people?
I was impressed at how much work had been done.
I mean, we had a few people speak who had been part of like the offline
first movement before local-first got coined as a term, who said
like, this has been around since, I want to forget the earliest year,
what, 2008, 2009 or something, people started trying to do this.
I was impressed by how much like previous art there was, but also
how it hadn't progressed that much.
Like maybe other things became popular in the tech space at the time, or it
didn't have this same like cultural energy behind it that it kind of does now.
But it was both like, wow, this has been going on for ages, and we haven't
actually gotten to a place where it's, like, standardized or easy to do yet,
But then all the people who presented at the conference, it made me get this
sense of like, Oh, things are picking up.
People are working things out.
Like a bunch of these like wonderfully smart people have
solved a bunch of complex problems over the last couple of years.
Like, great.
We are like hitting inflection points, you know, CRDTs and like Automerge
and things like this are like actually making a huge difference.
so I think I was just kind of blown away by how much sophisticated, hard technical
work had already been invested into this.
philosophy or dream, that made me go, Oh, this has to happen now.
Like this has to, this has to pan out.
Like we've hit the apex, we're over the hump.
Yeah, this was certainly the goal with the conference to just
bring together all the people.
There's so much.
Momentum already happening, but a lot of it is like mostly felt on a given
day on someone's solitary desk and like they're working on something and
think, Oh my gosh, this is so cool, but like, does anyone else care?
And then bring all of those people together.
The momentum compounds, and then you go even further and show like how this
can have like a massive global impact.
this is sweet.
We certainly met all of those goals and exceeded them for ourselves.
And thank you so much for contributing in such a meaningful way to, to that event.
Yeah, no, I loved it.
And I'll also add on that I think I was also impressed by, everyone in this
community is like, maybe, maybe by nature of being at a conference like this, which
is trying to say, let's build software differently, like, let's do a radical
change to the way software works, was, you know, Then the kind of person who
was also thinking very creatively out of the box, like out of the norm about
how we should build software, what software is, like who builds software.
it was a, it's a very like holistic, I think is the word I want to use,
approach to understanding what.
Software and programming is, which is what I always love at the right conferences.
It's like, okay, we are not just showing each other like how
to do API calls with some new framework, like React on the screen.
Like, please God, no, not anymore.
But if someone could please talk about like how this fits into like developer
culture or wider culture, I felt like there was a lot of that at the
conference that I really appreciated.
Yeah, that's what I think makes it such an inclusive and wide space, since at the
end of the day, the, also the local-first essay was not very prescriptive in terms
of like, you ought to use CRDTs, but laid out those ideals of like, of things
that I think most people can get behind.
and some might see it as like a nice to have bonus and some others say
like, Absolutely, I won't touch any software that doesn't respect all
of those ideals, but I think this, kind of spans a very wide open tent.
Yeah, I feel like it's sort of.
Like the older people who have been in software a while
sort of already knew this.
They're like, yeah, you don't trust random companies with your data.
Like we've seen enough of them die.
Like they're very, like, I keep everything locally.
I make it all myself.
And then I feel like, you know, younger people, let's say people like born after
like 1985 or something, you know, we just, we Didn't live through that, that
period of everything dying off as much.
And so a little bit more naive, a little bit more like, yeah, of course, all my
data lives in the cloud at some random person's server, of course I don't own
it, of course I don't have the ability to edit my apps, the sort of, blinkered
by what we think is possible and what we think we're allowed to do in software.
And this is kind of like unblinkering people being like, okay, you've been
living in this paradigm, but this is not the way things have to be.
We could change this.
This is just like how things unfolded because of market like forces.
But.
What if, what if you actually had control over your software?
Like crazy idea.
I love it.
Maggie, thank you so much for this wonderful conversation.
Thank you so much again for contributing in such a great way
to the conference, coining a whole new term and inspiring many, many
developers and barefoot developers, soon to be barefoot developers.
So thank you so much for taking the time today.
Yeah, I really loved it.
Thanks so much for having me chat.
Thank you for listening to the local-first FM podcast.
If you've enjoyed this episode and haven't done so already, please subscribe and
leave a review wherever you're listening.
Please also share this episode with others.
Spreading the word about the podcast is a great way to
support it and to keep it going.
A special thanks again to Rocicorp and Expo for supporting this podcast.
See you next time.