Open source в России и работа с открытыми решениями: ключевые вопросы, чеклист и мнения экспертов
Ключевые моменты по теме, полезные источники, а также мнения экспертов с опытом разработки открытых решений и не только.
С уходом западных вендоров организации в России стали активнее использовать open source решения, а регуляторы — запустили эксперимент с распространением российских технологий на условиях открытой лицензии (список участников — в док-файле здесь).
При этом многие подводные камни и вопросы, сопутствующие интеграции и разработке свободных программных продуктов, все еще остаются без должного внимания. Дело в том, что они обладают комплексной природой и требуют понимания принципов работы с авторскими и исключительными правами; знания свежей проблематики и трендов в сфере технологического лицензирования; актуальной информации о бизнес-моделях в open source продуктов; а также опыта развития технологических сообществ.
Обсудим ключевые моменты, на которые следует обратить внимание российским организациям-пользователям открытых решений, а также непосредственным вендорам и разработчикам OSS-технологий, и посмотрим на источники, способные послужить отправной точкой для изучения темы.
Выбор open source технологий
Поставщики открытых продуктов агрессивнее коммерциализируют свои решения и переводят их из open source в source available, кардинальным образом меняя лицензии. В результате организации-пользователи оказываются в неловкой ситуации — в силу неожиданного характера изменений им приходится оперативно разбираться с новыми условиями и ограничениями, также — искать альтернативные решения, если необходима замена компонента, обретающего проприетарный статус. Подобных ситуаций множество: от ввода жесткой copyleft-лицензии SSPL (Server Side Public License) на стороне MongoDB и Elastic до перевода существенного числа продуктов HashiCorp из классического open source формата на новые условия, регулируемые лицензией BSL (Business Source License).
Тренд на коммерциализацию open source решений способствует еще и тому, что в зоопарке лицензий — различных типов и уровней совместимости — регулярно появляются новинки. OSS-разработчики либо дорабатывают существующие лицензии и выпускают производные, либо готовят новые условия с нуля. Такие нововведения следует анализировать хотя бы для того, чтобы понимать ход развития «лицензионной мысли» в ИТ и не только.
Также в процессе проектирования новых продуктов на основе open source решений стоит глубже изучать характеристики организаций-разработчиков и спектр других вопросов: от лицензионной политики и рисков, связанных с ее внезапным изменением, до степени развитости сообщества контрибьютеров вокруг продуктов того или иного вендора open source технологий.
При этом одно дело — отслеживать уже произведенные изменения лицензий, другое — регулярно проводить аудит тех. стека и подбирать «скамейку запасных», третье — прогнозировать смену лицензий критичных компонентов.
Что почитать:
- Компактный гайд по лицензиям — поможет разработчикам и организациям познакомиться с лицензиями и подходами к их выбору.
- На что обратить внимание при интеграции open source технологий — от вопросов безопасности до документации и активности сообщества.
Развитие своих OSS-решений
В России разработку и продвижение open source технологий пока невозможно считать массовой. Однако запрос есть, и точечные попытки распространения продуктов в формате свободного программного обеспечения существуют.
Для развития в этом направлении и успешной реализации корпоративных open source проектов следует опираться на мировой опыт, но при этом существенным образом адаптировать его. Например, понимать, какие проблемы существуют в сфере лицензий, почему организации-разработчики их меняют, какие условия и для чего они начинают использовать, появляются ли новые модели распространения open source технологий.
Также необходимо точнее формулировать предложение для аудитории и контрибьютеров (что именно вы распространяете: общедоступный код, что-то еще), по возможности избегая множества возможных трактовок.
Кстати, если говорить о source available подходах, то стоит обратить внимание на модели и лицензии, направленные на защиту от конкуренции (взять хотя бы BSL), и так называемый отложенный open source (DOSP). Обе особенности лицензирования применили HashiCorp, а также CockroachDB и Sentry, но эти варианты не являются единственными возможными.
Плюс — стоит понимать, как обеспечивать устойчивость open source разработок: хватит ли мотивации контрибьютерам, как поддерживать их — финансировать кого-то или нет, нужно ли вовлекать партнерские организации и клиентов в развитие совместных OSS-начинаний и т.д. В этом поможет анализ бизнес-моделей и хода развития известных open source продуктов. Достаточно начать, например, с истории Grafana (часть первая, вторая, третья). В целом профильной литературы по теме достаточно. Так, в «Open Source Projects — Beyond Code» и «Producing Open Source Software» можно найти подходы к развитию OSS-проектов и сообществ вокруг них.
Что почитать:
- Гайд по запуску собственных open source решений — ряд экспертов по работе над open source стратегией и сообществами делятся ключевыми моментами и рекомендациями в материале от Linux Foundation.
- Зачем организациям open source отделы — материал о том, чем занимаются такие структуры и корпоративные эксперты по open source, с примерами и подробными рекомендациями для запуска специализированных отделов и отдельных ролей.
Нужны ли аналоги LF
Российским структурам будет сложно воспроизвести модель Linux Foundation на текущем этапе развития рынка как минимум в силу скромной стартовой базы — недостатка экспертов и низкой готовности организаций поддерживать что-либо централизованное. При попытках копирования таких моделей есть риск получить два-три «центра силы», которые будут поддерживать конкурирующие компании. Следить за разнородными инициативами каждого из них технологическому сообществу может быть затруднительно.
Поэтому стоит главным образом опираться на опыт структур вроде Linux Foundation на корпоративном уровне — изучать и адаптировать механизмы взаимодействия с контрибьютерами, открытые лицензии, open source бизнес-модели и стратегии развития таких проектов. Такой подход позволит не только ориентироваться на собственные возможности и ресурсы организаций, но и поможет им понимать инициативы регуляторов, а также OSS-ассоциаций.
Чеклист с вопросами
Это — основные вопросы для тех, кто хотел бы эффективнее работать с open source решениями. Список для организаций-пользователей OSS-решений:
1. Как вы подходите к выбору open source технологий для использования и интеграции в технологический стек организации? Учитываете и отслеживаете ли вы условия распространения таких решений (лицензии)? Прогнозируете ли вы односторонние изменения лицензий организациями-разработчиками?
2. Кто из сотрудников вашей организации занимается такими вопросами? К кому могут обращаться сотрудники за разъяснениями помимо юристов?
3. Предоставляете ли вы сотрудникам актуальную информацию по теме (вебинары, митапы, вики), чтобы они могли самостоятельно разбираться с лицензиями при выборе технологий для рабочих и личных проектов?
4. Как точно ваши сотрудники понимают специфику участия в разработке open source решений с точки зрения распределения авторских и исключительных прав? Учитываете ли вы такие моменты в должностных инструкциях и трудовых договорах?
5. Делятся ли ваши сотрудники информацией об участии в open source проектах и рассказывают ли о личных разработках? Понимаете ли вы, что их интересует? Как регулирует и допускает ли организация такие активности в рабочее время?
Для OSS-разработчиков:
1. Каким образом ваши open source проекты соответствуют стратегии развития организации в целом? Какие инсайты они дают для улучшения ваших продуктов?
2. Понятны ли ваши open source и коммерческие лицензии потенциальным пользователям? Достаточно ли прозрачны различия условий таких лицензий?
3. Учитывает ли ваш подход к работе с контрибьютерами коммуникационную стратегию?
4. Применяете ли вы CLA (Contributor License Agreement) в своей работе? Понятны ли его условия контрибьютерам ваших open source проектов? Дают ли такие условия прозрачную основу для инхаус-развития результатов вашей деятельности в open source?
5. Есть ли у вас ключевое контактное лицо для взаимодействия с open source контрибьютерами и разрешения сложных вопросов?
Мнения экспертов
В качестве завершения на сегодня — поговорил с теми, кто обладает опытом работы над собственными открытыми проектами и не только. Коротко обсудили, как коллеги подходят к выбору лицензий для разработок, и что думают об open source в России.
Как вы подошли к выбору лицензии для open source версии продукта?
Как в целом вы оцениваете перспективы open source в России?
Весьма актуально.
Благодарю за статью.
Подписался.
Большое спасибо!
Комментарий удален модератором