Passage à un code source fermé : les changements techniques

Ce qu'est Cal.diy

Cal.diy est la plateforme de planification open source. Elle inclut le moteur de planification complet, le framework de la boutique d'applications et l'infrastructure de réservation. C'est tout ce qui rend Cal.com puissant en tant que solution auto-hébergée pour les particuliers.

Les fonctionnalités commerciales et enterprise qui ne s'appliquent à Cal.com qu'en tant que service géré ont été supprimées. Toutes les fonctionnalités gratuites restent dans Cal.diy.

Ce qui a été supprimé

La séparation entre Cal.com et Cal.diy se résume aux fonctionnalités commerciales et enterprise. Voici ce qui n'est plus inclus dans Cal.diy :

• Organisations et équipes : Gestion d'organisations multi-locataires, création d'équipes, disponibilité des équipes, parcours de réservation d'équipe, outils de migration d'organisation, PBAC (contrôle d'accès basé sur les permissions) et tous les endpoints API v2 associés

• Formulaires de routage : Le package complet de la boutique d'applications Routing Forms, incluant le générateur de parcours, les actions de formulaire, la boîte de dialogue de test, l'intégration de routage Salesforce, la fonctionnalité de suivi du routage et la gestion des réponses en file d'attente

• Workflows : Moteur de workflow automatisé (rappels, relances, déclencheurs) et toutes les références associées dans l'API v2, les bibliothèques de plateforme et les parcours de réservation

• Réservation instantanée : Types d'événements instantanés et tout le code du service de réservation associé

• Téléphone IA : Exécution des appels téléphoniques Cal.ai et l'onglet du type d'événement téléphonique IA

• Attributs et segments : React Awesome Query Builder (RAQB), attributs des membres, filtrage basé sur les segments et paramètres de la plateforme de l'espace de travail

• SAML/SSO : Flux d'inscription SAML/SSO Enterprise

• Insights : Tableaux de bord d'analyse et de reporting

• API v1 : Toute l'application API v1 a été supprimée. Cal.diy est fourni uniquement avec l'API v2

• Interface Enterprise : Assistant de configuration de licence, téléchargements de documents de conformité, astuces EE, fonctionnalités premium pour les noms d'utilisateur, page de facturation administrateur, traduction IA, parcours d'achat de crédits

• Audit des réservations : Journalisation d'audit des réservations (fonctionnalité d'observabilité enterprise)

• Usurpation d'identité : Usurpation d'identité de l'utilisateur administrateur dans les parcours de réservation et de synchronisation du calendrier

Tout le reste demeure dans Cal.diy : la logique de planification centrale, la boutique d'applications, les parcours de réservation et l'API v2.

Préparer le code pour Cal.diy

Pour préparer le dépôt calcom/cal.com à sa transition vers calcom/cal.diy, nous avons conservé une branche séparée dans le dépôt privé, synchronisée avec la branche principale du dépôt public. Cette branche nous servait de point de référence pour identifier et supprimer les fonctionnalités commerciales avant le changement de nom. En le comparant par diff, nous pouvions voir exactement quel code devait être isolé afin que, lorsque calcom/cal.com est devenu calcom/cal.diy, seul le code open source reste.

Nous avons également utilisé cette branche pour confirmer que toutes les vérifications GitHub passaient. Nous voulions que la transmission du dépôt soit propre, donc avant la mise en ligne du changement de nom, nous nous sommes assurés que l'intégration continue était au vert et que la base de code était dans un état sain pour que la communauté puisse la reprendre dès le premier jour.

Changement de licence : AGPL 3.0 vers MIT

Nous avons changé la licence de Cal.diy de l'AGPL 3.0 au MIT.

Cal.diy est un produit différent avec un objectif différent de Cal.com : donner à la communauté la plateforme de planification la plus permissive possible. MIT est mieux adapté à cet objectif.

Mainteneurs de Cal.diy

Cal.diy est maintenu par d'anciens stagiaires de Cal.com qui sont maintenant mainteneurs officiels du dépôt.

Ces ingénieurs ont passé du temps dans la base de code Cal.com. Ils comprennent l'architecture, les schémas et le produit. Ils ont livré de vraies fonctionnalités pendant leurs stages, examiné des PR et débogué des problèmes de production.

L'équipe d'ingénierie de Cal.com se concentre sur le produit commercial. Les mainteneurs de Cal.diy se concentrent sur la communauté.

Modifications de l'infrastructure

Le dépôt public comportait des années de configuration CI/CD, d'intégrations de bots et d'automatisation DevOps. Tout a dû être reconstruit pour le dépôt privé.

Actions GitHub

Cal.diy dispose de 53 workflows GitHub Actions. Le dépôt privé en a 62. Nous avons modifié presque chaque workflow existant pour mettre à jour les références à l'ancien dépôt dans les étapes de checkout, les URL de l'API, les chemins des artefacts et les hooks de déploiement.

Les dépôts privés ont des modèles d'autorisations différents. Plusieurs premières PR ont corrigé des échecs de CI, car le checkout d'un dépôt privé nécessite des permissions explicites contents: read que les dépôts publics obtiennent implicitement.

Secrets et configuration d'environnement

La plupart des secrets sont repris, mais quelques-uns doivent être provisionnés à nouveau pour le dépôt public, comme les identifiants des suites de tests qui s'exécutent avec Google et Stripe. Les nouveaux mainteneurs les provisionneront bientôt et les suites de tests se réactiveront automatiquement lorsqu'elles verront les paramètres.

Portage des correctifs de sécurité

Pendant que les deux dépôts étaient maintenus en parallèle, la sécurité était une priorité dans les deux sens. Les vulnérabilités étaient corrigées dans le dépôt qui les découvrait en premier, puis portées vers l'autre. Parfois, un correctif atterrissait dans le dépôt public et était cherry-pické dans le dépôt privé. Parfois, c'était l'inverse.

Les exemples incluent la mise à niveau d'axios vers la version 1.15.0 pour corriger des CVE critiques, la mise à niveau de handlebars vers 4.7.9 pour résoudre une vulnérabilité critique, le blocage de localhost et des adresses loopback dans la protection SSRF, l'ajout d'une protection CSRF aux retours OAuth via des nonces signés HMAC, la prévention de l'IDOR dans les endpoints tRPC et la résolution des échecs de l'audit de sécurité de fast-xml-parser.

Notre objectif était de remettre Cal.diy à la communauté dans un état solide du point de vue de la sécurité. Cela signifiait traiter le dépôt public comme une base de code de production, et non comme une réflexion après coup, même pendant que le produit commercial était développé dans le dépôt privé.