В этой статье хочу поговорить об особенностях платформ с открытым исходным кодом, а может и развеять некоторые мифы о них. Обсудим, в каких ситуациях опенсорс подходит крупному и среднему бизнесу для замещения ушедших с рынка инструментов.
Буду говорить применительно к CRM, поскольку в своей работе сконцентрирован на этом классе решений. Но все те же рассуждения можно отнести и к другим энтерпрайз-инструментам.
Прежде чем перейду к сути, небольшая оговорка про импортозамещение.
Поиск замены более недоступному инструменту - действительно весьма распространенная причина внедрения сегодня. Но никакой крупный проект не существует в вакууме. Кроме условия “использовать российское” у бизнеса, а тем более у крупного, всегда есть ряд ограничений и требований, которые приходится учитывать. Поэтому на моей практике, в том числе в последний год, внедрение опенсорса чаще начинается с необходимости удовлетворить бизнес-требованиям, а импортозамещение выступает второстепенным условием. Так что и говорить о проектах будем в комплексе, опираясь на аргументы, которые были и остаются актуальными, вне зависимости от новостной повестки.
Не разработка с нуля и не проприетарный продукт
Начнем с базового позиционирования.
У крупного бизнеса есть три основных варианта развертывания инструментов автоматизации - покупка проприетарного продукта, собственная разработка с нуля или внедрение решения на базе опенсорсной платформы. Отличаются они доступной степенью кастомизации решения под бизнес-процессы, скоростью его поставки и участием собственной или привлеченной на проект команды разработки.
Собственная разработка
Создание инструмента под себя с нуля в идеале позволяет получить ровно ту автоматизацию, которая требуется. Проблема в больших сроках, а также в том, что на старте проекта, помимо опытной команды, компании необходимо иметь видение того, как это должно работать - от высокоуровневого представления до деталей реализации.
Ряд особенностей системы, в частности гибкость, должны закладываться на начальных этапах планирования архитектуры, или впоследствии их нельзя будет реализовать. Каждая такая “особенность” по-своему удорожает разработку, поэтому должна быть экономически обоснованной. Иными словами, проект должен быть основан не только на глубоком понимании текущего положения вещей в бизнесе, но и на представлении о наиболее вероятном пути его развития. При этом учесть все возможные пути тоже нельзя - слишком дорого.
В целом собственная разработка - это высокие требования к команде, большие сроки и стоимость реализации, а также риски, что инструмент так и не будет закончен.
Покупка проприетарного продукта
Покупка проприетарного инструмента - более быстрый способ автоматизировать бизнес-процессы. Но такой продукт имеет ограничения по кастомизации, определяемые архитектурой решения (их задает вендор), поэтому может не соответствовать реальному положению вещей в конкретной компании.
Зачастую эти несоответствия обусловлены как раз особенностями компании - ее ноу-хау. Банк выбирает свой способ скоринга клиентов, страховая по-своему считает риски и т.п. Как подстраиваться под такие ситуации, зависит от особенностей конкретного продукта. Иногда необходимо подстраивать свои бизнес-процессы под инструмент (под best practice, рекомендованные консультантами разработчика). А в каких-то системах может быть предусмотрена настройка таких моментов.
Так или иначе, используя проприетарное решение, базовую функциональность автоматизации можно запустить почти сразу, т.е. риски не получить вообще ничего существенно ниже. Но за лицензии придется заплатить, а в модели абонентской подписки, платить придется регулярно. Любая кастомизация будет оплачиваться отдельно по тарифам вендора или его официального партнера. А реалистичность такой кастомизации зависит от конкретного продукта.
Решение на опенсорс-платформе
Внедрение решения на базе платформы с открытым исходным кодом в определенных ситуациях позволяет оптимизировать затраты и риски. Поскольку в основе - опенсорс, оплата лицензии и привязка к одному поставщику отсутствуют. Но при этом в решении уже есть некий “каркас”, вокруг которого можно строить реализацию индивидуальных потребностей.
В отличие от собственной разработки, не надо продумывать инфраструктуру, модели данных и прочие детали. Не требуется выбирать технологический стек. Бизнес сразу получает инструмент, который можно использовать с первого дня - тайм-ту-маркет сегодня крайне важен. Да, его необходимо настраивать и кастомизировать. Но зачастую реализовать то, что нужно в каждом отдельном случае, на базе опенсорсной платформы легко - здесь много готовых библиотек для всевозможных интеграций и обмена данными внутри инфраструктуры заказчика. Интегрировать их в решение или даже написать собственные расширения может как собственная команда, так и внешний интегратор.
Мне в опенсорсе нравится гибкость с точки зрения сроков внедрения. Когда мы запускали CRM в стартапе, базовые необходимые задачи (звонки, продукты, интеграцию с веб-мастерами) сделали примерно за месяц. Это ровно тот срок, который был им необходим для найма людей, их обучения и т.д. То есть стартап сразу запустился с CRM. Но конечно же, инструмент потом дорабатывали под изменения и рост компании. А в банке мы честно дорабатывали систему по объемному ТЗ около 6 месяцев, и это не считая долгой отладки интеграций и загрузки начальных данных.
В целом для самописного ПО такие сроки нереальны. А при настройке закрытого проприетарного продукта нельзя было бы настолько гибко управлять требованиями.
Далее я остановлюсь на некоторых особенностях опенсорса, которые стоит учитывать при выборе одного из трех описанных подходов. Плюс это или минус - зачастую зависит от конкретного проекта.
С опенсорсом возможна глубокая кастомизацию под задачу
Как я отметил выше, опенсорсную платформу - ту же CRM - можно взять и использовать как есть. В базовой версии SuiteCRM будут клиенты, отчеты, процессы, звонки, встречи, календарь и т.д. Некоторым компаниям этого достаточно. Например, если стоит задача запустить отдел продаж, но процессы еще не выстроены, поэтому непонятно, как именно все должно работать.
Но запуски с нуля на моей практике встречаются редко. Более типичная ситуация - кастомизация, когда у крупного и среднего бизнеса есть устоявшиеся процессы, которые сложно или невозможно поменять. Как правило, в опенсорсе можно многое изменить через конфигурирование и внешние библиотеки - сделать другой интерфейс, настроить интеграции со сторонними продуктами и т.п. Если этой гибкости недостаточно, можно доработать под конкретную задачу сами модули платформы - ведь код открыт и вполне доступен. Этим инструмент на базе опенсорс-платформы принципиально отличается от проприетарного.
Распространенный сценарий, когда кастомизация требуется не сегодня, а когда-нибудь в будущем. Это как в примере с запуском отдела продаж - базовые “хотелки” для CRM есть и сегодня, в принципе им удовлетворяет широкий круг решений. Взять проприетарное решение можно достаточно быстро (иногда просто по клику на сайте - в аренду). Однако непонятно, когда бизнес упрется в ограничения тарифа или коммерческого продукта в целом, которые окажутся для него критичными.
Даже предвидя ограничения, писать с нуля на этой стадии - явно не вариант. А вот опенсорс с готовыми 30-40 модулями - отличный выбор. Срок запуска - минимальный: несколько дней на установку, импорт начальных данных и обучение. Дальше можно поработать квартал или полгода, собрать обратную связь от пользователей. Поняв, чего не хватает, можно спокойно доработать систему под себя.
В нашей практике встречались даже запросы на доработки на уровне архитектуры (из-за требований службы безопасности заказчика). Было и перестроение логики системы. Например, для подразделения крупного международного консалтингового агентства в сфере бизнес-недвижимости мы совмещали в одной CRM несколько разных воронок продаж, у каждой из которых своя логика расчета маржинальности (причем, еще и с учетом мультивалютности). Эти доработки заняли у нас около 5 месяцев. Но с клиентом продолжаем работать уже почти 7 лет - автоматизируем новые процессы, поддерживаем изменения в бизнесе и т.п.
С опенсорсом такое вполне реально. Конечно, чем масштабнее доработки, тем дороже они будут стоить. Но о затратах нужно говорить отдельно.
Опенсорс - не бесплатно и не всегда дешевле проприетарного продукта
Не все понимают, что продукт с открытым исходным кодом - это не про бесплатный сыр. Но если не говорить об экзотике, вероятнее всего внедрить его будет дешевле, чем поставить сторонний продукт или разработать свое.
Стоимость проприетарного инструмента для крупного бизнеса складывается из трех компонент:
Лицензии. Оплачиваются единоразово или за период, проект внедрения - поэтапно. В случае крупного бизнеса это сотни тысяч долларов в год.
Проекта внедрения. Его стоимость закладывается в смете.
Поддержки. В определенном объеме она может закладываться в лицензионные платежи. Сверх этого объема обычно включается почасовая ставка, размер который определяется или согласуется с вендором (обычно она заметно выше стоимости часа работы среднего разработчика с рынка труда).
Для собственной разработки лицензионные платежи отсутствуют. Но нужно полностью оплачивать создание самого инструмента - содержать внутреннюю или внешнюю команду, которая будет проектировать архитектуру и писать код. Проект внедрения при этом никто не отменял - изменение привычных процессов (или выстраивание их с нуля) будет стоить бизнесу денег. После завершения активной фазы разработки часть команды придется оставить для сопровождения решения и внутренней технической поддержки. Отдельная сложность при этом - сохранить в компании компетенции, достаточные для дальнейшего развития системы (чтобы вместе со специалистами не ушли и ценные знания).
Час работы специалиста в этом случае, возможно, обойдется дешевле, чем при оплате партнеру вендора, но будет много сопутствующих расходов (помещение для поддержки, оснащение их рабочих мест и т.п.).
Как и результат собственной разработки, инструмент на базе платформы с открытым исходным кодом избавляет от лицензионных платежей. Для некоторых платформ есть лицензионные ограничения, связанные с тем, что любые доработки необходимо выкладывать в открытый доступ. Но это не финансовая история.
Стоимость проекта внедрения неоднозначна. В зависимости от потребностей бизнеса она может оказаться как дешевле, так и дороже проприетарного инструмента. Как правило, вариант “дороже” как раз подразумевает внесение экзотических изменений (иначе выгоднее действительно внедрить продукт от вендора). В этом случае важно то, насколько эти изменения критичны для бизнеса.
Последующая поддержка определяется стоимостью работы разработчиков. Стоимость часа специалиста, работающего с опенсорсной платформой, может быть в 1,5 - 2 раза ниже ставки разработчика под дорогие проприетарные системы. Но объем трудозатрат зависит от проекта.
В сухом остатке - за опенсорс придется в любом случае заплатить. Как я отмечал выше, весьма вероятно, что проект окажется дешевле, чем внедрение проприетарного решения. Но в общем случае это не гарантировано.
Опенсорс вполне безопасен, если грамотно выбирать платформу
Согласно распространенному мифу проприетарное решение от вендора безопаснее опенсорса. Но на мой взгляд это вопрос, требующий обсуждения.
Когда исходные коды открыты, любой может взять и проанализировать их на предмет закладок. В случае с некой редко используемой библиотекой риски что-то обнаружить действительно существуют. Но если на базе опенсорсной платформы развивается целая экосистема продуктов и интеграторов, им невыгодно допускать подобное. Невыгодно это и сообществу, которое отвечает за развитие платформы, потому что любая найденная закладка нивелирует их работу по популяризации инструмента. А шансов, что ее найдут, довольно много - анализ безопасности опенсорсных продуктов хоть и трудоемок, но лежит на поверхности.
В то же время от закладок в закрытых решениях никто не застрахован. Не имея возможности проанализировать исходники, вы никогда не заметите признаков их активности, пока они не сработают. Гарантом для клиента является “доброе имя” вендора или сертификация, если вендор прошел эту процедуру. Но далеко не все инструменты для крупного бизнеса сертифицированы.
Так или иначе, если для решения вопросов безопасности с опенсорсом и продуктом собственной разработки можно что-то сделать собственными силами, то с проприетарным инструментом все в руках производителя. И не только в вопросе безопасности.
Опенсорс исключает блокировку на вендоре и подрядчике, но не дает гарантий развития
Крупному бизнесу сложно менять используемые продукты и партнеров по разработке.
Если однажды был внедрен тот же Microsoft или Oracle, компания долгое время платит за лицензии и поддержку, даже если цена удваивается. Вероятно, это дешевле, чем инициировать новое внедрение.
При использовании проприетарного решения перейти на инструмент от другого вендора - значит выкинуть существующее и начать все заново. Сменить интегратора, не меняя базового продукта, проще. Но это никак не изменит стоимость лицензий (а иногда и стоимость часа поддержки, поскольку партнерская сеть может работать по единым тарифам).
С инструментом на базе платформы с открытым исходным кодом все свободнее. Оплаты за лицензию нет, поэтому ситуации, когда вендор внезапно решил кратно поднять стоимость, быть не может. Доработки и поддержка со стороны интегратора могут вырасти в цене. Но для заказчика ситуация не будет безвыходной - с популярными платформами для бизнеса работает множество интеграторов и нет никакой единой ценовой политики (как нет одного вендора, который бы ее определял).
Например, с SuiteCRM работают как крупные компании с именем, внедряющие десятки разных решений, так и небольшие разработчики, которые фокусируются на этой платформе и готовы взяться за ту же задачу дешевле. Есть и фрилансеры, готовые работать за минимальный гонорар. Выбор между этими вариантами - это уже вопрос предпочтений заказчика.
Сравнивая опенсорс с собственной разработкой, сложно объективно оценить деньги, но можно поговорить о рисках.
При разработке собственной платформы с нуля заказчик очень зависит от подрядчика и его команды (или собственной команды, если все происходит инхаус) - какой на проекте будет архитектор, насколько глубоко он продумает систему с точки зрения нагрузок, безопасности и прочих требований. Если по каким-то причинам этот человек с проекта уйдет, придерживаться стандартов качества уже не получится. А если уйдет вся команда, проект попросту встанет. Даже при наличии подробной документации срок введения в курс дела новой команды начинается от нескольких месяцев.
Опенсорс в этом смысле проще. Поскольку все множество подрядчиков, о которых я говорил выше, работают в одной парадигме, они в курсе базовых возможностей платформы и могут войти на проект гораздо быстрее. И у большинства есть опыт включения во внедрения за коллегами по рынку - смена поставщика услуг в этом мире не такая уж редкая ситуация. Так что риск заказчика остаться вообще ни с чем существенно ниже.
У любого преимущества есть обратная сторона. В данном случае отсутствие одного производителя или команды, отвечающей за развитие, - это отсутствие гарантии уверенного развития продукта определенным курсом в течение длительного времени.
Крупные вендоры регулярно выпускают обновления продукта, патчи безопасности, да и в целом имеют понятную стратегию. В лицензионных договорах как правило прописаны обязательства по поддержке решений в течение определенного времени.
У опенсорсного решения не обязательно есть вендор. Иногда за платформу в основе несет ответственность только некоммерческое сообщество, которое может прекратить свое существование или сменить вектор развития. А даже если вендор есть, он не связан с заказчиками договорными обязательствами. Единственная гарантия для клиента - искать зрелые опенсорсные решения, которые существуют годами, курируются большими сообществами и поддерживаются в том числе коммерческими организациями. Linux - отличный пример. Практика показывает, что если вокруг опенсорсной платформы формируется целое сообщество компаний, которые ее внедряют и кастомизируют, вероятность, что она развивается в ногу со временем, достаточно высока.
Вместо итогов
Лично я работаю с внедрением опенсорсной CRM уже 14 лет. Опыт показывает, что платформа с открытым исходным кодом может быть достойной альтернативой проприетарному продукту или собственной разработке. Но на старте важно учитывать особенности этого типа решений - в первую очередь считать деньги, понимая, что все это не бесплатно.
Для крупного и среднего заказчика опенсорсный и проприетарный продукты (если они оба соответствуют проектным требованиям) будут выглядеть одинаково. В обоих случаях контактировать заказчик будет с некой компанией, которая предлагает продукт, проект внедрения и последующую поддержку. Разница лишь в деталях исполнения. А поэтому в большей степени важны характеристики интегратора, его заинтересованность в доработках.
Автор: Луневский Дмитрий, директор по развитию компании Куб3
Комментарии (19)
s_ulimov
16.04.2023 16:10+4Вы привели очень хороший пример с SuiteCRM (форк SugarCRM), но в статье очень не хватает довольно важного уточнения, что Open Source не тоже самое, что и Free Software (которое иногда трактуется как бесплатное ПО). И хотя термины Открытое ПО и Свободное ПО часто используются как синонимы, но именно из-за этого непонимания могут возникать серьезное сложности и разочарования.
PereslavlFoto
16.04.2023 16:10Бесплатное ПО — это когда клиент бесплатно получает двоичные файлы.
Открытое ПО — это когда клиент бесплатно получает исходники с двоичными файлами.
Свободное ПО — это когда клиент бесплатно получает исходники с двоичными файлами и может улучшить эти исходники.
mvv-rus
16.04.2023 16:10Нет, отнюдь. "Свободное ПО" это когда клиент получает доступ к исходникам, может менять и даже совершенствовать их, но не имеет право делать на их основе тиражируемый программный продукт, который можно продавать. Классическая лицензия "свободного ПО" — GPL.
А открытое ПО (классическая лицензия его — BSD) позволяет использовать полученный исходный код, как угодно, лишь бы было указано его авторство. В том числе — и для разработки комерческого тиражируемого программного продукта.PereslavlFoto
16.04.2023 16:10Множество коммерческих программ доступны по GPL и вы можете их продавать. Не вижу тут никаких препятствий.
mvv-rus
16.04.2023 16:10Вы читали невнимательно. Я писал не про просто «коммерческие программы», а про тиражируемые программные продукты: те, которые можно использовать «как есть» — в виде двоичных исполняемых файлов и без необходимости помощи со стороны производителя. Поскольку тиражируемые программные продукты легко копировать, то производитель, чтобы не потерять доходы, по чисто экономическим причинам блокировал доступ к исходному коду тиражируемых программ.
И движение за «свободное ПО» было как раз ответом на эту политику производителей тиражируемых программных продуктов.
PS Русская Википедия, кстати, в целом, согласна с моим использование терминологии, касающейся открытого и свободного ПО.PereslavlFoto
16.04.2023 16:10И движение за «свободное ПО» было как раз ответом на эту политику производителей тиражируемых программных продуктов.
Движение за свободное ПО привело к тому, что производители стали выпускать тиражи коммерческих программных продуктов под свободной лицензией, когда узнали, что свободная лицензия не запрещает им продавать ПО.mvv-rus
16.04.2023 16:10Производитель, разумеется, волен распоряжаться своим продуктом любым образом. Но когда в отношении "свободного ПО" используется слово "производитель", в этом есть некое лукавство: в идеологии "свободного ПО", в ее исходном виде (типа как у Реймонда в "Соборе и базаре"), вообще не просматривается такого субъекта, как производитель, а ПО полагается продуктом деятельности некоего достаточно аморфного сообщества сообщества. А такое сообщество, в силу своей аморфности, не в состоянии обладать исключительным правом, необходимым для выпуска продукта под другой лицензией.
Что до реальности, в которой производители таки есть, то можно было бы, конечно, поговорить за экономику процесса, как она в вашем преставлении такая удивительная получается, но здесь и сейчас я этот разговор заводить не хочу. Это — тема для очень большого и совсем другого разговора. По-хорошему тут нужна, как минимум, одна статья, как эта экономика выглядела на разных этапах развития. Этих этапов я вижу, как минимум, три. И тиражируемые программный продукты — были основой экономики второго этапа, а не нынешнего. Ибо на нынешнем этапе основные деньги делаются на предоставлении услуг (как правило — централизованном), а не ПО.
В этой же ветки комментариев моей целью яыляется исключительно "исправление имен". А именно, явно указать на то, что прилагательное "свободное" в отношении ПО по факту накладывает дополнительные ограничения на его использование по сравненю с использованием открытого ПО — т.е. доступного всем и для любых целей. То есть — является не на самом деле не тем, чем кажется, как и многое из того, что содержит в своем названии слова "свобода" или "свободный". Если у вас есть возражения именно поэтому пункту, то дискуссию имеет смысл продолжить, иначе ее стоит закончить.
PereslavlFoto
16.04.2023 16:10Экономика процесса состоит в том, сначала производитель сам оплачивает свою работу, а затем потребители сами оплачивают работу производителя в той степени, в какой могут это сделать.
открытого ПО — т.е. доступного всем и для любых целей.
Это и есть свободное ПО, которое можно свободно использовать для любых целей.
А открытое, это когда можно получить исходники, даже если нельзя их использовать.mvv-rus
16.04.2023 16:10Экономика процесса состоит в том, сначала производитель сам оплачивает свою работу, а затем потребители сами оплачивают работу производителя в той степени, в какой могут это сделать.
Вы мне тут про какой-то коммунизм рассказываете, который с сознательными производителями и потребителями, работающими ради общего блага.
Но мы-то живем в царстве бездушного чистогана, капитализмом именуемым (и на то есть серьезные причины). И в этом царстве сознательность в сколь-нибудь существенных для экономики масштабах не работает. Чисто потому, что в царстве бездушнуго чистогана каждый работает на свое собственное благо. И потому в масштабах экономики потребитель в среднем предпочтет взять себе чужой продукт за минимально доступную ему цену. То есть, потребители в нашем царстве бездушного чистогана оплачивают работу производителя в той степени, в какой они вынуждены это делать.
Реальные работающие механизмы оплаты — они разные на разных стадиях развития ПО, и не всегда это — плата непосредственно за копию ПО. Но про эти подробности я здесь говорить не хочу (как я писал, для этого нужна полноценная статья).
А вот про что хочу все же сказать — это то, что вы демонстрируете ложный, неработающий почти никогда механизм компенсации издержек на разработку ПО. А вот почему вы это делаете — добросовестно ли заблуждаясь или из корысти какой — мне это не ведомо и, в общем-то, не интересно.
И да, Эрик Реймонд в своей классической работе «Собор и базар» рассматривал совсем не тот механизм, который вы тут декларируете — он как-то ближе был к реальной жизни.Это и есть свободное ПО, которое можно свободно использовать для любых целей.
Теоретически, если исходить из значения слова — да. К сожалению, на практике, как это часто бывает со словом «свободный», название «свободное ПО» («free software») присвоили сторонники другого, не столь свободного подхода: запрета использования «свободного ПО» как основы для разработок с закрытыми исходными текстами: всяческие FSF (Free Software Foundation), GNU с ее GPL и прочие идеологические последователи Столлмена. Поэтому для обозначения ПО, исходные тексты которого можно использовать действительно для любых целей (типа выпущенных под лицензией BSD) приходится использовать другое слово. Не знаю, как там американцы с этим обходятся, но в русском языке издавна используется слово «открытое ПО» (если чо — я это слово в середине 90-х годов слышал и в печати компьютерной видел именно по отношению BSD-версиям Юникса и т.п.)
Так что в этом вопросе явно требется то, что кто-то из древних китайцев (Конфуций, вроде бы) называл «исправлением имён».
Впрочем, конкретно в случае импортозамещения в России сейчас этой разницей можно пренебречь: вряд ли американский FSF сможет засудить хоть какую-нибудь российскую фирму и наказать ее на деньги.
Поэтому при обсуждении данной конкретной статьи такими тонкостями можно не заморачиваться — что автор, в общем-то, и сделал, и был прав.
grumbler70
16.04.2023 16:10Стоимость часа специалиста, работающего с опенсорсной платформой, может быть в 1,5 - 2 раза ниже ставки разработчика под дорогие проприетарные системы
Не всегда так, иногда может быть наоборот. Под какую-нибудь экзотику "зато с бесплатными исходниками" разраб вполне может влететь в копеечку.
DmitryLunevsky Автор
16.04.2023 16:10Да, конечно. Но, согласитесь, под "закрытую экзотику" тоже ценник будет огого!
Плюс от компании зависит (много дополнительных костов), от опыта разработчиков, от стека. Это скорее оценка в стиле "температура по больнице".
Pastoral
16.04.2023 16:10+2Лукавый выбор из трёх вариантов предложен. А на самом деле нужно сделать выбор из двух вариантов, но до трёх раз.
Проприетарный продукт или собственная разработка? В первом случае избавляемся от ответственности, во втором - имеем гешефт. Если таки разработка…
Разработка с нуля или опенсорс? В первом случае ниже порог входа, не нужно иметь уметь читать код. Во втором - меньше работы, но и меньше денег за неё. Если таки опенсорс…
Тёмный эльф или светлый, в смысле только берём или участвуем? Первое, на мой взгляд, как-то более скрепно, второе - либо дураками выглядеть, либо авторитет иметь, а проблем с опенсорс, типа (направления) развития - не иметь.
DmitryLunevsky Автор
16.04.2023 16:10Но ведь опенсорс (в смысле автоматизация на базе оперсорс платформ) не всегда равно разработка ?!
Когда мы начинали у нас были мелкие клиенты и им вполне хватало базовой CRM платформы и пары дней настройки.
Сейчас эти платформы активно развиваются и много чего можно сделать без разработки, тот же Odoo, Alfresco, Asterisk.
При этом проект на проприетарном продукте вполне может содержать огромный блок разработки, десятки человеко-лет. Посмотрите какие-нибудь решения на MS CRM в крупных компаниях.
PereslavlFoto
16.04.2023 16:10Как же так получается у многих людей и предприятий, чтобы пользоваться Open Source программами и взамен ничего не платить?
cema93
16.04.2023 16:10+2Могу рассказать на своём примере, когда-то давно работал в маленькой фирме сисадмином(отвечал за всё что связано с ПК, серверами софтом и т.д.), фирма около 20 человек. Как сейчас модно говорить "внедряли" CRM, а по факту нашли пару зрелых опенсорсных проектов, развернули, посмотрели что максимально подходит по функционалу и и выбрали. CRM полностью покрывала все хотелки путём настройки через админку без написания кода. Вот и получили CRM с всеми хотелками стоимостью работы в пару дней работы нескольких штатных сотрудников.
DmitryLunevsky Автор
16.04.2023 16:10Так и отлично. Я про это и стараюсь говорить. Смотрите уважаемые клиенты шире, есть отличные опенсорс продукты, которые вам вполне могут подойти практически как есть.
Это просто наш опыт для средних+крупных компаний показывает, что нужны доработки. Для небольших компаний вполне могут платформы as is использоваться. А потом, по мере роста, развивать систему.
leha_gorbunov
16.04.2023 16:10Только вот Open Source не появится вдруг из ничего. Скорее всего это какая-то компания делает под себя решение "с нуля", а потом его выкладывает как Open Source. Тем более такие решение как CRM и ERP без требований бизнеса не родятся, ну или останутся на стадии pet-проекта. Так, что где-то глубоко вначале любого open source лежит что-то написанное под конкретного заказчика. Как-то в отдельные пункты Собственная разработка и Open Source не очень по моему субъективному мнению разные стадии одного и того же.
DikSoft
Это, насколько я помню, первая статья на Хабре, где реалистично и взвешенно перечислены как плюсы, так и реальные минусы Open Source. Спасибо. Хоть кто-то реальную картину описал.