La mayoría de las empresas tratan el open source como una obra de caridad. Contribuyen código, generan buena onda con la comunidad y esperan que algo vuelva eventualmente. En BlackBox Vision descubrimos — casi sin querer — que el open source puede ser una fuente deliberada y repetible de negocios. No a través de sponsors ni donaciones, sino por la confianza y visibilidad que genera una librería bien mantenida.
Esta es la historia de cómo un solo paquete de React Native nos trajo cinco proyectos con clientes, decenas de integraciones de terceros y un modelo de servicios pagos que sigue generando ingresos años después.
El problema: pagos en React Native
Varios de nuestros clientes necesitaban integrar MercadoPago — la plataforma de pagos dominante en Latinoamérica — en sus aplicaciones React Native. El flujo de checkout tenía que ser nativo. No un WebView, no un navegador embebido. Una UI completamente nativa.
Esto no era una preferencia. Era un requisito estricto. Apple estaba rechazando activamente las apps que usaban WebViews para procesar pagos. Si querías que tu app fuera aprobada en el App Store, tenías que usar el SDK nativo sí o sí.
El problema era que MercadoPago ofrecía SDKs para Android (Java/Kotlin) e iOS (Swift/Objective-C), pero nada para React Native. Cada equipo que necesitaba esta integración tenía que escribir su propio bridge entre JavaScript y las capas nativas — un proceso doloroso y propenso a errores que requería conocimiento profundo de ambas plataformas.
Nosotros ya estábamos haciendo este trabajo para un cliente de healthtech. Necesitaban MercadoPago integrado en su app, y el constraint era claro: UI nativa únicamente. Así que construimos el bridge.
La decisión de hacer open source
Después de completar la integración para nuestro cliente, teníamos una decisión por tomar. Podíamos quedarnos con el código privado y reconstruirlo cada vez que un nuevo cliente necesitara lo mismo. O podíamos limpiarlo, documentarlo y liberarlo a la comunidad.
Elegimos open source.
React Native MercadoPago PX nació como una librería que le permitía a cualquier desarrollador React Native integrar el checkout de MercadoPago en su app con mínimo esfuerzo. El bridge se encargaba de toda la complejidad de comunicar JavaScript con los SDKs nativos en Android e iOS.
Pero publicar una librería no era suficiente. Sabíamos por experiencia que las librerías de integración viven o mueren por su documentación.
La documentación como producto
Construimos un sitio de documentación dedicado con guías de instalación paso a paso, instrucciones de configuración específicas por plataforma, troubleshooting de problemas comunes y prerequisitos claros. El objetivo era que la librería fuera usable por cualquier desarrollador, no solo por los que casualmente entendían el linking de módulos nativos.
Fue una inversión deliberada. Buena documentación reduce la carga de soporte, aumenta la adopción y — crucialmente — construye confianza. Cuando un desarrollador llega a tus docs y todo funciona de una, se acuerda de quién lo hizo.
Cómo el open source se convirtió en un canal de ventas
Acá es donde la cosa se puso interesante. Una vez que la librería ganó tracción, empezamos a recibir consultas de empresas que caían en dos categorías:
Empresas sin desarrolladores mobile
Muchos startups y empresas chicas tenían desarrolladores web que usaban React Native para hacer apps mobile. Podían manejar la mayor parte de la app, pero integrar un SDK nativo les quedaba grande. No sabían cómo configurar archivos de Gradle, CocoaPods o el linking de módulos nativos.
Para estas empresas, ofrecimos un servicio de instalación pago. Les configurábamos la librería en su proyecto, armábamos ambas plataformas, corríamos los tests de integración y les devolvíamos un checkout funcionando. Lo que a un equipo sin experiencia le podía llevar días o semanas, a nosotros nos tomaba horas.
Empresas con desarrolladores trabados en problemas de compatibilidad
Otras empresas tenían desarrolladores React Native capaces, pero estaban peleando con problemas de compatibilidad entre versiones. El ecosistema de React Native se mueve rápido, y las dependencias nativas se rompen entre versiones. Vimos equipos pasar semanas — a veces meses — tratando de resolver errores de build causados por versiones incompatibles de dependencias.
Para estas empresas, ofrecimos un servicio de soporte técnico. Diagnosticábamos los problemas de compatibilidad, arreglábamos la configuración del build y nos asegurábamos de que todo funcionara en ambas plataformas con la última versión de React Native.
Los números
Con el tiempo, al menos cinco proyectos con clientes vinieron directamente de la librería. No eran cosas chicas — eran proyectos de integración completos donde el primer contacto fue "estamos usando tu librería y necesitamos ayuda."
Hoy, 33 repositorios y 3 paquetes de terceros dependen de React Native MercadoPago PX. Cada uno de esos representa un desarrollador o equipo que eligió nuestra solución en vez de construir la propia.
El modelo de negocio: librería gratis, expertise pago
El modelo que surgió fue directo:
- La librería es gratis. Cualquiera puede instalarla, usarla y contribuir. Esto maximiza la adopción y la visibilidad.
- Los servicios de instalación son pagos. Para equipos que necesitan que alguien les configure todo, ofrecemos un servicio de integración rápido y confiable.
- El soporte técnico es pago. Para equipos peleando con problemas de compatibilidad o casos edge, ofrecemos troubleshooting experto.
- Los proyectos grandes vienen solos. Los equipos que tienen una buena experiencia con la librería y los servicios suelen volver para cosas más grandes.
Esto no es una estrategia de loss-leader donde regalás algo esperando vender después. La librería genuinamente resuelve un problema. Los servicios pagos cubren las brechas que inevitablemente existen entre "acá tenés una librería" y "esto funciona perfecto en mi proyecto específico."
Por qué el open source construye confianza
Hay una razón por la que esto funciona mejor que el marketing tradicional. Cuando un potencial cliente evalúa tu empresa, se está preguntando: "¿Esta gente realmente puede construir lo que necesito?"
El open source responde esa pregunta antes de la primera reunión. Tu código es público. Tu documentación es pública. Tus respuestas a issues, reviews de pull requests y release notes son todos públicos. Un CTO evaluando tu empresa puede leer tu código y formarse una opinión antes de mandar un solo email.
Esa es una confianza que ningún caso de estudio, testimonial o presentación de ventas puede replicar. Se gana con competencia demostrada, no con expertise autoproclamada.
Un framework práctico para convertir OSS en negocio
Si estás pensando en usar open source como canal de negocio, esto es lo que aprendimos:
1. Resolvé un dolor real y recurrente
No hagas open source de herramientas internas que solo le importan a tu equipo. Encontrá un problema que múltiples empresas enfrenten repetidamente. Integraciones de pago, flujos de autenticación, componentes de UI complejos — cualquier cosa que los desarrolladores necesiten pero no quieran construir desde cero.
2. Invertí en documentación como si fuera un producto
Tus docs son tu vidriera. Si un desarrollador no puede hacer funcionar tu librería en 15 minutos, va a buscar una alternativa. Escribí guías de instalación claras, proporcioná ejemplos que funcionen y documentá cada error común.
3. Diseñá niveles naturales de servicios pagos
Identificá dónde es probable que los desarrolladores se traben incluso con buena documentación. Esos puntos de fricción son tus oportunidades de servicio. Instalación, configuración, fixes de compatibilidad y extensiones custom son ofertas pagas naturales.
4. Mantené la librería consistentemente
Nada mata la confianza más rápido que un repo abandonado. Respondé a los issues, mergeá los PRs razonables y mantenete al día con los cambios del ecosistema. El mantenimiento activo señala que tu empresa es confiable y está comprometida.
5. Dejá que la librería se venda sola
No hagas hard-sell a través de tus proyectos open source. Dejá que la calidad del trabajo hable. Agregá un "Built by [Company]" con buen gusto en el README y un link a tu página de servicios. Los desarrolladores son alérgicos al marketing descarado en open source — la confianza ganada convierte mucho mejor que los mensajes forzados.
El open source no es solo para techies
Lo más importante que nos llevamos de esta experiencia es que el open source no es un hobby de desarrolladores. Es una estrategia de negocios. Cuando se ejecuta bien, crea un flywheel: la librería atrae desarrolladores, los desarrolladores se convierten en usuarios, los usuarios se convierten en clientes, y los clientes financian el desarrollo continuo de la librería.
No necesitás construir el próximo Kubernetes o TensorFlow. Una librería enfocada y bien mantenida que resuelva un problema específico para una audiencia específica puede generar más valor de negocio que cualquier campaña de marketing.
La clave es encararlo con intención. No tires código al mundo y esperes lo mejor. Tratá tu proyecto open source como un producto — porque eso es exactamente lo que es.
