Por qué elegí ELv2 — y qué significa para Invariant

Hace un par de meses no me habría imaginado construyendo un framework en TypeScript.

La idea ni siquiera se me había pasado por la cabeza.

Soy un ingeniero de software autodidacta. Siempre me he considerado más un generalista que un experto en un campo específico. Lo que siempre se me ha dado bien —y lo que más disfruto— es mirar un problema, entender cómo interactúan las piezas y averiguar cómo hacer que todo el sistema funcione.

Pienso naturalmente en sistemas.

Cuando los agentes de IA comenzaron a ser posibles, me obsesioné con ellos.

Incluso antes de que existiera MCP y antes de que el ecosistema actual de frameworks de agentes tomara forma, ya estaba construyendo demos de agentes simplemente porque me parecían fascinantes. No estaba intentando crear una "empresa de infraestructura de IA". Estaba jugando con un nuevo tipo de software e intentando entender qué se podía construir con él.

Pero casi de inmediato empecé a toparme con problemas.

Y curiosamente, esos problemas fueron la parte que más me entusiasmó.

Los modelos podían razonar sorprendentemente bien, pero darles más responsabilidad también significaba dar a sistemas probabilísticos el control sobre cosas que el software tradicionalmente espera que sean deterministas.

Estado. Ejecución. Recuperación ante caídas. Efectos secundarios. Procesos de larga duración. Sistemas externos.

Cuantos más agentes construía, más empezaba a pensar que quizás uno de los problemas importantes de la próxima década no sería simplemente construir modelos más inteligentes.

Sería construir software para modelos.

Porque sin importar cuán inteligentes se vuelvan los modelos, siguen siendo probabilísticos.

Y cuando miras más allá del modelo, casi todo lo que un agente realmente hace eventualmente se convierte en un flujo de trabajo.

Esa idea se quedó grabada en mí.

---

Siguiendo el problema

No me senté un día a diseñar Invariant desde primeros principios.

Surgió gradualmente.

Seguí construyendo sistemas de IA a mi manera. Discutí los problemas con otros ingenieros. Leí papers. Estudié cómo otros frameworks abordaban los agentes. Construí cosas, las rompí, las reconstruí y seguí preguntándome dónde debía terminar la responsabilidad del modelo y dónde debía comenzar la responsabilidad de la infraestructura.

Poco a poco, la tesis se volvió más clara:

Los modelos deben razonar. La infraestructura debe ejecutar.

El modelo puede decidir qué debería suceder.

Pero la infraestructura debe ser dueña de la ejecución, el estado, la recuperación, la observabilidad y las garantías que rodean esa decisión.

Una vez que comencé a separar esas responsabilidades, muchos de los problemas con los que había estado lidiando se volvieron mucho más fáciles de razonar.

Al menos para mí, funcionó.

Y eso eventualmente se convirtió en Invariant.

El framework en sí se armó sorprendentemente rápido. Pero no creo que las ideas detrás de él hayan surgido en unas pocas semanas.

Se sienten como la acumulación de años construyendo software, depurando sistemas, cometiendo errores arquitectónicos, aprendiendo cómo fallan las abstracciones y desarrollando mis propios criterios para resolver problemas.

La IA también cambió algo más para mí.

Como ingeniero generalista, a menudo he tenido ideas que eran más grandes de lo que podía implementar realistamente por mi cuenta. La IA acortó drásticamente la distancia entre entender una abstracción, diseñar una arquitectura, modelarla y traducirla en código funcional.

De repente, construir algo como Invariant yo solo no se sentía imposible.

Y luego me encontré con un problema completamente diferente.

Si quiero que otras personas usen esto, ¿qué tan abierto debería ser?

---

Quiero que Invariant sea abierto

He pensado mucho en esto.

Quiero que puedas leer el código fuente de Invariant.

Quiero que lo ejecutes en tu propia infraestructura.

Quiero que lo modifiques.

Quiero que aprendas de él.

Quiero que las empresas construyan productos con él.

Quiero que alguien descubra Invariant, reconozca uno de los mismos problemas que me volvían loco al construir agentes y piense:

"Esto me hace la vida más fácil."

Honestamente, construir una comunidad de ingenieros que encuentren útil Invariant sería probablemente uno de los resultados más satisfactorios de todo este experimento.

Y si algún día Invariant crea suficiente valor para desarrolladores y empresas como para que el proyecto mismo se convierta en una empresa sostenible, sería un sueño hecho realidad.

Pero hay una realidad importante detrás de todo esto.

Hoy sigo construyendo Invariant mientras trabajo en mi empleo de tiempo completo.

No hay una gran organización de ingeniería detrás.

No hay un gran fondo de capital de riesgo financiando el desarrollo.

No hay un negocio establecido protegiendo el proyecto.

Hay principalmente una idea en la que creo, mucho trabajo de ingeniería y yo intentando ver hasta dónde puedo llevarlo.

Esa es parte de la razón por la que elegí la licencia Elastic License 2.0 (ELv2) para Invariant.

---

¿Por qué ELv2?

El software de infraestructura tiene una tensión extraña.

Cuanto más útil lo haces, más fácil puede ser para otra empresa —potencialmente una con mucho más capital, ingenieros, infraestructura y distribución— tomar ese trabajo, empaquetarlo como un servicio administrado (cloud) y competir directamente contra quienes lo construyen.

Para una empresa grande, eso puede ser un problema estratégico.

Para una pequeña, puede ser existencial.

No creo que poner Invariant a disposición de todos deba requerir darle a otra empresa el derecho irrestricto de tomar el framework, ponerle una API en la nube enfrente, llamarlo de otra forma y convertir el framework en su propio producto comercial.

ELv2 me da un equilibrio con el que me siento cómodo.

Me permite decir:

• Construye con Invariant.
• Construye sobre Invariant.
• Construye un negocio utilizando Invariant.

Solo no tomes Invariant en sí para convertirlo en un servicio gestionado competidor.

Esa es la frontera.

---

¿Qué significa esto para ti?

Para la abrumadora mayoría de desarrolladores interesados en Invariant, no quiero que la licencia sea un obstáculo.

• Puedes inspeccionar el código fuente.
• Puedes ejecutarlo tú mismo.
• Puedes modificarlo.
• Puedes usarlo dentro de tu empresa.
• Puedes construir aplicaciones comerciales con él.
• Puedes desplegar esas aplicaciones en tu propia infraestructura.
• No necesitas una cuenta de Invariant Cloud para construir software con Invariant.

Y quiero preservar esa filosofía.

Si Invariant eventualmente ofrece una plataforma cloud gestionada, no quiero que tenga éxito porque hicimos que el auto-hospedaje (self-hosting) fuera intencionalmente doloroso o porque tu aplicación quede atrapada tras APIs propietarias.

Prefiero ganarme tu negocio.

Si eventualmente cobramos por ejecución gestionada, capacidades empresariales, observabilidad avanzada, colaboración, soporte o infraestructura que facilite ejecutar Invariant a escala, esos productos deberían valer la pena por sí mismos.

El framework debería seguir siendo útil sin ellos.

---

¿Es eso realmente Open Source?

Técnicamente, no.

Y no quiero jugar con esa definición.

ELv2 es una licencia source-available (código disponible), no una licencia de código abierto aprobada por la OSI.

Esa distinción importa.

Podría llamar a Invariant "código abierto" porque el código está disponible y la mayoría de los desarrolladores pueden hacer casi todo lo que normalmente querrían hacer con él.

Pero la comunidad de código abierto ha pasado décadas definiendo qué significa ese término. No creo que me corresponda cambiar discretamente la definición solo porque otra etiqueta sería más conveniente para marketing.

Así que lo llamaré por lo que es.

Invariant es código disponible (source-available) bajo ELv2.

Pero la apertura sigue siendo extremadamente importante para mí.

Especialmente para este tipo de infraestructura.

Si confías en Invariant para la ejecución de agentes de IA, creo que deberías poder entender lo que está haciendo.

Deberías poder inspeccionar cómo se ejecuta un flujo de trabajo. Deberías poder entender cómo se persiste el estado. Deberías poder ver qué sucede después de una falla. Deberías poder depurar el runtime.

La infraestructura diseñada para hacer que los sistemas probabilísticos sean más confiables no debería, en sí misma, exigir confianza ciega.

---

¿Por qué no MIT o Apache 2.0?

Consideré licencias permisivas.

Y entiendo por qué los desarrolladores las prefieren.

Son simples. Son familiares. Y otorgan a los usuarios una enorme libertad.

Quizás el modelo de licenciamiento de Invariant evolucione algún día.

Pero tengo que tomar decisiones basadas en el proyecto que existe hoy, no en la empresa que espero que pueda existir dentro de cinco años.

Y hoy, Invariant se está construyendo sin los recursos de una gran empresa detrás.

MIT o Apache otorgarían a todos la máxima libertad, pero esa libertad también se extendería a una organización bien financiada que tome Invariant y comercialice el framework en sí como un servicio gestionado.

No me siento cómodo asumiendo ese riesgo en este momento.

Más importante aún, prefiero establecer esa frontera ahora.

Antes de que haya cientos de colaboradores. Antes de que haya negocios que dependan de Invariant. Antes de que haya una gran comunidad cuyas expectativas puedan verse afectadas por un cambio de licencia posterior.

Prefiero decirte exactamente cuál es el trato desde el primer día que empezar con una licencia permisiva, generar adopción y cambiar las reglas después (pull the rug).

---

Lo que espero que Invariant llegue a ser

No sé exactamente cómo se verá Invariant dentro de varios años.

Eso es parte de lo que hace que esto sea emocionante.

Quizás siga siendo relativamente pequeño. Quizás otros ingenieros encuentren útiles las mismas ideas. Quizás se forme una comunidad a su alrededor. Quizás las empresas comiencen a construir sistemas serios con él. Quizás eventualmente se convierta en la empresa de infraestructura que hoy solo puedo imaginar.

Pase lo que pase, quiero preservar algunos principios:

1. Los desarrolladores deben poder entender la infraestructura de la que dependen.
2. Deberías poder construir productos comerciales reales con Invariant.
3. El auto-hospedaje (self-hosting) debe ser una opción real.
4. Las reglas deben ser claras antes de que las personas contribuyan con su trabajo.
5. Y si Invariant crea valor real, debe haber una empresa sostenible capaz de seguir invirtiendo en él.

ELv2 no es una respuesta perfecta al debate mucho más amplio sobre el código abierto y el software comercial.

Es simplemente el balance que se siente correcto para Invariant hoy.

Quizás mire hacia atrás a este post dentro de unos años y piense diferente.

Está bien.

Invariant en sí comenzó porque no dejaba de cuestionar cómo estábamos construyendo sistemas de IA.

No veo por qué debería dejar de cuestionar las decisiones en torno a la empresa tampoco.

Por ahora, quiero poner el trabajo allá afuera y ver qué construye la gente con él.

— José Vásquez