Управленцы не в курсе, open source в России и борьба с «изобретением велосипедов»: OSS-отчеты и мнения

Что примечательно, отчет показал, что многие управленцы плохо представляют, как обстоят дела с внедрением open source в их организациях. Так, 40% руководителей высшего звена заявили, что уровень использования ПО с открытым исходным кодом все еще остается на прежнем уровне. При этом их коллеги, занимающие более «прикладные» должности, охарактеризовали положение дел иначе, отметив рост доли используемых open source технологий.

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

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

Open-source является ключевым фактором для распространения и внедрения искусственного интеллекта и анализа данных. Прогресс в областях компьютерного зрения (CV) и обработки естественного языка (NLP) обусловлен не только развитием вычислительных ресурсов, но и доступностью открытых данных, наличием значительного количества исследований и открытыми библиотеками.

Однако в промышленности скорость внедрения и развития ИИ значительно ниже, что частично объясняется отсутствием публичных датасетов и ограниченным количеством кода, доступного в open-source. Этот барьер присутствует как в России, так и за рубежом.

В области технической диагностики, например, практически не существует open-source разработок, отсутствует сообщество, а почти все программные продукты являются собственностью западных компаний. После их ухода образовался вакуум, который сложно заполнить. Тем не менее, наблюдается положительная тенденция: отдельные энтузиасты и научные группы, включая Сколтех и ИТМО, продвигают эту область вперёд за счет развития open-source.

В России же еще в 2015 году Минцифры утвердило методические рекомендации по использованию свободного ПО (СПО) в деятельности гос. органов. Они содержат сведения о том, каким характеристикам лицензии на ПО должны соответствовать, чтобы эффективно использоваться в деятельности гос. органов. Эти характеристики можно описать как безвозмездность и широкие полномочия в свободе изучать, дорабатывать и распространять программу и ее производные в любой форме и любыми способами. При использовании таких программ, гос. органам рекомендуют ориентироваться именно на свободу распространения и на снижение затрат, которое повлечет использование такого ПО.

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

Формально эти рекомендации являются действующими. Однако сейчас тренд поменялся. Сейчас мы можем видеть уже сформировавшуюся тенденцию использования гос. органами российского ПО, которое включено в реестр отечественного программного обеспечения. Это утверждено рекомендациями Минцифы от 2023 года. И, насколько можно судить, если рекомендации по использованию свободного ПО являются перечнем рекомендательных норм о том, как выгодно и эффективно использовать СПО и срезать косты, то новые рекомендации о переходе на отечественное ПО представляют собой обширный стратегический план, существующий в тенденции импортозамещения.

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

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

Во всем мире опенсорс давно стал значимой частью IT-отрасли. В разных странах периодически выходят исследования, которые подтверждают это и дают представление о состоянии, демографии и различных аспектах использования опенсорса в мире. Их проводят как независимые сообщества, так и коммерческие компании, такие как Redhat. Однако в нашей стране сложно оценить масштабы сообщества, долю в отечественном IT и состояние опенсорса из-за разрозненности источников и недостатка информации. А эксперты неоднозначно оценивают уровень его развития. Мы столкнулись с этой проблемой, работая над текстами про опенсорс. Поэтому решили провести собственное независимое исследование, целью которого было понять, кто и зачем сегодня занимается опенсорсом в стране, выяснить мотивацию участников опенсорс-движения и проблемы, с которыми они сталкиваются.

Так как настолько масштабных исследований в России еще не проводилось, мы сами с нуля разработали концепцию, придумали вопросы и логику анкеты, нашли экспертов, провели интервью. Материала собрали очень много, уместить все в итоговый формат было невозможно, поэтому мы рассказали о самом главном и важном, на наш взгляд.На всех этапах работы мы консультировались с социологом. Вместе с ним мы составляли вопросы, корректировали логику анкеты и варианты ответов, отбирали валидные анкеты, анализировали результаты и делали выводы.

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

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

Проанализировав ответы респондентов и поговорив с представителями сообщества, мы сделали вывод, что подобные исследования могут быть очень полезными для представления происходящего с опенсорсом в стране. Даже в экспертной среде нет единого мнения по многим вопросам. Например, нуждается опенсорс в России в популяризации или нет; есть ли «российский опенсорс»; что считать свободным, а что открытым ПО; какую роль в развитии опенсорса может играть государство и так далее. Даже к самому понятию «опенсорс» относятся по-разному: для кого-то это сугубо формальные различия в лицензиях, а для кого-то это уже целая культура и подходы к разработке, которые двигают IT-сферу вперед.

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

Не существует единых требований к работе с открытым софтом, равно как и универсальных стандартов для всех международных сообществ. У каждого из них сложились собственные традиции и принципы, которыми они руководствуются при разработке продукта. Поэтому открытые объединения могут сочетать высокую толерантность в одних вопросах, и жёсткие правила – в других. Адаптация к таким особенностям требует определенной готовности и мотивации у разработчика, но обычно не является непреодолимым препятствием при знании письменного английского языка. Растущая популярность Open Source – тому доказательство.

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

С нашей точки зрения — для развития open source в России — необходимо понять, что рассматривать опенсорс исключительно в контексте форков и мифологической «бесплатности» открытых решений, конечно же, невозможно. Когда мы разговариваем с крупными российскими телекомами и ИБ-фирмами, мы видим, что в энтерпрайз-среде все еще распространены подобные заблуждения. Однако без комьюнити и контрибьютерской активности от лица организаций-пользователей открытых решений эта история безусловно не работает. Open source — это река, которая может с легкостью огибать отсыпанные корпоративные «островки», оставляя их далеко позади с точки зрения развития.

Исходя из нашего опыта работы, например, в статусе Linux Foundation Networking ambassadors, могу сказать, что мы наблюдали подобные случаи. За то время, пока люди самостоятельно дорабатывали сложные проекты в области управления сетевой инфраструктурой, их основу, грубо говоря, могли три раза переписать от и до буквально за месяц. Изменения могли быть крайне существенными. Поэтому в нашем восприятии enterprise-grade опенсорс — это в первую очередь про выравнивание относительного основного кода проекта, а во вторую — это контрибьютерская активность. Да, добавлять собственные наработки в upstream и убеждать комьюнити в их необходимости может быть затруднительно, но это — необходимая часть процесса. Если возвращаться к форкам, сложностей может быть еще больше, в частности когда конечной организации-пользователю нужно что-то поправить в проекте. Так заказчик зачастую попадает в ситуацию, когда ему приходится тратить дополнительные средства, время и нервы не просто на доработку, а полноценную разработку необходимого функционала. Отсюда и появляются байки о так называемой «токсичности» опенсорса.

С другой стороны, у нас было множество историй в России, когда заказчики, которые отдали свои деньги за доработку фичи и протащили ее в upstream, в итоге получают ее уже в совершенствованном виде (силами мирового комьюнити) бесплатно. Конечно же, во многом тут влияет и то, на каких исходных позициях находится культура менеджмента в той или иной организации — с чем и как они привыкли работать. Могу сказать, что в рамках сотрудничества с одним крупным облачным провайдером мы потратили около года на адаптацию существенной части ИТ-команды к работе с OpenStack (при переходе с VMware и привычного для них plug-n-play формата). Получатся, что при всем желании менеджмент крупного энтерпрайза часто оказывается не в полной мере готовым к полноценному использованию открытых решений. Для этого ему необходим кто-то, кого можно пинать, перекладывать риски. Однако есть и тип заказчиков, которые что-то развивают в духе технологических евангелистов/пионеров. Конечно же, круг таких людей и организаций достаточно скромный. Управленцев нового класса, которые понимают open source и co-dev, пока мало.

В нашей теме заметное развитие, в том числе с точки зрения адаптации open source технологий, идет в Kubernetes-сегменте. Дело в том, что здесь речь идет о разработчиках, которые естественным образом хотят использовать ровно то, что им удобно использовать, эффективные решения и последние наработки. Такие люди помогают менять «олдскульный» энтерпрайз, который все еще во многом хейтит опенсорс. Они рулят вниманием менеджеров, инфраструктурщиков, безопасников. Это — революционная модель развития опенсорса. Поэтому, если говорить в целом, — нет смысла бороться с open source, но стоит работать с его восприятиям. В энтерпрайз-сегменте имеет смысл отказываться от философии моментальной success story, и работать в формате постоянного НИР, как это всегда и происходит в open source среде, где приняты эксперименты, диалог с комьюнити и выработка решений в зависимости от контекста.