Smppcube frente al código abierto (Kannel · Jasmin · PlaySMS)

Quitemos de en medio la parte incómoda: Smppcube lleva Kannel dentro. No venimos a decirle que el código abierto sea mal software, porque lo tenemos en producción y volveríamos a elegirlo. Kannel son más de veinte años de C curtido que sostiene los binds con los SMSC mejor de lo que los sostendría cualquier cosa que escribiéramos nosotros. Esta comparativa no va de la calidad del software libre. Va de una pregunta mucho más estrecha y mucho más cara: ¿cuánto cuesta convertir un bearer gratuito en un negocio desde el que se pueda facturar, y ese proyecto es su producto o es un desvío? Abajo están las cifras honestas, una tabla comparativa y los casos en los que la opción gratuita es de verdad la correcta y usted debería cerrar esta pestaña y ponerse a construir.

Qué significa “gratis” en este mercado

Gratis en la licencia y gratis en el coste total son monedas distintas, y el sector de la mensajería es especialmente bueno confundiéndolas. El motivo es que lo gratuito hace la parte visible y espectacular. Habla SMPP. Mueve miles de mensajes por segundo. Sobrevive a que una operadora haga algo grosero a las tres de la madrugada. Verlo funcionar por primera vez lleva muy fácilmente a concluir que lo difícil ya está hecho.

Lo difícil no está hecho. Lo difícil es la parte aburrida. Un bearer mueve mensajes; un negocio decide de qué saldo de qué cliente salió cada mensaje, a qué tarifa y por qué ruta, si ese cliente tenía permitido enviarlo, qué pasa con el dinero cuando el mensaje falla en firme cuatro horas después, qué ve el cliente cuando entra a consultar y qué le enseña usted a un regulador o a un cliente que reclama seis meses más tarde. Nada de eso está en el alcance de un bearer, y nada de eso es opcional si usted cobra a la gente.

Así que la elección nunca fue “pagar o no pagar”. Es: pagar una licencia una vez, o pagar a un desarrollador durante seis a doce meses y seguir pagándole después para siempre para mantener lo que construyó. Las dos son legítimas. Solo que cuestan cantidades salvajemente distintas, y solo una de ellas pone la factura donde usted puede verla.

Qué cubre realmente cada opción de código abierto

En todas estas conversaciones salen tres proyectos. Los tres son buenos, los tres son honestos sobre su alcance y cada uno se detiene en un sitio distinto.

Kannel. La pasarela WAP y SMS de código abierto clásica, escrita en C, dividida en BearerBox (las conexiones), SMSBOX (la interfaz HTTP) y SQLBOX (las tablas de cola). Es un bearer en el sentido más puro: sostiene sus binds SMPP, mueve mensajes y hace ambas cosas extremadamente bien a volúmenes que dejan en evidencia a mucho software comercial. La configuración es un fichero que se edita por SSH. No hay GUI, ni concepto de cliente, ni saldo, ni factura, ni portal, ni línea de soporte. Eso no es una carencia del proyecto: es su frontera, trazada a propósito.

Jasmin. Una pasarela y enrutador SMS moderno en Python, con una arquitectura sinceramente elegante: un router de mensajes, una interfaz de gestión por línea de comandos (jCli), una API HTTP y, a diferencia de Kannel, un concepto rudimentario de facturación donde un usuario tiene créditos que cada envío descuenta a una tarifa configurada. Esa última parte importa, y es la razón por la que Jasmin entra tantas veces en la lista corta. Pero seamos precisos con lo que es: créditos por usuario, no un sistema de facturación. No hay factura, ni multidivisa, ni distinción entre prepago y pospago, ni tarifas por cliente según ruta y destino, ni árbol de revendedores, ni portal de cliente. Es un punto de partida mucho mejor que un bearer pelado, y sigue siendo un punto de partida.

PlaySMS. El que más se parece a un producto, porque es una aplicación web en PHP: interfaz de navegador, cuentas de usuario con niveles que incluyen un escalón de revendedor, un saldo de crédito sencillo, grupos de contactos y módulos de pasarela que le permiten apoyarse en Kannel o en un módem por debajo. Para una operación pequeña con un puñado de usuarios puede bastar de verdad, y preferimos que lo sepa ahora a que lo descubra tarde. Donde los operadores se le quedan grandes es en profundidad y en ritmo: tarifas por ruta, prepago y pospago conviviendo, facturación multidivisa, aislamiento real entre clientes, marca blanca por cliente, los canales nuevos y una velocidad de desarrollo que aguante que WhatsApp y RCS cambien las reglas cada trimestre.

El patrón en los tres es el mismo. La capa de telecomunicaciones está resuelta y es gratuita. La capa comercial está sin resolver y es suya.

La comparativa, lado a lado

	Kannel	Jasmin	PlaySMS	Smppcube v9
Coste de licencia	Gratis	Gratis	Gratis	6,400 USD una vez
Binds SMPP con SMSC	Excelente	Excelente	Vía módulo de pasarela	Kannel, dentro del stack
Panel de administración	Ninguno	CLI (jCli)	Sí, básico	GUI web completa
Cuentas de cliente	Ninguna	Usuarios con créditos	Sí, niveles básicos	Multicliente con árbol de revendedores
Control de crédito	Ninguno	Créditos por usuario	Saldo simple	Rutas de crédito, monedero y automáticas
Tarifas por ruta	Ninguna	Tarificación básica	Limitada	Por cliente, ruta y destino
Facturación	Ninguna	Ninguna	Ninguna	Prepago, pospago, recurrente, multidivisa
Portal de cliente marca blanca	Ninguno	Ninguno	Parcial	Por cliente, con su marca completa
Informes legibles por el cliente	Ficheros de log	Ficheros de log	Básicos	Cuadros de mando y exportaciones
WhatsApp, RCS, voz	No	No	No	En la misma plataforma
Soporte con responsable	Comunidad	Comunidad	Comunidad	Fabricante, con SLA
Tiempo hasta el primer cliente de pago	De 6 a 12 meses	De 4 a 9 meses	Semanas, y luego un techo	Días

Lea esa tabla con honestidad y saltan dos cosas. Las filas de arriba, las de telecomunicaciones, son un empate o casi, porque todos estamos de pie sobre el mismo software. Cada fila donde aparecen el dinero, los clientes o la marca es donde las opciones gratuitas se detienen y empieza el proyecto de construcción. La última fila es la que acaba importando más, y la ponemos precio dentro de un momento.

Las cuatro carencias, con un precio cada una

La guía de alternativas a Kannel recorre lo que un bearer nunca hará por usted. Este artículo hace lo menos cómodo y le pone un número a cada carencia. Las estimaciones de abajo asumen un desarrollador full-stack competente que ya entiende SMPP, los acuses de entrega y el dinero, que es un animal más raro de lo que parece y se cotiza en consecuencia.

Multicliente. Entre 1 y 2 meses de desarrollo. Cuentas, árbol de revendedores, grupos de permisos, aislamiento por cliente de contactos, campañas y sender IDs, y un interruptor de suspensión que pare a un cliente sin tocar a los demás. Suena a un fin de semana de CRUD hasta el día en que un fallo filtra la lista de contactos de un cliente dentro de la exportación de otro, que es una llamada telefónica que solo se hace una vez.

Facturación. Entre 3 y 6 meses de desarrollo, y aquí es donde mueren los proyectos. Reservar crédito antes de enviar, tarificar por la ruta realmente usada, reembolsar bien ante un fallo definitivo pero no ante uno temporal, hacer cada operación idempotente para que un reintento de la cola no cobre dos veces, sostener prepago y pospago a la vez, gestionar varias divisas y producir una factura que un departamento financiero acepte. La guía de modelos de facturación describe la disciplina contable que hay detrás. La primera versión lleva un mes y parece terminada. La versión que sobrevive a un cliente reclamando una línea de 50.00 USD lleva seis.

Portales de marca blanca e informes. Entre 2 y 3 meses de desarrollo. Un panel con la marca de cada cliente: redactar, subir una lista, consultar saldo, sacar un informe de entrega, ver una factura. Más convertir los eventos DLR en bruto en algo que el cliente pueda filtrar y entender sin llamarle a usted. Esta es la parte que sus clientes tocan todos los días, así que es también la parte que no puede parecer una herramienta interna.

Operación y el impuesto eterno. Entre el 20 y el 30 por ciento de la construcción, todos los años, indefinidamente. Parches de seguridad, una regla de plantillas de WhatsApp que cambió, una operadora que empezó a devolver un código de error nuevo, el desarrollador que escribió su motor de facturación aceptando otro trabajo y dejándole un libro mayor sin documentar. El software no es una compra de capital que se hace una vez: es una mascota a la que hay que dar de comer. Todo el mundo modela la construcción. Casi nadie modela la comida.

Sume: de seis a doce meses de desarrollo hasta una primera versión con la que pondría un cliente de pago, más una línea de mantenimiento permanente. Es la misma cifra que da nuestra guía de Kannel, y no es un número para asustar. Es lo que cuesta este problema concreto, y es la razón por la que existen las plataformas comerciales.

Coste total de propiedad a tres años

Vamos con las cifras. Las dos columnas de abajo asumen el mismo negocio: un revendedor con clientes a los que facturar, sobre su propio servidor. El rango de coste del desarrollador va desde un contratista competente en un mercado emergente, en torno a 3,000 USD al mes, hasta una contratación europea o norteamericana en torno a 8,000 USD al mes, una horquilla verdaderamente enorme y la mayor razón por la que esta decisión se ve distinta en Bogotá que en Fráncfort.

Concepto, 3 años	Código abierto, construido	Smppcube v9
Licencia de software	0 USD	6,400 USD, una vez
Servidor, de 40 a 80 USD al mes	De 1,440 a 2,880 USD	De 1,440 a 2,880 USD
Construir la capa que falta, de 6 a 12 meses de desarrollo	De 18,000 a 96,000 USD	0 USD
Mantenimiento, años 2 y 3	De 7,200 a 38,400 USD	Su propio tiempo de operación
Soporte cuando se cae un bind	Buena voluntad de la comunidad	Incluido
Total en caja a tres años	De 26,640 a 137,280 USD	De 7,840 a 9,280 USD

Antes de que nadie escriba: sí, el extremo bajo de esa columna de código abierto es alcanzable. Si el desarrollador es usted, y su tiempo no tiene precio de mercado porque de todos modos iba a estar sentado en esa mesa, la columna de construcción se desploma hacia el coste del servidor y de su paciencia. Es un escenario real y lo decimos dentro de dos secciones. Lo que no es, es gratis. Son de seis a doce meses de su vida profesional, gastados en infraestructura en lugar de en clientes, y pagados en la única moneda que luego no podrá facturar.

Y fíjese en la forma de las dos columnas, no solo en los totales. Una es un número fijo y pequeño, completamente conocido desde el primer día. La otra es un rango con un factor de cinco de dispersión, sin fecha de fin y con una cola que no se acaba nunca. En un negocio construido sobre márgenes finos por mensaje, la columna predecible ya vale algo por sí sola.

La línea que nadie pone en la hoja de cálculo

Aquí está la cifra que empequeñece todo lo anterior, y que no aparece jamás en las comparativas de construir contra comprar que la gente publica en los foros.

Tome las cuentas de servilleta del manual de reventa: diez clientes medianos con una media de 300.000 mensajes al mes son 3.000.000 de mensajes, y con un diferencial de 0.0030 USD eso son 9,000 USD de margen bruto cada mes. Ahora retrase seis meses el día en que puede dar de alta al cliente número uno mientras construye un motor de facturación. Son 54,000 USD de margen que nunca existieron, y ese es el caso optimista, porque asume que los clientes le esperan. No le esperan. Firman con el operador que estaba listo en marzo.

Por eso el tiempo hasta el primer ingreso pertenece a la tabla comparativa y por eso lo pusimos ahí. Cada mes de construcción es un mes sin vender, en un mercado donde el foso defensivo no es la tecnología en absoluto: es la calidad de las rutas, el servicio y la permanencia de un cliente cuyos sistemas ya están cableados a su API. Ninguna de esas tres cosas se gana escribiendo un libro mayor de créditos. Se ganan teniendo clientes, lo que exige poder aceptar clientes, que es justo lo que la construcción tiene delante.

El contrapunto, dicho con honestidad: este argumento solo muerde si de verdad tiene clientes esperando. Si todavía está probando que hay demanda, un lanzamiento retrasado no le cuesta nada porque no había ingresos que retrasar. Lo que nos lleva a la sección hacia la que iba todo este artículo.

Cuándo el código abierto sigue siendo la decisión correcta

Preferimos perder la venta a venderle 6,400 USD de software que no necesitaba. Cuatro casos en los que lo gratuito es lo correcto.

Usted es un único cliente y no tiene a quién facturar. Una empresa, una operadora, sus propios sistemas enviando sus propios mensajes. Sin árbol de revendedores, sin saldos de cliente, sin facturas, sin portal. Kannel más unos cuantos scripts es la respuesta correcta, y una plataforma multicliente es peso que cargaría a cambio de nada. Este es el caso más frecuente en el que decimos no compre.

Todavía está probando el mercado. Ningún cliente aún, ningún contrato firmado, solo una hipótesis. Una pasarela gratuita y una hoja de cálculo son un piloto perfectamente respetable, y le cuesta un fin de semana averiguar si alguien le va a pagar. Compre la plataforma cuando la respuesta sea que sí, no antes.

El software de pasarela es su producto. Hay equipos que están construyendo una plataforma de mensajería para venderla, o que tienen un requisito genuinamente inusual que ningún producto comercial modela. Si el software es el negocio y no un impuesto sobre el negocio, por supuesto que lo construye. Construirlo es el objetivo.

Su volumen y sus márgenes son diminutos. Unos pocos miles de mensajes al mes con un diferencial pequeño no amortizan una licencia en ningún plazo razonable, y tampoco amortizan seis meses de desarrollo. Quédese pequeño, quédese gratis, y sea honesto consigo mismo sobre cuál de los dos es.

Fíjese en que tres de esos cuatro son la misma prueba con ropa distinta: ¿la capa comercial es su producto, o es lo que se interpone entre usted y su producto?

Decidir esto en una tarde

No necesita un consultor. Necesita cuatro respuestas honestas, escritas donde luego no pueda maquillarlas.

Primero, ¿tiene clientes a los que facturar? Si no, pare, use Kannel y vuelva cuando la respuesta cambie. Si sí, la capa comercial no es opcional y la única pregunta es quién la escribe.

Segundo, ¿cuánto vale de verdad un mes de desarrollo para usted? Use un número real: lo que le pagaría a alguien o lo que podría ganar con esas horas haciendo otra cosa. Si su respuesta es “nada, esto lo hago por gusto”, es una respuesta legítima y la columna de construcción se acaba de abaratar muchísimo. Escríbala igualmente, porque cambia en cuanto tenga trabajo de verdad.

Tercero, ¿cuánto cuesta un mes de retraso? Multiplique su margen bruto mensual esperado por los meses de construcción. Si ese número es mayor que una licencia, la discusión ya terminó y ninguna sofisticación de la hoja de cálculo va a recuperarlo.

Cuarto, ¿quién responde a las dos de la mañana? No quién lo parchea con el tiempo. Quién se hace dueño del problema mientras el envío nocturno de extractos de un cliente está fallando. Si la respuesta es “yo, y además soy la única persona que entiende el código de facturación que escribí”, póngale precio con honestidad. Eso es una persona, no una partida contable, y es la restricción que en silencio marca el techo de lo grande que puede llegar a ser.

Y luego decida, y quédese en paz. Si las cuatro respuestas apuntan al código abierto, tiene nuestra bendición y nuestro respeto, y la guía de la pasarela SMS propia le dirá a qué se está apuntando en el plano operativo. Si apuntan al otro lado, lo que compra no es realmente software. Son los seis a doce meses que se ahorra para dedicarlos a clientes, entregados como una licencia única en su propio servidor, con la capa multicliente, de facturación y de portales ya escrita y con Kannel debajo, haciendo todavía el trabajo en el que siempre fue bueno.