¿Debería convertir mi empresa en open source? (2022)

• Supabase eligió ser open source desde sus inicios y, al construir el producto públicamente, obtuvo beneficios mayores de lo esperado en comunidad, contratación y expansión del producto.
• Las preocupaciones más comunes son las críticas a la calidad del código, la exposición de vulnerabilidades de seguridad y la copia por parte de competidores, pero la apertura también puede traducirse en mejoras colaborativas e iteración rápida.
• En contratación, las contribuciones al repositorio muestran el código real del candidato y su forma de colaborar, y Supabase solo comenzó con reclutamiento outbound después de contratar a 32 desarrolladores.
• Las funciones para pocos usuarios, integraciones y adaptadores pueden ser creados directamente por la comunidad, ampliando el alcance del producto y compensando los límites de prioridad del equipo interno.
• La defensibilidad de una empresa open source no proviene tanto de esconder el código, sino de acumular durante mucho tiempo velocidad de ejecución, marca, equipo y comunidad.

---

Por qué Supabase eligió open source desde el principio

• Supabase fue open source desde el día uno, y como sus fundadores eran usuarios y defensores de larga data de proyectos públicos como PostgreSQL, Python, Bitcoin y React, en ese momento no se sintió como una decisión difícil.
• A diferencia de la expectativa de que construir un negocio públicamente sería una carga, en el proceso de hacer crecer el producto y la empresa aparecieron varias ventajas inesperadas.
• Aunque parte de la experiencia de una empresa de herramientas para desarrolladores o PaaS, gran parte de esto también puede aplicarse a empresas de software en general.
• Hay tres preocupaciones recurrentes que suelen frenar el cambio a open source:
  • La gente podría criticar un código desordenado o incompleto.
  • Los hackers podrían encontrar y explotar agujeros de seguridad.
  • Los competidores podrían robar la propiedad intelectual.

La preocupación de “mi código es malo”

• La ansiedad por el mal código suele estar más cerca de un problema de orgullo personal, y si alguien se toma el tiempo de revisarlo, probablemente encontró allí algo que vale la pena perseguir.
• Como en la historia de Stone Soup, si compartes una buena idea con la comunidad, otras personas pueden adoptarla y mejorarla contigo.
• La comunidad puede refactorizar o reemplazar código malo, e incluso introducir nuevas guías de calidad de código para mejorar futuras contribuciones.
• Los miembros tóxicos que solo se quejan del código sin proponer mejoras no son, desde el inicio, el tipo de comunidad que quieres construir.
• Los contribuidores de open source suelen tener un “cementerio” de proyectos viejos, y eso se convierte en una biblioteca de ideas y enfoques para quienes intentan hacer algo parecido.
  • Alguien puede inspirarse en una forma específica de resolver un problema.
  • Como mínimo, puede ahorrar tiempo evitando repetir los mismos errores.
  • Es más probable que un proyecto viejo sea útil o simplemente pase desapercibido, que termine dañando tu reputación.

Código público y seguridad

• Al operar una solución alojada con código público, el mayor miedo es que un actor malicioso lea el código, encuentre vulnerabilidades y hackee el servicio.
• En la experiencia de Supabase, la frase de Linus's law, “con suficientes ojos, todos los bugs son obvios”, también aplica a los problemas de seguridad.
• Desde temprano, investigadores de seguridad, muchas veces anónimos, ayudan a revisar el código y la plataforma para detectar problemas potenciales.
• Si ofreces un SaaS, deberías publicar una guía simple en /.well-known/security.txt para que investigadores de buena fe sepan cómo divulgar problemas potenciales.
• Ponen a Bitcoin como ejemplo de un proyecto público que puede ser más seguro que una base de código propietaria.
  • Andreas M. Antonopoulos dijo en una charla de 2015 que los sistemas bancarios cerrados tienen un sistema inmunológico débil en términos de software.
  • En sistemas cerrados, grandes fallas de seguridad pueden permanecer ocultas durante mucho tiempo y causar daños enormes cuando finalmente se explotan.
  • En protocolos open source como Bitcoin, los agujeros de seguridad son visibles para todos, los exploits suelen descubrirse antes y con más frecuencia, y luego se parchean.
• Como una empresa de software exitosa puede construirse durante más de 10 años, a largo plazo un sistema open source puede acercarse más a un estado seguro que un sistema propietario y secreto.
• En una época de competencia feroz por contratar excelentes ingenieros de seguridad, el valor de la revisión pública crece aún más.

Competidores y preocupaciones sobre propiedad intelectual

• En software, las ideas son baratas y el valor casi siempre se crea en la ejecución de esas ideas.
• Si compartes tus ideas con el mundo, puedes enfocarte en iterar más rápido en lugar de preocuparte por quién accede a tu base de código.

• Construir una comunidad de expertos

  • Para construir una empresa exitosa, necesitas ejecutar bien durante mucho tiempo, por ejemplo 10 años, y hacer crecer tu base de clientes.
  • En esa carrera de largo aliento, la ventaja que un competidor obtiene al mirar tu base de código probablemente no sea tan grande si se mira el período completo.
  • Durante ese tiempo, la base de código probablemente será iterada y refactorizada muchas veces.
  • A largo plazo, la forma de ganar es construir el equipo y la comunidad que mejor iteran y mejoran tu solución en el mundo.

• Ganar en el mercado

  • Si un mercado total direccionable (TAM) grande y en crecimiento realmente vale la pena, es poco probable que sea un escenario de winner-takes-all.
  • Hay que encontrar primero un segmento de usuarios al que puedas sorprender y luego iterar rápido.
  • El tiempo que gastas enfocándote en competidores es tiempo que podrías dedicar a mejorar el producto o el equipo.
  • Si un competidor puede hacer fork de tu proyecto open source y lanzar más rápido, probablemente igual ibas a perder esa competencia.
  • En software, la IP y las patentes son famosas por ser difíciles de hacer valer, así que preocuparte menos por proteger ideas de software con abogados te ahorra tiempo, dinero y energía mental.
  • Un negocio puede protegerse mejor siendo quien mejor implementa una idea de software en el mundo.

• Competencia cloud en etapas posteriores

  • Cuando un proyecto alcanza una escala considerable, puede enfrentarse a situaciones como Elastic o Mongo, donde grandes proveedores cloud ofrecen el producto con un modelo de distribución más fuerte.
  • El mayor problema de una empresa que recién empieza es llegar primero a ese punto.
  • Si AWS llega a sacar recursos de una de sus líneas de productos multimillonarias para competir contigo con un producto alojado, entonces ya te está yendo muy bien.
  • Una respuesta más constructiva es identificar desde antes las áreas donde puedes adelantarte a cualquiera en la competencia.
  • Muchos proveedores cloud suelen tener una experiencia de desarrollador (DX) deficiente, así que DX puede convertirse en una capacidad central.
  • Si dentro de 6 años Google intenta quitarte el almuerzo, tu marca, tu equipo y tu comunidad deberían haberse preparado durante los años previos para una pelea tipo David contra Goliat.
  • Hay que planificarlo desde el principio para no ser tomado por sorpresa, y usar el tiempo y el enfoque para construir una estrategia ganadora.
  • Si un competidor viene a buscar ideas, siempre irá un paso detrás, y especialmente al inicio, cuando los recursos son escasos, preocuparse por la competencia consume todavía más energía.

Efecto en la contratación de desarrolladores

• Uno de los grandes problemas que sufren las startups, sin importar su tamaño, es la dificultad de contratar desarrolladores.
  • Es difícil hacer sourcing.
  • Es difícil evaluar desarrolladores.
  • Es difícil convencerlos del nivel de sus futuros colegas.
• El open source puede ayudar a reducir estos problemas de contratación.

• Sourcing público

  • Todos los desarrolladores se benefician del open source, y muchos quieren devolver ese beneficio contribuyendo a proyectos open source interesantes.
  • Las razones para contribuir pueden ser una buena comunidad, aprender nuevas tecnologías o disfrutar resolviendo problemas técnicos difíciles en una base de código desconocida.
  • Si reduces la barrera de contribución en un proyecto open source, es posible que excelentes desarrolladores lo encuentren.
  • Los contribuidores pueden participar en discusiones de issues, corrección de bugs, identificación de problemas y revisión de PR.
  • No todos los contribuidores están buscando trabajo, pero a muchos puede atraerles la posibilidad de trabajar tiempo completo con código open source.
  • Supabase solo comenzó con reclutamiento outbound después de operar por más de 2 años y contratar a 32 desarrolladores.
  • El open source fue uno de los principales canales de descubrimiento de talento para Supabase y seguirá siéndolo.
  • En una empresa remota y asíncrona, una estrategia de contratación basada en open source permite que las capacidades del candidato se muestren por sí solas, y facilita verificarlas.

• Contribuciones reales en lugar de LeetCode y pruebas por tareas

  • Una de las cosas que más molesta a los desarrolladores al buscar su próximo trabajo es tener que resolver problemas de LeetCode o hacer pruebas tipo take-home durante el proceso de entrevista.
  • Ese enfoque consume mucho tiempo, es agotador y muchas veces no representa el trabajo real que harán.
  • Si alguien contribuye a un repositorio, ya existen materiales como:
    • Ejemplos de cómo se comunica con el equipo y con miembros de la comunidad en un entorno remoto y asíncrono.
    • Ejemplos de contribuciones de código reales.
  • El candidato también puede evaluar a la empresa.
    • Puede ver si el equipo valora la calidad del código.
    • Puede ver si se comunica de forma efectiva.
    • Puede juzgar si toma buenas decisiones técnicas.
  • Las personas contratadas a través del repositorio de Supabase se volvieron indispensables por cuenta propia; en algunos casos lideraron el desarrollo del repositorio existente o iniciaron nuevas client libraries y SDKs.
  • No tuvieron que resolver problemas de LeetCode por Zoom.

Ampliar funciones para minorías de usuarios e integraciones

• Al crear una startup, muchas veces solo hay tiempo para resolver los problemas más grandes.
• Para moverte rápido, tienes que enfocarte en lo que pide el 80% de tu base de usuarios {p:80}.
• Las funciones que piden minorías de usuarios suelen posponerse indefinidamente.
• Si el sistema es open source, esos usuarios pueden contribuir directamente las funciones que necesitan, aumentando la utilidad del software.
• Este efecto aparece con frecuencia en integraciones y adaptadores.
  • Un usuario puede querer una integración con Azure o Vercel.
  • Si otra persona aporta los recursos de desarrollo para crear esa conexión, todos los usuarios del proyecto se benefician.

No reinventar la rueda una y otra vez

• En un mundo sin open source, las empresas tecnológicas seguirían reinventando la rueda constantemente.
• Supabase no solo publica nuevos proyectos como open source, también intenta apoyar proyectos open source existentes antes de construir algo nuevo.
• Sería una pérdida de tiempo y esfuerzo de desarrolladores que las automotrices usaran funciones propietarias, elementos de UI propietarios, bibliotecas de ventanas propietarias, sistemas operativos propietarios y drivers propietarios para mostrar mensajes de error que casi nadie verá.
• Supabase Launch Week es una recopilación de lo que el equipo y la comunidad construyeron durante los últimos 3 meses, y una de las ventajas de operar una empresa open source se ve en la velocidad de avance de la comunidad.
• Puedes leer más en el post de Launch Week 4, y si quieres participar, puedes visitar Supabase GitHub.

[GN⁺]

Opiniones de Hacker News

• Aquí hay una gran suposición implícita sobre la rentabilidad sostenible, y en particular hay partes que no cuadran con la realidad percibida si se consideran cosas como los sueldos de desarrolladores en EE. UU.
  En resumen, una empresa open source necesita que le caiga un rayo dos veces: una al proyecto open source y otra a la empresa.
  En el equipo de Graphistry nos gusta y trabajamos con open source todos los días; ayudamos a iniciar proyectos que derivaron en Apache Arrow y Nvidia RAPIDS, y también publicamos como open source clientes de Python/JS. PyGraphistry[AI] es una especie de navaja suiza para grafos, e incluye herramientas como GFQL, que implementa un lenguaje de consultas de grafos tipo Cypher en una forma embebible, nativa de dataframes y hasta acelerada por GPU.
  Pero el crecimiento sostenible viene principalmente de vender licencias de autohosting en la nube/on-premises de nuestro servidor de visualización de grafos con GPU a empresas, gobiernos y compañías de datos. Después de aguantar varios años, por suerte este negocio está creciendo bien, y aunque los ingresos de hosting SaaS por sí solos alcanzan para mantener a un equipo pequeño, no sostienen a la mayor parte del equipo. Sin los ingresos por licencias de autohosting, desaparecería la mayor parte de nuestro ciclo de innovación.
  Siento que este artículo pasa por alto la intersección entre la suerte de ganar la lotería, las características del mercado SaaS y la defensibilidad técnica. No digo que sea imposible, porque en nuestro caso el lanzamiento de Louie.AI y GFQL está cambiando la viabilidad comercial del open source, pero por lo que vivimos hasta llegar acá, me preocupan los nuevos fundadores que lean este artículo.

  • Me confundió la expresión “our GPU graph viz server”. No entendía cómo estaban extendiendo graphviz[1] en GPU ni cómo se podía ganar dinero con hosting de graphviz, pero después de mirar rápido el sitio web me quedó claro.
    [1] https://graphviz.org/
  • Me pregunto si las empresas que compran soluciones on-premises están comprando el código fuente o comprando soporte.
    Es decir, la clave es si son clientes que, si uno dice “ahora vamos a publicar el código”, responderían “genial, entonces cancelo el contrato”.

• Se dice: “Cuando hablo con otros fundadores sobre modelos de negocio open source, aparecen una y otra vez tres preocupaciones: que critiquen el código por estar desordenado, ser malo o estar incompleto; que hackers encuentren y exploten agujeros de seguridad; que competidores roben propiedad intelectual”. Creo que falta una cuarta.
  Que Amazon/AWS pueda comercializar y vender un servicio basado en mi código sin pagar nada.

  • Como alguien que ha creado y mantenido proyectos open source durante 20 años, la preocupación de “qué dirá la gente de mi código desordenado” me parece un poco graciosa.
    Cuando interactúo con usuarios y feedback mantengo la cortesía, pero por dentro pienso: “hablar es fácil. Yo sí lo construí. Cállate o manda un PR”. Como era de esperarse, esas personas casi nunca mandan un PR.
    Hay que seguir haciendo el trabajo real de construir y sacudirse a quienes solo critican.
    [0] - https://heywillow.io/
  • Esa parte se trata más adelante, en el párrafo sobre la “etapa tardía”.
    Si las grandes empresas intentan copiarte, ya estás ganando, y hace falta un plan previo para mitigarlo. Pero si interpreté bien el artículo, parece decir que no es un problema en el que haya que concentrarse o preocuparse al inicio.
  • Lo más importante es otra cosa: es realmente difícil ganar dinero distribuyendo el producto gratis.
  • Basta con elegir una licencia mejor, como GPL o AGPL.
    Las empresas de cloud se devoran otros productos open source porque esos productos no eligieron licencias que protegieran adecuadamente su trabajo.

• Es un artículo realmente bueno y profundo, pero hay algo que muchos proyectos pasan por alto: venderle al sector gubernamental civil.
  El gobierno de EE. UU. tiene muchos programas tecnológicos, como subsidios de la NSF, y como las agencias civiles, las agencias de inteligencia y los gobiernos estatales están fragmentados entre sí, termina existiendo un panorama de procurement de software enormemente amplio. Las barreras regulatorias y de compliance tampoco son tan altas como se cree, especialmente si los primeros contratos se ganan junto con socios. Suele ser ingreso estable y garantizado, capaz de financiar proyectos con compromisos de 3 a 5 años, y la rentabilidad es altísima.
  Me gustaría que más empresas open source aprovecharan esto. Porque muchas veces empresas totalmente privadas incorporan bibliotecas open source en sus productos, les agregan márgenes enormes y se quedan con todo.
  Ej.: https://x.com/ssankar/status/1749202248700420587?s=20
  Cuando estaba en el gobierno, vi mucho software de 12 millones de dólares que básicamente era una combinación de mapas open source + una DB open source. También vi, como otros puntos de referencia, OCR de PDF por 2 millones de dólares al año y herramientas tipo weights & biases por 30 millones de dólares al año.
  Además de la distribución de software, hay otros incentivos. Por ejemplo, priorizar la corrección de un bug específico o una falla de seguridad. Es muy probable que las agencias de inteligencia hayan pagado mucho dinero por safetensors.
  Supabase tendría cuatro caminos posibles: venta directa a Cybercom, venta directa a DOS o mediante contrato de equipo, venta al VA mediante un PWS, o venta directa a grandes contratistas de software del gobierno.
  La forma de ejecutarlo es enviar cold emails a un GS 14/15 o equivalente, contratar a un ex-GS15, o buscar licitaciones adecuadas en SAM.gov y luego preparar propuestas usando GovPro.ai como servicio completo, o rogue si quieren hacerlo ustedes mismos.

  • Creo que el gobierno y las startups normalmente no encajan bien.
    Para cuando la burocracia gubernamental termina de aprobar el contrato, es muy probable que la mayoría de las startups ya se haya quedado sin dinero.
  • Acabo de empezar un contrato de investigación con el gobierno, y si esto se parece aunque sea un poco, hay que tener cuidado.
    Los contratos pueden ser rentables, pero la burocracia es enorme y se necesita alguien con experiencia manejándola. No es un camino para todos, y consume mucho tiempo y negociación.
  • Estoy de acuerdo en que el gobierno es un mercado subestimado, pero no empezaría por el gobierno federal.
    Dejando de lado la enorme burocracia, el gobierno federal es la organización gubernamental más grande, lenta y difícil de manejar. Solo dentro de EE. UU. hay decenas de miles de otros entes gubernamentales: escuelas, ciudades, condados, estados, distritos de agua y bomberos, bibliotecas, etc.
    Si quieres entrar al sector público, es mejor acercarte de forma pequeña y amplia, no apostar todo al actor más grande.
  • Es un buen camino si funciona, pero también hay muchas razones por las que podría no serlo.
    El sector gubernamental más rentable del mundo es el Departamento de Defensa de EE. UU..
    Pero el Departamento de Defensa es increíblemente burocrático, sensible a los plazos y obsesionado con el secreto.

• El modelo de negocio de Supabase consiste en promocionarse como una empresa de código abierto, pero en la práctica nadie en su sano juicio intentaría alojarlo por su cuenta para producción.
  Por cosas como documentación sutilmente incompleta, bugs sutiles y funciones importantes sutilmente ausentes. Así que recibe elogios por ser open source, pero en realidad no es práctico; lo veo simplemente como una herramienta de marketing.

  • Que un producto como Supabase sea open source sí tiene ventajas reales.
    La primera es tranquilidad. Aunque hoy no lo alojes tú mismo, tienes una vía de salida adicional si el servicio deja de gustarte. Por supuesto, también deberían ofrecer acceso a los datos en crudo.
    La segunda es la calidad del código. Si alguna vez lidiaste con código realmente malo que por fuera parecía funcionar bien, sabes lo importante que es tener código que no dé vergüenza publicar.
    La tercera es la posibilidad de contribuir. Antes pensaba que no era gran cosa, pero después de vivirlo varias veces, es enorme poder pedir cambios o contribuir directamente cuando faltan funciones, hay bugs o problemas de rendimiento. En la mayoría de los proyectos de código cerrado, ya es tener suerte contar siquiera con un canal transparente para pedir funciones.
  • Incluso si solo usas la versión comercial, la ventaja de un producto open source es que pone un límite superior a qué tan “malvada” puede volverse la empresa.
    Si se supera cierto umbral, la gente puede decidir invertir esfuerzo en un fork. MariaDB es un ejemplo de eso.
    Hubo personas que nos dijeron directamente que justamente eso les daba tranquilidad para usar el servicio administrado de nuestra empresa.
  • A menos que se quiera decir que Supabase publica deliberadamente software separado y defectuoso para la comunidad open source con el fin de convencerla de que el servicio comercial es una opción más estable, no entiendo por qué una empresa haría algo así.
    Parece mucho más fácil ser una empresa open source legítima y real.
    Si no se quería decir eso y leí mal, entonces el resto hace que Supabase se vea muy bien.
  • Estoy de acuerdo con esta parte. Un software open source “bien hecho” debería poder instalarse con el gestor de paquetes de la distribución y, aunque tenga cierta opinión orientada a un caso de uso específico, debería tener valores predeterminados funcionales con un mínimo de cuidado.
    Tal vez no sea viable comercialmente, pero el estado actual erosiona fuertemente los estándares que uno puede esperar del software open source, y no veo un beneficio claro de largo plazo para las empresas que eligen ese enfoque.
  • El open source no se trata solo de alojarlo uno mismo.
    Aunque el desarrollador no lo ejecute directamente, permite ver el código que realmente está corriendo.

• Me gusta Supabase, también me gusta el open source comercial en general, y estoy de acuerdo con buena parte del artículo.
  Pero la parte que dice “en software, las ideas son baratas. El valor casi siempre se crea al ejecutar la idea” me suena rara.
  He escuchado esa frase en situaciones como “tengo una gran idea de startup, ¿firmas un NDA antes de que te la cuente?”.
  Pero si publicas el software como open source, no estás ofreciendo solo la idea, sino también una parte sustancial de la ejecución de esa idea.
  Claro que el código no es toda la ejecución; eso se extiende a ventas, marketing, soporte, etc. Aun así, me parece que el artículo subestima demasiado el valor del código e insinúa que no vale nada sin ventas y marketing, y no creo que eso sea cierto.

  • El código no es inútil, pero sin ventas, marketing y conversaciones con clientes, está bastante cerca de serlo.
    Si tuviera que repartir el valor, diría 90% ventas/marketing/validación con clientes y alrededor de 10% código. Opero un SaaS bootstrappeado con ingresos de siete cifras bajas, y puedo decir que el código en general es un desastre y está en evolución constante.
  • Creo que el código, una vez creado, no tiene valor, porque el costo de copiarlo es 0.
    Una casa no se puede copiar gratis, pero el software sí.
    A los desarrolladores se les paga por el proceso de crear el código y por resolver todos esos pequeños problemas invisibles.
    Por eso vender software es tan rentable. Si no vendes el software, no puedes ganar dinero con él. El software no es como los objetos físicos de la realidad que compartimos.

• Para mí, la pregunta central no es si el código es lo bastante bueno o si un competidor lo va a copiar, sino si puedes ganar suficiente dinero como para construir un negocio sostenible.
  Los proyectos open source citados y queridos no son buenos negocios: PostgreSQL, Python, Bitcoin, React.
  Mongo y Elastic son excelentes, pero son excepciones. Hay más empresas exitosas de bases de datos de código cerrado que empresas de bases de datos open source.
  Una empresa open source es difícil. Pero para los usuarios es muy valiosa.

  • Mongo y Elastic cambiaron sus licencias a SSPL, la “Server Side Public License”, que se parece más a una variante propia de la AGPL. La OSI declaró que no es una licencia open source [1].
    Dejando de lado el debate sobre qué licencia es “open source”, lo importante es que estas empresas concluyeron que licencias ampliamente usadas como (A)GPL, Apache y MIT dejan mucho margen para que competidores creen servicios administrados/hosteados y compitan por escala. Por ejemplo, cuando OpenSearch de Amazon ofreció ElasticSearch más barato.
    [1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

• Parece que esta pregunta se usa con el sentido de “¿nuestra empresa debería publicar el código fuente de su software?”.
  Pero para mí, responder la pregunta original ofrece un camino para responder la pregunta reformulada. La pregunta original trata sobre la naturaleza del software que la empresa usa, no del software que vende.
  Personalmente, si existe una alternativa, siempre elegiré el producto open source. Incluso si estoy dispuesto a pagar costos de soporte o donar al proyecto. El acceso libre para ver el código fuente es fundamentalmente importante incluso en software que no tengo ninguna intención de modificar.
  Sé que a mucha gente le parece una postura extrema. Pero detesto la idea de no poder desarmar un microondas, una manija de puerta o una transmisión. Puede que no logre volver a armarlo bien, pero también podría encontrar un engranaje roto y hacer una reparación de 2 dólares en vez de un reemplazo de 90. O podría construir un microondas Frankenstein con transmisión.
  Para mí es importante poder extender las funciones de un servidor web o entender por qué mi plugin crashea la app host. También creo que es importante para la sociedad. Por eso me aferro a mi extremismo open source. Si me muestran un servidor web ultracompacto moderno que maneja HTTPS/4 en 5 KB con IA integrada, me va a interesar, pero si no es open source, seguiré usando el stack actual.
  Por esta mentalidad, el software que hago es open source, y a veces la gente paga por él.

• Sobre la parte que dice: “si dentro de 6 años Google intenta robarte el almuerzo, debes tener una marca, un equipo y una comunidad que hayan pasado los últimos años preparándose para una pelea de David contra Goliat”, en mi experiencia, para los responsables de compras cosas como la marca, la comunidad, el equipo y la experiencia de los desarrolladores significan casi nada frente al cumplimiento normativo
  Especialmente si te enfrentas de lleno a un proveedor establecido como Google.

  • Buen punto. Creo que debería agregarlo al artículo.
    En el caso de Supabase, de hecho, durante los últimos años se han estado preparando para cumplir requisitos como SOC2, HIPAA y GDPR, así que la observación es acertada.

• Nuestro producto también ha estado dándole vueltas a este problema. Algún día vamos a convertirlo todo en open source bajo MIT o Apache, la licencia que nos guste más en ese momento, y eso ya lo tenemos publicado en el sitio. No será algo tipo AGPL ni open core.
  Pero sentí que ganar dinero con un producto bajo esa estructura es totalmente imposible, y así fue también en mi experiencia previa. La consultoría es posible, pero un producto es distinto. Supabase recibió una enorme inversión de venture capital, y lo mismo ocurre con casi todos los proyectos open source “grandes”.
  Si estás haciendo bootstrap, especialmente en un proyecto ambicioso y difícil, no puedes pagar las cuentas durante un buen tiempo. Las personas tienen un límite de tiempo durante el cual pueden trabajar gratis, y si un equipo pequeño se comunica de forma estrecha y continua sobre código privado, puede moverse mucho más rápido al reducir el overhead necesario para un proyecto open source exitoso.
  Me gustaría escuchar ejemplos de proyectos de tamaño similar, con 0 dólares de inversión, iniciados en los últimos 5 años, con al menos 2 integrantes de tiempo completo, que hayan durado más de 3 años y que todavía recomienden este enfoque. Me da curiosidad cómo se ganan la vida. Creo que algo como Redis ya no ocurre. Al menos yo no lo he visto. Incluso un proyecto simple como langchain recibió decenas de millones de dólares de venture capital, cuando yo pensaba que justamente ese tipo de proyecto era candidato para que un equipo de pocas personas lo intentara monetizar con varias fuentes de ingresos.

  • Puedes publicar todo el código bajo una licencia de software libre y aun así no apuntar a ser un “proyecto open source exitoso” ni asumir el overhead que eso implica.
    Todo mi software lo publico en dominio público, es decir, como software libre, pero nada de eso se ha convertido en un proyecto open source ni en una comunidad exitosa. El software libre es, ante todo, una ideología, y luego una práctica o una funcionalidad.
  • Sourcehut es AGPL y quizá no se use tanto como Redis, pero ha empleado a más de 2 personas, según su último reporte de 2022 tuvo ganancias y ha durado más de 3 años.

• Creo que convertir una empresa en open source no tiene sentido a menos que esté dirigida a desarrolladores o que estés creando un producto que, en la práctica, nadie vaya a hostear por su cuenta.
  Supabase es un caso representativo de ambas cosas. Como ejemplo de lo segundo está Plausible Analytics, que sí se puede hostear por cuenta propia. Yo lo hago así con Coolify.io. Pero si no creas tu propio sistema de CI/CD para traer y fusionar las actualizaciones de los releases, te vas a perder las actualizaciones.