Wechsel zu Closed-Source: die technischen Änderungen

Was Cal.diy ist

Cal.diy ist die Open-Source-Scheduling-Plattform. Sie umfasst die komplette Scheduling-Engine, das App-Store-Framework und die Buchungsinfrastruktur. Sie enthält alles, was Cal.com als selbst hostbare Lösung für Einzelpersonen leistungsstark macht.

Kommerzielle und Enterprise-Funktionen, die nur für Cal.com als verwalteten Dienst 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:

• Organizations und Teams: Mandantenfähige Organisationsverwaltung, Team-Erstellung, Team-Verfügbarkeit, Team-Buchungsabläufe, Org-Migrationstools, PBAC (permission-based access control) und alle dazugehörigen API-v2-Endpunkte

• Routing Forms: Das komplette Routing-Forms-App-Store-Paket, einschließlich Route-Builder, Formularaktionen, Testdialog, Salesforce-Routing-Integration, Routing-Trace-Funktionalität und Verarbeitung von Warteschlangenantworten

• Workflows: Automatisierte Workflow-Engine (Erinnerungen, Follow-ups, Trigger) und alle dazugehörigen Verweise in API v2, Plattformbibliotheken und Buchungsabläufen

• Instant Booking: Sofortige Termintypen und der gesamte dazugehörige Buchungsdienst-Code

• AI Phone: Cal.ai-Anrufausführung und der Tab für den AI-Phone-Typ

• Attributes and Segments: React Awesome Query Builder (RAQB), Mitgliederattribute, segmentbasierte Filterung und Plattform-Einstellungen des Workspaces

• SAML/SSO: Enterprise-SAML/SSO-Anmeldeflow

• Insights: 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 Lizenz-Einrichtung, Download von Compliance-Dokumenten, EE-Tipps, Premium-Benutzername-Funktionen, Admin-Abrechnungsseite, AI-Übersetzung, Kaufguthaben-Flow

• Booking Audit: Protokollierung des Booking Audits (Enterprise-Observability-Funktion)

• Impersonation: Admin-Benutzer-Impersonation über Buchungs- und Kalender-Sync-Flows hinweg

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

Den Code für Cal.diy vorbereiten

Um das Repository calcom/cal.com auf die Umstellung zu calcom/cal.diy vorzubereiten, haben wir im privaten Repository einen separaten Branch gepflegt, der mit dem main-Branch des öffentlichen Repositories synchron blieb. Dieser Branch war der Referenzpunkt, von dem aus wir kommerzielle Funktionen vor der Umbenennung identifiziert und entfernt haben. Durch den Vergleich mit diesem Branch 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 genutzt, um zu bestätigen, dass alle GitHub-Checks bestanden haben. Wir wollten die Übergabe des Repositories sauber halten, also haben wir vor dem Go-live der Umbenennung sichergestellt, dass CI grün war und die Codebasis in einem gesunden Zustand war, damit die Community sie ab Tag eins übernehmen konnte.

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 permissive Scheduling-Plattform zu geben. MIT passt besser zu diesem Ziel.

Cal.diy-Maintainer

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

Diese Engineers haben Zeit in der Cal.com-Codebasis verbracht. Sie verstehen die Architektur, die Patterns und das Produkt. Sie haben während ihrer Praktika echte Features ausgeliefert, PRs reviewed und Produktionsprobleme debuggt.

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

Infrastrukturänderungen

Das öffentliche Repository hatte jahrelang 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 fast 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 behandelten CI-Fehler, weil das Checkout eines privaten Repos explizite contents: read-Berechtigungen erfordert, die öffentliche Repos implizit erhalten.

Geheimnisse und Umgebungskonfiguration

Die meisten Geheimnisse werden übernommen, aber einige müssen für das öffentliche Repository neu bereitgestellt werden, etwa Zugangsdaten für Test-Suites, die gegen Google und Stripe laufen. Die neuen Maintainer werden sie bald bereitstellen, und die Test-Suites werden automatisch wieder aktiviert, sobald sie die Einstellungen sehen.

Sicherheits-Backporting

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

Dazu gehören das Upgrade von axios auf 1.15.0 zur Behebung kritischer CVEs, das Upgrade von handlebars auf 4.7.9 zur Behebung einer kritischen Schwachstelle, 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 das Beheben von Sicherheitsprüfungsfehlern bei fast-xml-parser.

Unser Ziel war es, Cal.diy der Community aus Sicherheitssicht in einem soliden Zustand zu übergeben. Das bedeutete, das öffentliche Repo als Produktions-Codebasis zu behandeln und nicht als nachträglichen Gedanken, selbst während das kommerzielle Produkt im privaten Repo gebaut wurde.