On September 2, 2026, Ivan Bochkarev published an open letter to the project leadership and the MODX Revolution team on the official MODX forum. The Russian version was published on modx.pro.

Open letter on the official MODX forum

Russian version on modx.pro

The essence of the proposal is quite simple: the author believes that the development of MODX is hindered by the existing management model. As a solution, they propose a public roadmap, more predictable handling of Pull Requests, regular releases, and, most importantly, the creation of a distributed Core Maintainers Team with the transfer of additional technical authority to active participants. The letter itself explicitly states a desire to participate in shaping the roadmap, influence the outcome of their work, and see their changes in official releases.

I understand this as a proposal for the modx.pro community to gain more real influence over the official MODX Revolution.

I disagree with this.

modx.pro is a separate community with its own interests

First of all, I believe it is necessary to stop automatically equating modx.pro with the entire MODX community.

modx.pro is a large, well-known, and historically significant Russian-speaking community. However, it is an independent platform with its own participants, administration, economy, and interests.

The history of Russian-speaking MODX has never been reduced to just a single platform. There were modx.ru, community.modx-cms.ru, modx.im, and other centers. They appeared, conflicted, broke apart, and replaced one another. I have already written about this in detail in the article "How the MODX Community Died".

Therefore, in the current situation, I am also interested in another question: where are the other communities?

The official international forum exists, GitHub exists, Slack exists. But where are the other independent engineering centers of MODX today that are shaping their own vision of its future?

If virtually no such centers remain, and the most prominent active community turns out to be modx.pro, which increasingly resembles a commercial ecosystem around components and services, then perhaps the problem runs much deeper than the lack of a roadmap and slow PR reviews.

Perhaps MODX truly no longer has much of the engineering community that once drove the platform forward.

Why I am against granting modx.pro additional authority

I don't need to guess how the modx.pro community will handle power. I have already seen how it handles the power it currently has.

A recent technical conflict on modx.pro ended with the deletion of the discussion and the blocking of my account. Then, after trying to publish an open appeal in the ru_modx Telegram group, I was banned from there as well. I have already described these events in the "Open Letter to Nikolay biz87 Savin".

What matters to me here is not the personal side of the conflict. What matters is something else: when a strong independent technical opponent appeared, offering a different direction and openly disputing the existing model, the conflict was resolved through administrative means.

Now this same community proposes giving active participants more authority within official MODX. I see no reason to support such an expansion of influence.

Especially considering that modx.pro has its own established economy. I already analyzed it in the concept "modx.pro is not a brother to the community and end business": the platform is increasingly built around Extras, MiniShop, pdoTools, Modstore, integrators, and development and support services.

A viable MODX is objectively profitable for this economy. The longer MODX lives and the more projects depend on the existing component stack, the longer the market around it exists.

Therefore, I do not consider modx.pro a neutral party when it comes to the development of the core. Granting such an ecosystem greater influence over the roadmap and technical decisions will, with high probability, lead to MODX better serving precisely this existing model of components and services.

I do not see a new technological future for MODX here.

120 Pull Requests do not make a new future yet

One of the main arguments of the open letter is about 120 open Pull Requests and more than 570 Issues.

However, the number of PRs in itself says nothing about the direction of development. If you open the Revolution backlog, there is a lot of useful work: fixes for ACL, Resources, Package Manager, Manager UI, lexicons, sessions, compatibility, CI, and other parts of the system. There are also deeper refactorings.

Overall, though, I see primarily maintenance and the gradual modernization of the existing Revolution, rather than a new MODX architecture created by the community that simply cannot get into the core due to a lack of merge rights.

This is important because the fundamental problem of MODX, in my view, has long run much deeper.

As I wrote in the concept "MODX is legacy that isn't going anywhere", MODX 3 received Composer, namespaces, DI, and modern PHP mechanisms, but the fundamental model of Revolution remained the same: Resources, Templates, TVs, Chunks, Snippets, Plugins, the parser, and most of the system's overall architectural philosophy.

You can speed up merges by several times and still continue very effectively maintaining a fifteen-year-old architecture.

Therefore, I see no grounds to believe that additional authority for modx.pro will solve the technological problem of MODX on its own.

All of this was already discussed half a year ago

The current open letter did not appear out of nowhere.

On February 27, 2026, a large thread appeared on the official MODX forum titled "The future of MODX: ideas, roadmap and release cycle?". They discussed virtually the exact same things: the lack of a roadmap, slow PR reviews, ExtJS, release regularity, community participation, and a shortage of decision-makers. Participants explicitly noted that such conversations have been repeating for many years.

Ivan Bochkarev participated in this discussion personally. Even back then, he outlined a fairly specific vision of the future: an API-first core with REST and GraphQL, a micro-kernel, DI, Composer, Vue 3 Manager, Redis, RoadRunner/Swoole, CLI, migrations, tests, and other changes.

In that same thread, Ivan wrote that since February 22 he had submitted 79 PRs, of which only one had been accepted at that time, and later formulated something even more important: if they were given freedom, even the two of them could complete a significant amount of work.

In the same discussion, core maintainer Jason Coward described the flip side of the situation: the active core team essentially consisted of just a handful of people, and a large flow of PRs without prior architectural coordination did not remove the bottleneck, but rather increased the load on those who ultimately had to evaluate and integrate the changes.

And joshualuckers was already warning back then that MODX initiatives like this have gone through the exact same cycle many times: discussion, hopes, a lack of sustainable changes, and a few years later, a new conversation about the very same problems. Now, following the new open letter, he wrote bluntly: "It looks like history will repeat itself, as usual. Sadly."

For my objections, this changes nothing fundamentally. I still do not consider transferring additional authority to the modx.pro community to be a good solution.

However, this past discussion seriously reinforces my compromise option.

Make a separate MODX 4

If Ivan and the modx.pro community truly have their own vision for the future of MODX, they do not need to first acquire additional rights within the current Revolution.

Open Source already allows you to take the code and make a separate next-generation branch — a conditional MODX 4.

Ivan already has his architectural vision, dozens of PRs, and a publicly stated readiness to work hard. modx.pro has a platform, an audience, and its own community. This is enough to start implementing their vision independently of the current MODX Revolution review process.

There is no need to obtain additional merge rights in the official branch in advance. There is no need to coordinate every step with the current maintainers. There is no need to maintain backward compatibility where it gets in the way of a new architecture.

Build the MODX that you consider correct. Assemble it into a full-fledged product and distribute it via modx.pro. If MODX 4 turns out to be genuinely successful, attracting users, real projects, and demand — a migrator can be created, and further relations with official MODX can then be discussed based on working results.

How exactly to organize development, releases, documentation, and other processes is up to the modx.pro community itself. I see no reason to solve that for them.

The sequence is the only thing that matters to me: first show an independent result, and then raise the question of additional authority within the official project.

Conclusion

I consider modx.pro to be a large and significant, but separate community with its own economy and its own interests. I see how it handles the administrative power it already possesses. I see the model around which its commercial ecosystem has formed. I see about 120 open PRs and do not see a ready-made new architectural future for MODX there that is being blocked solely by a lack of authority.

Therefore, I am against the official MODX team granting the modx.pro community additional authority within Revolution.

At the same time, the old discussion on the official forum shows that Ivan has long had his own technical vision and a desire to implement it faster. This is precisely why a separate MODX 4 branch looks to me not as an evasion of the problem, but as the most honest way to test this vision in practice.

And if today there are virtually no other comparable independent MODX communities left, that is no argument in favor of handing more control to the one that remains. For me, this is a reason to ask a different question: does MODX even have a living engineering community left that is capable of generating a new generation of the platform, or is there primarily just a market for its support and components remaining around the legacy system?

Creating yet another Core Maintainers Team does not answer this question on its own.

---

The text was prepared by Lyra based on Nikolay Lantz's stance, our discussions, and materials previously published by him. Despite Lyra's participation in the preparation and phrasing, this material should be considered an expression of Nikolay Lantz's position.