В апреле 2023 года мы выпустили Squadus — инструмент деловых коммуникаций, фундаментом которого стало СПО. Над проектом мы работаем около трёх лет, и сегодня это комплексный, многофункциональный продукт для компаний любой численности.

К созданию Squadus мы подходили как к непростому, но важному для компании опыту. Ранее сторонний код использовался в МойОфис максимум на уровне внедрения определённых библиотек, тех или иных функциональных модулей. В случае со Squadus был выбран принципиально иной сценарий — форк большого проекта и его дальнейшее самостоятельное развитие с учетом потребностей заказчиков. Путь от открытого кода к готовому бизнес-решению пролегал через массу сложностей. Их преодолением сообща занимались наши разработчики, юристы, специалисты по кибербезопасности, DevOps'ы и другие эксперты.

Почему в случае со Squadus мы предпочли сделать форк, и оправдал ли ожидания такой подход? Реальны ли выгоды от использования СПО при создании нового продукта? Обо всем этом рассказываем под катом.

Привет, Хабр! Меня зовут Артём Романов, в МойОфис я руковожу департаментом, который создаёт Squadus — единое цифровое рабочее пространство для компаний любого масштаба. Разработка этого решения стартовала три года назад на базе СПО, и часть функциональности мы позаимствовали у приложения Rocket.Chat. На сегодняшний день Squadus — это комплексный инструмент коммуникаций, который существенно отличается от исходного продукта. Приложение позволяет общаться в чатах, проводить конференции, автоматизировать действия с помощью ботов, обеспечивает совместную работу с документами.

О нюансах разработки Squadus на Хабре уже рассказали мои коллеги: в статьях про бэкенд, фронтенд, UX решения и функциональность мобильной версии. Я же сконцентрируюсь на теме open-source — и отдельно постараюсь ответить на вопрос, насколько значительны выгоды, которые несёт с собой использование открытого кода при создании нового продукта.

Предпосылки создания Squadus

В 2020 году, исходя из наблюдений за рынком и общения с заказчиками, нам стало очевидно: бизнес нуждается в инструменте, который аккумулировал бы в себе основные каналы деловой коммуникации. Вследствие пандемии обозначился тренд на дистанционную работу; компании стремились оптимизировать взаимодействие сотрудников на удалёнке и находились в поиске комплексных решений. Так появилась идея нового продукта МойОфис — единого цифрового рабочего пространства Squadus.

Поскольку мы планировали покрыть потребность рынка, что требовало определённой оперативности, вариант с СПО выглядел оптимальным. Берём базовую функциональность из стороннего продукта (те же личные и групповые чаты, возможность интегрировать ВКС) — и начинаем дорабатывать решение, исходя из потребностей целевых заказчиков.

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

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

Правовые риски. Изучаем сторонние библиотеки на предмет лицензий

Как мы и сказали выше, Rocket.Chat имеет лицензию MIT, удобную и ни к чему особо не обязывающую, кроме указания копирайтов. Но у open-source есть своя специфика. В нашем случае мы обнаружили, что на 500 тыс. строк кода Rocket.Chat приходится 11 млн. строк third-party библиотек, которые они в себя затягивают. Некоторые из этих библиотек уже не столь лояльны в плане лицензирования, как сам Rocket.Chat. В итоге мы проделали большую работу по выявлению всех зависимостей продукта от различных open-source библиотек.

Таких библиотек мы насчитали порядка 400 — все это были прямые зависимости. Каждую библиотеку изучили на предмет лицензий. Если лицензия библиотеки нас не устраивала, мы либо избавлялись от библиотеки (и тем самым лишались определенной функциональности), либо брали взамен другую, с более лояльной лицензией; в ряде случаев заменяли функции сторонней библиотеки собственным кодом. Это весьма трудоёмкий подход, но как коммерческий разработчик мы были обязаны предпринимать все необходимые меры для законного использования стороннего кода.

Например, однажды мы столкнулись с невозможностью бесплатного использования оригинального комплекта эмодзи от Rocket.Chat. Изначально пакет назывался emojione, но в результате ребрендинга был переименован авторами в Joypixels; при этом поменялась и лицензия комплекта: графические элементы стали платными. Условия лицензии предполагали возможность аренды комплекта, но не его покупку, и в итоге мы просто заменили набор эмоджи на другой — бесплатный и свободно распространяемый комплект.

RocketChat и сегодня продолжает использовать пакет Joypixels: по соглашению с авторами библиотеки, эмодзи из неё могут использоваться в самом RocketChat, но не в сторонних приложениях. Поэтому те, кто перепродают, либо форкают продукт, не заменяя эмоджи, вполне могут столкнуться с проблемами незаконности их использования. Этот кейс лишний раз доказывает важность тщательного изучения всех библиотек на предмет их лицензий в случае с СПО — даже если речь идет о простом пакете графических элементов.

Ещё один пример проблемной зависимости, с которой мы столкнулись — jschardet. Лицензия этой библиотеки была несовместима с лицензией MIT. В коде Rocket.Chat она используется только в одном месте: для определения кодировки виджетов страниц, которые её не предоставляют. Библиотека не поддерживается уже несколько лет, а поскольку она работает с внешними (по отношению к приложению) данными, использовать ее весьма небезопасно. Мы провели анализ и выяснили, что страниц без указания кодировки в современном Web исчезающе мало. Большинство браузеров спрятали/убрали функциональность выбора кодировки страницы. В итоге мы избавились от функции автоопределения кодировки и, соответственно, от самой библиотеки.

Риски ИБ. Обеспечиваем безопасную разработку и регулярные аудиты

С этой категорией рисков нам, с одной стороны, отчасти повезло. Сам Rocket.Chat периодически проводит аудит ИБ, к тому же помогает развитое комьюнити проекта: пользователи регулярно репортят баги безопасности. С другой стороны, это было актуально для нас лишь на старте разработки продукта — и мы в любом случае тщательно проверяли качество исходного кода, поскольку не были уверены в его фактической безопасности.

Чем дальше развивался наш форк, тем меньше мы могли полагаться на комьюнити в плане обеспечения ИБ. Возможные риски закрывали с помощью внутренней команды ИБ и независимых аудитов (как и в случае со всеми другими продуктами МойОфис), причём начали это делать задолго до коммерческого релиза Squadus.

На пути обновления некоторых библиотек и компонентов мы встречаем препятствия — в виде тех архитектурных решений, которые были приняты в Rocket.Chat. В частности, например, обновление версий СУБД может блокироваться из-за необходимости обновления фреймворка Meteor.JS, при этом его обновление приводит к тому, что приложение перестаёт запускаться. Meteor.JS отвечает и за бэк, и за фронт, в то время как наша цель — отказаться от «Метеора» полностью. Поэтому мы действуем по двум направлениям: переделываем фронт на React и рефакторим бэкенд, постепенно избавляясь от старого API.

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

Технологические риски. Перерабатываем и оптимизируем архитектуру

Помимо самой команды, работающей над Rocket.Chat, у продукта есть большое развитое комьюнити. Соответственно, часть кода решения написана людьми со стороны. Команда Rocket.Chat старается контролировать качество поступающего кода, тем не менее, все ещё возможны случаи, когда в ваш продукт на базе open-source попадает чей-то «проблемный» код — это зависит от того, насколько далеко вы форкнулись.

Для нас эти риски уже неактуальны: мы форкнулись ещё в 2020 году, и сегодня развиваем Squadus без оглядок на Rocket.Chat.

Безусловно, open-source решения позволяют быстро получить базовую функциональность для вашего будущего продукта. Но нужно помнить, что потребуется масса времени на доведение его до ума. В случае со Squadus, от Rocket.Chat у нас осталась вся базовая функциональность — её мы сохранили практически полностью. При этом за последние два года переписали более 50% исходного кода.

Мы понимали, что архитектура исходного продукта не оптимальна для работы крупных заказчиков. Система с трудом обрабатывала действия даже 500 пользователей, хотя нашей целью было 100 тыс. активных пользователей. Поэтому мы собрали команду и стали серьёзно прорабатывать архитектуру, исследовать, что нужно делать для обеспечения большей стабильности и нагрузоустойчивости (Rocket.Chat параллельно шёл примерно тем же путём, минимально делясь подробностями с сообществом).

Заимствовать что-либо из Rocket.Chat мы перестали два года назад. В том числе потому, что они начали внедрять нерелевантные для нас фичи. И если бы мы решили не дорабатывать продукт под себя, это сыграло бы с нами злую шутку. Без владения роадмапом СПО невозможно контролировать вектор развития продукта — когда угодно он может развернуться в любую сторону, в том числе за счёт поступления новой функциональности от контрибьюторов. Успели нанять людей и получить нужную экспертизу — хорошо, в противном случае придется идти вслед за сообществом, которое разрабатывает open-source продукт, — а вовсе не туда, куда надо вашим пользователям.

Постепенно мы наращиваем долю нашего кода в продукте. В перспективе она может достигнуть 100%. Весь фронтэнд будет на React, Meteor.js не будет вообще, бэкенд будет микросервисным и cloud native. Подробности о том, чего мы уже достигли в этой области, опять же, доступны в наших технических статьях (1, 2).

Какой-то open-source у нас в итоге однозначно останется. Как минимум некоторые third-party библиотеки, которые мы сами добавили в продукт.

Оправдались ли наши ожидания по поводу создания продукта на базе open-source?

Да, но только потому, что мы изначально были готовы к трудоёмкости проекта. Мы понимали: за полгода можно собрать MVP-продукт, чтобы демонстрировать потенциальным заказчикам, получать обратную связь и решать, стоит ли вообще тратить деньги и силы на эту разработку. Сделать же комплексное решение, в полной мере удовлетворяющее запросам крупных заказчиков, — нельзя. Наш путь к коммерческому релизу занял два года — это время потребовалось на оптимизацию архитектуры, различные переработки и добавление новой функциональности.

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

Узнать подробности о Squadus, цифровом рабочем пространстве от МойОфис, вы можете на специальной странице продукта.