Open source: ¿qué pensamos?
Open source: ¿qué pensamos?
Desde el lanzamiento de Cal.com, hemos recibido incontables mensajes de fundadores preguntando si el código abierto sería la dirección adecuada para que su startup la siguiera, así que queríamos escribir sobre el proceso de toma de decisiones de empezar cal.com como una empresa de código abierto, para ayudar a otros a tomar una decisión similar.
Ha habido mucho hype en torno al código abierto desde 2021, y algunas revistas de tecnología están escribiendo sobre el "Renacimiento del código abierto", pero queremos asegurarnos de que estás haciendo lo correcto por los motivos correctos — o al menos reflexionar sobre tus motivos.
Últimamente hemos recibido bastante a menudo variaciones parecidas a la pregunta anterior (debido al crecimiento y la cobertura de cal.com), por eso queríamos escribir un artículo que explicara cómo pensamos sobre SaaS frente a código abierto y cuándo abrir el código.
A pesar de que los dos habíamos usado muchos proyectos de código abierto antes y valorado muchísimo el trabajo que hacen, ninguno de nosotros se consideraría un fan acérrimo del código abierto. Cal.com es el primer proyecto OSS en el que ha trabajado cualquiera de los dos, ya que todos los proyectos en los que habíamos trabajado antes eran de código cerrado. La mayor parte del tiempo había una muy buena razón para que esos proyectos no fueran de código abierto.
¿Por qué construimos Cal.com en primer lugar?
Cuando Peer trabajó en su empresa anterior, leanhire.com, descubrió que necesitaban desesperadamente una herramienta de programación más potente.
A diferencia del caso de uso típico en el que Peer, o sus empleados, harían reservas (como en ventas o selección de personal), ellos necesitaban un producto de programación para su marketplace de contratación. En todo marketplace de dos caras, tus usuarios interactúan con otros usuarios, lo que no encaja bien con el modelo típico que ofrecen los productos de programación existentes.
Herramientas de programación como Calendly, SavvyCal y Motion son productos increíbles para ayudarte a hacer reservas. Sin embargo, no tienen la capacidad de proporcionar la infraestructura de programación para casos de uso más avanzados, como marketplaces de contratación, telemedicina y más. Por ejemplo, no sería viable que un marketplace de contratación pagara $19/mes por cada asiento si tienes más de 5,000 usuarios, como tenía Peer en Lean Hire.
Los productos de programación SaaS existentes tampoco ofrecen muchas perspectivas sobre lo que está ocurriendo en su interior. En la incorporación de Lean Hire, antes pedían a sus clientes que simplemente copiaran y pegaran su enlace de programación y la plataforma lo añadía automáticamente a los correos de outreach. Sin embargo, una vez que el destinatario hacía clic en el enlace de programación, la plataforma de Lean Hire no tenía la capacidad de rastrear lo que ocurría después.
No sabían si los eventos ocurrían ni cuándo, y tampoco si se reprogramaban o se cancelaban. No había forma de cambiar el flujo de trabajo de la reserva, el diseño o las llamadas de API que se realizaban al reservar. Por eso necesitaban una solución abierta, accesible y extensible que pudieran autoalojar.
Peer buscó inmediatamente en Google "Calendly open source" porque eso es lo que significa open source: abierto, accesible, extensible y autoalojable.
Para su sorpresa, no pudo encontrar ni un solo proyecto que hiciera lo que Lean Hire estaba buscando. Curiosamente, en ese momento cientos de otras personas estaban buscando exactamente lo mismo. Hilos de foros, debates en Reddit y más fueron abiertos por personas preguntando si existía un producto de programación de código abierto que pudiera competir con las soluciones SaaS más populares.
¿Por qué hicimos Cal.com de código abierto?
Desde el primer día nos quedó claro que Cal.com sería un proyecto de código abierto. Las cosas que queríamos hacer eran fundamentalmente más difíciles siendo un producto SaaS cerrado que siendo open-source.
El punto clave aquí es que las limitaciones de los productos de programación existentes solo podían resolverse con código abierto. Muchos fundadores toman el camino equivocado de pensar que deberían construir una alternativa de código abierto a un producto existente, creyendo que su producto triunfará únicamente porque es open source. En cambio, solo deberías plantearte hacer tu proyecto de código abierto si el código abierto realmente resuelve los retos que quieres abordar (por ejemplo, la personalización, el autoalojamiento). Si estás evaluando este camino, merece la pena entender cómo los proyectos de código abierto pasan a modelos de código cerrado y qué impulsa esas decisiones con el tiempo.
Por ejemplo, podrías construir una alternativa de código abierto a Twitter, pero es poco probable que despegara, porque las redes sociales no se benefician realmente de ser de código abierto. Hay muchos ejemplos de proyectos que son de código abierto solo por el hecho de serlo.
Sin embargo, si por ejemplo miraras el sector del comercio electrónico, que está dominado en su mayoría por productos SaaS como Shopify o BigCommerce, verías que tener una alternativa de código abierto permitiría que las tiendas pudieran autoalojarse, personalizarse completamente y tener whitelabel, además de ampliarse de formas que no son posibles con un producto de código cerrado. Este sería un buen caso de por qué deberías abrir tu proyecto.
Además de esto, con cualquier software abierto, accesible y gratuito, hay inconvenientes obvios y no tan obvios. El código abierto tiene muchas ventajas de las que seguramente eres consciente, pero no está exento de desventajas.
Monetización
El software comercial de código abierto (COSS) es un modelo de empresa en tendencia en el que tu producto principal es de código abierto, pero también tienes ofertas comerciales que generan ingresos. Este tipo de empresas puede crecer de forma increíble. Es la naturaleza del software libre y abierto tener una adopción masiva desde el principio. A los desarrolladores les encanta el código abierto. Les encanta poder mirar la base de código, corregir errores simples que puedan molestarles o, en general, simplemente ser útiles y devolver algo. ¿A quién no le gusta ser útil?
Pero ese crecimiento masivo y esa creación de valor tienen un coste: capturar ese valor. Prácticamente todos los fundadores de COSS con los que hablo están pensando en el concepto de creación de valor y captación de valor.
Un negocio SaaS freemium tiene dos clientes: el nivel gratis y el de pago. Y la proporción suele ser muy buena. Por ejemplo:
“Webflow impulsa más de 100,000 sitios web para empresas grandes y pequeñas." – https://webflow.com/customers
La última valoración de Webflow se informa que es de $2.1B.
Una empresa de código abierto, por otro lado, se ve fundamentalmente distinta, con un montón de personas que se autoalojan y clientes gratis, que a veces ni siquiera saben que existe una empresa comercial detrás del proyecto.
Por ejemplo: WordPress impulsa más de 455 millones de sitios web a fecha de 2021, y esa cifra no deja de crecer.
“La empresa matriz de WordPress.com, Tumblr y más, Automattic, anuncia una nueva ronda de financiación que eleva la valoración total de la compañía a 7.5 mil millones de dólares” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Si Webflow diera soporte a 455 millones de sitios web — o — si WordPress fuera un negocio SaaS centralizado con la economía y el mecanismo de captación de valor de Webflow, probablemente serían las empresas más grandes del mundo.
Ser una startup COSS es, esencialmente, jugar a largo plazo. No capturarás ingresos de las personas que autoalojan tu producto por su cuenta, pero esperas que la tracción del código abierto te ponga en el radar de grandes empresas que podrían cerrar un acuerdo mayor contigo.
Por eso, pensar en el runway que tiene tu empresa es importante. Probablemente tardarás mucho en lanzar tu empresa, desarrollar el producto hasta un estado en el que compita con alternativas de código cerrado y, por último, empezar a generar tracción y cerrar acuerdos grandes. Esto significa que, si no tienes la financiación para seguir trabajando en el producto mientras al principio genera pocos ingresos, quizá no captures suficiente valor para sobrevivir.
Contribuciones
Uno de los beneficios importantes de ser de código abierto son las contribuciones de la comunidad. Hemos recibido algunas contribuciones increíbles de la comunidad por las que estamos enormemente agradecidos. Algunas son pequeñas correcciones de errores, pero otras pueden ser funciones enormes.
Normalmente, si personas dentro de una empresa amplían Cal.com para sus propias necesidades, por ejemplo para escribir una integración con Microsoft Exchange, probablemente pondrán ese código en una pull request para que podamos tener esa funcionalidad dentro del propio proyecto.
La mayoría de los ingenieros de nuestro equipo eran antes personas que contribuían al proyecto en su tiempo libre, lo que nos viene genial porque podemos ver ejemplos de su trabajo de inmediato, ya están familiarizados con la base de código y además ya sienten pasión por trabajar en el proyecto.
Robar
Uno de los principales inconvenientes del código abierto es que, al tener tu código disponible libremente en Internet, la gente creará copias de tu producto y robará tu código.
A pesar de que tenemos licencia AGPL y cualquier modificación del código tiene que abrirse como código abierto, todavía hay personas que incumplen y seguirán incumpliendo estas licencias. Además, nada impide que uno de nuestros competidores mire nuestro código y vea cómo hemos construido las funciones, y luego use ese código en su propio proyecto de código cerrado. Si lo hacen lo bastante bien, nadie sabrá que fue robado, ya que sus productos son de código cerrado.
No hay mucho que podamos hacer para detener esto. Por eso intentamos abordar el problema de las copias de Cal.com simplemente teniendo una marca destacada y fuerte. Esperamos que, si alguien tomara el código de Cal.com y creara su propia versión clonada, no ganara tracción porque la gente sabría que es una copia, y que la comunidad nos lo reportara para que pudiéramos tomar medidas legales.
Por ejemplo, el código fuente de Twitch se vio comprometido en 2021, pero si intentaras tomar su código fuente y lanzar una versión clonada de Twitch, no llegarías a ninguna parte.
Entonces, ¿debería abrir X como código abierto?
Si te estás haciendo tú mismo esta pregunta, probablemente no deberías hacerlo. Como hemos mencionado antes, normalmente es muy evidente si necesitas o no una solución abierta, accesible y extensible. Si no la necesitas, no la abras como código abierto solo por hacerlo.
Sin embargo, si quieres vender a empresas, a sectores muy regulados o simplemente quieres construir una solución para las masas más amplias de personas (455M sitios de WordPress frente a 100,000 sitios de Webflow) entonces abrirlo como código abierto tiene muchísimo sentido.
Además, asegúrate de centrarte en construir el mejor producto. A la mayoría de los consumidores realmente no les importa si eres de código abierto o no.
Les importa obtener el mejor valor por su dinero. El código abierto ayuda muchísimo a crear valor: el ciclo de feedback es rapidísimo, los miembros de la comunidad corrigen errores, ayudan con las traducciones y hacen muchas otras cosas, pero no olvides nunca construir un producto superior al de tu competidor SaaS.
Porque, al final del día, eso es lo único que importa: construir algo que la gente necesite. Si te interesa cómo sigue evolucionando nuestro pensamiento sobre el código abierto, lee un mensaje de nuestro fundador sobre nuestro próximo capítulo.