Leina 
Wanta OpenConnector, Composio, Nango y Pipedream: ¿qué parte es open source?
Compara el código público, el alojamiento propio y las licencias de cuatro herramientas para agentes. Descubre cómo añadir providers y migrar desde OOMOL SaaS.
OOMOL
Conectar un agente de IA a Gmail, Notion o Slack hace que la primera ejecución tenga un resultado tangible. El asistente ya puede buscar correos, actualizar documentos y realizar tareas reales.
Después aparecen preguntas más concretas. ¿Se puede añadir una operación que falta? ¿Hasta dónde se puede investigar una llamada fallida? Si un cliente exige guardar sus credenciales en infraestructura propia, ¿se puede trasladar también el servicio de conexión?
En ese momento importan el código que publica la plataforma y las partes que tu equipo puede operar. OpenConnector, Composio, Nango y Pipedream sirven para integrar aplicaciones, pero sus repositorios, licencias y opciones de despliegue tienen alcances diferentes.
Qué parte del sistema está abierta
El SDK, el conector y el entorno de ejecución cumplen funciones distintas.
- El SDK prepara solicitudes y recibe respuestas. Su código permite revisar el comportamiento del cliente.
- El código de ejecución del conector convierte una operación en una solicitud a una API externa, con la transformación de parámetros y el tratamiento de resultados. Publicarlo permite revisar y ampliar esa implementación.
- El entorno del conector ejecuta las operaciones y suele gestionar credenciales, permisos y registros. Un código público con instrucciones de despliegue permite al equipo hacerse cargo de esos componentes.
Figura 1. El código del conector se ejecuta dentro de su entorno. La implementación concreta varía entre productos.
Un SDK público no demuestra que el código de la pasarela también lo sea. Poder editar un conector tampoco basta para desplegar toda la plataforma de forma independiente.
Los cuatro productos, juntos
| Producto | Código público principal | Alojamiento propio | Alcance que conviene revisar |
|---|---|---|---|
| OpenConnector | Connector SDK, oo CLI, pasarela, definiciones de providers, ejecutores y Web Console | Rutas públicas con Docker y Node.js, además de Cloudflare | Repositorio principal: Apache-2.0; SDK y CLI: MIT. Revisar ejecutor y autorización por operación |
| Composio | SDK, CLI y adaptadores de frameworks en el repositorio principal | Opciones empresariales de alojamiento propio y despliegue privado | La licencia MIT del SDK no establece la licencia de la pasarela |
| Nango | Plataforma de integración y código de funciones | Alojamiento propio gratuito y Enterprise | Elastic License 2.0 en el repositorio principal; funciones limitadas en la edición gratuita |
| Pipedream | Componentes, documentación y paquetes relacionados | Los componentes suelen ejecutarse en la infraestructura de Pipedream | Licencia Source Available; publicar componentes no equivale a ofrecer toda la plataforma para despliegue autónomo |
Fuentes: OpenConnector, repositorio de Composio, despliegue de Composio, alojamiento de Nango y componentes de Pipedream.
Cuando falta un provider
Imagina que tu equipo incorpora un CRM y quiere que el agente consulte clientes y actualice su seguimiento. Ese servicio todavía no aparece en el catálogo.
La extensión útil consiste en añadir un provider en la pasarela: la integración del servicio con su autenticación, parámetros y operaciones. El SDK y la CLI mantienen su forma habitual de llamar a las herramientas. Normalmente no hace falta modificar su código fuente.
OpenConnector ofrece tres vías:
- Implementarlo por tu cuenta en tu pasarela, al ritmo que necesite el negocio.
- Enviar una PR para compartir la implementación con otros usuarios.
- Abrir una issue con el servicio y las operaciones que quieres que nuestro equipo incorpore.
Para estas solicitudes de nuevos providers u operaciones, normalmente integramos la funcionalidad relacionada en 24–36 horas. Es nuestro ritmo habitual de trabajo; la complejidad de la API, las cuentas de prueba y la autorización de terceros pueden afectar al plazo.
Así, una carencia del catálogo tiene una vía práctica de resolución. Puedes desarrollar la integración o colaborar con los responsables del proyecto y conservar las herramientas de llamada existentes. Consulta la guía de contribución o abre una solicitud.
El código de OpenConnector abarca Connector SDK, oo CLI, la pasarela, las definiciones y ejecutores de operaciones y la Web Console. El SDK se usa desde la aplicación; oo connector busca, inspecciona y ejecuta operaciones; MCP y HTTP/OpenAPI ofrecen otras entradas. SDK y CLI pueden conectarse al servicio de OOMOL o a un entorno propio. Herramientas de desarrollo
Los repositorios de OpenConnector, Connector SDK y oo CLI permiten revisar el recorrido del cliente a la ejecución. Tu equipo puede gestionar cuentas conectadas, permisos y registros con datos sensibles ocultos dentro de su propio entorno.
Figura 2. Captura del repositorio oficial. Los nombres y las cifras corresponden a la versión capturada, sin garantizar la cobertura actual.
Tras añadir un provider, aplicaciones y agentes siguen usando las mismas entradas. Antes de adoptar una operación, comprueba que su ejecutor esté disponible, que los parámetros cubran la tarea y que puedas cumplir la autorización del servicio externo.
El repositorio principal de Composio se presenta como un monorepo de SDK, con Python, TypeScript, CLI y adaptadores. Permite examinar el cliente, pero no demuestra que la implementación interna de la pasarela esté publicada. Repositorio de Composio
Composio sí ofrece alojamiento propio y configuraciones privadas para empresas. Sería incorrecto describirlo como exclusivamente cloud. Conviene distinguir las rutas que parten de código público, las que requieren un acuerdo empresarial y las partes que pueden modificarse después del despliegue. Composio MCP Gateway
Nango publica el código de su plataforma y admite alojamiento propio. La edición gratuita cubre principalmente autenticación y proxy API; funciones, sincronizaciones, webhooks y MCP forman parte de la oferta completa Cloud o Enterprise. Explicación de Nango
Pipedream permite leer, escribir y contribuir componentes. Estos suelen ejecutarse en su infraestructura serverless. Editar una operación y operar toda la plataforma subyacente siguen siendo capacidades diferentes. Documentación de Pipedream
El código público también tiene condiciones
Que el código sea visible en GitHub no implica que las licencias concedan los mismos permisos.
| Código evaluado | Licencia publicada |
|---|---|
| Repositorio principal de OpenConnector | Apache-2.0 |
| Connector SDK | MIT |
| oo CLI | MIT |
| SDK público de Composio | MIT |
| Repositorio principal de Nango | Elastic License 2.0 |
| Repositorio principal de Pipedream | Pipedream Source Available License |
Antes de mantener un fork, redistribuir código u ofrecer un servicio basado en él, revisa sus condiciones. La licencia de OpenConnector cubre el código del proyecto; las condiciones de las API externas, sus autorizaciones y los derechos de marca siguen aplicándose por separado.
Operar el servicio también implica mantenerlo
Un despliegue propio permite revisar el estado del entorno, los fallos recientes y los registros, y decidir qué ajustes necesita la configuración o el código.
Figura 3. Captura del repositorio oficial. Las estadísticas ilustran la interfaz, no la escala ni la fiabilidad actuales.
También hay que encargarse de las actualizaciones, copias de seguridad, claves e infraestructura, y registrar aplicaciones OAuth para algunos servicios. El control adicional trae consigo esa responsabilidad de mantenimiento.
Empezar con SaaS y migrar al crecer
OOMOL SaaS y OpenConnector comparten el mismo modelo de llamadas a conectores: identificadores de providers y operaciones, y contratos de parámetros. La aplicación o el agente conserva ese vocabulario tanto en OOMOL como en servidores propios. Opciones de uso
Puedes empezar con SaaS y desplegar OpenConnector cuando crezca el negocio o un cliente necesite infraestructura privada. Al apuntar el SDK y la CLI a tu instancia, las llamadas admitidas y sus parámetros se pueden reutilizar sin implementar de nuevo esas integraciones.
| Entrada | Cambio para alojamiento propio | Qué se reutiliza |
|---|---|---|
| Connector SDK | Inicializar OpenConnector con tu baseUrl y token del entorno | Identificadores de operaciones admitidas, entradas y métodos como execute |
| oo CLI | Configurar OO_CONNECTOR_URL y, si procede, OO_CONNECTOR_TOKEN | Comandos de conector como search, schema, run y parámetros de las operaciones |
Consulta las guías del SDK y de la CLI.
El nuevo entorno todavía necesita conexiones de cuentas, aplicaciones OAuth y credenciales. Si usas gestión de equipos, usuarios de proyecto u otras capacidades SaaS, revisa su compatibilidad por separado. El diseño compartido conserva la capa de llamadas; no traslada automáticamente todas las cuentas y funciones alojadas.
Para evaluarlo, ejecuta una operación habitual en SaaS y prueba después la misma operación con los mismos parámetros desde el mismo SDK o CLI en tu instancia. Si falta un servicio, revisa también el proceso de contribución o solicitud.
Si quieres empezar pronto y conservar una ruta hacia infraestructura propia, conecta una aplicación con OOMOL o despliega una instancia y comprueba una operación de uso diario.
Los logotipos y las capturas proceden de sitios o repositorios oficiales y se usan para identificar y comparar los productos. Los derechos pertenecen a sus respectivos titulares. El esquema conceptual se creó para este artículo.