A transição para código fechado: as alterações técnicas

O que é o Cal.diy

O Cal.diy é a plataforma de agendamento de código aberto. Inclui o motor de agendamento completo, a estrutura da app store e a infraestrutura de reservas. É tudo o que torna o Cal.com poderoso como uma solução auto-hospedada para indivíduos.

As funcionalidades comerciais e de enterprise que apenas se aplicam ao Cal.com como um serviço gerido foram removidas. Todas as funcionalidades gratuitas permanecem no Cal.diy.

O que foi removido

A separação entre o Cal.com e o Cal.diy resume-se a funcionalidades comerciais e de enterprise. Eis o que já não está incluído no Cal.diy:

• Organizações e Equipas: Gestão de organizações multi-tenant, criação de equipas, disponibilidade de equipas, fluxos de reserva de equipas, ferramentas de migração de organizações, PBAC (controlo de acesso baseado em permissões) e todos os endpoints relacionados da API v2

• Formulários de Encaminhamento: O pacote completo da app store de formulários de encaminhamento, incluindo o criador de rotas, ações de formulário, diálogo de teste, integração de encaminhamento do Salesforce, funcionalidade de rastreio de encaminhamento e gestão de respostas em fila

• Fluxos de Trabalho: Motor automatizado de fluxos de trabalho (lembretes, acompanhamentos, gatilhos) e todas as referências relacionadas na API v2, bibliotecas da plataforma e fluxos de reserva

• Reserva Instantânea: Tipos de eventos instantâneos e todo o código de serviço de reserva associado

• Telefone com IA: Execução de chamadas telefónicas do Cal.ai e o separador de tipos de eventos de telefone com IA

• Atributos e Segmentos: React Awesome Query Builder (RAQB), atributos de membros, filtragem baseada em segmentos e definições de plataforma do espaço de trabalho

• SAML/SSO: Fluxo de registo Enterprise SAML/SSO

• Estatísticas: Painéis de análise e relatórios

• API v1: Toda a aplicação API v1 foi removida. O Cal.diy é fornecido apenas com a API v2

• Interface de Utilizador Enterprise: Assistente de configuração de licença, downloads de documentos de conformidade, dicas de EE, funcionalidades de nome de utilizador premium, página de faturação de administrador, tradução por IA, fluxo de compra de créditos

• Auditoria de Reservas: Registo de auditoria de reservas (funcionalidade de observabilidade enterprise)

• Personificação: Personificação de utilizador administrador nos fluxos de reserva e sincronização de calendário

Tudo o resto permanece no Cal.diy: a lógica de agendamento principal, a app store, os fluxos de reserva e a API v2.

Preparar o código para o Cal.diy

Para preparar o repositório calcom/cal.com para a sua transição para calcom/cal.diy, mantivemos um ramo separado no repositório privado que permaneceu sincronizado com o ramo principal do repositório público. Este ramo foi o ponto de referência a partir do qual identificámos e removemos funcionalidades comerciais antes da alteração de nome. Ao comparar as diferenças, conseguimos ver exatamente qual o código que precisava de ser separado para que, quando o calcom/cal.com se tornasse calcom/cal.diy, restasse apenas o código de código aberto.

Também utilizámos este ramo para confirmar que todas as verificações do GitHub estavam a passar. Queríamos que a entrega do repositório fosse limpa, por isso, antes de a alteração de nome entrar em vigor, garantimos que a CI estava verde e que a base de código estava num estado saudável para a comunidade começar a trabalhar logo no primeiro dia.

Alteração de licença: AGPL 3.0 para MIT

Alterámos a licença do Cal.diy de AGPL 3.0 para MIT.

O Cal.diy é um produto diferente com um propósito diferente do Cal.com: dar à comunidade a plataforma de agendamento mais permissiva possível. A licença MIT adequa-se melhor a esse objetivo.

Mantenedores do Cal.diy

O Cal.diy é mantido por antigos estagiários do Cal.com que são agora mantenedores oficiais do repositório.

Estes engenheiros passaram tempo dentro da base de código do Cal.com. Eles compreendem a arquitetura, os padrões e o produto. Desenvolveram funcionalidades reais durante os seus estágios, reviram PRs e depuraram problemas de produção.

A equipa de engenharia do Cal.com foca-se no produto comercial. Os mantenedores do Cal.diy focam-se na comunidade.

Alterações de infraestrutura

O repositório público tinha anos de configuração de CI/CD, integrações de bots e automação de DevOps. Tudo isso precisava de ser reconstruído para o repositório privado.

GitHub actions

O Cal.diy tem 53 fluxos de trabaho de GitHub Actions. O repositório privado tem 62. Mexemos em quase todos os fluxos de trabalho existentes para atualizar as referências ao antigo repositório nos passos de checkout, URLs de API, caminhos de artefactos e ganchos de implementação.

Os repositórios privados têm modelos de permissão diferentes. Vários PRs iniciais abordaram falhas de CI porque o checkout de repositórios privados requer permissões explícitas de contents: read que os repositórios públicos obtêm implicitamente.

Segredos e configuração de ambiente

A maioria dos segredos é transferida, mas alguns precisam de ser aprovisionados do zero para o repositório público, como credenciais para conjuntos de testes executados no Google e Stripe. Os novos mantenedores irão aprovisioná-los em breve e os conjuntos de testes reativar-se-ão automaticamente quando detetarem as definições.

Backporting de segurança

Enquanto os dois repositórios eram mantidos em paralelo, a segurança era uma prioridade em ambas as direções. As vulnerabilidades eram corrigidas no repositório que as detetasse primeiro e, depois, portadas para o outro. Às vezes, uma correção era aplicada no repositório público e integrada no privado. Outras vezes, acontecia o contrário.

Os exemplos incluem a atualização do axios para 1.15.0 para corrigir CVEs críticas, a atualização do handlebars para 4.7.9 para resolver uma vulnerabilidade crítica, o bloqueio de endereços localhost e de loopback na proteção SSRF, a adição de proteção CSRF aos callbacks de OAuth através de nonces assinados por HMAC, a prevenção de IDOR nos endpoints tRPC e a resolução de falhas na auditoria de segurança do fast-xml-parser.

O nosso objetivo era entregar o Cal.diy à comunidade num estado sólido do ponto de vista da segurança. Isso significava tratar o repositório público como uma base de código de produção, e não de forma secundária, mesmo enquanto o produto comercial estava a ser construído no repositório privado.