Cal.com hat angekündigt, dass sie ihre Codebasis schließen und kein Open-Source-Produkt mehr sein werden. Ihre Begründung ist, dass KI Open Source für SaaS-Unternehmen zu gefährlich gemacht hat. Code wird von KI zu nahezu null Kosten gescannt und ausgenutzt, und Transparenz wird zunehmend zur Offenlegung.
Vielen Dank, Sam. Ich schätze es sehr, dass du das so direkt ansprichst. Ich habe die jüngsten damit verbundenen KI-Nachrichten verfolgt (so gut ich mithalten kann), und diese Frage hat mir sicher im Hinterkopf beschäftigt. Mach weiter so! 
Hier gibt es viel Respekt. Das war eine Sorge, die ich seit geraumer Zeit im Hinterkopf hatte, wenn es um Discourse geht. Danke euch, dass ihr auf der richtigen Seite steht und das Kernprodukt weiterhin nicht enshittifiziert. Ich kann mir kaum vorstellen, dass wir aus vielen Gründen noch eine Weile auf eine KI-Regulierung warten werden, aber die Lage ist derzeit sehr düster.
Ich hoffe, ihr wisst alle, wie sehr es geschätzt wird, dass man das Produkt nicht selbst hosten muss und trotzdem gebettelt wird, Geld zu zahlen, um grundlegende Funktionen freizuschalten (wie es viele „Open-Source“-Produkte tun). 
Das plötzliche Schließen Ihres Quellcodes behebt nicht magisch alle bestehenden Sicherheitsprobleme in Ihrem Code, die noch nicht identifiziert wurden. Es verhindert jedoch definitiv, dass die Community dabei hilft, diese zu beheben.
Darüber hinaus ist es ein rücksichtsloser Schritt gegenüber allen, die zum Wachstum Ihres Produkts beigetragen haben. Warum sollte ich nach dieser Aktion jemals wieder etwas mit oder für cal.com tun? Warum sollte ich irgendetwas für ihre Hobby-Fork cal.dyi unternehmen? Sie haben einfach das gesamte Vertrauen, das sie aufgebaut hatten, über den Haufen geworfen.
Danke für den Blogartikel, es war eine interessante Lektüre, Sam 
Das steht überall im Internet, aber ist die Sicherheitsbedrohung („unsere Modelle sind zu gefährlich") der echte oder Hauptgrund dafür, dass es nicht veröffentlicht wird?
Einige Leute behaupten, es handele sich eher um eine PR-Strategie, auch wenn die potenzielle Stärke der Modelle dadurch nicht vollständig in Frage gestellt wird. Ein Beispiel: On Anthropic's Mythos Preview and Project Glasswing - Schneier on Security
Ich weiß zwar nichts von all diesen komplexen Themen, aber ich bin vorsichtig, wenn ich Artikel lese, die sich blitzschnell auf allen Nachrichtenseiten und in Online-Communities verbreiten. Ich gehe davon aus, dass es Einschränkungen bei den Behauptungen gibt. Dass wahrscheinlich etwas dran ist, aber andere Informationen geklärt werden müssen oder übertrieben sind.
Ich bezweifle keineswegs, dass Modelle unglaublich schnell sind, Schwachstellen zu finden und sie wahrscheinlich auszunutzen, und du hast das sogar mit dem Discourse-Codebeispiel unterstrichen.
Zu dem Artikel selbst: Ich möchte nur etwas anmerken, das mir beim Lesen seltsam vorkam:
Closed Source war schon immer eine schwächere Verteidigung für SaaS, als die Leute zugeben wollen. Eine Webanwendung ist nicht etwas, das man einmal ausliefert und dann versteckt hält. Große Teile davon werden bei jeder Anfrage direkt im Browser des Nutzers ausgeliefert: JavaScript, API-Verträge, clientseitige Abläufe, Validierungslogik und Funktionsverhalten. Angreifer können das alles bereits einsehen, und KI macht diese Einblicke drastisch günstiger. Das Schließen des Repositories mag einige serverseitige Implementierungsdetails verbergen, aber es macht das System nicht unsichtbar. Was es hauptsächlich bewirkt, ist, dass weniger Verteidiger den Gesamtüberblick einsehen können.
Dann später:
Closed Source kann etwas Verschleierung bieten, doch Verschleierung ist brüchig. Code wird geleakt, Binärdateien werden rückentwickelt, APIs werden kartiert, und Angreifer lernen viel, indem sie das laufende System abfragen. Die eigentliche Verteidigung besteht nicht darin, den Code für immer zu verstecken. Es geht darum, Software und Betriebspraktiken zu entwickeln, die auch unter genauer Prüfung standhalten.
Als ich den zweiten Absatz las, hatte ich das Gefühl, das schon einmal gelesen zu haben.
Ich habe nach oben gescrollt und festgestellt, dass die beiden Absätze sehr, sehr ähnlich sind. Beide sagen im Wesentlichen dasselbe, nur mit anderer Formulierung.
Ich verstehe die Notwendigkeit einer Zusammenfassung, aber in diesem Fall hatte ich wirklich das Gefühl, dass ich die gleichen Dinge schon ein paar Absätze zuvor gelesen hatte.
Das war wirklich eine inspirierende Lektüre, Sam. Das macht mich stolz, bei Discourse zu arbeiten.
[verzweifelt überlege ich mir etwas, das mich weniger wie ein Schmeichler wirken lässt…]
Vielleicht mache ich jetzt sogar noch etwas Arbeit. 
Dieser Text hat mich wirklich tief bewegt. Der Satz darüber, Mut zu wählen, anstatt sich hinter einer verschlossenen Tür zu verstecken, ist so kraftvoll. Danke, dass Sie seit 13 Jahren zu Open Source stehen und uns daran erinnern, worum es dabei wirklich geht. Diese Worte werde ich nicht so schnell vergessen.
Toller Satz!
https://releases.discourse.org funktioniert auch und sieht jetzt so gut aus 
Oh, das ist lecker! Und wunderschön klar und sehr nützlich, großartige Arbeit!
Wenn Open Source tot wäre, warum nutzen sie es dann noch? Warum sind sie nicht von PostgreSQL zu Oracle DB gewechselt? Warum ist das Team nicht von Linux auf MS Windows umgestiegen? usw.
Ihre gesamte Anwendung, Middleware und sogar große Teile der Infrastruktur basieren auf Open Source.
Das ist eine großartige Ankündigung und ein spannendes Thema.
Ich verstehe das Risiko, dass KI Zero-Day-Exploits beschleunigen könnte.
Ich unterschätze keineswegs den Aufwand, aber ich frage mich, ob Discourse in Erwägung ziehen würde, eine Art relative Echtzeit-CI/CD-Pipeline für Updates einzuführen?
Vielleicht geschieht das bei Meta- und Discourse-verwalteten Seiten bereits. Ich denke hier speziell an Self-Hosted-Installationen, bei denen ein Feature-Flag Updates entweder sofort nach Veröffentlichung oder mit Verzögerung als automatisierter Prozess freischalten könnte.
Oder vielleicht zeigt sich dies als automatisierte Sicherheitsupdate-Funktion, die unabhängig von anderen Updates aktiviert werden kann.
Unabhängig davon möchte ich meinen Dank und meine Wertschätzung für die Discourse-Software und die Menschen dahinter erneut aussprechen. Vielen Dank!
Es gibt gute Gründe, warum dies hier keine gute Idee ist:
Genau! Das bedeutet, dass sie die Schwachstellen dieser Middleware erben, und diese werden öffentlich bekannt gegeben, unabhängig davon, was sie zu verbergen versuchen.
Das ist alles eine große Farce. Jeder Studierende weiß, dass Sicherheit durch Verschleierung nicht funktioniert.
Discourse zeigt, dass es möglich ist, Open Source zu bleiben, ein nachhaltiges SaaS-Geschäft aufzubauen UND im Schwachstellen-Umfeld Schritt zu halten, anstatt sich davor zu verstecken.
So schön zu sehen, dass Discourse nicht nur Open Source bleibt (was ich ohnehin nie bezweifelt habe), sondern sich auch hier positioniert. 
Ich habe nichts gegen ihre Entscheidung, sie liegt in ihren Händen, aber das ganze Spin-Doctoring ist extrem frustrierend.
Eines hat mir die KI-gestützte Codegenerierung und die Suche nach Schwachstellen gelehrt: Wir kämpfen immer noch mit denselben schlechten, aber populären Ideen, die Führungskräfte seit Anbeginn der Zeit vertreten. In diesem Fall das Argument der „Sicherheit durch Unklarheit