من يموّل مطوّري المصدر المفتوح؟ سؤال سلسلة التوريد الذي تتجاهله إدارة المشتريات
تراجعون بدقة كل مورّد تجاري تتعاملون معه، لكن لا أحد يراجع من يموّل الأشخاص الذين يصونون مكتبات المصدر المفتوح التي يرتكز عليها نظامكم التقني بالكامل. هذه الفجوة تزداد كلفة.
تراجع إدارة المشتريات لديكم بدقة من يملك مزوّد إدارة علاقات العملاء، وأين تُخزَّن بياناته، وماذا يحدث لعقدكم إذا استحوذت شركة أخرى عليه. اسألوا الفريق نفسه من يموّل الشخص الذي يصون مكتبة تحليل نصوص صغيرة مدفونة في طبقات ثلاث داخل بنية برمجياتكم، وستُقابَلون بنظرة فارغة. تخيّلوا هذه المكتبة الواحدة مثالاً يمثّل عشرات المكتبات المماثلة التي تشحنونها دون تفكير. لا أمر شراء، لا توقيع، لا مدير حساب. وصلت مجاناً، فلم تحصل يوماً على عمود مخاطر خاص بها.
هذا هو الخطأ. المكتبة مجانية بالنسبة لكم، لكنها مكلفة الإنتاج. شخص ما يقضي أمسياته، أو بات يقضي أيام عمله المدفوعة بشكل متزايد، في إبقائها حية. تتبّعوا ذلك الراتب وستصلون إلى السؤال الحقيقي المختبئ تحت شجرة الاعتماديات لديكم.
لماذا تُعدّ جهة تمويل مشروع مفتوح المصدر مخاطرة في سلسلة التوريد؟
النموذج المعتاد لمخاطر المصدر المفتوح يدور حول الشيفرة. هل توجد ثغرة معروفة؟ هل الترخيص متوافق؟ هل المشروع مهجور؟ كلها أسئلة مشروعة، وكلها قابلة للإجابة عبر أداة فحص آلية. لكنها تشترك في افتراض واحد: أن الخطر يكمن في الأداة الموجودة بين أيديكم بالفعل.
الخطر الذي تغفله أداة الفحص يكمن في الأشخاص الذين يقرّرون محتوى الإصدار التالي. الاعتمادية الواحدة تيار من القرارات المستقبلية التي يتخذها من يملك صلاحية التعديل على الشيفرة، ولهذه القرارات مدخلات. أحد أكبر هذه المدخلات هو مَن يدفع راتب متخذ القرار.
لسنوات، كانت الإجابة الصادقة عن سؤال «من يدفع» هي «لا أحد، والنتيجة واضحة». مشرف واحد يعمل بلا أجر، منهك، يرقّع مكتبة يعتمد عليها نصف الإنترنت. كانت تلك مشكلة موارد لها حل واضح: ادفعوا لهؤلاء الأشخاص أجورهم.
اليوم، أصبحوا يتقاضون أجورهم بالفعل، لكن ليس منكم. وهذا لا يُغلق المشكلة، بل يعيد تشكيلها.
حين لا يكون الممول هو المستخدم
هذه هي الآلية: حين يأتي دخل المشرف من المستخدمين المعتمدين على البرمجية، يتجه الحافز نحو الاستقرار. عطّلوا الأداة التي يعتمد عليها هؤلاء المستخدمون ويتوقّف المال. حلقة التغذية الراجعة هنا مُحكَمة، وتصبّ في صالح من يشغّل الشيفرة في بيئة الإنتاج.
حين يأتي الدخل من مؤسسة، أو برنامج شركة كبرى، أو زمالة حكومية، تنحرف تلك الحلقة عن مسارها. من يوقّع الشيك له أولوياته، ومن حقه أن تكون له: الأمن، الاستدامة، سلامة المجتمع البرمجي، السيادة الرقمية، أياً كانت مهمته المعلنة. تتحوّل تلك الأولويات إلى مدخل في خارطة طريق اعتمادية يبني عليها آلاف الشركات، ولم تُستشر أي منها، لأن أياً منها لم يعد الزبون.
هذه مؤسسات حقيقية بمهام معلنة، ويستحق الأمر قراءتها. صندوق التقنية السيادية الألماني (Sovereign Tech Fund)، المدعوم من وزارة الاقتصاد الاتحادية، يستثمر في البنية الرقمية المفتوحة خدمةً للمصلحة العامة، وقد ضخّ أموالاً في curl وOpenSSL وGnuPG وPHP وsystemd وأجزاء من منظومة Rust. أما مبادرة Alpha-Omega، التابعة لمؤسسة أمن المصدر المفتوح ضمن مؤسسة Linux والممولة من مايكروسوفت وجوجل وأمازون، فهدفها تحسين الوضع الأمني للمشاريع الحرجة، وقد موّلت مؤسسة Python البرمجية، ومؤسسة Rust، وNode.js، ومؤسسة Eclipse. اقرأوا المهمتين جنباً إلى جنب، وسيتضح النمط: الأمن، والمرونة، والسيادة. أهداف منطقية جميعها. لكنها أيضاً أهداف طرف آخر، لا أهدافكم، مرتبطة تحديداً بالمكتبات الموجودة في قاع بنيتكم التقنية.
التمويل المؤسسي لمطوّري المصدر المفتوح، في مجمله، تطوّر إيجابي. فبنية تحتية حرجة تعاني نقص التمويل حالة أسوأ من بنية تحتية حرجة ممولة. ومع ذلك، فمن يدفع يضع الأجندة، وحين يتوقف الدافع عن كونه المستخدم، تنجرف الأجندة بعيداً عن استقرار تشغيل المستخدم نحو مهمة الممول المعلنة، أياً كانت نيته. هذا الانحراف لا يظهر أبداً في نتائج فحص الاعتماديات. ومن الأمانة توضيح طبيعة هذا الطرح: إنه آلية يجدر ترقّبها، مبنية على تحليل الحوافز، لا قضية موثقة بملف عام جاهز تقدّمونه لمن يشكّك. سبب المراقبة بسيط: الحوافز تسير في هذا الاتجاه بالفعل.
هل سبق أن أثّر تحوّل في أولويات المنبع على الفرق في المصب؟
حدث ذلك، أو على الأقل هناك حلقة واحدة تُقرأ على هذا النحو، ومكتبة OpenSSL أوضح مثال عليها، يُطرح كتوضيح لا كدليل قاطع. بعد أن كشفت ثغرة Heartbleed عام 2014 عن هشاشة تمويل المكتبة، تدفقت عليها أموال مؤسسية جادة عبر مبادرة البنية التحتية الأساسية التابعة لمؤسسة Linux، بدعم من أمازون وجوجل وIBM وإنتل ومايكروسوفت. وبفضل هذا التمويل وإعادة الهيكلة، خاض المشروع عملية إعادة بناء معمارية كبرى صدرت كإصدار OpenSSL 3.0 عام 2021، بنظام «مزوّدين» جديد ووحدة FIPS موجّهة تحديداً لمستخدمي الامتثال التنظيمي. كما أوقف الإصدار الجديد العمل بقائمة طويلة من الواجهات البرمجية وجاء مصحوباً بتراجع في الأداء أمضت المشاريع التابعة له شهوراً في تشخيصه ومعالجته. لم يتصرف أحد بسوء نية. التسلسل الزمني موثّق؛ أما قراءة أن أولويات الممول هي من صاغته فهي قراءتي، لا استنتاج السجل نفسه. ظهور مجموعة ميزات موجّهة للامتثال بالتزامن مع إعادة هيكلة ممولة يتّسق، في أقل تقدير، مع تلك القراءة، وقد دفع الجميع في المصب فاتورة الترحيل.
من المنحة العرضية إلى المدخل البنيوي
ما يجعل هذا الأمر جديراً بالطرح الآن هو الحجم والبنية. كان تمويل المشرفين في الماضي عرضياً وشخصياً: صندوق تبرعات، منحة لمرة واحدة، شركة ترعى الأداة التي يعتمد عليها فريقها. التمويل العرضي يشتري نفوذاً عرضياً، وهو ضجيج يمكن تجاهله.
طبيعة المال تتغير. برامج الشركات، والمؤسسات الخيرية، والمبادرات المدعومة حكومياً، تتعامل بشكل متزايد مع المكتبات التأسيسية بوصفها بنية تحتية عامة تستحق تمويلاً متعدد السنوات. الاتجاه المرجّح، وهذا استشراف لا حقيقة مستقرة، هو أن يتجه هذا المال المنظّم نحو مشرفي المنظومات التأسيسية: بيئات تشغيل اللغات البرمجية والمكتبات القياسية التي يقوم عليها كل شيء آخر. حين يصل التمويل المنظّم والمتكرر إلى قاعدة البنية بدلاً من أطرافها، يشتري نفوذاً منظّماً ومتكرراً، وتتوقف أولويات الممول عن كونها ضجيجاً وتبدأ في التسرب صعوداً عبر كل ما يُبنى فوقها.
كلما طالت المدة التي تخططون خلالها لتشغيل بنيتكم التقنية الحالية، زاد رهانكم على أولويات منبع يحددها، على مدى السنوات القادمة، أشخاص لم تفحصوا حوافزهم يوماً.
كيف تُجرون فحص العناية الواجبة على اعتمادية لم تشتروها؟
لا يمكنكم فحص مشروع مفتوح المصدر بالطريقة نفسها التي تفحصون بها مورّداً تجارياً. لا عقد، لا مدير حساب، لا تعويض خدمة حين يسوء الأمر. لكن غياب العقد يستدعي نوعاً مختلفاً من التدقيق، لا غيابه بالكامل.
ابدأوا بمشرفي الاعتماديات الحرجة فعلاً لديكم، تلك الحفنة التي سيضركم فعلاً أي تحوّل مفاجئ في اتجاهها. لكل واحدة منها، اطرحوا ثلاثة أسئلة مباشرة. من يموّل حالياً المشرفين الرئيسيين؟ ما المهمة المعلنة لهذا الممول؟ وما خطتكم البديلة إذا تباعدت تلك المهمة عن احتياجاتكم: نسخة متفرّعة يمكنكم تبنّيها، نسخة مجمّدة محفوظة لديكم، بديل تجاري يمكنكم شراؤه؟ بناء خريطة واضحة لاعتمادياتكم الحرجة وحوكمتها عمل غير براق، ويبدو اختيارياً فقط حتى الأسبوع الذي يتوقف فيه عن ذلك.
الانضباط نفسه يصبح أكثر إلحاحاً حين تبدأ أنظمتكم بالتصرف من تلقاء نفسها. فمع انتقال الأنظمة العميلة إلى صلاحيات فعلية، ترث مكونات المصدر المفتوح بداخلها أي مخاطرة حوكمة كامنة خلف مشرفيها، وترثها بسرعة الآلة. تحوّل في الأولويات كان بإمكانكم امتصاصه يدوياً في السابق يصبح تحوّلاً تنشره أتمتتكم قبل أن يقرأ أحد سجل التغييرات.
لا شيء هنا يدعو إلى تجنّب المصدر المفتوح الممول؛ فالممول أفضل من المهجور. الخطوة المطلوبة هي تسعير مخاطرة تتحملونها مجاناً حالياً. الشيفرة لم تكن يوماً كامل المخاطرة. ما يحدد اتجاهها هو حافز الإنسان الذي يكتبها، وذلك الحافز يخضع الآن لجهة تمويل لم تقابلوها قط.
أسئلة شائعة
هل ينبغي أن نتوقف عن استخدام مشاريع مفتوحة المصدر تتلقى تمويلاً حكومياً أو من شركات كبرى؟
لا. الصيانة الممولة أكثر أماناً عموماً من الصيانة غير الممولة والمنهكة. ما يهم هو الوعي: اعرفوا من يموّل اعتمادياتكم الحرجة، واحتفظوا بخطة بديلة جاهزة ليوم تتباعد فيه أولويات الممول عن احتياجاتكم.
كيف نعرف من يموّل مشرفاً معيناً في مشروع مفتوح المصدر؟
ابدأوا بصفحات التمويل والرعاية الخاصة بالمشروع نفسه، والمؤسسة الحاكمة له إن وجدت، وأي سجلات منح أو زمالات منشورة. قارنوا ذلك بأسماء المشرفين الذين يدمجون التعديلات فعلياً. وحيث يكون الأمر غامضاً، اعتبروا الغموض نفسه إشارة المخاطرة.
ما الفرق بين مخاطرة الشيفرة ومخاطرة الحوكمة في المصدر المفتوح؟
مخاطرة الشيفرة تتعلق بالأداة الموجودة بين أيديكم بالفعل: الثغرات، والتراخيص، ومدى استمرار صيانة المشروع. أما مخاطرة الحوكمة فتتعلق بالقرارات المستقبلية: من يملك صلاحية التعديل، ومن يدفع له، وأي أولويات تشكّل الإصدار التالي. أدوات الفحص ترصد الأولى وتعمى تماماً عن الثانية.
مواضيع ذات صلة
- في أوبونتو 26.04 LTS، حزمة coreutils التي تعتمد عليها بنيتكم التقنية لم تعد GNU
- علاوة السيادة: لماذا تكسب حلول الذكاء الاصطناعي السيادي للمؤسسات الرهان على حرية الوصول لا على السرعة
- قضايا الأسرار التجارية تُحسم قبل سنوات من استقالة أي موظف. اسألوا شركة فاسيندا تشيكن
- Security & Trust
كُتب بواسطة شخصية تحريرية بالذكاء الاصطناعي ضمن نظام التحرير الخاص بـ Abyshire وروجع من فريقنا.