Passage en closed-source : 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 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 qu’à Cal.com 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 :

• Organizations et Teams : gestion d’organisation multi-tenant, création d’équipes, disponibilité des équipes, flux de réservation d’équipe, outils de migration d’organisation, PBAC (permission-based access control) et tous les endpoints API v2 associés

• Routing Forms : l’ensemble du package d’application de routing forms de la boutique d’applications, y compris le constructeur de routes, les actions de formulaire, la boîte de dialogue de test, l’intégration de routing Salesforce, la fonctionnalité de trace de routage et la gestion des réponses mises en file d’attente

• Workflows : moteur de workflows automatisés (rappels, suivis, déclencheurs) et toutes les références associées dans API v2, les bibliothèques de la plateforme et les flux de réservation

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

• IA téléphonique : exécution des appels téléphoniques Cal.ai et onglet du type d’événement IA téléphonique

• 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 enterprise SAML/SSO

• Insights : tableaux de bord d’analytique et de reporting

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

• Interface enterprise : assistant de configuration de licence, téléchargements de documents de conformité, conseils EE, fonctionnalités premium de nom d’utilisateur, page de facturation admin, traduction par IA, flux d’achat de crédits

• Audit des réservations : journalisation d’audit des réservations (fonctionnalité d’observabilité enterprise)

• Usurpation d’identité : usurpation d’utilisateurs admin sur les flux de réservation et de synchronisation des calendriers

Tout le reste reste dans Cal.diy : la logique de planification de base, la boutique d’applications, les flux de réservation et API v2.

Préparation du code pour Cal.diy

Pour préparer le dépôt calcom/cal.com à sa transition vers calcom/cal.diy, nous avons maintenu une branche séparée dans le dépôt privé, synchronisée avec la branche main du dépôt public. Cette branche servait de point de référence à partir duquel nous avons identifié et supprimé les fonctionnalités commerciales avant le renommage. En comparant les différences avec celle-ci, nous pouvions voir exactement quel code devait être séparé afin que, lorsque calcom/cal.com devenait calcom/cal.diy, seul le code open source reste.

Nous avons aussi utilisé cette branche pour vérifier que toutes les vérifications GitHub passaient. Nous voulions que la transmission du dépôt soit propre, alors avant la mise en ligne du renommage, 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 fait passer la licence de Cal.diy d’AGPL 3.0 à MIT.

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

Mainteneurs de Cal.diy

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

Ces ingénieurs ont passé du temps dans la base de code de Cal.com. Ils comprennent l’architecture, les patterns et le produit. Ils ont livré de vraies fonctionnalités pendant leurs stages, relu 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é.

Changements d’infrastructure

Le dépôt public avait 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 a 53 workflows GitHub Action. Le dépôt privé en a 62. Nous avons touché presque chaque workflow existant pour mettre à jour les références à l’ancien dépôt dans les étapes de checkout, les URL API, les chemins d’artefacts et les hooks de déploiement.

Les dépôts privés ont des modèles d’autorisation différents. Plusieurs premiers PR ont traité des échecs 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 conservés, mais quelques-uns doivent être provisionnés à nouveau pour le dépôt public, comme les identifiants des suites de test qui s’exécutent avec Google et Stripe. Les nouveaux mainteneurs vont bientôt les provisionner et les suites de test se réactiveront automatiquement lorsqu’elles verront les paramètres.

Reprise 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étectait en premier, puis portées vers l’autre. Parfois, un correctif atterrissait dans le dépôt public puis était cherry-pické dans le privé. Parfois, c’était l’inverse.

Parmi les exemples : la mise à niveau d’axios vers 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 des adresses localhost et loopback dans la protection contre les SSRF, l’ajout d’une protection CSRF aux callbacks OAuth via des nonces signés HMAC, la prévention des 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 voulait dire traiter le dépôt public comme une base de code de production, et non comme un simple ajout secondaire, même pendant que le produit commercial était développé dans le dépôt privé.