Smppcube против open source (Kannel · Jasmin · PlaySMS)

Начнём с неудобного: внутри Smppcube работает Kannel. Мы не собираемся убеждать вас, что открытое ПО плохое: мы сами используем его в продакшене и сделали бы тот же выбор снова. За Kannel стоит двадцать с лишним лет отлаженного кода на C, и он держит подключения к SMSC лучше, чем всё, что мы написали бы сами. Это сравнение не о качестве бесплатного ПО. Оно о гораздо более узком и гораздо более дорогом вопросе: сколько стоит превратить бесплатный транспортный шлюз (bearer, то есть уровень, который только передаёт сообщения) в бизнес, который выставляет клиентам счета, и станет ли этот проект вашим продуктом или отвлечением от него? Ниже приведены честные цифры, сравнительная таблица и случаи, когда бесплатный вариант действительно правильный выбор и вам стоит закрыть эту страницу и приступить к разработке.

Что на самом деле означает «бесплатно» на этом рынке

Бесплатная лицензия и нулевая совокупная стоимость измеряются в разных валютах, и индустрия сообщений на редкость успешно их путает. Причина в том, что бесплатная часть делает видимую, впечатляющую работу. Она работает по SMPP. Она передаёт тысячи сообщений в секунду. Она выдерживает неожиданные действия оператора среди ночи. Увидев её в работе впервые, очень легко решить, что самое сложное уже сделано.

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

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

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

Три проекта всплывают в каждом таком разговоре. Каждый хорош, каждый честно обозначает свои границы, и каждый заканчивается в своём месте.

Kannel. Классический шлюз WAP и SMS с открытым кодом, написанный на C и разделённый на BearerBox (подключения), SMSBOX (HTTP-интерфейс) и SQLBOX (таблицы очередей). Это транспортный шлюз в самом строгом смысле: он держит ваши SMPP-подключения, передаёт сообщения и делает и то и другое отлично, на объёмах, до которых не дотягивает многое коммерческое ПО. Настройка сводится к файлу, который правят по SSH. Нет графического интерфейса, нет понятия клиента, нет баланса, счёта, портала и линии поддержки. Это не недоработка проекта, а его граница, проведённая сознательно.

Jasmin. Современный SMS-шлюз и маршрутизатор на Python с действительно удачной архитектурой: маршрутизатор сообщений, интерфейс управления из командной строки jCli, HTTP API и, в отличие от Kannel, зачаточная модель биллинга, в которой у пользователя есть кредиты и каждая отправка уменьшает их по настроенному тарифу. Последний пункт важен, и именно поэтому Jasmin часто попадает в шорт-лист. Но назовём вещи точно: это кредиты на пользователя, а не система биллинга. Нет счетов, нет нескольких валют, нет разделения на предоплату и постоплату, нет тарифной сетки для клиента по маршруту и направлению, нет дерева реселлеров, нет клиентского портала. Это гораздо лучшая отправная точка, чем голый транспортный шлюз, но всё же только отправная точка.

PlaySMS. Больше всех похож на продукт, потому что это веб-приложение на PHP: интерфейс в браузере, пользовательские аккаунты с уровнями, включая уровень реселлера, простой баланс, группы контактов и модули шлюзов, которые позволяют управлять Kannel или модемом на нижнем уровне. Для небольшой компании с несколькими пользователями его действительно может хватить, и мы предпочитаем, чтобы вы узнали об этом сейчас, а не позже. Операторы вырастают из него по глубине и темпу развития: тарифные сетки по маршрутам, предоплата и постоплата параллельно, счета в нескольких валютах, настоящая изоляция тенантов, white-label для каждого тенанта, новые каналы и темп разработки, который успевает за WhatsApp и RCS, меняющими правила каждый квартал.

Во всех трёх случаях картина одна. Телеком-уровень решён и бесплатен. Коммерческий уровень не решён и ложится на вас.

Сравнение: все варианты рядом

	Kannel	Jasmin	PlaySMS	Smppcube v9
Стоимость лицензии	Бесплатно	Бесплатно	Бесплатно	6 400 $, разовый платёж
SMPP-подключения к SMSC	Отлично	Отлично	Через модуль шлюза	Kannel внутри стека
Интерфейс администратора	Нет	CLI (jCli)	Есть, базовый	Полноценный веб-интерфейс
Клиентские аккаунты	Нет	Пользователи с кредитами	Есть, базовые уровни	Мультитенантность с деревом реселлеров
Контроль баланса	Нет	Кредиты на пользователя	Простой баланс	CreditRoute, WalletRoute и AutoRoute
Тарифные сетки по маршрутам	Нет	Базовая тарификация	Ограниченно	По клиенту, маршруту и направлению
Выставление счетов	Нет	Нет	Нет	Предоплата, постоплата, регулярные счета, несколько валют
Клиентский портал white-label	Нет	Нет	Частично	Для каждого тенанта, полностью под его брендом
Отчёты, понятные клиенту	Лог-файлы	Лог-файлы	Базовые	Дашборды и экспорт
WhatsApp, RCS, голос	Нет	Нет	Нет	В той же платформе
Поддержка с ответственностью	Сообщество	Сообщество	Сообщество	Поставщик, с SLA
Время до первого платящего клиента	От 6 до 12 месяцев	От 4 до 9 месяцев	Недели, затем потолок	Дни

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

Четыре пробела и цена каждого

Руководство об альтернативе Kannel разбирает, чего транспортный шлюз никогда за вас не сделает. Эта статья берёт на себя менее приятную задачу и назначает цену каждому пробелу. Оценки ниже предполагают одного грамотного full-stack-разработчика, который уже понимает SMPP, отчёты о доставке и деньги; такой специалист встречается реже, чем кажется, и стоит соответственно.

Мультитенантность. Около 1-2 человеко-месяцев. Аккаунты, дерево реселлеров, группы прав, изоляция контактов, рассылок и имён отправителя по тенантам и выключатель, который блокирует одного клиента, не затрагивая остальных. Кажется, что это CRUD на одни выходные, пока однажды ошибка не выгрузит список контактов одного клиента в экспорт другого, а такой звонок клиенту делают только один раз.

Биллинг. Около 3-6 человеко-месяцев, и именно здесь проекты погибают. Резервировать баланс до отправки, тарифицировать по маршруту, который был фактически использован, правильно возвращать деньги при окончательной ошибке, но не при временной, делать каждую операцию идемпотентной, чтобы повтор из очереди никогда не списывал дважды, вести предоплату и постоплату параллельно, работать с несколькими валютами и формировать счёт, который примет финансовый отдел. Руководство о моделях биллинга описывает, какой дисциплины здесь требует журнал операций. Первая версия занимает месяц и выглядит готовой. Версия, которая выдерживает спор клиента из-за строки на 50,00 $, занимает шесть.

Порталы white-label и отчёты. Около 2-3 человеко-месяцев. Панель под брендом каждого тенанта: написать сообщение, загрузить список, проверить баланс, получить отчёт о доставке, посмотреть счёт. Плюс превращение сырых событий DLR в то, что клиент может отфильтровать и понять, не звоня вам. Именно с этой частью ваши клиенты работают каждый день, поэтому она не может выглядеть как внутренний инструмент.

Эксплуатация и бессрочные расходы. Около 20-30% стоимости разработки каждый год, без срока окончания. Патчи безопасности, изменившееся правило шаблонов WhatsApp, оператор, который начал возвращать новый код ошибки, разработчик вашего биллингового движка, который ушёл на другую работу и оставил вам недокументированный журнал операций. Программное обеспечение не капитальная покупка, которую делают один раз: его приходится содержать постоянно. Все считают стоимость разработки. Почти никто не считает стоимость содержания.

Итого: от 6 до 12 человеко-месяцев до первой версии, к которой вы подключили бы платящего клиента, плюс постоянная статья расходов на сопровождение. Это та же цифра, что приводится в нашем руководстве по Kannel, и это не страшилка. Столько стоит именно эта задача, и именно поэтому коммерческие платформы вообще существуют.

Совокупная стоимость владения за три года

Теперь цифры. Две колонки ниже предполагают один и тот же бизнес: реселлер с клиентами, которым нужно выставлять счета, работающий на собственном сервере. Диапазон ставок разработчика охватывает грамотного подрядчика на развивающемся рынке примерно за 3 000 $ в месяц и штатного специалиста в Европе или Северной Америке примерно за 8 000 $ в месяц. Это действительно огромный разброс, и он главная причина того, что в Лагосе это решение выглядит иначе, чем во Франкфурте.

Статья расходов, 3 года	Открытое ПО с доработкой	Smppcube v9
Лицензия на ПО	0 $	6 400 $, разовый платёж
Сервер, от 40 до 80 $ в месяц	От 1 440 до 2 880 $	От 1 440 до 2 880 $
Разработка недостающего уровня, от 6 до 12 человеко-месяцев	От 18 000 до 96 000 $	0 $
Сопровождение, 2-й и 3-й год	От 7 200 до 38 400 $	Ваше собственное время на эксплуатацию
Поддержка, когда падает подключение	Добрая воля сообщества	Включена
Итого денег за три года	От 26 640 до 137 280 $	От 7 840 до 9 280 $

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

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

Строка, которую никто не вносит в таблицу

Вот цифра, которая перекрывает всё, что выше, и она никогда не появляется в сравнениях «разработать или купить», которые публикуют на форумах.

Возьмите быстрый расчёт из руководства по перепродаже SMS: десять клиентов среднего размера, в среднем по 300 000 сообщений в месяц, дают 3 000 000 сообщений, и при наценке 0,0030 $ это 9 000 $ валовой маржи каждый месяц. Теперь отложите на шесть месяцев день, когда вы сможете подключить первого клиента, потому что вы пишете биллинговый движок. Это 54 000 $ маржи, которой так и не было, и это оптимистичный сценарий, потому что он предполагает, что клиенты вас подождут. Они не ждут. Они подписывают договор с оператором, который был готов в марте.

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

Контраргумент, честно: этот довод работает, только если клиенты действительно ждут. Если вы ещё проверяете спрос, отложенный запуск ничего не стоит, потому что откладывать было нечего. Это подводит нас к разделу, ради которого написана вся статья.

Когда открытое ПО всё же правильный выбор

Мы лучше потеряем продажу, чем продадим вам ПО за 6 400 $, которое вам не нужно. Вот четыре случая, когда бесплатный вариант правильный.

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

Вы ещё проверяете рынок. Клиентов пока нет, подписанных договоров нет, есть только гипотеза. Бесплатного шлюза и электронной таблицы вполне достаточно для достойного пилота, и за одни выходные вы узнаете, готов ли вам вообще кто-нибудь платить. Покупайте платформу, когда ответ будет «да», не раньше.

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

Ваши объёмы и маржа очень малы. Несколько тысяч сообщений в месяц с небольшой наценкой не окупят лицензию ни за какой разумный срок и не окупят шесть человеко-месяцев разработки. Оставайтесь небольшими, оставайтесь на бесплатном варианте и честно отвечайте себе, какой из этих случаев ваш.

Заметьте, что три из четырёх случаев представляют собой одну и ту же проверку в разных формулировках: является ли коммерческий уровень вашим продуктом или тем, что стоит между вами и вашим продуктом?

Как решить этот вопрос за полдня

Консультант вам не нужен. Нужны четыре честных ответа, записанных там, где потом их не получится подправить.

Первое: есть ли у вас клиенты, которым нужно выставлять счета? Если нет, остановитесь, используйте Kannel и возвращайтесь, когда ответ изменится. Если да, коммерческий уровень обязателен, и вопрос только в том, кто его напишет.

Второе: сколько для вас на самом деле стоит человеко-месяц разработки? Возьмите реальную цифру: либо сколько вы заплатили бы специалисту, либо сколько вы заработали бы за эти часы на другом деле. Если ваш ответ «нисколько, я делаю это для удовольствия», это законный ответ, и колонка разработки только что стала очень дешёвой. Всё равно запишите его, потому что он изменится в тот момент, когда у вас появится много работы.

Третье: во что обходится месяц задержки? Умножьте ожидаемую ежемесячную валовую маржу на число месяцев разработки. Если результат больше стоимости лицензии, спор уже окончен, и никакое уточнение таблицы его не вернёт.

Четвёртое: кто ответит ночью? Не кто в итоге выпустит исправление. Кто отвечает за проблему, пока у клиента не проходит ночное формирование выписок. Если ответ «я, и ещё я единственный, кто понимает написанный мной код биллинга», оцените это честно. Это человек, а не статья расходов, и именно это ограничение незаметно задаёт потолок вашего роста.

Затем примите решение и не сомневайтесь в нём. Если четыре ответа указывают на открытое ПО, у вас есть наше одобрение и уважение, а руководство по SMS-шлюзу на собственном сервере расскажет, что вас ждёт в эксплуатации. Если они указывают в другую сторону, вы покупаете на самом деле не программное обеспечение. Вы покупаете от шести до двенадцати месяцев, которые сможете потратить на клиентов, в виде разовой лицензии на вашем собственном сервере, с уже написанным мультитенантным уровнем, биллингом и порталами и с Kannel, который внизу по-прежнему делает то, что всегда умел хорошо.