Между OpenSign и Documenso выбирают не по фичам, а по юридической части

MAATRIX

Когда команда решает уйти от DocuSign или HelloSign на self-hosted решение, первый вопрос обычно звучит как «какой из них функциональнее». И это неправильный вопрос. OpenSign и Documenso закрывают один и тот же базовый сценарий — загрузить PDF, расставить поля подписи, разослать подписантам, получить аудиторский след — примерно одинаково хорошо. Разница, которая реально определяет выбор, лежит не в списке фич, а в том, что происходит с юридической силой документа после того, как последний подписант нажал кнопку. Разберём оба инструмента честно: где они технически различаются, а где различие есть только на бумаге маркетинга.

Почему сравнение «по фичам» здесь не работает

Если сесть и построчно сверить возможности OpenSign и Documenso, список получится почти симметричным: загрузка PDF, drag-and-drop полей (подпись, дата, текст, чекбокс, инициалы), назначение нескольких подписантов с порядком подписания, ссылки без обязательной регистрации получателя, аудиторский след с IP и таймстампами, встраиваемые виджеты, REST API для интеграции с вашим бэкендом, шаблоны для повторяющихся документов. Обе платформы open-source, обе можно поднять на своём VPS через Docker Compose, обе не берут денег за количество отправленных документов, если вы хостите их сами.

Проблема в том, что этот список ничего не говорит о главном вопросе, ради которого бизнес вообще внедряет электронную подпись: будет ли подписанный документ иметь силу в суде или перед контрагентом, если дело дойдёт до спора. А это уже не вопрос функциональности продукта — это вопрос того, какой вид электронной подписи вы реализуете и признаётся ли она в вашей юрисдикции автоматически или только по отдельному соглашению сторон. Мы разбирали эту логику подробно в статье про электронную подпись на своём сервере — там же объяснено, почему ни один self-hosted инструмент сам по себе не создаёт квалифицированную подпись. То же самое в равной степени касается и OpenSign, и Documenso: оба технически реализуют простую или неквалифицированную подпись, и статус кода на GitHub этого не меняет.

OpenSign: что за стек и как устроен self-hosted

OpenSign — открытая платформа для подписания документов от команды OpenSign Labs, позиционируется как прямая альтернатива DocuSign и Dropbox Sign. Технологически это заметно другой стек, чем у Documenso: бэкенд построен на Parse Platform (Parse Server поверх Node.js), в качестве базы данных используется MongoDB, а не PostgreSQL, фронтенд — React. Для self-hosted развёртывания проект публикует готовый набор для Docker Compose, где поднимаются сразу несколько сервисов: сам Parse Server, MongoDB, веб-приложение и (в зависимости от конфигурации) отдельный контейнер для генерации PDF.

Лицензия — AGPL, как и у большинства open-source конкурентов DocuSign в этой нише; практическое следствие то же самое, что и для любого AGPL-проекта: если вы модифицируете код и предоставляете сервис пользователям по сети, изменения нужно раскрывать. Для чистого self-hosted использования внутри компании без переработки исходников это ограничение обычно не создаёт проблем.

Функционально OpenSign закрывает стандартный набор: конструктор полей подписи на PDF, массовая рассылка (bulk send) одного документа множеству получателей, шаблоны с предзаполненными полями, вебхуки на события подписания (полезно, если нужно триггерить свою бизнес-логику сразу после подписи, а не поллить API), встраиваемый виджет подписи для собственного сайта, ролевая модель пользователей внутри организации. У проекта также есть облачная версия с бесплатным тарифом на ограниченное число документов в месяц — но раз вы читаете статью про self-hosted сравнение, вас интересует именно вариант на своём сервере.

Documenso: коротко, что уже разобрано отдельно

Про Documenso на этом блоге уже есть подробный разбор, поэтому здесь — только контекст для сравнения. Это монолитное приложение на Next.js с PostgreSQL как основным хранилищем и Prisma в роли ORM, лицензия — тоже AGPL. Подписание PDF реализовано через связку pdf-lib для встраивания полей и headless Chromium (Puppeteer) для рендеринга — именно эта часть стека требовательнее всего к памяти в моменте подписания, о чём мы писали в статье сколько RAM нужно для Documenso. Полная установка с нуля — в статье как установить и настроить Documenso на VPS, а частые проблемы эксплуатации (сертификат подписи, SMTP, миграции базы) — в отдельном разборе частых ошибок на сервере.

Ключевое, что стоит помнить при сравнении: Documenso изначально роднее классическому веб-стеку на PostgreSQL, которым уже пользуется большинство команд для других сервисов — это снижает порог входа для администратора, который уже умеет обслуживать Postgres, но ещё не сталкивался с MongoDB.

Функции бок о бок: где реально разница, а где нет

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

Юридическая значимость подписи — вот где реально расходятся дороги

Вот честная часть, которую маркетинг обеих платформ формулирует расплывчато. Ни OpenSign, ни Documenso в базовой self-hosted конфигурации не выдают подпись, равнозначную квалифицированной электронной подписи (УКЭП по российскому 63-ФЗ) или квалифицированной подписи по регламенту eIDAS в Евросоюзе. Обе платформы реализуют то, что по логике большинства юрисдикций классифицируется как простая или (при более сложной настройке с собственной криптографией) неквалифицированная подпись — доказательство факта подписания через привязку к учётной записи, IP, таймстампу и хешу документа, но без сертификата, выданного аккредитованным удостоверяющим центром.

Практическое следствие: юридическая сила подписанного в OpenSign или Documenso документа в большинстве случаев не возникает автоматически, а зависит от того, есть ли между сторонами предварительное соглашение о признании такого способа подписания равнозначным собственноручному. Для внутреннего документооборота компании (согласования, служебные записки, кадровые формы между сотрудником и работодателем, где есть трудовой договор с соответствующим пунктом) это работает без дополнительных телодвижений. Для внешних договоров с контрагентом, который не подписывал с вами отдельного соглашения о признании ЭП, юридическая устойчивость такого документа в споре куда менее очевидна — независимо от того, какую из двух платформ вы выбрали.

Здесь важна разница не между OpenSign и Documenso, а между юрисдикцией применения. В США логика ESIGN Act и UETA признаёт простую электронную подпись с фиксацией намерения сторон по умолчанию куда охотнее, чем в континентальном праве. В Евросоюзе eIDAS формально признаёт простую электронную подпись, но с оговоркой, что суд свободен оценивать её доказательную силу по обстоятельствам дела — подпись не отклоняется автоматически, но и не приравнивается железно к собственноручной. В российской практике по 63-ФЗ логика строже: без прямого соглашения сторон о признании простой или неквалифицированной подписи её доказательная сила в споре куда более уязвима. Сама постановка вопроса «эта подпись законна» некорректна в любой из юрисдикций — законна любая подпись, вопрос в том, какую доказательную силу она имеет без соглашения сторон.

Значит, выбор между OpenSign и Documenso с точки зрения юридической части сводится не к тому, какая платформа «более легальна» — обе одинаково не легальнее друг друга, — а к тому, готовы ли вы выстроить вокруг любой из них правильный процесс: оферту с явным пунктом о признании способа подписания, фиксацию согласия при онбординге контрагента, и — если документ требует силы, равной собственноручной подписи по умолчанию (отчётность, госзакупки) — интеграцию с внешним аккредитованным удостоверяющим центром через API вместо попытки закрыть это самой платформой. Ни у OpenSign, ни у Documenso нет встроенного пути к этому уровню.

Хостинг и администрирование: разные технологические миры, но не решающий фактор

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

Состав стека. OpenSign на Docker Compose поднимает больше движущихся частей: Parse Server, MongoDB, веб-приложение, иногда отдельный сервис генерации PDF — итого обычно 3-4 контейнера. Documenso компактнее: приложение Next.js и PostgreSQL, то есть 2 контейнера в минимальной конфигурации (плюс опционально почтовый релей, если не используете внешний SMTP). Больше контейнеров у OpenSign не значит «хуже» — это значит больше точек, которые нужно мониторить, обновлять синхронно и резервировать по отдельности.

База данных и то, что с ней связано. MongoDB у OpenSign — документоориентированная база без строгой схемы, что упрощает разработку кастомных полей, но означает отдельный набор инструментов для бэкапа (mongodump/mongorestore или снапшоты тома) параллельно с уже привычным pg_dump, если MongoDB больше нигде на инфраструктуре не используется. Если у вашей команды уже есть отлаженный процесс бэкапа PostgreSQL для других сервисов, Documenso органично встраивается в существующую практику без нового инструментария.

Требования к ресурсам. Точные цифры зависят от нагрузки и объёма документов, поэтому дальше — ориентиры, а не гарантия. Связка Next.js + PostgreSQL у Documenso в состоянии покоя обычно укладывается в скромный VPS (детали — в статье про RAM для Documenso выше). У OpenSign из-за большего числа сервисов (Parse Server как отдельный процесс поверх Node.js, MongoDB со своим кэшем страниц в памяти) базовый расход памяти в состоянии покоя, как правило, ощутимо выше при сравнимой нагрузке — закладывайте запас по RAM заранее, а не по факту первого падения контейнера при пике одновременных подписаний.

Обновления и миграции. У Documenso схема базы версионируется через Prisma-миграции, которые прогоняются перед стартом контейнера приложения — предсказуемо, но требует бэкапа перед каждым крупным обновлением. У OpenSign, поскольку MongoDB не требует жёсткой схемы, обновления версий приложения обычно проходят мягче с точки зрения миграции данных, но платите вы за это меньшей строгостью контроля целостности — валидация полей и связей чаще остаётся на совести кода приложения, а не СУБД.

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

Как выбирать на практике

Если сводить всё к последовательности решений, а не к абстрактному «что лучше», логика такая:

1. Определите тип документов. Внутренние согласования и подтверждения от собственных сотрудников — обе платформы одинаково подходят. Внешние договоры без предварительного соглашения о признании ЭП — ни одна не закрывает это «из коробки», нужен либо пункт в оферте о признании способа подписания, либо интеграция с аккредитованным УЦ поверх любой из систем.
2. Проверьте, что уже есть на инфраструктуре. Команда с опытом PostgreSQL — Documenso снижает трение при эксплуатации. Команда, которая не боится MongoDB и хочет массовую рассылку и вебхуки без доработки — OpenSign даёт это сразу.
3. Оцените реальную нагрузку. Много одновременных подписаний больших PDF — закладывайте запас по памяти для обеих платформ: у Documenso пик приходится на рендеринг через Chromium, у OpenSign — на Parse Server и операции с MongoDB под нагрузкой.
4. Пропишите юридическую часть заранее. Оферта или отдельный документ о признании способа электронного подписания реально определяет, будет ли подпись иметь значение при споре — технический выбор платформы к этому решению отношения не имеет.
5. Не бойтесь мигрировать при необходимости. Обе хранят PDF и метаданные в открытых форматах, поэтому переход с одной на другую при умеренном объёме архива — задача на дни, а не на месяцы.

Частые вопросы