Overstappen naar closed source: de technische wijzigingen

Wat Cal.diy is

Cal.diy is het open-source planningsplatform. Het bevat de volledige planningsengine, het appstore-framework en de boekingsinfrastructuur. Het is alles wat Cal.com krachtig maakt als self-hosted oplossing voor individuen.

Commerciële en enterprisefuncties die alleen van toepassing zijn op Cal.com als beheerde service zijn verwijderd. Alle gratis functies blijven in Cal.diy.

Wat is verwijderd

Het onderscheid tussen Cal.com en Cal.diy draait om commerciële en enterprisefuncties. Hier is wat niet langer is inbegrepen in Cal.diy:

• Organisaties en Teams: Beheer van multi-tenant-organisaties, aanmaken van teams, beschikbaarheid van teams, boekingsstromen voor teams, migratietooling voor organisaties, PBAC (toegangsbeheer op basis van permissies) en alle gerelateerde API v2-endpoints

• Routing-formulieren: Het volledige appstorepakket voor routing-formulieren, inclusief de routebouwer, formulieracties, testdialoog, Salesforce-routingintegratie, functionaliteit voor routingtracering en afhandeling van wachtrijreacties

• Workflows: Geautomatiseerde workflow-engine (herinneringen, opvolgacties, triggers) en alle gerelateerde verwijzingen in API v2, platformbibliotheken en boekingsstromen

• Direct boeken: Instant event-types en alle bijbehorende code van de boekingsservice

• AI-telefoon: Uitvoering van telefoongesprekken via Cal.ai en het tabblad voor het AI-telefoon-eventtype

• Attributen en segmenten: React Awesome Query Builder (RAQB), ledenattributen, segmentgebaseerde filtering en platforminstellingen van de werkruimte

• SAML/SSO: Aanmeldstroom voor Enterprise SAML/SSO

• Insights: Analyse- en rapportagedashboards

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

• Enterprise UI: Wizard voor licentie-instelling, downloads van compliancedocumenten, EE-tips, premiumgebruikersnaamfuncties, factureringspagina voor beheerders, AI-vertaling, flow voor het kopen van credits

• Booking Audit: Logregistratie van boekingsaudits (enterprise-observabilityfunctie)

• Impersonation: Impersonatie van beheerdersgebruikers in boekings- en kalendersynchronisatiestromen

De rest blijft in Cal.diy: de kernlogica voor planning, de appstore, de boekingsstromen 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 in de privérepository een aparte branch aan die gesynchroniseerd 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 naamswijziging. Door ermee te diffen, konden we precies zien welke code moest worden afgesplitst, zodat wanneer calcom/cal.com calcom/cal.diy werd, alleen de open-sourcecode overbleef.

Ook gebruikten we deze branch om te bevestigen dat alle GitHub-checks slaagden. We wilden dat de overdracht van de repository soepel verliep, dus voordat de naamswijziging live ging, zorgden we ervoor 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 zo'n permissief mogelijk planningsplatform bieden. MIT past beter bij dat doel.

Onderhouders van Cal.diy

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

Deze engineers hebben tijd doorgebracht in de codebase van Cal.com. Ze begrijpen de architectuur, de patronen en het product. Tijdens hun stages hebben ze echte functies opgeleverd, PR's beoordeeld en productieproblemen opgelost.

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

Infrastructuurwijzigingen

De publieke repository had jaren aan CI/CD-configuratie, botintegraties en DevOps-automatisering. Alles moest opnieuw worden opgebouwd voor de privérepository.

GitHub-acties

Cal.diy heeft 53 GitHub Action-workflows. De privé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.

Privérepositories hebben andere toestemmingsmodellen. Verschillende vroege PR's pakten CI-fouten aan, omdat checkout van een privérepo expliciete contents: read-rechten vereist die publieke repos impliciet krijgen.

Secrets en omgevingsconfiguratie

De meeste secrets blijven behouden, maar een paar moeten opnieuw worden ingericht voor de publieke repository, zoals inloggegevens voor testsuites die tegen Google en Stripe draaien. De nieuwe onderhouders zullen die binnenkort aanmaken en de testsuites worden automatisch opnieuw geactiveerd zodra ze de instellingen zien.

Security-backporting

Terwijl de twee repositories parallel werden onderhouden, had beveiliging in beide richtingen prioriteit. Kwetsbaarheden werden gepatcht in de repository die ze als eerste tegenkwam en daarna backgeport naar de andere. Soms kwam een fix in de publieke repo terecht en werd die selectief overgenomen in de private. Soms was het andersom.

Voorbeelden zijn het upgraden van axios naar 1.15.0 om kritieke CVE's op te lossen, het upgraden van handlebars naar 4.7.9 om een kritieke kwetsbaarheid op te lossen, het blokkeren van localhost- en loopbackadressen 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 fouten uit de security-audit van 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 behandelden als een productiecodebase, niet als een bijzaak, zelfs terwijl het commerciële product in de private repo werd gebouwd.