Smppcube vs código aberto (Kannel · Jasmin · PlaySMS)

Vamos resolver primeiro a parte delicada: o Smppcube traz o Kannel dentro dele. Não estamos aqui para dizer que código aberto é software ruim, porque nós o usamos em produção e faríamos a mesma escolha de novo. O Kannel reúne mais de vinte anos de código C amadurecido, que mantém binds com SMSCs melhor do que qualquer coisa que nós mesmos escreveríamos. Esta comparação não trata da qualidade do software livre. Trata de uma pergunta muito mais específica e muito mais cara: quanto custa transformar um bearer gratuito (a camada que transporta as mensagens) em um negócio a partir do qual você possa faturar, e esse projeto é o seu produto ou um desvio? A seguir estão os números honestos, uma tabela comparativa e os casos em que a opção gratuita é realmente a escolha certa, e você deve fechar esta página e começar a construir.

O que “gratuito” realmente significa neste mercado

Gratuito na licença e gratuito no custo total são moedas diferentes, e o setor de mensageria é especialmente bom em confundi-las. O motivo é que a parte gratuita faz o trabalho visível e impressionante. Ela fala SMPP. Ela movimenta milhares de mensagens por segundo. Ela resiste a uma operadora que se comporta de forma inesperada de madrugada. Ao vê-la funcionar pela primeira vez, é muito fácil concluir que a parte difícil está resolvida.

A parte difícil não está resolvida. A parte difícil é a parte monótona. Um bearer transporta mensagens; um negócio decide de qual saldo de qual cliente saiu cada mensagem, a qual tarifa e por qual rota, se esse cliente tinha permissão para enviá-la, o que acontece com o dinheiro quando a mensagem falha definitivamente quatro horas depois, o que o cliente vê quando entra para conferir e o que você apresenta a um órgão regulador ou a um cliente que contesta uma cobrança seis meses depois. Nada disso está no escopo de um bearer, e nada disso é opcional se você cobra das pessoas.

Portanto, a escolha real nunca foi “pagar ou não pagar”. A escolha é: pagar uma licença uma única vez, ou pagar um desenvolvedor por seis a doze meses e continuar pagando para sempre para manter o que ele construiu. As duas opções são legítimas. Elas apenas custam valores muito diferentes, e só uma delas coloca a conta em um lugar onde você consegue vê-la.

O que cada opção de código aberto realmente cobre

Três projetos aparecem em todas essas conversas. Todos são bons, todos são honestos sobre o próprio escopo, e cada um termina em um ponto diferente.

Kannel. O gateway WAP e SMS de código aberto clássico, escrito em C, dividido em BearerBox (as conexões), SMSBOX (a interface HTTP) e SQLBOX (as tabelas de fila). É um bearer no sentido mais estrito: mantém seus binds SMPP, transporta mensagens e faz as duas coisas extremamente bem, em volumes que muitos softwares comerciais não alcançam. A configuração é um arquivo editado via SSH. Não há interface gráfica, nem conceito de cliente, nem saldo, nem fatura, nem portal, nem linha de suporte. Isso não é uma lacuna do projeto: é o limite do projeto, definido de propósito.

Jasmin. Um gateway e roteador SMS moderno em Python, com uma arquitetura realmente bem resolvida: um roteador de mensagens, uma interface de gerenciamento por linha de comando (jCli), uma API HTTP e, diferentemente do Kannel, um conceito rudimentar de cobrança, em que um usuário tem créditos que cada envio desconta a uma tarifa configurada. Esse último ponto importa, e é por isso que o Jasmin entra com frequência na lista de finalistas. Mas é preciso ser exato sobre o que ele é: créditos por usuário, não um sistema de faturamento. Não há fatura, nem várias moedas, nem distinção entre pré-pago e pós-pago, nem tabela de tarifas por cliente, por rota e destino, nem hierarquia de revendedores, nem portal do cliente. É um ponto de partida muito melhor do que um bearer puro, e continua sendo um ponto de partida.

PlaySMS. O que mais se parece com um produto, porque é uma aplicação web em PHP: interface no navegador, contas de usuário com níveis que incluem um nível de revendedor, um saldo de crédito simples, grupos de contatos e módulos de gateway que permitem acionar o Kannel ou um modem por baixo. Para uma operação pequena, com poucos usuários, ele pode ser realmente suficiente, e preferimos que você saiba disso agora a descobrir mais tarde. Onde os operadores acabam precisando de mais é em profundidade e ritmo: tabelas de tarifas por rota, pré-pago e pós-pago funcionando lado a lado, faturas em várias moedas, isolamento real entre tenants, white-label por tenant, os canais mais novos e um ritmo de desenvolvimento que acompanhe o WhatsApp e o RCS mudando as regras a cada trimestre.

O padrão é o mesmo nos três. A camada de telecomunicações está resolvida e é gratuita. A camada comercial não está resolvida e fica por sua conta.

A comparação, lado a lado

	Kannel	Jasmin	PlaySMS	Smppcube v9
Custo da licença	Gratuito	Gratuito	Gratuito	US$ 6.400, uma única vez
Binds SMPP com SMSCs	Excelente	Excelente	Via módulo de gateway	Kannel, dentro da stack
Interface de administração	Nenhuma	CLI (jCli)	Sim, básica	Interface web completa
Contas de clientes	Nenhuma	Usuários com créditos	Sim, níveis básicos	Multi-tenant com hierarquia de revendedores
Controle de crédito	Nenhum	Créditos por usuário	Saldo simples	Crédito, Carteira e Rota Automática
Tabelas de tarifas por rota	Nenhuma	Tarifação básica	Limitadas	Por cliente, rota e destino
Emissão de faturas	Nenhuma	Nenhuma	Nenhuma	Pré-pago, pós-pago, recorrente, multimoeda
Portal white-label do cliente	Nenhum	Nenhum	Parcial	Por tenant, com marca própria completa
Relatórios legíveis pelo cliente	Arquivos de log	Arquivos de log	Básicos	Dashboards e exportações
WhatsApp, RCS, voz	Não	Não	Não	Na mesma plataforma
Suporte com responsável definido	Comunidade	Comunidade	Comunidade	Fornecedor, com SLA
Tempo até o primeiro cliente pagante	6 a 12 meses	4 a 9 meses	Semanas, depois um limite	Dias

Leia essa tabela com honestidade e duas coisas se destacam. As linhas de cima, as de telecomunicações, estão empatadas ou quase, porque todos nós usamos o mesmo software como base. Toda linha em que aparecem dinheiro, clientes ou marca é onde as opções gratuitas param e o projeto de construção começa. A última linha é a que acaba pesando mais, e vamos colocar um preço nela logo adiante.

As quatro lacunas, com um preço para cada uma

O guia de alternativas ao Kannel mostra o que um bearer nunca vai fazer por você. Este artigo faz a parte menos confortável e coloca um número em cada lacuna. As estimativas abaixo pressupõem um desenvolvedor full-stack competente que já entende SMPP, confirmações de entrega e dinheiro, um profissional mais raro do que parece e remunerado de acordo.

Multi-tenancy. Cerca de 1 a 2 meses de desenvolvimento. Contas, hierarquia de revendedores, grupos de permissões, isolamento por tenant de contatos, campanhas e IDs de remetente, e uma chave de suspensão que bloqueia um cliente sem afetar os demais. Parece um fim de semana de CRUD até o dia em que um bug vaza a lista de contatos de um cliente na exportação de outro, e esse é um telefonema que você só faz uma vez.

Faturamento. Cerca de 3 a 6 meses de desenvolvimento, e é aqui que os projetos fracassam. Reservar crédito antes do envio, tarifar pela rota efetivamente usada, reembolsar corretamente em uma falha definitiva, mas não em uma temporária, tornar cada operação idempotente para que uma nova tentativa da fila nunca cobre duas vezes, manter pré-pago e pós-pago lado a lado, lidar com várias moedas e gerar uma fatura que um departamento financeiro aceite. O guia de modelos de cobrança descreve a disciplina contábil envolvida. A primeira versão leva um mês e parece pronta. A versão que resiste a um cliente contestando um item de US$ 50,00 leva seis.

Portais white-label e relatórios. Cerca de 2 a 3 meses de desenvolvimento. Um painel com a marca de cada tenant: redigir mensagens, carregar uma lista, consultar o saldo, obter um relatório de entrega, ver uma fatura. Além disso, transformar eventos de DLR brutos em algo que o cliente consiga filtrar e entender sem ligar para você. Esta é a parte que seus clientes usam todos os dias, por isso também é a parte que não pode ter aparência de ferramenta interna.

Operação e o custo permanente. Cerca de 20% a 30% do custo de construção, todos os anos, por tempo indeterminado. Correções de segurança, uma regra de modelos de mensagem do WhatsApp que mudou, uma operadora que passou a retornar um novo código de erro, o desenvolvedor que escreveu seu motor de faturamento aceitando um emprego em outro lugar e deixando para você um livro-razão sem documentação. Software não é uma compra de capital feita uma única vez: é um compromisso contínuo, que exige cuidado constante. Todo mundo calcula a construção. Quase ninguém calcula a manutenção.

Somando tudo: 6 a 12 meses de desenvolvimento até uma primeira versão na qual você colocaria um cliente pagante, mais uma linha permanente de manutenção. É o mesmo número citado no nosso guia sobre o Kannel, e não é um número para assustar. É o que este problema específico custa, e é a razão pela qual as plataformas comerciais existem.

Custo total de propriedade em três anos

Vamos aos números. As duas colunas abaixo pressupõem o mesmo negócio: um revendedor com clientes para faturar, operando no próprio servidor. A faixa de custo do desenvolvedor vai de um profissional terceirizado competente em um mercado emergente, por cerca de US$ 3.000 por mês, até uma contratação na Europa ou na América do Norte, por cerca de US$ 8.000 por mês, uma diferença realmente enorme e a principal razão pela qual esta decisão parece diferente em Lagos e em Frankfurt.

Item, 3 anos	Código aberto, com a camada construída	Smppcube v9
Licença de software	US$ 0	US$ 6.400, uma única vez
Servidor, US$ 40 a US$ 80 por mês	US$ 1.440 a US$ 2.880	US$ 1.440 a US$ 2.880
Construir a camada que falta, 6 a 12 meses de desenvolvimento	US$ 18.000 a US$ 96.000	US$ 0
Manutenção, anos 2 e 3	US$ 7.200 a US$ 38.400	Seu próprio tempo de operação
Suporte quando um bind cai	Boa vontade da comunidade	Incluído
Total em caixa em três anos	US$ 26.640 a US$ 137.280	US$ 7.840 a US$ 9.280

Antes que alguém nos escreva: sim, o limite inferior da coluna de código aberto é alcançável. Se o desenvolvedor é você, e o seu tempo não tem preço de mercado porque você estaria naquela mesa de qualquer forma, a coluna de construção cai para perto do custo do servidor e da sua paciência. É um cenário real, e nós o tratamos duas seções adiante. Mas ele não é gratuito. São seis a doze meses da sua vida profissional, investidos em infraestrutura em vez de clientes, e pagos com o único recurso que você não pode faturar depois: o seu tempo.

E observe o formato das duas colunas, não apenas os totais. Uma é um valor fixo e pequeno, totalmente conhecido desde o primeiro dia. A outra é uma faixa com variação de cinco vezes, sem data de término definida e com um custo residual que nunca acaba. Em um negócio baseado em margens estreitas por mensagem, a coluna previsível já tem valor por si só.

A linha que ninguém coloca na planilha

Este é o número que supera tudo o que foi mostrado acima, e ele nunca aparece nas comparações entre construir e comprar que as pessoas publicam em fóruns.

Pegue a conta rápida do guia prático de revenda: dez clientes de porte médio, com média de 300.000 mensagens por mês, somam 3.000.000 de mensagens, e com um spread de US$ 0,0030 isso representa US$ 9.000 de margem bruta todos os meses. Agora adie em seis meses o dia em que você consegue fazer o onboarding do primeiro cliente, enquanto constrói um motor de faturamento. São US$ 54.000 de margem que nunca existiram, e esse é o cenário otimista, porque pressupõe que os clientes vão esperar por você. Eles não esperam. Eles assinam com o operador que estava pronto em março.

Por isso o tempo até a primeira receita pertence à tabela comparativa, e por isso nós o colocamos lá. Cada mês de construção é um mês sem vender, em um mercado em que a vantagem competitiva não está na tecnologia: está na qualidade das rotas, no atendimento e na fidelidade de um cliente cujos sistemas já estão integrados à sua API. Nenhuma dessas três coisas se conquista escrevendo um livro-razão de créditos. Elas se conquistam tendo clientes, o que exige ser capaz de aceitar clientes, e é exatamente isso que a construção está bloqueando.

O contraponto, dito com honestidade: este argumento só se aplica se você realmente tem clientes esperando. Se ainda está validando a demanda, um lançamento adiado não custa nada, porque não havia receita a adiar. O que nos leva à seção para a qual todo este artigo vinha se encaminhando.

Quando o código aberto ainda é a escolha certa

Preferimos perder a venda a vender a você US$ 6.400 em software de que você não precisava. Estes são os quatro casos em que a opção gratuita é a correta.

Você é um único tenant e não tem ninguém para faturar. Uma empresa, uma operadora, seus próprios sistemas enviando suas próprias mensagens. Sem hierarquia de revendedores, sem saldos de clientes, sem faturas, sem portal. Kannel com alguns scripts é a resposta certa, e uma plataforma multi-tenant seria um peso carregado sem necessidade. Este é o caso mais comum em que dizemos: não compre.

Você ainda está validando o mercado. Nenhum cliente ainda, nenhum contrato assinado, apenas uma hipótese. Um gateway gratuito e uma planilha formam um piloto perfeitamente respeitável, e basta um fim de semana para descobrir se alguém vai pagar você. Compre a plataforma quando a resposta for sim, não antes.

Software de gateway é o seu produto. Algumas equipes estão construindo uma plataforma de mensageria para vender, ou têm um requisito realmente incomum que nenhum produto comercial atende. Se o software é o negócio, e não um custo imposto ao negócio, é claro que você deve construí-lo. Construí-lo é o objetivo.

Seu volume e suas margens são muito pequenos. Alguns milhares de mensagens por mês com um spread pequeno não amortizam uma licença em nenhum prazo razoável, e também não amortizam seis meses de desenvolvimento. Continue pequeno, continue na opção gratuita e seja honesto consigo mesmo sobre qual é o seu caso.

Observe que três desses quatro casos são o mesmo teste formulado de maneiras diferentes: a camada comercial é o seu produto, ou é o que está entre você e o seu produto?

Como decidir isso em uma tarde

Você não precisa de um consultor. Precisa de quatro respostas honestas, escritas em um lugar onde você não possa ajustá-las depois.

Primeiro, você tem clientes para faturar? Se não, pare, use o Kannel e volte quando a resposta mudar. Se sim, a camada comercial não é opcional, e a única questão é quem vai escrevê-la.

Segundo, quanto vale de fato um mês de desenvolvimento para você? Use um número real: o que você pagaria a alguém ou o que poderia ganhar usando essas horas em outra atividade. Se a sua resposta for “nada, faço isso por prazer”, é uma resposta legítima, e a coluna de construção acabou de ficar muito barata. Anote mesmo assim, porque isso muda no momento em que você fica ocupado.

Terceiro, quanto custa um mês de atraso? Multiplique sua margem bruta mensal esperada pelos meses de construção. Se esse número for maior do que uma licença, a discussão já terminou, e nenhum refinamento da planilha vai mudar isso.

Quarto, quem responde de madrugada? Não quem vai corrigir o problema em algum momento. Quem assume o problema enquanto o processamento noturno de extratos de um cliente está falhando. Se a resposta for “eu, e também sou a única pessoa que entende o código de faturamento que escrevi”, calcule isso com honestidade. Isso é uma pessoa, não um item de custo, e é a restrição que, sem alarde, limita o tamanho que o seu negócio pode alcançar.

Então decida, e fique tranquilo com a decisão. Se as quatro respostas apontarem para o código aberto, você tem nosso apoio e nosso respeito, e o guia do gateway self-hosted vai mostrar o que você está assumindo em termos operacionais. Se apontarem para o outro lado, o que você está comprando não é exatamente software. São os seis a doze meses que você passa a dedicar aos clientes, entregues como uma licença única no seu próprio servidor, com a camada multi-tenant, de faturamento e de portais já escrita, e o Kannel ainda fazendo, por baixo, o trabalho em que sempre foi bom.