Cal.com قد أعلنت أنها ستغلق كودها المصدري ولن تكون منتجًا مفتوح المصدر بعد الآن. والسبب الذي ذكروه هو أن الذكاء الاصطناعي جعل المصادر المفتوحة خطيرة للغاية على شركات البرمجيات كخدمة (SaaS). حيث يتم فحص الكود واستغلاله بواسطة الذكاء الاصطناعي بتكلفة شبه معدومة، وأصبحت الشفافية الآن تعني التعرض للخطر.
شكرًا لك يا سام. أقدر جدًا تعاملك مع هذا الأمر بشكل مباشر. لقد تابعت آخر الأخبار المتعلقة بالذكاء الاصطناعي (بقدر ما أستطيع)، وقد ظل هذا السؤال يدور في خلدّي. استمروا في العمل الرائع. 
كثير من الاحترام هنا، لقد كان هذا شيئًا يقلقني في أعماقي منذ فترة مع Discourse. شكرًا لكم على الوقوف في الجانب الصحيح من هذا الأمر ومواصلة عدم تدهور المنتج الأساسي. لا أستطيع تخيل أننا سنحصل على تنظيم للذكاء الاصطناعي لفترة أطول لعدة أسباب، لكن الأمور قاتمة جدًا حاليًا.
آمل أن تدركوا جميعًا كم يقدر الجميع عدم استضافة المنتج بأنفسهم مع الاستمرار في التوسل إلينا لدفع المال لفتح ميزات أساسية (كما تفعل العديد من المنتجات “مفتوحة المصدر”). 
إغلاق المصدر فجأة لا يُصلح سحرًا جميع مشكلات الأمان الموجودة في الكود والتي لم يتم اكتشافها بعد. لكنه بالتأكيد سيمنع المجتمع من المساعدة في إصلاحها.
إلى جانب ذلك، يُعد هذا تصرفًا غير لائق تجاه كل من ساعد في نمو منتجك. لماذا سأقوم الآن، أو في أي وقت، بأي شيء مع/لـ cal.com بعد هذا الإجراء؟ ولماذا سأفعل أي شيء من أجل “الشوكة” الهواية cal.dyi؟ لقد أهدروا ببساطة كل الثقة التي بنوها.
شكرًا لك على مقال المدونة، كان قراءة ممتعة سام 
انتشرت هذه الأخبار في كل مكان على الإنترنت، لكن هل تهديد الأمان (“نماذجنا خطيرة جدًا”) هو السبب الحقيقي أو الرئيسي لعدم إطلاقها؟
يدعي البعض أن الأمر يميل أكثر إلى كونه حيلة علاقات عامة، رغم أنه لا يلغي تمامًا القوة المحتملة للنماذج. مثال على ذلك: On Anthropic's Mythos Preview and Project Glasswing - Schneier on Security
بالتأكيد لا أعرف شيئًا عن كل هذه المواضيع المعقدة، لكنني أتوخى الحذر عندما أقرأ مقالات تنتشر بسرعة البرق على جميع مواقع الأخبار والمجتمعات عبر الإنترنت. أفترض أن هناك بعض التحفظات فيما يُدّعى. ربما هناك بعض الحقيقة وبعض المعلومات الأخرى التي تحتاج إلى توضيح، أو أنها مبالغ فيها.
لا أشك مطلقًا في أن النماذج سريعة للغاية في اكتشاف الثغرات واستغلالها على الأرجح، وقد أبرزت ذلك حتى من خلال مثال كود Discourse.
بشأن المقال نفسه، فقط أود الإشارة إلى شيء شعرت أنه غريب أثناء قراءته:
المصدر المغلق كان دائمًا دفاعًا أضعف لبرمجيات الخدمة السحابية (SaaS) مما يرغب الناس في الاعتراف به. تطبيق الويب ليس شيئًا تُسلمه مرة واحدة ثم تخفيه. أجزاء كبيرة منه تُسلّم مباشرة إلى متصفح المستخدم في كل طلب: جافا سكريبت، عقود واجهات برمجة التطبيقات (API)، تدفقات جانب العميل، منطق التحقق، وسلوك الميزات. يمكن للمهاجمين فحص كل ذلك بالفعل، والذكاء الاصطناعي يجعل هذا الفحص أرخص بشكل كبير. إغلاق المستودع قد يخفي بعض تفاصيل التنفيذ من جانب الخادم، لكنه لا يجعل النظام غير مرئي. ما يفعله في الغالب هو تقليل عدد المدافعين القادرين على فحص الصورة الكاملة.
ثم، لاحقًا:
المصدر المغلق قد يشتري بعض الغموض، لكن الغموض هش. يتسرب الكود، ويتم عكس هندسة الملفات الثنائية، وتُرسم خرائط واجهات برمجة التطبيقات، ويتعلم المهاجمون الكثير فقط من خلال استجواب النظام قيد التشغيل. الدفاع الحقيقي ليس إبقاء الكود مخفيًا إلى الأبد. إنه بناء البرمجيات والممارسات التشغيلية التي تصمد عند قدوم التدقيق.
عندما قرأت الفقرة الثانية، شعرت أنني قرأت ذلك من قبل.
تصعدت للأعلى، ولاحظت أن الفقرتين متشابهتان جدًا، جدًا. كلاهما يذكر نفس الأشياء، لكن باستخدام صياغة مختلفة.
أفهم الحاجة إلى التلخيص، لكن في هذه الحالة، شعرت حقًا أنني قرأت نفس الأشياء تقريبًا قبل بضع فقرات.
كان هذا حقًا قراءة ملهمة يا سام. إنه يجعلني فخورًا بالعمل في Discourse.
[أفكر بعصبية في شيء أقوله لأبدو أقل مثل المبالغة في المجاملة…]
ربما أقوم ببعض العمل الآن. 
لقد تأثرتُ حقًا بقراءتي لهذا النص. إن عبارة اختيار الشجاعة بدلاً من الاختباء خلف باب مغلق قوية جدًا. شكرًا لك على دعمك للمصادر المفتوحة طوال 13 عامًا، وعلى تذكيرنا بما تدور حوله حقًا. هذه الكلمات ستظل راسخة في ذهني.
بيان رائع!
https://releases.discourse.org يعمل أيضًا ويبدو رائعًا الآن 
يا لها من نكهة لذيذة! وواضحة بشكل جميل ومفيدة للغاية، عمل رائع!
إذا كان البرمجيات مفتوحة المصدر قد ماتت، فلماذا لا يزالون يستخدمونها؟ لماذا لم ينتقلوا من PostgreSQL إلى Oracle DB؟ ولماذا لم ينتقل الفريق من Linux إلى MS Windows؟ إلخ.
تُبنى تطبيقاتهم بالكامل، والوسائط، وحتى أجزاء كبيرة من البنية التحتية، على البرمجيات مفتوحة المصدر.
هذا إعلان وموضوع رائع.
أدرك مخاطر تسريع الذكاء الاصطناعي لاستغلال الثغرات الأمنية غير المعروفة (zero-day exploits).
بدون التقليل من الجهد المبذول بأي حال، أتساءل عما إذا كان نظام Discourse سيبني نوعًا من خطوط أنابيب التكامل المستمر/التسليم المستمر (CI/CD) النسبية في الوقت الفعلي للتحديثات؟
ربما يحدث هذا بالفعل في مواقع Meta ومواقع Discourse المدارة، لكنني أفكر تحديدًا في النسخ المستضافة ذاتيًا، حيث يمكن لعلامة ميزة (feature flag) تمكين التحديثات فور إصدارها، أو تأجيلها كعملية آلية.
أو ربما يتجلى ذلك في ميزة تحديث أمني آلية يمكن تمكينها بشكل مستقل عن التحديثات الأخرى.
بغض النظر، دعني أستمر في تقديم شكري وتقديري لبرنامج Discourse وللأشخاص وراءه. شكرًا لك!
هناك أسباب وجيهة تجعل هذا ليس فكرة جيدة هنا:
بالضبط! وهذا يعني أنهم يرثون ثغرات تلك الوسائط، ويتم الإفصاح عنها علنًا بغض النظر عما يختارون إخفاءه.
كل هذا مجرد تمثيل. فكل طالب جامعي يعرف أن الأمان عبر الغموض لا يعمل.
يُظهر Discourse أنه من الممكن البقاء مفتوح المصدر، وبناء عمل تجاري مستدام كخدمة برمجية (SaaS)، مع مواكبة مشهد الثغرات بدلاً من محاولة الاختباء منه.