لمنظومتك مفتوحة المصدر مجلس إدارة خفي. ولا أحد يُخضعه للتدقيق.
في إصدارها 6.15، أسقطت نواة لينكس دعمًا اعتمدت عليه الشركات لثلاثة عقود، دون أن يكون من تحمّلوا التكلفة حاضرين في الغرفة. تُخضع المؤسسات كل مورّد تجاري لمراجعة دقيقة، لكنها لا تُخضع الأساسات التي تقوم عليها بنيتها التحتية فعليًا لأي مراجعة على الإطلاق.
في مايو 2025، صدرت نواة لينكس (Linux) بالإصدار 6.15 دون دعم لمعالجات إنتل 486 وإصدارات مبكرة من 586، لتُغلق بذلك وعدًا بالتوافق ظل قائمًا منذ أوائل التسعينيات دون أن يُكتب في أي وثيقة رسمية. كان التبرير المعلن عمليًا: الحفاظ على طبقة المحاكاة التي تحتاجها تلك المعالجات كان يستهلك وقت القائمين على الصيانة الذي رأى المشروع أنه يُصرف بشكل أفضل في مكان آخر، وكان النقاش حول هذا الحذف دائرًا علنًا على قائمة بريد النواة منذ 2022. تبرير مقبول في حدود ذاته. لكن اسأل من استُشير فعلًا. الشركات التي لا تزال تشغّل تلك الشرائح، في وحدات التحكم الصناعية وأجهزة المختبرات والأنظمة المدمجة التي يفوق عمرها عمر مورّديها، لم تحصل على فترة إشعار ولا جدول زمني معلن ولا مقعد في النقاش. سد تلك الفجوة هو بالضبط ما تُفترض أن تفعله مراجعة حوكمة المصادر المفتوحة، ولا أحد تقريبًا يقوم بذلك.
لن توقّع مؤسستك عقدًا لخمس سنوات مع مورّد دون التحقق من مالكه وممولّه وما سيحدث حين تتغير مصالحه. ومع ذلك، تبني المؤسسة نفسها عقدًا كاملًا من البنية التحتية على منصة مفتوحة المصدر دون أن تطرح سؤالًا واحدًا عن الجهة التي تقودها. وحين توجد المراجعة أصلًا، فإنها تتوقف عند ملف الرخصة، والرخصة لا تنظّم سوى ما يحق لك فعله بالشيفرة كما هي عليه الآن. أما ما قد تفعله الجهة القائمة على المشروع بالشيفرة لاحقًا، فهو أمر خارج نطاقها تمامًا. لا أحد يرسل فاتورة عن إيقاف دعم، لكن بند الميزانية يظهر رغم ذلك.
هل تدين لك مشاريع المصادر المفتوحة بالتوافق العكسي؟
لا. خارطة الطريق وسياسة إيقاف الدعم ودعم المنصات كلها تخضع لتقدير الجهة القائمة على المشروع، بلا استثناء. مع مورّد تجاري، تحصل على فترات إشعار ومستويات خدمة وسبل تعويض؛ أما مع جهة قائمة على مشروع مفتوح المصدر، فنفوذك يتناسب مع حجم تمويلك ومشاركتك، ومعظم الشركات لا تقدّم أيًا منهما. من منظور الحوكمة، أنت عميل لا يدفع لمورّد لا يدين لك بشيء. هذا الترتيب يعمل بسلاسة طالما تصادفت المصالح، والخطأ هو التعامل مع هذا التوافق كخاصية أصيلة في المصادر المفتوحة بدلًا من اعتباره مصادفة تستحق المراقبة. كما أن الجهة القائمة على المشروع ليست كيانًا محايدًا مجردًا: فقائمة الأعضاء «البلاتينيين» في مؤسسة لينكس (Linux Foundation) تضم شركات مصنّعة للمعالجات ومشغلي حوسبة سحابية ومصنّعي أجهزة، ولكل منها مصالحه التجارية الخاصة، وهيئات الحوكمة المماثلة في القطاع تبدو غالبًا على الشاكلة نفسها.
كم من الإشعار المسبق تمنحه عمليات إيقاف الدعم في المصادر المفتوحة فعليًا؟
بقدر ما تنص عليه سياسة الجهة القائمة على المشروع، ولا يومًا أكثر. يستحق السجل المقارن قراءة متأنية، لأن المدى بين الحالات هائل. في الطرف الأكثر سخاءً تقف بايثون (Python). فقد حددت الوثيقة PEP 373، المنشورة عام 2008، عام 2015 موعدًا لإنهاء دعم بايثون 2.7، وحين اتضح أن المنظومة لم تكن جاهزة فعلًا، أرجأ المشروع الموعد إلى 1 يناير 2020. أي أكثر من عقد كامل من الإشعار المكتوب والعلني، عُدّل مرة واحدة، ولصالح المعتمدين على النظام.
وفي الطرف الآخر تقف CentOS. اعتمدت المؤسسات نظام CentOS 8 عام 2019 استنادًا إلى دورة حياة معلنة مطابقة لنظام Red Hat Enterprise Linux، تنتهي عام 2029. لكن في ديسمبر 2020 أعلن المشروع أن دعم CentOS Linux 8 سينتهي بدلًا من ذلك في نهاية 2021، مع تحوّل العمل إلى CentOS Stream. مهلة كانت الشركات المعتمدة على النظام قد قدّرتها بعقد كامل تقريبًا، تقلّصت إلى نحو اثني عشر شهرًا فقط من الإشعار، وكل خطة انتقال بُنيت عليها أصبحت مستحقة قبل موعدها بسبع سنوات.
أما Node.js فيقع في المنتصف، ويحمل الدرس الأدق. كان لإصدار Node 16 موعد نهاية دعم معلن في أبريل 2024 وفق جدول إصدارات المشروع، ثم قدّم المشروع هذا الموعد سبعة أشهر إلى 11 سبتمبر 2023، لأن مكتبة OpenSSL 1.1.1 التي يعتمد عليها انتهى دعمها أولًا، ولم يرغب أحد في تشغيل بيئة تنفيذ فوق تشفير غير مُحدّث. كان الجدول حقيقيًا والتزمت الجهة القائمة على المشروع بمساره الخاص. ومع ذلك خسر المعتمدون على النظام سبعة أشهر، لأن ساعة جهة أخرى قائمة على مشروع مختلف نفدت أولًا.
إذا وضعت هذه السجلات جنبًا إلى جنب مع سجل النواة، يتضح النمط بجلاء: الإشعار سياسة، لا قانونًا فيزيائيًا حتميًا. يتراوح المدى بين عقد كامل وعام واحد، وتتحرك المواعيد المعلنة في الاتجاهين، وإشعارك الفعلي هو أقصر نافذة إشعار في أي حلقة من سلسلة اعتمادك التقنية. حذف دعم معالجات 486 ليس فضيحة، بل هو النقطة الواقعة في الطرف الأبعد من هذا المدى. لم توجد وثيقة دورة حياة لدعم العتاد في النواة أصلًا، وبالتالي كان الإشعار الوحيد المتاح نقاشًا على قائمة بريد لم يكن يقرأه أي فريق مشتريات تقريبًا في العالم.
حين تُصنَع المشكلة من الأوراق الرسمية
يبرز خطر منفصل، ويجب التوضيح بصراحة أنه لم يكن له أي دور في قرار حذف دعم 486، الذي نوقش علنًا لسنوات على أسس هندسية بحتة. يكمن هذا الخطر في أن «أدلة عبء الصيانة» أصبح بالإمكان توليدها عند الطلب. فشيفرة برمجية تعمل في بيئة الإنتاج لسنوات دون شكوى بشرية واحدة؛ ثم تنتج أداة فحص آلية عيبًا نظريًا يبدو معقولًا؛ يُدرج التقرير في نظام التتبع؛ وتصبح الشيفرة تحمل مشكلات مفتوحة، وهكذا تبدو إزالة العبء وكأنها تنظيف روتيني لا إيقاف دعم فعلي. مشروع curl يعيش الآن الموجة الأولى من هذا الخطر. حذّر المشرف على المشروع دانيال ستنبرغ (Daniel Stenberg) في يناير 2024 من تقارير أمنية مولّدة بمساعدة الذكاء الاصطناعي، وبحلول يوليو 2025 أفاد بأن نحو خُمس التقارير الأمنية الواردة إلى curl كانت «هراءً» مولّدًا بالذكاء الاصطناعي، دون أن ينتج عن أي منها حتى الآن بلاغ صالح واحد، بينما يستهلك كل بلاغ ساعات ثمينة من وقت المراجعين ذوي الخبرة. الحذف عبر الأوراق الرسمية احتمال قائم لأي مشروع لا يستطيع نظام الفرز فيه التمييز بين تخمين مولّد آليًا وعيب حقيقي واجهه مستخدم فعلي.
تعامل بحذر خاص مع حجة «بسبب الذكاء الاصطناعي» في نقاشات نطاق المشاريع، فالمقدمة نفسها تُستخدم كطاقة إضافية في حجة واحدة (عدد أقل من القائمين على الصيانة يمكنه تغطية شيفرة أكبر) وكعبء في الحجة التالية (فيضان من التقارير المولّدة يُغرق نظام التتبع)، ومقدمة تدعم نتيجة ونقيضها في آن واحد لا تؤدي أي وظيفة تحليلية حقيقية.
كيف تبدو المراجعة الفعلية لحوكمة المصادر المفتوحة؟
تشبه مراجعة الموردين تمامًا، لكنها موجهة طبقة واحدة إلى الأسفل، والسجل المقارن أعلاه يمنحك الأسئلة مباشرة.
وفي المنطقة، حيث تُبنى برامج تحول رقمي كبرى مثل رؤية السعودية 2030 واستراتيجية الإمارات للذكاء الاصطناعي على الطبقات التقنية نفسها مفتوحة المصدر، وتُلزم أطر مثل نظام حماية البيانات الشخصية السعودي (PDPL) المؤسسات بتقييم مخاطر مورديها، نادرًا ما يمتد ذلك التقييم إلى الأساس البرمجي الذي تقوم عليه الأنظمة أصلًا.
سياسة دورة حياة مكتوبة. هل تنشر الجهة القائمة على المشروع سياسة من الأساس؟ عقد الإشعار الكامل الذي حصلت عليه بايثون كان موجودًا لأن وثيقة PEP 373 كانت موجودة. أما النواة فلم يكن لديها وثيقة مماثلة لدعم العتاد، وهو ما أخبرك مسبقًا أن الإشعار سيكون مهما قررته قائمة البريد.
السجل والتوجه. حين أرجأت هذه الجهة موعدًا من قبل، في أي اتجاه تحرك؟ عدّلت بايثون لصالح المعتمدين عليها، بينما عدّلت CentOS ضدهم بما يعادل عقدًا كاملًا تقريبًا. آخر تعديل قامت به جهة ما هو أفضل مؤشر متاح على تعديلها القادم.
الإشعار المتسلسل. نافذة إشعارك الفعلية هي الحد الأدنى عبر السلسلة كاملة، لا الرقم المكتوب على الغلاف. التزم جدول Node 16 بموعده تمامًا إلى أن نفد جدول OpenSSL. حدد أي ساعات ترثها منصاتك من طبقات أعلى في السلسلة.
الحوكمة والتمويل. من يموّل الجهة القائمة على المشروع، وهل يستفيد ذلك التمويل حين تُضطر أنت إلى تحديث العتاد أو الانتقال لمنصة أخرى؟
التعرض للمخاطر ومسار الخروج. اعرف أي الميزات والمنصات وأجيال العتاد في منظومتك تقع ضمن منطقة «الإرث» المحتملة لدى الجهة القائمة على المشروع، وقيّم تكلفة التفريع (fork) أو التثبيت على إصدار محدد أو الانتقال الآن، بهدوء، لا في الربع الذي يصلك فيه قرار إيقاف الدعم. مسار خروج قيّمته مسبقًا هو النوع الوحيد الذي يقوّي موقفك التفاوضي.
لا شيء هنا غريب أو استثنائي. إنه نفس تحليل الحوافز الذي نطبقه في مراجعات الاستراتيجية التقنية، موجّهًا هذه المرة نحو طرف مقابل لم تفكر معظم المؤسسات يومًا في فحصه، وهو ما ينبغي أن يندرج ضمن خطة دورة الحياة نفسها المخصصة لـالمنصات التي تقوم عليها أعمالك. كما يتقاطع هذا مع انضباط سبق أن دعونا إليه في سياق الجاهزية لتبني الذكاء الاصطناعي: تُختبر الادعاءات قبل أن يتصرف أحد بناءً عليها، أيًا كان مصدرها، سواء من طبقة تقنية عليا أو من داخل مجلس إدارتك نفسه. الأساسات التي تقوم عليها منظومتك هي موردون بلا أي من التزامات المورّدين المعتادة. راجع الجهات القائمة على مشاريعك كما تراجع مورّديك تمامًا. فهي قادرة على تغيير قرارها، والتكلفة تقع عليك أنت.
أسئلة شائعة
كيف يمكنني معرفة ما إذا كان مشروع مفتوح المصدر أعتمد عليه قد يوقف دعمًا أحتاجه؟
راقب الجهة القائمة على المشروع، لا الشيفرة وحدها. غياب سياسة دورة حياة مكتوبة، وتحول التمويل وتركيبة مجلس الحوكمة نحو أولويات تجارية جديدة، ومناقشات إيقاف الدعم التي تُصاغ بوصفها «تقليلًا لعبء الصيانة»، وضعف تغطية القائمين على الصيانة لمسارات الشيفرة التي تستخدمها، كلها مؤشرات مبكرة. كان حذف دعم معالجات 486 معلنًا في نقاشات النواة قبل نحو ثلاث سنوات من صدوره فعليًا. تعامل مع خيوط الحوكمة العلنية لأي مشروع كما تتعامل مع تقارير الأرباح الفصلية لمورّد: مملة، وعلنية، وحافلة بالإشارات الدالة.
هل تشكّل تقارير الأخطاء المولّدة بالذكاء الاصطناعي خطرًا حقيقيًا على استقرار البرمجيات؟
نعم، وتجربة مشروع curl تكشف شكل هذا الخطر بوضوح: نسبة كبيرة من التقارير الأمنية الواردة أصبحت الآن مولّدة آليًا، ولم يثبت صحة أي منها تقريبًا. يكمن الخطر في عملية الفرز نفسها. فالعيب النظري المولّد آليًا دليل أضعف بكثير من عطل حقيقي واجهه مستخدم فعلي في بيئة الإنتاج، وأي مشروع يعامل الاثنين بالتساوي سينتهي به الأمر تدريجيًا إلى تصنيف شيفرة تعمل بكفاءة كعبء زائد. عند تقييم أي اعتماد تقني، اسأل عما إذا كانت عملية الفرز فيه تميّز بين التخمين المولّد آليًا والبلاغات البشرية الحقيقية.
ما الذي ينبغي أن تغطيه مراجعة حوكمة المصادر المفتوحة؟
أربعة عناصر: هل تنشر الجهة القائمة على المشروع سياسة دورة حياة، وكيف التزمت بمواعيدها أو عدّلتها في السابق (يتراوح المدى بين عقد كامل من الإشعار في حالة بايثون 2، وانهيار مهلة CentOS 8 من 2029 إلى نهاية 2021)؛ ومن يحكم الجهة القائمة على المشروع ويموّلها ووجهة إيراداتها المستقبلية؛ وخريطة لأي أنظمة لديك تعتمد على وظائف قد تُصنّف يومًا ما كإرث تقني، بما في ذلك نوافذ الإشعار الموروثة من طبقات أعلى في السلسلة؛ ومسار خروج مُقدّر التكلفة مسبقًا (تفريع، أو تثبيت إصدار، أو انتقال). جدّد هذه المراجعة سنويًا، لأن حوافز الجهات القائمة على المشاريع تتحرك أسرع من دورات التحديث.
مواضيع ذات صلة
- في أوبونتو 26.04 LTS، حزمة coreutils التي تعتمد عليها بنيتكم التقنية لم تعد GNU
- علاوة السيادة: لماذا تكسب حلول الذكاء الاصطناعي السيادي للمؤسسات الرهان على حرية الوصول لا على السرعة
- قضايا الأسرار التجارية تُحسم قبل سنوات من استقالة أي موظف. اسألوا شركة فاسيندا تشيكن
- Security & Trust
كُتب بواسطة شخصية تحريرية بالذكاء الاصطناعي ضمن نظام التحرير الخاص بـ Abyshire وروجع من فريقنا.