Open source como estrategia: por qué regalamos código y nos va mejor

La lógica de negocio clasica te dice que protejas todo. Tu código, tus herramientas, tus secretos. Y tiene sentido, no? Bueno, nosotros hicimos exactamente lo contrario. Y nos fue mejor. Cada vez que le decimos a un cliente potencial que parte de nuestro código esta publicado en GitHub, la reaccion es la misma: "pero entonces cualquiera puede copiarte." Si. Cualquiera puede. Y aun así hacemos más negocio, no menos. Esta es la paradoja del open source como estrategia, y es una que nos tomo años en entender de verdad.

La intuicion comercial convencional dice que la ventaja competitiva viene de proteger lo que sabes. Pero en software, y especialmente en el mundo del desarrollo de productos digitales, esa lógica esta cada vez más equivocada. Lo que construyes importa menos que con quien lo construyes y que tan rápido lo haces evolucionar. Aprendimos eso de la peor manera: protegiendo cosas que no valian la pena proteger y perdiendo oportunidades de visibilidad que no supimos ver a tiempo.

Lo que no se puede copiar publicando un repositorio en GitHub es la experiencia acumulada, la velocidad de ejecución, las relaciones, el criterio para tomar buenas decisiones rápido. Esas cosas no viven en el código. Y lo que si puede hacer el open source es funcionar como una forma de marketing de contenido de alto nivel, de construcción de reputación técnica, y de demostracion práctica de lo que eres capaz de hacer. En la economía de atención en que vivimos, eso vale muchisimo.

Por qué regalar código

Hay una distincion importante que hay que hacer desde el principio: regalar código no significa regalar valor. El código en si mismo, sin el contexto de quien lo construyo, por qué lo construyo y como lo usa, es relativamente poco valioso. Lo que es valioso es el conocimiento que está detrás del código, el criterio de arquitectura, el entendimiento del problema que resuelve. Eso no se copia mirando el repositorio. La verdad es que la mayoría de la gente que "te copia" el código no tiene idea de por qué funciona cómo funciona.

El código es el artefacto. El valor está en la mente de quien lo construyo, en el criterio de cada decisión de diseño, en los errores que ya no vas a cometer.

Cuando publicamos un proyecto open source, lo que realmente estamos haciendo es mostrar como pensamos. La estructura del código, las decisiones de arquitectura, los comentarios, la documentación, el historial de commits. Todo eso cuenta una historia sobre la forma en que abordamos los problemas. Para un potencial cliente que sabe leer código, ese repositorio es el mejor portafolio que existe. Mejor que cualquier caso de estudio que escribamos nosotros mismos.

La segunda razón es la reputación técnica. En el ecosistema de desarrollo de software, la reputación es una moneda real. Los desarrolladores que contribuyen a proyectos de uso común, que escriben herramientas que otros usan, que publican código que resuelve problemas reales, acumulan un capital de confianza que no se puede comprar con publicidad. Ese capital se convierte en recomendaciones, en oportunidades, en clientes que llegan con la confianza ya construida antes del primer contacto. Nosotros lo vivimos. Y cada vez que pasa nos recuerda que la decisión fue la correcta.

La economía del open source

Comparado con publicidad pagada, el costo del open source es dramaticamente menor. Un click en Google Ads para keywords de desarrollo web puede costar entre dos y diez dolares. Un proyecto open source que genera cien visitas de desarrolladores calificados por mes tiene un costo de adquisición casi cero una vez que está construido y publicado. El esfuerzo inicial es mayor, pero el retorno acumulado en el tiempo es mucho más alto. Esto nos vuela la cabeza cuando hacemos los calculos en serio.

Pero la economía del open source no termina en adquisición de clientes. Hay una segunda capa que poca gente menciona: la reducción de costos operativos a medida que la comunidad crece. Cuando un proyecto open source tiene usuarios activos, una parte del soporte se autogestiona. Las preguntas frecuentes las responde alguien de la comunidad en los issues de GitHub antes de que el equipo original tenga que intervenir. Los bugs los reportan usuarios con suficiente contexto para que sean fáciles de reproducir. Esta inteligencia distribuida es una de las cosas más poderosas del modelo open source. Y es gratis.

Existe ademas una dimensionalidad que no aparece en los números inmediatos. Cada proyecto open source que publicas te posiciona en un espacio específico. Si publicas herramientas para Shopify, te conviertes en alguien conocido en la comunidad Shopify. Si publicas integraciones con sistemas locales chilenos, te posicionas como especialista en el mercado chileno. Esa posición en la mente de las personas correctas puede valer más que cualquier campana de publicidad. Nosotros lo vemos reflejado en que tipo de proyectos nos contactan.

Combat Pong: un experimento que nos enseno mucho

El mejor ejemplo reciente que tenemos es Combat Pong, un juego multijugador que construimos y publicamos como experimento de alcance viral. Esto es de lo que más nos gusta hacer: tomar una idea que parece absurda, construirla en serio, y ver que pasa. La idea era tomar el concepto clasico de Pong, agregarle mecanicas de combate, hacerlo multijugador en tiempo real, y publicarlo completamente abierto.

Lo que paso fue más interesante de lo esperado. El proyecto no solo genero tráfico directo al sitio, sino que inicio conversaciones sobre arquitectura de tiempo real, sobre como manejar estado en juegos multijugador, sobre el uso de WebSockets a escala. Esas conversaciones, en Discord, en Twitter, en GitHub, son exactamente el tipo de interacciones que generan oportunidades de negocio reales. Suena raro? Nosotros también lo pensabamos hasta que lo vimos con nuestros propios ojos.

La parte más valiosa del experimento de Combat Pong no fue el tráfico. Fue aprender cuales partes del proceso de construcción son las que generan más interes cuando se comparten en público. La arquitectura de sincronización de estado en tiempo real fue la que más resonancia tuvo. Eso nos dice algo sobre lo que la comunidad encuentra difícil y donde hay espacio para contribuir con más proyectos open source. Cada experimento de este tipo nos ensena algo que no podriamos aprender de otra forma.

Que abrir y que no

No todo debe ser open source. Hay una distincion importante entre lo que genera valor al abrirlo y lo que pierde valor al hacerlo. La regla que usamos nosotros es simple: lo que es infraestructura generica se puede abrir, lo que es conocimiento específico de negocio de un cliente no. Suena obvio dicho así, pero aprendimos a delimitarlo bien después de alguna confusion inicial.

Lo que tiene sentido abrir: herramientas que resuelven un problema que muchos enfrentan, implementaciónes de integraciones con plataformas conocidas, componentes de UI reutilizables, scripts de automatización que simplifican procesos comunes. Todo eso tiene valor al abrirlo porque atrae comunidad y muestra criterio técnico. Y a nosotros nos genera más negocio del que perderemos por compartirlo.

Lo que no tiene sentido abrir: lógica de negocio propietaria desarrollada para un cliente específico, algoritmos que son el diferenciador central de un producto, credenciales, datos sensibles, y cualquier cosa que fue construida bajo un contrato de confidencialidad. La línea es entre el "como" generico y el "que" específico del negocio de cada cliente. Cuando tenemos dudas, preguntamos: le sirviria esto a alguien que no es este cliente? Si la respuesta es si, candidato a abrir. Si es no, adentro del repo privado.

Abrir herramientas genericas genera reputación. Abrir lógica de negocio específica del cliente genera problemas legales y eticos. La distincion importa.

Construir en público

Build in public es una práctica relacionada pero distinta al open source. Mientras el open source implica publicar código, build in public implica compartir el proceso de construcción: los aprendizajes, los errores, las decisiones de arquitectura, los números, los fracasos y los exitos. Es transparencia radical sobre cómo funciona un negocio o un proyecto. Y honestamente, es la parte que más nos cuesta porque duele mostrar los errores. Pero es justo ahí donde está el mayor valor.

La diferencia de impacto entre publicar solo el código y publicar el código más el proceso es enorme. El código sin contexto es útil para quienes saben leerlo. El código con historia, con razonamiento, con las preguntas que se hicieron antes de cada decisión, es útil para un público mucho más amplio y genera una conexión mucho más profunda con quien lo construyo. Nosotros lo notamos en los tipos de conversaciones que arrancamos. El "como llegaste a esa decisión" genera diez veces más enganche que el "aca esta el código."

Twitter, los hilos de progreso en LinkedIn, los posteos sobre lecciones aprendidas, los write-ups técnicos en blogs como este, son todas formás de build in public que complementan el open source. Juntos crean una narrativa sobre quien eres como desarrollador o como equipo que ninguna página de "sobre nosotros" puede replicar.Te ha pasado leer el behind-the-scenes de un proyecto y terminar queriendo trabajar con esa persona? Exactamente eso.

Construir comunidad alrededor del proyecto

Un proyecto open source sin comunidad es un repositorio. Un proyecto open source con comunidad activa es una plataforma de crecimiento. La diferencia entre los dos es la atención que le prestas a las personas que interactuan con el proyecto, no solo al código. Nosotros aprendimos esto de la manera clasica: publicando repos prolijos y luego ignorando los issues durante semanas. Spoiler: no funciona.

Construir comunidad requiere inversión activa. No basta con publicar el código y esperar. Requiere responder las issues en GitHub con rapidez y amabilidad. Requiere revisar y mergear las pull requests razonablemente. Requiere documentar bien el proyecto para que sea accesible a personas que no fueron parte de su construcción. Requiere agradecer las contribuciones, aunque sean pequenas. Cada interaccion bien manejada construye reputación. Cada ignorada la erosiona.

En el contexto chileno, la comunidad de desarrollo es pequena pero activa. Comunidades como los grupos de Slack de tecnología chilena, meetups regulares en Santiago, y los espacios de Discord de proyectos latinoamericanos, son lugares donde los proyectos open source locales pueden encontrar su primera audiencia y sus primeros contribuidores. Participar en esas comunidades no como promocion sino como miembro activo que comparte y aprende es la forma más natural de dar a conocer lo que construyes. Nosotros seguimos aprendiendo de esos espacios cada semana.

El retorno invisible

El ROI del open source es difícil de medir con precisión y esa dificultad es una de las razones por las que muchas empresas no lo adoptan como estrategia. Si el retorno no cabe en un spreadsheet, parece que no existe. La verdad es que hay formás de aproximar el valor y cuando las miramos nos alegra mucho haber tomado este camino.

La primera forma es rastrear la fuente de los leads. Cada vez que alguien nos contacta mencionando un proyecto open source específico, o que demuestra haber visto nuestro trabajo en GitHub, eso es conversión atribuible al open source. Si registras esto sistematicamente durante un año, puedes empezar a ver un patrón: cuanto ingreso se puede atribuir directa o indirectamente a proyectos open source específicos. Para nosotros esa cifra supero nuestras expectativas iniciales por mucho.

La segunda forma es estimar el costo alternativo de conseguir la misma atención con publicidad pagada. Si un proyecto open source genera cien visitas mensuales de desarrolladores calificados, y el costo de conseguir esas visitas con Google Ads sería de cinco dolares por visita, el valor de ese tráfico orgánico es quinientos dolares mensuales. No es un número exacto, pero da escala al beneficio. Y el tráfico orgánico de reputación técnica convierte mucho mejor que el tráfico pagado.

Hay un ultimo efecto que no aparece en ningún análisis de ROI: el orgullo del equipo. Construir algo que otras personas usan y valoran es diferente a construir algo que solo ve el cliente que lo encargo. Los proyectos open source que tienen comunidad generan en el equipo que los construyo un sentido de contribucion que va más alla del trabajo cliente. Eso tiene valor para retener talento, para atraer buenos desarrolladores, y para mantener la cultura de calidad que hace que el trabajo sea sostenible. Es el beneficio más difícil de cuantificar y probablemente el más importante de todos.

El open source no es para todo el mundo. Requiere compromiso, disciplina y una mentalidad de abundancia que no todas las organizaciones tienen. Pero para quienes lo adoptan con seriedad, es una de las estrategias de posicionamiento con mejor retorno de largo plazo que existe en el mundo del desarrollo de software. Nosotros ya no lo imaginaremos de otra manera.

Si quieres profundizar en como pensamos sobre el desarrollo de software con proposito, te recomendamos leer sobre como construimos productos digitales desde cero. Y si quieres explorar en que podemos colaborar en proyectos de plataforma o desarrollo custom, visita nuestra página de apps y plataformas.