#542: Zensical - a modern static site generator

If you built documentation in the Python ecosystem,

chances are you've used Martin.authors to work.

His material for MKDocs, PowersDocs for a fast API, UV,

AWS, OpenAI, and tens of thousands of other projects.

When MKDocs 2.0 took a direction that would break material

in 300 ecosystem plugins, Martin went back to the drawing board.

The result is Zenzical, a new static site generator

with a rust core, differential builds in milliseconds

instead of minutes and a migration path designed

to bring the whole community along.

This is Talk Python to me, episode 542,

recorded February 17, 2026.

POP! Talk Python to me,

yeah, we ready to roll, upgrade in the code,

no fear of getting old,

they sink in the air, new frameworks in site,

geeky rap on deck,

core crew, it's time to unite.

We started in Pyramid,

crews in old school lanes,

had that stable base, yeah, sir.

Welcome to Talk Python to me.

The number one Python podcast for developers and data scientists.

This is your host, Michael Kennedy.

I'm a PSF fellow who's been coding for over 25 years.

Let's connect on social media.

You'll find me and Talk Python on Macedon,

Blue Sky, and X,

the social links are all in your show notes.

You can find over 10 years of past episodes

at TalkWython.fm,

and if you want to be part of the show,

you can join our recording live streams.

That's right, we live stream the raw,

uncut version of each episode on YouTube.

Just visit TalkPython.fm slash YouTube

to see the schedule of upcoming events.

Be sure to subscribe there and press the bell

so you'll get notified anytime we're recording.

This episode is brought to you by Century.

You know Century for the air monitoring,

but they now have logs too.

And with Century, your logs become way more usable,

interleaving into your air reports

to enhance debugging and understanding.

Get started today at TalkPython.fm slash Century.

Martin, welcome to Talk Python to me.

Great to have you here.

Thanks for having me.

I'm excited to talk about static sites

and the next big platform for building them here

and Python and beyond.

So really excited to talk about Zencicle.

Am I saying that right?

Yeah, pretty much, Zencicle.

Zencicle, okay.

Great, yeah.

I know MK Dox, material for MK Dox

has been really, really popular

and you all have made a big splash

announcing this new project.

So I really look forward to diving into it.

Before we do though,

let's just get a little bit of background on you.

Who is Martin?

Of course, so hi, my name is Martin Donut.

Most people probably know me as SquidFunk.

I've been an independent developer

and consultant for the last 20 years now.

And I mostly ride in TypeScript, Python,

and lately a lot of rust.

So I've become a huge fan of rust actually.

I'm kind of a free spirit.

So I love doing my own thing

and building products from front to back basically.

So doing the front end as well as the back end.

And for the past 15 years,

I contributed a lot to open source.

As I already mentioned,

my most popular project so far is material for MK Dox.

And it's, well, millions of people

looking, basically look at sites

that are built with it every day.

Yeah, well, and Zencicle, my latest project

will hopefully go far beyond that.

So we're working very hard on it.

And this is why I'm here today.

So excited to talk about it.

Yeah, I am as well.

And let's, let's just start by admiring your website

a little bit.

Thanks.

Brian and I spoke about this over on Python Bites podcast.

And we kind of just got distracted

just staring at the website.

It's this beautiful flow of, I don't know, colors.

It looks a little bit like a black hole worm,

a white wormhole sort of experience.

I don't know.

What was the inspiration there at this cool design?

Yeah, this is actually a strange attractor.

So this is something from physics.

I'm not very, very proficient in physics,

but those strange attractors had,

I had a fascination for them for a very long time.

And they follow very simple rules.

So it's just three equations that define

how their points move in three-dimensional space.

And yeah, but still with those simple rules,

a very complex shape can emerge.

And this is for us actually symbolizes

the process of evolving ideas through writing.

So if you have slightly different conditions from the start,

it's still orbiting around the same shape,

but it might look a little bit different.

And there's actually, I can share this now,

there's actually a little Easter egg.

Nobody has found it so far.

So if you hover over the homepage on zanthical.org

with the mouse in the left bottom corner,

you can actually change the coefficients of the animation.

And if you do this, so you can click on them,

and then you can use your cursor.

I'm changing beta.

We run a beta 0.2T right now.

Oh, it really does change it.

Yeah, oh my goodness.

Yeah, so it takes a little time,

but if you change the coefficients in a specific way,

it might completely chaotic and become unstable.

So this is what I really find fascinating

about those strange attractors.

And it's also the inspiration for the logo.

So we're building on this image a lot.

OK, I thought it was just a cool design.

I didn't realize I had all this.

This meaning and actual math and physics behind it.

That's super cool.

I love chaos theory and all of this,

these fractal type of ideas here and it's super neat.

OK, so what is zanthical?

Why did you build it?

Why not just more material?

So there are a lot of questions in there, actually.

Maybe let me just start by shortly speaking

about what it is.

So in very simple terms, it's a tool

to build beautiful websites from a folder of text files.

So you just write and mark down and can generate a static site.

You don't need a database for it.

So to those who don't know what a static site is,

you don't need a database or server.

It's just static HTML, which means you just pip install zanthical

and you're ready to go within a few minutes.

And it's fully open source, MIT licensed.

And to maybe explain a little bit more about static sites,

so the big benefit of it, you can host it for free

in many places, for instance, on GitHub pages or Cloudflare.

And there is secure and fast by default

because there is only static file serving involved.

And zanthical, so we try to make it pretty

with a modern design, many built-in features,

and fun according to the feedback of our users,

which is kind of unusual for writing documentation.

So yeah.

Very cool.

And if anyone's tried to manually create a static site,

it quickly becomes a challenge.

If you're just writing, say, hey, it's only five HTML pages.

I can just write the HTML, you know what I mean?

But well, what if you want to have common navigation?

Or you want to change the look and feel, you know,

they're like, oh, well, now I've got to go edit that

in five places, right?

And so even just beyond, basically beyond one page,

having something that generates the static site

is, it's super valuable, right?

Because it'll generate the wrapper, navigation,

the common CSS, the footer, all those kinds of things, right?

Yes, so it depends on what you want to do.

So of course, if you have a small site,

like a personal website or so, you can just write

basic HTML if you're proficient in it.

For instance, the users of material,

only 7% of them are frontend developers.

As we can, we will dive a little bit into how

Zenzical relates to material later.

And what Zenzical is being used for primarily

is for documentation.

So it builds on the Doxxus code philosophy,

which means that you treat your documentation exactly

like your source code.

So you primarily write documentation.

You just, you don't want to fight frontend development

problems.

You just want to keep the content, like get the content out.

And with this Doxxus code, what the cool thing about

this is you can, you know, you can use the same tools

and processes and workflows, like you use for code,

like versioning and PRs to make changes.

And the adoption is growing really fast, actually,

among companies in recent years,

and they're moving away from proprietary tools

to open source solutions.

So Zenzicals for you, or a static site generator in general,

is for you if you just want to get your writing out.

And of course, you can also customize it

and make it pretty as you want.

But you don't necessarily need to know HTML, CSS,

and JavaScript.

And that's quite difficult.

And you talked about writing.

And you even have your metaphor with strange attractors.

I personally find if, if I'm just in a clean space,

where it's really just about the ideas,

I don't have to worry about the design.

It makes it so much easier to just focus on the actual writing.

You know, you're in a markdown editor.

My favorite is typore, but you can use

whatever variety that you want, right?

And you're just there.

You're not worried, even hardly about the formatting

in the markdown, you're just writing.

And I find that very a good creative space, I guess.

Yeah, that's a beautiful markdown.

So you can just write, as you mentioned,

and how you, in the end, use it.

You can still decide that afterwards.

So if you want to build a website,

if you want to create a PDF of it,

if you just want to use it for internal note taking or so.

And this is the big benefit of markdown

as it takes away a lot of the headache

of having to remember a lot of markup

in order to get your ideas out of the door.

Can you actually put markup in it if you need to?

For example, maybe you need a particular image.

Two of them side by side that are links

and you want them to open an in-new tab

as somebody clicks them.

Can you set it into basically an unsafe mode

and let it to embed it in markup?

Yeah, that's a great question.

So yes, it's possible.

You can just use HTML within markdown.

We currently depend on Python markdown,

which we inherited from Material for MkDox.

We are gradually moving towards common mark,

which, so just as a context, Python markdown

has some oddities when you use HTML within markdown.

For instance, it won't replace relative or else correctly.

This is like an annoying thing.

But once we move to common mark,

we will also have like predefined components

that you can use because you can't express everything

like more complex things in plain markdown.

So there are only things like you can make text bold,

you can have lists, tables, et cetera,

but if it's more complex,

some, as you mentioned, am aligning to images

or having an image with a caption or so,

you need a basically HTML.

And this is possible already,

but we will make it much easier in the future.

The front and the world already knows this.

So they use MDX, they've been using MDX for quite a while,

which is a dialect on top of markdown

with adds more liberty, with components and so on.

So you can create reusable components that you can use.

Yeah, but yeah, so it's possible.

It's, our users already also do it.

We also have it on some examples on the documentation,

and we will make it much more powerful in the future.

Yeah, very nice.

I do think regular markdown is just,

just a few missing things.

I love the simplicity of it.

And you know, had tips, John, we were for creating it,

but it's just like, there's a,

I just need to maybe put a class here

or just do a little, if I could just control this

a little bit more than you could,

you could basically escape HTML with,

obviously being careful to not just recreate HTML

with square brackets instead of angle brackets, right?

Yeah, there's been a lot of work on Python Markdowns.

On Python Markdown, there are some extensions

that allow you to add classes,

at least to block elements.

So Markdown, you need to distinguish between, like,

inline and block elements.

Oh, no, it also works, sorry,

it also works on inline elements, like links and so on.

But this is special syntax.

So Python Markdown is a dialect that is not standardized,

like common mark in common mark.

This is not easy, easily possible to add specific classes.

But with common mark, as I mentioned,

you have MDX, which is a de facto standard.

I don't know if they've standardized it already.

That allows for much, much more.

So what is Zensacle for?

Is this a documentation generating tool?

Is it a just open-ended static site generator?

What is possible and what is your goal or your target

with this project?

Yeah, so as I mentioned right now,

we're focusing on documentation.

So because this is the thing we're coming from.

But we're building Zensacle for much, much more.

So our stretch goal is to have a fully-fledged

knowledge management and documentation solution.

There are already a lot of companies

that use it internally for knowledge management.

Basically, there's an alternative to ZAS-based solution,

like Confluence and Notion.

We are aware that for this, we need with a WIC.

So what you see is what you get a visual editor

that is also usable by non-technicals.

And if you scroll, if you check out our roadmap

and scroll down all the way, you will see it as a stretch goal,

which is basically something we're working towards.

Because this would actually allow so much more people

within organizations to use it.

And in general, Zensacle, with Zensacle,

we focus on three key areas that make us different

from other static site generators, which is well,

a modern design.

So of course, some also have a modern design,

but within the Python ecosystem,

the some options might look a little bit dated

or a little bit, so we try to be a little bit more

on the edge, actually.

And it should be flexible and it should be fast.

So those three things.

Because the design actually is the thing

that people notice first.

So what we offer is a design that is customizable,

brandable, you have tons of options

with which you can change how navigation is laid out,

how you can also change colors, fonts, et cetera.

And we have a lot of components

that are make it ready for technical writing.

As you mentioned, you just want to start writing.

So we have stuff like admonitions, tabs,

and one specific feature that we have is code and notations

that we inherited from material farm catalogs,

which is quite unique amongst static site generators,

which allows you to put a little bubble

onto any line of code.

You have to visit our documentation.

This is our, you currently browsing our, the other side.

All right, all right, all right.

I got, I got, I got, I'll get this thing.

Right, right, no worries.

Yeah, and there you have the search for code and notations.

Yes, our code and notations,

which allow you to create a bubble

in any line of code.

And if you click that bubble,

there opens a tool tab and within this tool tab,

you can reduce any rich content.

So you can have lists, any mark,

the formative markdown tables, diagrams,

basically anything you can use anyway within markdown.

And this is a very popular feature in material.

And so of course, we brought it over.

So users can still use it.

So the second thing I talked about is, it should be flexible.

So what makes sense is different is we have a modular architecture

or say we're working towards a modular architecture.

We're still in alpha.

So we're close to finishing the module system.

And in the end, there's modules all the way down,

which means all core functionality

is implemented as modules,

which is different from other solutions

where the plugin system sometimes is more or less

an afterthought.

So there's a plugin system added with specific hooks,

extension points where you can hook into.

And this might seem sufficient at first,

but in the end, so for us, for instance,

MK docs in the end was a little bit limiting.

And this allows you to basically swap extent,

replace all modules.

You can use our modules.

You can write your own, pull in third-party modules.

And as I mentioned, Rust.

So don't worry.

You don't need to learn Rust.

You will also be able to write modules in Python

because we are super happy users of Pyro3,

which is absolutely amazing library.

And Pyro3 has really become a super important foundation

of Python these days.

It's almost like the C bindings first.

Exactly.

So yeah, so with Pyro3, it allows us to have a Rust runtime.

So all of the orchestration and how in which order,

so in which order things are around threading,

caching, parallelization, et cetera,

is all is happening in Rust.

And we will provide Python bindings

so that you still can use Python to write modules.

And they're still running fast.

This portion of talk Pythonomy is brought to you by Century.

You know Century for their great error monitoring.

Let's talk about logs.

Logs are messy.

Trying to grip through them and line them up

with traces and dashboards just to understand one issue

isn't easy.

Did you know that Century has logs too?

And your logs just became way more usable.

Century's logs are trace-connected and structured.

So you can follow their request flow

and filter by what matters.

And because Century surfaces the context

right where you're debugging,

the trace relevant logs, the error,

and even the session replay all land in one timeline.

No time stamp matching, no tool hopping.

From front end to mobile to back end,

whatever you're debugging,

Century gives you the context you need

so you can fix the problem and move on.

More than 4.5 million developers use Century,

including teams at Anthropic and Disney Plus.

Get started with Century logs and error monitoring today

at talkpython.fm slash century.

Be sure to use our code talkpython26.

The link is in your podcast player's show notes.

Thank you to Century for supporting the show.

Which brings me to the last point

where we're different.

We have a very heavy focus on performance.

So our goal is to let you start with one page

because of course all documentation sites

or projects start small

and let you scale that to something like 100,000 pages.

How we do it is through differential builds.

We have created our own runtime,

which is called that our X.

And differential builds mean

that we are only rebuilding what changed.

So for instance, if you only change the page title,

only that page and all instances

where the page titles used are being rebuilt.

And this means that changes are visible in milliseconds

and not minutes.

Yeah, that's super cool.

And so I'm presuming the build system itself

is rust-based, right?

Yeah, exactly.

It's 100% rust-ish.

Yeah, yeah.

Coming from Python background,

what was that experience like building that?

Yeah, so that's kind of a tricky question

because I'm not really coming from a long history

so I don't have a long Python background.

I wrote my name TypeScript

and I only started 2021, writing Python.

So this is actually the history,

how material started and how all of this unfolded.

But I've written in several languages,

so I also have written and I can see

Irlang, Ruby, Python TypeScript.

Rust was still extremely hard to learn.

So I basically banked my head

against the keyboard for a month,

wasn't making no progress at all

because, yeah, fighting with the borough checker.

So and once you get past that,

and then of course, lifetimes and hiring trade-bounds

and some other features,

I'm now some kind of like 3,000 hours in something like that.

It gets really good.

So I think Rust is seriously one of the best languages

ever made because it allows you to express ideas

extremely clearly with extreme clarity.

And this is due to the very good type system of course

and you get bare metal performance.

So I find it kind of insane having a language like Rust

because it's so easy to write once you're used to it.

It feel you will be very productive

and still have bare metal performance.

It's completely insane.

Yeah, that's wild.

But it's got a little bit of a learning curve

compared to Python or TypeScript or something like that.

Yeah, so I had, I think, 18 years of experience

with many languages.

As I mentioned, I already did,

I also did a lot of C and I still found it very hard to learn.

But it's, if you were,

by this word, it's worth it.

And my recommendation probably would be to learn it

on something that you really care about.

So that you want to build

because otherwise you will probably lose the drive

since you were running against those walls.

Maybe for you, it's, or for somebody else,

it's much easier to learn.

So maybe it's just, I'm a bad example

that I needed so long, I don't know.

But because after that month,

it wasn't that I was completely up to speed.

So it was just, I was making very, very tiny progress,

at least progress because for a month,

I wasn't making progress at all.

The next show that I'm doing after this one,

which actually has, in real, on clock time,

wall time, it's happening like two hours or less

from now is with Samuel Colvin from Pydantic,

talking about Monty, a Python runtime.

He's, he and his team are rewriting in Rust,

specifically targeting AI.

So the Rust theme will continue.

It's definitely a very, it caught me a little bit off guard,

like how much people love it.

But it's also, you know, it makes perfect sense

that we want this nice modern language

for writing lower level things,

even if it plugs in the Python, right?

Yeah, so the fun thing is I also talked to Samuel

a long time ago, and he was the one recommending

to me to write it in Rust.

So it's one of, is one of the reasons I,

yeah, definitely I looked into it.

And it made, it made a lot of sense also during time,

the progress we're making and so on,

the walls were hitting that to reconsider

or learning Rust, best investment, yeah.

Yeah, amazing, amazing.

So I wanted, I want to dig into your component structure

and some of those things, but maybe before we do,

let's, let's talk about the origins a little bit.

So what, let's talk about how you went from material

for MK docs, why, why even change?

Why not just more material?

Yeah, so this is, there's a great question,

and this is a little bit of a story,

so there are several stories in there,

actually, because it's, so it's 10 years.

I try to go make it as compact as possible

while keeping the most important things.

So to those who don't know,

material for MK docs is a very popular documentation framework.

It's used by tens of thousands of projects.

They're prominent users, like AWS, Microsoft,

OpenAI, also large open source projects use it,

like for instance, fast API, UV, KNative,

and it's built on top of MK docs as the name says,

which is one of the most, which became one

of the most popular static site generators.

And it also eventually became my job.

So I could make it my job.

I could work on open source and earn a living somehow.

I'm getting there how that worked.

And, but at some point, we needed a new foundation.

We've like kind of outgrown MK docs

because it was not evolving at the pace that we needed.

So we began exploring alternatives.

And yeah, so there's a lot of lessons learned in material.

So let me shortly, maybe talk about how it started.

Because it started as a site project in 2015,

like many things start,

because I wanted to release a,

actually a C library, zero copy protocol

buffer library I wrote called Protobluff.

But then I realized that it needed more than a readme.

So I looked at the existing static site generators,

which were Hugo, Jekylls, things,

MK docs, something like that.

And they all looked a little bit dated.

I'm not a designer, but I wanted something more modern

and Google was pushing material design

quite, quite hard for app development at that time.

So, and I've also seen it being used in the web.

So I thought, well, maybe combine this.

I quickly settled on MK docs was easy to use, simple templating,

enough for a site project, basically.

So it was a site project.

Did what more steps to it, checked the license,

and but didn't do an effort at your diligence.

So even put MK docs in the name to show the connection.

So which is common for the in-send.

That actually turned out to be one of the biggest decisions

made in my career since I was basing my complete work

on somebody, something I don't control.

And it shaped the next 10 years of all the work I was doing

and it's actually the reason why Zenzikilix is today.

I see.

So after I started development on it,

I, like nine months later, released the first version

in Senegal users, a lot of feature requests.

And it was a site project.

So I was doing a client work at the time.

As I mentioned, I've been like a consultant and developer

freelancer for 20 years.

And I only had Sundays to work on it.

So which at first was efficient.

But the more popular it got, the more maintenance that came.

So it kind of crept into my mornings and evenings.

And I was doing triage, like answering questions,

and trying to fix bugs before I went to the client.

And it was getting harder and harder

to justify in front of my partner, actually,

because I was doing it in my spare time.

And so I did what, eventually, all projects that

started site projects and where you don't have the full time

to work on it, how they, yeah.

So what basically happens is you start turning down

feature requests.

And many open source projects don't cross this line.

And for me, it was a first.

So, yeah.

And also, additionally, so I mentioned

before that I started writing Python in 2021

at the time I was focusing.

So I only had Sundays to work on it.

I didn't know Python.

So I said that, OK, I will focus on the templating stuff.

I will do the HTML, CSS, JavaScript, all of this,

make it beautiful, and try to solve as much

as many problems as possible in the front end.

But I won't start learning Python.

Because it wasn't a language that I was using at that time.

And I couldn't make it up the time for it.

So that's where I drew the line.

Yeah.

Yeah, and then I tried to be a fan that Python thing anyway.

I don't think so.

But well, at the time, in 2015, it wasn't

clear that it was going to be as popular as it was as it is now.

It's really started to become popular then.

But it's really taken over the world and.

Absolutely.

Yeah, I think so.

Python, of course, yeah.

For me, I think one of the main reasons

is because it's very popular in the ML community

and all of the LLMAI work that's happening

and so on made it extremely popular.

So I also think that Rust is doing a very good job

on keeping it that way.

Because finally, you have a very easy way

to offload work to native code, which is much easier

than fiddling with C and C++ and void pointers and whatever.

So as I mentioned, Pyre3 is just an absolutely amazing library.

It's so easy to write Rust code.

Yeah, I think you're right.

I think Python.

Rust has really provided an important escape hatch for.

I wrote it this way.

It's not fast enough.

Like, well, this part we're going to make it as fast

as I can be, basically.

Yeah.

Yeah.

So, um, so I interrupt you, keep going.

I know where it's, no worries.

Yeah, no, no.

Yeah, so as I mentioned, I try to keep it basically

afloat for the first four years.

And at the time, I didn't see the potential at all.

It was just a theme, not a kind of product or so.

But yet, I felt responsible and kept on maintaining it.

And my developer friends didn't understand

why I was doing that.

So I, but for me, it was like, well, you know,

it was kind of cool because I had a growing project.

I had no immediate plans.

I don't know.

Let's see where that where I can, where I can, can take it.

And, um, yeah.

So, and with this study and slowly growth over years,

then companies and organizations started using it.

So they were basing their public facing documentation

on me, like the guy that maybe works on this project

on a Sunday.

And yet, I felt responsible enough to trying to fix

the bugs reported as quickly as possible.

Yeah.

And, um, yeah, then in 2020, actually came the turning point.

So when I was working on version five of it,

I shared my progress publicly as I did before.

And somebody mentioned a donate button.

Uh, so, and I think the wording was something, uh, like, uh,

so that I can order pizza to survive the long Sunday

coding sessions.

Um, but I heard from another developer who did this

on this project, well, successful project for five years,

a donate button and he made $90.

So I, I, I immediately said that's not going to work.

But, um, I said, let's try an Amazon wish list.

You know, I just put some stuff on there.

And, um, maybe if somebody thinks my work is useful,

then he can order me like, make me a present, something, send me a present.

So, um, yeah, and I basically received everything on that wish list.

It was completely insane.

So there were two consecutive days that felt like Christmas.

I even put like, uh, so, um, I put some, you know,

books and, but then also, uh, single mold.

I, I, I love Scottish, Scottish single mold.

Uh, it was a whiskey with it that cost $120 and I received that as well.

So it was like, what's happening?

Um, and that means to start thinking actually about demographics.

Um, so in that I needed to better understand the audience of material for MK docs.

And I did a poll and the results were absolutely eye opening.

I mentioned before, seven percent only of front of users are front end developers,

which means and materials of front and heavy project.

So I kind of had an edge there in the Python space, um, because, yeah, you know,

it's based based on Python.

So front end developers that write in JavaScript, they rather go for something like

Tokyo Soros or React based or whatever.

And technical writers were quite happy with the project.

I didn't know even technical writers existed.

So I, I had no clue that this job, that, that this is a job because I thought at

the time and it's in hindsight, completely naive, of course, I thought that, um,

as a developer, you need to write the documentation, you know, and so I learned

about that and, um, accidentally build a product for technical writers.

And by the way, when I say product, I mean something that is not necessarily

something you pay for, but something that doesn't feel engineered.

So something that is like polished and, uh, designed and that you actually

want to want to use, um, and yeah.

So, uh, I had a product, uh, a product that has like product market fit and,

but at the time I didn't earn any money of it.

So at the same time, I read about sponsorware and this, like a, I'm not sure if you

heard of it, but it's like a new model of monetization for open source at the time.

It was quite new so that you can get paid for your work.

So you can, so some developers, for instance, they sell course material or access

to gated content or code or nothing at all.

So if you have a popular project, you can just try to raise sponsorships from,

and some companies are very generous when it comes to open source.

And what we did with material was we gave away, uh, away early access to the

latest features to the sponsors and each feature was tied to funding goal.

And when that funding goal was met, it became free for everyone.

So it was like kind of a funded, uh, feature development, uh, in multiple stages.

And, uh, that's what I thought of it.

Sorry.

The super clever.

I really love the idea of, uh, providing something for the sponsors,

but still not turning it into, well, here's a paid version of our product.

And here's the open source version.

But there's always this tension of how do you, how do you reward the people

who support you without undermining the open source project?

And that's, that's a clever angle.

Yeah.

So that's extremely challenging.

Um, so as I'm, as I'm telling you, so this is what I came up with with.

And, and I thought, maybe it could work something like that.

And again, my developer friends, they said, well, never work.

Nobody will pay for open source.

You're insane, spoiler alert.

It did work.

And in the end, we made 200 K a year of it, um, and could build a team and everything.

So I know in Silicon Valley terms, this is probably minimum wage, but, uh, in Europe,

it's, uh, quite, quite an amount with which you can work very well.

And, um, yeah.

So I started this program in 2020 and it, it grew steadily.

And it finally allowed me to work on features, um, outside of the Sunday.

So invest more hours into it.

And finally, learn Python in 2021, wrote my first plugin and started hacking, um,

the MkDocs features, um, that's, well, that got turned down that, that we, um,

upstreamed, but where the maintainer said, ah, it's maybe not a good fit or we don't have

the time for it.

And, um, yeah, in total, I wrote 12 MkDocs plugins.

So it started as a team, but it turned into a popular, sorry, into, uh,

powerful docs framework in the end.

And those were quite well for several years until it didn't anymore.

And, um, that's the reason why Zenzical then came into being.

So the way it didn't work is that just where you wanted to take it, started to diverge

from MkDocs or you, you couldn't get your changes upstreamed or committed back.

So the thing was that MkDocs was not evolving as we needed it in the, it's,

so historically MkDocs had a sequence of single maintainers.

And as far as I know, um, all of them worked on it in their spare time because they had regular jobs.

And material was evolving quickly because, you know, we had funding.

We could, uh, we could invest much more in time in it.

We could, um, then of course, then an open source project that has only maintained in, um, in,

in the spare time.

And so it was changing to slowly.

So we started a lot of discussions on necessary API changes because for many uses material,

for MkDocs was MkDocs.

Uh, so we were kind of like the storefront, uh, where, uh, most of the issues and like bug reports

and feature requests came, came in, um, because more, um, many people are using material for MkDocs

and with this, uh, MkDocs basically, um, and the main challenges that we faced, um,

were performance and plugin orchestration.

I mentioned I wrote 12 plugins and it's very hard to make them cooperate.

And if you look at any popular MkDocs plugins issue tracker, you will find issues that,

um, go something like, well, this plugin is incompatible with this plugin.

Uh, well, if I, if I change the order of the plugins in the configuration, this, uh,

this and this happens.

So and, and those, both of those problems, um, came where brought to us again and again

by, by the users with which we talked.

And, um, so, you know, it was coming, coming up a lot, um, then suddenly after nine years,

the original maintainer returned to MkDocs.

And we were super optimistic because the project was like maintained again.

He also started a sponsorship program.

We upstream some of our funding immediately and supported this work.

So before MkDocs have, um, had no way to sponsor them.

And, um, the moment this, uh, this went live, we immediately supported it.

And some PRs were finally merged and issues were closed.

But, yeah, then, um, the works went silent and it started working in, in basically,

uh, in the quiet.

And three months later, we were invited to a video call.

Um, so, um, we as maintainers from, um, so I as a maintainer for material for

MkDocs and, um, some other key ecosystem maintainers.

And we learned that MkDocs, um, that the plans for MkDocs 2.0 were completely

different, uh, from what existed at the, so what currently exists.

MkDocs 1.x, uh, which primarily means no plug and API and customization via

templating alone.

So we already knew this is not enough because we've, that's what we've done the

first four years where, as I mentioned, I was only doing the templating.

And some things you can't just do with templates, um, for instance, um, having

a, um, tax support where you need to pull in different, tax from different pages.

And then render them on another page or so.

So you need synchronization efforts and you can't do this with, with templating.

Yeah.

By the way, all of this information is public.

So, um, you can read it on the MkDocs issue tracker.

So, um, yeah, I'm not telling anything secret or so.

Yeah.

So it's a completely different direction than the one that we worked on and we

erased objections in the call and, um, but, yeah, still they were dismissed.

So MkDocs 2.0, as it looks right now, uh, is something incompatible with

MkDocs 3.0 plugins and ecosystem will become useless and tens of thousands of

projects will be affected and for us.

So we had absolutely no choice then to start building something.

So to start make something off this because at the time we had already 50,000

projects, uh, 50,000 public projects, depending on us, um, we talking to enterprise

users and we knew that this number is much, much higher.

So for instance, one of our professional users, um, they already also

sponsored material, they have two and a half thousand projects internally.

So only one, one company and they have a dedicated team of individuals that

maintain their, um, customizations on top of MkDocs for all of the teams inside

the company.

It's a very big company.

So, uh, that's, uh, what you could infer from the, I, I, I, I could, I could,

my, yeah, I could believe it, uh, I couldn't, couldn't believe it at all.

So absolutely insane.

Yeah.

So, um, as I mentioned, we had no choice.

So what we did was we immediately, immediately went back to the drawing board with the

learnings from the, from the, um, almost 10 years that passed since I started material.

Uh, we build a lot of prototypes in types, Krypton Python, um, iterated on them.

We did a lot of conceptual work and, uh, realized within weeks, what could

actually be done with a radically different architecture?

Because writing 12 plugins, I, you know, I know the, the ins and outs of MkDocs.

I, I know the, uh, so I had to do a lot of hacks, for instance, to make the block plugin

of material work with the way navigation works in MkDocs.

Um, and, um, the number one complaint, as I mentioned, was it MkDocs is slow and it

doesn't scale.

So like fixing a typo, you're doing a full rebuild and this can take minutes.

So our design work centered exactly around this problem.

And after a short while, so, uh, we knew exactly what MkDocs should look like, um,

and we didn't want to let our users down.

And we, so in, in essence, we had two options.

We know what it should, should look like, uh, we could fork it or we could start

from scratch and forking is not really possible the way, because of the way

how Python dependencies work.

So all of the plugins have a dependency on MkDocs.

And this means that we would also need to fork all of the, so without doing,

uh, black magic with imports, uh, which is, might not be the best idea.

Um, so we would also need to fork all plugins or all plugins would need to switch

to the fork.

So this would be like moving an entire city at once, and it's frankly impossible.

So, and we, with, uh, if we would fork it, we wouldn't be able to realize our

learnings that we gained in the groundwork that we did.

So we had to start from scratch, actually.

All right, plus you'd have to convince the entire community to at least create

a parallel package.

Cause when you pip install that other plugin, it's going to say, Hey,

PyPi, I, I need MkDocs and now you'd need the forked version, you know,

whatever that's going to be called, right?

So yeah, it would be a big battle, wouldn't it?

Just technically with, or a, or a commute, you'd have to move the community,

which is a very challenging thing to do.

Yeah, and, um, so for us, the, the most sensible thing was to just, you know,

we just start from scratch, um, we make it as compatible as possible.

Uh, that was, it became quite clear very quickly that we need to optimize for

compatibility because if you create something that is not compatible and that

forces uses to migrate documentation manually and to do a lot of work to get

over to something, something else, um, you won't get a lot of adoption.

So, all you got to do is think about that, that 2,500 project team, like, okay.

How do I keep them working with this, right?

Yes, yes.

Yeah.

So, um, what we, what we then did is, uh, we had an idea how it should look.

Um, then we started with Rust because it was recommended to us.

So it was very hard at first and, um, it, in, in total, it took us 16 months

to, um, to build all of this, but it was not only writing code.

It was also exactly knowing where we want to go, um, because, you know,

we're starting fresh.

So we better be sure that we are going into a direction, um, where we actually

want to go for the next 10 to 20 to 30 years, depends.

So we are, we are, we are, we are really in for this for the long game.

Um, so the 10 years that I've been doing this, uh, I only, I see that this is only

the start.

And, um, we wrote a lot of things from scratch.

So, um, the runtime, as I mentioned, it's like the heart of Zenzical, um,

it, uh, already has something like 15,000 lines of code, um, a tiny HDDP

middleware framework for file serving because we don't want to, so we want

also want to make the fight server extensible and don't want users to force

them into async rust and also don't have a, um, dependency on Tokyo, um,

and, uh, also like a monorepo management tool for Rust and JavaScript that

we also open sourced, which, um, not sure if you've worked with monorepos,

but in JavaScript, for instance, there's learner and it has 800 dependencies.

So when you install it, you, what you pull down is just insane.

Uh, so we worked a lot on the processes as well that we can make releases

very easy and that we have a good way of working basically.

And we're very, very careful about our choice of dependencies.

So if it's not something that, so let me put it another way.

If it's something that you can write quite quickly, actually, and, uh,

we rather own in order to make changes ourselves.

We rather write it from, from scratch.

Yeah.

I think that's a very healthy philosophy.

And also, I think this agentic AI world that were in these days,

if you just need one or two functions and used to think, well,

maybe I'll lean on this and in your case, a crate or maybe a, a pipi package or

something, but if it's just one or two functions, maybe you really can just

write it yourself without much effort and it just, it saves you so much trouble.

You know, uh, I started using pip dash audit, pip audit for a lot of my projects.

And I would say for, for my bigger projects, every, every two weeks,

I get at least one CVE vulnerability notification for something I'm using.

I'm like, uh, but here's the thing.

It's, it's in a situation of that probably a piece of code or

functionality of that package that I don't even use or care about.

So it doesn't really apply to me, but then I've got all these, like, here's

an issue, like a latent issue that is in my code.

Yeah.

I'm going to have to figure out and deal with, but it's because I've taken in

so much as part of this package, where if I had just written the one or two

functions, then it'd be fine.

You know what I mean?

I think there's the, it's, I think things are swinging back a little bit from

like, let's just, just pull in everything because it's going to help us to

like, well, maybe not everything.

Yeah.

And also you, you're not, you can't just change things easily.

And you depend on, um, other API.

So for instance, um, one of the reasons why we cheer, why we choose to build

a lot of things from scratch is that we want to control the public API.

So the worst thing for us would probably just be to export a third party API

that we're using as part of our public interface because it's rust.

So it would mean that if those, this public API would change the entire

ecosystem would break.

So we're very careful.

What to what, what APIs we, um, expose and rather wrap it in order to be

safe so we can replace things, if things replaceable.

So maybe you have the philosophy of it, it might be okay to use this

crate, but we don't, we don't exchange its types as the public as part of

our API or something along those lines.

Yeah, we don't expose it.

So we, um, I've, um, in, in some instance, the rappers that I've wrote

are identical to the, um, to the types that we, um, that we use from another

crate.

But by using our own types or just wrapping them, because in Rust, the,

the nice benefit is, um, you have zero cost abstraction.

So the, all the code is monomorphized in line.

So you don't pay for, um, wrapping code.

That's the absolute crazy thing.

So it's, um, you can finally create a really clean architecture without

runtime, um, penalties if you do it right.

Oh, that's wild.

Yeah.

Yeah.

Yeah.

Very interesting.

So you can see I have a huge list of topics we're, um, we're basically just

barely crack, crack, crack the surface.

But I like to go back to this, uh, this component, um, wrong, uh, wrong search

there.

You have a component, um, that was in the other part of it.

Let's just talk down, talk through some of these, these things you've got, like, uh,

admonitions, buttons, code blocks.

Like let's talk through some of the building blocks, I guess that you think are

interesting here.

Yeah.

So I think most of the, uh, so if you, um, if you're not new to technical writing,

most of the stuff shouldn't be quite new.

So like admonitions, code blocks, stuff like that, you've probably seen our data

tables, uh, diagrams are just pyramid diagrams, uh, as they are, as they can,

you, as you can use them on GitHub, uh, one of the, so like the, the, the,

the flagship features in material or in, and now Zenzika, um, as I mentioned,

like code annotations, which is a part of code blocks.

Um, otherwise we also have a, an icon and emoji integration.

So, um, you can use one of, I think we have something like over 10,000 icons

now, um, with a quite simple syntax.

That's not standard markdown.

That's the problem.

So that's like a Python markdown extension, um, and we're working on moving this

over to common mark and finding a way to, um, to migrate this over, um, because

you know, right now it's, uh, Zenzika uses Python markdown for compatibility

with materials for MK docs, which means that for markdown rendering, we need,

we need to go through Python.

And this is a temporary limitation that we have, um, because I mentioned

we are focusing, uh, really hard on compatibility, um, and all of those

components would also be, of course, be available within our common mark solution

that we're working on that we will ship, um, later, later this year.

Um, yeah, but, um, yeah, right now, of course, you can use them as their

mentioned on our documentation and we will, of course, provide automated

tooling to get them over to common mark.

Yeah, I guess it's interesting that you've got to not just consider the API

and, and the syntax and stuff, but maybe even the same parsing engine that

have this strong compatibility, right?

Yeah, we can even read MK docs, why I'm a configuration.

So you can build an MK docs project with Zenzika as, as it stands, the thing

that we currently don't support in its entirety is the plugins from the

ecosystem. We, uh, or we already support some plugins.

Uh, for instance, the MK docs strings plugin, the author is also part of

the Zenzika team now with MK docs strings being the second biggest project in

the MK docs space, so we're very happy to have them on board.

Um, and several other plugins, but as I mentioned, so Zenzika uses modules.

So what we will do in the end is we will still always be able to read MK docs

configuration and map the plugin configurations to equivalent Zenzika modules.

So the logic will be completely rewritten, but you will be able to migrate

your project with a command.

That's our, that's our goal because you know, there's, has so much work

been going on into projects built with material and MK docs.

So, uh, we need to make it easy for users and organizations to switch.

And this is the main part we're working on in 2000, uh, in 2026.

I think this is, it's critical, right?

If you, yeah, you're absolute best users, you know, like that, that big company,

but many others, of course, they're not going to rewrite everything.

Well, maybe they will, but many of them won't rewrite everything.

They'll just use an old version and grin and bear it as long as they have to.

You know what I mean?

Like this, this idea of, um, doing it from scratch.

But if you provide a, a path for them, that's very easy.

Then all of a sudden, they get this way better experience, right?

I can only imagine, you know, the build speed helping out the, the bigger projects,

the most, yeah.

And the compatibility part is one of the hardest engineering parts, actually.

So that you have to think about them, you know, because we don't want to pay

ourselves, paint ourselves into a corner.

So we need to think about where do we want to go?

But how can we go there faster right now without making sacrifices in a way

that we can't in the end replace things?

And we have a pretty elaborate plan, how to do all of this.

And yeah, so we're working very hard on it to make it.

So right now you can just use, use material, of course, you can, you can keep using it.

Or if your site already built in Zenzical, you will have better speed and the modern design

and the better search.

So the search has been completely rewritten.

From material to to Zenzical, it's also, it's currently integrated.

It's integrated with Zenzical and we will open source it as a dedicated open source

project.

It's, it's called disco.

So you will also be able to use the search in other projects.

And for just as a number to get a feel for it, it's 20 times faster than the search

in material for Mk2x.

So it's a ground up rewrite.

And we, we actually started working on the search before we started working on Zenzical.

Yeah, I noticed how nice the search was when I was playing with it, um, we're in.

So is Zenzical.org itself built in Zenzical?

Yeah, of course.

And it's actually built with an Mk2x YML because with dock booting.

So it, you can also build it with, uh, with an Mk2x, uh, with material for, for Mk2x.

The project layout is exactly the same.

Yeah, you know, I find that, uh, there's just a bunch of static sites that seem to have,

I don't know what's going on with them, but their search is really bad.

You know, either, either they've just integrated some kind of Google thing,

where it's a site colon and they use your URL.

And then the search, which is a real bad experience, where you go search and it sets

there and it spins and it spins and, and then eventually it pulls up.

So it looks like you are pre computing these types of things or something with your search engine

or I've got some cool data structure to make that fast, right?

Well, it's not one cool data structure.

That would be great because then everybody could just use it.

But, um, no, so, several, several, several months of work went into, into the search.

Um, of course, I, um, so it's, it's a project of its own, as I mentioned,

it's also completely modular and, um, the reason why I'm most of the search engines

that are out there that are open source, so like the libraries that that you can use,

not services you have to pay for, that they are, don't provide results that are really relevant

or us, um, is that they use PM 25, which is like the standard, um,

bag of words, ranking algorithm for, um, information retrieval and this doesn't nicely pair

with autocomplete. So what you get is you start typing and you get a lot of dancing results

because, um, and also if you, if you add, uh, further documents to your index,

the, the balancing will be off because it's, um, the relevance is computed based on the occurrence

of a word in the entire corpus.

So you add a new document, those, uh, and those weights change again.

The search that we have, um, we, of course, as a baseline, also have a PM 25 implementation,

but, um, the implementation you see is a tie breaking implementation, which, uh,

provides much, much better accuracy and you can configure it.

So, um, tie breaking means, okay, we first look into the title of the, uh, document,

then, uh, and see if we have matches, then how many matches, then where they are,

then we look into the navigate in, in, in the path and then in the, uh, body of the document

and so on. All of this is configurable and, um, this is also why we believe that this

will alone will also be a very interesting project for other, for instance,

static site generators to integrate. Um, and you asked about like pre-computing.

So no, this is a search from the documents.

We put a search index, which is a strap down version of the HTML, uh, that is, um,

rendered when you, uh, when you load the page, um, it's one JSON that we ship to the client.

And for, for most pages, actually, this JSON is below one megabyte.

You can GC it, so compress it, uh, then it's something like 200k and you have

extremely fast search on the client with no cost.

And so we believe that, uh, for 90, 95, maybe 99% of documentation sites or sites in general,

this client site search is basically the way to go because it's fast.

And, uh, it doesn't require you to pay for anything.

And there are several ZAS based services that can be extremely expensive when you make,

when you do the math. So, um, yeah, you only need to use a server basically when you,

when the index becomes too big to ship to the client.

And we're also working on that by way. Okay. That's really cool.

You could shard the index or something like that, right?

I suppose, like you could say, we're gonna have 20, 26 index bits.

And if only if the word starts with an A, do you pull that piece down or something?

But yeah, not a lot of cool aspects.

Yeah. It's not not that simple, uh, but, uh, there are also some other,

in some other interesting solutions like page find.

It's a pretty interesting library. It doesn't completely different approach.

But, um, it's not as snappy as, um, the search that we ship to the, to the client.

I use page find for my personal website, which is a static site.

Yeah.

It's also a great, great solution. But, um, you, some, some things you won't be able to implement

in page find properly because, uh, so it's, you know, it's with software.

It's trade-offs all the way. So, well, I'm already thinking like I better pay attention to disco

when it comes out. So, maybe adopt it for some stuff. Beautiful. Okay. Uh, we got a couple

interesting questions sort of following up from the, the component side of things.

James X says, do you foresee a community-led templates or themes for Zenzical?

I know you have like two themes that I see something along those lines. A couple of themes

that you can choose now. But what's the, what is the theme story, I guess?

I don't want to ask you more broadly.

Um, yeah. So, absolutely. So, right now we have only this one theme.

Um, we have this variant setting where you can choose like the classic variant.

Which is, if you, when you, um, move over from material for MCADOX,

it looks exactly the same. Um, this is also why we needed to keep the HTML as it is,

also with the modern design that we provided and the modern variant, which is the standard

for Zenzical. In the, uh, we, once we move to the component system, we, um, will make it possible

to, uh, one, use components within markdown and two, also, uh, create a template engine that

is based on, uh, on components. This will allow us much, much faster rendering because,

uh, for instance, if you render the header, uh, on a, for a site, it's a lot of HTML because,

you know, there's the search box in it and some, some other stuff. But only the title changes.

So we will also make the rendering differential as part of the build that's, that's the plan.

And with this, uh, we will also make it open to, um, to the imbi developers, of course. So there

will be, um, the, like, packaging, um, for instance, compilation of, of ZAS, um, styles or

typescript or so will be part of Zenzical. So you don't need to pre-compile the theme like you,

we need to, we need to do for like the last 10 years for material. Um, so it will have a proper

asset pipeline. It will have a proper process to install themes. All of this is planned. But

right now we focus on feature parity. Um, so in order to make it possible for more users to migrate

right now, that's really interesting that you would deliver the theme as basically it's,

it's original source. Not it's rendered, you know, compiled or transpiled version, right?

To keep it. Yes. It's a part of this Zenzical build step, right?

Yes, exactly because, um, it's, we had a lot of requests for something like, hey, can we change

the media queries a little bit because the sidebar disappears too early for my, um, for my taste.

And, um, this is not, so for this, you have to go through the compilation step again and basically

fork the theme and recompile it. Um, we want to make this configurable so that you can, uh, use,

um, yeah. So, you know, configure the theme and build it and it just works. So this like, you

know, it just works. That's like the thing we're working towards. Make it as simple as possible.

Yeah. Yeah. Very cool. Let's maybe get short on time and maybe wrap up our, our chat talking about

two things. The future where you go and you talked about, um, compatibility being a big part of

things going forward in 2026, but also sustainability, right? You had all these great supporters

for material for MK docs, which you must have just been absolutely thrilled to realize how successful

that was, right? I mean, going from all, put up a wish list and then actually people love this.

I can, I can put all my energy into it. I mean, I know how great of a feeling that is, right?

That's completely insane. And I would, when, when I, when I started it, I would never believe

that it, that this would be my, my job at some point. Yeah. I feel the same way about the podcast.

And it's just, I'm so grateful for it. It's amazing. Yeah. So, yeah. Um, but then with this

transition to Zensacle, how does that change? Does that change anything or what's the story? Yeah.

So how do you bring that support over to Zensacle? As we don't have a lot of time, I try to make

explain it as compact as possible. So, um, we are saying goodbye to this pay for features, pay

for extra features. So by mid in material, you needed to be a sponsor in order to get the latest

features earlier. What we will do is, uh, everything is open source from the start. So, um,

it's for users. It's completely free. And, um, we are shifting our model, uh, from, um,

the sponsorships to something we call Zensacle Spark. Because what we discovered, uh,

talking a lot to our professional users is that the more we know about, um, the problem space

and the better we understand the problem space and the more we can collaborate with them,

the more we can, um, the better degrees of freedom we can provide. So we just, we don't intend to

just chip, um, feature feature feature, but we intend to, um, create degrees of freedom so that

you can adapt Zensacle to the processes within your organization, how they work to workflows,

et cetera, which are all different, which is all of a very diverse, basically. So Spark is a space

where you as a, um, as a company can basically get a seat, um, and together with us,

shape Zensacle as part of high level discussions where we explore the problem, the problem space,

we create proposals. So on the website, you will have clicked on the Spark section, um,

there's this zaps and progress. We call them zaps, Zensacle Advancement Proposals.

It's on the left side. Um, we write, um, very elaborate detailed proposals on specific topics

that we intend to work on. And then, um, with the feedback that we get, iterate on them and, um,

create a authoring, like the ideal authoring experience that, um, caters to the most cases possible,

um, because we want to build Zensacle, um, as I mentioned, like for the very long term, and not

as just a solution that is opinionated, but that is an unopinionated as possible. And the,

the third thing that you get besides like those, uh, the opportunity to discuss, um, like

high level discussions, discussions with us and create the proposals with us is, of course,

professional support. So this is also, we've been asking, uh, we've been asked for quite a lot

by companies. Um, so in Spark, you, um, yeah, you can basically, um, get, um, our time, you can,

we will, you can get direct access to the team. And, uh, also we have like those open video calls,

uh, where we share our progress and where you can get a, um, a window of support. And we talk

about any problem that is, uh, keeping you up at night, basically, and stuff like migrations

or how do you do this and this in Zensacle? And, um, yeah, it's, uh, it's been a blast. So it's,

we're really happy that the organizations are enrolling into this, uh, new model. Um, we think

it could also be a model that might translate quite well to other projects because you get a huge

competitive advantage. You know exactly what to build. Yeah, you're, you're on, you're talking to

the actual users. They're saying this is the thing that really is hard for us or you could just

get, maybe they don't say it, but you see it, right? Exactly. Yes. Yes. And the talking to the

users is the best thing you can do. So what we learned from those, uh, from, from the many times

we talked to them is always something like, wow, we never would have come up with this.

Congratulations on the success for material for MK docs and then this new project. I'm very excited

to see it coming along and it looks like it's going to be great. Maybe a final call to action for

people, like, can they go ahead and start using Zensacle? If they're interested, what do they do?

So on. Yeah, of course. So, uh, you can, uh, so we mentioned material for MK docs a lot. And this

is, uh, because, um, we are coming from this, this direction. So it means if you have a material

for MK docs project, you should definitely try out Zensacle and see if you can build your project.

But if you haven't used it, you can also just, uh, jumpstart a new project. Uh, it has a lot of

building functionality already. You get like, um, all of these components that we talked about,

free search, free search that you don't have to host. Um, a very modern static site that is

great on mobile. So just give it a try. And, um, we have a newsletter. So, uh, where we, um, once

a month, share the latest updates and, um, that, um, might also be worth checking out. Yeah. And

otherwise, um, we'd be happy to, to see you, um, to, to get any feedback. Also, uh, by the way,

we also have a public, um, a public discord, a community discord, which is growing very well.

So if you have any problems or so, then you would, um, get help there. Yeah. Would be, uh, great

to see as many users as possible, of course, and shape it to shape the future of Zensacle together

with all of you. Fantastic. Martin, thanks for coming on the show. Congrats on the project.

Thanks for the invitation. And happy anytime to come back. Yeah. Sounds good.

This has been another episode of Talk Python to me. Thank you to our sponsors. Be sure to check

out what they're offering. It really helps support the show. This episode is brought to you by

century. You know, century for the air monitoring, but they now have logs too. In a century,

your logs become way more usable, interleaving into your airports to enhance debugging and understanding.

Get started today at talk python.fm slash century. If you or your team needs to learn Python,

we have over 270 hours of beginner and advanced courses on topics ranging from complete

beginners to async code, flask, jingo, htmx, and even LLMs. Best of all, there's no subscription

in sight. Browse the catalog at talkpython.fm. And if you're not already subscribed to the show

on your favorite podcast player, what are you waiting for? Just search for Python and your podcast

player. We should be right at the top. If you enjoyed that geeky rap song, you can download the

full track. The link is actually in your podcast blog or share notes. This is your host, Michael Kennedy.

Thank you so much for listening. I really appreciate it. I'll see you next time.