«OSS, который не смог» — почему нельзя так просто взять и использовать open source вдолгую

TrueCrypt развивался на протяжении десяти лет, но в 2014 году авторы объявили, что сворачивают проект. На его сайте появилась плашка, что код утилиты небезопасен, вместе с подробной инструкцией по миграции на альтернативное решение (BitLocker от Microsoft). Тогда же вышла последняя версия утилиты, из которой убрали возможность шифрования данных, оставив только функции дешифровки.

Винсент Квинт говорит, что его команда хотела предоставить пользователям возможность не только получать информацию из интернета, но и генерировать контент самостоятельно. В этом состояло главное отличие Amaya от других веб-инструментов того времени вроде Mosaic.

Проект Квинта развивался под эгидой W3C почти 20 лет, но в 2013 году его закрыли. Основатели консорциума пересмотрели свою политику — их уже не так интересовало экспериментальное ПО, поэтому финансирование подобных инициатив сократили.

После ареста основателя компания Namesys прекратила свою деятельность, однако разработка ReiserFS продолжилась ее сотрудниками и другими добровольцами. Но даже несмотря на усилия энтузиастов, проект начал угасать. В 2022 году на форумах стали появляться треды о том, что интерес аудитории к системе потерян и, возможно, скоро ее перестанут поддерживать.

Приходилось и постоянно приходится сталкиваться с подобными ситуациями. Замена версии ПО по причинам безопасности — это довольно частое событие. В мире ПО не предусмотрена многовековая работа на одной версии, и если кто-то так ведёт бизнес, ему будет больно. Постоянно обновлять ПО — это единственный возможный путь ;) другого просто нет. Поэтому тот, кто уже так делает, вряд ли столкнется с гигантскими проблемами с миграцией open source куда-либо.

Есть ещё один момент: опенсорс можно форкнуть и развивать самому, это могут сделать представители сообщества, как было с TrueCrypt (его замена — VeraCrypt). Поэтому вероятность найти выход в мире опенсорс чуть больше, если сравнивать с банкротством компании-разработчика какой-то закрытой технологии.

В целом риск я вижу только один — возможность внедрения закладок, но это решается путем создания доверенных сборок и репозиториев, которые проверяют код на безопасность и закладки. Остальные риски открытого ПО (необходимость наличия сотрудников с необходимыми компетенциями, исчезновение этого ПО, сложность поддержки, отсутствие полной документации, отсутствие гарантий) вполне решаемы квалифицированными ресурсами, либо коммьюнити (пример MySQL->MariaDB, TrueCrypt->VeraCrypt, gogs->gitea, OpenOffice -> LibreOffice).

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

Каких-то неочевидных рисков мы не видим. Однако хотелось бы отметить риск того, что субъекты КИИ часто переходят на те технологии, которые недостаточно хорошо обеспечены локальными компетенциями. В результате этого, например, в объектах КИИ или ещё в каких-то чувствительных областях могут быть внедрены технологии, которые не выдержат испытания временем и, как в описанных в статье примерах, перестанут развиваться.

Из самых свежих историй, связанных с рисками, — блокировка доступа к сервисам Docker Hub с российских IP. При этом при использовании недоверенных зеркал и методов обхода блокировок высок риск получить вместе с новыми технологиями какие-то закладки-вредоносы или оказаться подверженным другим угрозам.

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

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

Некоторые компании не понимают модели лицензирования и силы, стоящие за тем или иным продуктом. Из-за этого они могут попытаться сделать форк проекта, который в дальнейшем будет невозможно развивать. Например, несколько российских компаний сделали свой форк популярного проекта Dremio, которые является open core, а не open-source (то есть у проекта нет открытого процесса разработки и сообщества, есть только код, который можно прочитать). В результате компании тратят деньги на форки, которые заведомо невозможно должным образом поддерживать.

Другие компании, обжегшись на уходе коммерческих вендоров, объявляют, что их стратегия теперь: «используем только open-source проекты». При этом данные компании как правило не осознают реальную стоимость развития и поддержки таких проектов, которая обычно измеряется в десятках и сотнях миллионах рублей в год.

Поэтому через некоторое время после сегодняшней эйфории в духе «мы свободны, все под нашем контролем» придет осознание реальности: нужные фичи не появляются, некому оперативно исправить баги и т.д. В итоге большинство компаний, которые сейчас делают ставку на «только open source» проиграют стратегически, так как не смогут поддерживать должный темп разработки. Для преодоления этой проблемы нужно вернуть доверие компаний к вендорам, но уже не западным, а российским.

А последние, к слову, не прочь заработать быстрых денег в условиях резко образовавшегося дефицита предложения. Это выливается в необоснованный рост цен и большое количество форков open source проектов, в которые компании-разработчики практически ничего не вкладывают. Потребуется время, что бы все участники процесса — вендоры и компании-потребители — нашли правильный баланс для успешного развития технологий.

Есть еще один риск — покупка open source и изменение вектора развития. Пример MySQL, Nginx показал, как это может быть. Риски конечно же есть, как и в любом ПО, даже в проприетарном не все гладко. Если говорить о мировой практике, то обычно, если ПО востребовано, то появляются форки, для примера: OpenSearch, MariaDB, Rocky Linux. Для большой компании поддерживать свой форк открытого ПО не составит проблем. А если нет нужды или средств, то переход на конкурирующий софт, благо обычно есть несколько альтернатив.

Мы в EdgeCenter были перед выбором, на какой диструбитив перейти после того, как RedHat отказалась от Centos. В рабочем порядке переустановили на всех серверах Centos на Stream 8 и не спеша размышляем о переходе на Ubuntu.

Мы — как инвесторы — не очень жалуем open source решения стартапов в силу того, что заработок на такой модели зачастую не так очевиден, либо отложен. Да, есть много успешных примеров вроде Nginx и других, а также Postgres Pro, которые показали, что в России можно делать очень успешный бизнес на базе open source с выручкой в миллиарды рублей. Однако сам по себе подход на основе открытых технологий требует стать достаточно популярным и компетентным в свой сфере, а только потом дает возможность строить бизнес, а не проект для души.

На заре компании Naumen, где я выступаю в роли акционера и председателя совета директоров, мы начинали работу в парадигме open source одни из первых в России. Но 23 года назад это было совсем тяжело. Клиенты брали бесплатно софт, а услуги не заказывали, потому что «все и без этого работает». Либо хотели доработок без оплаты. В те времена я даже делал Naumen Public License и верифицировал ее в OSI, но сейчас компания не выпускает продукты по open source лицензиям. В целом в российском корпоративном мире capex (капитальные затраты) чаще даются заказчику гораздо проще, если сравнивать с оплатой подписки или услуг, а 20+ лет назад покупка лицензии была самой понятной статьей в ИТ-расходах.