Cal.com ha chiuso il codice il 14 aprile 2026. Cinque anni come promotori dell’open source, poi la svolta: la produzione passa da AGPL a proprietario. Il motivo dichiarato: la sicurezza open source nell’era dell’AI non regge più.

Il ragionamento di Cal.com

Bailey Pumfleet, co-founder, ha sintetizzato così la decisione: “just having a previous-generation model like Claude Opus analyze an open-source codebase makes it trivial to find vulnerabilities.” La visibilità del codice, secondo lui, è diventata un vettore di attacco nell’era dell’AI.

Cal.com non ha abbandonato del tutto l’open source. Cal.diy è la versione community rilasciata sotto licenza MIT. Il codebase di produzione, però, si è già differenziato in modo sostanziale: autenticazione e data handling sono stati riscritti. Chi ha costruito su Cal.com open source deve scegliere: seguire la versione proprietaria, forkare Cal.diy, o migrare.

Il problema è la velocità, non la visibilità

Il rapporto OSSRA 2026 di Black Duck documenta un aumento del 107% delle vulnerabilità medie per codebase, arrivate a 581 per applicazione su 947 codebase analizzati in 17 settori. L'87% conteneva almeno una vulnerabilità, il 44% con problemi critici.

Pumfleet usa questi numeri come conferma della propria tesi, ma li legge al contrario. Il surge non dimostra che l’open source è intrinsecamente meno sicuro: dimostra che il codice generato con AI arriva in produzione senza il tempo di analisi che richiederebbe. La licenza non cambia nulla: il vettore è la velocità di produzione senza review. Un codebase proprietario cresciuto alla stessa cadenza accumula lo stesso debito di sicurezza del codice AI, con la differenza che rimane invisibile.

Pumfleet, in questo ragionamento, sta scambiando causa con effetto.

Come funziona davvero la sicurezza open source

La difesa dell’open source non si basa sulla segretezza. Si basa sulla distribuzione del costo di auditing.

Simon Willison, citato nell’articolo del Register, ha formulato l’argomento in modo preciso: i progetti open source possono condividere il budget di analisi delle vulnerabilità tra tutta la community, mentre il software proprietario deve trovare tutti i bug internamente, con un solo team e un solo budget.

Con l’AI che abbassa il costo di vulnerability scanning quasi a zero, questo vantaggio non si riduce: si amplifica. Ogni ricercatore, ogni team di sicurezza, ogni sviluppatore con accesso a un modello può analizzare un codebase pubblico. Cal.com, chiudendo il codice, trasforma il proprio asset da molti occhi distribuiti a pochi occhi pagati internamente.

C’è un dato che Pumfleet non considera: gli stessi modelli AI che trovano vulnerabilità nel codice sorgente open source possono fare reverse engineering di binari compilati. La segretezza del codice sorgente non è una difesa sostenibile contro un attaccante con strumenti adeguati. È una barriera per i contributor onesti, non per chi attacca con un modello.

Il take di TechMonk

La decisione di Cal.com accumula tre errori distinti. Tendono a presentarsi insieme, e la stessa logica la risentiremo da altri team nei prossimi mesi.

Primo: confondere visibilità con vulnerabilità. È una battaglia già persa da decenni. OpenBSD, la crittografia accademica degli anni ‘90, vent’anni di CVE nel software commerciale: tutti confermano la stessa cosa. La sicurezza per oscurità non ha mai fermato attaccanti competenti: ha fermato auditor, ricercatori e patch contributor. Pumfleet sta riproponendo un argomento già smontato come se trent’anni di storia nel merito non esistessero.

Secondo: leggere i dati di Black Duck nel verso sbagliato. Il 107% di aumento delle vulnerabilità per codebase non è un atto di accusa contro l’open source. È un atto di accusa contro la velocità di produzione del codice AI senza supervisione adeguata. La correlazione corretta: l’AI abbassa la barriera alla scrittura del codice, il codice scritto senza review arriva in produzione con più falle, indipendentemente dalla licenza. Il caso del vibe coding e la GPL mostra la stessa dinamica: il problema non è quale licenza copre il codice, è chi ne controlla la qualità.

Terzo, e il più grave: sottovalutare cosa succede quando l’AI entra nell’equazione dall’altra parte. Quando il costo di vulnerability scanning scende verso zero, scende anche il costo di auditing difensivo. Un progetto open source con centinaia di contributor, un processo di review attivo e strumenti AI accessibili a chiunque ha una capacità di copertura che un team di sicurezza interno non può eguagliare in termini assoluti. Cal.com era esattamente quel tipo di progetto: una community che guardava il codice, lo testava, lo patchava. Ha scelto di rinunciare a quel vantaggio, citando come minaccia gli stessi strumenti che avrebbero reso quella copertura ancora più capillare.

Il risultato pratico è che Cal.com si è appena iscritta al modello di sicurezza che usano Oracle, SAP e ogni altro vendor di software proprietario enterprise. Tutti con team di sicurezza dedicati. Tutti con centinaia di CVE ogni anno. Se l’oscurità proteggesse davvero, lo vedremmo nei numeri. Non lo vediamo perché la segretezza del codice sorgente proteggeva da un vettore specifico: il ricercatore che sfoglia manualmente un repository in cerca di falle. Quell’attacco è diventato marginale quando gli scanner automatizzati hanno reso possibile analizzare qualsiasi binario senza accedere al sorgente.

L’unico scenario in cui la decisione ha una logica difendibile è se Cal.com ha vulnerabilità architetturali già sfruttate che non può correggere senza ammetterle pubblicamente. In quel caso, chiudere il codice è gestione del danno reputazionale, non ingegneria della sicurezza. Ma questo è un giudizio sui decision maker, non sulla struttura del software.

Conclusione

L’open source sopravviverà all’AI. Il vantaggio strutturale della community auditing si somma agli stessi strumenti AI che Pumfleet cita come minaccia. La domanda più interessante è quante altre aziende faranno lo stesso calcolo sbagliato, e quanti sviluppatori scopriranno tardi di aver costruito su infrastruttura che non potevano più ispezionare.