Крупные информационные порталы: почему они все самописные?

Тут уже отката 50% походу вложено.

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

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

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

Я думал, что гибкость коробочных вариантов отточена годами их использования на разных проектах...

100 тыс - это в какой валюте?

Почему это бред? Senior Java Developer - 3500 - 4000 долларов с учетом налогов например. Где здесь бредовые цифры?

Именно поэтому любые коробочные варианты и становятся негибкими - стремятся угодить и вашим и нашим, находя некую середину. Это неплохо, но середина - это для крепких середняков

Не в рублях :)

Много очень холиварных моментов.

От себя дополню вот такими замечаниями:

1. Заказывая собственную разработку, чаще всего проще решаются вопросы с правами на продукт (авторские, смежные, эксклюзивные, неэксклюзивные - все можно грамотно в договоре предусмотреть). Продавая один движок во много рук, все права каждому не передашь.

2. Следствие п. 1 - продукт может быть поставлен на учет, как нематериальный актив. И эти миллионы рублей - не расход! Такой продукт увеличивает капитализацию компании. В дальнейшем такой продукт может быть сравнительно легко продан правообладателем, заложен в банке, сдан в аренду и т.д.

Часто не до конца понимают различия между "тупым распилом" и увеличением капитализации - цели у них, все же, разные.

Ага, очень интересно!

Здесь вопрос следующий: мы же хотим разрабатывать порталы под заказ. Как Вы считаете, пойдет ли заказчик на то, чтобы нам пренадлежали права на движок и исходный код не делить с заказчиком? А заказчику, в свою очередь, права на конечный портал (без исходного кода), его наполнение и т.п.?

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

Здесь вы можете пойти по политике лицензирования (но это уже не заказная разработка). Т.е. Вы разработали некий коробочный продукт, или платформу. Тогда вы сможете зарабатывать на трех направлениях:

а) Продажа лицензий;

б) Интеграция продукта в инфраструктуру заказчика (включая дополнительные работы по добавлению новой функциональности);

в) Платный саппорт.

Из этого лицензии, при определенных условиях (не всегда), могут быть поставлены на учет как нематериальный актив и увеличат капитализацию компании. Иногда работы по интеграции, если они формируют цельный продукт тоже могут формировать актив. А остальные затраты заказчика = прямые расходы.

Кроме того, убедить заказчика на такую схему тоже не просто:

- надо неплохо раскрутить свой бренд;

- лицензия должна позволять заказчику вносить изменения в исходный код;

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

Здесь нужно совсем иначе позиционировать компанию и ее услуги на рынке.

Пробуйте. Вот Вам примеры: Микрософт, Оракл, SAP и тысячи других используют подобный подход. Да взять ту же 1С или Битрикс.