Мы не будем банить людей ни на сайте, ни в чате ни по чьему запросу. Бан на сайте выписывается только за нарушение правил сайта, бан в чате — за нарушение правил чата.

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

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

Где можно увидеть исследование, в котором будет видно, что модули для D8/9 менее живы? Можешь привести примеры проектов, которые отказались от апгрейда до D8/9 и/или ушли на другие решения именно за меньшего разнообразия контриб-модулей?

Себестоимость разработки прямо не влияет на стоимость решения. Стоимость разработки для первого клиента прямо не влияет на стоимость решения.

Один из параметров при определении стоимости решения - потребность заказчика. Кто-то будет готов заплатить и 1000000, другой будет требовать за 100 рублей продать модуль.

Попробуй разные варианты. Например, X денег только за модуль, Y денег за модуль и установку с настройкой, Z денег за модуль, установку, настройку и доработку под нужды заказчика.

Навык работы в команде — это не про «лизание задницы», а про умение воспринимать людей как товарищей, делающих одно дело, умение доносить до людей свои идеи/предложения вежливо и спокойно, способность выслушать и принять чужую точку зрения. Хорошая статья об этом (хоть и про дизайнеров) — https://ux.pub/kak-ux-dizayneru-narvatsya-na-uvolnenie/

Без фактов разговор действительно бесполезный.

Ты ведь не пишешь, почему плохо то, что контрибов для Drupal 8/9 за 8 лет существования меньше 1.5 раза меньше, чем для Drupal 7 за 13 лет существования.

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

Нет, я имел в виду именно кастомную enterprise-сборку LightNest.

Чтобы узнать, почему закончилось развитие Lightning можно почитать официальный пресс-релиз (спойлер: потому что теперь для Drupal 9 развивают Acquia CMS).

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

Я тебе привожу конкретные примеры, ты мне в ответ — какие-то пространные рассуждения. Сделай исследование о том, сколько крупных компаний построило фабрики сайтов на WP и поделись с сообществом.

Еще раз конкретно: как минимум 4 из 500 мегакорпораций используют Drupal для создания инфраструктуры на Drupal. Как пример — доклад на европейском drupal-кемпе про сборку LightNest и 1800+ сайтов.

То есть, мой пример в пух и прах разбивает твои слова про то, что у всех ТНК всего тысяча сайтов наберется. А ты пишешь, что мои примеры подтверждают твои слова. Как это? LOL

Архив Drupal 7.83 «весит» 3.72 MB, а Drupal 9.3 — 30.82 MB (в 8 раз больше).

О чем тебе говорят эти цифры?

Для Drupal 7 есть примерно 14,5 тысяч модулей.

Для Drupal 8 уже есть почти 11 тысяч модулей. То есть, количество модулей составляет уже более 75% от количества модулей для Drupal 7.

Для Drupal 9 уже есть почти 7,5 тысяч модулей. Другими словами, количество модулей для Drupal 9 составляет уже больше 50% от количества модулей для Drupal 7.

О чем говорят эти числа?

Сложно представить себе большой сложный проект, сделанный одним высококвалифицированным разработчиком-фрилансером. У тебя есть такие примеры?

Где хоть один кейс такого использования сотен, и тем более, тысяч сайтов" хоть в одной корпорации?

Давайте как-то помягше. По себе знаю, когда опыта не хватает, даже вопрос правильно сформулировать сложно.

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

bsyomov wrote: Развивать и продвигать платформу которая массово используется куда проще. И привлекать в неё новых разработчиков, кстати, тоже.

Какое именно «развитие» и какие «новые разработчики» имеются в виду?

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

Возможно, для фрилансера-одиночки Drupal будет сложен, если у такого разработчика узкий горизонт планирования.

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

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

Как по мне, так это — разговоры в пользу бедных. Суть-то простая: не умеешь — научись, не хочешь учиться — плати, не хочешь учиться и платить — займись чем-нибудь другим. Я бы предпочел, чтобы в мире было больше людей с инженерным мышлением, чем тех, кто хочет дальше пользоваться каменным ножом (пусть даже собственного изготовления).

Очень странный получается «не прогресс» у Drupal: новые фичи внедряют, общемировым трендам в разработке следуют, лучшие решения интегрируют.

Мне интересно, какие большие концепции нужно освоить, чтобы делать сайты как на Drupal7? Начнем, как принято, с композера — пара-тройка команд, одна из которых на drupal.org дается в виде «copy-paste-enter». Что еще нужно освоить?

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

Сколько человек в команде работает? Как выстроены процессы деплоя и релизов?

Ты пишешь, что не используешь 99% модулей. Какого рода проекты ты реализуешь на Drupal?

Для освоения Webform не нужны навыки программирования. Рядовой контент-менеджер может клепать опросы по готовым сценариям, что дает экономию в 100-300%.