Cal.com a annoncé qu'ils ferment leur base de code et ne seront plus un produit open source. Leur raisonnement est que l'IA a rendu l'open source trop dangereux pour les entreprises SaaS. Le code est scanné et exploité par l'IA à un coût quasi nul, et la transparence devient désormais une exposition.
Merci, Sam. J’apprécie que tu aies abordé cela frontalement de cette manière. Je suis les actualités récentes liées à l’IA (du mieux que je peux) et cette question a certainement été en arrière-plan de mon esprit. Continuez ce excellent travail. 
Beaucoup de respect ici. C’était une préoccupation qui me trottait dans la tête depuis un moment avec Discourse. Merci à vous d’être du bon côté de la question et de continuer à ne pas enshittifier le produit de base. Je ne m’imagine pas que nous aurons une réglementation sur l’IA dans un proche avenir pour de nombreuses raisons, mais la situation est très sombre en ce moment. J’espère que vous savez à quel point tout le monde apprécie de ne pas avoir à auto-héberger le produit tout en étant sollicité pour débourser de l’argent afin de débloquer des fonctionnalités de base (comme le font de nombreux produits dits « open source »). 
Fermer soudainement votre source ne résout pas magiquement tous les problèmes de sécurité existants dans votre code qui n’ont pas encore été identifiés. Mais cela empêchera certainement la communauté de vous aider à les corriger.
En outre, c’est aussi un geste déplacé envers tous ceux qui ont contribué à faire grandir votre produit. Pourquoi ferais-je maintenant, ou jamais, quoi que ce soit avec ou pour cal.com après cette action ? Pourquoi ferais-je quoi que ce soit pour leur « fork » de loisir cal.dyi ? Ils ont tout simplement jeté toute la confiance qu’ils avaient créée.
Merci pour cet article de blog, c’était une lecture intéressante, Sam 
Cela a fait le tour d’Internet, mais la menace sécuritaire (« nos modèles sont trop dangereux ») est-elle la raison réelle ou principale de ne pas les publier ?
Certaines personnes affirment qu’il s’agit davantage d’un coup de pub, sans pour autant nier la puissance potentielle des modèles. Un exemple : On Anthropic's Mythos Preview and Project Glasswing - Schneier on Security
Je ne prétends rien savoir de tous ces sujets complexes, mais je reste prudent quand je lis des articles qui se propagent comme une traînée de poudre sur tous les sites d’information et les communautés en ligne. Je suppose qu’il y a des nuances dans ce qui est avancé. Qu’il y a probablement une part de vérité, mais aussi d’autres informations qui nécessitent des clarifications, ou qui sont surestimées.
Je ne doute pas du fait que les modèles sont incroyablement rapides pour identifier et probablement exploiter des vulnérabilités, et vous l’avez même illustré avec l’exemple de code Discourse.
Concernant l’article lui-même, je voudrais simplement souligner quelque chose qui m’a paru étrange à la lecture :
Le code fermé a toujours constitué une défense plus faible pour le SaaS que les gens ne veulent bien l’admettre. Une application web n’est pas quelque chose que vous livrez une fois et gardez caché. De grandes parties sont livrées directement dans le navigateur de l’utilisateur à chaque requête : JavaScript, contrats d’API, flux côté client, logique de validation et comportement des fonctionnalités. Les attaquants peuvent déjà inspecter tout cela, et l’IA rend cette inspection considérablement moins coûteuse. Fermer le dépôt peut masquer certains détails d’implémentation côté serveur, mais cela ne rend pas le système invisible. Ce que cela fait surtout, c’est réduire le nombre de défenseurs capables d’examiner l’ensemble du tableau.
Puis, plus loin :
Le code fermé peut offrir une certaine obscurité, mais l’obscurité est fragile. Le code fuit, les binaires sont décompilés, les API sont cartographiées, et les attaquants apprennent beaucoup simplement en interrogeant le système en cours d’exécution. La vraie défense ne consiste pas à garder le code caché indéfiniment. Il s’agit de construire des logiciels et des pratiques opérationnelles qui résistent lorsque l’examen critique arrive.
En lisant le deuxième paragraphe, j’ai eu l’impression de l’avoir déjà lu.
J’ai remonté la page et j’ai remarqué que les deux paragraphes sont très, très similaires. Ils disent exactement la même chose, mais avec des formulations différentes.
Je comprends la nécessité de résumer, mais dans ce cas, j’ai vraiment eu l’impression d’avoir lu essentiellement les mêmes choses quelques paragraphes plus tôt.
C’était vraiment une lecture inspirante, Sam. Ça me rend fier de travailler chez Discourse.
[cherchant frénétiquement quelque chose à dire pour ne pas avoir l’air d’un flagorneur…]
Je vais peut-être même travailler un peu maintenant. 
Lire cela m’a vraiment ému. La phrase sur le choix du courage plutôt que de se cacher derrière une porte verrouillée est si puissante. Merci de soutenir l’open source depuis 13 ans, et de nous rappeler ce en quoi il consiste. Ces mots resteront gravés en moi.
Superbe déclaration !
https://releases.discourse.org fonctionne également et a l’air si bien maintenant 
Oh, c’est délicieux ! Et d’une clarté magnifique, très utile, excellent travail !
Si le logiciel libre est mort, pourquoi l’utilisent-ils encore ? Pourquoi n’ont-ils pas migré de PostgreSQL vers Oracle DB ? Pourquoi l’équipe n’a-t-elle pas migré de Linux vers MS Windows ? Etc.
Toute leur application, le middleware, et même de larges parties de l’infrastructure sont construits sur le logiciel libre.
C’est une excellente annonce et un sujet très pertinent.
Je comprends le risque que l’IA accélère l’exploitation de failles zero-day.
Sans sous-estimer en aucune façon les efforts fournis, je me demande si Discourse envisagerait de mettre en place des pipelines CI/CD en temps réel relatifs pour les mises à jour ?
Peut-être que cela se fait déjà chez Meta et sur les sites gérés par Discourse. Je pense spécifiquement aux installations auto-hébergées, où un indicateur de fonctionnalité (feature flag) pourrait permettre de déployer les mises à jour dès leur sortie, ou avec un délai, via un processus automatisé.
Ou peut-être que cela se traduit par une fonctionnalité de mise à jour de sécurité automatisée, activable indépendamment des autres mises à jour.
Quoi qu’il en soit, permettez-moi de vous renouveler mes remerciements et mon appréciation pour le logiciel Discourse et pour les personnes qui se cachent derrière. Merci !
Il y a de bonnes raisons pour lesquelles ce n’est pas une bonne idée ici :
Exactement ! Et cela signifie qu’ils héritent des vulnérabilités de ce middleware, lesquelles sont divulguées publiquement, peu importe ce qu’ils choisissent de cacher.
Tout cela n’est qu’une grande mascarade. Tout étudiant en première année sait que la sécurité par l’obscurité ne fonctionne pas.
Discourse montre qu’il est possible de rester en open source, de construire une entreprise SaaS durable ET de suivre l’évolution du paysage des vulnérabilités plutôt que d’essayer de s’en cacher.
Ravi de voir que Discourse non seulement reste open source (ce que je n’ai jamais mis en doute), mais qu’il décide aussi de prendre position ici. 
Je ne m’oppose pas à leur décision, c’est à eux de la prendre, mais tout ce jeu de manipulation est extrêmement frustrant.
Une chose que la génération de code par IA et la chasse aux vulnérabilités m’ont apprise, c’est que nous combattons toujours les mêmes mauvaises idées populaires que les dirigeants ont défendues depuis la nuit des temps. Dans ce cas précis, l’argument de la « sécurité par l’obscurité » contre l’open source.