19 сентября 2018 в 20:51
Коллеги, поднимаю наболевшую тему с целью поделиться своим опытом и узнать о вашем мнении о ситуации на рынке.
На мой взгляд, тенденция разработок на базе Drupal в русскоговорящем сегменте такова, что разработчики предпочитают смотреть в сторону иностранных клиентов, чем пытаться что-то делать для локальных. Выгоднее работать там, где платят больше денег за тот же объем работ, и в довесок, где не требуется тратить время и доказывать/убеждать клиента делать проект на системе Drupal. Зарубежный рынок является “родным” для платформы.
В РФ скорее предпочтут 1С Битрикс и ему подобные аналоги т.к. есть готовые решения, есть сотни компаний-внедренцев (которые сами рады “втюхивать” CMS-ку за партнерский % с продаж).
Считаю, что еще сказывается ментальность аудитории (заказчиков), а именно условия продиктованные рынком их потребителей (краткосрочность). Я считаю, что Drupal - это решение для долгосрочных стратегических веб-проектов, для тех, кто умеет планировать на 3-5 лет вперед.
Также “размывание” аудитории спровоцировано новым трендом конструкторов сайтов (прим. Wix). Конструкторы сайтов на мой взгляд - это иллюзия работающая в рамках ложного убеждения, что бывает “просто+быстро+дешево+качественно”. Снаружи классный маркетинг, а внутри…
В итоге, основные факторы влияющие на стоимость разработки:
— Демпинг в среднем сегменте (низкий сегмент не учитываю).
— Более длительный срок разработки, чем на других системах (CMS). Малое количество готовых профессиональных и в т.ч. сегментных решений на Drupal, с PR-поддержкой и отлаженным саппортом.
— Отсутствие маркетинг-модели/стратегии. Потенциальная аудитория почти ничего не знает о Drupal.
— Дезинформация и неправильное позиционирование Drupal на русскоязычном рынке. Больше времени уходит на поиск и убеждение клиентов.
К ценовому демпингу приводят следующие факторы:
— Высокая конкуренция, а точнее иллюзия выбора среди “идеальных” CMS.
— Низкие компетенции многих исполнителей и заказчиков. Как следствие - проекты низкого качества > малое количество крупных компаний использующих Drupal в РФ, Белоруссии и Украине. И итоге: мало рабочих проектов для крупных компаний.
Про наш опыт разработок на Drupal:
На раннем этапе мы наелись “недорогих” проектов, которые обычно заканчиваются “проигрышем” для компании-разработчика. Маржинальности почти нет, вся команда устает из-за параллельности проектов, заказывают бесперспективные веб-проекты. С клиентами из низкого ценового сегмента, как правило, сложнее строить долгосрочные доверительные отношения (в большинстве случаев).
Пришлось менять стратегию, чтобы выжить. Поднимали качество путем разработки стандартов, строили процессы, нанимали больше людей, обучали, и все для того, чтобы попытаться работать с клиентами из среднего и высокого сегмента. Изменение позволило вывести направление компании по внешним drupal-разработкам в прибыльное. Но, есть свои нюансы, приходится иметь дело с рисками совершенно иного уровня. Полагаю, что пояснять не нужно.
Время идет… Рынок веб быстро меняется, и как мне кажется, Drupal в РФ начинает отставать от общей тенденции. Как считаете?
P.S. Некоторое время сообщество заморачивалось с созданием НКО для русскоязычного Drupal, но цель мне так и не стала ясна.
Комментарии
Хз.. как ни странно, но вопреки, а не благодаря, но Drupal в Рунете как минимум не сдает свои позиции.
Это, как говориться, мое сугубо личное мнение, основанное на том что я вижу сам вокруг себя..
Возможно кто-то вокруг себя видит другое..что, скорее всего, тоже некоторое отражение реальности в отдельно взятом окружении данного наблюдателя.
Значит получается, все это потому, что Drupal очень живучий, и нашу песню не задушишь не убьешь-)
Это слишком оптимистичный взгляд диванного фрилансера.
Оптимизм в оптимальных дозах может быть не только вреден..
А "диванного фрилансера" это что-то про сладкий сахар?-))
Drupal наверное самый живучий, если смотреть в ретроспективе и сравнивать с другими системами. Однако, меня не покидает ощущение, что в "чистом виде" Drupal является слишком дорогим решением (время > деньги) для разработки, поэтому уступает другим более дешевым "альтернативам".
На восьмёрке можно сделать конвеер, как это сделал радон. Это сильно удешевит и ускорит разработку, но для этого нужна как минимум высокая квалификация разработчика и большое количество проектов. То есть это вариант не для фрилансеров.
Другая ниша восьмёрки - большие и толстые по функционалы, рассчитанные на аналогичный кошелёк. Но тут нужна ещё более высокая квалификация + нужно несколько разработчиков, чтобы не растягивать сроки на годы. Что также не подходит для большинства фрилансеров.
Собственно поэтому и плодятся статьи типа восьмёрка говно, статейник за полчаса не собрать. Грядёт очередное глобальное вымирание. Вернее оно уже началось. Вымрут всякие динозавры типа файлзиллы))
Ну да, ну да. Только вот без диванных фрилансеров народ мигрирует с Д7 не на Д8, а на вп и битрикс. Получаем сокращение экосистемы.
Уменьшается количество, увеличивается качество, на то он и энтерпрайз.
Глядя на количество И качество модулей под вп и друпал закрадываются смутные подозрения что не всё так просто;)
Да, все ж Drupal это enterprise-решение. В точку!
Упрощу ваши многобукаф:
Ваш путь, имхо, очевиден. Тем более, что "живете" одним проектом в год.
А если, еще и E-commerce, то лучше сразу убегайте.
про E-commerce не совсем понятно, почему "убегать" то надо?) Мы в большинстве случаев работаем с e-commerce проектами клиентов из РФ и ближайшего зарубежья, как ни странно)
>P.S. Некоторое время сообщество заморачивалось с созданием НКО для русскоязычного Drupal, но цель мне так и не стала ясна.
Оно уже есть, но пока не особо применимо. Просто если вдруг будет какой грант под которым можно сделать конференцию - его будет проще взять.
Пост хороший. Очень много сегментов, во всех разная картина.
>С клиентами из низкого ценового сегмента, как правило, сложнее строить долгосрочные доверительные отношения (в большинстве случаев).
Можно. мы научились. Тут специализация важна.
Про НКО согласен.. юр.лицо эффективно работает, когда оно представляет из себя нечто целое, организовано идущее к какой-то определенной цели.. А персонажам басни Крылова юр.лицо только во вред..
> Просто если вдруг будет какой грант под которым можно сделать конференцию - его будет проще взять.
Надеюсь, мы все дождемся этого момента) Было слишком много обсуждений, а действия по итогу совершались? НКО зарегистрировано?
> Можно. мы научились. Тут специализация важна.
По-началу думал, что это может быть лишь совпадения... просто частые и очень похожие 
Согласен, при том клиенты наших клиентов (сори за тавтологию) оказывают непосредственное влияние. Например, мы много работали со строительными компаниями. Аудитория там сложная, много обмана, и было похоже, что вся "бизнес-модель" основана на принципе "не нае***ь - проживешь"
Да, зарегистрировано, новосиб, i20biz, те парни которые уже делали кэмп и как раз была история про грант.
Ничего не имею против конструкторов сайтов. Ну если у человека мелкий бизнесс и стандартные требования, нахрена ему кормить дизайнеров, разработчиков, сеошников.
Пусть начинает с Викса, Укоза, Тиу. Надо будет что-то больше - закажет и его требования будут более адекватные.
Согласен.
Тоже не против конструкторов, но дело в маркетинговой подаче, которая в глазах потребителя наделяет конструктор сайтов волшебными свойствами и возможностями... навороченные как ERP, но только с 2-мя кнопками: "Включить" и "Бабло"
А клиенты верят, даже когда их потребности существенно выходят за рамки "конструктора". Маркетинг создает иллюзию.
С такими клиентами все равно каши не сваришь. Пусть пользуются конструкторами. Много денег там не потратят.
По секрету могу сказать, что уже есть конструкторы сайтов, сделанные на восьмёрке.
Для потребителя это в первую очередь конструктор, а не Друпал.
Ну так мы же тут не потребители вроде как.
из того, что я видел на Drupal - они проигрывают по интерфейсу и простоте логики. Все же Drupal не для начинающих пользователей, как бы его не пытались упростить. Возможно, позже кто-то придумает еще более простую модель интерфейса, но как мне видится это будет иметь побочку, например для того же SEO из-за мусорности кода после "конструирования".
Поигравшись в конструкторы клиент начинает понимать за что с него хотят денег разработчики. Так что это наоборот очень хорошая штука. С другой стороны, если клиенту всё понравилось в конструкторе - это вообще отлично, значит он сэкономленные деньги в бизнес вложит или там детям игрушки купит.
Все движется в сторону коробочных отраслевых решений так как, так как качество выше , а цена меньше = это для клиента.
Если Вы в состоянии обеспечить предложение для этого спроса = Вы на "коне".
Приветствую! да, тренд именно такой, но как мне видится, что клиентам не хватает гибкости в готовых решениях. К нам недавно пришел клиент на разработку системы для онлайн-обучения. Они год пользовались GetCourse, плевались, но "ели кактус", альтернатив ему в РФ практически нет, но сама платформа оказалась "тупиковой" из-за непродуманной архитектуры... оставлю без подробностей, там доходит до смешного, просто сервис явно управляется не разработчиком). В итоге, заморочились и создают (с нашей помощью) свое комплексное решение в т.ч. под индивидуальные нужды. Получается, что коробочное или saas должно обладать гибкими свойствами, чтобы закрывать пускай даже небольшие, но индивидуальные потребности клиентов.
Одна из сфер применения Drupal, в которой наверное у Drupal не много конкурентов:
Быстрое и недорогое "построение" рабочего прототипа вэб-приложения.
Например если надо быстро и недорого протестировать "бизнес-нишу".
Семерка в этом плане "выезжала" за счет огромного кол-ва готовых модулей.
У Восьмерки готовых модулей пока немного, в сравнении с Семеркой.
Но улучшенное "переиспользование" наработок в Восьмерке, сглаживает этот "недостаток".
Но для этого нужно "специальное" ТЗ-)
Оно конечно должно учитывать "необходимости" Заказчика, но в первую очередь должно писаться под возможности Drupal.
А я вот недавно понял, что возможности друпала в первую очередь ограничены возможностями разработчика.
И кстати ещё одна ниша - это хэдлес технологии. Для относительно простых приложений бэк можно собрать из готовых модулей и накликать мышкой всего за пару часов, не написав ни одной строчки кода.
До этих "пары часов" еще пройдет месяц изучения мануалов))) Так что да, "возможности друпала в первую очередь ограничены возможностями разработчика".
Можно ссылки?
Раньше попадались регулярно. Уже не помню, где видел, сейчас надо гуглить, но мне в лом и я не буду)))
кто бы что не писал... Архитектура системы по итогу решает. Есть ли еще похожие Друпалу альтернативы?)
Размер сообщества разработчиков (самое большое в мире, среди CMS/F систем) тоже говорит о чем-то...
Симфони
А между тем в этом месяце D8 демонстрирует обнадеживающий рост:
Вопрос поднят интересный, вполне вероятно, что Друпал будет преуспевать в несколько видоизменном формате.
Не секрет, что весь фронт-енд уверенно переходит на JavaScript в виде библиотек/фрейморков React, Angular, Vue.
Даже в ААА-тайтлах типа Battlefield 5 используется React для создания интерфейса.
Но есть одна проблема - клиент не хочет нанимать разработчика, чтобы управлять контентом, ему нужна CMS, желательно подогнанная под его конкретные нужды. Кроме того, писать вручную бек-енд - это долго и дорого, т.е. напрашивается очевидное решение - соединить надежную и гибкую CMS с передовыми технологиями фронт-енда.
И здесь дальновидность Дриса с его API-first философией, положенной в основу Drupal 8, дает неожиданное преимущество перед конкурентами.
Активно развиваются продукты, облегчающие задачу по объединению этого стака. Contenta CMS, React Apollo и т.д.
Я сейчас делаю сайт на свежевышедшем Gatsby.js 2, в команде которого есть люди, много лет посвятившие себя разработке на Drupal.
Так вот, в Gatsby.js есть плагин для интеграции Drupal, нормальная документация по этой теме и несколько видео туториалов.
Опять же, если верить Дрису, в ближайшие годы Drupal срастётся с React, и самописные php-динозавры типа WordPress будут выглядеть безнадежно устаревшими.
Но WP тоже притянули в админку что-то, не помню что.
Backbone у них точно есть
Слушайте, а как с gatsby-проектами решают про наличие форм(любых) на проекте?
Schemata на стороне друпала и json-schema-form на стороне реакта. Самих форм, как таковых на бэкенде нет - он отдаёт json-структуру формы и принимает данные в json.
Прослеживается стратегия развития платформы, никакого "болота". С одной стороны каждая новая версия (эпоха) Drupal - логически завершает предыдущую и это больно, особенно если на предыдущей версии разработаны и работают крупные проекты, но с другой стороны эти кардинальные изменения позволяют платформе выходить из "устоявшихся" методологий, что продляет жизнь проекту через адаптацию, с опережением лет на 5 (как минимум).
Я давно говорю, что нынешние лидеры OpenSource-CMS в ближайшем будущем захлебнутся в поддержке легаси
На рынке Drupal конечным пользователям совершенно все равно на какой версии реализован веб-проект. На пике технологической волны находятся разработчики, которые формируют уверенное движение в заданном направлении.
Для разработчиков технологии только совершенствуются и усложняются (стоимость разработки только растет), а для конечного потребителя важна максимальная упрощенность и низкая стоимость (все делать одной кнопкой и платить как можно меньше).
Как мне видится рыночная тенденция: веб-разработки в сегменте частных заказов (небольших сайтов) перестанет существовать в "чистом" виде. Недовебмастера начнут изучать и внедрять некие гибриды (конструкторы и др.), ближайший пример - сервис GetCourse с небольшим сообществом пользователей-недоразработчиков готовых за 10-20 т.р. настроить систему под клиента в рамках ф-ционала заложенного разработчиками этой платформы.
Появятся drupal-продукты, более адаптированные к современным нуждам рынка, которые "внутри" (для разработчиков) будут весьма сложно устроены, а для конечных пользователей - максимально упрощенными.
Может в новой бизнес-модели веб-разработок добавится еще что-то, например что-то из бизнес-модели RedHat.
Лично я вижу практически безграничный потенциал для разработчиков в ближайшем будущем. Снова учиться, снова практиковаться и следовать тенденциям...
Друпал в этом раскладе не нужен, за 10-20т.р. в ленивом режиме накликивается весьма кучерявый сайт на вп, который просто работает и будет работать ещё очень долго (потому что обновляется в два клика).
Backbone не является актуальной в 2018, но дело даже в другом. На WordPress можно быстро развернуть приличный сайтец, и в плане выбора инструментария он превосходит Drupal (хотя хорошие темы и плагины в большинстве случаев платные, особенно если идет речь о продвинутом функционале).
Производительность у WordPress не блещет. У меня был случай, когда клиент требовал поднять показатели gtmetrix выше 70%, что мне так и не удалось, в том время как сайты на D8 без особого шаманизма удается держать в радиусе 80-90%, но это дело частное, и цифры эти по существу мало что значат (кроме случаев с придирчивыми клиентами).
Речь о том, что WordPress не показалась мне хорошей CMS в текущем виде. По крайней мере, мне не удалось сделать её такой же удобной для клиента, как Drupal. Причина - отсутствие четкого разделения слоев template и content.
В Drupal клиент работает в разделе Материалы, где исключительно оперирует контентом, который рендерится в рамках созданной разметки. В Wordpress ему приходится лезть прямо в конструктор страницы, не важно какой из множества конструкторов используется, и зачастую эту разметку ломает. Один вид этих инструментов для редактирование страницы отпугивает клиента и заставляет его каждый раз привлекать разработчика по мельчайшему поводу, чтобы не нажать ничего лишнего.
Можно отыскать еще много недостатков WP, но для меня отсутствие возможности у клиента полноценно управлять конентом без риска задеть слой шаблона или слой логики нигилирует саму идею CMS.
Допускаю, что я не отыскал правильных плагинов, либо в WordPress 5 появится аналог views.
Это точно о вп?! О_О
Какой ещё конструктор страницы? Как ещё нафиг задеть слой шаблона или логика?? Новости из параллельной вселенной.
Выбирайте любой
По-моему в некотором роде это и ответ: Надо уменьшать стоимость разработки.
Не за счет серьезного уменьшения тарифов-))
Первый способ: оптимизация ТЗ под drupal-way
Бывает Заказчик вываливает ТЗ-монстр, где все запутанно-переплетено..
С первого раза кажется на месяцы работы.
Потом немного причесываешь ТЗ,
систематизируешь, с первого взгляда разные, но на самом деле в общей части одинаковые подзадачи,
подбираешь существующий "стратегический" алгоритм решения задачи,
подгоняешь все это дело под возможности Drupal (drupal-way-)
В итоге, для решения задачи оказывается достаточно несколько контриб-модулей, реализующих 80% функционала (как в той притче) и несколько модулей, реализующих остальные 20% функционала
конечно, в итоге стоимость разработки, согласно калькуляции выше, не снижается в 5 раз-) но снижается, в любом случае, достаточно ощутимо.
Второй способ: "Многоразовое" использование кода и OpenSource
и т.д.
Вот вообще не согласен абсолютно. Что значит "оптимизация тз под друпал-вэй"? Друпал вэй - это не мышка, это не контрибные модули, это не упрощение. Друпал-вэй - это комплексный подход к построению алгоритмов и к их реализации. Не бывает друпал-вэй и недрупалвэй задач, есть только друпалвэй и недрупалвэй решения.
И если разработчик подгоняет ТЗ якобы под друпал, на самом деле не надо лукавить - разработчик просто понижает планку требований до уровня своей квалификации и не более того. И это касается не только друпала. Не важно, друпал это, вордпрес или укладка плитки - если исполнитель начинает упрощать ТЗ, значит он недостаточно компетентен.
Тот кто адаптирует ТЗ, тот с 2008 года лепит слайдеры на views slideshow. А тот, кто один раз переступил через себя и сделал хотелки заказчика, тот коммитит сейчас в cutting edge опенсорсные проекты.
И не надо просто удешевлять разработку. Надо всегда ставить цену, адекватную усилиям. И естественно, цена и усилия будут сокращаться при появлении наработанных собственных решений, но прошу заметить - наработка решений это как раз и есть процесс, обратный упрощению ТЗ.
ЗЫ: этт уже ближе к 2 способу.
Как говорят японцы, у каждого свой drupal-way..
Для кого-то это - сделать оффигенно, но дорого для конечного потребителя, без всякого учета рентабельности конечного продукта.
Для кого-то это обоснование собственной недостаточной квалификации.
Для кого-то это качественно и оптимально по затратам решать бизнес-задачи заказчика.
Для кого-то ...ээээ... и т .д.
Один из последних случаев у нас в компании:
Клиенту потребовалось организовать систему бизнес-процессов с графическим редактором блок-схем. Фактически, клиент хотел "рисовать" процессы (модули Maestro + Orchestrator) и назначать на каждый процесс автоматические действия (модуль Rules + куча подмодулей) Мы нашли подходящие по функционалу модули и начали решение задачи. Сконструировали "прототип". Затем оказалось, что модуль Maestro решает более 80% из поставленной задачи, но спроектирован достаточно узкоспецифично. Для того, чтобы на 100% обеспечить решение согласно цели клиента - нам бы пришлось делать патчи, либо мудрить "костыли", но мы отвечаем за производимые решения репутацией и делаем на совесть. В итоге приняли решение отказаться от Maestro из-за его логических ограничений. Архитекрута модуля просто не была продумана универсально. Приняв на себя ответственность за решение - пришлось писать свой модуль (если точнее - группу модулей) бизнес-процессов, а это доп. фин. нагрузка (фактический минус). В итоге, вместо 1 дня на разборку и настройку модуля Maestro (который закрывал 80% из поставленной задачи) мы потратили порядка 3-х недель. В денежном выражении работа всей команды разработчиков обошлась в круглую сумму. Клиент, разумеется, не готов платить за этот "пшик". Аргументация у клиента простая, что у того же Битрикса это реализовано, протестировано и стоит меньше, на сумму за разработку модуля можно купить несколько лицензий. Вот на таких "мелочах" Drupal становится невыгодным для обеих сторон.
Но, наша миссия/стратегия такова, что мы понимаем все преимущества Drupal и вкладываемся в разработки, снимая нагрузку с клиентов, хоть этот процесс крайне болезненный и длительный. Это тяжелый путь и я бы искренне не рекомендовал повторять его, проиграть очень легко. Это всего лишь наша попытка сделать Enterprise-Drupal доступным для определенной аудитории, более массовой.
Уверен, что если бы взялись за детальную проработку ТЗ на Битриксе, то выяснилось бы, что всё это реализованное и протестированное, решало бы задачу клиента на те же самые 80%.
А оставшиеся 20% точно как же стоили бы 80% разработки, если не хуже.
т.е. проще говоря вы не смогли допилить модуль под проект, где УЖЕ решалось 80% задачи и решили написать новый за 3 недели...
Вот тут, поконкретней, пожалуйста.
Вполне обыденная ситуация. Как известно, первые 90% проекта занимают 90% времени. А оставшиеся 10% занимают ещё столько же. Те самые 20% могут оказаться очень критичными, а по трудоёмкости допиливание существующего модуля как правило даже больше, чем написать модуль с нуля под определённую задачу.
Сильно сомневаюсь, что подобное применимо к данной ситуации. Чет многое не сходится по описанию ТСа.
+ с архитектурой Maestro знаком...
совершенно верно, так и получилось. Ниже я описал ситуацию.
Не совсем, скорее клиент пытался ориентировать на ф-ционал Битрикса по BPM.
Все дело в "силе" стратегического решения. Существуют "слабые" и "сильные" решения. Поясняю...
Maestro во многих логических частях не приспособлен для гибкой работы с нодами, сущностями, статусами и др. В модуле используются собственные сущности, которые как раз не дают гибкости, в сравнении с теми же нодами. Можно было конечно попробовать допилить сущность Maestro до того, что требовалось по ТЗ, но это тупиковая дорожка. Скорее всего через N-время клиенту понадобилось что-нибудь добавить в ф-ционал BPM, а значит, потребуется пилить Maestro дальше. Это все нагромождения поверх изначально ограниченной логики. При том, модуль Maestro огромный и разобраться с тем как он работает, какие у него есть возможности, к чем можно "подцепиться" и др. занимает много времени. Мы детально разобрали модули и приняли решение, что их допиливание – это временнАя ловушка: да, мы бы выиграли время в первой итерации разработки, но позднее, при расширении ф-ционала мы бы только теряли и проклинали себя за "слабое" стратегическое решение.
Странно.
hook_entity_presave и hook_entity_load обычно решают 99% потребностей.
И hook_entity_property_info_alter - остальной 1%.
А вообще, это не справедливо, я бы даже сказал это дискриминация какая-то: друпал все больше становится CMF (ориентируется на разработчика, а не только на "сборщика" (CMS)).
А поддержка Drupal больше для CMS.
В каталог модулей drupal.org "принимаются" только готовые решения (модули) c достаточной поддержкой.
В результате чего просто огромная куча кода, написанная под какие-то конкретные проекты "пропадает зря".
Потому-что затраты на "обощение" "кода" для более универсального применения и оформление его до стандартов каталога модулей drupal.org - в большинстве случаев не окупятся.
Я думаю, для обеспечения возможности повторного использования кода, а следовательно удешевления разработки, а следовательно для популяризации и развития Drupal было-бы здорово иметь еще некий "каталог модулей"(наработок) и для разработчиков (и тех, кто ищет разработчиков для решения каких-либо конкретных задач).
Я в курсе про github, но категоризация репозиториев там не организованная и пользоваться им в данном контексте, мягко говоря, не удобно.
Да ничего подобного. Можно спокойно заливать свои модули на d.org в статусе Full project.
Будет висеть плашка This project is not covered by Drupal’s security advisory policy.
Если помогут пройти security check - уберется.
Такой код можно держать в песочнице того же d.org, появятся ко-мантейнеры - можно будет и в контриб перевести.
Если увеличить на орге количество модулей, это приведёт только к дополнительным сложностям при поиске. А если учесть, что под редкие задачи модули часто приходится устанавливать, чтобы посмотреть, что они делают, то после установки пятого по счёту неподходящего модуля любой адекватный человек плюнет и накодит свой кастомный модуль.
Коллеги, вы читали но не вдумались, про что я написал..
А смысл? Если он не расчитан в сыром виде для использования на ЛЮБОМ сайте?
Но возможно, при необходимости, его можно адаптировать под другой сайт или даже при некотором "спросе" сделать "универсальную" версию?
Идея не в том, чтобы выползти на drupal.org, как минимум это не основной смысл.
Смысл в том, чтобы громко заявить: Парни, вот такую *фигню* я уже делал, у меня есть по ней наработки, второй и последующие разы ее реализация обойдется немного (а может и много) дешевле.
Я не писал конкретно про орг.. Я знаю несколько людей, они каталог модулей подобно оргу сами могут сделать-))
Ок.. распишу немного подробнее с примерами.
Допустим я на каком-то проекте написал модуль, который достаточно жестко связан с тем проектом, но его функционал с большой долей вероятности может быть востребован на других проектах..
Что обычно в подобных случаях происходит?
Модуль лежит где-то в бэкапах, потом ты забываешь вообще, для чего он разрабатывался, и при следующей чистке свободного пространства на жестком диске он просто удаляется.
Почему это происходит?
Потому что никто не знает, что задачу, для которой разрабатывался этот модуль, уже решал.
А если будет некий инструмент-ресурс, где ты как минимум мог бы выложить описание той задачи, которую решал разработанный тобою модуль или джае исходный код(например ссылку на github). На котором его достаточно несложно было бы найти при необходимости.
Т.е. на первом этапе тебе не надо оптимизировать его под правила drupal.org.
Просто за пол-часа составил описание, при необходимости добавил ссылку на гитхаб и вуаля: про твои старания уже знают куча человек. А как этим распорядиться, тут много вариантов.
Для этого можно вести блог. Описал задачу, описал алгоритм решения, привёл фрагменты кода. И не надо вываливать в открытый доступ код с завязкой на конкретные филды/типы сущностей/классы вёрстки. Потому что узнать принцип и глянуть на десяток ключевых строк порой куда удобнее, чем рефакторить 1000 строк под свою ситуацию.
Тогда - в песочницу.
Смысл - в том, чтобы найти единомышленников, которым этот код может помочь, обзавестись ко-майнтейнерами, получить поддержку этого кода.
Да есть уже это ресурс - называется: drupal.org.
Что вас вечно тянет плодить сущности без лишней на то нужды?
Залил модуль в песочницу, сделал ему нормальное описание, чтобы было понятно для чего он, огляделся - если кому-то еще нужен значит - хорошо, допиливаем, и в контриб. Если нет - значит, пусть лежит в песочнице.
это контрпродуктивно.
Например у нас есть 1000 разработчиков, которые хотят дать "вторую жизнь" своему коду.
Каждому из этой 1000 необходимо сделать свой блог и раскрутить его.
Пусть кажды разработчик потратит на это допустим 20 часов.
В итоге получаем затраты: 20 000 человеко-часов.
Причем, часть из них отсеется еще на этапе разработки блога.
Часть отсеется на раскрутке.
Про большую часть этих блогов никто никогда не узнает, т.к. в следствии хреновой раскрутки поисковики будут выдавать их на второй сотне страниц поисковой выдачи.
А чтобы что либо найти по этим блогам , придется потратить, опять же кучу человеко-часов, причем результат не гарантирован, даже если нужное решение всетаки есть.
На разработку первой версии каталога, без особых заморочек, я думаю будет достаточно часов 100, а при наличии каких-либо готовых наработок итого меньше в разы.
Экономический эффект очевиден?-)
Идея хорошая, но вижу снижение эффективности, если не будет "контролирующего узла".
Дык а я про что?
Вот только drupal.org это англоязычный ресурс, т.е. если не бОльшая, то большАя часть единомышленников сразу отсеется.
drupal.org сложно раскрутить в рускоязычной части интернетов, если конечно вы не являетесь владельцем drupal.org и у вас почему-то появилась такая необходимость.
Всетаки каталог модулей-тем drupal.org не "верх совершенства", и в нем много чего еще можно оптимизировать.
И про каталог drupal.org в основном знают только "прожженые" друпал-разработчики. А я, например, хотел бы чтобы про мои наработки узнали люди, не имеющие никакого отношения к друпал, но которым необходим просто разработчик, который может решить их задачу, потому что он ее уже решал-)
Хотелось бы увидеть более полную картину, для чего. Речь про эту часть:
Например, допустим я разработал интернет-магазин, "продающий" типографские услуги (печать визиток, брошюр, буклетов плакатов и т.п.)
Основа магазина: конструктор заказа.
Конструктор заказа, по сути - пошаговый выбор неких параметров заказа (тип бумаги, формат, палитра, контент, тираж и т.п.)
В итоге покупателю выдается макет и стоимость заказа.
Подобный функционал может пригодиться для какой-либо другой "отрасли", в большей части просто адаптировав наборы параметров в конструкторе заказа.
Например это пошив индивидуальных автомобильных чехлов.
Почти теже самые параметры, только бумагу меняем на ткань-)
будни любой более-мене сформировавшейся команды: вы не успеваете актуализировать и держать в порядке собственную базу решений, не то что разбираться в чужой.
поэтому вариант про блог имхо более актуальный. блог-постами пользуются. песочницей - нет (хотя с английским ни у кого проблем нет. просто это дольше чем найти то же самое на какомнть английском блоге).
Зато подобный инструмент мог бы помочь некоторым определиться с более узкой специализацией. Тогда и база решений, требующая актуализации не была бы такой обширной.
Плюс, т.е. минус. поиск по куче отдельных блогов необходимого решения, занятие минее эффективное, чем поиск по хорошо структуированному и категоризированному каталогу.
Плюс, как писал ранее, каталог охватит большее кол-во разработчиков и снизит затраты на разработку-поддержку-раскрутку увеличив качество.
Повторял, повторяю, и буду повторять: братцы, учите английский.
И это при том, что в школе я учил французский, а в институте - английский, т.е. обя языка знаю одинаково плохо. У меня нет никакой особой мотивации топить за английский язык.
Тем не менее. Английский - это такой же рабочий язык для IT-отрасли, как и, например, для авиации.
Английский - довольно-таки односложный и структурированный язык, скорее всего именно по этому он и стал стандактом де-факто в технической литературе.
Ничего в этом страшного нет, надо просто практиковаться, и d.org этому способствует.
Да за братцев я почти не переживаю. Братцы как нибудь с английским разберутся.
А вот как остальных убедить и принудить, вот в чем вопрос.
Абсолютно согласен. Владение английским хотя бы на уровне технической семантики - огромное преимущество и большая свобода выбора.
Нет, не очевиден. Если кто-то скачает модуль, заточенный под конкретный сайт (как это бывает с 99% кастомных модулей), то он потом ещё потратит несколько часов, чтобы в коде отделить зёрна от плевел. А в итоге может и вообще не понять, как же оно работает на самом деле.
А блог не обязательно вести на своём сайте. Есть хабр, есть медиум, есть друпал.ру. И вообще, как по мне, толковому техническому блогу раскрутка не шибко нужна, т.к. запросы в основном очень низкочастотные, а релевантность высокая.
Смысл не в том, чтобы давать качать всем "модуль, заточенный под конкретный сайт "
а смысл такой:
Плюс открывается еще куча возможностей:
- (прикрутив обсуждения-лайки) получить оценку коллег, о качестве работы.
- получить рекомендации коллег по улучшению качества
- получить заявки (или даже заказы) на доработку для "унификации" модуля или заказ на интеграцию в другой проект.
- оказать информационную поддержку пользователям
и многое-многое другое
у Одинэсников такая штука уже лет 15 работает: https://infostart.ru/public/app1C/
И на развитие ресурса зарабатывает.
И разработчикам подзаработать дает
И пользователям издержки снижает
Подобный сервис на мой взгляд должен спонсироваться/поддерживаться более крупными заинтересованными сторонами, а не частными разработчиками-одиночками. В таком случае ресурс будет востребован 3-мя сторонами: разработчики, компании, заказчики.
согласен, с самоорганизацией у нас бядаа..
Не могу понять, как у других получается-)
Мотивации нет. В РФ все же очень "бедные" возможности (рынка почти нет) для развития таких проектов, как Drupal и прочих доп. сервисов, образующих среду. Если бы разработчики видели определенные выгоды для публикации и актуализации своих работ на подобном сервисе - тогда все было бы в порядке с самоорганизацией. По факту мы имеем толковых, но разрозненных специалистов, которые тупо не имеют объективных причин, чтобы тратить время на то, что не даст им обратной пользы. Если бы... подобный сервис поддерживался несколькими компаниями/студиями, тогда были бы все предпосылки к развитию, больше ресурса > возможности. А пока мы лишь наблюдаем результат ментальности и экономической стратегии "разделяй и властвуй". Никто не придет к нам со спасительным мешком денег, пока сами не начнем кооперироваться для достижения целей.
Я вот ушел из друпалеров года 3-4 назад только по той причине что друпал был нацелен только на сборщиков, а я программист. Смысл разбираться в такой сложной системе, а тогда еще и 8-ка появлялась, когда все программирование вовлеченное в друпал разработку предполагает бесплатное написание модулей на d.org.
"Свои под проект" модули хейтятся сообществом за то что они типа ненадежные, т.к. не на d.org и мол это попытка программиста завязать на себя, когда по хорошему все надо мышкой изловчиться сделать на модулях с d.org.
А сейчас вы нарекаете что сборщикам недостает круто конфигурируемых модулей под СНГ специфику, ну так смысл программистам их писать..
В комментируемый Вами коммент заложен немного другой смысл.
Наверное, если он не понятен, значит его надо как-то доступнее "разжевать".. Займусь как появится время..
Ну да ладно, суть не в этом..
Недавно обратил внимание на такую хрень.. кто-то пытается собирать на друпал вэб-приложения исключительно на котрибных модулях, а кто-то принципиально не использует готовые модули, а пишет, пусть корявое, но свое...
Оба подхода - откровенный радикализм-)
Обычно делается все намного проще..
1.Получается задача от заказчика.
2.Подбирается список контриб-модулей, которые способны решить некую часть задачи.
3.То что контрибные модули решить не могут, решается кастомными модулями, и тут навыки программиста киздец как необходимы.
По некоей волшебной формуле, практически 80% хотелок заказчика решается контрибными модулями..
И 20% - кастомными..
т.е. при достаточном навыке, в большинсте случаев, при использовании drupal, вы выдаете результат, который обходится в 2-4 раза дешевле для заказчика, чем при использовании каких либо низкоуровневых фреймфорков и прочих ассемблеров..
помоему, очень мощный инструмент, что семерка, что восьмерка, да и на шестерке люди чудеса творили..