От форка до собственной архитектуры

Откуда вообще взялась задача

До появления МС22 мы сами пользовались примерно тем же набором инструментов, что и многие администраторы. Кто-то предпочитал SecureCRT, кто-то MobaXterm, использовали Termius, а разработчики в значительной степени жили в VS Code и подключались через Remote Development. Отдельно существовали утилиты для SSH-ключей, работы с форматами ключей, базами данных, диагностики сети и прочих административных задач. Никакой внутренней идеи «нам срочно нужен собственный SSH-клиент» у нас не было.

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

Мы сначала предложили наиболее очевидный с инженерной точки зрения вариант: подобрать подходящий open source, проверить его, помочь с внедрением и сопровождением. Заказчику это не подходило, ему требовалось решение того же класса, что уже использовался внутри организации, но пригодное для процесса импортозамещения и закупки. И была еще одна маленькая деталь: срок около одного месяца. Если решение не появлялось вовремя, часть сотрудников должна была перейти на стандартный терминал Linux.

Для небольших компаний это может звучать как довольно странная угроза: не будет MobaXterm — ну и что, есть ssh user@host. В большой регулируемой инфраструктуре все несколько интереснее. Есть утвержденные классы ПО, процессы установки, списки разрешенного ПО, требования ИБ, закупочные процедуры и тысячи пользователей, которым нельзя просто написать в корпоративный чат: «Ребята, с понедельника все осваиваем .ssh/config, tmux и счастливую жизнь». Технически можно. Организационно — иногда проще написать продукт.

Почему мы не стали писать SSH-клиент с нуля

Сейчас легко посмотреть на МС22 3.0 и сказать: раз приложение все равно в итоге почти полностью переписали, может, надо было сразу начинать с чистого листа? Нет. Это был бы классический пример правильной архитектуры, появившейся слишком поздно для решения реальной задачи.

В момент первого запроса у нас было примерно четыре недели, и за это время собственный менеджер соединений должен был получить хотя бы:

• терминальный эмулятор;
• SSH;
• работу с ключами;
• SFTP;
• менеджер сохраненных подключений;
• туннелирование;
• кроссплатформенный GUI;
• импорт и экспорт конфигурации;
• поддержку нескольких сессий;
• установщики;
• локализацию;
• механизмы обновления;
• документацию;
• тестирование на нескольких ОС;
• подготовку продукта к корпоративной эксплуатации.

И это только то, что видит пользователь. Под ним остается работа с PTY, файловой системой, хранением секретов, SSH-библиотеками, lifecycle процессов, сетевыми ошибками, кодировками, прокси, jump-host, различиями Windows/Linux/macOS и еще длинным списком мелочей.

SSH выглядит простым ровно до того момента, пока ваша задача звучит как ssh root@10.10.10.10. Как только появляется требование сделать из этого тиражируемый desktop-продукт, начинается совсем другая инженерия. Поэтому вместо разработки собственного терминала за четыре недели мы стали искать проект, который уже решает 70–80% задачи.

Почему Electerm

Мы посмотрели несколько open source решений и в итоге остановились на Electerm. С практической точки зрения он закрывал большую часть исходных требований: терминал, SSH/SFTP, сохранение подключений, туннели, быстрые команды, кроссплатформенность и нормальный GUI. Кроме того, проект распространяется под лицензией MIT, исходный код открыт, а desktop-сборка использует Electron. Это было принципиально: нам нужна была кодовая база, которую разрешено модифицировать, собирать и развивать.

И здесь важно сразу сказать вещь, которую мы никогда не скрывали перед заказчиками: первая версия МС22 была форком Electerm. Более того, какое-то время мы сами не видели в этом ничего большего. У нас был конкретный запрос, open source позволял его закрыть, мы добавляли необходимые изменения, занимались локализацией, упаковкой и всем тем огромным количеством не очень романтичной работы, которое отделяет GitHub-репозиторий от продукта, который может приобрести крупная организация. Инновационного прорыва здесь не было, зато была решена проблема заказчика. Иногда это полезнее.

35 дней: продукт как средство закрыть конкретную проблему

Основной ресурс мы направили на прохождение пути от исходного запроса до готового к закупке решения. По нашей внутренней хронологии этот путь занял 35 дней при исходном ожидании заказчика около месяца. Первая версия МС22 вышла в начале 2024 года: терминал, SSH, Mosh, SFTP и Telnet, а из операционных систем — Windows, macOS, Linux, включая Astra Linux, РЕД ОС и «Альт».

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

Провал №1. Мы оптимизировали продукт под дедлайн вместо жизненного цикла

Первая версия МС22 решала задачу, ради которой появилась, и это одновременно было ее главным достоинством и главным недостатком. Мы смотрели на нее примерно так: есть конкретный заказчик, есть конкретное требование, есть срок, есть рабочий результат, done. В терминах проектной работы все было прекрасно. В терминах продуктовой разработки мы почти ничего еще не сделали, потому что не знали:

• насколько большой вообще существует рынок таких решений;
• действительно ли другим компаниям нужен российский менеджер соединений;
• какие функции пользователи считают обязательными;
• готовы ли администраторы отказаться от SecureCRT, MobaXterm или Termius;
• какие сценарии нужны кроме SSH;
• насколько важны RDP и VNC;
• насколько критично потребление ресурсов;
• нужен ли встроенный клиент СУБД;
• какие функции заставляют человека открыть отдельную утилиту.

Мы сделали продукт с очень конкретным решением задачи: один заказчик и его дедлайн. Это, кстати, значительно лучше нуля заказчиков, но все еще довольно специфическая выборка.

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

Мы пересадили на МС22 собственных сотрудников

После второго запроса мы решили перестать рассуждать о продукте абстрактно и сделать неприятную для разработчика вещь: начать самим им пользоваться. Мы постепенно пересадили на МС22 сотрудников, которым по работе регулярно требовались SSH-подключения и другие административные операции. Это оказалось гораздо полезнее, чем внутреннее тестирование по чек-листу: QA может проверить, создается ли SSH-соединение, а администратор через неделю спросит, почему для операции, которую он выполняет 40 раз в день, нужно каждый раз делать четыре клика. Это разные классы обратной связи.

Очень быстро появились вещи, которые невозможно хорошо увидеть на демонстрационном стенде:

• где интерфейс заставляет делать лишнее действие;
• какие параметры соединения реально переиспользуются;
• какие операции должны работать с клавиатуры;
• что нужно видеть одновременно;
• где неудобно работать с большим количеством хостов;
• какие маленькие утилиты постоянно открываются рядом с терминалом;
• на каких задачах начинает раздражать производительность.

Мы фактически превратили собственную компанию в первый постоянный dogfooding-стенд. Название метода красивое, а на практике это означает, что разработчика начинают регулярно ловить в коридоре люди со словами: «Слушай, а кто придумал вот эту кнопку?» Весьма эффективная методика UX-исследований. Позже мы распространили эту практику на все наши продукты: если сотруднику нужен инструмент такого класса, он пользуется внутренним и присылает замечания.

Потом мы сделали еще одну странную вещь: запустили рекламу не ради продаж

Нам нужна была более широкая выборка, поэтому параллельно с развитием продукта мы начали маркетинговую активность и тестирование не только для получения лидов. Нас интересовало, чем вообще пользуются администраторы и чего им не хватает. Одним из таких экспериментов стала статья на Хабре «От PuTTY до МС22: сравниваем SSH-клиенты», опубликованная 6 октября 2024 года. На момент подготовки этой статьи у нее более 100 тысяч просмотров и 77 комментариев.

И вот комментарии оказались интереснее самой публикации. Там довольно быстро появились:

• mRemoteNG;
• Tabby;
• Bitvise;
• Remmina;
• KiTTY;
• SuperPuTTY;
• VS Code Remote Development;
• JetBrains;
• аргументы в пользу обычного OpenSSH;
• критика цен;
• критика Electron;
• вопросы по поддерживаемым терминалам;
• замечания по сравнению возможностей;
• и, разумеется, прямой вопрос: «Чем МС22 отличается от Electerm?»

И вот здесь случился еще один полезный провал.

Провал №2. Мы хотели собрать обратную связь, но недооценили вопрос доверия

Сегодня мы бы такую статью сделали иначе. Формально задача была продуктовая: понять, что используют люди, чем недовольны и какие сценарии считают важными. Но часть аудитории совершенно закономерно увидела другое: производитель продукта пишет сравнение, в котором участвует его собственный продукт. В комментариях нам прямо написали, что материал выглядит как реклама МС22, там же довольно быстро нашли связь с Electerm и задали вопрос, в чем вообще отличие.

Это был хороший урок. Техническая аудитория очень плохо переносит попытки делать вид, что коммерческого интереса не существует, даже если конкретная публикация действительно нужна вам для исследования. Наверное, правильнее было сразу написать в первом абзаце: да, МС22 наш продукт, да, первая версия основана на Electerm, мы хотим понять, чем реально пользуется аудитория и чего не хватает существующим клиентам, поэтому вот сравнение, а теперь можете нас разбирать. Получили бы мы меньше ехидных комментариев? Сомневаюсь. Но вопрос доверия был бы закрыт сразу.

При этом сами комментарии оказались крайне полезными. Например, пользовательская критика Electron и потребления ресурсов появилась там еще в 2024 году: в обсуждении других клиентов напрямую отмечали высокое потребление памяти приложениями на Electron. Через два года мы придем ровно к этой архитектурной проблеме уже внутри собственного продукта. Иногда комментарий на Хабре — это бесплатный технический долг, присланный из будущего.

Работа с upstream: сначала все было хорошо

Параллельно мы поддерживали контакт с разработчиком Electerm, потому что не хотели превращать форк в полностью отдельный проект без необходимости. Это стандартная проблема любого корпоративного форка: пока возможно, гораздо выгоднее оставаться близко к upstream. Новые версии и исправления Electerm попадают в нашу продуктовую ветку, а поверх них ложатся локализация, собственные функции и корпоративные доработки. Чем меньше расхождение, тем дешевле сопровождение, а каждый большой собственный патч потенциально означает будущий конфликт при обновлении upstream.

Поэтому логика была простая: полезные универсальные изменения по возможности отдавать обратно в Electerm, а специфичные продуктовые вещи для российского рынка держать у себя. Кроме технического взаимодействия, мы поддерживали исходный проект и финансово. Какое-то время модель работала нормально, но постепенно направления разработки начали расходиться.

Провал №3. Мы слишком долго считали, что форк останется просто форком

У форка есть очень приятная экономика в начале: вы получаете огромный объем уже работающего кода и можете концентрироваться только на отличиях своего продукта. Проблема начинается в тот момент, когда именно отличия становятся вашим продуктом.

У нас сначала появились собственные функции. Первой крупной собственной доработкой стала полноценная работа с RDP и VNC — она появилась в версии 1.1 в сентябре 2024 года, то есть примерно через полгода после первого релиза. Дальше начали меняться интерфейс и сценарии работы, потом — требования безопасности. Вот здесь граница стала принципиальной.

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

• как должны храниться данные;
• какие соединения допустимы;
• где должны находиться секреты;
• какие внешние зависимости приемлемы;
• как приложение должно вести себя в изолированном контуре,

начинает отличаться от upstream, вы уже не можете безусловно наследовать его архитектурные решения.

Мы предложили часть своих изменений upstream, часть из них в проект не вошла, и это совершенно нормальное право автора open source проекта. Здесь важно не превращать ситуацию в историю «плохой upstream не принял наши прекрасные патчи»: у разработчика Electerm свои цели, аудитория и roadmap, у нас — свои. Дело было не в чьей-то неправоте, мы наконец поняли, что наши продукты движутся в разные стороны. После этого поддержание иллюзии единого проекта стало бы дороже самостоятельного развития, и начиная с этого периода МС22 начал развиваться независимо.

Что означает «независимо», когда у вас уже большой форк

Нельзя просто однажды утром выполнить git remote remove upstream и считать, что теперь у вас собственная архитектура. История проекта от этого не исчезает: в коде остаются исходные abstractions, библиотеки, модель данных, assumptions, UI-компоненты, сетевой стек и десятки архитектурных решений, которые принимались для другого продукта.

Поэтому самостоятельное развитие форка обычно проходит три стадии. Первая, самая приятная, звучит как «мы добавим пару функций». Вторая, менее приятная, — «почему при обновлении опять 47 конфликтов?». Третья — «если мы заменили половину подсистем, почему вторая половина все еще определяет, что нам можно делать?». Вот на третьей стадии начинается настоящий собственный продукт, и у нас этот переход хорошо проявился к ветке 2.x.

Версия 2.0: SSH-клиента нам уже стало мало

К началу 2026 года мы уже постоянно использовали МС22 внутри компании и заметили забавную вещь. Терминал мы открывали в МС22, а рядом с ним регулярно открывались другие приложения: для генерации SSH-ключей, проверки и преобразования данных, работы с базой, DNS, проверки портов, HTTP-запросов, LDAP и анализа сетевых проблем. Получалась типичная рабочая станция администратора: терминал, клиент СУБД, HTTP-клиент, утилита для ключей, DNS, LDAP, сканер портов, сравнение файлов и еще несколько окон рядом.

И здесь сформировалась идея, которая сегодня для нас значительно важнее слова «импортозамещение»: МС22 должен стать единым приложением для администратора инфраструктуры, а не только российской заменой одного зарубежного SSH-клиента. В январе 2026 года публично вышло крупное обновление, в котором появились встроенные инструменты: генерация SSH-ключей, криптографические утилиты, DNS, traceroute, проверка портов, анализ трафика, HTTP-, SNMP- и LDAP-клиенты, калькулятор подсетей и сравнение файлов. Эту ветку мы внутри воспринимали как переход к поколению 2.x. Это был уже не просто терминал с менеджером закладок.

Зачем вообще встраивать эти инструменты

Здесь можно вполне справедливо спросить: зачем собирать все в одно приложение, если ssh-keygen, curl, dig, traceroute, openssl, Wireshark и десятки других инструментов прекрасно существуют отдельно? Они действительно прекрасно существуют, и мы не пытались сделать собственный curl, который победит curl, или собственный dig. Смысл был в другом.

Контекст администратора уже находится в менеджере соединений: имя хоста и IP, порт, учетные данные, SSH-ключ, прокси, jump host, переменные окружения и история работы. Если из этого же объекта можно открыть SSH, SFTP, RDP, VNC, подключение к базе данных, DNS lookup, проверку порта и HTTP-запрос, исчезает значительная часть ручного переноса контекста между приложениями.

Особенно это заметно в большой инфраструктуре. Проверить нужно 443 порт вот этого хоста, к которому только что не получилось подключиться, возможно через тот же сетевой контур. Или открыть базу, связанную с этим сервером. Или выполнить одинаковую диагностическую операцию для нескольких узлов. Отсюда постепенно начала формироваться единая модель соединения вместо набора независимых протоколов: текущая версия МС22 поддерживает SSH/SFTP, FTP/TFTP/SCP, Telnet, Serial, RDP, VNC и подключения к СУБД, а также tunneling и SSH Jump.

Но до текущей версии оставались две большие проблемы: RDP/VNC и ресурсы.

Провал №4. Первая проблема: «поддерживает RDP» и «нормально работает с RDP» — разные характеристики

RDP и VNC мы добавили довольно рано, и на презентации фраза «поддерживаются SSH, SFTP, RDP и VNC» выглядела прекрасно. В эксплуатации оказалось несколько сложнее, особенно это касалось RDP. SSH сравнительно удобен для кроссплатформенной клиентской реализации: у вас есть хорошо описанный протокол, зрелые библиотеки и относительно предсказуемая модель терминальной сессии. RDP — другой зверь, соединение может зависеть от:

• режима безопасности;
• TLS;
• NLA;
• CredSSP;
• особенностей конкретной Windows;
• серверных политик;
• графического транспорта;
• шлюзов;
• согласования возможностей клиента и сервера.

В текущей версии МС22 поддерживаются NLA, TLS, legacy-режим и RD Gateway, но до этого состояния мы пришли не сразу. В первой реализации совместимость фактически была слишком узкой: на современных конфигурациях все могло выглядеть нормально, а потом приходишь в реальную корпоративную инфраструктуру — и там внезапно обнаруживаются Windows разных поколений, серверы с разными настройками безопасности, старые политики и комбинации, которых на вашем аккуратном тестовом стенде почему-то никто заранее не установил.

Это был важный продуктовый урок. Если клиент удаленного доступа работает только с той инфраструктурой, которая нравится клиенту удаленного доступа, исправляться должна не инфраструктура: это клиент недостаточно совместим. Мы сначала пытались исправлять проблемы локально, но постепенно стало понятно, что ограничения сидят уже не в отдельных функциях, а глубже, в архитектуре.

Вторая проблема: приложение было тяжелым

Исходная архитектура была унаследована от мира Electron/NodeJS, и для быстрого старта это отличный компромисс. Electron вообще часто ругают несколько однобоко: за сравнительно небольшую стоимость разработки вы получаете:

• один UI для нескольких ОС;
• огромную web-экосистему;
• быстрый development cycle;
• зрелые библиотеки;
• достаточно предсказуемую упаковку desktop-приложения.

Electerm и сегодня собирается через electron-builder, а его разработка требует Node.js/npm. Проблема не в том, что Electron плох. Проблема начинается, когда характеристики вашей нагрузки перестают совпадать с компромиссами платформы, а у нас росло количество:

• параллельных сессий;
• сетевых соединений;
• фоновых операций;
• файловых операций;
• протоколов;
• внутренних инструментов;
• долгоживущих объектов.

И мы все чаще упирались в ресурсы. Наши замеры показывают масштаб так: приложение поколения 2.x в режиме ожидания занимало около 250 МБ оперативной памяти, новая ветка 3.0 — порядка 50 МБ. Это усредненное значение по нескольким операционным системам: Windows, macOS и РЕД ОС. Универсальным benchmark считать его не стоит, это результат наших внутренних измерений. По тем же тестам нагрузка при 50 одновременных сессиях в новой архитектуре сопоставима примерно с десятью сессиями предыдущего поколения.

Это уже не оптимизация кнопки. Пять раз — достаточно большой разрыв, чтобы перестать искать очередной memory leak в надежде, что именно он объясняет архитектуру.

Самое неприятное решение проекта: переписать почти все

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

1. Можно ли устранить проблемы эволюционно?

Часть проблем — да. Но сетевые подсистемы, производительность и зависимость от старой runtime-архитектуры уже ограничивали друг друга.

2. Будем ли мы дальше следовать архитектуре Electerm?

Нет, к этому моменту roadmap продуктов окончательно разошелся.

3. Даст ли переписывание что-то пользователю?

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

4. Каким должен быть следующий слой продукта?

Мы уже строили не форк терминала. Нам нужен был системный слой для:

• SSH;
• файловых операций;
• RDP/VNC;
• баз данных;
• локального хранения;
• сетевых инструментов;
• автоматизации;
• будущих интеграций.

После этого решение стало достаточно очевидным, и мы начали перенос backend-части на Rust.

Почему Rust

Не потому, что в 2026 году техническая статья без Rust рискует не получить сертификат соответствия Хабру. У нас были вполне прагматичные причины: для desktop-приложения такого класса критичны:

• контроль над памятью;
• многопоточность;
• сетевой I/O;
• большое количество долгоживущих соединений;
• predictable resource usage;
• работа с native API;
• возможность собирать отдельные протокольные подсистемы без полноценного Node runtime.

Из чего собрана системная часть

Вопрос, который здесь возникает первым: какие библиотеки мы взяли. Ответ короткий — никаких. Готовых решений, реализующих SSH, RDP, VNC или работу с СУБД целиком, в 3.0 нет, все протокольные реализации написаны нами.

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

При этом мы не хотели выбрасывать весь UI. Для пользователя все это не должно быть особенно интересно: если пользователь SSH-клиента вынужден думать о нашем runtime, мы где-то ошиблись. Он должен заметить другое:

• приложение запускается быстрее;
• потребляет меньше памяти;
• больше сессий не превращают ноутбук в отопительный прибор;
• RDP подключается к реальной инфраструктуре;
• VNC не живет отдельной жизнью;
• интерфейс не ломается из-за того, что внутри поменялось почти все.

Но переписывание тоже оказалось провалом. Просто полезным

Есть неприятная особенность полного переписывания кода: вы не просто переносите функции, вы переносите все уже когда-то исправленные странности. За годы разработки в старом коде накапливаются десятки решений вида «если сервер такой — делаем так», «если Windows старая — иначе», «если ключ такого формата — вот этот путь», «если соединение через proxy — не забудь это», «если SFTP оборвался здесь — восстановить состояние вот так».

Документация обычно описывает далеко не все эти случаи. Часть документации находится в комментариях, часть — в commit history, часть — исключительно в памяти разработчика, который однажды три часа выяснял, почему конкретный сервер отвечает именно таким образом. При rewrite все это приходится находить заново.

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

Поэтому мы не считаем переписывание на Rust достижением само по себе. Язык программирования — средство, а результатом можно считать только изменение эксплуатационных характеристик.

Что мы сделали одновременно с переписыванием

Нам не хотелось выпускать обновление с единственным changelog вида «все осталось как было, только разработчикам теперь спокойнее». Поэтому параллельно с переносом архитектуры мы продолжили первоначальную идею единого рабочего места администратора: появился более полноценный клиент для работы с базами данных, мы расширили набор встроенных инструментов, переделали части RDP/VNC и продолжили работу над автоматизацией.

Добавили даже небольшое обучение командной строке в формате задач. Идею подсмотрели у проектов вроде Command Challenge: вместо чтения еще одной страницы документации пользователь получает небольшую задачу и решает ее непосредственно командами. Это не самая корпоративная функция в истории корпоративного ПО, и, пожалуй, поэтому она нам нравится.

Версия 3.0: точка, где от исходного форка осталась в основном история

С датами здесь стоит быть точными. Внутри команды июнь 2026 года был нашим релизным рубежом новой архитектуры: к этому моменту ветка 3.0 уже стала основной для дальнейшего развития. Публично beta-версия МС22 3.0.0 была объявлена 13 июля 2026 года, и так корректнее фиксировать дату для внешней истории продукта.

Здесь стоит уточнить формулировку, потому что «переписали приложение на Rust» звучит красиво, но неточно. Любое десктопное приложение состоит из двух частей: видимой для пользователя и невидимой. Видимую часть, интерфейс, мы переделали в версии 2.0. Невидимую, системную, — в 3.0, отказавшись от прежней реализации на NodeJS в пользу Rust. Целиком на Rust десктопное приложение такого класса не собирается. На практике переход дал несколько результатов.

Память

Потребление в режиме ожидания снизилось примерно с 250 МБ в ветке 2.x до 50 МБ в 3.0, то есть приблизительно в пять раз в нашем тестовом сценарии.

Масштабирование сессий

Около 50 одновременных сессий в новой архитектуре создавали нагрузку, сопоставимую примерно с десятью в предыдущей. Как и в случае с памятью, это усредненный результат наших тестов на Windows, macOS и РЕД ОС, а не универсальный benchmark для произвольной инфраструктуры.

RDP/VNC

Подсистемы были переработаны, в том числе для повышения совместимости с Windows разных поколений. В 3.0 появилась поддержка RD Gateway, а публичное описание новой версии отдельно отмечает расширение совместимости с современными и более старыми Windows Server.

Что МС22 представляет собой сейчас

По состоянию на 11 августа 2026 года на сайте актуальной указана версия 3.0.0. Текущий продукт позиционируется как менеджер подключений, баз данных и встроенных администраторских инструментов. Сейчас в одном приложении объединены подключения (SSH, SFTP, SCP, FTP и TFTP, Telnet, Serial, RDP, VNC, SQL), туннелирование (проброс портов, обратный туннель, динамический прокси, SSH Jump) и набор инструментов: работа с SSH-ключами, криптографические утилиты, DNS, traceroute, сканер портов, анализ трафика, HTTP, SNMP, LDAP, калькулятор подсетей, сравнение файлов и автоматизация.

По сути это и есть главное изменение концепции за два года. В 2024 году вопрос звучал так: как быстро заменить зарубежный SSH-клиент? В 2026-м он звучит уже иначе: какие инструменты нужны администратору инфраструктуры каждый день и какие из них разумно объединить вокруг одной модели подключений?

Еще один неприятный вопрос: цена

После первой статьи на Хабре мы довольно хорошо поняли, что наша ценовая модель людям, мягко говоря, не понравилась: комментарии содержали формулировки вроде «заградительные цены» и вполне закономерное сравнение стоимости с MobaXterm. Здесь тоже стоит объяснить исходную логику. На первой стадии мы вообще не рассматривали МС22 как массовый продукт. Это было решение для организаций, которым действительно нужно импортозамещение конкретного класса ПО и которые фактически финансируют дальнейшую поддержку проекта. При этом мы всегда настаивали, что все потенциальные покупатели в начале полноценно тестировали решение и только после этого принимали решение о покупке.

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

По состоянию на текущий момент у МС22 есть бесплатная редакция без ограничения по сроку: до пяти закладок, двух параллельных сессий и с ограничением RDP/VNC-сессий до 30 минут. Все встроенные инструменты при этом доступны. Платная личная бессрочная лицензия сейчас указана по цене 8500 рублей, лицензии для юридических лиц начинаются от 7000 рублей в год.

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

Четыре провала, которые оказались полезнее четырех успехов

Если убрать версии, Rust, RDP и весь продуктовый контекст, наша история сводится примерно к четырем ошибкам.

1. Мы считали продукт одноразовым

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

2. Мы недооценили прозрачность коммуникации

Статья со сравнением дала много отличной обратной связи, но часть читателей вполне справедливо воспринимала ее как рекламу собственного продукта. Вывод: если вы производитель — говорите об этом сразу, особенно на Хабре. Аудитория все равно найдет GitHub, юридическое лицо, исходный проект и ваши старые комментарии. Просто сделает это без вашего участия.

3. Мы слишком долго надеялись сохранить архитектурную близость к upstream

Пока собственных изменений мало, это дешевая стратегия. Когда ваши требования безопасности, UI и roadmap расходятся с оригинальным проектом, она превращается в постоянный налог на каждое изменение. Вывод: нужно заранее определить технический критерий, после которого форк считается самостоятельным продуктом: критические подсистемы становятся собственными, security model отличается, roadmap не совпадает, а merge с upstream создает больше затрат, чем пользы.

4. Мы слишком долго лечили симптомы архитектуры

RDP можно чинить, утечку памяти можно чинить, очередной проблемный цикл тоже можно чинить. Но если каждое новое исправление сталкивается с тем же архитектурным ограничением, стоит посчитать не только стоимость переписывания, но и стоимость не переписывания кода еще два года. И у нас в какой-то момент второе число стало больше первого.

Как бы мы строили такой продукт сейчас

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

• первых 35 дней;
• первого заказчика;
• второго заказчика;
• реального пользовательского отзыва;
• понимания нужных функций;
• данных по проблемам старой архитектуры;
• уверенности, что rewrite вообще имеет экономический смысл.

Мы бы только заранее добавили несколько правил.

Правило 1. С самого начала отделить upstream от продуктовой архитектуры

Даже если первая версия — почти чистый форк, должно быть понятно, что наследуется, что можно заменить, какие интерфейсы мы считаем своими и какие данные должны пережить замену внутренней реализации.

Правило 2. Не смешивать наличие функции и ее зрелость

Один плюс в сравнительной таблице стоит очень мало, особенно после первого реального заказчика. За строкой «RDP: +» должны стоять поддерживаемые версии Windows Server, NLA, режимы TLS, RD Gateway, буфер обмена, разрешение экрана, работа через прокси и матрица регрессионных проверок.

Правило 3. Сразу включить dogfooding

Разработчик приложения для администратора не должен узнавать о типичном административном сценарии через три месяца после релиза.

Правило 4. Собирать рабочие процессы

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

Правило 5. Считать стоимость архитектурного наследства

Количество строк собственного кода — плохая метрика самостоятельности форка. Гораздо полезнее смотреть:

• сколько времени занимает merge upstream;
• какую долю критического пути контролируете вы;
• сколько bugs невозможно нормально исправить без изменения базовой архитектуры;
• сколько решений приходится принимать исходя из ограничений продукта, который вы уже фактически не развиваете.

Почему мы вообще продолжаем этим заниматься

МС22 не был запланирован как большой самостоятельный продукт. Это был способ решить очень конкретную задачу очень конкретного заказчика, и мы даже сами поначалу не были уверены, что этому направлению нужно отдельное развитие. Дальше рынок довольно последовательно объяснил нам обратное: сначала вторым запросом, потом пользователями, комментариями, багами и, наконец, RDP. RDP вообще умеет очень убедительно объяснять архитектурные проблемы.

В результате продукт прошел довольно странный путь: запрос заказчика, поиск open source, форк Electerm, 35 дней, российский продукт, второй заказчик, dogfooding, обратная связь, собственные функции, расхождение с upstream, МС22 2.x, архитектурные ограничения, rewrite, Rust, МС22 3.0.

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

Чего в МС22 сейчас нет

Выше довольно много про наши ошибки, поэтому будет честно назвать и границы самого продукта. Ниже четыре вещи, которых в МС22 на сегодня нет, вместе с объяснением почему.

Мобильная версия

Большого спроса на этот класс решений на мобильной платформе мы пока не видим, по крайней мере по обращениям к нам. В сторону смотрим внимательно, но здесь мало добавить поддержку: нужно удобное и понятное управление, иначе получится формальная галочка в списке функций. Ровно ту ошибку мы уже разбирали выше на примере RDP.

Общее пространство для обмена конфигурациями

Запросы на это мы получаем, причем обычно вместе с централизованными политиками контроля и логированием действий администраторов. Формально это уже другой класс решения, а не менеджер соединений. Идеи, как это реализовать, у нас есть, и не исключено, что появятся они в отдельном продукте, а не внутри клиента.

Глубокая интеграция с менеджером паролей

Отдельной интеграции внутри МС22 нет. Мы пошли с другой стороны: наш десктопный менеджер паролей ОдинКлюч умеет подставлять пароли в сторонние приложения, и МС22 в их числе. Насколько этого достаточно, покажет обратная связь. Если окажется, что нужна более тесная связка, будем делать.

Автоматизация на Python

Такие запросы приходят регулярно, чаще всего от тех, кто раньше работал с SecureCRT или Xshell. Большинство описанных задач закрываются быстрыми командами, инструментом скриптов и действиями, которые выполняются сразу после установки подключения. Но привычку пользователя переломить сложно, и мы это понимаем, поэтому за темой продолжаем следить.

Отдельно про версию 3.0: она вышла недавно и пока находится в статусе беты. Накопленного списка известных проблем у нас на этот момент нет, поэтому нам сейчас важна обратная связь, в том числе через эту статью.

Что дальше

Сейчас у нас остается несколько направлений развития МС22. Одно из них связано с дальнейшим превращением клиента в единое рабочее место администратора, другое — с интеграциями с инфраструктурными системами, где связка с ОдинХаб пока только первые шаги. Кроме того, архитектура МС22 нужна нам для еще одного будущего продукта, поэтому часть решений, которые сейчас появляются внутри клиента, изначально проектируются уже с расчетом на дальнейшее переиспользование. Но здесь мы стараемся не повторять свою первую ошибку и не рассказывать о roadmap как о готовом функционале. Когда появится — тогда и будем обсуждать.

Вместо заключения

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

Но если вы:

• поддерживаете upstream;
• честно рассказываете происхождение продукта;
• принимаете собственные инженерные решения;
• исправляете ограничения;
• слушаете пользователей;
• а в какой-то момент готовы отказаться даже от исходной архитектуры,

то форк вполне может оказаться хорошим стартом для собственного продукта. С МС22 именно это и произошло. Мы начинали с задачи «через месяц заменить зарубежный менеджер соединений», а сегодня у нас собственная архитектура на Rust, единая модель SSH/RDP/VNC/DB-подключений, встроенные инструменты администратора и совершенно другой roadmap. Текущая публичная версия — 3.0.х.

И поэтому у нас сейчас несколько необычная просьба к тем, кому интересна эта история. Скачайте бесплатную версию и попробуйте реально им поработать. Подключите домашний сервер, роутер, базу, используйте его несколько дней вместо привычного клиента. Если все устраивает — прекрасно. Если что-то бесит — еще лучше.

Особенно нас интересуют случаи вида «я каждый день делаю X, а у вас для этого нужно совершить какое-то безумие», или «на вот этой древней Windows Server через вот такую корпоративную схему RDP не работает», или даже «кто вообще придумал этот интерфейс и почему он такой ужасный». Последний вариант мы тоже читаем. Желательно только последней причиной все-таки написать, как сделать лучше.

Потому что значительная часть МС22 появилась именно таким образом: кто-то однажды сказал, что существующий вариант неудобен, нестабилен или вообще сделан не так. Мы проверили. Иногда пользователь был неправ, иногда были неправы мы. А иногда после этого приходилось переписывать приложение на Rust.