Использовать Open Source в ядре бизнеса: стоит ли рисковать

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

На том же GitHub можно найти библиотеки под любые запросы. Почему бы не использовать их в основе своих проектов? Такой подход ускоряет запуск, внедрение инноваций и, соответственно, выход на конечных клиентов. На конкурентном рынке это важное преимущество. 

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

Проведенное Ассоциацией ФинТех исследование «Технологическая независимость российского финтех-рынка» показало, что 82% опрошенных российских компаний, занимающихся собственной разработкой, считают подход через open source для своей организации оптимальным с точки зрения сроков реализации, внедрения и рисков.

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

Риски open source

Первая сложность в том, что в мире open source всегда ребром стоит вопрос лицензирования. Необходимая библиотека может иметь ограничения на копирование кода, коммерческое использование или модификацию. За этим нужно следить, поскольку политика лицензирования может меняться со временем.

Наглядный пример смены политики лицензирования — ELK (Elasticsearch, Logstash, Kibana — набор инструментов для сбора, хранения, анализа и визуализации данных). В 2021 году разработчики изменили некоторые условия лицензирования. Часть функционала Elasticsearch и Kibana оказалась вынесена из под лицензии Apache 2.0 в коммерческую Elastic Subscription License (ESL). Некоторые функции Logstash «уехали» в плагины, которые теперь тоже распространяются как коммерческий продукт. Эти изменения активно обсуждались в сети, поскольку влияют на использование функций стека ELK в других решениях, в т.ч. open source.

Более свежий пример — перевод под коммерческую лицензию Redis Source Available License (Redis-SA) некоторых компонент Redis. Ранее они распространялись под лицензией BSD.

Но самая главная проблема — это отсутствие гарантий выбранного курса развития. Сообщество может прекратить поддержку библиотеки или продолжить ее развитие в противоположном направлении. Многие open source сообщества зависят от ресурсов и стратегий крупных компаний, поэтому неожиданное сворачивание поддержки со стороны одного производителя может поставить крест на всем продукте.

Например, Red Hat объявил о прекращении поддержки CentOS 8 задолго до обещанного срока (изначально LTS-поддержка должна была длиться до 2029 года). Вместо стабильного CentOS был предложен CentOS Stream, который стал «тестовой» версией перед выпуском RHEL. Компаниям, которые использовали CentOS, срочно пришлось искать альтернативу. Похожая история произошла с Docker Swarm, когда производитель сменил приоритет на Kubernetes.

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

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

И еще одно но…

За скобками я пока оставил вопрос безопасности. Хотя в целом open source — штука довольно безопасная, поскольку код читают и перепроверяют десятки и сотни людей, известны случаи обнаружения серьезных уязвимостей спустя годы, после того как были написаны соответствующие модули.

Так, например, в 2014 году были выявлены уязвимости в библиотеке OpenSSH и утилите Bash. Спустя два года, в 2016 году, обнаружили уязвимость в ядре Linux. Dirty COW позволяла писать в защищенные области памяти, не имея на это достаточно прав, и потенциально получать root. Уязвимость просуществовала в ядре почти 10 лет.

Аудит безопасности open source компонент, добавленных в проект, требует довольно серьезных трудозатрат, на фоне которых собственный код уже не кажется таким уж сложным путем.

Наша практика

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

Я вижу, что в мире мы не одни такие. Заметно снижение доверия к oVirt-based решениям. Например, RedHat объявил о прекращении поддержки oVirt в пользу собственной коммерческой платформы OpenShift Virtualization (на базе KubeVirt). Это с одной стороны показывает тенденцию, а с другой — oVirt сообщество лишилось крупных корпоративных участников.

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

Хотя open source как идея мне близка, текущая ситуация делает его использования в основе своей инфраструктуры довольно рискованным.