Cal.com は、コードベースを閉鎖し、オープンソース製品ではなくなると発表した。その理由は、AI がオープンソースを SaaS 企業にとって危険すぎるものにしたためである。コードは AI によってほぼゼロのコストでスキャンされ悪用され、透明性が今や露出へと変わっている。
これは、https://blog.discourse.org/2026/04/discourse-is-not-going-closed-source にある元の投稿のための補足ディスカッショントピックです。
これは、https://blog.discourse.org/2026/04/discourse-is-not-going-closed-source にある元の投稿のための補足ディスカッショントピックです。
「いいね！」 38
サム、ありがとう。このように正面から向き合ってくれて感謝しています。
私は最近の関連するAIのニュースを追いかけています（できる限りですが）、この質問は確かに私の頭の片隅にありました。素晴らしい仕事を続けてください。
「いいね！」 14
ここでの敬意に心から感謝します。Discourseについては、以前から心の片隅で懸念していました。皆さんがこの問題において正しい立場を取り、コア製品を 劣化 させない姿勢を続けてくださっていることに感謝しています。AI規制がすぐに実現するとは思えませんが、現在の状況は非常に暗いです。
オープンソース製品のように、製品をセルフホストしなくても、基本的な機能の解除のために金銭を要求され続けることを皆さんがどれほど感謝されているか、理解していただければ幸いです。
「いいね！」 14
ソースコードを突然クローズしても、まだ特定されていない既存のセキュリティ上の問題が自動的に解決されるわけではありません。むしろ、コミュニティがそれらの問題を修正する手助けをすることを妨げるだけです。
それだけでなく、製品を成長させるために貢献してくれた人々に対する非常に無礼な行為です。cal.com に対して、この行動の後、あるいは今後、私が何かを手伝ったり関与したりする理由がどこにあるでしょうか。彼らの趣味のフォークである cal.dyi に対しても同様です。彼らは築き上げてきた信頼をすべて捨て去りました。
「いいね！」 8
ブログ記事を読んでいただきありがとうございます。とても興味深い内容でした、サム 
これはインターネット全体で話題になっていますが、セキュリティ上の脅威（「私たちのモデルは危険すぎる」）が、リリースしない本当の、あるいは主な理由なのでしょうか？
一部の人は、これは完全にはモデルの潜在的な強さを否定するものではないものの、むしろ PR 工作に近いと主張しています。一例として：On Anthropic's Mythos Preview and Project Glasswing - Schneier on Security
もちろん、これらすべての複雑なトピックについて私は何も知りませんが、すべてのニュースサイトやオンラインコミュニティで瞬く間に拡散される記事を読む際には慎重になります。主張にはいくつかの留保があるだろうと想定しています。おそらく一部は真実であり、他の情報については明確化が必要か、あるいは過剰に hype されているのでしょう。
モデルが脆弱性を発見し、おそらく悪用するスピードが非常に速いという点については疑いの余地がありません。Discourse のコード例でもそれを指摘されていました。
記事自体について、少し違和感を覚えた点を指摘させてください：
クローズドソースは、SaaS に対する防御策として、人々が認めたくないほど常に弱いです。Web アプリケーションは、一度リリースして隠しておけばよいものではありません。その大部分は、すべてのリクエストでユーザーのブラウザに直接配信されます：JavaScript、API 契約、クライアントサイドのフロー、検証ロジック、機能の動作などです。攻撃者はすでにそれらすべてを検査でき、AI によってその検査コストが劇的に下がっています。リポジトリを閉鎖しても、サーバーサイドの実装詳細の一部を隠すことはできても、システムを不可視にはしません。それが主に成し遂げるのは、システム全体を検査できる防御者の数を減らすことです。
その後、後ほど：
クローズドソースはある程度の隠蔽性を購入できますが、隠蔽性は脆いです。コードが漏洩し、バイナリがリバースエンジニアリングされ、API がマッピングされ、攻撃者は実行中のシステムを問いただすだけでも多くのことを学びます。真の防御は、コードを永遠に隠し続けることではありません。 scrutiny が訪れた際にも耐えうるソフトウェアと運用プラクティスを構築することです。
2 段落目を読んだとき、すでに読んだような気がしました。
上にスクロールすると、2 つの段落が非常に、非常に似ていることに気づきました。どちらも同じことを述べていますが、表現が異なります。
要約の必要性は理解できますが、この場合、数段落前にほぼ同じ内容を読んだような強い印象を受けました。
「いいね！」 5
これは本当に感銘を受ける読み物でした、サム。Discourse で働いていることに誇りを感じます。
必死に、へつらいのように聞こえないようにする言葉を考え中…
さっそく仕事に取り掛かるかもしれません。
「いいね！」 18
これを読むと本当に心が動かされました。鍵のかかった扉の後ろに隠れるのではなく、勇気を選ぶという一節は非常に力強いものです。13 年にわたりオープンソースのそばに立ち続けていただき、その本質を思い出させてくれたことに感謝します。これらの言葉は、私の心に残り続けるでしょう。
「いいね！」 9
素晴らしいコメントですね！
https://releases.discourse.org も機能しており、今ではとても見栄えがします 
「いいね！」 9
おいしそうですね！そして、とても明確で役立つ内容、素晴らしい仕事です！
「いいね！」 5
「いいね！」 4
オープンソースが死んだなら、なぜ彼らはまだそれを使っているのでしょうか。なぜ PostgreSQL から Oracle DB へ移行しないのでしょうか。なぜチームは Linux から MS Windows へ移行しないのでしょうか。など。
彼らのアプリケーション全体、ミドルウェア、さらにはインフラの大部分はオープンソース上で構築されています。
「いいね！」 5
これは素晴らしい発表とトピックですね。
AI がゼロデイエクスプロイトを加速させるリスクは理解しています。
その努力を軽視するつもりは毛頭ありませんが、Discourse では更新に対して何らかの相対的なリアルタイム CI/CD パイプラインを導入することを検討してはどうかと考えます。
Meta や Discourse 管理サイトでは既にこの仕組みが機能しているかもしれませんが、私は特にセルフホスト環境を想定しています。機能フラグによって、更新をリリース時に自動適用するか、あるいは遅延させて自動適用するかを制御できるような仕組みです。
あるいは、他の更新とは独立して有効化できる自動セキュリティ更新機能として実装されるかもしれません。
いずれにせよ、Discourse ソフトウェアとその開発者の方々に心から感謝と敬意を表します。ありがとうございます！
「いいね！」 3
ここでのこの案が適切ではないには、それなりの理由があります：
「いいね！」 1
その通りです！つまり、彼らはそのミドルウェアの脆弱性を継承しており、それらは彼らが何を隠そうと関係なく公開されます。
これはすべて大がかりな茶番です。セキュリティ・バイ・オブスキュリティ（隠蔽によるセキュリティ）が機能しないことは、学部生なら誰でも知っています。
Discourseは、オープンソースでありながら持続可能なSaaSビジネスを構築し、脆弱性の動向に追いつくことが可能であることを示しています。隠れるのではなく、それに対処する必要があるのです。
「いいね！」 5
Discourse がオープンソースであり続けるだけでなく、ここで毅然とした態度を取ることを決めたことに、とても嬉しく思います。
彼らの決定自体は構いません。それは彼ら自身の判断ですから。しかし、全体として行われている世論操作には非常にイライラします。
AI によるコード生成や脆弱性探索を通じて学んだのは、私たちは今もなお、経営者が昔から抱えてきた「悪が流行っている」という同じ考え方に立ち向かっているということです。今回の場合は、オープンソースに対する「セキュリティ・バイ・オスキュリティ（秘匿によるセキュリティ）」という主張です。
「いいね！」 5