Как open-source сервисы выдают за российскую разработку

Только все обсудили китайский «Москвич», как появился новый повод для дискуссий о российских продуктах — «Р-Фон». Но в IT-сфере есть и другие поводы для обсуждений, например, когда продукт целиком – иностранный open-source, но прямо об этом не говорит.

Мы активно следим за рынком корп. мессенджеров и встречаем продукты, сделанные на основе открытого кода. Иногда они позиционируют себя заменой западным решениям и российской разработкой. Часто изменения, которые были внесены в продукт, минимальны. В этой статье расскажем, как определить тех, кто «втихую» использует open-source и чем это может аукнуться клиентам таких сервисов.

Кстати, в конце есть саммари статьи 😉

Ни для кого не секрет, что с весны 2022 года Slack, MS Teams и другие зарубежные корп. мессенджеры стали ограничивать российских юзеров. Из-за этого часть отечественных компаний перешла на open-source решения, такие как Mattermost, Rocket. Chat и другие. В этом нет ничего удивительного, потому что в IT-сфере в целом много open-source и это норма — использовать или начинать строить свои сервисы на основе него. Это упрощает и ускоряет разработку. Например, мы сами разрабатываем мессенджер и для видеозвонков используем Jitsi. Это хорошее временное решение, но в перспективе планируем от него отказаться.

Кто-то использует open-source не как компонент, а как основу своего продукта. И вкладывают много ресурсов в его усовершенствование. Например, Тинькофф рассказывают о своем пути в доработке Mattermost и получившимся на его основе мессенджере TiMe. Или корп. мессенджер Squadus от МойОфис, который сделан на Rocket.Chat, и поддерживает совместную работу с документами на базе продуктов МойОфис.

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

На сайтах почти всех корп. продуктов есть скриншоты интерфейсов, по основным элементам которых мы и понимаем, на основе чего был сделан продукт. Давайте посмотрим на несколько самых популярных примеров.

Глобус в обозначении публичных каналов, замочек у приватных и отсутствие аватарок чатов — почти всегда это значит, что под капотом Mattermost.

Квадратные разноцветные аватарки у чатов, да и в целом формы скругленных квадратов во всем интерфейсе — привет, Rocket.Chat.

Иногда узнать открытый код можно на этапе тестирования по «кривым» переводам некоторых частей интерфейса.

Такое встречается не только на рынке мессенджеров, но и, например, в видеозвонках. Много российских решений в этой сфере сделаны на основе jitsi meet. Зачастую определить его можно по тому, что звонок открывается в отдельной вкладке браузера, а не внутри приложения. Адрес встречи выглядит, как https://meet.{название_сервиса}.com/ru. И сами разработчики не рекомендуют устраивать звонки, где одновременно будет более 100 человек.

Эти способы для определения продуктов на основе открытого кода можно применить и к сервисам из других сфер.

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

Но в подарок к плюсам идут и ограничения, которые есть у изначального open-source. Поэтому, если вы пробовали сами разворачивать Mattermost, Rocket.Chat или jitsi meet, но решили поискать другие варианты из-за ограничений, лучше сразу уточнить у разработчика, преодолели ли они критичные для вас проблемы или нет. Примерами таких проблем могут быть ограничения на количество уведомлений, проблемы с пушами и производительностью.

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

Немного о безопасности. Информация об уязвимостях исходного кода продукта будет поступать к компаниям-разработчикам с задержкой. Например, у Mattermost есть политика ответственного раскрытия информации и страница обновлений безопасности, в соответствии с которой они сообщают о найденых уязвимостях в их коде через 30 дней после самостоятельного устранения слабых мест. После такого публичного анонса одновременно с компанией «тихушником» об уязвимостях узнают и злоумышленники. Это ставит под угрозу безопасность продукта и данные пользователей.

И никуда не деться от вопроса легальности. Есть лицензия AGPLv2, по которой доступен открытый код Mattermost и многих других программ. В соотвествии с ней, разработчик, который распространяет программы на основе такого открытого кода, должен передать клиенту все права на модификации и дополнения, которые он добавил к опенсорс-решению. То есть он должен убедиться, что у его клиентов тоже есть доступ к исходному коду со всеми его дополнениями. И он должен рассказать об этом клиентам. Получается, если действовать в легальном поле, то заработать на такой программе будет трудно.

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

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

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

Мы каждый год составляем свой рейтинг российских корп. мессенджеров, где пишем именно про те продукты, которые написаны с нуля. Если вам интересны именно такие решения, то вот ссылка на наш рейтинг.

Если коротко и грубо собрать все, о чем мы писали выше, то получится, что в IT-сфере много open-source и это норма — использовать или начинать строить свои сервисы на основе него. Но есть два варианта использования отрытого кода: как компонент или как основу своего продукта. При этом, говорит разработчик об использовании open-source или нет, зависит лишь от его решения.

Плюсы от внедрения продуктов написанных на основе отрытого кода:

• доработка открытого кода
• установка этого кода на ваши сервера или предоставление облачного доступа
• тех. поддержка
• на все это вы не тратите ресурсы вашей компании

Минусы:

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

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

А как вы относитесь к сервисам написанным на основе открытого кода? Готовы ли покупать доработанные open-source решения?