Código abierto vs IA: la decisión que sorprendió 2026

Cal.com, la plataforma de scheduling más grande de código abierto fundada en 2022, anunció el 15 de abril de 2026 que cierra su proyecto y se migra a licencia propietaria. El motivo: modelos de IA como Mythos pueden escanear automáticamente código abierto para encontrar vulnerabilidades que los humanos tardarían años en detectar. Bailey Pumfleet, CEO fundador, confirmó que la empresa preferiría mantener open source, pero los riesgos de seguridad en la era de IA ya no lo hacen viable. Una decisión que marca un punto de quiebre en la historia del software libre.

El anuncio que sacudió el ecosistema: Cal.com dice adiós al código abierto

Ponele que estabas usando Cal.com para gestionar tus calendarios y reuniones. Confiabas en que siendo open source, cualquiera podía auditar el código, reportar bugs, y la comunidad lo mantenía seguro. El 15 de abril, Bailey Pumfleet metió una bomba: Cal.com se cierra. Licencia AGPL → licencia propietaria.

¿Qué pasó? Que durante 5 años, Cal.com fue el hogar de la comunidad open source de scheduling. Funciones colaborativas, sync de calendarios, webhooks, todo disponible públicamente. Ahora, la empresa que fundó Pumfleet en 2022 reconoce que mantener código sensible en repositorios públicos es como “handing out the blueprint to a bank vault”, según la analogía de ZDNET.

¿La razón? No es algún hack específico (aunque sí hubo reportes de herramientas como OpenClaw ejecutando comandos directamente en calendarios). El problema es mucho más macro: modelos de IA entrenados para encontrar vulnerabilidades pueden scour (rastrear) repositorios públicos de forma automática, a escala, y descubrir brechas de seguridad en minutos que le tomarían meses a un equipo humano. Eso sí, la ironía: Cal.com habría preferido seguir siendo open source. La presión de la seguridad en la era de IA fue más fuerte.

Mythos y el escaneo automático de vulnerabilidades: el arma silenciosa de la IA

Para entender por qué Cal.com se asustó, necesitás entender qué es Mythos. Mythos es un modelo de Anthropic diseñado para hacer precisamente eso: escanear código, identificar patrones vulnerables, y reportar (o explotar) fallos. No necesita que un humano le diga “mirá esta función”, simplemente trabaja en automático.

El caso clásico que usan para ilustrar el peligro: OpenBSD, el sistema operativo open source que goza de reputación ultra paranoia sobre seguridad, descubrió hace poco un integer overflow crítico en el protocolo TCP SACK que había estado ahí 27 años sin que nadie lo viera. Cuando lo encontraron, fue porque alguien aplicó una herramienta de análisis estático. Imaginate si en lugar de 27 años de humanos auditando el código, había una IA observando desde el principio. ¿Cuánto tiempo le habría tomado encontrarlo? Probablemente días, no décadas.

Huzaifa Ahmad de Hex Security cuantificó el diferencial: explotar una vulnerabilidad en código open source es de 5 a 10 veces más fácil que en código cerrado, porque tenés la arquitectura, las dependencias y hasta los errores de lógica directamente en GitHub. Una IA que sabe qué buscar puede automatizar esa búsqueda completa en minutos, escanear miles de repos en paralelo, y reportar cada descubrimiento. Eso es lo que asusta. En ejecutar agentes sin depender de terceros profundizamos sobre esto.

Los números de 2026: la brecha de seguridad se disparó

Si creés que esto es hype, mirá los datos. El reporte OSSRA 2026 mostró un aumento de 107% en vulnerabilidades detectadas por base de código comparado con 2025. Pero acá viene lo interesante: ese número incluye tanto vulnerabilidades reales como falsos positivos masivos de scanners IA que reportan cualquier cosa que se parezca a un problema (más sobre eso después).

Lo concreto:

• 86% de aplicaciones auditadas en 2026 contienen vulnerabilidades de open source conocidas
• 90% de esas aplicaciones incluyen componentes sin actualizar hace 4+ años
• 45% de las vulnerabilidades encontradas caen en la categoría OWASP Top 10
• Código generado por IA: 20% de errores son de configuración crítica (credenciales, permisos, certificados expuestos)

El tema es que la mayoría de los equipos no updatea sus dependencias porque “funciona”. Funciona hasta que funciona mal. Y una IA tarda segundos en encontrar exactamente dónde va a funcionar mal.

Agentes de IA ejecutando código: la nueva superficie de ataque

Ojo: el problema no es solo que IA encuentre vulnerabilidades. El problema es que hay agentes de IA ya operacionales en producción que pueden ejecutar comandos en tu filesystem, acceder a tu calendario, enviar emails, y correr comandos en shell. OpenClaw es el ejemplo concreto: un agente open source que integra funciones de email, filesystem, y ejecución de comandos. Re piola para experimentación local. Pesadilla si está desplegado en internet sin validación de inputs.

¿Qué pasa cuando una IA maliciosa (o un modelo comprometido) usa OpenClaw para iterar sobre tu base de código buscando credenciales hardcodeadas, keys de API expuestas, o consultas SQL inyectables? No tarda 5 minutos. Y si eso está en un repo público, el atacante ni siquiera necesita acceso a tu infraestructura. Viene, copia, modifica, deploya.

Fortune 500 ya tiene 80% de adoption de agentes IA activos en 2026. La mayoría aún está experimentando localmente. Pero conforme esos agentes se desplieguen más ampliamente, el riesgo escala exponencialmente.

Project Glasswing: Anthropic contraataca para defender open source

Antes de que te desesperes pensando que open source está muerto, Anthropic metió mano. Project Glasswing es una iniciativa de $100 millones para descubrir, auditar y parchear vulnerabilidades críticas en proyectos open source populares. La idea es usar IA para encontrar el problema, y luego el equipo de Anthropic trabaja con los maintainers para arreglarlo antes de que se publique públicamente. Más contexto en evaluar riesgos de privacidad en plataformas.

No es perfecto (tenés que confiar en Anthropic, tenés que confiar en que lo hacen bien), pero es un esfuerzo genuino de contrabalance. Si Cal.com eligió cerrar, otros proyectos pueden elegir mantener open source pero recibir auditorías profesionales. Es una bifurcación de estrategias: riesgo compartido vs. riesgo contenido.

El problema de los falsos positivos: 5000+ reportes por un bug real

Acá viene el lado perverso. Curl, el cliente HTTP que todas las máquinas del mundo usan (en serio, está en todos lados), tuvo que cerrar su bug bounty en 2026 porque recibía 5000+ reportes de supuestas vulnerabilidades diarias. Casi todos falsos positivos de scanners IA que no entienden contexto.

El maintainer de curl, Daniel Stenberg, reportó que de esos 5000 reportes, quizá 5 tenían mérito. El resto era ruido puro: herramientas IA aplicando patrones genéricos sin entender lógica de negocio, sin verificar si realmente hay explotabilidad, sin saber que ese “buffer overflow” que encontró en realidad es imposible porque hay validación previa.

El resultado: los desarrolladores open source que ya están quemados ahora tienen aún menos incentivo para mantener proyectos públicos. Si además le suman que una IA real puede encontrar vulnerabilidades que sí importan, y los atacantes pueden explotarlas a escala (porque el código está público), muchos van a tomar la decisión de Cal.com: cerrar.

Cal.diy: open source para hobbyistas, closed source para empresas

Cal.com no eliminó completamente open source. Lanzó Cal.diy como una versión fully open source del producto, pensada para desarrolladores y pequeños equipos que quieren experimentar, forkear y customizar. Pero el producto principal, el que usan en producción miles de empresas, ahora es propietario. Complementá con infraestructura local para modelos de IA.

Es una bifurcación inteligente. Reconocés que open source tiene valor (innovación, comunidad, confianza), pero separás el risk según el use case. Si sos un dev independiente experimentando en localhost, usás Cal.diy. Si sos una empresa con datos de clientes, usás Cal.com con SLA, auditorías regulares, y código que no está en GitHub público.

La pregunta que quedó abierta: ¿van otros a seguir el mismo patrón? Probablemente sí.

Errores comunes al responder a esto

Error 1: “Esto es solo marketing de Anthropic”

Sí, Anthropic tiene incentivo en asustarte sobre vulnerabilidades. Pero los datos de OSSRA son independientes, y el problema de OpenBSD (27 años sin detectar un fallo) es un caso de estudio real. La amenaza existe, más allá de si Anthropic la inflama o no.

Error 2: “Simplemente updateemos todas las dependencias”

Lindo en teoría. En la práctica, updatear dependencias rompe cosas: cambios de API, incompatibilidades, breaking changes que exigen refactoring. Muchas empresas no lo hacen porque el costo de arreglar todo lo que se rompe es más alto que el riesgo percibido. Una IA que explota la vuln vieja pone eso en perspectiva muy rápido.

Error 3: “Podemos auditar open source internamente”

Si una IA entrenada en seguridad tarda 5 minutos en escanear un repo entero, vos no vas a hacerlo en una afternoon. La ventaja que tenía open source (muchos ojos) se disuelve cuando una IA escanea más rápido que todos esos ojos juntos. Para más detalles técnicos, mirá opciones alternativas para alojar código.

Preguntas Frecuentes

¿Por qué Cal.com abandonó el código abierto exactamente?

Porque modelos de IA como Mythos pueden escanear automáticamente código público para encontrar vulnerabilidades mucho más rápido de lo que un equipo humano puede identificarlas y parchearlas. Bailey Pumfleet, el CEO, explicó que es como “entregar el plano de una bóveda de banco” a quien quiera. Prefieren mantener Cal.diy como proyecto open source para desarrolladores, pero el producto de producción ahora es cerrado.

¿Qué es Mythos y qué amenaza representa?

Mythos es un modelo de Anthropic especializado en encontrar vulnerabilidades de seguridad en código. Puede analizar repositorios públicos en minutos y reportar (o explotar) fallos que los humanos tardarían meses o años en detectar. La amenaza es que automatiza completamente la búsqueda de brechas en open source a escala.

¿Es más seguro el código propietario que el abierto?

Según Hex Security, explotar vulnerabilidades en código abierto es 5-10 veces más fácil que en código cerrado, porque tenés acceso a la arquitectura y a los detalles de la implementación. Pero eso no significa que el código cerrado sea automáticamente seguro, solo que la barrera de entrada es mayor. Open source aún tiene ventajas (auditoría comunitaria), pero la IA cambió el juego.

¿Deberían cerrar mi proyecto open source por seguridad?

Depende de qué haga tu proyecto. Si es código experimental, una herramienta de desarrollo, o un hobby, mantenerlo abierto sigue siendo valioso. Si toca credenciales, maneja datos sensibles, o es infraestructura crítica, el riesgo cambió. La tendencia que ves con Cal.com va a acelerarse: proyectos se bifurcan en versión open (hobbyista) y versión propietaria (producción).

¿Qué es Project Glasswing?

Project Glasswing es una iniciativa de Anthropic con $100 millones para auditar vulnerabilidades críticas en proyectos open source populares. Usan IA para identificar problemas y trabajan con los maintainers para parchearlos antes de hacerlos públicos. Es una respuesta de la industria al problema que creó la IA.

Conclusión

Cal.com no fue la primera empresa en cerrar un proyecto open source, pero sí fue la primera en hacerlo explícitamente por razones de seguridad relacionadas con IA. Es un marcador de límite: el modelo de “muchos ojos ven todo” que funcionó durante 30 años de open source ya no funciona cuando esos “muchos ojos” incluyen máquinas que ven en microsegundos.

Eso no significa que open source esté muerto. Significa que se bifurca: open source sigue siendo valiosa para experimentación, innovación, y comunidad. Pero para producción sensible, las empresas van a elegir código propietario auditado, control de acceso, y seguridad de “caja negra”.

Si mantenés un proyecto open source, la pregunta que tenés que hacerte no es “¿debería cerrar?” sino “¿qué datos sensibles expongo al público?” Si la respuesta es “ninguno”, seguí adelante. Si expones arquitectura de sistemas, patterns de validación, o dependencias viejas con vulnerabilidades conocidas, empieza a pensar en una bifurcación tipo Cal.com: versión abierta para desarrolladores, versión segura para producción.

Antropic respondió bien con Project Glasswing. Pero el real fix es cultural: los desarrolladores open source necesitan reconocer que la IA cambió el juego, y ajustar sus prácticas (auditorías regulares, dependencias actualizadas, secretos fuera del código) en consecuencia. Cerrar no es la solución. Ser paranoia es.

Fuentes

• ZDNET – ‘Like handing out the blueprint to a bank vault’: Why AI led one company to abandon open source
• Cal.com Blog – Why Cal.com is moving to a closed-source model
• PR Newswire – OSSRA 2026: Open Source Vulnerabilities Report
• The New Stack – How AI threats forced Cal.com to abandon open source
• Kaspersky – Vulnerabilidades en código abierto en la era de la IA