Joep Meindertsma - Atomic Data

Welcome to the NGI Zero podcast where we talk to the people who are building the next

generation internet.

Hi, I'm Ronny Lam.

And I'm Tessel Renzenbrink.

We both work for NLnet, a foundation which financially supports people working on free

and open source technologies.

Today we're joined by Joep Meindertsma.

He is the CEO of Ontola IO, a Dutch software development firm that aims to give people

more control over their data.

He has received NGI Zero funding for three separate projects, Solid Search, Atomic Data

and Atomic Tables.

These are the projects we will talk about today.

Welcome Joep, and thanks for joining.

Awesome, looking forward to it.

Did we miss anything in our introduction?

I think that pretty much sums it up.

Maybe for some extra background, I started off with doing online democracy stuff about

10 years ago, and from there on slowly migrated towards doing more with data ownership and

open data, but we'll probably dive into that soon.

Sure, yeah, indeed.

Your projects are all about modeling and connecting data.

What are the key issues with how data is used on the web today?

I think one of the biggest issues at this point is that a lot of data is siloed, and

this is partly because a lot of big tech companies are designing their systems to have data siloed.

What that basically means is that it's very hard to reuse data.

What that means is that users get locked into an ecosystem.

There's a very concrete example of this.

I'm locked into the Google ecosystem.

I have a Gmail account.

I have a Google calendar.

It integrates everywhere.

I have a Google Drive thing, and that kind of limits how easy it is for me to switch

to some sort of competitor, and this really limits the degree of innovation, and it also

makes me very dependent on what Google does.

Google has a large control over my life.

It can serve me ads and manipulate me.

It can have a large impact on how my software world looks like.

I think that there's a lot of reasons why we should want to have more control over our

data, but it's just difficult.

The main reason that it's difficult is not necessarily only because these big tech companies

are trying to lock us in, but also because it's very difficult to make open tools that

work well with each other.

Of course, there's an open source email tool, and of course, there's an open source calendar

tool, and there's an open source this and this and that.

But every time somebody makes some sort of open source tool, they not only have to make

that tool open and really good, but they also have to make sure it works well with people's

data.

That's basically the fundamental limitation, in my view, of how many of these applications

work nowadays is that they don't really work well together.

So the issue that as a software engineer you have is when you're designing an application,

you also have to design its API, its programming interface.

When you do that, it's very tempting to just design the thing that you need at that point

in time.

But that also means that if somebody wants to use that API, they'll have to read your

specification, they have to understand how you've been thinking about this.

And many APIs are vastly different.

So one of the things that I was trying to solve with first with linked data and later

with Atomic Data is to make one API that's highly standardized, very readable, very browsable,

and very highly interoperable so that at some point in the future, people could make

their own applications that work well together.

And one of the cool things you can do if you have a very well-defined API is that you can

have decentralized data.

So you can have data that's stored in a different server somewhere else in the world, and you

can point to it using a link, and you can reuse that.

So for example, let's say I'm going to plan a wedding event, and I have a lot of lists

of attendees of people who I want to invite to my wedding.

And I have this wedding event concept where I want people to be able to RSVP, but I also

want a lot of information from people like, are you a vegetarian?

What's your profile picture?

What's your phone number maybe or email address?

And are you taking a plus one?

All of these questions.

What would be really nice if I could just point to someone's URL, like I would point

to your URL, and that URL would contain all this information like, what's your profile

picture?

What's your name, et cetera.

And that's basically what linked data promise has been about in the past few decades, but

wasn't really achieved because it was just too much of a hassle for developers.

So that's why I started working about four years ago on Atomic Data, which is a very

strict subset of linked data, which enforces JSON compatibility.

Most developers use JSON as a serialization format.

And it also enforces type safety, which means that if you have like a date field for your

birth date, for example, that's standardized in how it's written, like year, year, year,

month, month, date, date.

So you can't like, you know which data type it is, which is very useful for software engineers.

And the third thing it does is enable this decentralized data approach.

You use URLs.

So it's basically a very long monologue for the main problem that I've been working on

and how I'm trying to solve it with Atomic Data specification.

Yeah, thanks.

That really clarifies things.

But just for people who are not really super into this field, can you maybe go back a little

and explain what the semantic web is and what RDF is and what Atomic Data does to improve

on RDF?

So the inventor of the World Wide Web is Tim Berners-Lee.

And he made the first websites, the first website and the first web browser and the

first web server back in, I think, 88 or 89.

And at some point in time, he realized that websites are nice, they're documents.

But what you want is that a URL, like the link to websites, doesn't just represent a

document, but it can represent a person.

It can represent an event.

It can represent anything.

And that's when he started working on the semantic web, right?

Where the web is linked with semantic meanings.

So you have like a person and they have a friend, right?

And this friend is another link somewhere which has its own data.

So that's basically the goal of the semantic web.

And the semantic web is expressed using this language basically called RDF, which is the

Resource Description Framework.

And it was introduced in the 90s.

It was based on XML and it never really took off.

Like nobody's actually using RDF in production.

But this dream of having a semantic web where all machines are connected to each other and

people can reuse data and this data is extremely machine readable.

I really love that dream.

So my software company, Ontola, had this product called Argue, which is this e-democracy platform

we talked earlier about.

And we went all in on RDF, right?

So we basically made our whole stack linked data RDF stuff.

But at some point, we became really frustrated and we saw some of the fundamental limitations

of RDF.

And that's basically when I was thinking, OK, I need to constrain this.

I need to make it a smaller subset.

I need to make it a little bit tighter.

So it's easy to work with as a software engineer.

And that's what Atomac Data is.

It's like this is making this semantic web useful for software engineers and for developers.

That's like when I'm talking about JSON compatibility and type safety.

I know this is already becoming pretty technical.

So I'm sorry if you're listening to this and you think, what was this guy talking about?

How is it taking off?

Are other people adopting this?

That's an interesting question because when I started out with Atomic Data, I first wrote

the specification, right?

I had like this 70 page document just detailing how the specification would work.

And it's just an idea and nothing happens, right?

Like nobody's going to make something if you just have a specification.

So what you need is a specification plus an implementation.

That's why I started working on what I thought would be the best killer application, which

is Atomic Server.

And Atomic Server is basically, I'm not sure if you're familiar with Notion, but like this

all in one workspace app where you have documents, but you also have tables.

So in a way, it's like Microsoft Excel plus Microsoft Word merged into one user friendly

application.

So I wanted to make that, but using Atomic Data as basically the core and make it fully

open source and free for everyone and make it really, really performant.

So I wrote it in Rust, which is a really nice programming language for making these performance

system applications.

Atomic Server became basically this database with a very easy to use front end, which people

can use to manage their data.

And that's basically the main use for Atomic Data right now is that application implementation.

So what I'm trying to do now is basically build a community around that implementation.

So people start using it for their own projects.

And we have a bunch of front end libraries which people can use to implement it in their

apps.

So there's like a React library, there's a Svelte library, there's a Node.js library.

So like a lot of tools for developers to help them get started.

But because it's all JSON, you don't even need to use these libraries.

You can just use your whatever framework you're already using and just fetch the data straight

from Atomic Server.

And really the goal is to make it really easy for developers to start using this in their

production apps.

I think it's really interesting what you're saying that you cannot just write a specification,

but that you also have to do an implementation.

And you did a lot of implementation already.

Yeah, that's true.

I think I was mainly inspired by Tim Berners-Lee.

So he did the same thing with when he started the World Wide Web.

He's like, okay, I wrote this specification for the World Wide Web with, you know, HTTP

and HTML.

But the only reason it took off is because he also wrote an open source server and an

open source browser.

And so he had the specification server and browser.

I did the same thing for Atomic.

Because I think that's like a recipe that could work.

The specification still has to prove itself, right?

Other people also have to like it to some extent.

And that's kind of the difficult part is convincing developers to also use this.

But that's why I'm focusing so much on the implementation, just to have like a very good

open source database.

Because if you have a good open source database, you can just use it without the benefits of

Atomic Data.

But as more and more projects are using that, at some point, the interoperability between

these projects is going to be a huge selling point.

So I'm hoping that we get like this S curve adoption, right?

So first you have a couple of projects using atomic data.

And at some point, a lot of people are using it and they can point to each other and you

get like this accelerating effect, same as the World Wide Web growth, right?

You get this network effect and then it can really pick up steam.

Yeah, I also want to congratulate you on your on your documentation.

I mean, it's it's super.

It's huge.

It's well written.

It's understandable.

I think not enough people pay so much attention to documentation.

Is this something that is specifically important to you?

Is it something you like to do?

How come you do it so well?

Oh, thanks.

To be honest, I'm not entirely very happy about all the documentation.

I mean, some things of it are good and I'm a bit proud of, but there's also like still

a lot of gaps.

Because I think documentation writing isn't very fun compared to application writing.

I think that's like one of the biggest hurdles.

So what I often tend to do is to structure my thoughts using my writing and that becomes

documentation.

So if I'm thinking about, oh, I need to solve like this problem, then I just start writing

the documentation basically and use it as part of a process.

So that for me makes it a little bit easier to to to make something.

So in a way, that's like documentation driven development.

Right.

So you have like a couple of software development paradigms.

Some people do test driven development and this is documentation driven development.

And the advantage of that is that you end up with an API that's very easy to explain

because you basically start with the explanation of how you can use it.

And then at some point you've built it and then other developers who look at it,

hopefully it feels understandable because otherwise you make something that's

logical to program, but maybe harder to use.

And is or may be one of your goals to to to put this into a standard.

I mean, you you wrote a specification, but I it's your hope to get this into a real

standard.

So I think what's what the specification is, is to some extent, it already is a standard.

So when I started off, I also named it a standard.

And then somebody called me and said, hey, listen, this is not a standard.

I'm like, but but it's a specification, right.

And it standardizes something.

He says, yes, but for it to be a standard, it has to be adopted.

So I think, yes, that's exactly my goal.

I want it to be a standard.

I want it for I want people to use it.

So then it kind of becomes a standard.

And that probably also includes making the specification even stricter and tighter

because like at some point there's going to be some sort of ambiguity that's inside

the documentation already.

It's going to be very obvious if people are going to make their own applications on it

or their own server implementations, for example, that are slightly different.

So this is like one of the challenges is if you build an implementation is that it's very

tempting for the implementation to basically get further than the documentation because

it's very tempting to just add this new feature or this cool thing.

And if you don't document it, well, then it's kind of out there and it becomes a de facto

specification, even though it's not written down.

So that's like, I think, a pitfall.

And is that is that the way you work?

You first write your specification and you then develop your application to it?

For pretty much.

Yeah, for most things, that's how I prefer to work.

That's definitely the case at very early days of Atomic Server development, which is like

I was on vacation in Switzerland and I was just on my laptop all day.

My girlfriend hated it because I wasn't really enjoying the vacation as much, but I was in

this flow where I just writing Atomic Server and writing the documentation.

And nowadays, what I often do is I first write an issue in GitHub, very detailed issue,

explore a couple of approaches and a couple of APIs, and then I build it.

Because now I'm at a point where the specification is not changing a lot

and the implementation is changing mostly because like specific endpoints,

specific plugins, specific added features that the documentation is pretty stable.

Just to follow up on Ronny's question.

So you want it to be adopted, but are you planning on going through like a standards

body to get it adopted as a standard?

So the Atomic Data is a W3C working group, which in a sense means that there is already

some sort of process in there for it to become a standard.

I also reached out to a body that is concerning media type standards.

I forgot like the body doing the MIME types.

But at some point, I also became a little bit frustrated with the bureaucracy of some

of these processes.

And I saw that there are some really, really effective standards or specifications that is

they're widely adopted, but they're not documented in such a group.

So then I became more, I was more like, okay, if I just document it well and I make the process

open and transparent, then I don't necessarily have to adhere to some very bureaucratic

external process at this point.

But maybe later it becomes necessary, like as it grows and more people are using it.

I do think that's the point.

I would like to make a NGI Zero plug here because we don't only give grants to great projects,

but we also support with practical support.

And one of our partners in the NGI Zero coalition is Tolerant Networks.

And they have very much a lot of experience with standardization bodies.

And especially this point that you mentioned, like it's super slow and difficult and you

need to speak to the right people.

And they can, if you are interested, or maybe you can send somebody else to do it if you

don't like it, but they can really help you with taking the steps.

I mean, they can't do it for you, but they can definitely give you advice on it.

And this is also for anybody listening who wants this kind of support than NGI Zero.

Oh, this sounds actually really useful.

So I'm 100% going to do this.

Nice.

I also have another question.

And this is more from the perspective of people who are using the web.

So of course you are directed mostly toward developers.

But what would a person who is using the web, what would Atomic Data be like for them?

Would the web experience change or would it be like under the hood and they would hardly

notice or?

I think if it works well, if it's like widely adopted and many services use it, at some

point, many things are going to start to feel like magic.

Like your calendar is just completely integrated with all these other services and it just

works.

You can have like one list of contacts and they are automatically updated in terms of

their profile picture and new data arises.

And you only get access to people who actually want you to have access and you get the

fields that you should get access to.

I think you can have like completely open source social media platforms that have a timeline

that don't order based on what advertisers want.

So Facebook, they have like an AI trained to maximize engagement and make you click

on as much ads as possible.

You can have like your own algorithm for social media feed.

So for example, I would like to have a social media feed that helps me understand the world

as good as possible and keeps me up to date on important events and have some sort of

neutrality not to be too much biased in a certain direction.

And maybe someone else could pick their own algorithm that they would want for their

social media feed.

I think the open source social media direction is very interesting and I hope it can make

polarization in our society a little less worse.

And I can also imagine that it just removes a bunch of hassle.

So like if you have your Google Photos, right, there's a lot of photos stored there and at

some point you just want a different front end.

You have like this other app and it works really nice.

You want to migrate to it.

Well, with Atomic Data, that should be completely trivial because you can just change the front

end of an app without moving your data.

Your data just is yours.

It's on your server somewhere.

And as an additional benefit to that, that means things are really, really fast.

So if you use Atomic Server, which if you're listening to this and you want to try it,

it's just a one-liner Docker command.

It's a 12 megabytes binary executable.

It's very, very easy to install.

You'll notice that it's ridiculously fast.

Like there's nothing on the web, like pretty much not a single app that you've used that

is this fast.

And I like fast applications.

I like that things open instantly.

And with Atomic Server, like when you're searching through all of your data, like every key press

performs a search and within like seven or 20 milliseconds, you get like a full response

back.

So you'll feel very productive.

And I think that's also a big plus.

That's a nice bridge to our next question, which is, I mean, if people are interested,

how can they get involved?

What do they have to do to work with Atomic Data?

I think the easiest path for people to work with it is to just install Atomic Server

somewhere.

And that's like probably the easiest with the Docker image.

So like I said, like a one-liner, no external dependencies or whatever.

And if then people actually want to make an application, there's a couple of libraries.

So we have like a React library, a Svelte library, an Atomiclib library for other JS

applications.

There's a template for React applications.

There's also a template for Svelte websites, which basically is an entire website, which

is already linked to Atomic Server.

So there's a couple of ways people can get started.

But I think the biggest one is to join the Discord server, because we have like a Discord

server.

You can just ask your question there.

I'd love to help you.

There's other people who help as well.

And it's, I think, a very good place to just share your idea and get some feedback and

start working on this.

What are the next steps for the project?

So at this point, the project lacks some important features for me that I think limited to

becoming a very useful headless CMS.

So a headless CMS is basically the number one proposition I'm trying to achieve with

the Atomic Server application, which is basically...

Can you explain what a headless CMS is?

Yes.

So a headless CMS is basically a thing where you store content for the web.

It's a content management system.

So WordPress, for example, I think many people are familiar with WordPress, which you use

for building websites.

That is a CMS, but it has a head as well, which is the front end.

And the headless CMS is only the backend stuff, but without the front end.

So you can design the web page all the way you want, any way you want.

And the headless CMS basically deals with all the data.

It's a place where you can sign in and edit your web pages.

You can search your things.

And I really want to make that proposition really well.

So we have this proposition mostly aimed at software engineers who want to make websites.

So we have a couple of features that are still missing, which are currently being prioritized.

One of them is an improved document editor, which should feel similar to Obsidian.

Not sure if you're familiar with that, but it's like this markdown, what you see is what you mean.

kind of text editor, which I feel like is very productive.

And we're building things like a form interface where you can create a form web page,

where you can just make submissions without creating a user or whatever, just for guest entries.

For example, for surveys or for a contact form for your website or a reservation for your restaurant.

These types of things is what forms are about.

So better document support, better form support are two top priorities.

And the newest things right now is basically the table editor and the data model editor,

the ontology editor, which was done using the NGI Zero grant.

So thank you a lot for that.

And it seems a lot of stuff is happening.

I looked at your roadmap and it's like every month there's a new thing being built.

Can you tell me something about the team that's behind this?

Who are the people working on this?

At this point, the team working on Atomic Server is pretty small, actually.

It's me and Polle Pas.

So Paul Opass also works at Ontola.

He's mostly working on the front end.

So if you see something in the front end that's good and well designed,

chances are pretty high that he did that.

And I'm mostly doing the backend stuff.

But we're both doing a bit backend and a bit frontend as well.

And there's also now a couple of people who have been contributing to the repository,

which to me, that's like the most magical thing.

If you have an open source project and there's some random person you've never heard of

and they're improving your code base and asking how the testing suite works or something,

when that happens, I just feel all warm and fuzzy inside.

It's really magical.

That's when the adoption starts.

Yeah, yeah, absolutely.

Well, the next question was, what do you like most about working on your project?

But maybe that was the answer.

Yes, I think that a feeling of community when people start using something,

that's one of the most magical and good feelings.

I also really like it when things come together and they are simple.

So I really have a strong distaste for complexity in software projects

or having too many components.

And if you make something that feels very lightweight and easy to understand

and easy to set up and it has a little amount of dependencies,

that also feels very, very good.

But I'm not sure if other people will feel the same about that,

but I feel that's a very strong guiding force in how we write software.

To zoom out again a little to the semantic web more generally,

what do you think is needed?

Because it sounds like there are a lot of positive sides to it.

So what would be needed in the rest of the world to get the semantic web going?

I think that's a good question because if I look at just the semantic web

and the RDF specification, it has a couple of these big limitations,

which I feel will make it impossible to be really big.

So we have RDF and the SOLID project.

I've also been a contributor to SOLID and worked quite closely

even with Tim Berners-Lee a couple of years ago.

But at some point I just felt like this isn't going to be the thing

that I want it to be.

It's too technically complex.

It's too difficult for software engineers to make something.

So I feel like what the semantic web needs is type safety,

JSON support and a clear consistent protocol.

And these are the three things I think that Atomic Data has solved and has now added.

I do think that there's still some things that Atomic Data is probably missing,

like good OAuth support.

So I think that's a big one I also want to work on in the near future.

And what we're also missing is just implementations,

just people toying with it and creating their own apps.

Because the only way it really takes off is if we are seeing the start of this S curve

and you get these network effects.

And I think that there's a couple of domains where that makes more sense than in other domains,

mostly personal data, personal document management, event management, event registration, RSVPs.

I think these specifically would benefit a little bit extra from having open...

Yeah, having an implementation for atomic server.

And the people who are now listening, how can they contribute to making the semantic web

a thing that's going to be?

Oh yeah.

I think one of the biggest things you can do is just make simple apps.

Just make simple, useful apps for yourself.

Just make some sort of short demonstration.

Just make it like a weekend project, toy around with it a bit.

And demonstrate to people that this is something that you can play with

and actually use it for something that you want.

So maybe you want to import your playlist from Spotify

and have a playlist manager for your music.

That's not a very complex application,

but it's a very fun process to make something like that.

Or make a tool for your resume.

Make a resume editor and use that in Atomic Data

and share the data models that you've created.

So one of the big things for Atomic Data is that the data models that you create

are also URLs, which you can reuse.

So other people can reuse your data models.

And as that happens, you get like this standardization effect.

But that does require that people start making some of these data models

and spreading them and using them in applications.

That's like the magic of the network effect that still has to happen.

How did the NGI Zero grant help you reach your goals for your project?

It has a huge effect because I have a very small software company.

And we basically get to choose how we spend our time,

depending on how the money flows.

So we would love to work on an open source tool,

like completely MIT licensed, without having some sort of paid service attached to it,

to just make that available for people.

And that's basically only possible through grants and subsidies

to bootstrap that process.

Because it takes a while, even for an open source tool,

to get it to a point where you get like user adoption.

And you can use the grant to bootstrap adoption.

And from there on, at some point, get an investor

to build towards a revenue model that's sustainable.

So what NGI Zero for me did was enable this first path, basically,

this first place in the process where you can do your fundamental research

and you can build the open source tool and you can get your first amount of users.

And from there on, you can try to basically scale it up and turn it into a service.

But what I really wanted to do is to first focus on having a good specification,

having a good open source implementation.

And that's basically impossible if the first thing that you need to do

is to find customers and get a consistent revenue flow.

Because then you're going to focus on a lot of different things.

And I think that the open source character is going to be left behind if you do that.

So for me, it's essential in developing something with this kind of business model.

Yeah, agreed.

What advice would you give to people considering to apply for funding?

Yeah, focus on community.

I think that is such a big thing.

Just set up a Discord server for your project and invite people to that, link to it everywhere.

And every time somebody joins, just reach out to them

and talk about what makes them enthusiastic about technology.

Because these individual connections that I had with people

have been so incredibly inspiring and rewarding.

Because the first people who are going to join such a community

are probably one of the most innovative, interesting people that you'll ever meet.

So I feel like just set up an infrastructure for your community to grow.

Do everything in public.

Just write your thoughts in GitHub issues.

Because there's a small chance that other people are going to read it.

And if they do, these are the most important people for your project to grow.

So yeah, community, community, community.

True.

I think we're getting to the end of our questions at least.

Is there anything you would still like to say?

Yeah, I want to say thank you so much for making this all possible.

I think that it's pretty rare for software engineers to be able to do something like this,

right?

To basically receive income for working on completely open source tools just for a more open web.

And I think without the role that you play in this ecosystem,

it would be very, very difficult to make meaningful changes.

So yeah, thank you so much for that you're working on this.

I really appreciate it.

Well, and we'd like to return that because we'd like to

thank you for working on improving the internet.

Oh, thank you.

I think that's it for this podcast.

So we'll leave it here.

And Joep, thank you very much for joining us today

and sharing all the interesting things about your project.

Well, thank you so much for having me.

It's been a blast.