Cal.com ha annunciato che stanno chiudendo il loro codice sorgente e non saranno più un prodotto open-source. La loro motivazione è che l'intelligenza artificiale ha reso l'open source troppo pericoloso per le aziende SaaS. Il codice viene scansionato e sfruttato dall'AI a costi quasi nulli, e la trasparenza sta diventando esposizione.
Grazie, Sam. Apprezzo molto che tu abbia affrontato la questione in modo diretto come hai fatto. Ho seguito le recenti notizie sull’IA (per quanto mi è stato possibile) e questa domanda è stata certamente presente nella mia mente. Continua il ottimo lavoro. 
Molto rispetto qui, era una preoccupazione che avevo in fondo alla mente da un po’ di tempo riguardo a Discourse. Grazie a voi per essere dalla parte giusta della questione e per continuare a non enshittificare il prodotto principale. Non riesco a immaginare che avremo una regolamentazione sull’IA per un bel po’ di tempo per molte ragioni, ma la situazione è molto cupa in questo momento.
Spero che abbiate tutti ben presente quanto tutti apprezzino il fatto di non dover auto-ospitare il prodotto e di non essere comunque sollecitati a sborsare soldi per sbloccare funzionalità di base (come fanno molti prodotti “open source”). 
Chiudere improvvisamente il tuo codice sorgente non risolve magicamente tutti i problemi di sicurezza esistenti nel tuo codice che non sono ancora stati identificati. Ma di certo impedirà alla comunità di contribuire a risolverli.
Oltretutto, è anche un gesto scortese verso tutti coloro che hanno contribuito a far crescere il tuo prodotto. Perché dovrei ora, o in futuro, fare qualcosa con/per cal.com dopo questa azione? Perché dovrei fare qualcosa per la loro “fork” per hobbisti cal.dyi? Hanno semplicemente buttato via tutta la fiducia che avevano creato.
Grazie per l’articolo del blog, è stata una lettura interessante, Sam 
Questo è stato ovunque su internet, ma la minaccia alla sicurezza (“i nostri modelli sono troppo pericolosi”) è la ragione reale o principale per non rilasciarli?
Alcune persone sostengono che sia più uno stunt di pubbliche relazioni, pur non cancellando completamente il potenziale di forza dei modelli. Un esempio: On Anthropic's Mythos Preview and Project Glasswing - Schneier on Security
Certamente non so nulla di tutti questi argomenti complessi, ma sono cauto quando leggo articoli che si diffondono a velocità fulminea su tutti i siti di notizie e nelle comunità online. Immagino ci siano delle riserve su ciò che viene affermato. Che probabilmente c’è un fondo di verità e altre informazioni che necessitano di chiarimenti, o sono state esagerate.
Non ho alcun dubbio sul fatto che i modelli siano incredibilmente veloci nel trovare e probabilmente sfruttare le vulnerabilità, e hai anche evidenziato questo con l’esempio di codice di Discourse.
Riguardo all’articolo stesso, voglio solo segnalare qualcosa che mi è sembrato strano mentre leggevo:
Il codice chiuso è sempre stata una difesa più debole per il SaaS di quanto le persone vogliano ammettere. Un’applicazione web non è qualcosa che si distribuisce una volta sola e si tiene nascosto. Grandi parti di essa vengono consegnate direttamente nel browser dell’utente a ogni richiesta: JavaScript, contratti API, flussi lato client, logica di convalida e comportamento delle funzionalità. Gli attaccanti possono già ispezionare tutto ciò, e l’IA rende tale ispezione drasticamente più economica. Chiudere il repository potrebbe nascondere alcuni dettagli implementativi lato server, ma non rende il sistema invisibile. Ciò che fa principalmente è ridurre il numero di difensori in grado di esaminare l’immagine completa.
Poi, più avanti:
Il codice chiuso può comprare un po’ di oscurità, ma l’oscurità è fragile. Il codice viene trapelato, i binari vengono decompilati, le API vengono mappate e gli attaccanti imparano molto semplicemente interrogando il sistema in esecuzione. La vera difesa non è tenere il codice nascosto per sempre. È costruire software e pratiche operative che resistano quando arriva la scrutinio.
Quando ho letto il secondo paragrafo, ho avuto la sensazione di averlo già letto.
Ho fatto scorrere verso l’alto e ho notato che i due paragrafi sono molto, molto simili. Entrambi affermano le stesse cose, ma usando una formulazione diversa.
Capisco la necessità di riassumere, ma in questo caso, ho davvero avuto la sensazione di aver letto sostanzialmente le stesse cose pochi paragrafi prima.
Questa è stata davvero una lettura ispiratrice, Sam. Mi rende orgoglioso di lavorare su Discourse.
[pensando freneticamente a qualcosa da dire per non sembrare un adulatore…]
Forse mi metto anche al lavoro ora. 
Leggere questo mi ha davvero commosso. La frase sulla scelta del coraggio invece di nascondersi dietro una porta chiusa è così potente. Grazie per aver sostenuto l’open source per 13 anni e per averci ricordato di cosa si tratta davvero. Queste parole resteranno con me.
Grande affermazione!
https://releases.discourse.org funziona anche ed è così bella ora 
Che gusto! E splendidamente chiaro e molto utile, ottimo lavoro!
Se l’Open Source è morto, allora perché lo stanno ancora usando? Perché non sono passati da PostgreSQL a Oracle DB? Perché il team non è passato da Linux a MS Windows? Etc.
L’intera applicazione, il middleware e anche ampie parti dell’infrastruttura sono costruiti su Open Source.
Questa è un’ottima comunicazione e un ottimo argomento.
Comprendo il rischio che l’IA acceleri gli exploit zero-day.
Senza sminuire in alcun modo lo sforzo necessario, mi chiedo se Discourse potrebbe prendere in considerazione l’implementazione di pipeline CI/CD in tempo reale relative agli aggiornamenti?
Forse questo avviene già su siti gestiti da Meta e da Discourse; sto pensando specificamente a quelli self-hosted, dove un flag di funzionalità potrebbe abilitare gli aggiornamenti al momento del rilascio o con un ritardo, come processo automatizzato.
Oppure potrebbe manifestarsi come una funzione di aggiornamento automatico della sicurezza che può essere abilitata indipendentemente dagli altri aggiornamenti.
Comunque sia, desidero continuare a esprimere la mia gratitudine e apprezzamento per il software Discourse e per le persone che lo sviluppano. Grazie!
Ci sono buone ragioni per cui questa non è una buona idea qui:
Esatto! E questo significa che ereditano le vulnerabilità di quel middleware, che vengono divulgate pubblicamente indipendentemente da ciò che decidono di nascondere.
Tutto questo è una grande farsa. Ogni studente universitario sa che la sicurezza per oscurità non funziona.
Discourse dimostra che è possibile rimanere open source, costruire un’attività SaaS sostenibile E tenere il passo nel panorama delle vulnerabilità, invece di cercare di nascondersene.
Sono così felice di vedere Discourse non solo rimanere open source (cosa che non ho mai messo in dubbio), ma anche decidere di prendere una posizione in merito. 
Non mi dispiace la loro decisione, è loro facoltà, ma tutta questa manipolazione dell’opinione pubblica è estremamente frustrante.
Una cosa che la generazione di codice tramite AI e la caccia alle vulnerabilità mi hanno insegnato è che stiamo ancora combattendo contro le stesse idee sbagliate ma popolari che i dirigenti hanno sostenuto fin dall’alba dei tempi. In questo caso, l’argomento della “sicurezza per oscurità” contro l’open source.