Overstappen naar closed source: de technische wijzigingen

Wat Cal.diy is

Cal.diy is het open-source scheduling platform. Het bevat de volledige scheduling engine, de app store-framework en de booking-infrastructuur. Het is alles wat Cal.com krachtig maakt als self-hosted oplossing voor individuen.

Commerciële en enterprise-functies die alleen van toepassing zijn op Cal.com als beheerde dienst, zijn verwijderd. Alle gratis functies blijven in Cal.diy.

Wat is verwijderd

Het verschil tussen Cal.com en Cal.diy komt neer op commerciële en enterprise-functies. Dit zit er niet meer in Cal.diy:

• Organizations en Teams: multi-tenant organisatiebeheer, aanmaken van teams, beschikbaarheid van teams, bookingflows voor teams, tooling voor org-migratie, PBAC (permission-based access control) en alle gerelateerde API v2-endpoints

• Routing Forms: het volledige app store-pakket voor routing forms, inclusief de route builder, form actions, testdialoog, Salesforce routing-integratie, routing-tracefunctionaliteit en verwerking van in de wachtrij geplaatste reacties

• Workflows: geautomatiseerde workflow-engine (herinneringen, follow-ups, triggers) en alle gerelateerde verwijzingen in API v2, platformbibliotheken en bookingflows

• Instant Booking: instant event types en alle bijbehorende code voor bookingservices

• AI Phone: uitvoering van telefoongesprekken door Cal.ai en het tabblad voor het AI Phone-eventtype

• Attributes and Segments: React Awesome Query Builder (RAQB), member attributes, segmentgebaseerde filtering en platforminstellingen voor de workspace

• SAML/SSO: enterprise SAML/SSO-aanmeldflow

• Insights: analytics- en rapportagedashboards

• API v1: de volledige API v1-applicatie is verwijderd. Cal.diy wordt alleen geleverd met API v2

• Enterprise UI: licentie-installatiewizard, downloads van compliance-documenten, EE-tips, premium username-functies, adminfacturatiepagina, AI-vertaling, buy-credits-flow

• Booking Audit: bookingauditlogboek (enterprise observability-functie)

• Impersonation: impersonatie van admingebruikers over booking- en calendarsyncflows heen

Alles anders blijft in Cal.diy: de kernlogica voor scheduling, de app store, de bookingflows en API v2.

De code voorbereiden voor Cal.diy

Om de calcom/cal.com-repository voor te bereiden op de overgang naar calcom/cal.diy, hielden we een aparte branch aan in de private repository die synchroon bleef met de main branch van de publieke repository. Deze branch was het referentiepunt waarmee we commerciële functies identificeerden en verwijderden vóór de hernoeming. Door ermee te diffen, konden we exact zien welke code moest worden afgesplitst, zodat wanneer calcom/cal.com calcom/cal.diy werd, alleen de open-source code overbleef.

We gebruikten deze branch ook om te controleren of alle GitHub-checks slaagden. We wilden de overdracht van de repository netjes houden, dus vóór de hernoeming live ging, zorgden we dat CI groen was en de codebase in een gezonde staat verkeerde zodat de community er vanaf dag één mee verder kon.

Licentiewijziging: AGPL 3.0 naar MIT

We hebben de licentie van Cal.diy gewijzigd van AGPL 3.0 naar MIT.

Cal.diy is een ander product met een ander doel dan Cal.com: de community de meest permissieve scheduling platform-optie geven die mogelijk is. MIT past daar beter bij.

Cal.diy-beheerders

Cal.diy wordt onderhouden door voormalige stagiairs van Cal.com die nu officiële maintainers van de repository zijn.

Deze engineers hebben tijd doorgebracht in de Cal.com-codebase. Ze begrijpen de architectuur, de patronen en het product. Ze hebben tijdens hun stages echte functies geleverd, PR's beoordeeld en production issues debugged.

Het engineeringteam van Cal.com richt zich op het commerciële product. De Cal.diy-maintainers richten zich op de community.

Infrastructuurwijzigingen

De publieke repository had jarenlang CI/CD-configuratie, bot-integraties en DevOps-automatisering. Dat moest allemaal opnieuw worden opgebouwd voor de private repository.

GitHub actions

Cal.diy heeft 53 GitHub Action-workflows. De private repository heeft er 62. We hebben bijna elke bestaande workflow aangepast om verwijzingen naar de oude repo bij te werken in checkout-stappen, API-URL's, artifactpaden en deployment hooks.

Private repositories hebben andere rechtenmodellen. Verschillende vroege PR's losten CI-fouten op, omdat checkout van een private repo expliciete contents: read-rechten vereist die publieke repos impliciet krijgen.

Secrets en omgevingsconfiguratie

De meeste secrets nemen we over, maar een paar moeten opnieuw worden ingericht voor de publieke repository, zoals credentials voor testsuites die tegen Google en Stripe draaien. De nieuwe maintainers zullen ze binnenkort provisionen en de testsuites worden automatisch weer geactiveerd wanneer ze de instellingen zien.

Security backporting

Terwijl de twee repositories parallel werden onderhouden, was security in beide richtingen een prioriteit. Kwetsbaarheden werden gepatcht in de repository die ze als eerste tegenkwam, en daarna backported naar de andere. Soms landde een fix in de publieke repo en werd die cherry-picked naar de private. Soms ging het andersom.

Voorbeelden zijn het upgraden van axios naar 1.15.0 om kritieke CVE's te verhelpen, het upgraden van handlebars naar 4.7.9 om een kritieke kwetsbaarheid op te lossen, het blokkeren van localhost- en loopback-adressen in SSRF-bescherming, het toevoegen van CSRF-bescherming aan OAuth-callbacks via HMAC-ondertekende nonces, het voorkomen van IDOR in tRPC-endpoints en het oplossen van security audit-fouten voor fast-xml-parser.

Ons doel was om Cal.diy vanuit beveiligingsperspectief in een solide staat aan de community over te dragen. Dat betekende dat we de publieke repo als een production codebase behandelden, niet als een bijzaak, ook terwijl het commerciële product in de private repo werd gebouwd.