Pull to refresh

Почему не Drupal?

CMS *Website development *Drupal *
Sandbox
Dries Buytaert
Недавно, я столкнулся с некоторыми проблемами при разработке проекта на Drupal 7 (при переходе на Drupal 7), но речь не о них. В поисках решений, я натолкнулся на статью "The Drupal Crisis", одного из разработчиков Drupal — Daniel F. Kudwien, которая пролила свет на происходящее в кузнице Drupal. Сразу скажу, что большая часть проблем описанных в статье уже не актуальна, т.к. статья прошлогодняя. Тем не менее многим будет интересно ознакомиться с ее переводом.


Хронология событий


В следующей таблице представлена занимательная хронология событий, которые можно рассматривать как отправные точки начала кризиса Drupal.
2008 февраль Drupal 7 открыт для разработки.
октябрь 285 неисправленых багов.
2009 март Acquia1 взывает сообщество разработчиков о помощи.
июнь 3120 неисправленных багов из 13763
сентябрь Запланирована заморозка кода. При этом 10 новых фич по-прежнему разрабатываются с нуля и их внедрение разрешено в Drupal 7
2010 январь Выпущена первая альфа-версия Drupal 7 с кучей критических багов в новом API. Но еще больше багов в тех самых новых фичах.
июль Поток ошибок слишком большой (как мы все знаем, один исправленный баг зачастую имеет свойство порождать несколько новых), разработчики не справляются. Командный дух и ощущение цели утеряно.
Чтобы хоть как-то разгрести всю эту «кашу» вводится новый приоритет для багов — «major» (важный).
Даже не представляю, какой ад творился у них в багтрекере.
октябрь Выпущена первая бета-версия Drupal 7
2011 январь Drupal 7 выпущен с более чем 300 неисправленных major-багов и нерабочим механизмом обновления.
май Чтобы хоть как то стабилизировать ситуацию нанимается еще один maintainer2 для сопровождения Drupal 7 и Drupal 8, над ядром которого также идет работа. Drupal проводит политику исправления ошибок в стадии разработки Drupal 8 и затем выпуская обратные (backporting) фиксы для Durupal 7 и 6.
июнь Более 200 critical и major-багов меняют статус на normal.
июль Новые цифры: 15 критических и 200 важных ошибок в ветке Drupal 8 затрудняют backporting-политику.
август 4153 неисправленных бага из общего количества в 22181, которое за два года возросло почти в два раза практически останавливает развитие ветки Drupal 8. Порядок обновления Drupal 6 и Drupal 7 все еще неясен многим пользователям.

Как видите события развиваются плачевно. Только в новых проектах: Dashboard, Shortcut, Toolbar и Overlay более 150 неисправленных багов и задач. Именно эти модули разрабатывали с нуля после заморозки кода, затем их переписывали как минимум один раз после внедрения, что очень сильно повлияло на отложенный релиз Drupal 7.
На 2012 год ситуация с 7кой вроде улучшилась. В намеченном релизе 8-ки все относящееся к ядру теперь будет вынесено в папку core.


Разбор ситуации


«Считаю, что изначальный призыв сообщества Drupal к помощи демотивировал ключевую группу: разработчиков ядра, способных справиться с самыми тяжелыми задачами…
У нас сейчас примерно 450+ разработчиков ядра, из которых где-то 10 работают над интерфейсом»

© с этим замечанием когда-то выступил один из лидеров команды, ответственной за юзабилити.

Иными словами: «разработчики ядра не особо хотели взваливать на себя груз, но взвалить пришлось все равно». Эти новые фичи не только задерживали релиз Drupal 7, но и отвлекали разработчиков ядра от работы над более важными проблемами API и подсистем ядра Drupal. Многие из этих проблем до сих пор не решены. Сверху же посчитали, что неплохо было бы реализовать этот функционал. Ну и что, что сырой?! Суйте его в ядро — пусть сообщество поддерживает.

Новые подсистемы Drupal 7 очень сложны и сильно взаимосвязаны с другими не менее сложными подсистемами. Из-за этого (высокий порог вхождения) новички не могут быть включены в процесс исправления багов. Это прерогатива прожженных разработчики ядра и модулей, глубоко понимающих последствия изменения этих подсистем. Не совсем понятно, что думало руководство Acquia, взывая о помощи сообщества. Крик души?

Без всяких сомнений: бесплатный вклад в разработку и интересы коммерческих предприятий — в целом, несовместимы, что во многих случаях сильно тормозит развитие и даже губительно. Drupal тому пример. К сожалению, вклад в код ядра некоторых из самых активных и опытных разработчиков, устроившихся за последние 3 года в компанию, внезапно снизился практически до нуля. Конфликт интересов на лицо. Видимо, не судьба Acquia стать для Drupal тем, чем был Red Hat для Linux.


Что мы имеем?


В дополнение к вышеупомянутым «недоделкам» и новым фичам, ядро Drupal до сих пор тащит за собой кучу очень старого и никому не нужного хлама (сарказм-field: даешь MVC?!), основанного на API и концепциях, допущенных в Drupal 5 лет назад и раньше.

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

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

Ядро Drupal больше не поддается поддержке. Вы все еще верите в красивые сказки Acquia о LTS редакциях для нежелающих гнаться за номерами версий?!


Путь Drupal. Есть ли выход?


Daniel F. Kudwien в своей следующей статье "Drupal Crisis Conclusion" предлагает несколько способов взять разработку Drupal под контроль. Но динамика такова, что за последние 2 года появилось 8000+ новых сообщений о багах.

Каждое из них должно быть:
  1. создано
  2. проанализировано
  3. исправлено
  4. рассмотрено экспертом
  5. протестировано
  6. одобрено
  7. и, наконец, добавлено в код

В среднем это означает, что через данный процесс должны проходить 320 багов в месяц или 10 багов в день. Не трудно подсчитать, что для того чтобы разгрести все это потребуется более 2 лет. Причем, дальше эти числа будут только расти, т.к. как части ядра изменяются и всплывают различного рода несостыковки подсистем. Стремительные темпы наблюдаются уже сегодня.

Как признаются сами разработчики, мы уже сами не знаем, какие части Drupal на самом деле считается ядром, а Acquia уже тольком не знает что в ядре активно поддерживать.
У разработчиков уже практически нет желания помогать в поддержке этого бедствия из недоделанных модулей. Сейчас куча неважных вещей отвлекает разработчиков от категорически необходимого рефакторинга, направленного на борьбу с настоящими, ужасными проколами в дизайне ядра.


Заключение (от меня)


Всех интересуюет вопрос, что ждет Drupal в будущем?

Возможно, Drupal 8 намертво увязнет в своих проблемах, и чтобы вытащить его, Acquia придется еще больше рассчитывать на свои силы, и еще меньше — на сообщество. Многие переосмыслят использование Drupal в своем бизнесе.

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

Почему нелогическому? Многие продукты остаются лучшими на протяжении нескольких лет, отлично работают и радуют тех кто ими пользуется. Но не самих разработчиков, которые достигли предела совершенства, «высосали» все из проекта и бояться его испортить. А, топтаться на одном месте — не выход, потому что в этом нет развития, логики, прогресса… как хотите. Иногда такие проекты замораживают, для того чтобы начать работу над чем то новым, более революционным. При этом конечно могут образовываться форки и продукт долгое время еще не потеряет своей актуальности. За примерами далеко ходить не нужно: замечательный CMF CodeIgniter из которого образовалась Kohana.

На сегодняшний момент считаю, что Drupal 6 — это пик развития Drupal. Стабильный и устоявшийся продукт, один из лучших в своем роде. Далее, развитие этой прекрасной CMS переходит в другое русло: Drupal перестает быть продуктом сообщества, и все больше становится продуктом корпорации (в некотором смысле повторяя судьбу Linux).

не-ловкий-момент
В России сформировалось огромное сообщество Drupal-разработчиков, ежегодно собирающихся на таких конференциях, как: DrupalConf, DrupalForum, DrupalCamp и др.
Сейчас, они будут защищать Drupal и это верно, т.к. лучший инструмент — тот, которым ты лучше всего владеешь. Но и они уже недовольны. Полистайте комментарии например, здесь.

Я бы хотел сказать новичкам, которые стоят перед выбором, еще раз подумать, какую CMS/CMF использовать в качестве основного инструмента. Тем более, что вектор определенно сместился в сторону использования веб-фреймворков.
Для себя лично, я уже сделал выводы… главное во время отказаться от того, что тянет тебя вниз.

И напоследок скажу, что автор, ожидавший массу негативных эмоций, несогласий и ругани из-за поста "The Drupal Crisis", к своему удивлению обнаружил, что практически все, кто ответил на пост, в целом согласились с озвученными проблемами.

Тем временем Rockettheme3 прощается с Drupal (оригинал).


Первоисточники и прочие материалы


  1. Daniel F. Kudwien «The Drupal Crisis»
    Оригинал:
    http://www.unleashedmind.com/en/blog/sun/the-drupal-crisis
    Перевод Романа Грачева (http://graker.ru):
    http://graker.ru/news/2011/08/25/khvatit_krasit_guby_ogromnoi_svine
  2. Daniel F. Kudwien «Drupal Crisis Conclusion»
    Оригинал:
    http://www.unleashedmind.com/en/blog/sun/crisis-conclusions
    Перевод Романа Грачева (http://graker.ru):
    http://graker.ru/news/2011/08/26/kak_smyt_makiyazh_so_svini_ili_vykhod_iz_krizisa
  3. Туманное будущее Друпала
    http://www.drupal.ru/node/65464?page=1
  4. Почему я не люблю Drupal
    http://habrahabr.ru/post/44980/


Сноски


  1. Acquia — фирма созданная разработчиком Drupal Дрисом Бёйтартом.
  2. Maintainer — человек, сопровождающий программный продукт, принимает участие в разработке и багфиксах.
  3. RocketTheme — лидирующая студия по производству платных шаблонов для Joomla. Также производит шаблоны для других CMS.
    Основана Andy Miller, являющимся соучредителем Joomla.
    Miller работал над CMS Mambo и ранними версиями Joomla в качестве основного разработчика.
    Шаблоны от RocketTheme используют Gantry Framework, который так же является их разработкой.
Tags:
Hubs:
Total votes 137: ↑107 and ↓30 +77
Views 24K
Comments Comments 295