An Open Letter to MODX Leadership and the MODX Revolution Team

General
1

From the MODX developer and user from the Russian-speaking community

We are addressing the MODX leadership and the team responsible for the development of MODX Revolution.

This letter is not about conflict, nor is it about positioning the “community against MODX.”

Quite the opposite.

We want MODX to continue living, evolving, and remaining a modern platform on which real projects can be built.

However, there is now a significant gap between the community’s willingness to develop MODX and the way the project is currently governed and developed.

What is happening today

MODX Revolution remains a working and useful platform.

At the same time, core development is moving significantly slower than the modern web and developers’ expectations require.

The official repository has a large backlog of open Pull Requests and Issues. At the time of writing, GitHub shows around 120 open PRs and more than 570 open Issues.

At the same time, development has not stopped: fixes are being submitted, new PRs are being opened, and MODX Revolution 3.2.0, 3.2.1 and 3.2.2 were released in 2026.

Therefore, the problem is not simply a lack of developers or activity.

The problem is how community work is turned into decisions and official releases.

There are developers.

There are PRs.

There are ideas.

There are people willing to test, fix, maintain and improve the code.

What is missing is a sufficiently predictable process that turns this work into continuous development of MODX.

We need a public roadmap

The community has been asking for a roadmap for years.

In February 2026, a dedicated discussion about the future of MODX, its roadmap and release cycle was started on the MODX Community Forum.

The discussion once again raised:

  • the absence of a public roadmap;

  • the need for a clear PR process;

  • regular releases;

  • more active community participation;

  • distributed responsibility for reviews and releases.

Six months have passed, and many of these questions remain relevant.

We need to understand:

  • where MODX Revolution is going;

  • which areas are priorities;

  • what is planned for the next 6–12 months;

  • which changes are considered strategic;

  • what will happen with ExtJS and the Manager API;

  • how the API and backend infrastructure will evolve;

  • how the frontend will evolve;

  • which MAB recommendations are still relevant;

  • which have already been implemented;

  • which have been superseded or withdrawn;

  • what the long-term development model for MODX 3.x is.

A roadmap does not have to be perfect.

It can change.

But without one, the community has no reliable answer to a basic question:

Where should we invest our time and effort?

PRs should not remain unresolved for months

An open Pull Request already represents someone’s work.

A developer has spent time analyzing a problem, writing code, preparing tests, opening the PR and being ready to respond to feedback.

If a PR does not fit the project’s direction — close it.

If the solution is incorrect — reject it.

If changes are required — request them.

If the solution is good — merge it.

Any of these outcomes is better than leaving a PR without a decision for months.

The problem is therefore not only the number of open PRs.

It is the lack of a predictable lifecycle for them.

The community needs clear states such as:

New → Needs review → Changes requested → Ready for merge → Merged / Closed

And clear response expectations for each stage.

Nobody expects every PR to be accepted.

But every properly prepared PR should be reviewed and receive a clear outcome.

We need a distributed maintainer team

One of the most significant systemic risks is the concentration of critical decisions in too few people.

If the project’s progress depends on whether one or two people have time to review a PR, prepare a release or make an architectural decision, development will inevitably slow down.

MODX is large enough to have a distributed Core Maintainers Team.

The community is ready to participate.

We need:

  • additional maintainers;

  • clear criteria for receiving maintainer rights;

  • defined areas of responsibility;

  • technical reviewers;

  • a release manager;

  • people responsible for triage;

  • a transparent process for assigning and transferring responsibilities.

This does not mean giving up quality control.

Quite the opposite.

Distributed responsibility can improve quality while reducing the project’s dependence on individual availability.

MAB needs a final status

MAB was created as a mechanism for defining the architectural direction of MODX.

Over the years, some recommendations have been implemented, some have become obsolete, and some have been replaced by other approaches.

It is now time to establish the current status of every recommendation:

  • Implemented

  • Superseded

  • Withdrawn

  • In progress

  • Planned

  • Rejected

We do not need to spend another few years discussing MAB.

We need to complete the audit and establish the current technical status.

This would allow the project to build on work that has already been done instead of starting strategic planning from scratch.

We need a predictable release cycle

The community does not need rare, large releases surrounded by a separate organizational effort every time.

Smaller and predictable releases would be much more useful.

For example:

  • regular patch releases;

  • planned minor releases;

  • development/nightly builds;

  • public testing;

  • a changelog for every release;

  • a clear process for preparing the next version.

Nightly and development builds are particularly important.

They allow the community to test changes before a final release and provide feedback while it can still influence the outcome.

Testing must lead to a result

It is not enough to ask the community to test changes.

If developers spend time testing a PR and that PR then remains without a decision for months, the process does not work.

Testing should lead to a concrete next step:

merge / changes requested / rejected / additional testing required

This is simple, but it is essential for building trust in the contribution process.

We need to triage the existing backlog

There is no need to process hundreds of PRs and Issues simultaneously.

Start with classification.

Ready to merge

The change has been reviewed and does not require significant additional work.

Needs review

A technical review is required.

Needs testing

The change needs testing on real projects.

Changes requested

The author needs to make changes.

Outdated

The PR is no longer relevant because of changes in 3.x.

Close

The issue has already been solved, is no longer relevant, or has been addressed through another solution.

This process would reduce the backlog and give contributors a clear understanding of what is happening with their work.

The community is ready to help

It is important to make this clear: the community is not asking the small MODX team to do everything themselves.

Quite the opposite.

There are developers willing to:

  • write code;

  • fix bugs;

  • test PRs;

  • perform triage;

  • write documentation;

  • maintain infrastructure;

  • prepare releases;

  • fund development;

  • take responsibility for specific areas.

But this requires appropriate permissions and clear rules.

The project cannot simultaneously ask the community to help while preventing contributors from taking their work to a meaningful conclusion.

Open Source requires more than funding — it requires governance

If money is invested into the project, it should help solve real project problems.

In particular:

  • triage;

  • PR review;

  • release management;

  • testing;

  • documentation;

  • development of key components;

  • backlog management;

  • CI/CD infrastructure.

The community is also willing to contribute financially.

If funding is required for a properly functioning Core Maintainers Team, let’s openly discuss the required amount, responsibilities and funding model.

A transparent model is much better:

funding → specific work → specific result → public report

We do not want a fork

This is an important point.

Nobody benefits from another independent version of MODX simply because the existing development process is too slow.

We want to develop the official MODX Revolution project.

We want to submit PRs to the official repository.

We want our changes to be included in official releases.

We want to participate in defining the roadmap.

We want to help test new versions.

We want to invest our time and money into the project.

But this requires a real opportunity to influence the outcome of that work.

However, a fork becomes the consequence of inaction

If the community keeps receiving the same answers:

  • there will be a roadmap;

  • there will be a process;

  • reviews will happen;

  • everything will be discussed;

  • we will return to this soon;

while the situation itself does not materially change, a natural question arises:

What are developers supposed to do now?

If the official repository does not allow the project to evolve quickly enough, developers will eventually create their own infrastructure.

Not because they want to destroy MODX.

But because they want to continue working.

Therefore, a fork in such a situation would not be the cause of the problem.

It would be a consequence of it.

And the longer necessary changes are postponed, the more likely it becomes that the community will develop an alternative branch.

What we propose

We do not need another discussion that lasts for several years.

We need concrete action by 30 September:

1. Publish a roadmap

At least for the next 6–12 months.

2. Conduct a public MAB audit

Define the current status of every recommendation.

3. Publish the contribution process

From PR creation to merge or closure.

4. Establish a Core Maintainers Team

And distribute technical responsibilities.

5. Triage the existing backlog

Start with the most relevant PRs and Issues.

6. Define a release cycle

And follow it.

7. Launch regular development/nightly builds

Allow the community to test changes before release.

8. Assign responsibility for reviews and releases

Development should not depend on the availability of a single person.

9. Publish a funding model for Open Source development

Make it clear which tasks can be directly funded.

10. Publicly answer the question about the future of MODX Revolution

Not with general promises, but with a concrete plan.

In conclusion

We do not want MODX to disappear.

We do not want another conflict.

We do not want a fork for the sake of having a fork.

We want MODX to move forward.

We need a modern, actively developed platform with a clear future, regular releases, a working contribution process and a real opportunity for the community to participate in core development.

MODX still has a strong community, significant accumulated technical potential, a large ecosystem of Extras and developers who are ready to continue contributing.

But this is not enough without a functioning governance and development model.

We do not need another year of waiting.

We need decisions.

We are ready to help.

We are ready to develop.

We are ready to test.

We are ready to fund development.

We are ready to take responsibility.

The question is whether MODX leadership is ready to create the conditions in which this work can actually become part of the official project.

We hope the answer is yes.

And we hope that this time the answer will be followed by concrete action.

2

Don’t have much to add, this clearly and accurately reflects own concerns. I fully support this message and hope it leads to concrete actions.

3

It looks like history will repeat itself, as usual. Sadly.

4

I find this proposal rather ironic.

The modx.pro community keeps speaking on behalf of some abstract “MODX community”, while in my view modx.pro itself has long since become a separate community with its own administration, economy, commercial interests, products, services, and people around them.

At the same time, instead of strengthening diversity inside that community, modx.pro has repeatedly shown a tendency to suppress disagreement: removing inconvenient publications and comments, blocking unwanted participants, and even reshaping internal reputation mechanisms in ways that affect who is visible and influential.

And now the same community is once again asking for more authority inside the official MODX project, while describing the bright future that supposedly becomes possible once these powers are granted.

I do not support that.

My concern is simple: I see no reason to believe that additional influence over the official Revolution roadmap, reviews, merges and releases would primarily be used to create a fundamentally better MODX. I think it is much more likely to strengthen the existing commercial ecosystem around modx.pro, its components and related services.

But I also see a very simple and constructive alternative.

Ivan has already described his own vision of the future MODX in the previous discussion: API-first core, REST/GraphQL, a modernized architecture, Vue 3 Manager, Composer, DI, CLI tooling, migrations, tests and so on. He has also written dozens of PRs and stated that, given enough freedom, even a very small team could accomplish a lot.

So take that freedom.

Create a separate next-generation branch — call it MODX 4.

Build the MODX you believe should exist. Do not wait for merge permissions. Do not depend on the current core maintainers. Do not preserve backward compatibility where you believe it prevents progress. Publish the roadmap yourselves, make the architectural decisions yourselves, and deliver it through modx.pro.

If it works, if people adopt it, if real projects appear around it, then add a migration path from MODX 2/3 and you have proved your case with a working product rather than promises.

This approach also gives modx.pro something I think is important: the full moral right to develop its own community in whatever direction it considers appropriate, without pretending to represent everyone else around MODX. It would make the situation much more honest and explicit: modx.pro is a large and important MODX community, but it is its own community.

This is especially relevant because Nikolay Savin himself publicly stated that there is no longer any RSC — Russian-speaking MODX Community — although that comment was quickly removed from modx.pro. I preserved his response before it was deleted and described the episode here:

So perhaps it is time to take that statement seriously. If there is no longer a single Russian-speaking MODX community, then modx.pro does not need to act as if it represents one. It can openly become what it already appears to be: an independent MODX community with its own vision, products, interests and development direction.

And a separate MODX 4 would be an excellent way to prove that vision in practice without asking anyone for additional authority first.

My full reasoning is here:

5

@fi1osof Hello.

Thank you for the detailed response. I think there are several important points that should be separated, because the discussion currently mixes three different things: MODX as a project, modx.pro as a separate platform, and my personal contribution to the development of MODX.

The modx.pro community keeps speaking on behalf of some abstract “MODX community”

I have never claimed that modx.pro is the sole representative of the entire MODX community.

Moreover, this is precisely why in the original letter I deliberately did not write that “modx.pro should receive additional rights”. I was talking about the community, contributors, and a distributed Core Maintainers Team.

The proposal is very simple: if a person or a group of people regularly contributes to development, testing, triage, documentation, or releases, there should be a clear path for them to gradually receive the appropriate rights and responsibilities.

This does not mean giving control to modx.pro.

It means distributing responsibility among the people who are actually doing the work.

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

I don’t quite understand which part of the letter leads to this conclusion.

There is no proposal in the letter to give modx.pro additional authority as an organization or platform.

I wrote:

“We need a distributed Core Maintainers Team.”

and separately:

“clear criteria for receiving maintainer rights”

So this is not about being affiliated with modx.pro. It is about contribution, responsibility, and transparent criteria.

If tomorrow an active developer from another MODX community starts regularly working on the core, I see absolutely no reason why they should not have the same opportunities.

Regarding my personal contribution

This is where I find the suggestion that I should “create MODX 4 separately” particularly strange, because for many years I have actually been doing the opposite.

I did not leave to build a separate CMS.

I continue to work directly on the official modxcms/revolution project.

In particular, recently I have submitted a significant number of PRs addressing real problems in the current Revolution: ACL, sessions, parser, Package Management, Manager, setup, media sources, xPDO, CI, PHP 8.x issues, and many others.

This is not architecture experimentation for the sake of experimentation. To a large extent, this is work on existing Issues and problems that have remained unresolved for years.

That is why I explicitly wrote in the letter:

“If the solution is good — merge it.”

and:

“Nobody expects every PR to be accepted.”

I don’t need every one of my PRs to be automatically merged into core.

I need a decision to be made about them.

Merge, changes requested, or close — any of these outcomes is better than no decision at all.

And this is not limited to Revolution

I have permissions in modxorg/Docs, and I actively work there on the official project documentation.

The situation there actually demonstrates that a distributed responsibility model can work.

I can independently fix documentation, create PRs, and bring the work to completion. There are currently changes in the Docs covering MODX 3, xPDO, REST, processors, upgrade documentation, events, Russian documentation, and other areas.

So I am not simply saying that “the community should do something”.

I am doing it.

And I am trying to do the same in the core, within the permissions I currently have.

At the same time, I genuinely do not have enough permissions in Revolution

There is an important detail here.

Currently, in modxcms/revolution, I have permissions that allow me to work on triage and PRs, but I do not have push or maintain permissions.

The situation is different in Docs, where I have push access.

To me, this is a good example of exactly the problem I described.

Nobody needs to give anyone “power over MODX”.

We need to give the necessary authority to specific people who have already demonstrated their contribution, while keeping transparent criteria and accountability.

Regarding modx.pro

Yes, modx.pro is an independent platform.

It has its own administration, economy, commercial products, and user base. I do not hide this, and I have never suggested that modx.pro should be considered an official MODX body.

But historically, and today, it is one of the most active Russian-speaking platforms around MODX.

At this point, many of the other Russian-speaking platforms that existed in the past are simply unavailable or have effectively ceased to exist.

So it is completely natural that people who continue to communicate and work with MODX use this platform.

At the same time, the existence of commercial interests within an ecosystem does not automatically mean there is a conflict of interest.

If I fix a bug in modParser, modSessionHandler, ACL, Package Manager, or the documentation, it does not become less useful to MODX simply because I also develop Extras and work within a commercial ecosystem.

Moreover, a significant part of my current contribution is not related to commercial products at all: it is work directly on the core and official documentation.

We also support all the free add-ons that @bezumkin2 donated before his departure. A couple of examples:

And one more important point

You suggest that I:

“Create a separate next-generation branch — call it MODX 4.”

But that is exactly what I do not want to do right now.

I do not want another division of the ecosystem.

I want the official MODX Revolution project to evolve.

That is precisely why I spend my time on Issues, PRs, testing, documentation, and fixing technical debt in the existing repository.

If my goal were simply to build “my own MODX”, it would be much easier for me to leave and create a separate project where I could make any architectural decisions without worrying about backward compatibility.

But that does not solve the problem of the existing MODX project.

So my question remains the same

I am not asking:

“Give modx.pro control over MODX.”

I am asking a different question:

How can someone who wants to invest time, code, testing, documentation, and money into the official MODX Revolution project get a clear path from contributor to responsible maintainer?

What are the criteria?

Who makes the decision?

How does review work?

Who is responsible for releases?

How are areas of responsibility distributed?

How are architectural decisions made?

What happens to PRs that remain without a decision for months?

That is what my letter was about.

And if the answer to these questions is:

“Don’t wait for changes in the existing project. Create your own MODX 4.”

— that is also a very concrete answer.

But then it is no longer a solution to the governance problem of the official MODX Revolution project. It is a proposal for the community to ultimately split into different projects.

Personally, I believe that as long as we have an opportunity to make the official MODX project stronger, it makes much more sense to try that first.

That is exactly why I wrote the open letter.

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.

And that is logical, because my primary goal was not to create yet another alternative architecture, but to address the vast majority of known and currently relevant problems in the existing MODX Revolution.

Most of the issues I have been working on were not things I decided to invent as a new direction for MODX. They were already existing project issues and problems that needed to be addressed.

Moreover, most of these issues had an assigned Milestone, and I did not choose them for work at random.

So this is specifically about working on already identified problems and project priorities, rather than trying to push my own vision of MODX 4 into the core.

Therefore, yes — from the outside, it may indeed look primarily like maintenance and gradual modernization of Revolution.

That is exactly what I have been doing.

I believe that before discussing a completely new architecture, it makes sense to first bring the existing project into better shape: fix accumulated problems, reduce technical debt, improve compatibility, documentation, testing, and infrastructure.

Moreover, @opengeek himself mentioned in one of his recent articles that a project roadmap would be prepared and published. So for me, working on the current issues and tasks is naturally connected to the future roadmap — I am not trying to replace the process of defining the direction of MODX.

I am trying to work within the existing project and its already identified priorities, while expecting a clearer and more public understanding of where exactly the project is going next.

Once that is clear, it will be much easier and more constructive to discuss what architectural changes MODX actually needs and in which direction the project should evolve.

7

@fi1osof Your conclusion, not your premise, is where I think this thread goes wrong.

First — sorry for my English, it is not my native language, and I will try to keep this as clear as I can, because the facts here matter more than the grammar.

You are right about two things. modx.pro is its own community with its own commercial interests, and no website, company or language group should speak for all of MODX. And a working prototype proves more than a manifesto.

But “build your own MODX 4 and prove yourself” is not a neutral suggestion. It is the exact path this community has already walked once, and we know where it ends. Let me put the dates on the table:

April 19, 2012 — MODX publishes “Bringing Evolution Development Back to Life”: only a few people have push access to the official repository, and “with the current workload of the MODX Team, it also serves as a barrier. That must change!” The proposed fix is not a fork. It is an Integration Manager selected by the community, with push access to the official repository — “handing over the keys to the Community ASAP.”

January 23, 2013 — a ready fix for an XSS in FormIt is submitted as a PR. By March 17 there is no reaction at all; in mid-March the bug is confirmed as still present in the released version.

November 14, 2016 — Revolution 2.5.2, a security release, publicly thanks bezumkin, Fi1osof, Mark-H, AgelXNash and chengruiqi. In the same discussion a member of the MODX security team writes: “We took too long to respond to your initial email, and I’m sorry for that.”

September 2, 2026 — Ivan’s letter. The same diagnosis, fourteen years later: contributions exist, people exist, the process that turns them into decisions does not.

So this is not “the Russian community against MODX.” We proved the opposite in 2012–2016: when there was a process, we worked inside it, and the result was official acknowledgements in the security releases.

What followed between those dates is also a fact: parallel community builds, and then in 2016 MODX itself turned Evolution over to its community team — its own words, again, “handing over the keys” — with Evo 2.0 shipping in 2018 and the repository later settling in the evocms-community organization. Two ecosystems, two add-on markets, two documentation sets, and a migration problem that outlived every argument that produced it. I went through that cycle from the inside.

The lesson is not “forks are evil” — forking is a fundamental Open Source freedom. The lesson is: when the only way to turn your work into a decision is to build a separate product, contributors do not unite, they fragment. And the installed base pays for it.

That is why I am not answering your challenge with another competing branch. I am answering it with an offer to build jointly, under a new, community-owned brand, combining three things we already have:

the Evolution CMS experience: years of maintaining a huge installed base and modernizing under backward-compatibility constraints, including its Laravel-based core work;

Laravel ecosystem practices: packages, contracts, service container — modern PHP without reinventing our own wheel;

the next-generation architecture ideas you and others keep raising: API-first, no ExtJS, a clean core.

With one rule agreed in advance — two tracks:

Track A — backward-compatible evolution: security, modern PHP support and DX for the existing installed base;

Track B — a progressive track without BC constraints: where clean-architecture ideas are validated by prototypes, not declarations.

Governance from day one: maintainers earn rights by contribution history, responsibilities are scoped, RFCs are public, and the brand is controlled by no single company or national group — including modx.pro, and including us. If a real official process appears, merging efforts is on the table; Ivan’s September 30 deadline is for MODX, not for us. But after fourteen years of the same loop, the people who have been carrying this project largely on old memory owe themselves a working alternative.

We are not waiting for permission anymore. And if you want influence over the architecture, you will have far more of it inside this effort than outside it. The name, like everything else, we will choose together. Who is in?

P.S. Sorry again for my English.

8

@ibochkarev

Ivan, I am not arguing with your personal contribution as a contributor. I am arguing about motives and long-term direction.

My position here is quite clear: as a member of the modx.pro team, you are primarily acting in the interests of the modx.pro ecosystem — pdoTools, miniShop, and everything built around them. I have explained more than once where I believe the problems with that ecosystem are.

Right now you can point out that pdoTools and miniShop are popular. I do not see that popularity as proof of technical superiority. In my view, it is largely the result of marketing, distribution, and ecosystem dominance. And if the core starts being reshaped around that model, MODX gradually stops being an independent platform where different approaches can coexist and turns into a system that increasingly assumes the pdoTools + miniShop ecosystem as the default way to work.

Even in your own groups, the idea that “pdoTools should be a must-have out of the box” has come up more than once.

My position is different. If MODX is going to be redesigned, then I believe it should be redesigned fundamentally, probably even without backward compatibility, because the foundation of MODX itself contains many historical architectural problems.

And I do know what I am talking about here. I was one of the early people actively advocating for MODX Revolution, which at the time itself caused conflict with supporters of MODx Evolution.

I recently described some of the current architectural problems in more detail here:

But I do not believe anyone is actually going to undertake that kind of rewrite. It is simply too much work.

That is why I currently see only two realistic outcomes.

Either you receive more authority and gradually turn MODX itself into MODX.pro — not merely a project influenced by modx.pro, but a root project increasingly shaped around the architecture, assumptions, and ecosystem of pdoTools, miniShop, and related solutions — which I consider the more likely scenario; or nothing fundamental changes at all, and in 2030 MODX will still be essentially the same MODX it is today, while you continue developing your own increasingly separate fork or ecosystem around it.

I simply wanted to make my view on this clear.

9

@agel_nash

Evgeny, I don’t think I can argue with anyone here any further. More precisely, I don’t think I have the moral right to do so. Only you yourselves can decide where to go and how to move forward.

I have only expressed my own point of view, based on my personal experience. And just as I publicly said many years ago that I had doubts about the future of MODX, my opinion has not changed once over all these years. If anything, I keep seeing more and more evidence that confirms it.

But there is one thing I still do not understand: why have you all kept dragging this project forward instead of building your own?

And especially considering that I believe you probably could have done it.

Is it really just about money? In other words, are you doing this simply because “we make money from MODX”?

But that is boring.

It would have been far more interesting to build your own product and move on. You already have modx.pro, which means you already have a distribution channel. You could have built a new project, launched a new community on a separate domain, promoted it through modx.pro, and by now you could already have had your own established user base.

So why go through all of this now?

I left MODX many years ago and I do not regret it at all. I even built my own engine with AI integrated into it:

Yes, very few people care about it. Yes, I did not build a community around it. But it was interesting to work on. I ran many of my own experiments there and implemented a lot of things exactly the way I personally wanted them to work.

And now I do not complain that someone refused to give me merge rights.

At the same time, I spent several years working in big tech, including as a tech lead, including at SberLab, as well as in European and American companies. My technical level today is already very high.

So why am I writing here now?

Simply because about six months ago I left my job again. By my own decision.

I became bored and lost interest. The company was large, but at that point I no longer felt that there was anything meaningful left for me to pursue there or much left for me to learn. So I left in order to focus more seriously on my own projects.

Recently, however, I had to do some work on an old MODX website for a long-term client of mine, and that led me to an interesting realization.

With AI, the programming language almost no longer matters.

One of the reasons I originally left MODX was that I was tired of PHP and simply did not want to write PHP anymore. But over the last few months I have been doing a lot of programming with AI, and in that workflow you are effectively programming in natural language.

So I opened that old project in my IDE and told my AI agent, in exactly the same natural-language form, what needed to be done.

And because my MODX websites have traditionally been built with modxSite + modxSmarty — meaning that everything important is stored in files and tracked in Git — the AI agent had no trouble finding the relevant files and completing the work.

And that led me to an interesting thought:

with AI, it no longer matters very much whether you are working inside MODX or inside some completely different project.

What matters is whether AI can work with the project effectively.

And then I saw a market opportunity.

There are a huge number of old MODX websites that could be migrated to newer technologies.

But there is a problem: classic, clean MODX is not really designed for this kind of workflow, because so much of its logic and templating is stored in the database.

That is a historical architectural decision, and it cannot really be changed without radical measures.

So even if I wanted to return to MODX seriously, I probably could not do it, because at a mental level I simply would not want to maintain and develop a project built around that model.

And that is what I do not understand about you.

As a marketer, I understand it.

As a programmer, I do not.

10

@ibochkarev The fact that after half a year (of this discussion) you still have to resort to an Open Letter (to get some response from the MODX core team), speaks for itself. Seemingly you don’t speak directly to each other. But without direct communcation a cooperative endeavor (like building a future version of MODX) won’t ever work.

Please try to speak directly to Jason. And if that is not successful or you don’t find an arrangement that works for both of you, then do you own thing.

I appreciate that you don’t want to split the MODX community (by creating a new fork), but the (public) response from the MODX core team in the last months has been underwhelming
and this discussion here is getting quite pointless.

11

Hello!

I’ve been communicating in the core-contributors chat, privately with Ryan, Mark, the guys from Sterc, and with former core team members on Slack.

But when I wasn’t heard and didn’t receive the desired response from management, and after consolidating opinions from the Russian-speaking community and my colleagues, I decided to make my last attempt to somehow revive the development process with this open letter.

I’ll try to contact Jason via private message, but I’m hoping to get some response here as well.

Thank you for your reply.

12

Thank you for the letter. It’s clear how much care went into it, and how much its authors want MODX to succeed.

So do we.

MODX Revolution has earned a reputation for stability and security over many years, and keeping that reputation shapes every decision below. Here is where things stand and where we are going, as plainly as we can put it.

The queue

Since late February, one contributor has opened 98 pull requests: 56 in the first eight days, 13 more in March, and 26 in August. That is a great deal of effort, offered in good faith. Today it accounts for 71 of the 117 open PRs in the repository.

In April we asked that anyone planning a large batch talk through scope with the code owners first. That offer stands, and it matters a lot more than it may sound. Much of the communication around this work has been indirect, and speed has come ahead of coordination.

Direct conversation about scope and what belongs in Revolution, before the next batch rather than after, would do more for this queue than anything else being proposed.

Five people have reviewed these PRs so far. Twenty-nine have had formal review, 24 were approved, and 12 have merged, five last week. Eleven approved PRs are waiting on integration, delayed by a burst of security advisories and now back in focus. A security report will always take priority over everything else. That is what maintaining a CMS known for stability and security requires, and the work is invisible from outside until the patches ship.

Fifty-six have had no review yet because there are not enough active reviewers to handle the load. On the ones that have been reviewed, the review has ended up carrying the change—reviewers identify what is wrong, the contributor incorporates it, and reviewers check again. That is a fine rhythm for one PR. Across dozens, the few people reviewing are doing their part and the contributor’s too.

The letter asks for a decision on every PR. A PR that is reviewed and approved by trusted maintainers gets integrated. A PR with changes requested stays with its author. A PR nobody has reviewed stays open and labeled as needing review, because closing it unread would be a decision made without looking. Which state a PR is in is visible on GitHub today; what moves it forward is review.

The bottleneck that anyone can help remove

The constraint is not process but confidence, and confidence comes from people who know this codebase reading a change and confirming it does what it claims. Automated checks and tooling can catch syntax and style. But they cannot tell you whether a change to a core subsystem will hold up across the sites Revolution is running today.

Only a person with deep working knowledge of that code can, and that judgment is what a merge depends on.

Anyone with a GitHub account can contribute in this way. No role or explicit permission required. A single independent “tested on 3.2.2, fixes the issue” or “this breaks X” from someone who understands the affected code does more to move a PR than any workflow document we could write. The letter says the community is ready to test and review. The queue is public. If each open PR had two or three knowledgeable people who had exercised it, integration would be much more efficient.

The people who do that consistently are how our maintainer pool grows. A maintainer is someone whose approval the code owners can merge without re-reviewing. That trust comes from two activities. One is a record of reviews that turned out to be right. The other is working with the existing maintainers rather than around them: raising scope before the work, discussing approach while it is in progress, and treating review as a conversation rather than a gate to get past.

Maintainers coordinate; that is most of what the role is. Someone who does that consistently becomes a maintainer in practice well before anyone changes a permission, and the code owners judge that record.

And this is not theoretical. One contributor is earning exactly that standing right now, through sustained work in one area of the codebase, by reviewing other people’s changes with care, and by talking things through with the rest of us as a matter of course. That path is open to everyone.

Contributions still need a person behind them who has checked that the problem exists, tested the change, and can respond to feedback with their own judgment. Within that, the fastest fix for this queue is more reviewers who know the code, not fewer PRs. If more reviews arrive, the integration backlog will grow before it shrinks, and that is fine.

The direction

You are right that we owe the community a clear answer, and that it should have come years ago. Here it is.

MODX Revolution is maintained for stability and security. That means several minor releases this year, possibly a major one, and that pace continues. It is not being modernized by significant refactoring. What is in the queue is maintenance and features against a fifteen-year-old architecture; merging the PRs in it faster expedites a better-maintained legacy system, not a modern one.

That sets the bar for what belongs in Revolution. A change that improves stability, security, or compatibility with low risk to existing sites is welcome and will be reviewed on those terms. Expansive new features and broader modernization are a lower priority, and contributors should expect them to wait or to be declined. We would rather say that now than let them sit.

The future is a re-imagined solution built on a revised version of the goals the MAB set out. Its foundation will be designed by a small group and opened to contribution once it can absorb it, not before. We are not giving a timeline. Missed timelines have cost more trust than silence, and we would rather show this than schedule it.

Additional authority over the current codebase is not on the table. That has nothing to do with who is asking; Revolution is simply not where the future gets decided anymore.

There is already talk in this thread of a community-built successor under a new name. Forking is a fundamental freedom of open source, and that is a legitimate path. We would only say this: our read is that the installed base is the thing everyone in this thread truly cares about, and every parallel ecosystem has undermined that base.

If it were to come to that, and we would bear no ill will were it to do so, it would neither be an official direction nor would it bear “MODX” branding.

In short

Want it faster? Review something today, and bring what you know about the code with you. Direction on what comes next stays with the founders until there is a foundation to show.

— Jason & Ryan

13

So, the Revolution is over. Long live the Revolution? :wink:

14

Thank you for the detailed and straightforward response.

I think this gives us a good opportunity to move from discussing the problem to actually doing something about it.

I agree that one of the main constraints right now is the lack of people who can review changes, test them against real installations, and provide meaningful feedback. This is an area where the community can help.

From my side, I suggest we start with three things:

1. Triage the existing PRs

Let’s go through the older PRs and check whether the problems they address are still relevant, whether they can still be reproduced, and whether the proposed changes still make sense for the current direction of Revolution.

For PRs that are no longer relevant or have become obsolete, we can suggest closing them. For PRs that are still relevant, we can leave comments with the current status and testing results and, where useful, use labels or milestones to help prioritize them.

2. Organize community testing

I’ll translate and update the PR testing instructions in Russian and start coordinating this with the Russian-speaking part of the community.

At the same time, I think a very simple prioritization mechanism could help — for example, GitHub Projects, labels, or milestones — so that people who are willing to spend time testing can quickly see which PRs are the most valuable to test first.

I don’t think we need to build a complicated process around this. The main goal is simply to make it easy for someone who wants to help to understand where their testing effort is most useful.

3. Work through the accumulated backlog and move forward together

I don’t think we need to solve the entire backlog at once. It would be better to gradually work through it, get some practical results, and learn from that process.

I’ll also take the point about coordination seriously. Before starting another large batch of changes, I’ll make sure the scope and approach are discussed with the relevant code owners first.

Next week, we’ll try to start with a small first wave of PR testing. I’ll help the people involved prioritize what to test first — they have actually been asking for this in our community chat.

Let’s see how much difference this can make in practice. If we can get more knowledgeable people testing and reviewing the existing PRs, we should get a much clearer picture of what is still relevant, what can move forward, and where the real remaining bottlenecks are.

I think that’s a good place to start.

15

So, the Revolution is over. Long live the Revolution? :wink:

Hah! Revo 3.x will be improved, secured and supported for years—way too many users and businesses rely on it.

But ripping and replacing the underlying engine and airframe while the plane is flying isn’t that. Investment in something new under the hood, based on modern practices/libraries, is another subject for a new codebase with breaking changes. If bridges to similar functinality can be bolted onto the current codebase with clear proof it doesn’t break things, decrease security, or slow things down would be fine, too (most likely as Extras). And that definitely doesn’t mean we wouldn’t do our best to make Revo → whatever’s next as possible as possible to migrate, but it won’t be a blocker to doing things substantially better for both site owners and those building them.

16

Before doing mass updates to things, please reach out to us directly and let’s coordinate an approach that doesn’t create even more overwhelm and potential extra info that doesn’t make it easy to make calls on what to do.

17

Thhis is something the community is asking for, has been for years, and still is the mean concern. Lack of leadership.

18

Thanks, @rthrash.

I’m happy to coordinate this and avoid creating additional noise or parallel efforts.

I actually tried to reach out directly: I sent personal messages to both you and @opengeek in Slack on Sunday and Tuesday, and also tried to reach out here in the Community. Unfortunately, I haven’t received any response so far.

So I’d like to clarify where would be the best place to continue this discussion and coordinate the next steps.

Is there a specific Slack channel, thread, meeting, or another place where we can discuss this with the relevant people and agree on a concrete way forward?

I’m ready to help with the work — including testing PRs, reviewing issues, documenting the current state, or helping coordinate community contributors. I just want to make sure the effort is aligned with the MODX team and actually helps move the situation described in the original post forward.

What would be the best way to proceed from here?

19

Hey @ibochkarev I’ll set up a Zoom for us next week when I’m back from visiting my daughter at college.

20

Hey @rthrash, I’d like to follow up on this.

You suggested continuing the discussion in a group chat so I wouldn’t have to worry about speaking English and dealing with translation at the same time. I agreed and created the group chat, but so far we haven’t managed to start the discussion there.

Since then, I’ve also followed up with you here in private messages a few times and reached out to you privately on Slack, but I haven’t heard back yet.

I’d really like us to bring the discussion we started to some kind of concrete point — even if that simply means figuring out whether we want to move forward, what makes sense to work on first, and who is willing to be involved.

If the team has other priorities right now, or you don’t plan to continue this discussion, that’s completely fine too. I’d just appreciate knowing that directly, rather than continuing to try to get the conversation going.

I’m still willing to put time and effort into this and help move things forward if there’s a shared intention to do so. If it’s not a priority right now, just let me know and I’ll step back and won’t keep coming back to this.