Открытый код в бизнесе

Если выбирают правильную модель монетизации и внимательно работают с сообществом.

5142 просмотров

Open Source Software (OSS) — программное обеспечение с открытым исходным кодом. Этот код можно копировать, изменять, создавать на его основе собственные программы. Главная особенность такого ПО — любой желающий может увидеть, какие технологии у него «под капотом», как развивается Open Source-проект и даже поучаствовать в его развитии.

То, что код общедоступен, не значит, что на нем нельзя заработать. Есть множество компаний, которые строят свой бизнес на основе OSS; некоторые из них входят в число крупнейших разработчиков ПО в мире, зарабатывают сотни миллионов долларов в год, а стоят — миллиарды.

На основе данных Companies Market Cap, Bloomberg и LATKA. Информация актуальна на август 2022.

У этих компаний три общих черты:

1. Они предлагают продукты, которые востребованы у широкого сообщества разработчиков и инженеров.
2. Работают в сфере разработки ПО с финансовым потенциалом в 1 трлн долларов (что в несколько раз больше, чем, например, оценочная стоимость мировой игровой индустрии).
3. Выбирают правильную модель монетизации.

У третьего пункта решающая роль: бизнес-модель или комбинация нескольких моделей определяет коммерческий успех Open Source-компании.

Он вам не Open Source / Тайная империя свободного ПО

Популярные бизнес-модели

Самые распространенные модели монетизации продуктов с открытым кодом — Open Core (открытый основной код), хостинг (облачный сервис), профессиональные услуги и маркетплейс.

Open Core — модель монетизации ПО, при которой основной (core) код продукта открыт для всех. Любой может бесплатно скачать код или готовую к использованию сборку и применять по своему усмотрению. Любой может даже потенциально влиять на развитие продукта — если предлагаемые изменения в код примут основные разработчики.

Обычно, чтобы зарабатывать на Open Core, компания продает Enterprise- или Premium-версию продукта, в основе которого — общедоступный основной код. В Enterprise-версию могут добавлять, например, техподдержку, продвинутые функции безопасности, повышенную доступность, различные варианты интеграции со сторонним ПО, соответствие отраслевым и другим специфическим требованиям — например, стандарту FIPS 140-2 или системе сертификации СЗИ ФСТЭК.

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

Примеры компаний, которые используют Open Core:

• MongoDB. Разрабатывает одноименную систему управления базами данных (СУБД) типа NoSQL. Согласно исследованию Stack Overflow Developer Survey 2022, это четвертая по популярности СУБД среди разработчиков. Бесплатно доступна локальная инсталляция — MongoDB Community Server. Есть несколько платных вариантов (например, MongoDB Enterprise Server).
• Confluent. Создает решения для автоматизации работы с большими данными в реальном времени. В основе продуктов — сторонний проект с открытым кодом: распределенная стриминговая платформа Apache Kafka. Поверх нее компания бесплатно предлагает дополнительные функции в рамках Community-лицензии. Под коммерческой лицензией распространяется решение Confluent Platform.
• Elastic. Предлагает инструменты для логирования, поиска, безопасности и аналитики. Основной продукт — поисковая система Elasticsearch с двойным лицензированием, основанная на свободной библиотеке Apache Lucene. Бесплатно можно использовать Open Source-версию Elastic Stack. Есть три варианта платной подписки.

Хостинг (облачные решения)

В чем смысл open source?

Ряд компаний предлагает Open Source-продукты в виде управляемых облачных сервисов, или хостинга. Главный плюс для пользователей: не нужно думать об инфраструктуре, в которой запускается продукт, — ее поддерживает компания-разработчик.

Один из минусов хостинг-модели для самой Open Source-компании — конкуренция со стороны крупных провайдеров публичных облаков типа AWS, Azure и GCP.

Провайдеры предлагают Open Source-продукты в своих облаках. Клиентам, которые уже пользуются таким облаком, удобнее подключить дополнительную услугу здесь же, у провайдера, а не обращаться к компании-разработчику. Поэтому, чтобы защитить свои коммерческие интересы, Open Source-компании иногда меняют тип лицензирования продуктов — на такой, который запрещает продавать их ПО как услугу без лицензионных отчислений. Лицензии на свои решения с открытым кодом меняли, например, Elastic, MongoDB, CockroachDB.

Помимо уже упомянутых в прошлой категории Elastic и MongoDB хостинг-модель также используют:

• Databricks. Разрабатывает облачную lakehouse-платформу для работы с полуструктурированными данными. В её основе — Open Source-фреймворк Apache Spark. Компания предлагает бесплатную версию платформы Databricks Community Edition и коммерческий сервис у крупных облачных провайдеров.
• WP Engine. Предоставляет облачную WordPress-платформу. В бесплатной версии WP Engine есть ограничения: нельзя, например, использовать собственные темы, загружать плагины, запускать свою рекламу, подключать Google Analytics. Эти и другие опции доступны в бизнес-тарифах WP Engine.

Профессиональные услуги

Если компания продает расширенную техническую поддержку своего Open Source-решения, консультирует и обучает работе с ним, она использует бизнес-модель professional services («профессиональные услуги»).

Нередко professional services — это дополнительный источник дохода к заработку на подписке (Open Core). Так работают, например, HashiCorp, MongoDB, Confluent.

Red Hat — самая известная Open Source-компания, которая начинала с модели professional services. Со временем Red Hat включила поддержку в поставку своих продуктов и сфокусировалась на Open Core. Это, кстати, вообще самая успешная из всех Open Source-компаний: она первой вышла на IPO (еще в 1999-м) и первой заработала $1 млрд (в 2012-м). Однако в 2019 году Red Hat стала частью IBM.

Другие компании, которые используют модель professional services:

• Cloudera. Разрабатывает дистрибутивы на основе фреймворка Apache Hadoop. Фреймворк используют для создания распределенных поисковых систем, ориентированных на работу с большими данными. Cloudera предлагает платные поддержку, тренинги и другие профессиональные услуги, но также и продукты — то есть использует гибридную модель.
• Percona. Начинала с профессиональной поддержки MySQL. Позже компания стала разрабатывать и собственные решения на основе этой и ряда других БД с открытым кодом.
• Data Egret. Специализируется на поддержке популярной СУБД PostgreSQL.

Маркетплейс

Магазин Android-приложений — типичный пример маркетплейса на основе Open Source-решения, то есть операционной системы с открытым кодом. Такой маркетплейс предлагает платное и бесплатное ПО для Android-смартфонов, а зарабатывает на комиссии, которую платит разработчик ПО. Из популярных маркетплейсов для Android и ее производных — Google Play, Samsung Galaxy Store, Huawei AppGallery.

Сам Android можно назвать примером Open Core для Google и не только. У операционной системы существует проект Android Open Source Project, который разрабатывается как Open Source. К этой базе различные производители устройств добавляют свои дополнения и «надстройки». Так Open Source превращается в коммерческий продукт и монетизируется.

Как компании выбирают бизнес-модели

Если очень упрощенно, процесс коммерциализации Open Source-компании состоит из двух этапов:

1. разработки продукта с открытым кодом, вокруг которого будет строиться бизнес, или выбора готового OSS;
2. монетизации Open Source-продукта с помощью одной или нескольких бизнес-моделей.

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

Как видно, базовым продуктом может быть:

• своя разработка — собственный Open Source-проект «с нуля»;
• готовый проект — существующий Open Source-проект, который компания берет без изменений;
• форк — ответвление от готового Open Source-проекта, на основе которого создается собственный.

К примеру, HashiCorp разработала несколько Open Source-решений для автоматизации работы с мультиоблачной инфраструктурой. Самые успешные продукты компании — IaC-платформа для управления инфраструктурой Terraform и менеджер секретов Vault. Эти и другие её решения доступны по подписке (Open Core-модель) и в облаке (хостинг). Также HashiCorp предлагает расширенную поддержку и обучение (профессиональные услуги).

Пример компании, которая взяла за основу готовый проект, — Cloudera. Она предлагает платные поддержку, тренинги и другие профессиональные услуги, но также и продукты. То есть компания применяет гибридную модель: Open Core + профессиональные услуги.

Гибридный подход также использует, например, MongoDB: компания развивает сразу и Open Core-, и хостинг-модели, то есть продает on-premises и облачные инсталляции своей базы данных. Та же история — у Elastic и Confluent.

Многие компании переходят на гибридный вариант постепенно: начинают с одной модели, достигают относительного успеха, а потом добавляют что-то еще. Так, например, было у Red Hat и Percona, которые начинали с профессиональных услуг, а потом добавили и Open Core.

Можно привести в пример и «Флант»: мы начинали как сервисная компания, а теперь, кроме этого, у нас есть собственные продукты. Например, Kubernetes-платформа Deckhouse, в которую мы вложили лучшие практики эксплуатации Kubernetes и собственные Open Source-наработки. То есть Deckhouse монетизируется по Open Core-модели с подпиской за поддержку. Также на базе этой платформы мы предоставляем услугу managed Kubernetes — и это уже модель professional services.

Какая модель выгоднее

По мнению британского разработчика и инвестора Имрана Гори, из всех четырех моделей Open Core — наиболее прибыльна. Она устойчива и хорошо масштабируется. На последнем месте по маржинальности — professional services; по этому поводу Гори замечает, что доходы от профессиональных услуг часто непредсказуемы и требуют расширения численности персонала — это может привести к тому, что компания окажется незащищенной при изменении доходности.

Как пример сравнения Open Core и professional services Гори приводит кейс Red Hat: в 2019 году, по сведениям инвестора, компания заработала на профессиональных услугах в три раза меньше, чем на подписке на свои продукты. Эту закономерность подтверждают и данные HashiCorp: в 2021 году прибыль от professional services составила 5 млн долл., в то время как поддержка и лицензии, то есть Open Core-составляющая, — 165 и 36 млн соответственно.

Эксперт по Open Source Джон Марк Уокер в своем гайде Building a Business on Open Source пишет, что инвесторы неохотно вкладывают в компании, которые предоставляют только профессиональные услуги и поддержку.

Инвесторам нужен быстрый возврат инвестиций, а создание сервисной компании — это более долгий путь, чем создание продуктовой.

В то же время, отмечает Уокер, у модели Open Core немало недостатков, главный из которых — необходимость контролировать разработчиков Open Source-продукта и его экосистему. Тотальный контроль может привести к тому, что платформа с открытым исходным кодом будет «искалечена». Вместо этого эксперт предлагает альтернативную Open Core-модель, когда компании создают собственные продукты или услуги на основе уже готовых и успешных платформ с открытым исходным кодом — таких, как OpenStack и Apache Hadoop (см. пример Cloudera). Поверх такой платформы можно развивать свои продукты и услуги. Приложения могут быть и проприетарными, и с открытым кодом, но важно другое: платформа, на основе которых они развиваются, полностью открыта и эволюционирует при участии большого сообщества.

• Сегодня уже есть множество компаний, на примере которых можно видеть, как на Open Source зарабатывают.
• Чтобы создать успешный Open Source-бизнес, нужно выбрать правильную бизнес-модель или комбинацию нескольких.
• Учитывая опыт успешных компаний, можно заключить, что Open Core — это идеальная база и для хостинга, и для профессиональных услуг. Поэтому самый перспективный сценарий — создать крепкий Open Core-продукт, поверх которого можно было бы экспериментировать с дополнительными услугами.
• Если бизнес строится на базе существующего Open Source-проекта, есть риск зависимости от него, потому что он может развиваться «своим ходом». Хотя при грамотном взаимодействии с сообществом компания может оказывать значительное влияние на продукт, очень важно делать это аккуратно. Когда происходит коллаборация со всей индустрией в рамках Open Source-проекта, от нее выигрывают и компании, и пользователи.

Источник: vc.ru

ПО на базе Open Source для бизнеса: за и против

Российскому рынку сегодня нужны сотни новых программных продуктов. И создавать их нужно максимально оперативно. Многие разработчики именно поэтому активно применяют ПО с открытым исходным кодом, ведь создавать новое с нуля неэффективно, да и времени на это нет.

Согласно данным, собранным Scarf за первый квартал 2023, программное обеспечение на Open Source становится всё популярнее с каждым годом. Так, например, мировой рост такого ПО, загружаемого с помощью менеджера Scarf, показал увеличение на 60%, причем число загрузок в России выросло в 3,2 раза. В этой статье Даниил Передрий, младший специалист по ИБ RTM Group, рассмотрит преимущества и минусы использования ПО на Open Source в бизнес-среде, а также опишет методы снижения рисков и предложит практические рекомендации.

Плюсы и минусы его использования

• возможность доработки ПО для решения узкоспециализированных задач;
• развитие собственной экосистемы за счет усилий сторонних разработчиков;
• участие в деятельности открытого сообщества облегчает для компании поиск и найм новых сотрудников.

А теперь стоит посмотреть, какое влияние Open Source ПО может оказать на бизнес.

Сначала плюсы:

1. Сокращение затрат: за Open Source ПО не надо платить вовсе
2. Широкие возможности для модификации: на один исходный продукт может быть создано огромное количество версий программы со своими особенностями, благодаря чему можно сразу найти более подходящий вариант для конкретных задач
3. Независимость от вендора: ПО на открытом исходном коде позволяет не быть привязанным к одному поставщику, поэтому можно не беспокоиться о возможном прекращении поддержки, а также изменении условий лицензирования тех продуктов, которые допускают использование в коммерческой деятельности
4. Прозрачность: открытый исходный код позволяет бизнесу анализировать и контролировать качество кода, что может обеспечить бóльшую надежность
5. Поддержка стандартов и совместимость: такое ПО обычно строится на открытых стандартах, что обеспечивает совместимость между различными системами и упрощает интеграцию.

А теперь минусы:

1. Общедоступность одновременно и минус, и плюс. Производить анализ такого ПО могут не только добросовестные исследователи, но и злоумышленники. Последние, обнаружив уязвимости, способны использовать их для атак как на поставщика решений, применившего программы для разработки своих продуктов, так и на его клиентов;
2. Отсутствие гарантий и техподдержки разработчика: в случае возникновения проблем бизнесу придётся либо собственноручно тратить ресурсы на восстановление работоспособности системы, либо полагаться на помощь сообщества;
3. Сомнения в долгосрочной жизнеспособности продукта и отсутствие подотчетности поставщика, – именно эти сложности наряду с другими проблемами выделяют разработчики при внедрении ПО на Open Source;
4. Сложность внедрения: продукты, созданные на базе открытого исходного кода, часто требуют от IT-службы повышенной квалификации для их успешного внедрения и поддержки работоспособности в организации;
5. Вероятность подделки репозиториев и внедрения вредоносных пакетов. Согласно совместной аналитике Checkmarx и Illustria, злоумышленники использовали методы автоматизации, чтобы отравить всю экосистему NuGet, PyPi и NPM 144 294 вредоносными пакетами. Это позволило им опубликовать большое количество таких разработок за короткий промежуток времени, что затруднило для различных команд безопасности быстрое выявление и удаление проблем безопасности. Всегда существует вероятность того, что злоумышленники могут «спрятать» в программах на базе открытого исходного кода уязвимости, вредоносы и другие неприятные «сюрпризы», которые могут в дальнейшем привести к финансовым и репутационным потерям для тех, кто использует такое ПО.

Уязвимости

Посмотрим теперь на самые крупные примеры уязвимостей в Open Source ПО, которые привели к негативным последствиям:

1. Heartbleed (2014)

Ошибка Heartbleed позволяет любому непривилегированному злоумышленнику читать память систем, защищенных уязвимыми версиями программного обеспечения OpenSSL. Это ставит под угрозу секретные ключи, используемые для идентификации поставщиков услуг и шифрования трафика, имен и паролей пользователей.

2. Shellshock (2014)

Эта уязвимость была обнаружена в Unix-оболочке Bash, которая является стандартной для большинства Linux-систем и macOS. Shellshock позволял злоумышленникам выполнять произвольный код на уязвимых системах, что могло привести к захвату удаленного контроля над ними, утечке данных и другим последствиям. В 2014 году Yahoo была атакована через уязвимость Shellshock, и злоумышленники получили доступ к серверам компании. В результате атаки были скомпрометированы данные пользователей и ресурсы серверов. Этот инцидент повлек за собой дополнительные затраты на усиление безопасности, исправление уязвимости и компенсацию ущерба клиентам.

3. Apache Struts 2 (2017)

Уязвимость в популярном open-source фреймворке Apache Struts 2 позволяла злоумышленникам выполнить произвольный код на сервере с помощью специально сформированных HTTP-запросов. Она стала причиной одной из самых крупных утечек данных в истории, когда хакеры получили доступ к системам компании Equifax, в результате чего данные около 143 миллионов американцев, включая социальные страховые номера, адреса и даты рождения, были скомпрометированы. Это привело к финансовым и репутационным потерям компании, а также к судебным искам и увольнению руководителей.

4. Log4Shell (2021)

Уязвимость в популярной Java-библиотеке log4j позволяла злоумышленникам выполнять произвольный код на различных системах с помощью специально сформированных строк входа. Для реализации атак преступники использовали, в том числе, производные ботнета Mirai. Эта программа может обнаруживать общедоступные сетевые камеры, маршрутизаторы и другие устройства и подключать их к ботнету. Злоумышленник в дальнейшем управляет им для реализации DDoS-атак на конкретную цель, истощая ресурсы и нарушая работу online-сервисов.

Как обезопасить себя тем, кто использует Open Source ПО?

Примеры выше показывают, что последствия атак, связанных с уязвимостями ПО на базе открытого исходного кода, могут дорого обойтись бизнесу. Для снижения этих рисков в последние годы стали появляться новые программные решения, призванные обеспечить безопасность и более удобную масштабируемость Open Source ПО, названные Software Composition Analysis (SCA).

Они помогают анализировать корпоративные приложения, как правило, уже в процессе разработки (а иногда и коммерческие продукты внутри проектов заказчика), чтобы идентифицировать встроенные Open Source компоненты. Кроме этого, инструменты SCA выявляют известные уязвимости в этих пакетах, что повышает эффективность разработки за счет снижения затрат на исправление дефектного кода.

Они также могут определять лицензию, под которой распространяется конкретный компонент, что облегчает оценку юридических рисков. Не случайно за последний год, согласно статистике Gartner, интерес к SCA вырос на 20%. Здесь стоит отметить такие крупные коммерческие SCA продукты, как Black Duck от Synopsys и отечественный CodeScoring от Profiscope, а также Open Source анализатор Dependency-Check от Open Web Application Security Project (OWASP).

Чтобы снизить риски от использования ПО на базе открытого исходного кода, эксперты RTM Group рекомендуют:

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

Проблемы применения Open Source ПО становятся все актуальнее, поскольку подобные программы сегодня присутствуют в стеке технологий практически любой организации, но нельзя однозначно сказать, хорошо это или плохо. В каждой компании будет своя уникальная ситуация: если потенциальные риски от использования Open Source не превышают стоимость покупки проприетарного ПО, его внедрения, поддержки и обучения персонала, то бизнес может мириться с ними. Однако, стоит учитывать, какие издержки могут возникнуть в случае выхода из строя одного или нескольких Open Source компонентов, ведь в такой ситуации ответственность за инцидент полностью ляжет на плечи компании.

Подводя итог, можно сказать, что использование Open Source ПО является важным трендом в современных технологиях, и его использование может помочь бизнесу сэкономить деньги и повысить эффективность работы. Однако, необходимо учитывать потенциальные риски и принимать меры по их снижению.

Источник: securitymedia.org

Рассуждения об опенсорсе — где он может быть полезен в контексте импортозамещения зарубежных CRM

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

Буду говорить применительно к CRM, поскольку в своей работе сконцентрирован на этом классе решений. Но все те же рассуждения можно отнести и к другим энтерпрайз-инструментам.

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

Поиск замены более недоступному инструменту — действительно весьма распространенная причина внедрения сегодня. Но никакой крупный проект не существует в вакууме. Кроме условия “использовать российское” у бизнеса, а тем более у крупного, всегда есть ряд ограничений и требований, которые приходится учитывать. Поэтому на моей практике, в том числе в последний год, внедрение опенсорса чаще начинается с необходимости удовлетворить бизнес-требованиям, а импортозамещение выступает второстепенным условием. Так что и говорить о проектах будем в комплексе, опираясь на аргументы, которые были и остаются актуальными, вне зависимости от новостной повестки.

Не разработка с нуля и не проприетарный продукт

Начнем с базового позиционирования.

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

Собственная разработка

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

Ряд особенностей системы, в частности гибкость, должны закладываться на начальных этапах планирования архитектуры, или впоследствии их нельзя будет реализовать. Каждая такая “особенность” по-своему удорожает разработку, поэтому должна быть экономически обоснованной. Иными словами, проект должен быть основан не только на глубоком понимании текущего положения вещей в бизнесе, но и на представлении о наиболее вероятном пути его развития. При этом учесть все возможные пути тоже нельзя — слишком дорого.

В целом собственная разработка — это высокие требования к команде, большие сроки и стоимость реализации, а также риски, что инструмент так и не будет закончен.

Покупка проприетарного продукта

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

Зачастую эти несоответствия обусловлены как раз особенностями компании — ее ноу-хау. Банк выбирает свой способ скоринга клиентов, страховая по-своему считает риски и т.п. Как подстраиваться под такие ситуации, зависит от особенностей конкретного продукта. Иногда необходимо подстраивать свои бизнес-процессы под инструмент (под best practice, рекомендованные консультантами разработчика). А в каких-то системах может быть предусмотрена настройка таких моментов.

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

Решение на опенсорс-платформе

Внедрение решения на базе платформы с открытым исходным кодом в определенных ситуациях позволяет оптимизировать затраты и риски. Поскольку в основе — опенсорс, оплата лицензии и привязка к одному поставщику отсутствуют. Но при этом в решении уже есть некий “каркас”, вокруг которого можно строить реализацию индивидуальных потребностей.

В отличие от собственной разработки, не надо продумывать инфраструктуру, модели данных и прочие детали. Не требуется выбирать технологический стек. Бизнес сразу получает инструмент, который можно использовать с первого дня — тайм-ту-маркет сегодня крайне важен. Да, его необходимо настраивать и кастомизировать.

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

Мне в опенсорсе нравится гибкость с точки зрения сроков внедрения. Когда мы запускали CRM в стартапе, базовые необходимые задачи (звонки, продукты, интеграцию с веб-мастерами) сделали примерно за месяц. Это ровно тот срок, который был им необходим для найма людей, их обучения и т.д. То есть стартап сразу запустился с CRM.

Но конечно же, инструмент потом дорабатывали под изменения и рост компании. А в банке мы честно дорабатывали систему по объемному ТЗ около 6 месяцев, и это не считая долгой отладки интеграций и загрузки начальных данных.

В целом для самописного ПО такие сроки нереальны. А при настройке закрытого проприетарного продукта нельзя было бы настолько гибко управлять требованиями.

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

С опенсорсом возможна глубокая кастомизацию под задачу

Как я отметил выше, опенсорсную платформу — ту же CRM — можно взять и использовать как есть. В базовой версии SuiteCRM будут клиенты, отчеты, процессы, звонки, встречи, календарь и т.д. Некоторым компаниям этого достаточно. Например, если стоит задача запустить отдел продаж, но процессы еще не выстроены, поэтому непонятно, как именно все должно работать.

Но запуски с нуля на моей практике встречаются редко. Более типичная ситуация — кастомизация, когда у крупного и среднего бизнеса есть устоявшиеся процессы, которые сложно или невозможно поменять. Как правило, в опенсорсе можно многое изменить через конфигурирование и внешние библиотеки — сделать другой интерфейс, настроить интеграции со сторонними продуктами и т.п. Если этой гибкости недостаточно, можно доработать под конкретную задачу сами модули платформы — ведь код открыт и вполне доступен. Этим инструмент на базе опенсорс-платформы принципиально отличается от проприетарного.

Распространенный сценарий, когда кастомизация требуется не сегодня, а когда-нибудь в будущем. Это как в примере с запуском отдела продаж — базовые “хотелки” для CRM есть и сегодня, в принципе им удовлетворяет широкий круг решений. Взять проприетарное решение можно достаточно быстро (иногда просто по клику на сайте — в аренду). Однако непонятно, когда бизнес упрется в ограничения тарифа или коммерческого продукта в целом, которые окажутся для него критичными.

Даже предвидя ограничения, писать с нуля на этой стадии — явно не вариант. А вот опенсорс с готовыми 30-40 модулями — отличный выбор. Срок запуска — минимальный: несколько дней на установку, импорт начальных данных и обучение. Дальше можно поработать квартал или полгода, собрать обратную связь от пользователей. Поняв, чего не хватает, можно спокойно доработать систему под себя.

В нашей практике встречались даже запросы на доработки на уровне архитектуры (из-за требований службы безопасности заказчика). Было и перестроение логики системы. Например, для подразделения крупного международного консалтингового агентства в сфере бизнес-недвижимости мы совмещали в одной CRM несколько разных воронок продаж, у каждой из которых своя логика расчета маржинальности (причем, еще и с учетом мультивалютности). Эти доработки заняли у нас около 5 месяцев. Но с клиентом продолжаем работать уже почти 7 лет — автоматизируем новые процессы, поддерживаем изменения в бизнесе и т.п.

С опенсорсом такое вполне реально. Конечно, чем масштабнее доработки, тем дороже они будут стоить. Но о затратах нужно говорить отдельно.

Опенсорс — не бесплатно и не всегда дешевле проприетарного продукта

Не все понимают, что продукт с открытым исходным кодом — это не про бесплатный сыр. Но если не говорить об экзотике, вероятнее всего внедрить его будет дешевле, чем поставить сторонний продукт или разработать свое.

Стоимость проприетарного инструмента для крупного бизнеса складывается из трех компонент:

• Лицензии. Оплачиваются единоразово или за период, проект внедрения — поэтапно. В случае крупного бизнеса это сотни тысяч долларов в год.
• Проекта внедрения. Его стоимость закладывается в смете.
• Поддержки. В определенном объеме она может закладываться в лицензионные платежи. Сверх этого объема обычно включается почасовая ставка, размер который определяется или согласуется с вендором (обычно она заметно выше стоимости часа работы среднего разработчика с рынка труда).

Для собственной разработки лицензионные платежи отсутствуют. Но нужно полностью оплачивать создание самого инструмента — содержать внутреннюю или внешнюю команду, которая будет проектировать архитектуру и писать код. Проект внедрения при этом никто не отменял — изменение привычных процессов (или выстраивание их с нуля) будет стоить бизнесу денег. После завершения активной фазы разработки часть команды придется оставить для сопровождения решения и внутренней технической поддержки. Отдельная сложность при этом — сохранить в компании компетенции, достаточные для дальнейшего развития системы (чтобы вместе со специалистами не ушли и ценные знания).

Час работы специалиста в этом случае, возможно, обойдется дешевле, чем при оплате партнеру вендора, но будет много сопутствующих расходов (помещение для поддержки, оснащение их рабочих мест и т.п.).

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

Стоимость проекта внедрения неоднозначна. В зависимости от потребностей бизнеса она может оказаться как дешевле, так и дороже проприетарного инструмента. Как правило, вариант “дороже” как раз подразумевает внесение экзотических изменений (иначе выгоднее действительно внедрить продукт от вендора). В этом случае важно то, насколько эти изменения критичны для бизнеса.

Последующая поддержка определяется стоимостью работы разработчиков. Стоимость часа специалиста, работающего с опенсорсной платформой, может быть в 1,5 — 2 раза ниже ставки разработчика под дорогие проприетарные системы. Но объем трудозатрат зависит от проекта.

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

Опенсорс вполне безопасен, если грамотно выбирать платформу

Согласно распространенному мифу проприетарное решение от вендора безопаснее опенсорса. Но на мой взгляд это вопрос, требующий обсуждения.

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

В то же время от закладок в закрытых решениях никто не застрахован. Не имея возможности проанализировать исходники, вы никогда не заметите признаков их активности, пока они не сработают. Гарантом для клиента является “доброе имя” вендора или сертификация, если вендор прошел эту процедуру. Но далеко не все инструменты для крупного бизнеса сертифицированы.

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

Опенсорс исключает блокировку на вендоре и подрядчике, но не дает гарантий развития

Крупному бизнесу сложно менять используемые продукты и партнеров по разработке.

Если однажды был внедрен тот же Microsoft или Oracle, компания долгое время платит за лицензии и поддержку, даже если цена удваивается. Вероятно, это дешевле, чем инициировать новое внедрение.

При использовании проприетарного решения перейти на инструмент от другого вендора — значит выкинуть существующее и начать все заново. Сменить интегратора, не меняя базового продукта, проще. Но это никак не изменит стоимость лицензий (а иногда и стоимость часа поддержки, поскольку партнерская сеть может работать по единым тарифам).

С инструментом на базе платформы с открытым исходным кодом все свободнее. Оплаты за лицензию нет, поэтому ситуации, когда вендор внезапно решил кратно поднять стоимость, быть не может. Доработки и поддержка со стороны интегратора могут вырасти в цене. Но для заказчика ситуация не будет безвыходной — с популярными платформами для бизнеса работает множество интеграторов и нет никакой единой ценовой политики (как нет одного вендора, который бы ее определял).

Например, с SuiteCRM работают как крупные компании с именем, внедряющие десятки разных решений, так и небольшие разработчики, которые фокусируются на этой платформе и готовы взяться за ту же задачу дешевле. Есть и фрилансеры, готовые работать за минимальный гонорар. Выбор между этими вариантами — это уже вопрос предпочтений заказчика.

Сравнивая опенсорс с собственной разработкой, сложно объективно оценить деньги, но можно поговорить о рисках.

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

Опенсорс в этом смысле проще. Поскольку все множество подрядчиков, о которых я говорил выше, работают в одной парадигме, они в курсе базовых возможностей платформы и могут войти на проект гораздо быстрее. И у большинства есть опыт включения во внедрения за коллегами по рынку — смена поставщика услуг в этом мире не такая уж редкая ситуация. Так что риск заказчика остаться вообще ни с чем существенно ниже.

У любого преимущества есть обратная сторона. В данном случае отсутствие одного производителя или команды, отвечающей за развитие, — это отсутствие гарантии уверенного развития продукта определенным курсом в течение длительного времени.

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

У опенсорсного решения не обязательно есть вендор. Иногда за платформу в основе несет ответственность только некоммерческое сообщество, которое может прекратить свое существование или сменить вектор развития. А даже если вендор есть, он не связан с заказчиками договорными обязательствами.

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

Вместо итогов

Лично я работаю с внедрением опенсорсной CRM уже 14 лет. Опыт показывает, что платформа с открытым исходным кодом может быть достойной альтернативой проприетарному продукту или собственной разработке. Но на старте важно учитывать особенности этого типа решений — в первую очередь считать деньги, понимая, что все это не бесплатно.

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

• crm система
• импортозамещение
• open-source
• open source

• Open source
• CRM-системы
• Управление проектами

Источник: habr.com