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 технологий.
Также необходимо точнее формулировать предложение для аудитории и контрибьютеров (что именно вы распространяете: общедоступный код, что-то еще), по возможности избегая множества возможных трактовок.
Кстати, если говорить о 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 версии продукта?
Если говорить простыми словами, то нашу enterprise-версию можно использовать при наличии договорных отношений между нами и заказчиком, а community-версия не имеет такого ограничения. Также есть определенные ограничения по модификациями и повторному использованию в тех или иных целях, например, примитивная переупаковка нашего кода в свой продукт будет нарушением условий лицензии. В целом community версия позволяет получить представление о наших продуктах. Однако после изучения решений посредством таких лицензий, наши заказчики переходят на enterprise-лицензии. [Интервью по теме — здесь.]
Обычно у open source есть три вектора. Первый — это pet-проекты. Второй — вклад в коммьюнити, создание бесплатных библиотек, из которых можно брать модули и встраивать в свои продукты. Это делает жизнь других инженеров проще. И третий вектор — открытие части или всего исходного кода коммерческих продуктов, чтобы код могли проверить на безопасность, убедиться, что там нет уязвимостей или самостоятельно модифицировать программу под потребности компании. Мы пошли по третьему пути и выбрали лицензию, которая позволяет покупателям модифицировать код серверной части (при этом клиентская часть останется проприетарной — она несет в себе коммерческую функцию, которая обеспечивает команду ресурсами на развитие продукта).
Выбрали GNU General Public License v3.0 по трем причинам. Во-первых, наш backend-проект использует ряд сторонних библиотек, каждая из которых покрыта GNU-совместимыми лицензиями. Например, GNU LGPL v2.1, GNU LGPL v3.0, GNU GPL v2.0, GNU GPL v3.0. Это обязывает нас использовать такую же или совместимую лицензию для нашего проекта. Во-вторых, при использовании GNU GPLv3 исходный код продуктов на основе нашего проекта НЕ может быть закрытым, так как наш исходный код открыт. В-третьих, менее строгие лицензии, как MIT, MPL, Apache 2.0, нам не подошли. Rocket.Chat и Mattermost используют MIT/Apache 2.0, но это уже полноценные open source проекты, а наша цель на данный момент — аудит кода и возможность его модификации.
Обычно под open-source подразумеваются серверные решения, но не мобильные или десктопные клиенты. Чтобы в современном мире создать качественное и конкурентоспособное приложения для iOS/Android, нужна большая команда с product owner'ом, дизайнерами-разработчиками интерфейса, тестировщиками и высокооплачиваемыми инженерами. На содержание такой команды и, соответственно, развитие продукта, нужны ресурсы. Поэтому инвестиции в коммерческую версию продукта — это гарантия, что приложения будут качественными, удобными и стабильными. Так как речь о корпоративных коммуникациях и сотнях сообщений в день, баги и ошибки, которые случаются, например, в приложениях Mattermost, это недопустимая история.
CEO корпоративного мессенджера Compass
Как в целом вы оцениваете перспективы open source в России?
Перспективы опенсорс-разработки в России кажутся весьма обещающими. Опенсорс-проекты в России сейчас перерождаются, в частности благодаря новому подходу от технических директоров и разработчиков, которые теперь обращаются к нему с более прагматической точки зрения, при сохранении романтической идеи открытого исходного кода. В целом опенсорс-сообщество в России сталкивается с теми же проблемами и позитивными аспектами, что и в мире. Один из основных позитивных факторов — увеличение размера сообщества и ускорение распространения информации внутри него.
Современные технологии общения и рекомендательные системы способствуют быстрому распространению проектов среди заинтересованных пользователей и контрибьюторов, создавая основу для прогресса. Если смотреть на каком-то таком историческом горизонте, мне кажется, что опенсорс в России сейчас переживает определенный ренессанс. Это связано с тем, что он был несколько романтической идеей, реализуемой скорее из каких-то высоких материй и убеждений. Потом был период, когда люди обнаружили ряд проблем, многие технические директора и разработчики более трезво научились смотреть на опенсорс. Сегодня они начинают заниматься всем этим из более прагматичных соображений, лучше понимая плюсы и минусы, а не только романтическую составляющую, которая, к слову сказать, не ушла. Многие разделяют первоначальные идеи опенсорса, но повзрослели и более трезво смотрят на мир. Поэтому, мне кажется, что сейчас, идет некий подъем опенсорс на этой волне.
В России культура создания open source продуктов только начинает развиваться. На данный момент рынок open source в России от общего числа проектов составляет не более 1-2%. Учитывая текущую ситуацию, интерес российских компаний к open source продуктам еще вырастет.
Сейчас более 85% IT-компаний на российском рынке в том или ином виде уже используют open source решения. Это значительный драйвер роста для компаний, которые планируют или уже разрабатывают open source продукты.
CEO корпоративного мессенджера Compass
Мы работаем над новыми программными решениями в области анализа больших данных, и они, конечно же, опираются и на open source разработки, что является абсолютной нормой в российской и мировой практике.
С учетом массового ухода западных поставщиков проприетарных продуктов стоит ждать быстрого развития культуры работы с open source в России, в том числе появления российских вендоров открытого программного обеспечения. Такая работа уже идет, также формируется практика разработки российских лицензий.
Кстати, эффективные решения, например, в области анализа больших данных, вполне могут появиться не только в ИТ-компаниях, но и в российских научных коллективах. В мировой практике есть множество примеров, когда сотрудники лабораторий университетов объединялись и выпускали прорывные продукты, в том числе в формате open source, взять хотя бы Apache Spark.
Сегодня, когда многие зарубежные компании и разработчики закрыли для себя российский рынок, оставив российских пользователей вне привычного технологического стека, когда санкционное давление на отечественную ИТ-отрасль увеличивается с каждым днем, роль открытого программного обеспечения становится все более значимой. Открытый исходный код как основа имеет потенциал для замены значительной части иностранного ПО, которое уже ушло или может уйти с российского рынка. Это справедливо как для разработчиков, активно использующих открытый исходный код при создании проектов для замены зарубежных аналогов, так и для потенциальных заказчиков или пользователей, ищущих замену решениям, которые уже ушли или могут уйти с российского рынка.
Важно отметить, что одного кода недостаточно: необходимо также обладать навыками его поддержки и развития на местном уровне. В связи с этим, юридическая чистота разработки, корректное использование и соблюдение требований актуальных лицензий становятся критически важными вопросами. АНО «Открытый код» в прошлом году опубликовала ряд аналитических материалов, посвященных корректному выбору лицензий и соблюдению лицензионных требований. В этом году планируется подготовить методические рекомендации для разработчиков открытого кода и других заинтересованных лиц, затрагивающие вопросы лицензионной гармонизации: принципов создания лицензий для ОСПО, корректного использования терминов, принципов перевода и согласования текста лицензий (как на русском, так и на иностранных языках).
Весьма актуально.
Благодарю за статью.
Подписался.
Большое спасибо!