Открытое письмо руководству MODX и команде MODX Revolution (Русская версия)

Всем привет!

Сегодня на официальном форуме сообщества я опубликовал Открытое письмо руководству MODX и команде MODX Revolution.

Ниже его переведенный вариант.

От сообщества разработчиков и пользователей MODX

Мы обращаемся к руководству MODX и команде, отвечающей за развитие MODX Revolution.

Это письмо не про конфликт и не про противостояние «сообщество против MODX».

Наоборот.

Мы хотим, чтобы MODX продолжал жить, развиваться и оставался современной платформой, на которой можно строить реальные проекты.

Но сегодня между желанием сообщества развивать MODX и существующим процессом разработки образовался серьёзный разрыв.

Что происходит сейчас

MODX Revolution остаётся работоспособной и востребованной системой.

При этом развитие ядра происходит значительно медленнее, чем этого требует современный веб и ожидания разработчиков.

В официальном репозитории находится большой backlog Pull Requests и Issues.

При этом важно отметить: разработка полностью не остановлена. Появляются новые PR, исправления и релизы.

Проблема в другом.

Проблема в том, как работа сообщества превращается в решения и официальные релизы.

• Разработчики есть.
• PR есть.
• Идеи есть.
• Готовность тестировать, исправлять и поддерживать код есть.

Но отсутствует достаточно предсказуемый процесс, который превращает эту работу в регулярное развитие MODX.

Нам нужен публичный roadmap

Вопрос roadmap поднимается сообществом не первый год.

В феврале 2026 года на форуме MODX была открыта отдельная дискуссия о будущем MODX, roadmap и release cycle.

В ней обсуждались:

• отсутствие публичного roadmap;
• необходимость понятного процесса работы с PR;
• регулярные релизы;
• возможность более активного участия сообщества;
• необходимость распределения ответственности за review и releases.

Прошло полгода.

И многие из этих вопросов по-прежнему остаются актуальными.

Нам необходимо понимать:

• куда движется MODX Revolution;
• какие задачи являются приоритетными;
• что планируется сделать в ближайшие 6–12 месяцев;
• какие изменения считаются стратегическими;
• что будет происходить с ExtJS и Manager API;
• как будет развиваться API и backend-инфраструктура;
• как будет развиваться frontend;
• какие MAB-рекомендации остаются актуальными;
• какие из них уже реализованы;
• какие были отменены или заменены;
• какой будет модель дальнейшего развития MODX 3.x.

Roadmap не обязан быть идеальным.

Он может меняться.

Но его отсутствие создаёт гораздо большую проблему:

сообщество не понимает, куда направлять свои силы.

PR не должны месяцами находиться в неопределённости

Открытый Pull Request — это уже работа разработчика.

Кто-то потратил время на анализ проблемы, написал код, подготовил тесты, оформил PR и готов отвечать на замечания.

• Если PR не соответствует направлению проекта — его можно закрыть.
• Если решение неправильное — его можно отклонить.
• Если необходимы изменения — их можно запросить.
• Если решение хорошее — его можно принять.

Любое из этих решений лучше многомесячного отсутствия решения.

Сегодня проблема заключается не только в количестве открытых PR.

Проблема в отсутствии предсказуемого процесса их прохождения.

Сообществу необходимы понятные состояния:

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

И понятные сроки реакции на каждом этапе.

Не обязательно обещать, что каждый PR будет принят.

Необходимо обеспечить, чтобы каждый качественно оформленный PR был:

рассмотрен → получил feedback → получил решение.

Нужна распределённая команда maintainers

Один из самых серьёзных системных рисков — концентрация критически важных решений у слишком небольшого количества людей.

Если проект зависит от того, найдётся ли время у одного-двух человек посмотреть PR, провести release или принять архитектурное решение, развитие неизбежно будет замедляться.

MODX уже достаточно большой проект, чтобы иметь распределённую Core Maintainers Team.

Сообщество готово участвовать в такой работе.

Нужны:

• дополнительные maintainers;
• понятные критерии получения прав;
• разграничение ответственности;
• технические reviewers;
• release manager;
• люди, отвечающие за triage;
• прозрачный процесс назначения и передачи полномочий.

Это не означает отказ от контроля качества.

Наоборот.

Распределение ответственности позволит повысить качество и снизить зависимость проекта от отдельных людей.

MAB должен получить окончательный статус

MAB был создан как механизм формирования архитектурного направления MODX.

За прошедшие годы часть рекомендаций была реализована, часть потеряла актуальность, часть была заменена другими решениями.

Теперь необходимо просто зафиксировать актуальный статус каждого пункта:

• Implemented
• Superseded
• Withdrawn
• In progress
• Planned
• Rejected

Не нужно снова годами обсуждать MAB.

Нужно завершить его аудит и получить актуальную техническую картину.

Это позволит использовать уже проделанную работу вместо того, чтобы начинать стратегическое планирование с нуля.

Нужен нормальный release cycle

Сообществу не нужны редкие большие релизы, вокруг которых каждый раз возникает отдельная организационная проблема.

Лучше небольшие и предсказуемые релизы.

Например:

• регулярные patch-релизы;
• плановые minor-релизы;
• development/nightly builds;
• публичное тестирование;
• changelog для каждого релиза;
• понятный процесс подготовки следующей версии.

Nightly и development-сборки особенно важны для сообщества.

Они позволяют тестировать изменения до финального релиза и получать обратную связь тогда, когда её ещё можно использовать.

Тестирование должно приводить к результату

Недостаточно просто попросить сообщество протестировать изменения.

Если разработчики тратят время на тестирование, а после этого PR месяцами остаётся без решения, такая модель не работает.

Результатом тестирования должен становиться следующий шаг: merge / changes requested / rejected / additional testing required

Это простая вещь, но именно она формирует доверие к процессу.

Нужен triage существующего backlog

Необязательно пытаться сразу обработать сотни PR и Issues.

Нужно начать с классификации.

Ready to merge — Изменения проверены и не требуют существенной доработки.

Needs review — Нужен технический review.

Needs testing — Код требует проверки на реальных проектах.

Changes requested — Автору необходимо внести изменения.

Outdated — PR потерял актуальность из-за изменений в 3.x.

Close — Проблема уже решена, неактуальна или решение принято другим способом.

Такой процесс позволит уменьшить backlog и вернуть разработчикам понимание того, что происходит с их вкладом.

Сообщество готово помогать

Важно подчеркнуть: сообщество не требует, чтобы небольшая команда MODX сделала всю работу самостоятельно.

Наоборот.

Есть разработчики, которые готовы:

• писать код;
• исправлять баги;
• тестировать PR;
• заниматься triage;
• писать документацию;
• поддерживать инфраструктуру;
• готовить релизы;
• финансировать разработку;
• брать ответственность за отдельные направления.

Но для этого необходимы полномочия и понятные правила.

Нельзя одновременно говорить сообществу «помогайте» и оставлять его без возможности довести работу до результата.

Open Source требует не только денег, но и управления

Если в проект вкладываются деньги, они должны помогать решать реальные проблемы проекта.

В первую очередь это могут быть:

• triage;
• PR review;
• release management;
• тестирование;
• документация;
• разработка ключевых компонентов;
• работа с backlog;
• инфраструктура CI/CD.

При этом сообщество готово участвовать и финансово.

Если для полноценной работы Core Maintainers Team требуется финансирование — давайте открыто обсудим необходимую сумму, задачи и модель финансирования.

Гораздо лучше иметь прозрачную модель: финансирование → конкретная работа → конкретный результат → публичный отчёт

Мы не хотим форка

Это принципиальный момент.

Никто не выигрывает от появления ещё одной независимой версии MODX только потому, что существующий процесс разработки оказался слишком медленным.

• Мы хотим развивать официальный MODX Revolution.
• Мы хотим отправлять PR в официальный репозиторий.
• Мы хотим видеть свои изменения в официальных релизах.
• Мы хотим участвовать в формировании roadmap.
• Мы хотим помогать тестировать новые версии.
• Мы хотим вкладывать время и деньги в развитие проекта.

Но для этого должна существовать возможность реально влиять на результат своей работы.

Однако fork становится следствием отсутствия решений

Если сообщество годами сталкивается с одной и той же ситуацией:

• roadmap обсуждается, но не появляется;
• contribution process обсуждается, но не становится рабочим инструментом;
• PR открываются, но долго остаются без решения;
• сообщество готово тестировать, но не видит результата;
• backlog продолжает расти;

возникает естественный вопрос: Что разработчикам делать сейчас?

Если официальный репозиторий не позволяет достаточно быстро развивать проект, разработчики рано или поздно начинают создавать собственную инфраструктуру.

Не потому, что хотят уничтожить MODX.

А потому, что хотят продолжать работать.

Поэтому появление fork в такой ситуации будет не причиной проблемы.

Это будет следствием отсутствия работающего механизма развития официального проекта.

И чем дольше откладываются необходимые изменения, тем выше вероятность того, что сообщество начнёт развивать альтернативную ветку.

Что мы предлагаем сделать в ближайшие 30 дней

Мы предлагаем не создавать ещё одну дискуссию на несколько лет, а перейти к конкретным действиям.

1. Опубликовать roadmap

Хотя бы на ближайшие 6–12 месяцев.

2. Провести публичный аудит MAB

Для каждого пункта определить текущий статус.

3. Опубликовать contribution process

От создания PR до merge или закрытия.

4. Создать Core Maintainers Team

И распределить технические полномочия.

5. Провести triage backlog

Начать с наиболее актуальных PR и Issues.

6. Определить release cycle

И придерживаться его.

7. Запустить регулярные development/nightly builds

Чтобы сообщество могло тестировать изменения до релиза.

8. Определить ответственных за review и releases

Чтобы работа не зависела от одного человека.

9. Опубликовать модель финансирования Open Source-разработки

И показать, какие задачи можно финансировать непосредственно.

10. Публично ответить на вопрос о будущем MODX Revolution

Не общими обещаниями, а конкретным планом.

В заключение

• Мы не хотим закрытия MODX.
• Мы не хотим очередного конфликта.
• Мы не хотим форка ради форка.
• Мы хотим развивающийся MODX.

Нам нужна современная, активно развивающаяся платформа с понятным будущим, регулярными релизами, работающим процессом contribution и возможностью сообщества реально участвовать в развитии ядра.

У MODX всё ещё есть сильное сообщество, большой накопленный технический потенциал, огромная экосистема дополнений и разработчики, которые готовы продолжать работу.

Но этого недостаточно без работающей модели управления проектом.

Поэтому сейчас нужен не очередной год ожидания.

Нужны решения.

• Мы готовы помогать.
• Мы готовы разрабатывать.
• Мы готовы тестировать.
• Мы готовы финансировать.
• Мы готовы брать на себя ответственность.

Вопрос только в том, готово ли руководство MODX создать условия, при которых эта работа действительно сможет попасть в официальный проект.

Мы надеемся, что ответ будет да.

И что на этот раз за ответом последуют конкретные действия.

Огромная просьба кто имеет желание и возможность поддержать его — оставить комментарий или оставить реакцию по ссылке Открытое письмо руководству MODX и команде MODX Revolution.

Заранее всем спасибо!