Open core

Open core, código abierto y freemium son tres líneas distintas

Estos términos se usan como sinónimos y cortan por ejes diferentes. Conviene ser preciso, porque la diferencia decide qué te pasa si el proveedor cambia de idea.

• Código abierto es un hecho de licencia sobre el código: la licencia te concede el derecho a ejecutarlo, estudiarlo, modificarlo y redistribuirlo. No dice nada sobre quién paga qué.
• Open core es una decisión de empaquetado encima de eso: una parte del producto lleva licencia abierta y otra parte sencillamente no existe en público. La mitad propietaria suele ser el servicio alojado, el inicio de sesión único, los registros de auditoría, los permisos y lo que pidan los clientes más grandes.
• [Freemium](/glossary/freemium) es una decisión de precio dentro de un único producto propietario: un plan gratuito y planes de pago del mismo software cerrado. Nada es abierto y autoalojar no está sobre la mesa.
• [Precio por uso](/glossary/usage-based-pricing) es ortogonal a los tres — describe cómo se calcula la factura, no qué se te permite hacer con el código.

Una prueba útil: con freemium, llegar al techo significa que actualizas de plan. Con open core, llegar al techo significa que actualizas o construyes tú mismo la pieza que falta, porque tienes el resto del sistema en las manos. Esa segunda opción es todo el valor del modelo para quien lo adopta, y es real más a menudo de lo que se supone.

Leer un repositorio para ver dónde cae la línea de verdad

Escribimos con regularidad sobre herramientas de crecimiento de código abierto en nuestras páginas /grow, y después de más de sesenta el patrón es lo bastante constante como para ser una lista de comprobación. Lo que dice la insignia y dónde está el muro de pago son hechos separados, y el segundo es el que decide si la herramienta resuelve tu problema. Busca esto antes de adoptar nada:

• Abre el archivo LICENSE, no la insignia. El propio campo de licencia de GitHub muestra `NOASSERTION` cuando no puede clasificar lo que encontró, y algunos repositorios con insignia de licencia no tienen texto de licencia alguno. Por sí solo no es una prueba concluyente, pero es el único campo donde no puedes permitirte suponer.
• Busca la nota al pie que dice solo en la nube. La forma más común es una lista de funciones en el README donde una o dos entradas llevan una nota discreta de que están disponibles en el plan alojado. Si esa entrada es la razón por la que ibas a adoptar la herramienta, ya has leído la historia entera.
• Lee la tabla comparativa que el propio proyecto publica. Es marketing, así que trata con desconfianza las columnas de la competencia, pero la columna que describe su propio producto suele ser precisa y te dice qué creen sus mantenedores que están vendiendo.
• Mira qué plugins o módulos están marcados como núcleo. Un proyecto que marca unas capacidades como núcleo y otras como opcionales ya ha trazado su línea en público, y eso es mucho más fiable que una página de precios.
• Comprueba quién ostenta el copyright y si hay acuerdo de contribución. Una sola empresa con el copyright puede relicenciar más adelante; una fundación o una base amplia de contribuyentes lo hace bastante más difícil. Este es el campo que predice qué pasará dentro de tres años.

docmd, un compilador de documentación que analizamos el 3 de septiembre de 2026, es un ejemplo pequeño y limpio de la forma hecha de manera legible: el compilador y todas sus salidas de compilación son MIT en el repositorio, y la única pieza alojada — un relay que permite a un sitio puramente estático ejecutar el asistente de IA sin operar un backend — está marcada con claridad como el servicio opcional. En un minuto sabes qué autoalojarías y qué comprarías, cosa que no es cierta en todos los proyectos de la categoría.

Qué significa si lo adoptas, y si lo construyes

Como quien adopta, la pregunta honesta no es si la herramienta es abierta, sino cuánto te cuesta salir. Autoalojar es gratis en términos de licencia y no es gratis en horas: alguien se encarga de las actualizaciones, las copias de seguridad y la caída. Compara eso con el plan alojado al tamaño que esperas tener dentro de un año, no al que tienes ahora. Aun así, lo que compras con esas horas es real: tus datos siguen en una base de datos que controlas y, si la hoja de ruta del proveedor se aleja de ti, te queda un sistema en marcha en lugar de una migración.

Como fundador que se plantea el modelo para su propio producto, hay que tener claro que open core es una estrategia de distribución antes que de ingresos. Compra alcance, credibilidad ante desarrolladores y un flujo de personas que contribuyen; no produce clientes por sí mismo y te limita después, porque mover una función del lado abierto al lado de pago es una de las pocas decisiones que le cuesta a un proyecto su buena voluntad de forma fiable. Decide la línea antes de que el repositorio sea público y escríbela donde los usuarios puedan leerla.

Tampoco elimina nada del trabajo de hacerse encontrar. Un repositorio abierto es un canal de distribución con el mismo problema que todos los demás: alguien tiene que enterarse. Por eso los proyectos que ganan con este modelo suelen ser los que hacen el trabajo corriente de contenido y comunidad junto a la ingeniería, no los que dieron por hecho que la licencia haría el marketing.