Бесплатно ли бесплатное ПО?

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

ПО с открытым кодом исторически развивали энтузиасты для возможности обкатать новые идеи, подходы и технологии быстро развивающейся ИТ-индустрии, где основные деньги зарабатывались на производстве и поддержке оборудования. Появление Интернета оказало огромное влияние на движение Open Source, в недрах которого родилось множество проектов: Linux, OpenBSD, OpenSSH, Android, GNU и др. Начиная с 2000-х годов поднялась волна проектов с открытым исходным кодом, но на этот раз их поддержали «Единороги» — технологические гиганты и стартапы-единороги: Google, Amazon, Uber, Netflix, Spotify, Airbnb, Lyft и т. д.

ПО с открытым кодом стало сегодня инструментом конкурентной борьбы гигантов как между собой, так и с «Бегемотами» — традиционными, не очень поворотливыми производителями функционального ПО (Microsoft, Oracle, SAP и др.) с широким спектром проверенных временем и рынком программных решений, накопившими огромную клиентскую базу. Вторые также все чаще выходят на рынок ПО с открытым кодом, предлагая в своем портфеле открытые решения.

Сегодня ПО с открытым кодом — это значимая часть глобальной ИТ-индустрии. Почему это произошло, видно из табл. 1.

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

Сегодня всех производителей ПО можно разделить на две большие категории: традиционные разработчики функционального ПО с жесткой системой лицензирования и монетизации — это стиль Бегемотов; а также производители ПО с открытым кодом (как бесплатного, так и коммерческого), где доминируют Единороги. Коммерческие компании, которые выросли на открытом ПО, как правило, предлагают рынку один продукт, в основе которого лежит какой-либо доведенный до коммерческой реализации проект открытого ПО, сопровождаемый производителем. Риски эксплуатации такого продукта для конечного потребителя минимизированы при приемлемой цене стоимости владения технологическим стеком, часть которого, включая ОС, систему хранения данных и веб-сервисы, фактически бесплатна.

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

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

Тут стоит вспомнить еще об одном скрытом риске SSPL-лицензирования (Server Side Public License): компания, желая сэкономить на лицензиях, может столкнуться с реальными проблемами в недалеком будущем. Производители коммерческого ПО с открытым кодом вынуждены защищать себя от недобросовестного применения своих решений, которые целиком или частично могут использоваться в рамках определения ПО с открытым кодом. Одним из шагов явилась практика SSPL-лицензирования — закрытия части кода на стороне серверов. В итоге открытое ПО оказывается только частично открытым.

Получается, что и покупка ПО у вендора, и самостоятельная разработка — далеко не идеальные решения.

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

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

Какие-то ветви или все решение оказываются тупиковыми: скажем, ветка не «пошла» у Единорога, была выложена в открытый доступ и в дальнейшем не поддерживается. Это может быть и заведомо ложным «вбросом» ущербной технологии для замедления конкурентов и технологического отрыва от участников рынка, что часто сопровождается длительной рекламой в среде разработчиков. Например, случай с Hadoop: пока все совершенствовали NoSQL и MapReduce, компания Google делала собственный распределенный Spanner, но SQL. Возможно и просто технологическое ветвление проекта с открытым кодом, например: Hudson –> Jenkins, MySQL –> MariaDB, Cadence –> Temporal, MongoDB –> DocumentDB, ElasticSearch –> OpenSearch. Кроме того, ПО с открытым кодом может решать задачи для особого окружения конкретной компании и не работать у конечного потребителя — например, Yahoo с распределенным хранением данных на Hadoop. Сообщество может перестать активно участвовать в развитии проекта после ухода из него харизматичного лидера, начинает вязнуть в плохо согласованных изменениях без четкого стратегического плана развития и в итоге стагнирует (Apache Apex). Возможны и проблемы с дополнительными скрытыми расходами по сборке и сопровождению ПО: дистрибутивы Linux (Centos, Debian) без пакета v8 от Google, который оказалось слишком сложно собирать. Это привело к тому, что и соответствующее расширение для PostgreSQL перестало выходить в бинарном виде и пользователи теперь вынуждены делать сборки самостоятельно.

Что делать компании, которая оказалась наедине с проблемой, сделав ставку на тупиковую ветвь в своем желании сэкономить и иметь все под контролем? В любом случае, будь то открытое ПО, открытое ПО от Единорогов или Бегемотов, самостоятельная доработка такого кода и его дальнейшее использование сопряжены со скрытыми рисками, которые надо непременно учитывать.

***

Для перемещения из точки А в точку Б можно воспользоваться такси (аналог облаков), можно купить новый автомобиль с гарантией (аналог ПО от вендора), а можно взять старую «Волгу» и модернизировать ее — аналог использования Open Source без поддержки. Последний вариант требует времени и квалификации.

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

Сергей Шестаков (info@luxms.ru)  —  генеральный директор, Дмитрий Дорофеев  —  главный конструктор, ГК Luxms (Санкт-Петербург).