По просьбам общественности на скорую руку накатал перевод заметки Даниэла Кудвиена The Drupal Crisis.

Кстати (минианонс!), статью я переводил на специально сделанном для этих целей сайте, который теперь уже открыт, и по возвращении из Ленинграда будет представлен общественности.

Далее — перевод.

Кризис в Друпале

В последнее время случилось немало событий, которые, очевидно, можно рассматривать только как критические точки:

Февраль 2008: Drupal 7 открыт для разработки.

Октябрь 2008: 285 неисправленных багов в Drupal 7.

Март 2009: запущена инициатива по развитию пользовательских качеств Drupal 7 (D7UX).

Июнь 2009: 3120 неисправленных багов (а всего их 13763).

Сентябрь 2009: изначально запланированная заморозка кода. Однако для 10 новых фич по-прежнему разрешена разработка (с нуля) и внедрение в Drupal 7.

Январь 2010: выпущена первая альфа-версия Drupal 7, куча критичных багов в новых API, а еще больше — в этих новых фичах.

Июль 2010: багов слишком много, ощущение цели утеряно; чтобы хоть как-то разобраться в потоке ошибок, в Drupal введен новый приоритет багов — «major» (важный — пр. пер.)

Октябрь 2010: выпущена первая бета-версия Drupal 7.

Январь 2011: Drupal 7.0 выпущен с более чем 300 неисправленных важных багов и нерабочим порядком обновления.

Май 2011: чтобы исправить баги в Drupal 7, для Drupal 8 приходится добавить еще одного мейнтейнера.

Июнь 2011: более 200 критичных и важных багов меняют статус на нормальные.

Июль 2011: разработка Drupal 8 блокирована порогом в 15 критичных и 200 важных багов/задач.

Август 2011: 4153 неисправленных бага (а всего 22181, то есть количество выросло почти в два раза за два года). Порядок обновления все еще неясен многим пользователям Drupal 6. Прогресс в разработке Drupal 8 стремится к нулю.

Более 150 неисправленных багов и нерешенных задач — только в новых проектах Dashboard, Shortcut, Toolbar и Overlay. Именно эти модули разрабатывали с нуля после заморозки кода (что неудивительно, ведь их проекты появились только шестью месяцами ранее). Затем их переписывали как минимум один раз после внедрения, и это очень сильно повлияло на отложенный релиз Drupal 7.

Я думаю, необходимо четко понимать, что обратная связь через инициативу D7UX демотивировала ключевую группу: разработчиков ядра, способных справиться с самыми тяжелыми задачами, нужными для предложенных изменений.
[…]
У нас сейчас примерно 450+ разработчиков ядра, из которых где-то 10 работают над его (ядра) интерфейсом.

… с этим замечанием когда-то выступил один из лидеров команды, ответственной за юзабилити. Иными словами: «Разработчики ядра не особо хотели взваливать на себя груз, но взвалить пришлось все равно».

Эти принятые в последнюю минуту новые фичи не только блокировали релиз Drupal 7. Также они отвлекали многих высококлассных разработчиков ядра и не давали им работать над более важными проблемами API и подсистем ядра Друпала. Многие из этих проблем до сих пор не решены.

Вновь разработанные в Drupal 7 подсистемы весьма сложны и сильно взаимосвязаны с еще более сложными подсистемами. Из-за этого новички неспособны помочь с исправлением багов и выключаются из процесса. Почти все баги требуют крепкого знания многих подсистем, а также глубокого понимания последствий их изменения. Либо за них должны браться прожженные разработчики ядра и модулей, либо они хотя бы должны писать внимательные отзывы и подписываться под изменениями.

Если же им все равно, двигаться в сторону разработки Drupal 8 не получится, несмотря на направленность этих разработчиков, в целом, на низкоуровневый функционал ядра. Но все равно, разработчикам ядра приходится заниматься совершенно неуместным функционалом, который, как кое-кто решил, было бы неплохо реализовать для своих основных проектов. Суйте в ядро — пусть сообщество поддерживает.

В то же время, некоторые из самых активных и опытных разработчиков ядра в последние три года устроились на работу в уже упомянутую коммерческую компанию. И в некоторых случаях их вклад в код ядра внезапно (и к сожалению) снизился практически до нуля. Без всяких сомнений, это есть экономическая истина: бесплатный вклад в разработку и интересы коммерческих предприятий — в целом, несовместимы. И, конечно, каждый должен самостоятельно решать, как использовать свои ресурсы и во что их вкладывать. Тем не менее, 19% всех разработчиков ядра (а также два человека с правами сохранять изменения) — получают деньги и подвержены влиянию одного главного «третьего» лица, в чем, очевидно, заключается конфликт интересов как сегодня, так и в долговременной перспективе.

В дополнение к этим упомянутым выше недоделанным, узконаправленным фичам, ядро Друпала все еще тащит за собой кучу очень старого, никому не нужного хлама. Имеются в виду мелкие и негибкие фичи, основанные на API и концепциях, допущенных в Друпале пять лет назад и больше.

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

Ядро Друпала больше не поддается поддержки. Программного хлама слишком много. И недоделанных, никем в общем-то не поддерживаемых фич — тоже слишком много.

Есть только один способ снова взять его под контроль:

1. Выделить профиль стандартной установки в отдельный проект.
И отправить модули, обеспечивающие «стандартный» функционал, в дополнительные.
Сделать страницу http://drupal.org/project/standard — главной страницей для скачивания Друпала.

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

Короче: нужно вернуть ядру поддерживаемость.

3. Хватит заниматься херней. Нужно биться с настоящими, ужасными проколами в дизайне ядра.

4. И в конце-концов уже исправить архитектуру ядра Друпала через инициативы.
Сделать его простым, менее запутанным, быстрым. Убрать тоскливый балласт. Собраться.

Мы должны стать цельным фреймворком и, в то же время, простой, но расширяемой CMS, как и было раньше.

Хватит нам красить губы огромной свинье. Нет больше никакого желания помогать в поддержке существующего бедствия из недоделанных модулей. Разработчиков ядра задрал аргумент, что мы якобы можем совладать с ожирением через «усиление маркетинга и обучение новых разработчиков». Это вовсе не так, совсем не так. Потому что это не снимает бремени с существующих разработчиков, отнимает кучу времени, и кроме того, у масштабирования есть предел. Те, кто будет дальше за это ратовать — увидят, как релиз Drupal 8 будут откладывать еще дольше.

Если Друпал затянет слишком далеко в неподдерживаемом, нежизнеспособном направлении, ядро официального дистрибутива Друпала можно будет заместить «средним» решением, урезанным до нормального размера, позволяющим сосредоточиться на дизайне архитектуры. Такая возможность есть, но использовать ее следует только в крайнем случае.

А теперь развлекайтесь на DrupalCon в Лондоне!
Буду скучать.

Примечание: если кто-то воспринял мой пост как личное оскорбление, позвольте заверить вас, что я совершенно определенно не думал ни о ком лично в процессе написания. Я пытался оставаться настолько непредвзятым и объективным, насколько возможно. Но я ведь тоже всего лишь человек, да и английский у меня — не родной.