Открытое ПО в России — что изменилось к 2023 году

О значении Open Source для российского рынка говорит тот факт, что больше половины решений в реестре отечественного ПО написано с использованием открытого кода, отметили в фонде «Сколково». По другим оценкам, доля ИT-продуктов с опенсорс-элементами в реестре может достигать 85%. К 2026 году 92% российских компаний будут использовать решения на базе Open Source.

Открытое ПО может оказаться под капотом практически любого решения: не все разработчики ставят об этом в известность своих заказчиков. К примеру, они могут использовать библиотеку десятилетней давности, решив не тратить деньги на обновления. Это чревато наличием уязвимостей, некоторые из них способны привести к серьезным потерям для бизнеса.

Однако к стандартным рискам, связанным с Open Source, в 2022 году прибавились новые — специфичные для российских компаний. Оценить их и понять глубину проблемы в каждом конкретном случае помогут ответы на несколько вопросов.

Вопрос первый: насколько свободен Open Source?

Многие зарубежные поставщики ИT-решений ушли из России — некоторые сделали это быстро, другие дали время на адаптацию и сворачивают деятельность постепенно. Могут ли прекратить работу на российском рынке опенсорсные продукты? Могут.

Приведу в пример Apache Software Foundation (ASF). Эта организация занимается развитием популярных в мире и в России решений для разработчиков: инструментов для работы с большими данными Airflow, Hadoop, Flink и Kafka, системы управления базами данных CouchDB, программы для нагрузочного тестирования Jmeter. Их использует практически весь ИT-сектор, включая ИT-департаменты крупных компаний в России.

Несмотря на слово «фонд» в названии, Apache Software Foundation — это компания, у которой есть совет директоров, генеральный директор, счет в банке, налоговая отчетность и самое главное — юридический адрес. Компания, являясь международной, зарегистрирована в юрисдикции определенного государства. В случае с ASF это США.

У Соединенных Штатов есть возможности влиять на политику американских компаний. Например, «сверху» может поступить указание изменить лицензию, регламентирующую использование решений ASF. Сейчас она одна из наименее строгих — можно использовать, распространять и продавать продукты на основе открытого кода практически без ограничений. Однако вполне может появиться запрет применять решения компании для пользователей из России или других государств.

Например, юристы отмечают, что во многих лицензиях предусмотрен пункт о санкциях — США и ЕС могут запретить использование ПО с открытым кодом или архитектурой, которое развивает организация из этих стран, в рамках технологических ограничений для подсанкционных стран.

Еще в сентябре 2021 года президент группы компаний InfoWatch, председатель правления АРПП «Отечественный софт» Наталья Касперская и глава компании «Ашманов и партнеры» Игорь Ашманов опубликовали открытое письмо о рисках использования открытых технологий. По их данным, руководство Open Source-проектов всегда имеет тесные связи с руководством крупнейших американских ИТ-корпораций, которые участвуют в определении их стратегии и политики развития. Например, IBM регулярно финансирует Linux-сообщество (Linux — операционная система с открытым исходным кодом. — «РБК Тренды»): начиная с 2000 года и в начале 2023 года объявила о выделении $1 млрд на поддержку Linux и других связанных с этой операционной системой открытых технологий.

Кроме того, разработчики могут закрывать доступ к своим опенсорс-решениям по собственной инициативе. Так, скандинавский разработчик софта Qt Group в марте 2022 года заблокировал загрузку продуктов с российских IP-адресов и убрал поддержку русского языка с сайта. Qt — это открытая программа, которая упрощает создание и поддержку технически сложных или нагруженных приложений.

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

Вопрос второй: как распространяется открытое ПО?

Исходный код проектов (то есть конкретных программ, например Apache Hadoop или LibreOffice) размещается на GitHub — главной площадке мирового Open Source-сообщества. Исполняемый код (адаптированный под понимание компьютером) выкладывается на отдельных сайтах проектов.

Блокировка аккаунтов на сайтах проектов неприятна, но не страшна: есть способы получить необходимые для разработки решения пакеты и без учетной записи. А вот отключение от GitHub может быть довольно болезненным — такие прецеденты уже случались.

Нюанс в том, что этот портал — это не просто хранилище исходного кода. Он содержит большое количество многокомпонентных сервисов, которые связаны друг с другом. Они показывают всю историю развития кода: кто и когда внес изменения, зачем это было сделано, какую проблему решали. Отключение от этого инструмента, который является стандартом работы с исходным кодом всего мирового открытого ПО, станет большой проблемой.

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

При этом страдает не только компания, которую заблокировали, но и все сообщество: продукт не получит полезных для других пользователей доработок.

Вопрос третий: как поддерживается открытое ПО?

В рамках комьюнити поддержка открытого ПО бесплатна, но не гарантирована. Нет SLA (Service Level Agreement, соглашение об уровне предоставляемых услуг. — «РБК Тренды») по времени и качеству ответа. Чаще всего ответ приходит полезный и в разумные сроки, но так происходит не всегда.

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

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

Ситуация с техподдержкой опенсорс-решений такая же, как и с поддержкой зарубежного ПО и оборудования. Почти 70% компаний без сервиса вендоров столкнулись с различными проблемами, показал недавний опрос компании КРОК. До 2022 года почти половина российских компаний использовали прямую поддержку разработчиков. Сегодня им пришлось переориентироваться на поддержку собственными командами (49%) или оплачивать услуги российских партнеров (33%).

Вопрос четвертый: серьезны ли риски осознанной порчи кода?

Еще несколько лет назад казалось, что это невозможно. Сейчас это наша новая реальность. Причем она не связана исключительно с Россией: разработчики добавляют вредоносные закладки и портят собственный код по разным причинам, чаще всего в качестве протеста против неоплачиваемой работы.

Например, осмысленная порча популярных Open Source-пакетов faker.js и colors.js их автором в начале 2022 года нарушила работу тысяч приложений. Речь идет о программах для платформы разработки серверных и сетевых решений Node.js, первая генерирует случайные данные для тестирования приложений, вторая окрашивает символы в консоли для улучшения читаемости. Разработчик пакетов Марак Сквайрс объяснил свой поступок нежеланием бесплатно поддерживать корпорации.

Прецедентов достаточно, чтобы серьезно относиться к этому риску. В конце 2022 года «Лаборатория Касперского» сообщила, что обнаружила десятки скомпрометированных пакетов Open Source, загруженных десятки тысяч раз. Доля критических уязвимостей в таких решениях достигает 10%, опасных — 35%.

Однако российским компаниям нужно быть вдвойне осторожными. Есть случаи, когда открытое ПО целенаправленно нарушало работу систем пользователей из России.

Еще в марте 2022 года российские разработчики стали вести список открытых программ, которые недружелюбны к российским разработчикам. Сейчас в нем больше 30 опенсорс-проектов — они несут реальную угрозу информационной безопасности. Кроме того, указаны почти 250 проектов, которые заблокировали российские аккаунты или отказали в обслуживании.

Например, разработчик популярного пакета NPM node-ipc (это менеджер пакетов для языка программирования JavaScript) в марте 2022 года выпустил вредоносные версии библиотеки в знак протеста против конфликта на Украине. Они содержали код, который перезаписывал или удалял произвольные файлы пользователей из России и Беларуси благодаря считыванию IP-адреса системы.

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

Что делать?

Очевидно, что продолжать работать с открытым ПО как ни в чем не бывало уже не получится. Закрываться внутри страны, работая только на своей инфраструктуре, создавая аналог GitHub, обучая собственных программистов, неэффективно. На это потребуется слишком много времени и ресурсов, а разница в компетенциях и уровне развития технологий будет расти. Появится разрыв между версиями продуктов, а соединить их — огромный труд.

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

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