Cal.com e IA: o novo modelo de software aberto entre segurança, monetização e código público

Quando uma empresa que nasceu com a bandeira da abertura decide fechar o coração do próprio produto, o movimento costuma dizer muito mais sobre o momento do mercado do que sobre um único repositório. Foi exatamente isso que a Cal.com sinalizou ao mover seu core de produção para um ambiente fechado e reposicionar sua oferta pública em torno do Cal.diy, uma versão open source mais enxuta, sob licença MIT, com partes comerciais e componentes sensíveis removidos.

A justificativa oficial é direta: com o avanço de ferramentas de IA capazes de acelerar a descoberta de vulnerabilidades em software público, manter todo o código crítico exposto passou a representar um risco operacional maior. Em outras palavras, o que antes era tratado como transparência e colaboração agora começa a ser lido também como superfície de ataque.

O caso é especialmente relevante porque a Cal.com se consolidou como uma alternativa aberta ao Calendly, apoiada justamente pela promessa de código acessível, comunidade e controle por parte do usuário. Agora, a empresa adota um modelo híbrido: preserva uma versão pública, mas separa formalmente o que é comunidade do que é produção. Isso não significa o fim do open source, mas indica uma redefinição do que, dentro de um produto comercial, pode ou não continuar visível.

O que mudou na prática

Na estrutura anterior, havia um grau maior de espelhamento entre o que estava público e o que rodava em produção. Com a nova abordagem, esse espelhamento diminui: as partes críticas passam a ser reescritas fora do repositório aberto, reduzindo a possibilidade de comparação direta entre a base pública e o sistema real.

Segundo a própria lógica anunciada pela empresa, os pontos mais sensíveis são áreas como autenticação e tratamento de dados. São exatamente os trechos que, em qualquer software SaaS, concentram parte importante do risco. Ao isolá-los, a Cal.com tenta limitar o impacto de uma leitura automatizada e massiva do código por ferramentas de IA e por atacantes que usam esse tipo de automação para encontrar falhas mais rápido.

Ao mesmo tempo, o Cal.diy mantém o núcleo de agendamento, mas remove camadas enterprise, integrações avançadas e componentes que fazem sentido no produto comercial. Na prática, a empresa passa a oferecer duas experiências distintas: uma base pública mais simples e um ambiente privado ou on-premise para clientes self-hosted que precisam do pacote completo.

Por que a decisão importa agora

O ponto mais interessante do caso não é apenas a mudança técnica, mas a mudança de mentalidade. Por anos, o debate sobre open source comercial girou em torno de monetização, sustentabilidade e governança. Agora, entra uma nova variável: custo de ataque.

Se ferramentas de IA tornam mais barato vasculhar código público, identificar padrões e localizar fragilidades, a exposição deixa de ser só uma escolha filosófica e passa a ser uma decisão de risco. Isso muda a equação para startups que nascem abertas, crescem com distribuição pública e depois precisam proteger partes cada vez mais críticas do seu produto.

É por isso que o caso da Cal.com pode virar referência. Ele sugere que empresas open source comerciais podem começar a tratar o repositório público como uma vitrine limitada, não como espelho integral da produção. E, se essa lógica se espalhar, a tendência pode normalizar uma divisão entre:

• um núcleo público, simplificado e auditável;
• e um core privado, onde ficam autenticação, lógica sensível e diferenciais de negócio.

Segurança, marca e ambiguidade estratégica

A narrativa oficial se apoia em segurança. Mas, como em quase toda mudança desse tipo, há uma camada de estratégia comercial difícil de separar completamente da justificativa técnica. Reduzir a exposição também reduz a possibilidade de cópia, engenharia reversa e comparação detalhada por concorrentes.

Isso não invalida o argumento de segurança. Apenas mostra que os incentivos convergem. Quando um produto depende de confiança, dados e automação, proteger o core pode ser simultaneamente uma decisão prudente e uma proteção competitiva.

Por outro lado, há um custo. Empresas que construíram sua reputação em cima da abertura total podem enfrentar ruído de percepção. Parte da comunidade pode ler a mudança como um afastamento da proposta original. Ainda assim, a aposta da Cal.com parece ser que, para clientes e operadores, segurança pesa mais do que abertura absoluta — especialmente em software que lida com calendários, dados de usuários e fluxos de integração.

O que essa mudança sinaliza para o mercado

O caso pode servir como precedente para outras startups open source comerciais. Se a inteligência artificial amplia a capacidade de analisar software público em escala, a pressão por esconder ou isolar o que é crítico tende a aumentar. Isso pode acelerar um movimento já conhecido em outro formato: o surgimento de versões públicas funcionais, mas incompletas, enquanto a produção real permanece fora do alcance do repositório aberto.

Na prática, o mercado pode caminhar para uma normalização de modelos híbridos. E isso traz consequências importantes:

• mais cautela na definição do que realmente deve permanecer aberto;
• menos espelhamento entre comunidade e produção;
• mais dependência de repositórios privados para componentes sensíveis;
• e uma revisão gradual do que significa “open source” em empresas com produto comercial.

O limite entre proteção e fechamento

Há, no entanto, limites importantes nessa leitura. A decisão pode ser interpretada como uma resposta legítima a um cenário de ameaça mais sofisticado, mas também pode ser vista como um passo a mais no controle comercial. Além disso, o texto divulgado pela empresa não prova, por si só, que o código aberto tenha causado incidentes na Cal.com. O movimento é preventivo, não necessariamente reativo a um ataque comprovado.

Outro ponto é que a separação entre o produto público e o produto de produção já vinha acontecendo em algum grau. A formalização do novo modelo, portanto, não cria uma arquitetura totalmente nova — ela apenas explicita uma divisão que já estava em curso.

Mesmo assim, o impacto simbólico é forte. Quando uma empresa nascida dentro da lógica open source começa a tratar o próprio código público como risco operacional, ela reposiciona o debate para além do discurso ideológico. A discussão deixa de ser “abrir ou não abrir” e passa a ser “o que pode ser aberto sem comprometer o negócio e a segurança?”.

Uma mudança que pode marcar época

O caso da Cal.com é um termômetro interessante de uma transição maior. A IA não está apenas transformando desenvolvimento, produtividade e suporte. Ela também está alterando a economia da vulnerabilidade. Se encontrar falhas ficou mais fácil, mais rápido e mais escalável, então a velha equação do open source comercial precisa ser recalculada.

É por isso que essa decisão importa: ela mostra que o debate sobre transparência no software entrou em uma nova fase. Não se trata mais apenas de comunidade e colaboração, mas de exposição, custo de ataque e contenção de risco.

Em resumo, a Cal.com não abandonou a abertura por completo. O que ela fez foi algo mais sutil — e talvez mais importante: redesenhou os limites da abertura em um cenário em que a IA torna o código público mais valioso para auditores, usuários e, cada vez mais, também para atacantes.