Automattic резко сократила вклад в разработку WordPress. Если раньше компания выделяла больше 3915 часов в неделю, то теперь ориентир – около 45 часов. По масштабу это уже близко к вкладу крупных хостеров вроде WP Engine (порядка 40 часов в неделю). Фокус – только критические баги и безопасность.
Новость выглядит как перераспределение ресурсов, но за ней стоит конфликт с WP Engine и давление на сообщество вокруг идей форка. Ниже – что произошло и что это значит для экосистемы.
Конфликт Automattic и WP Engine
В октябре 2024 года WP Engine подал иск против Automattic. Хостер счёл действия компании недобросовестной конкуренцией. В претензиях, в частности:
- Критика в админке WordPress – публикация материала, дискредитирующего WP Engine.
- Плагин ACF – попытка заменить Advanced Custom Fields (более 2 млн установок) собственным форком в каталоге WordPress.org.
- Блокировка доступа – ограничение аккаунтов сотрудников WP Engine на WordPress.org, что мешало обновлять плагины и работать с сообществом.
Суд встал на сторону WP Engine: Automattic обязали восстановить доступ к ресурсам WordPress.org, вернуть контроль над ACF и прекратить дискредитирующие действия. Юридическая нагрузка и репутационный фон – один из факторов, почему компания пересматривает объём open source-вклада.
Почему Automattic снижает участие
Мэтт Мулленвег, основатель WordPress и глава Automattic, формулирует позицию так: компания не может в одиночку тянуть основную массу разработки. Сокращение спонсорских часов должно выровнять баланс в экосистеме и дать пространство другим участникам. Параллельно Automattic усиливает упор на коммерческие продукты:
- WooCommerce – e-commerce на WordPress;
- Jetpack – набор инструментов для сайтов;
- WordPress.com – хостинг и коммерческая платформа.
По заявлениям компании, активное участие в направлениях вроде Gutenberg, Playground и Openverse также пересматривается: приоритет – юридические вопросы и продуктовые линии Automattic.
Блокировка сторонников форка
Параллельно Мэтт Мулленвег заблокировал на WordPress.org аккаунты нескольких участников, которые продвигали идею форка и альтернативной модели управления. В числе затронутых – Joost de Valk (создатель Yoast SEO), Karim Marucchi, а также Se Reed, Heather Burns и другие.
Позиция Мэтта в общих чертах такая: форки в open source полезны – они дают пространство для экспериментов с управлением и архитектурой. Если идеи сработают, сообщество сможет перенести удачные практики в основной проект. Блокировку он подал как стимул перейти от обсуждений к реальной работе над форком и через год сравнить результаты (в том числе на саммите разработчиков).
Форки: шанс или риск для экосистемы
Форк WordPress – тяжёлая инженерная и организационная задача: нужна инфраструктура, репутация, люди и годы поддержки. С другой стороны, именно форки иногда становятся лабораторией, из которой в mainline возвращаются удачные решения.
Критика со стороны Мэтта касается, в частности, идей децентрализованного каталога плагинов: риск рекламы в админке и неконтролируемого сбора данных, что плохо стыкуется с привычными ожиданиями пользователей WordPress. Спор здесь не только технический, но и про доверие к каталогу и модели управления.
Что это значит для разработчиков
Меньший вклад Automattic теоретически открывает окно для независимых команд и компаний, готовых спонсировать core, плагины и документацию. На практике успех зависит от того, появятся ли устойчивые спонсоры и координация – иначе развитие core может замедлиться.
Конфликт с WP Engine и блокировки на WordPress.org добавляют неопределённости: сложнее планировать долгие вложения в экосистему, если правила доступа и политика каталога меняются резко. Для агентств и хостеров разумно диверсифицировать зависимости: следить за core, иметь план на альтернативные репозитории и не строить критичные процессы только вокруг одного игрока.
Итог на сейчас: Automattic уходит в режим «критические фиксы и безопасность», усиливает коммерческие продукты и жёстко реагирует на инициативы форка. Сообществу предстоит проверить, сможет ли оно закрыть образовавшийся разрыв в часах разработки без потери качества релизов.
