Как 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 решения?