Open source продукты стали жизнеспособной альтернативой проприетарным решениям, покинувшим рынок. Однако российским организациям еще предстоит сформировать компетенции для того, чтобы перейти от операционного «латания дыр» к стратегическому использованию технологий с открытым кодом. Например, задуматься о том, как распространение собственных разработок в таком формате может поспособствовать развитию продуктов и бизнеса.
Также потребуется внимательнее относиться к тренду на изменение лицензий популярных open source продуктов и разобраться с его предпосылками. Последний аспект имеет отношение к так называемому жизненному циклу open source решений и соответствующим рискам: смены лицензии в силу выбора иной бизнес-модели, прекращения распространения решения по open source лицензии или полного ухода с рынка компании-разработчика. Как раз о подобных ситуациях мы и поговорим в этом материале: обсудим, почему open source разработки откладывают в «долгий ящик» или вовсе бросают без какой-либо надежды на дальнейшее развитие.
Disclaimer: В материале речь не идет о сравнении открытого и проприетарного ПО, а о частном случае сложностей с open source проектами, которые в целом встречаются и у проприетарных решений. Также относительно open source специфики — удалось взять комментарии у представителей российского рынка.
Потеряли интерес и закрылись
В 2004 году TrueCrypt выпустила первую версию одноименной утилиты для шифрования данных. На тот момент в основу проекта легла кодовая база другого открытого криптографического инструмента — E4M. Но вскоре после релиза разработчики получили письмо от генерального директора компании SecurStar. Он утверждал, что автор E4M — бывший сотрудник организации, который воспользовался корпоративными разработками. Якобы он не имел права распространять их под открытой лицензией.
Чтобы разобраться в ситуации, команда TrueCrypt временно прекратила распространять инструмент. Соответствующее сообщение появилось в сети usenet [это — одна из старейших сетей для общения по принципу «один для всех»]. Спустя полгода команда TrueCrypt выпустила вторую версию утилиты (уже без проприетарного кода) под собственной открытой лицензией TrueCrypt Collective License.
Инструмент получил одобрение сообщества и приобрел широкую популярность, в том числе благодаря поддержке отрицаемого шифрования. Это — особый способ криптографического преобразования, когда пару сообщений шифруют несколькими ключами одновременно. Задача такого подхода — обеспечить высокую стойкость к принуждающим атакам. Он позволяет скрыть секретное сообщение от третьей стороны, даже если той станет известен один из ключей для расшифровки.
TrueCrypt активно развивался на протяжении десяти лет, но в 2014 году авторы объявили, что сворачивают проект. На его сайте появилась плашка, что код утилиты небезопасен, вместе с подробной инструкцией по миграции на альтернативное решение (BitLocker от Microsoft). Тогда же вышла последняя версия утилиты, из которой убрали возможность шифрования данных, оставив только функции расшифровки.
Новость вызвала множество вопросов в open source сообществе. Проведённые аудиты не выявили проблем с безопасностью, и в Linux Foundation даже планировали создать форк TrueCrypt, чтобы перезапустить его под новым названием. Отсутствие видимых недостатков и каких-либо внятных объяснений со стороны команды разработки стали почвой для подозрений. В рекомендации использовать BitLocker — инструмент с закрытым исходным кодом — многие увидели «свидетельство канарейки» — якобы разработчики пытались намекнуть, что TrueCrypt могут применять для слежки. Противники этой теории в качестве контраргумента приводили интервью одного из авторов TrueCrypt. По его словам, команда просто потеряла интерес к разработке ПО. Хотя, разумеется, нашлись и те, кто не поверил в искренность его ответов.
Картина прояснилась в 2015 году, когда один из аналитиков команды Project Zero, которую собрала компания Google, все-таки обнаружил две серьезные уязвимости в драйвере TrueCrypt, который решение устанавливает на Windows. С их помощью злоумышленники могли получить более высокий уровень привилегий в операционной системе. Выявленные уязвимости подтолкнули многих из преданных пользователей продукта к миграции на альтернативные open source решения — например, VeraCrypt и DiskCryptor. Участники комьюнити продолжают выпускать для них обновления.
Не смогли договориться
В 2017 году российский разработчик представил набор утилит для серверного мониторинга netutils-linux, например, для работы в дата-центрах и на инфраструктуре провайдеров. Под хабрапостом разработчика появилось множество положительных отзывов, а также идей по развитию решения. Например, один из участников дискуссии предложил реализовать настройку XPS (Transmit Packet Steering) для распределения пакетов. И позже автор выпустил соответствующий апдейт.
Но уже в декабре 2018 года вышло последнее обновление инструмента. Как пишет автор, он не смог договориться с бывшим работодателем о принадлежности прав на проект. В попытке продлить ему жизнь, разработчик поддержал идею сделать форки — всего их три (под лицензией MIT) — однако они тоже давно не обновлялись. Последние коммиты сделаны год назад и касаются незначительных изменений вроде исправления опечаток.
Сократили финансирование
В 1970-х Французский национальный исследовательский институт INRIA развивал сеть CYCLADES, которую можно считать предшественницей интернета. Позже один из участников проекта — Винсент Квинт — переключился на новую для того времени сферу: разработку инструмента для веб-серфинга со встроенным WYSIWYG-редактором.
Команда Квинта продемонстрировала свой браузер на одной из первых конференций, посвященных веб-технологиям. На ней были представители W3C, которых заинтересовали наработки французских исследователей. Руководители W3C взяли проект под свое крыло, который впоследствии получил название Amaya.
Винсент Квинт говорит, что его команда хотела предоставить пользователям возможность не только получать информацию из интернета, но и генерировать контент самостоятельно. В этом состояло главное отличие Amaya от других веб-инструментов того времени вроде Mosaic. Проект Квинта развивался под эгидой W3C почти 20 лет, но в 2013 году его закрыли. Основатели консорциума пересмотрели свою политику — их уже не так интересовало экспериментальное ПО, поэтому финансирование подобных инициатив сократили.
Главные разработчики Amaya покинули проект, из-за чего возникли серьезные технические сложности — например, пропала возможность поддерживать самописный движок для рендеринга. К сожалению, браузер не удалось возродить даже усилиями комьюнити. Исходный код выложили на GitHub, но сейчас эта страница недоступна. Но проект остается в памяти резидентов площадок вроде Hacker News.
«Чемпиона продукта» арестовали
ReiserFS — это файловая система для Linux, разработанная в 2001 году компанией Namesys под лицензией GPLv2. Она получила признание среди специалистов за новый подход к хранению и организации данных, ориентированный на повышение производительности серверов. Так, ReiserFS стала первой файловой системой, входящей в стандартное ядро Linux начиная с версии 2.4.1. Свое название она получила в честь основателя компании и главного разработчика Ханса Райзера.
С ним же связана история закрытия ReiserFS. В 2006 году его взяли под арест по подозрению в убийстве. Судебный процесс длился пару лет — по его итогам Ханса приговорили к 15 годам лишения свободы. Новость о преступлении Райзера вызвала бурную реакцию в сообществе — на форуме Slashdot тематический тред собрал 1651 комментарий. Но пользователей больше волновала не столько судьба разработчика, сколько будущее файловой системы. Некоторые комментаторы шутили, что правоохранители разрешат Райзеру программировать в камере.
После ареста основателя компания Namesys прекратила свою деятельность, однако разработка ReiserFS продолжилась ее сотрудниками и другими добровольцами. Но даже несмотря на усилия энтузиастов, проект начал угасать. В 2022 году на форумах стали появляться треды о том, что интерес аудитории к системе потерян и, возможно, скоро ее перестанут поддерживать.
Опасения резидентов Hacker News подтвердились: в прошлом году ReiserFS получила статус obsolete в ядре Linux 6.6. По этому поводу высказался сам Райзер, подчеркнув возможности четвертой версии ReiserFS, в которой были учтены многие недостатки третьей. Однако специалисты предполагают, что к 2025 году ReiserFS полностью исключат из Linux kernel. В ответ на эту новость Эдуард Шишкин, который продолжил разработку системы после Райзера, заявил об отсутствии достойных альтернатив.
Он также упомянул, что происходящее никак не повлияет на разработку пятой версии ReiserFS, так как это «совершенно независимый проект». Несмотря на категоричный настрой Шишкина, в сообществе все же задумались об альтернативах. В качестве примера приводят Btrfs, в разработке которой участвуют крупные компании вроде SUSE и Fujitsu. О перспективности проекта говорит и тот факт, что в 2020 году Btrfs стала стандартной файловой системой для Fedora.
Что думают эксперты
Такие кейсы, как и ситуации со сменой лицензий на распространенные open source решения, говорят о том, что отсутствие стратегического понимания комплексной природы open source может обернуться рисками. Чтобы узнать, как к таким историям относятся представители российских ИТ-компаний и не только, и на какие характерные риски стоит обратить внимание, я обратился к коллегам за комментариями.
Приходилось и постоянно приходится сталкиваться с подобными ситуациями. Замена версии ПО по причинам безопасности — это довольно частое событие. В мире ПО не предусмотрена многовековая работа на одной версии, и если кто-то так ведёт бизнес, ему будет больно. Постоянно обновлять ПО — это единственный возможный путь ;) другого просто нет. Поэтому тот, кто уже так делает, вряд ли столкнется с гигантскими проблемами с миграцией 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+ лет назад покупка лицензии была самой понятной статьей в ИТ-расходах.
Что еще почитать по теме:
