drawing in funding

I recommend setting up GitHub Sponsors. I personally find it to be the most convenient way to contribute financially to open source software projects. I was using GitHub Sponsors as a way to support MkDocs prior to the recent change in maintainership and would be happy to continue to do so.

As regards team management I don't have any significant concerns, although we will need invested parties stepping up. I do think it's important for the ecosystem that MkDocs has a strong and independant leadership distinct from Material for MkDocs, while still drawing from their expertise & experiance. We've got plenty of smart capable people here, and I'm sure we'll be able to step up to the mark, together.

Didn't notice on first read, but I find this part a bit confusing. Is it speaking about building a team, or leadership? IIUC you are the leadership now @tomchristie ( 🎉 ), so I'm not sure why we make a special case of Material for MkDocs regarding building a team. Don't we want them on the team 🤔? Or did you mean that leadership will be embodied by the whole team? Not sure to understand 😛

I should have started with that: welcome back Tom! Glad you're stepping up and investing time in MkDocs again to lead its maintenance and growth 🙂 It's good to have someone dedicated to it, especially when they're the original author 😄 Happy to hop on the saturday call to chat 🙂

Okay, I'll take an open call tomorrow, Sat 27th at 7 AM UTC on https://meet.google.com/fes-iqes-fyr
Appreciate the weekend Europe morning might not be best time for all, but it's a starting point.
Perhaps we'll be able to schedule within more sensible weekday working hours for a future call.

Edit: Confusing myself with timezones.

Thanks @tomchristie and @fralau 🙂

The few things I wrote down:

• easing creation of new themes: we already link to a basic theme that serves as an example, but it probably doesn't provide the "Python packaging" bit. Maybe we could offer a Copier template that does just that.
• for a better DX when creating plugins: provide clear guidance and API to handle errors (exceptions, we already have PluginError), handle warnings (deprecations, etc.), and log messages (this one is quite good already, but I very recently found myself needing to support a once parameter when logging, to prevent the same message from showing many times).

Hello,

Since Material for Mkdocs entered in maintenance mode, it seems that Mkdocs project needs a fresh start no?

Dear All,

First of all, I want to thank you again for your contributions to MkDocs. After these years, it seems that there is a group spirit. 👍

I have briefly looked at Zensical, and I am not sure I get the full picture. @Andre601, why do you deem that MkDocs has become a "roadblock"? You are probably in a better position than me to perceive the technical limitations.

My perception is that MkDocs' core is brilliantly built, but the plugin and extensions ecosystem has grown in various directions, and might need some organizing principles (particularly to make the plugins compatible with each other).

Dear Friends,

I looked at the statistics of MkDocs, and I found there are 86'000 repositories, small and big, that rely on MkDocs. This project has 21.3K stars. That indicates that there are tens of thousands of websites right now, that depend on MkDocs for their production.

It is a fact that MkDocs is a trusted product that changed life for a lot of documentation writers. A lot of them, like me, have a debt of gratitude to its author and maintainers. There is profound intelligence in the way it was designed, and thoughtfulness about how to extend it with plugins; it evolved over the years with many contributions.

Certainly, MkDocs's author and maintainers would make it differently today. However, it has the merit to exist and to work. This discussion itself is proof that MkDocs matters.

The scope of this discussion is thus our shared responsibility toward those many people (documenters, developers) who have been helped, and are being helped daily, by MkDocs.

For the current situation, indeed the code frequency (additions or deletions per week) indicates that this project might be in a dangerous position.

However, solving it, may not necessarily mean taking draconian measures. On the contrary, it might become solvable if we consider that everyone here has good intentions and has demonstrated competence in some key areas; and by pointing the finger at facts, rather than individuals.

An action in that direction would be to pull our heads together on the questions raised by #4010, which (in my understanding) is essentially a question of PRs and commits. What if we decomposed that problem in its constituent parts?

I believe that in a discussion where there are disagreements, we should at least find a few basic facts we can all agree with.

The first is that we all love MkDocs and wish it to continue and improve.

Another key fact, is that we all wish to respect and follow the rules that govern open source software, and the management of public repos. MkDocs is published under a BSD-2 (simplified) license, which is permissive.

This gives rights and duties to each party:

1. Tom Christie is the creator of MkDocs. If my data are correct, he holds the copyright on the code base, as well as the property on the name (MkDocs) and repository. By the rules we all agree with, has can exert those rights in any way he pleases. It would be illegal to pressure him to relinquish those rights, regardless of our opinions. We should consider this repo as his own home: he can have as many guests as he wishes, but no one here has the right demand admission to his private property, exert social pressure on him, or trespass.

2. Each of us may redistribute the code of MkDocs and use it in source and binary forms, with or
   without modification, essentially in any way he pleases as long as he respects the conditions of the license.

So that leaves us with only two acceptable solutions:

1. Either an amicable solution is found with Tom Christie's free consent, as the legitimate owner of the repo and name, to allow further PRs and merges.

2. Or, a group of developers make a fork of the MkDocs project with a new name.

Solution 1 requires acknowledgement of and respect for Tom's rights. With solution 2, each of us would decide which project they want to stay with. A fork could be done in an amicable way, by stating and respectfully acknowledging each other's divergences. That would be much better, so that users would then know why they are choosing one project or the other.

I would welcome solution 1 and encourage it; but I wouldn't oppose 2 if that was required to restore the peace.

Happy New Year 2026!

Following up on the conversation, do we now wish to explore the fork solution?

We have been heads down migrating from httpx to aiohttp due to the sudden and unexpected death of the project (check encode/httpx#3784 for details) Then I ended up on this page, coming across familiar faces...

Thank you @ofek for your note on Zensical, and preventing yet another supply chain disaster.