Проблемы коммерческого Open Source - фейковые разработчики, безопасность и санкции
Об этом говорится в исследовании Института изучения мировых рынков (ИИМР), представленного журналистам 18 марта. Сотрудники ИИМР опросили более ста представителей крупных российских компаний как с госучастием, так и без.
ПО данным исследования, объем глобального рынка Open Source по итогам 2022 г. достиг $25-28 млрд (по разным оценкам), а к 2027 г. выручка в этом сегменте удвоится. В то же время, российский рынок развивается в уникальных условиях: на фоне ухода западных вендоров проприетарного ПО и при острой необходимости оперативно импортозамещать продукты в критически важных отраслях, уже через два года доля решений на основе открытого кода в общем объеме софта, используемого корпоративными клиентами, составит две трети - по 32% коммерческого и условно-бесплатного Open Source соответственно. Если учитывать проприетарные продукты, в коде которых есть элементы открытых решений, то вместе с официальным Open Source доля такого софта составит минимум 90%.
Год назад ситуация был противоположной. 81% составлял проприетарный софт (в том числе и от российских компаний), 4% и 15% приходилось на коммерческий и бесплатный Open Source соответственно.
На конец 2023 г. соотношение было таково: 61% - проприетарный софт, 12% - коммерческий Open Source, 27% - бесплатные программные продукты с открытым исходным кодом.
Руководитель аналитической группы ИИМР Святослав Бочаров, представивший эти данные, рассказал, что большинство - 23,9% опрошенных - назвали в качестве преимущества коммерческого открытого ПО отсутствие риска ухода его производителя с российского рынка. 12,7% - понравилась возможность дорабатывать ядро продукта. По 10% опрошенных компаний ценят соответственно соотношение цена/качество софта, возможность быстро сменить вендора, вносить изменения в коммерческий открытый софт в диалоге с вендором и возможность технической поддержки (традиционно сильной стороны коммерческого Open Source).
Отрицательные стороны коммерческого Open Source - отсутствие специалистов, высокая стоимость перехода и даже сопротивление сотрудников - такую причину сложностей с открытым софтом назвало 17,9% опрошенных.
Большинство компаний, которые радикально против коммерческого Open Source, называют такие причины, по которым не планируют его внедрять: отсутствие подходящего продукта (27,3%), отсутствие сотрудников с необходимым уровнем экспертизы (22,7%), отсутствие адекватной системы поддержки и обновления у вендоров (20,5%).
По данным исследователей, у коммерческого Open Source есть не только проблемы с его восприятием потенциальными пользователями, но репутационные сложности, которые создают фейковые разработчики, радикально настроенные антироссийские "хактивисты", которые - невиданное дело в Open Source - "ввели санкции" против российских пользователей, и дискриминация России на признанных международных площадках и репозиториях, вроде GitHub и GitLab.
Фейковые разработчики, наследники Дениса Попова с его BolgenOS, ставшего персонажем мема, занимаются тем же, что и их духовный вдохновитель - продают открытый бесплатный продукт с минимальными модификациями под видом серьезного ПО. При этом они не подвергаются обструкции и высмеиванию, как некогда Попов, наоборот, многие из них входят в Реестр российского ПО, как вполне добросовестные вендоры, со всеми преимуществами близости к госбюджету.
Эксперты сошлись в мнении, что лучшим средством борьбы с этим явлением станет проверка продуктов новых членов сообщества на процентное соотношение изначального открытого кода и модификаций вендора. При этом эксперты отметили, что нужно не перегнуть палку и хорошо зарекомендовавших себя производителей проверками не мучить.
Проблему отказа западных репозиториев работать с российскими разработчиками, а также варианты возможного импортозамещения таких сервисов, прокомментировала корреспонденту ComNews и. о. директора АНО "Открытый код" Надежда Кострюкова.
"Создание "российских GitHub" - это тренд отечественного ИТ-рынка. Первым о выходе на рынок, насколько я помню, заявил GitFlic (gitflic.ru), за ним вышел Mos.hub (hub.mos.ru), решение разрабатывает "Ростелеком" - это репозиторий "Феникс" в рамках экосистемы "Лукоморье", репозиторий "Сфера" от компании "Т1 Диджитал". Сбербанк только недавно выпустил бета-версию репозитория, МТС движется в этом же направлении, Институт системного программирования им. В. П. Иванникова Российской академии наук (ИСПРАН) поддерживает доверенный репозиторий, платформа "Сизиф" от компании "Базальт" функционирует уже несколько лет и еще ряд, в основном от крупных компаний. Таких репозиториев, с разной функциональностью и под разные задачи, - достаточное количество", - рассказывает Надежда Кострюкова.
По ее словам, два года назад намечался проект создания национального репозитория, но идея себя изжила, точнее, должна быть модифицирована согласно новым реалиям.
"На взгляд нашего экспертного сообщества, нужен не еще один репозиторий - национальный или любой другой - а надстройка над уже существующими репозиториями, которая позволит собрать сообщество. Оно и будет выбирать, в каком из репозиториев хранить код (и, может быть, обмениваться кодом с другими репозиториями), делиться знаниями. На этой площадке может быть собрана информация о конкретных разработчиках, их портфолио. Мелкие компании не могут позволить себе привлечь в инхаус специалистов высокого уровня. Такая платформа дала бы возможность компаниям с небольшим финансовым плечом привлечь разработчиков на конкретные проекты, поскольку у них будут знания об их возможностях", - считает и. о. директора АНО "Открытый код" Надежда Кострюкова.
Санкции, по ее информации, в Open Source действительно существуют несмотря на то, что они, казалось бы, против самой идеи свободного ПО.
"Это началось с приложений Сбербанка и Альфа-банка. Они первые пострадали еще в марте 2022 г. И это продолжается. Были определенные высказывания со стороны владельцев-операторов площадок (не все они были претворены в жизнь). Тем не менее, доступ к нескольким Open Source-продуктам был заблокирован. Эта практика существует и сейчас. Например, твой код размещен на GitHub, вдруг к тебе приходит "письмо счастья" о том, что он "убран в архив" и у тебя есть неделя, чтобы его свернуть и перенести в другое место, иначе он станет навсегда недоступен. Пока это явление не носит массовый характер, скорее точечный, хотя атака на российские банки два года назад носила системный характер. Такое поведение зарубежных платформ дает четкий сигнал российским разработчикам использовать российские площадки. Минимум, пока на них еще мало аудитории, держать на них зеркала продуктов с GitHub, чтобы в одночасье не лишиться результатов труда", - подытожила Надежда Кострюкова.
Главный исследователь безопасности открытых операционных систем Positive Technologies Александр Попов рассказал корреспонденту ComNews о способах безопасного пользования программным обеспечением с открытым исходным кодом. Ранее в выступлении он рассказал о "закладках", которые антироссийски настроенные программисты могут помещать в код открытого ПО.
"Скорее это не "закладки", а намеренные диверсии против российских пользователей. В ряде случаев в открытые проекты проникали так называемые "хактивисты" и внедряли в них коммиты, которые, например, выполняют вредоносные действия для пользователей с российскими IP-адресами или выводили баннеры с обидными словами про нашу страну. Коммиты - изменения в открытом коде, которые проходят незаметными в процессе ревью - проверки конечного продукта. За проект отвечает его мейнтейнер (куратор). Бывает, что он сам придерживается радикальных взглядов и сознательно пропускает вредоносные коммиты, а бывает так, что он просто их проглядел. Поэтому крайне важно повторно проверять ПО, которые ты используешь в продукте - делать двойное ревью", - советует Александр Попов.
Второй путь, который позволит не допустить вредоносный код в домашнюю разработку - контроль цепочки поставки, рассказывает представитель Positive Technologies.
"Разработчик не пишет весь код для конечного продукта. Что-то отдается подрядчикам на аутсорсинг. Какой-то код берется из Open Source. Кроме того, есть программные компоненты, которыми пользуется разработчик, но они не входят в конечный продукт. Компиляторы, например. Очень важно контролировать, какими инструментами ты пользуешься, откуда их взял. Есть технические средства, которые позволяют контролировать эти инструменты. Без этих средств ты не можешь получить сертификацию, отследить, обновлены ли у тебя все библиотеки, тебя могут взломать через уязвимость в каком-то необновленном компоненте. Эти способы можно масштабировать для работы с репозиториями и облачными решениями. Если вы их применяете, то может чувствовать себя более-менее спокойно", - подытожил Александр Попов.
