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

Отечественные технологические компании, вузы и другие организации все чаще обращают внимание на тонкости работы с open source и задумываются о распространении собственных решений в открытом формате [об этом говорят свежие отчеты, которые мы рассмотрим далее]. Однако с точки зрения понимания специфики работы с open source и соответствующими рисками [взять хотя бы тренд на source available] бизнесу и госучреждениям еще предстоит сформировать ключевые корпоративные компетенции.

Посмотрим, какие аспекты выделяют зарубежные и российские аналитики, а также — по традиции — обсудим проблемы с представителями отечественного ИТ и не только.

Фотография — Andrew Gook — Unsplash License

Фотография — Andrew Gook — Unsplash License

Расскажите менеджерам

Один из отчетов о положении дел в сфере открытого программного обеспечения — 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 разработки и центров экспертизы в этой области. Роль таких центров могут играть, например, вузы. При наличии поддержки со стороны индустрии, разумеется.

2c52fc0071162bcd2ecad896be1d17ee.jpgАлександр Нозик

директор Центра научного программирования МФТИ

Откройте ваш «велосипед»

Другой отчет — 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.

9187d9e3dbb9cf63311e90cf09322fb8.jpgЮрий Кацер

автор тг-канала DataKatser, Lead DS в Рокет контрол

«Горшочек, не вари!»

Неудивительно, что вопросы, связанные с лицензиями на 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% респондентов.

При этом по данным еще одного свежего отчета, на этот раз подготовленного Институтом изучения мировых рынков (ИИМР), более 70% опрошенных представителей российских компаний-разработчиков и потребителей ПО рассматривают запуск коммерческих решений с открытым кодом. Примечательно, что — помимо нехватки общих корпоративных компетенций — развитие российского open source сдерживает недостаточное внимание к сообществам вокруг технологических продуктов.

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

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

1ec8c384e68f5ec3730bdc3cdfff04d7.jpgИван Панченко

заместитель генерального директора 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 среде, где приняты эксперименты, диалог с комьюнити и выработка решений в зависимости от контекста.

Habrahabr.ru прочитано 1622 раза