Отечественные технологические компании, вузы и другие организации все чаще обращают внимание на тонкости работы с open source и задумываются о распространении собственных решений в открытом формате [об этом говорят свежие отчеты, которые мы рассмотрим далее]. Однако с точки зрения понимания специфики работы с open source и соответствующими рисками [взять хотя бы тренд на source available] бизнесу и госучреждениям еще предстоит сформировать ключевые корпоративные компетенции.
Посмотрим, какие аспекты выделяют зарубежные и российские аналитики, а также — по традиции — обсудим проблемы с представителями отечественного ИТ и не только.
Расскажите менеджерам
Один из отчетов о положении дел в сфере открытого программного обеспечения — 2024 State of Open Source Report — вышел в феврале этого года. Его подготовили аналитики OpenLogic — специализированной консалтинговой фирмы с экспертизой в области open source, являющейся «дочкой» Perforce Software — компании-разработчика платформы для анализа кода и контроля версий. Также отчет поддержали в Open Source Initiative.
Результаты были получены на основе опроса 2 тыс. сотрудников организаций, использующих программное обеспечение с открытым исходным кодом. Половина респондентов занимала должности системных администраторов, разработчиков, инженеров и архитекторов. 17% опрошенных были тимлидами или менеджерами. Чуть менее 5% оказались руководителями высшего звена. Оставшаяся часть респондентов представилась консультантами, комьюнити-менеджерами или ИТ-евангелистами.
Что примечательно, отчет показал, что многие управленцы плохо представляют, как обстоят дела с внедрением open source в их организациях. Так, 40% руководителей высшего звена заявили, что уровень использования ПО с открытым исходным кодом все еще остается на прежнем уровне. При этом их коллеги, занимающие более «прикладные» должности, охарактеризовали положение дел иначе, отметив рост доли используемых open source технологий.
В целом 95% опрошенных отметили рост объема и значимости open source решений в корпоративном тех. стеке за прошедший год — 33% из них охарактеризовали изменение как «значительное». В основном это были представители крупных компаний со штатом до 5 тыс. сотрудников. Только 5% опрошенных сообщили, что их организации в целом сбавили темпы использования технологических решений с открытым исходным кодом.
Существенная проблема развития open-source продуктов в России — это незрелость культуры разработки и экспертизы в больших корпорациях. Все понимают, что использование и развитие open-source решений экономически выгодно, но все упирается в ответственность за принятие решений. Руководитель среднего звена не может принять решение о том, чтобы использовать тот или иной код или о том, чтобы вложиться в разработку этого кода. Нет практики проведения экспертизы открытых решений, а следовательно, если что, виноват будет тот же менеджер. Куда проще купить коробочное решение, пусть даже сильно дороже. Если что, всегда можно свалить на производителя.
Если экспертиза и производится, то она делается государством. То есть очень дорого, очень долго и очень не гибко, что сводит на нет многие преимущества открытых систем. На мой взгляд развитие open-source экосистемы в России в первую очередь связано с развитием центров культуры open-source разработки и центров экспертизы в этой области. Роль таких центров могут играть, например, вузы. При наличии поддержки со стороны индустрии, разумеется.
Откройте ваш «велосипед»
Другой отчет — 2023 State of Open Standards — подготовили в Linux Foundation и опубликовали прошлым летом. В центре его внимания — открытые стандарты и спецификации. Согласно отчету, такие стандарты спецификации, так или иначе, использует 91% компаний в секторе ИТ. Почти 80% организаций считают, что использование открытых стандартов положительным образом сказывается на их конкурентоспособности, а также инновационной активности (79% и 81% соответственно).
Общедоступность информации позволяет нескольким поставщикам услуг использовать одну и ту же технологию, создавать совместимые или взаимодополняемые решения. Так, компаниям не приходится «изобретать велосипед», а также снижается порог для выхода на рынок новых игроков, и возникает меньше вопросов по информационной безопасности и поддержке, в частности если сравнивать со ставкой на закрытые стандарты.
Похожую логику можно проследить в еще одном аналитическом отчете по теме — The Open Source Sustainability Ecosystem. Его выпустили специалисты Linux Foundation Energy прошлым летом. В целом этот фонд, как можно понять из наименования, поддерживает разработчиков, которые участвуют в совершенствовании открытых технологий, фреймворков и эталонных архитектур, имеющих отношение к энергетическому сектору. Для таких проектов, в частности sustainability-решений, Linux Foundation Energy запустили инкубатор: чтобы способствовать разработке новых открытых и интегрируемых технических интерфейсов и связующего программного обеспечения в этой сфере.
В качестве примера авторы отчёта привели Robotic Operating System. Это — открытая ОС для разработки систем управления роботами с высокой степенью модульности. Стандартизированная архитектура позволяет этому проекту поддержать сотрудничество между сообществами из разных предметных областей. Другой пример — FarmBot с роботизированными платформами для выращивания растений. Его разработчики публикуют документацию и исходный код, поэтому пользователи могут легко объединять решения FarmBot со сторонними модулями и дорабатывать их под свои задачи.
Open-source является ключевым фактором для распространения и внедрения искусственного интеллекта и анализа данных. Прогресс в областях компьютерного зрения (CV) и обработки естественного языка (NLP) обусловлен не только развитием вычислительных ресурсов, но и доступностью открытых данных, наличием значительного количества исследований и открытыми библиотеками.
Однако в промышленности скорость внедрения и развития ИИ значительно ниже, что частично объясняется отсутствием публичных датасетов и ограниченным количеством кода, доступного в open-source. Этот барьер присутствует как в России, так и за рубежом.
В области технической диагностики, например, практически не существует open-source разработок, отсутствует сообщество, а почти все программные продукты являются собственностью западных компаний. После их ухода образовался вакуум, который сложно заполнить. Тем не менее, наблюдается положительная тенденция: отдельные энтузиасты и научные группы, включая Сколтех и ИТМО, продвигают эту область вперёд за счет развития open-source.
«Горшочек, не вари!»
Неудивительно, что вопросы, связанные с лицензиями на open source и проприетарные программные продукты, все чаще поднимают на конференциях и тематических семинарах. Так, количество лицензий, одобренных Open Source Initiative, уже давно перевалило за сотню, и — с учетом тренда на их изменение и «почкование» [при переходе на source available] — разбираться в этом «зоопарке» становится все сложнее.
Эту тему, в частности в контексте работы государственных организаций, затронули составители одного из относительно старых отчетов 2020 года — Building and Reusing Open Source Tools for Government. В этом отчете сотрудники одного из аналитических центров США собрали достаточно подробное и простое для восприятия руководство для госучреждений, желающих внедрить или разработать решения с открытым кодом.
Согласно рекомендациям в отчете, при выборе альтернатив проприетарному ПО стоит не только проанализировать, с чем работают похожие организации, но и обратить внимание на текст лицензии открытого ПО [другой чек-лист есть тут]. Такая лицензия должна быть в публичном доступе, а также ее должны быть способны понять не только юристы.
В России же еще в 2015 году Минцифры утвердило методические рекомендации по использованию свободного ПО (СПО) в деятельности гос. органов. Они содержат сведения о том, каким характеристикам лицензии на ПО должны соответствовать, чтобы эффективно использоваться в деятельности гос. органов. Эти характеристики можно описать как безвозмездность и широкие полномочия в свободе изучать, дорабатывать и распространять программу и ее производные в любой форме и любыми способами. При использовании таких программ, гос. органам рекомендуют ориентироваться именно на свободу распространения и на снижение затрат, которое повлечет использование такого ПО.
Примечательно, что в самих рекомендациях есть ссылка на сайт gnu, а также обязанность гос. органов соблюдать требования, предусмотренные в свободных лицензиях. В целом, рекомендации подсвечивают основные моменты использования СПО, которые могут иметь значения для внедрения их в деятельность гос. органов и являются довольно легкими и понятными.
Формально эти рекомендации являются действующими. Однако сейчас тренд поменялся. Сейчас мы можем видеть уже сформировавшуюся тенденцию использования гос. органами российского ПО, которое включено в реестр отечественного программного обеспечения. Это утверждено рекомендациями Минцифы от 2023 года. И, насколько можно судить, если рекомендации по использованию свободного ПО являются перечнем рекомендательных норм о том, как выгодно и эффективно использовать СПО и срезать косты, то новые рекомендации о переходе на отечественное ПО представляют собой обширный стратегический план, существующий в тенденции импортозамещения.
Новые рекомендации также содержат ограничение на использование СПО (цитата): «При этом рекомендуется не использовать свободно распространяемое ПО, исключительные права на которое принадлежат физическим лицам или организациям, странами происхождения которых являются иностранные государства, совершающие (совершившие) в отношении Российской Федерации, российских юридических лиц и физических лиц недружественные действия, либо находящихся под юрисдикцией таких иностранных государств, прямо или косвенно подконтрольных им либо аффилированных с ними (далее - недружественные государства)».
Тем не менее, это не значит, что свободные и открытые лицензии больше не в почете. Формально СПО из не-недружественных государств может использоваться так же, как это указано в рекомендациях от 2015 года. При этом, ПО, включенное в реестр отечественного ПО также может распространяться на основе открытых/свободных лицензий или содержать в себе элементы кода по открытой/свободной лицензии. На это также указывают методические рекомендации ЦИКТ. Основным критерием для наличия таких элементов в коде программы включенной в реестр является соблюдение прав третьих лиц. Но, как показывает практика, некоторые ОС-программы могут быть нежелательными для включения в российское ПО из-за экспортных ограничений.
В целом инициатив, способствующих работе с open source лицензиями, в мире становится все больше. Одну из них поддерживает немецкая организация Open Source Automation Development Lab eG (OSADL), с которой сотрудничают крупные автопроизводители, фармацевтические компании, разработчики ПО и университеты. OSADL занимается как прикладными проектами, вроде «идеального» промышленного дистрибутива Linux, так и публикацией материалов, например, open source чек-листов.
Open source в России
Около 70% специалистов — из более чем 600 респондентов прошлогоднего исследования — считают, что российские организации и бизнес должны участвовать в работе open source экосистемы страны. Однако о какой-либо системной деятельности в этой области от имени своих организаций пока говорят лишь 15% респондентов.
Во всем мире опенсорс давно стал значимой частью IT-отрасли. В разных странах периодически выходят исследования, которые подтверждают это и дают представление о состоянии, демографии и различных аспектах использования опенсорса в мире. Их проводят как независимые сообщества, так и коммерческие компании, такие как Redhat. Однако в нашей стране сложно оценить масштабы сообщества, долю в отечественном IT и состояние опенсорса из-за разрозненности источников и недостатка информации. А эксперты неоднозначно оценивают уровень его развития. Мы столкнулись с этой проблемой, работая над текстами про опенсорс. Поэтому решили провести собственное независимое исследование, целью которого было понять, кто и зачем сегодня занимается опенсорсом в стране, выяснить мотивацию участников опенсорс-движения и проблемы, с которыми они сталкиваются.
Так как настолько масштабных исследований в России еще не проводилось, мы сами с нуля разработали концепцию, придумали вопросы и логику анкеты, нашли экспертов, провели интервью. Материала собрали очень много, уместить все в итоговый формат было невозможно, поэтому мы рассказали о самом главном и важном, на наш взгляд.На всех этапах работы мы консультировались с социологом. Вместе с ним мы составляли вопросы, корректировали логику анкеты и варианты ответов, отбирали валидные анкеты, анализировали результаты и делали выводы.
Исследование состояло из анкетирования и опроса экспертов по актуальным вопросам. На этапе анкетирования мы рассылали опросник по крупным компаниям, опенсорс-проектам и тематическим сообществам. Одной из сложностей, с которыми мы столкнулись, стало недоверие и скептицизм как со стороны независимых разработчиков, так и со стороны компаний. Среди разработчиков некоторые подозревали, что мы аффилированы с государством, преследуем интересы какой-то компании или пытаемся собрать личные данные. Некоторые компании также отнеслись к нам с недоверием и отказались от участия из-за опасений, что это может повлиять на их репутацию. Они также опасались, что информация, полученная в рамках анкетирования, может быть использована против них или их сотрудников. Несколько экспертов по этой же причине отказались давать интервью.
Поэтому мне кажется, что проводить больше таких исследований необходимо хотя бы для того, чтобы у участников сообщества повышалось доверие к ним. Возможно, благодаря этому, и между собой они станут проявлять меньше скепсиса в адрес друг друга.
Проанализировав ответы респондентов и поговорив с представителями сообщества, мы сделали вывод, что подобные исследования могут быть очень полезными для представления происходящего с опенсорсом в стране. Даже в экспертной среде нет единого мнения по многим вопросам. Например, нуждается опенсорс в России в популяризации или нет; есть ли «российский опенсорс»; что считать свободным, а что открытым ПО; какую роль в развитии опенсорса может играть государство и так далее. Даже к самому понятию «опенсорс» относятся по-разному: для кого-то это сугубо формальные различия в лицензиях, а для кого-то это уже целая культура и подходы к разработке, которые двигают IT-сферу вперед.
Исследование показало, что остается много вопросов, требующих дополнительного уточнения. Например, мы ожидали, что разработчиков, занимающихся опенсорсом в рамках своих трудовых обязанностей, будет больше. Кроме того, оказалось, что многие разработчики, зная об опенсорсе и даже работая в нем, мало интересуются состоянием и проблемами сообщества в стране. Наше исследование подсветило многие другие проблемы, с которыми сталкиваются люди, занимающиеся опенсорсом в стране.
При этом по данным еще одного свежего отчета, на этот раз подготовленного Институтом изучения мировых рынков (ИИМР), более 70% опрошенных представителей российских компаний-разработчиков и потребителей ПО рассматривают запуск коммерческих решений с открытым кодом. Примечательно, что — помимо нехватки общих корпоративных компетенций — развитие российского open source сдерживает недостаточное внимание к сообществам вокруг технологических продуктов.
Не существует единых требований к работе с открытым софтом, равно как и универсальных стандартов для всех международных сообществ. У каждого из них сложились собственные традиции и принципы, которыми они руководствуются при разработке продукта. Поэтому открытые объединения могут сочетать высокую толерантность в одних вопросах, и жёсткие правила – в других. Адаптация к таким особенностям требует определенной готовности и мотивации у разработчика, но обычно не является непреодолимым препятствием при знании письменного английского языка. Растущая популярность Open Source – тому доказательство.
А вот техническая компетентность разработчиков, действительно, может стать проблемой. С необходимостью публиковать код автоматически появляются высокие требования к его качеству, документированности и т.д. С помощью такой «внутренней» проверки уже на первом этапе отсеиваются низкокачественные и малоценные разработки, которыми делиться будет, как минимум, стыдно. Распространять нужно качественный код, способный объединить вокруг себя разработчиков, сформировать новые идеи и направления. Практика показывает, что большинство IT-специалистов – и российских, и зарубежных – к такому экзамену не готовы.
Иван Панченко
заместитель генерального директора Postgres Professional
С нашей точки зрения — для развития 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 среде, где приняты эксперименты, диалог с комьюнити и выработка решений в зависимости от контекста.
