В ответ на: к примеру масштабируемость заложенная на начальном этапе позволит добавлять функции не переписывая доброй части имеющегося кода, закрытые системы имеют возможность подключения сторонних модулей, АПИ и т.п.
А у открытых вроде как АПИ не бывает в силу чего? =)
В ответ на: этого мало, как правило нового разработчика не устраивает то как спроектирована система.
Ну мне тоже не нравится многое =) А что, у закрытых систем нет таких недостатков?
Если подразумевать что "бесплатно - это открытый код", а "платно - закрытая система", то по существу ничем они не отличаются, просто открытые ситемы более гибки для адаптации. И у открытых систем есть платная поддержка, можете выбирать даже из нескольких саппортов, в отличие от закрытых.
В общем случае тезис "бесплатно=открыто" и "платно=закрыто" некорректен в утверждении "бесплатно - поддерживай сам, платно - поддерживают другие". Собственно возьмем, например, FreeBSD - открытая система, ее разве никто не поддерживает? Поддерживают, за деньги, много кто. А вот в этом ключе рассматривать например тот же самый мелкософт - _никогда_, еще раз повторю, _никогда_ на все мои запросы исправления _моего_ конкретного бага их продукта _никогда_ мне саппорт не помогал, а кроме оригинального саппорта это никто не мог сделать (что логично).
Возьмем, например, CMS A (opensource) vs CMS B.
Если вы, как окнечный потребитель (архитектор, базирующийся на основе этой CMS) выбираете то, счто вам не нравится как спроектированно - откровенно говоря это неумный мазохизм, поэтому считаем что и система А, и система В не вызывают органического оттторжения у вас. И у той, и у другой системы существую АПИ, возможность подключения дополнительных модулей примерно одинаково (ибо одноклассники, реализуют по существу один и тот же функционал), но в обоих нет, скажем, определнного эвента - предположим, что это будет эвент посещения определенной страницы проекта. Как вы их будете добавлять?
В случае с системой-А вы можете либо перелопатить исходники (при нормальном документировании это не сложно), исправить код, сгенерировать дифф-патч (именно таким путем достигается нормальный оптимальный учет изменений в продакшн-коде), либо извращаясь через данное вам от майнтейнера АПИ получить свою функцию (как следствие - вероятно это будет неэффективная реализация скорее всего - имхо). И именно за этот труд вы можете получить деньги с клиента. И при условии, что вы не первый раз сталкиваетесь с этой CMS это не занимает много времени.
Кстати, если уж полученный вами патч действительно востребован, то ничто не мешает вам за него получить деньги еще раз, с другого клиента, или жестом доброй воли отправить патч разработчику CMS - шансы, что в следующем релизе он появится близки к 100%.
В случае с системой В вы имеете только второй вариант, то есть известить разработчика, выполнить неэффективное чаще всего решение (извращения через АПИ чаще более затратны с точки зрения времени программиста - это мой скромный опыт) и продадите его по той же цене клиенту, и/или, возможно (а может быть и нет, если функция непопулярна была), через полгода/год вы получите встроенную функцию, которую потом продадите клиенту (не факт что дешевле - greece рулит миром =) ). Я конечно понимаю что так проще, но является ли это преймуществом закрытых систем?
Спор собственно начался с того, что конечная продакшн-эксплуатация открытых систем (объявленных в рамках данного топика бесплатными) более затратна, чем закрытых, и это утвердение еще никто не подтвердил никакими конкретными именованными расчетами, кроме имха =)
В итоге, нормальную CMS выходит обслуживать по стоимости столько же, если речь идет об "излишиствах нехороших", но при всех равных открытые системе гибче и для конечного потребителя проекта быстрее-реализуемей, если конечно проект реализуется не "кодером-самоучкой" а нормальным грамотным архитектором.
