La respuesta corta
Open source no destruye el moat cuando el artefacto público termina un trabajo limitado y el valor comercial vive en continuidad, contexto acumulado, criterio operativo e implementación. El error es elegir entre dos extremos malos: no publicar nada útil o publicar el sistema completo sin una frontera. Una capa abierta seria puede crear confianza sin exponer infraestructura privada ni lógica propietaria de decisión.
Una herramienta gratuita inútil no crea confianza
Una demo mutilada solo demuestra miedo. La capa abierta debe terminar un trabajo importante. Si alguien la instala, sigue las instrucciones y no obtiene una salida útil, tampoco tiene razones para creer que el producto profundo sea mejor. “Gratis” no es la propuesta de valor. Completar el trabajo sí. El artefacto necesita una promesa estrecha, una entrada real, una salida usable y un límite de falla honesto.
El moat no es el botón que falta
En QC 4.1 Light, el trabajo público es diagnosticar seriamente el transcript de una llamada. Devuelve una revisión basada en evidencia con mapa de etapas, fortalezas, breakpoint, objeciones, correcciones, recovery line y replay plan. La profundidad comercial no es un botón secreto eliminado de la versión gratuita. Es continuidad: comparación de equipo, historial, coaching adaptativo, dashboards operativos y el sistema propietario detrás de QC 4.1. Esa capa mejora cuando acumula contexto.
Una prueba práctica de frontera
Antes de publicar un artefacto, separo cuatro capas. La primera es el trabajo que el usuario puede completar de forma segura en público. La segunda es la interfaz o las instrucciones necesarias para ejecutarlo. La tercera es infraestructura privada: credenciales, rutas internas, datos de clientes y detalles de deployment. La cuarta es criterio comercial: reglas acumuladas, historial e intervenciones que hacen que el sistema mejore con el tiempo. Publica las dos primeras cuando sean realmente útiles. Protege las últimas dos, salvo que exista una razón específica para abrirlas.
Evidencia antes que aproximación
La regla pública más importante de QC 4.1 Light no es una lista de pesos secretos. Es un contrato más duro: el diagnóstico debe volver al transcript. Si la llamada no sostiene un claim, el reporte no puede presentarlo como hecho. Eso vuelve útil la capa gratuita sin publicar la lógica propietaria del veredicto. Cualquiera puede pedirle a un modelo una opinión sobre una llamada. El valor empieza cuando el output distingue una cita de una inferencia.
Publicar el límite junto a la capacidad
Open source se vuelve peligroso cuando el autor no puede explicar qué permanece privado, pero también se vuelve engañoso cuando esconde sus límites. Cada artefacto público debe declarar qué hace, qué no hace y qué capa pertenece al producto comercial. QC 4.1 Light revisa un transcript. No promete benchmarking de equipo, detección histórica de patrones, coaching adaptativo ni la metodología completa de QC 4.1. La frontera es parte del diseño del producto, no copy defensivo.
Distribuir después de ser útil
Un repositorio no es una estrategia de crecimiento por sí solo. El loop es artefacto útil, explicación clara, ruta de instalación, nota operativa, distribución y activación medida. Las estrellas pueden indicar atención. No demuestran que la herramienta completó el trabajo ni que creó intención comercial. Las señales duras vienen después: ejecuciones correctas, uso repetido, preguntas específicas, conversaciones cualificadas e implementación pagada. Hasta que existan, el resultado honesto es atención, no demanda.
El contrato de release
Un release público está listo solo cuando una persona desconocida puede entender el trabajo, instalar o cargar el artefacto, ejecutar un ejemplo completo y ver los límites conocidos sin pedirle al autor que traduzca el repositorio. Eso exige README claro, licencia explícita, ejemplos versionados, entradas y salidas esperadas, y una declaración sobre los datos que nunca deben compartirse. Si faltan esas piezas, publicar el código no es apertura. Es transferirle la deuda de documentación al usuario.
Lo que sí protegería
Protegería infraestructura privada, credenciales, contexto de clientes, lógica propietaria de evaluación y el sistema de coaching acumulado. No protegería un prompt genérico para llamarlo moat. El artefacto público debe ser lo bastante útil como para que un operador serio pueda discutirlo, probarlo y entender su límite. Luego la capa comercial debe ganarse el precio con profundidad y continuidad. Esconder trabajo débil no crea defensibilidad. Solo retrasa la inspección.