Это локальный ад веб-программиздма.

Миша, посмейся: В Саратове издали книгу стихов «Путинята» http://www.om-saratov.ru/news/index.php?ELEMENT_ID=6472

Леша, у меня с пятницы френдлента забита ссылками на эту книжку, там еще обложка, кстати, рулит невозбранно.

Но это позор для Саратова, да ;)

Потому что у МСВ™ большое ЧСВ. Надо охуенно всем показать, что они такие крутые. К тому же клиентам не всегда нравится надпись на их сайте "Powered by Joomla", например. Клиент же хочет "чистый" сайт за 3 копейки как правило? Ну и получает. Вместо красивого и удобного портала на Друпале или Джумле - кривопузую поделку какого-нибудь Васи Пупкина.

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

Ну тут как раз вопросов меньше всего. Просто договор составляется так, что клиент нанимает МСВ как подрядчика для изготовления сайта, и предоставляет средства производства: сервер и установленное ПО (LAMP + Drupal), а с "некоммерческим использованием" клиент пусть сам разбирается. МСВ берёт бабло за то, что заставляет на этом всём работать клиентский сайт.
Другое дело, что на глагне у клиентского сайта должна появиться надпись "powered by Drupal", и для МСВ и для клиента - это как серпом по яйцам. Для первых это как расписаться в собственно трешовости, а для вторых - "реклама стороннего ресурса", на которую ни один жлоб не пойдёт.

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

+++

1) Друпал распространякется под GPL, то есть не возбраняется ее коммерческое использование, а исходные тексты так и так предоставляются ;)

2) Нет требования обязательного присутствия на глагне бирки "powered by drupal".

Не скажу про аналогичный пункт 2 у джумлы и тюпы - просто не знаю, но пункт 1 у них вроде таков же. А аргумент про ЧСВ - ну не стесняются американские университеты свои сайты на друпале делать, или пепси.ру, например... Но у ж небольшая но очень горда фирма IBM могла бы уж сама для себя ЦМС написать, ан нет, на друпале сайт наваяла ;)

Дпупал - GPL

а кого это ебет? :)

RTFGPL ;) Коммерческое использование разрешено, если ты предоставляешь вместе с продуктом его исходные тексты

я повторяю вопрос: а кого это ебет?

Ну по крайней мере штатным способом удалить бокс powered by drupal можно и разрешено ;)

ненене, Миш, я про ето.

Уже было http://lj.rossia.org/users/boza/199655.html

+++

Про ЧСВ - согласен. Про остальное - ниже.

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

1. Привязать по возможности пользователя к себе (скорее всего специалист, готовый разобраться с внесением необходимых изменений в самописную систему будет стоить дороже, чем тот, кто сделал сайт своего класса 10к школы 349 на одной из широко известных систем).

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

3. Для достаточно требовательных клиентов или собственных суровых принципов может быть слишком много претензий к чужой системе, которые её разработчикам кажутся неважными или вообще "not a bug". С этим я сталкиваюсь постоянно. Это приводит к миллиону заплаток-плагинов и пункту два.

4. Когда в какой-угодно-язычной документации предлагается делать через жопу то, что нужно, её освоение или не освоение не имеет значения. Я не знаю, как с документацией у перечисленных систем, но с противоречивой и неполной (причём поначалу создающей впечатление полной, а потом половина текста оказывается автоматически вставленными шаблонами "Здесь должно быть описание функции XXX") документацией имею дело постоянно.

5. Если есть сотрудники, работающие за зарплату, то когда нет работы, можно "размять" их написанием системы, особенно если они "программисты на PHP", а не "пользователи друпала". Если она делает то, что надо (а легко менять стили, например, не надо), то это доказывает наличие квалификации.

6. Причины могут быть историческими: может, и перешли бы сейчас, но когда начинали, доступные системы были ещё недостаточно хороши. А сейчас переходить — себе дороже.

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

1. Очевидно ;)

2. Есть механизм проверки актуальности и апдейта установленных плагинов. Хочешь - пользуйся, не хочешь - не пользуйся. Но если вдруг выяснится, что найден тупой sql injection, который лечится апдейтом определенной части системы (или плагина) - это одно, а когда тебе надо править код в over 9000 сайтов, настраданной на твоей домотканой ЦМС - это несколько другое.

3. А куда деваться? Проще написать один маленький дополнительный плагин под этого конкретного заказчика. И самому его отслеживать, вместо того, чтобы отслеживать всю тушу домотканой ЦМС.

4. "Дьявол кроется в мелочах". Так и так для саппорта нужны специалисты, разбирающиеся в пыхпыхе и сиквеле. А про документацию у платных систем (того же Битрикса) я без нецензурности вообще говорить не могу.

5. А еще можно копать от забора и до обеда. Или полы в офисе помыть.

6. Лучше перейти сейчас. Потому что это будет дешевле, чем через пару лет, когда это будет еще дороже.

7. ТО есть под каждый заказ доптсывать фунционал? А зачем, если он уже есть готовый?

2. а когда тебе надо править код в
Это может быть проще делать в своей системе, чем в чужой с заплатками и плагинами. Потому что в случае
Хочешь - пользуйся, не хочешь - не пользуйся.
надо плагины переделывать и т.п. С заплатками, естественно, ещё хуже.

3. Речь о заплатках, а не плагинах. И со своей средой (в том числе на случай обновлений) интегрировать их много проще.
Плагины же индивидуальные вызывают сложности типа 2: править миллион плагинов, о которых уже забыл.

5. Можно ещё "совершенствовать навыки работы в PHP", но написание не слишком нужного, но полезного продукта — деятельность, позволяющая проверить, что они именно программировали.

6. Это голословно. Всякое может быть. Если для перехода сейчас надо переводить много сайтов, искать плагины и ставить заплатки — ясно, что даже переход "сейчас" растянется на годы (на каждом из сайтов переход происходит только когда требуется существенная переработка).

7. То есть: под большинство заказов не дописывать ничего, только настраивать. Если заказ сделает Белый дом (США), то можно, конечно, перейти и на Друпал:)

> 7. То есть: под большинство заказов не дописывать ничего, только настраивать. Если заказ сделает Белый дом (США), то можно, конечно, перейти и на Друпал:)

Кстати, о Белом Доме ;) http://lj.rossia.org/users/boza/244620.html

Я был в курсе этого, когда упоминал Белый дом.

Ещё один вариант ответа: жена неожиданно спросила, что это за "друпал", про который пишут неожиданно упавшие сайты:) :) :) (ХА-ХА-ХА)

"Дай дураку хуй стеклянный - он и его разобъет, и руки себе порежет".

Как правило, это проблема не в друпале, а в хостинге.

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

Ещё немного антирекламы Друпала? http://verbit.ru/LJR/romych.txt