В связи с уходом западных вендоров в российском IT-сегменте идет процесс замены недоступных ныне решений. Одним из способов заполнить пробелы стали решения Open Source. Существует стереотип, что они бесплатны, но на самом деле это не так. Какова модель продажи Open Source-решений, в каких ситуациях они выигрывают у коммерческих решений и каковы их особенности и перспективы?
Компетенции превыше всего
Развитие продуктов Open Source было заметным еще до введения «больших» санкций. Они прогрессировали во всем мире как минимум последние пять лет, в результате появились серьезные разработки на хорошем промышленном уровне. Некоторые из них способны заменить коммерческие продукты, а иногда даже их превосходят. В первую очередь это касается области разработки приложений, DevOps, мониторинга, СУБД, интеграции, инфраструктурных сервисов.
Существует известное заблуждение, что Open Source — бесплатный. Это не так. Компании, которые занимаются Open Source, на этом зарабатывают, просто другим способом: подпиской, за счет поддержки и т.п. Меняется модель продажи технологии, и на практике Open Source может оказаться дороже классического коммерческого продукта.
В нашей практике был интересный опыт, когда мы оказывали консалтинговые услуги крупному банку и выяснили, что для разворачивания лицензионного продукта нужен один специалист и 20% его рабочего времени. Для поддержки Open Source пришлось бы нанимать еще пять сотрудников. Банк посчитал и понял, что ему выгоднее купить классическое коммерческое решение с понятной «дорожной картой», понятными условиями поддержки, понятным функционалом. Это основная сильная сторона лицензионных продуктов и слабая сторона Open Source.
Применение решений на базе Open Source требуют серьезной компетенции. Покупая коммерческий продукт, клиент, как правило, получает и пакет сервисных услуг. С Open Source все иначе: необходима экспертиза, чтобы адаптировать продукт под конкретные задачи и поддерживать его работоспособность. И здесь потребуется либо пополнять штат соответствующими специалистами, либо обращаться за внешней экспертизой.
Именно поэтому Open Source, с одной стороны, действительно поможет закрыть пробелы, образовавшиеся в связи с технологическими санкциями и уходом западных вендоров, с другой стороны — его нельзя рассматривать как панацею. Сейчас мы видим на рынке разные ситуации. Есть компании, которые подпадают под регуляторные ограничения и в любом случае вынуждены заменять западные решения либо на российские коммерческие продукты, либо на Open Source. Многие российские решения основаны на Open Source, это общемировая практика: Open Source дорабатывается, а результат продается как коммерческий продукт.
Компании, которые начали внедрять эту практику раньше, в том числе после санкций 2014 года, получили некий бустер и могут быстрее развивать технологии. Одновременно заметен тренд на инхаус-разработки: заказчики стараются держать компетенцию у себя, что и требуется при создании решений на базе Open Source, а также дает некоторую независимость и позволяет избегать привязки к вендеру или интегратору.
Говоря о российском рынке, стоит отметить, что его компетенция сильно выросла. С уходом западных вендоров часть экспертизы стала недоступна, но тренд начался не вчера и не год назад, поэтому российский рынок в целом довольно сильный. Мы видим экспертов, которые работают не хуже мировых лидеров, многие состоят в международных сообществах Open Source. Благодаря наличию этого опыта переход на Open Source эффективен прежде всего в самых чувствительных местах, которые обеспечивает бизнес-деятельность заказчика и его ежедневные операции.
Преграды на пути внедрений
Главным препятствием на пути к более широкому внедрению Open Source остается все та же экспертиза. Эти решения всегда требовали и будут требовать высочайшей компетенции у заказчика либо у его надежного партнера. Этот партнер должен быть всегда в пределах досягаемости, поэтому доступ к коммерческим решениям из-за границы, в том числе на базе Open Source, теперь закрыт. Санкции фактически запрещают экспорт консалтинговых услуг в области технологий. Однако по-прежнему доступно множество публичных программ обучения. Экспертиза тоже накоплена, хотя ощущается нехватка опытных разработчиков, архитекторов. Их недоставало и раньше, но сейчас потребность возросла.
Второй немаловажный фактор, способный замедлить развитие Open Source в России, — необходимость апробации, то есть набор референса об успешных и неуспешных внедрениях. Одно и то же решение может хорошо работать в одном случае и плохо — в другом. Проблема устранима: например, наша компания для таких случаев предлагает свою программу цифровой независимости. Мы тщательно подходим к анализу существующего технологического стека, предлагаем свое видение и опыт. Мы подбираем несколько технологических стеков и по ним уже начинаем двигаться, работая над апробацией технологий, подходов к переносу и миграции, что позволяет ускорить процессы, снизить риски и самое главное — передать знания и экспертизу непосредственно заказчику.
Open Source или коммерческий продукт?
Самые слабые стороны Open Source — поддержка и отсутствие прозрачных «дорожных карт», чем всегда были хороши коммерческие продукты. К тому же Open Source не гарантирует, что можно получить конкретную функциональность. Поэтому появилось множество так называемых форков: от основной ветки отделяется доступный на данный момент код, а дальше ведется самостоятельная разработка. В коммерческом продукте другая история. Есть менеджер по продукту, он изучает потребности рынка и реализует основные запросы заказчиков. Кроме того, у коммерческих продуктов есть поддержка, что практически гарантирует закрытие критичных технических проблем.
В Open Source же можно рассчитывать только на доступные компетенции, но никто не поручится за исправление технических ошибок. В этом заключается главный риск. Тем не менее у серьезных продуктов есть большое комьюнити, которое дорабатывает код. Так за счет обратной связи появляется «дорожная карта». Полностью управляемой ее назвать нельзя, но она все равно дает некую стабильность и понимание, куда будет двигаться продукт.
Чтобы создать гарантированную поддержку и понятную «дорожную карту», появляются компании, реализующие упомянутые форки. Получается гибридная схема — берут общее из Open Source, сочетают с коммерческой частью, получают коммерческий, но вроде бы и Open Source-продукт. Такие гибридные решения санкционными инструментами заблокировать практически невозможно. Это не только российская специфика — это устоявшаяся практика, которая помогает снизить себестоимость.
Широкое распространение получили и сервисы техподдержки на продукты Open Source, что снимает риски обслуживания и открывает доступ к компетенции в случае технических проблем или необходимости консультаций.