Примеры Open Source-инструментов всегда под рукой и в повседневной жизни, и в бизнесе: браузерный движок Chromium (Google Chrome, Opera, Microsoft Edge), операционные системы Android и Linux, база данных MySQL, система контейнеризации Docker и контейнерный оркестратор Kubernetes. Согласно отчёту Open Source Security and Risk Analysis Report, около 96 % всех коммерческих баз кода содержат Open Source-код, а общая доля такого кода в этих базах — примерно 77 %. Сказать, что Open Source вездесущ, — не преувеличение.
Мы тоже используем Open Source-ПО: Kubernetes — основа нашей Deckhouse Kubernetes Platform. В модулях платформы мы применяем Prometheus, Grafana, Cilium, Istio, Dex и другие решения. Community-версия Deckhouse Kubernetes Platform и наша утилита werf сами являются Open Source-проектами.
В этой статье разберёмся, что такое Open Source, чем он привлекателен для компаний, как выбирать Open Source-инструменты и что учитывать при их внедрении.
Что такое Open Source
Open source software — это свободно распространяемое программное обеспечение с открытым исходным кодом. Это значит, что ПО чаще всего бесплатное, а его код общедоступен: его можно как просто просматривать, так и изучать, использовать, распространять и модифицировать, в том числе в коммерческих целях.
Термин «Open Source» появился в конце 90-х годов XX века как альтернатива более раннему термину «free software». Последний вызывал путаницу из-за многозначности слова «free» в английском языке. В итоге Open Source и free software выросли в отдельные идеологии:
- Ценности Open Source — удобство работы с кодом и совместная разработка как наиболее эффективный и способствующий инновациям формат работы. Open Source больше ориентирован на бизнес, чем free software, и позволяет присваивать и закрывать (делать проприетарным) результат изменения открытого ПО.
- Миссия free software — дать полную свободу и контроль над ПО пользователям. Сторонники этого подхода критикуют термин и движение Open Source за смещение акцента со свободы на практическую выгоду. Кроме того, они предпочитают лицензии, по которым все производные от свободного ПО также должны распространяться как свободное ПО.
Чтобы подходить под понятие Open Source, ПО должно соответствовать некоторым критериям: например, исходный код должен быть легко читаемым, лицензия не должна предполагать выплату роялти, не должно быть дискриминации в отношении отдельных лиц, групп, сфер деятельности. С полным списком требований можно ознакомиться на сайте фонда Open Source Initiative.
Какие бывают лицензии
На первый взгляд, открытый код противоречит самой сути лицензирования. Но есть парадоксальный нюанс: ПО без лицензии автоматически защищено авторским правом и его нельзя свободно использовать. Лицензия — это не обязательно ограничения и выплаты вознаграждения. Она нужна, чтобы определить условия использования, даже самые демократичные.
Существует более ста Open Source-лицензий, и их разбору можно посвятить не одну статью. Мы кратко опишем основные группы лицензий и приведём примеры.
Public Domain. Самая «щедрая» разновидность лицензий. Public Domain-ПО — это общественное достояние, не защищённое авторским правом, то есть его код можно применять как угодно. Такие лицензии позволяют разработчикам максимально широко распространять свой код, а пользователям, в том числе компаниям, — использовать его, не боясь нарушить условия лицензии. Пример Public Domain-лицензии — Unlicense.
Permissive. Так называемые «разрешительные» лицензии. Они отличаются от Public Domain тем, что позволяют сохранить авторское право. В остальном код проектов под Permissive-лицензиями можно использовать произвольно, в том числе не выкладывать в открытый доступ изменения в исходном коде, распространять их под другой лицензией или вовсе сделать их частью проприетарного продукта. Самые распространённые Permissive-лицензии — MIT, Apache 2.0, BSD.
Copyleft. Лицензии Copyleft больше остальных видов Open Source-лицензий соответствуют духу free software и накладывают самые строгие ограничения. Уровень строгости зависит от конкретной лицензии:
- Лицензии GPL и AGPL предполагают, что любые производные от исходного кода должны распространяться под такой же лицензией, то есть оставаться открытыми. Код под GPL/AGPL нельзя сделать частью проприетарного продукта.
- Лицензии LGPL и MPL позволяют использовать код в закрытом ПО, однако все изменения в исходном Open Source-коде необходимо открыть.
Ознакомиться с условиями лицензии при выборе Open Source-проекта — очень важный шаг, который нельзя пропускать. Обычно компании предпочитают продукты с Public Domain- и Permissive-лицензиями, потому что такой код, как правило, можно использовать как угодно, в том числе в закрытых проектах, без юридических, финансовых и репутационных рисков.
Почему компании выбирают Open Source-решения
Как мы уже говорили, практически во всех коммерческих базах кода есть код Open Source-проектов. Причин такой популярности Open Source у бизнеса много — разберём основные.
Бесплатность. Согласно отчёту State of Open Source Report, более трети компаний называют отсутствие лицензионных платежей и, соответственно, общее снижение затрат главным фактором, который побуждает их обратиться к Open Source-решениям. Внедряя Open Source, бизнес может оптимизировать расходы: например, средства, которые пошли бы на оплату проприетарного решения, можно перенаправить на разработку дополнительных фич для своего продукта.
Безопасность. Поскольку код Open Source-ПО открыт, его можно изучить до мельчайших подробностей, чтобы убедиться, что он не содержит ничего лишнего или вредоносного. Кроме того, уязвимости в безопасности обычно быстро устраняются, так как многочисленные пользователи постоянно тестируют инструмент в разных условиях и указывают разработчикам на проблемы.
Скорость разработки. Разработчики Open Source-проектов прислушиваются к запросам сообщества и реализуют особенно востребованные фичи. А энтузиасты из сообщества ищут ошибки, реализуют дополнительную функциональность, пишут и переводят документацию. Это непрерывный процесс, поэтому новые релизы выходят часто — проект живёт и бурно развивается.
Независимость от поставщика. Open Source — возможность избежать так называемого vendor lock-in — зависимости от поставщика решения. Используя 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-решения
Большинство репозиториев Open Source-ПО размещено на GitHub. В разделе Topics внутри каждой из тем есть список связанных с ней репозиториев. Их можно отсортировать по количеству звёзд, форков (копий репозитория), времени изменения. Например, в теме Kubernetes можно найти ссылки на репозитории хранилища etcd, пакетного менеджера Helm, интерфейса командной строки K9s. В разделе Trending можно посмотреть самые популярные репозитории за сегодняшний день / неделю / последний месяц.
При поиске Open Source-инструментов также можно обратиться к фондам, которые их поддерживают. Вот самые известные:
- Linux Foundation занимается развитием и популяризацией Linux и Open Source-проектов. Это «дом» таких известных решений, как PyTorch, Falco, Dex.
- Cloud Native Computing Foundation (CNCF) — дочерний фонд Linux Foundation. Open Source-решения под началом CNCF собраны на Cloud Native Landscape — интерактивной карте, на которой инструменты можно фильтровать по уровню зрелости, категории, индустрии и другим критериям. На карте можно найти, например, Kubernetes, Prometheus, Istio и проекты поменьше, в том числе утилиту werf, которую мы передали в CNCF в 2022 году. Чаще всего проекты CNCF распространяются под лицензией Apache 2.0.
- Apache Software Foundation поддерживает развитие Open Source-проектов Apache, в том числе Airflow, Hadoop и Kafka.
Узнать о развитии Open Source и наиболее трендовых проектах также можно из тематических отчётов. Например, мы уже приводили статистику из ежегодного отчёта State Of Open Source Report. В нём собраны данные о том, почему бизнес выбирает Open Source, в какие проекты инвестирует, какие возможности и вызовы видит.
Сравнить альтернативные Open Source-инструменты, отследить тренды и узнать, какой стек технологий используют крупные компании, можно на StackShare. Например, тут можно увидеть, что Udemy применяют Elasticsearch, Docker и Terraform, а Spotify — PostgreSQL, Kafka и Hadoop.
То, что какой-то Open Source-инструмент успешно применяет крупный бизнес, — потенциальный повод выбрать его и для своей компании, но это не должно быть единственным фактором выбора. Приведём ещё несколько критериев оценки проекта.
Жизнеспособность. Как мы уже говорили, большая часть Open Source-репозиториев находится на GitHub. На странице репозитория во вкладке Insights можно увидеть историю развития проекта.
- В разделе Pulse можно посмотреть количество открытых и закрытых запросов на изменение репозитория (pull requests) и тикетов (issues), а также релизы. Чем больше одобренных (merged) pull requests, закрытых issues и релизов и чем чаще они появляются, тем активнее развивается инструмент.
- В разделе Contributors видно, сколько изменений (commits) внесено в ПО за всю историю его существования, а также показан вклад отдельных разработчиков. Отсутствие изменений в последние несколько месяцев должно насторожить — возможно, проект заброшен.
Расширенную статистику по репозиторию можно найти в сервисе OSS Insight. Здесь видно:
- компании, которые вносят наибольший вклад в проект;
- график изменений проекта за всю его историю;
- динамику запросов на изменение и тикетов;
- рейтинг разработчиков по их вкладу в проект.
В статистике развивающегося проекта, как правило, есть периоды подъёмов и спадов, но нет пустот, особенно за последнее время.
Скорость поддержки. По графикам Pull Request Time Cost и Issue First Responded Time в том же OSS Insight можно отследить, сколько времени проходит до одобрения изменений в репозиторий и до ответов на тикеты, в которых пользователи могут передавать баги и предложения по развитию инструмента. Конечно, чем меньше это время, тем лучше.
Вовлечённость сообщества и репутация. Чтобы определить, насколько активно ИТ-сообщество участвует в судьбе ПО и как вообще к нему относится, можно посмотреть вкладку Discussions на странице репозитория на GitHub, а также изучить социальные сети проекта.
Качество кодовой базы, документация, совместимость с инфраструктурой. Последний — но не по важности — пункт. Необходимо оценить, насколько грамотно написан, удобно представлен и читабелен код, в каком состоянии документация к нему и не будет ли он конфликтовать с инфраструктурой компании.