Umstellung auf Closed Source: die technischen Änderungen

Was Cal.diy ist

Cal.diy ist die Open-Source-Terminplanungsplattform. Sie umfasst die vollständige Terminplanungs-Engine, das App-Store-Framework und die Buchungsinfrastruktur. Es ist alles, was Cal.com als selbst gehostete Lösung für Einzelpersonen leistungsstark macht.

Kommerzielle und enterprise-Funktionen, die nur für Cal.com als verwalteten Service gelten, wurden entfernt. Alle kostenlosen Funktionen bleiben in Cal.diy erhalten.

Was entfernt wurde

Die Trennung zwischen Cal.com und Cal.diy läuft auf kommerzielle und enterprise-Funktionen hinaus. Hier ist, was in Cal.diy nicht mehr enthalten ist:

• Organisationen und Teams: Multi-Tenant-Organisationsverwaltung, Team-Erstellung, Team-Verfügbarkeit, Team-Buchungsabläufe, Tools für die Organisationsmigration, PBAC (zugriffsbasierte Berechtigungssteuerung) und alle zugehörigen API-v2-Endpunkte

• Routing-Formulare: Das vollständige App-Store-Paket für Routing-Formulare, einschließlich des Route-Generators, Formularaktionen, Testdialog, Salesforce-Routing-Integration, Routing-Trace-Funktionalität und Verarbeitung von Antworten in der Warteschlange

• Workflows: Automatisierte Workflow-Engine (Erinnerungen, Follow-ups, Trigger) und alle zugehörigen Verweise über API v2, Plattformbibliotheken und Buchungsabläufe hinweg

• Sofortbuchung: Sofort-Ereignistypen und der gesamte zugehörige Code des Buchungsdienstes

• KI-Telefon: Ausführung von Telefonanrufen über Cal.ai und der Tab für den KI-Telefon-Ereignistyp

• Attribute und Segmente: React Awesome Query Builder (RAQB), Mitgliederattribute, segmentbasierte Filterung und Plattform-Einstellungen des Arbeitsbereichs

• SAML/SSO: Enterprise SAML/SSO-Registrierungsfluss

• Einblicke: Analyse- und Reporting-Dashboards

• API v1: Die gesamte API-v1-Anwendung wurde entfernt. Cal.diy wird nur mit API v2 ausgeliefert

• Enterprise-UI: Assistent zur Lizenzkonfiguration, Downloads von Compliance-Dokumenten, EE-Tipps, Premium-Benutzernamenfunktionen, Admin-Abrechnungsseite, KI-Übersetzung, Ablauf zum Kauf von Credits

• Buchungs-Audit: Audit-Logging für Buchungen (enterprise-Beobachtbarkeitsfunktion)

• Identitätsvortäuschung: Admin-Benutzer-Impersonation über Buchungs- und Kalendersynchronisierungsabläufe hinweg

Alles andere bleibt in Cal.diy: die zentrale Terminplanungslogik, der App-Store, die Buchungsabläufe und API v2.

Den Code für Cal.diy vorbereiten

Um das calcom/cal.com-Repository auf die Umstellung auf calcom/cal.diy vorzubereiten, haben wir einen separaten Branch im privaten Repository gepflegt, der mit dem main branch des öffentlichen Repositories synchron blieb. Dieser Branch war der Referenzpunkt, anhand dessen wir kommerzielle Funktionen vor der Umbenennung identifiziert und entfernt haben. Durch den Vergleich mit ihm konnten wir genau sehen, welcher Code abgetrennt werden musste, sodass beim Wechsel von calcom/cal.com zu calcom/cal.diy nur der Open-Source-Code übrig blieb.

Wir haben diesen Branch auch verwendet, um zu bestätigen, dass alle GitHub-Checks bestanden wurden. Wir wollten die Übergabe des Repositories sauber gestalten, also haben wir vor dem Livegang der Umbenennung sichergestellt, dass CI grün war und die Codebasis in einem gesunden Zustand war, damit die Community vom ersten Tag an darauf aufbauen kann.

Lizenzänderung: AGPL 3.0 zu MIT

Wir haben die Lizenz von Cal.diy von AGPL 3.0 auf MIT geändert.

Cal.diy ist ein anderes Produkt mit einem anderen Zweck als Cal.com: der Community die möglichst freizügige Terminplanungsplattform zu bieten. MIT passt besser zu diesem Ziel.

Betreuer von Cal.diy

Cal.diy wird von ehemaligen Cal.com-Praktikanten gepflegt, die jetzt offizielle Betreuer des Repositories sind.

Diese Ingenieure haben Zeit in der Codebasis von Cal.com verbracht. Sie verstehen die Architektur, die Muster und das Produkt. Während ihrer Praktika haben sie echte Funktionen ausgeliefert, PRs überprüft und Produktionsprobleme behoben.

Das Engineering-Team von Cal.com konzentriert sich auf das kommerzielle Produkt. Die Betreuer von Cal.diy konzentrieren sich auf die Community.

Infrastrukturänderungen

Das öffentliche Repository verfügte über jahrelange CI/CD-Konfiguration, Bot-Integrationen und DevOps-Automatisierung. All das musste für das private Repository neu aufgebaut werden.

GitHub-Aktionen

Cal.diy hat 53 GitHub-Action-Workflows. Das private Repository hat 62. Wir haben nahezu jeden bestehenden Workflow angepasst, um Verweise auf das alte Repo in Checkout-Schritten, API-URLs, Artefaktpfaden und Deployment-Hooks zu aktualisieren.

Private Repositories haben andere Berechtigungsmodelle. Mehrere frühe PRs befassten sich mit CI-Fehlern, weil der Checkout privater Repositories explizite contents: read-Berechtigungen erfordert, die öffentliche Repositories implizit erhalten.

Secrets und Umgebungskonfiguration

Die meisten Secrets werden übernommen, aber einige müssen für das öffentliche Repository neu bereitgestellt werden, etwa Anmeldedaten für Testsuiten, die gegen Google und Stripe laufen. Die neuen Betreuer werden sie bald bereitstellen, und die Testsuiten werden automatisch wieder aktiviert, sobald sie die Einstellungen erkennen.

Sicherheits-Backporting

Während die beiden Repositories parallel gepflegt wurden, hatte Sicherheit in beide Richtungen Priorität. Sicherheitslücken wurden in dem Repository behoben, in dem sie zuerst auffielen, und dann in das andere zurückportiert. Manchmal landete ein Fix im öffentlichen Repo und wurde in das private übernommen. Manchmal war es umgekehrt.

Beispiele sind das Upgrade von axios auf 1.15.0 zur Behebung kritischer CVEs, das Upgrade von handlebars auf 4.7.9 zur Behebung einer kritischen Sicherheitslücke, das Blockieren von localhost- und Loopback-Adressen im SSRF-Schutz, das Hinzufügen von CSRF-Schutz zu OAuth-Callbacks über HMAC-signierte Nonces, das Verhindern von IDOR in tRPC-Endpunkten und die Behebung von Fehlern bei Sicherheitsprüfungen von fast-xml-parser.

Unser Ziel war es, Cal.diy aus Sicherheitssicht in einem soliden Zustand an die Community zu übergeben. Das bedeutete, das öffentliche Repo als Produktionscodebasis zu behandeln und nicht als Nebensache, selbst während das kommerzielle Produkt im privaten Repo gebaut wurde.