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 уходит в режим «критические фиксы и безопасность», усиливает коммерческие продукты и жёстко реагирует на инициативы форка. Сообществу предстоит проверить, сможет ли оно закрыть образовавшийся разрыв в часах разработки без потери качества релизов.
