Código abierto: ¿qué pensamos?
Desde el lanzamiento de Cal.com, hemos recibido innumerables mensajes de fundadores preguntando si el código abierto sería la dirección correcta para su startup, y por ello queríamos escribir sobre el proceso de toma de decisiones de iniciar cal.com como una empresa de código abierto, para ayudar a otros a tomar una decisión similar.
Ha habido mucho bombo en torno al código abierto desde 2021, y algunas revistas tecnológicas están escribiendo sobre el "Renacimiento del código abierto", pero queremos asegurarnos de que estás haciendo las cosas correctas por las razones correctas – o al menos reflexionar sobre tus razones.
Recientemente hemos estado recibiendo variaciones similares de la pregunta anterior con bastante frecuencia (debido al crecimiento y la cobertura de cal.com), por lo que queríamos escribir una publicación que esquematizara cómo pensamos sobre SaaS versus código abierto y cuándo abrir el código.
A pesar de que ambos hemos utilizado muchos proyectos de código abierto antes y apreciado enormemente el trabajo que hacen, ninguno de nosotros se consideraría fanático acérrimo del código abierto. Cal.com es el primer proyecto OSS en el que cualquiera de nosotros ha trabajado, ya que todos los proyectos en los que hemos trabajado antes eran de código cerrado. La mayoría de las veces había una muy buena razón por la que esos proyectos no eran de código abierto.
¿Por qué construimos Cal.com en primer lugar?
Cuando Peer trabajaba en su empresa anterior, leanhire.com, descubrió que había una necesidad urgente de una herramienta de programación más poderosa.
A diferencia del caso de uso típico donde Peer, o sus empleados, harían reservas (como en ventas o reclutamiento), necesitaban un producto de programación para su mercado de contratación. En cada mercado bidireccional, tus usuarios interactúan con otros usuarios, lo que no se adapta bien al modelo típico ofrecido por los productos de programación existentes.
Las 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 de programación más avanzados, como mercados de contratación, telemedicina y más. Por ejemplo, no sería factible para un mercado de contratación pagar $19/mes por cada asiento si tienes más de 5,000 usuarios, como Peer tenía en Lean Hire.
Los productos de programación SaaS existentes tampoco proporcionan muchas percepciones sobre lo que está sucediendo en su interior. En la incorporación de Lean Hire, anteriormente pedían a sus clientes que simplemente copiaran y pegaran su enlace de programación y la plataforma lo agregaría automáticamente a los correos electrónicos de alcance. Sin embargo, una vez que el destinatario hacía clic en el enlace de programación, la plataforma Lean Hire no tenía la capacidad de rastrear lo que sucedía a continuación.
No sabían si o cuándo ocurrieron los eventos, y si fueron reprogramados o cancelados. No había forma de cambiar el flujo de trabajo de reservas, diseño o llamadas a la API que se realizan al reservar. Por lo tanto, se necesitaba una solución abierta, accesible y extensible que pudieran autohospedar.
Peer buscó inmediatamente en Google "Calendly código abierto" porque eso es lo que significa el código abierto: abierto, accesible, extensible y autohospedable.
Para su sorpresa, no pudo encontrar un solo proyecto haciendo lo que Lean Hire estaba buscando. Coincidentemente, en ese momento, cientos de otras personas estaban buscando exactamente lo mismo. Hilos de foros, discusiones en Reddit y más fueron abiertos por personas preguntando si había un producto de programación de código abierto que pudiera rivalizar 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 teníamos la intención de hacer eran fundamentalmente más difíciles siendo un producto SaaS cerrado que siendo de código abierto.
El punto clave aquí es que las limitaciones de los productos de programación existentes solo podrían resolverse mediante código abierto. Muchos fundadores siguen el camino equivocado pensando que deberían construir una alternativa de código abierto a un producto existente, pensando que su producto tendrá éxito solo porque es de código abierto. En cambio, solo deberías considerar hacer tu proyecto de código abierto si el código abierto realmente soluciona los desafíos que deseas abordar (por ejemplo, personalización, autohospedaje).
Por ejemplo, podrías construir una alternativa de código abierto a Twitter, pero es poco probable que despegue, porque las redes sociales no se benefician realmente de ser de código abierto. Hay muchos casos de proyectos que son de código abierto solo por el hecho de ser de código abierto.
Sin embargo, si, por ejemplo, miraras la industria del comercio electrónico, que está dominada principalmente por productos SaaS como Shopify o BigCommerce, verías que tener una alternativa de código abierto permitiría a las tiendas ser autohospedadas, completamente personalizadas y etiquetadas en blanco, y ampliadas de maneras 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 desventajas obvias y no obvias. El código abierto tiene muchas ventajas de las cuales probablemente estés al tanto, pero el código abierto no está exento de desventajas.
Monetización
El software comercial de código abierto (COSS) es un modelo de empresa en tendencia donde tu producto principal es de código abierto, pero también tienes ofertas comerciales que generan ingresos. Estos tipos de empresas pueden tener un crecimiento increíble. Es la naturaleza del software gratuito y abierto tener una adopción masiva al principio. A los desarrolladores les encanta el código abierto. Les encanta poder mirar dentro de la base de código, corregir errores simples que pueden molestarlos, o simplemente ser útiles y devolver algo. ¿A quién no le gusta ser útil?
Pero el gran crecimiento y la creación de valor tienen un costo: la captura de valor. Prácticamente cada fundador de COSS con el que hablo está pensando en el concepto de creación de valor y captura de valor.
Un negocio SaaS freemium tiene dos clientes: la tarifa gratuita y la de pago. Y la proporción suele ser muy buena. Por ejemplo:
“Webflow potencia más de 100,000 sitios web para negocios grandes y pequeños.” – https://webflow.com/customers
La última valoración de Webflow se informa en $2.1B.
Una empresa de código abierto, por otro lado, se ve fundamentalmente diferente, con un montón de autohospedadores y clientes gratuitos, que a veces ni siquiera saben que existe una empresa comercial detrás del proyecto.
Por ejemplo: WordPress potencia más de 455 millones de sitios web a partir de 2021, y ese número solo sigue creciendo.
“La empresa matriz de WordPress.com, Tumblr y más, Automattic, anunciando una nueva ronda de financiamiento que eleva la valoración total de la empresa a $7.5 mil millones” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Si Webflow potenciara 455 millones de sitios web – o – si WordPress fuera un negocio SaaS centralizado con la economía y el mecanismo de captura 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 autohospedan 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 firmar un trato más grande contigo.
Por lo tanto, pensar en la duración que tiene tu empresa es importante. Probablemente tomará mucho tiempo lanzar tu empresa, construir el producto hasta un estado en el que sea competitivo con las alternativas de código cerrado, luego empezar a construir tracción y finalmente comenzar a cerrar grandes tratos. Esto significa que si no tienes la financiación para seguir trabajando en el producto mientras genera poco ingreso inicialmente, puede que no captures suficiente valor para sobrevivir.
Contribuciones
Uno de los beneficios significativos de ser de código abierto son las contribuciones de la comunidad. Hemos tenido algunas contribuciones increíbles de la comunidad por las que estamos increíblemente agradecidos. Algunas de estas son pequeñas correcciones de errores, pero otras pueden ser características enormes.
Generalmente, si las personas dentro de una empresa extienden Cal.com para sus propias necesidades, por ejemplo, para escribir una integración de Microsoft Exchange, es probable que pongan este código en una solicitud de extracción para que podamos tener esta funcionalidad dentro del proyecto en sí.
La mayoría de los ingenieros de nuestro equipo eran previamente personas que contribuyeron al proyecto en su propio tiempo, lo que funciona muy bien para nosotros porque podemos ver ejemplos de su trabajo de inmediato, ya están familiarizados con la base de código y ya tienen pasión por trabajar en el proyecto.
Robo
Uno de los principales inconvenientes del código abierto es que, con tu código libremente disponible en internet, las personas crearán copias de tu producto y robarán tu código.
A pesar de que estamos licenciados bajo AGPL y cualquier modificación del código debe ser de código abierto, todavía hay personas que lo hacen y continuarán violando estas licencias. Además, no hay nada que impida a uno de nuestros competidores mirar nuestro código y ver cómo hemos construido características, y luego tomar ese código para usarlo en su propio proyecto de código cerrado. Si hacen un buen trabajo en ello, nadie sabrá que fue robado, ya que sus productos son de código cerrado.
No hay nada que realmente podamos hacer para detener esto. Por lo tanto, intentamos abordar el problema de las copias de Cal.com simplemente teniendo una marca prominente y fuerte. Esperamos que si alguien tomara el código de Cal.com y creara su propia versión falsa, no ganara tracción ya que la gente sabe que es una copia, y que la comunidad nos lo reportara para que podamos tomar acciones legales.
Por ejemplo, el código fuente de Twitch fue comprometido en 2021, pero si intentaras tomar su código fuente y comenzar una versión falsa de Twitch, no llegarías a ningún lado.
Entonces, ¿debería abrir el código X?
Si te estás haciendo esta pregunta a ti mismo, probablemente no deberías hacerlo. Como hemos mencionado anteriormente, suele ser muy obvio si necesitas una solución que sea abierta, accesible y extensible o no. Si no la necesitas, no la abras solo por el hecho de hacerlo.
Sin embargo, si quieres vender en industrias empresariales altamente reguladas o simplemente deseas construir una solución para las masas (455M de WordPress frente a 100,000 sitios de Webflow), entonces abrir el código tiene mucho sentido.
Además, asegúrate de concentrarte en construir el mejor producto. La mayoría de los consumidores no les importa si eres de código abierto o no.
Les importa el mejor valor por su dinero. El código abierto ayuda mucho con la creación de valor: el ciclo de retroalimentación es muy rápido, los miembros de la comunidad corrigen errores, ayudan con traducciones, y muchas otras cosas, pero nunca olvides construir un producto superior sobre tu competidor SaaS.
Porque al final del día, eso es lo que realmente importa: construir algo que la gente necesite.
