A mudar para código fechado: as alterações técnicas

O que é a Cal.diy

A Cal.diy é a plataforma open-source de agendamento. Inclui o motor de agendamento completo, a framework da loja de aplicações e a infraestrutura de reservas. É tudo o que torna a Cal.com poderosa como uma solução self-hosted para indivíduos.

As funcionalidades comerciais e de enterprise que só se aplicam à Cal.com como serviço gerido foram removidas. Todas as funcionalidades gratuitas mantêm-se na Cal.diy.

O que foi removido

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

• Organizations e Teams: gestão multi-tenant de organizations, criação de teams, disponibilidade de teams, fluxos de reservas de team, ferramentas de migração de orgs, PBAC (controlo de acesso baseado em permissões) e todos os endpoints relacionados da API v2

• Routing Forms: o pacote completo da loja de aplicações de routing forms, incluindo o construtor de rotas, ações de formulário, diálogo de teste, integração de routing com Salesforce, funcionalidade de tracing de routing e tratamento de respostas na fila

• Workflows: motor automatizado de workflows (lembretes, seguimentos, gatilhos) e todas as referências relacionadas na API v2, bibliotecas da plataforma e fluxos de reserva

• Instant Booking: tipos de evento instantâneos e todo o código do serviço de reservas associado

• AI Phone: execução de chamadas telefónicas da Cal.ai e o separador do tipo de evento AI phone

• Attributes and Segments: React Awesome Query Builder (RAQB), atributos de membros, filtragem baseada em segmentos e definições da plataforma do workspace

• SAML/SSO: fluxo de registo enterprise SAML/SSO

• Insights: painéis de análise e relatórios

• API v1: a aplicação inteira da API v1 foi removida. A Cal.diy vem apenas com a API v2

• Enterprise UI: assistente de configuração de licença, downloads de documentos de conformidade, dicas EE, funcionalidades premium de username, página de faturação de admin, tradução por IA, fluxo de compra de créditos

• Booking Audit: registo de auditoria de bookings (funcionalidade enterprise de observabilidade)

• Impersonation: personificação de utilizador por admin em fluxos de reserva e sincronização de calendário

Tudo o resto permanece na Cal.diy: a lógica central de agendamento, a loja de aplicações, os fluxos de reserva e a API v2.

Preparar o código para a Cal.diy

Para preparar o repositório calcom/cal.com para a transição para calcom/cal.diy, mantivemos uma branch separada no repositório privado que ficou sincronizada com a branch principal do repositório público. Essa branch foi o ponto de referência a partir do qual identificámos e removemos as funcionalidades comerciais antes da mudança de nome. Ao comparar com ela, conseguimos ver exatamente que código precisava de ser separado para que, quando calcom/cal.com se tornasse calcom/cal.diy, apenas o código open-source ficasse restante.

Também usamos esta branch para confirmar que todas as verificações do GitHub estavam a passar. Queríamos que a passagem do repositório fosse limpa, por isso, antes de a mudança de nome entrar em vigor, garantimos que a CI estava verde e que a base de código estava numa boa situação para a comunidade assumir desde o primeiro dia.

Mudança de licença: AGPL 3.0 para MIT

Mudámos a licença da Cal.diy de AGPL 3.0 para MIT.

A Cal.diy é um produto diferente, com um objetivo diferente da Cal.com: dar à comunidade a plataforma de agendamento mais permissiva possível. O MIT é mais adequado para esse objetivo.

Maintainers da Cal.diy

A Cal.diy é mantida por antigos estagiários da Cal.com, que agora são maintainers oficiais do repositório.

Estes engenheiros passaram tempo dentro da base de código da Cal.com. Conhecem a arquitetura, os padrões e o produto. Lançaram funcionalidades reais durante os estágios, reveram PRs e debugaram problemas de produção.

A equipa de engenharia da Cal.com foca-se no produto comercial. Os maintainers da 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 teve de ser reconstruído para o repositório privado.

GitHub actions

A Cal.diy tem 53 workflows do GitHub Action. O repositório privado tem 62. Tocámos em quase todos os workflows existentes para atualizar referências ao repositório antigo nos passos de checkout, URLs da API, caminhos de artefactos e hooks de deployment.

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

Segredos e configuração de ambiente

A maior parte dos segredos transita, mas alguns precisam de ser provisionados de novo para o repositório público, como credenciais para suites de testes que correm contra Google e Stripe. Os novos maintainers irão provisioná-los em breve e as suites de testes reativar-se-ão automaticamente quando virem as definições.

Backporting de segurança

Enquanto os dois repositórios foram mantidos em paralelo, a segurança foi uma prioridade em ambas as direções. As vulnerabilidades foram corrigidas no repositório que as detetava primeiro e depois retroportadas para o outro. Às vezes, uma correção chegava ao repositório público e era cherry-picked para o 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 loopback na proteção contra SSRF, a adição de proteção CSRF aos callbacks OAuth através de nonces assinados com HMAC, a prevenção de IDOR em endpoints tRPC e a resolução de falhas de auditoria de segurança do fast-xml-parser.

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