لماذا تساهم الشركات الكبيرة في المصادر المفتوحة، ولماذا نغيب نحن عنها؟

عندما تشغل سيرفراً بنظام Linux فأنت تستخدم نواة كتب جزءاً كبيراً من تعديلاتها في آخر إصدار موظفون في Intel وGoogle وRed Hat وAMD وQualcomm وNVIDIA وMeta، وعندما تنشر تطبيقك على Kubernetes فأنت تستخدم مشروعاً بدأ في Google ثم ساهمت فيه أكثر من ثمانية آلاف شركة. وهذا يطرح سؤالاً يبدو غريباً لمن يرى البرمجيات المفتوحة عملاً تطوعياً: لماذا تدفع شركة تبحث عن الربح رواتب مهندسين يكتبون كوداً يستطيع منافسها أن يأخذه مجاناً في اليوم التالي؟ وفي المقابل لماذا نادراً ما نرى اسم شركة من منطقتنا في قوائم من يكتبون هذا الكود، مع أننا من أكبر مستخدميه؟

هذا المقال رأي شخصي، ولكنه رأي يبدأ من الأرقام، فكل رقم فيه مربوط بمصدره وتاريخه، وما كان تحليلاً مني وليس حقيقة مثبتة فسوف أقول ذلك صراحة. وقد شرحنا في مقال حوكمة المشاريع مفتوحة المصدر كيف تدار المشاريع ومن يدفع لمشرفيها، ولن أعيد ذلك هنا، وإنما أسأل سؤالاً آخر: لماذا تساهم الشركات، وماذا نخسر عندما لا نساهم؟

وسوف نناقش في هذا المقال ما يلي:

• من يكتب نواة Linux وKubernetes فعلاً، بالأرقام من إحصاءات كل إصدار.
• ماذا تقدم كل شركة كبيرة، ومنها أمثلة من خارج الغرب، وأين يوجه الانتقاد.
• كيف تنظم الشركات ذلك من خلال مكتب المصادر المفتوحة OSPO.
• الأسباب السبعة التي تجعل الشركة تدفع، ولكل سبب مصدره.
• أرقام منطقتنا، وما قدمته فعلاً، ثم رأيي في سبب غيابنا وما يكلفنا.
• ما تستطيع شركتك أن تفعله في هذا الربع، مع نموذج قصير لسياسة المساهمة.

من يكتب نواة Linux فعلاً؟

ينشر موقع LWN بعد كل إصدار من نواة Linux إحصاءات يكتبها Jonathan Corbet، يعد فيها التعديلات Changesets التي دخلت الإصدار، ويوزعها على جهات عمل المطورين الذين كتبوها، وهذه الإحصاءات هي أوضح دليل متاح على من يدفع ثمن النواة. ففي إحصاءات الإصدار 7.2 المنشورة في 17 أغسطس 2026 دخل الإصدار 16,418 تعديلاً من 2,652 مطوراً، يعملون لدى 249 جهة استطاع الموقع أن يعرفها، وكانت أكبر الجهات Intel بنسبة 9.2% من التعديلات، ثم Google بنسبة 7.3%، ثم Red Hat بنسبة 5.3%، ثم AMD بنسبة 5.0% وQualcomm بنسبة 4.7%، ثم NVIDIA وMeta وSUSE وIBM وOracle وMicrosoft بنسب أقل.

ولاحظ أن الصورة لا تتغير كثيراً من إصدار إلى آخر، ففي الإصدار 7.1 في 15 يونيو 2026 كانت Intel أيضاً أكبر جهة معروفة بنسبة 9.1% ثم Google بنسبة 7.7%، وفي الإصدار 6.19 في 9 فبراير 2026 كانت Intel في المقدمة بنسبة 11.1%. وفي مقال الإصدار 6.18 المنشور في 1 ديسمبر 2025 جمع الموقع سنة كاملة من الإصدارات من 6.13 إلى 6.18، فكانت 80,035 تعديلاً من 5,275 مطوراً لدى 372 جهة، وفيها Intel بنسبة 11.0% ثم Google بنسبة 7.5% ثم Red Hat بنسبة 6.5%.

والأهم من ترتيب الشركات هو السطر الذي لا يحمل اسم شركة، وهو (None)، أي المطورون الذين لا يعملون لدى أي جهة ويساهمون بوقتهم الخاص. ففي إحصاءات الإصدار 2.6.24 المنشورة في 9 يناير 2008 كان هذا السطر في أول القائمة بنسبة 14.1%، وأمامه Red Hat بنسبة 10.4% وIBM بنسبة 8.2% وNovell بنسبة 6.8%، أما في الإصدار 7.2 فقد نزل إلى 4.5%. والصورة التالية تبين الإصدارين جنباً إلى جنب:

في الصورة أعلاه لاحظ التالي:

• السطر (Unknown) يعني أن LWN لم يعرف جهة عمل المطور، وقد ارتفع في الإصدار 7.2 إلى 16.7%، ويقول Corbet في المقال نفسه إن ذلك يعكس جزئياً تدفق مطورين جدد إلى مجتمع النواة، لذلك لا تحسبه على الشركات ولا على المتطوعين.
• إذا جمعت (Unknown) و(None) و(Consultant) في الإصدار 7.2 تحصل على 23.8%، أي أن 76% على الأقل من التعديلات جاءت من مطورين تعرف جهة عملهم، وهذه القسمة من حسابي وليست جملة في مقال LWN.
• الشركات التي في القائمة شركات شرائح Chips مثل Intel وAMD وQualcomm وNVIDIA، وشركات سحابة وخدمات مثل Google وMeta وMicrosoft، وشركات توزيعات مثل Red Hat وSUSE، ولكل نوع منها سبب مختلف للمساهمة كما سيأتي.

Kubernetes: من مشروع شركة واحدة إلى مشروع آلاف الشركات

النواة مشروع عمره أكثر من ثلاثين سنة، فلننظر إلى مشروع أحدث بدأ داخل شركة واحدة. فقد أعلنت CNCF في 17 ديسمبر 2015 أنها تتوقع أن يكون Kubernetes وetcd أول المشاريع التي تساهم بها الشركات فيها، وقالت Google في الإعلان نفسه إنها ستساهم بمشاريع مثل Kubernetes. وبعد ذلك بسبع سنوات نشرت CNCF تقرير مسيرة Kubernetes في 8 يونيو 2023، وفيه أن Google وRed Hat معاً كانتا تكتبان 83% من المساهمات قبل أن ينضم المشروع إلى CNCF في 2016، وأن حصتهما نزلت إلى 46%، وأن 8,012 شركة و77,115 شخصاً ساهموا في المشروع.

وتستطيع أن ترى الأرقام الحية في لوحة الشركات في CNCF DevStats، وهي لوحة تعد كل مساهمة في مستودعات Kubernetes من Commits وPull Requests ومراجعات وتعليقات وتنسبها إلى شركة صاحبها. وعندما قرأتها في أكتوبر 2026 كانت حصة Google من مساهمات آخر 12 شهراً 19.4%، ثم Red Hat بنسبة 9.6%، ثم Microsoft بنسبة 7.6%، ثم VMware بنسبة 3.2%، ثم IBM وAmazon وIntel وNVIDIA بأقل من 3% لكل منها، والنسب من قسمتي لعدد مساهمات كل شركة على المجموع الكلي بدون الحسابات الآلية Bots، والصورة التالية تجمع الرقمين:

والدرس هنا أن Google لم تخسر شيئاً عندما شاركت الآخرين في مشروعها، بل جعلت Microsoft وAmazon وRed Hat يدفعون رواتب مهندسين يطورون أداة تبيع Google خدمتها المدارة Managed Service في سحابتها، وهذا يقودنا إلى الأسباب، ولكن قبلها لنمر على الشركات واحدة واحدة.

وإذا أردت أن تعرف كيف تعمل المؤسسات التي تستضيف هذه المشاريع ومراحل النضج فيها، فقد شرحنا ذلك باختصار في قسم المؤسسات المحايدة، وفي المقالات التالية عن كل مؤسسة ومشاريعها:

دليلمشاريع Linux Foundation خارج CNCFكيف تحولت Linux Foundation إلى مظلة فوق OpenJS وPyTorch وOpenSSF وValkey وغيرها، ومن يمولها ويقرر فيها، وكيف تقارن بمؤسسات Apache وEclipse وPython.دليلمشاريع CNCF: خريطة أدوات Cloud Nativeماذا تعني مراحل Sandbox وIncubating وGraduated في CNCF، وما الذي يحله كل مشروع متخرج، وكيف يختار فريق صغير منها ما يحتاجه فقط.دليلمشاريع مؤسسة Apache: ماذا يحل كل مشروعكيف ترتب مشاريع مؤسسة Apache حسب المشكلة التي يحلها كل منها، وكيف تفحص صحة أي مشروع قبل أن تعتمد عليه.دليلمشاريع مؤسسة Eclipse: من Jakarta EE إلى Mosquittoما الذي تستضيفه مؤسسة Eclipse غير المحرر الذي تعرفه، ولماذا تغيرت حزم Java من javax إلى jakarta.

من يدفع؟ الشركات واحدة واحدة

Red Hat وIBM: كل المنتج يبدأ من المشروع الأصلي Upstream

Red Hat هي المثال الأوضح لشركة بنت عملها كله على المساهمة، فهي تقول في صفحة نموذج التطوير إنها تدعم المجتمعات بأن تساهم في الكود وتبني منتجاتها من المشاريع الأصلية، ثم تختبر هذه البرمجيات وتقويها وتدعمها لعملائها. لذلك تجد Red Hat ثالثة في النواة بنسبة 5.3% في الإصدار 7.2، وثانية في Kubernetes بنسبة 9.6%، وكانت مع IBM في أعلى قائمة النواة سنة 2008 كما رأيت في الصورة الأولى، وIBM اليوم هي الشركة الأم لـ Red Hat، وما زالت تظهر باسمها في القائمتين.

Google وMicrosoft: مستهلك ضخم يرد جزءاً مما يأخذ

Google ثانية في النواة وأولى في Kubernetes كما رأيت، ولديها سياسة مكتوبة لموظفيها في صفحة Open Source Patching تبدأ بجملة تقول إن المساهمة في المشاريع المفتوحة القائمة أمر مشجع عليه، وتسمح للموظف أن يرسل إصلاحه إلى أي مستودع عام برخصة من الأنواع المسموحة دون مراجعة مسبقة، بشرط أن يستخدم بريد الشركة وألا يطلب المشروع توقيع اتفاقية CLA غير موافق عليها مسبقاً، وسوف نعود لهذه السياسة في آخر المقال لأنها نموذج جيد لما تستطيع شركتك أن تكتبه.

أما Microsoft فتقول في صفحة برنامج المصادر المفتوحة إن مطوريها يستخدمون أكثر من 200,000 مكون مفتوح المصدر كل شهر، وإن أكثر من 70,000 مهندس فيها يستخدمون GitHub Enterprise Cloud لنشر مشاريعها المفتوحة، ويدير البرنامج مكتب للمصادر المفتوحة OSPO. وتظهر Microsoft في النواة بنسبة 3.0% في الإصدار 6.19، وفي Kubernetes بنسبة 7.6%، وهي التي بنت نظام الشبكات SONiC لمراكز بيانات Azure ثم نقلته إلى Linux Foundation في 14 أبريل 2022.

Meta: PyTorch وReact إلى مؤسسة محايدة

في 12 سبتمبر 2022 نقلت Meta مشروع PyTorch إلى مؤسسة جديدة تحت Linux Foundation، وكان في مجلس إدارتها عند التأسيس AMD وAWS وGoogle Cloud وMeta وMicrosoft Azure وNVIDIA، أي أن منافسي Meta صاروا شركاء في تمويل أداتها. ثم في 7 أكتوبر 2025 أعلنت Meta مؤسسة React تحت Linux Foundation أيضاً، والتزمت بشراكة لخمس سنوات فيها أكثر من 3 ملايين دولار ودعم هندسي، ومن أعضائها المؤسسين Amazon وMicrosoft وVercel. ولاحظ أن Meta كانت أكبر جهة في الإصدار 7.1 من النواة بعدد الأسطر المعدلة بنسبة 15.8%، مع أنها السابعة بين الشركات بعدد التعديلات.

ويجدر هنا أن أفرق بين PyTorch وLlama، فـ Meta تسمي نماذج Llama مفتوحة المصدر، ولكن مؤسسة OSI قالت في بيانها في 20 يوليو 2023 إن رخصة Llama 2 ليست مفتوحة المصدر، والسبب أنها تقيد الاستخدام التجاري لبعض المستخدمين وتمنع بعض أوجه الاستخدام، وقد شرحنا الفرق بين الرخص في مقال الرخص.

Intel وAMD وQualcomm وNVIDIA: الشريحة لا تباع بدون درايفر

شركات الشرائح هي أكبر كتلة في النواة اليوم، فـ Intel الأولى بين الجهات المعروفة في كل الإصدارات الأخيرة، وAMD كانت الأولى بعدد الأسطر المعدلة في الإصدار 7.2 بنسبة 22.4%، وتظهر Qualcomm وNVIDIA وArm وNXP وRenesas في القائمة نفسها. والسبب بسيط: المعالج أو بطاقة الرسوميات التي لا يعمل درايفرها في Linux يوم صدورها لن يشتريها أحد لسيرفراته، والدرايفر الذي يدخل النواة الرسمية يصونه معك كل من يغير الواجهات، كما سنرى في سبب المشروع الأصلي أولاً.

Huawei وAlibaba وغيرهما: المساهمة ليست غربية فقط

تظهر Huawei في قوائم النواة باستمرار، بنسبة 2.0% في الإصدار 7.0 و1.3% في الإصدار 7.1، وبنسبة 2.4% في سنة الإصدارات من 6.13 إلى 6.18، وفي الإصدار 7.2 ظهرت Kylin بنسبة 1.7%، وفي الإصدار 6.18 ظهرت شركة الهواتف vivo بنسبة 1.9%. أما Alibaba فقد ساهمت بمشاريع كاملة في مؤسسة Apache، فمشروع Dubbo دخل حاضنة Apache في 16 فبراير 2018 وتخرج منها في 15 مايو 2019، وتقول وثائق Apache RocketMQ إن المشروع ولد من أحمال التجارة الإلكترونية في Alibaba، وAlibaba أيضاً من الأعضاء الرئيسيين في مؤسسة SONiC. أما ByteDance وTencent فلم أجدهما في جداول أكبر الجهات التي راجعتها في LWN، ولن أدعي لهما أرقاماً لم أتحقق منها.

Oracle وDell: مساهمة حقيقية بحجم أصغر

Oracle حاضرة في النواة منذ 2008، بنسبة 2.4% في تلك السنة وبنسبة 1.5% في الإصدار 7.2 و2.4% في سنة 6.13 إلى 6.18. أما Dell فدورها أصغر وأكثر تركيزاً على عتادها، ومن الإنصاف أن أقول ذلك بدقة: فهي من الأعضاء الرئيسيين Premier Members في مؤسسة SONiC، وقال ممثلها في إعلان انتقال SONiC إنها من المساهمين الرئيسيين فيه، وفي ملف المشرفين MAINTAINERS في النواة مشرف واحد ببريد dell.com لدرايفر DELL WMI SYSMAN، وقائمة بريدية لـ Dell في ثمانية أقسام من درايفرات أجهزتها، بينما يصون أغلب درايفرات Dell أشخاص من خارجها. ولم تظهر Dell في أي جدول لأكبر الجهات في LWN، وأغلب مستودعاتها في حسابها في GitHub أدوات لمنتجاتها مثل سكربتات iDRAC ووحدات OpenManage لـ Ansible.

Amazon: أكبر مستفيد، والانتقاد الأشهر

تقول AWS في صفحتها للمصادر المفتوحة إنها تساهم في المجتمعات على المدى الطويل، وتذكر Kubernetes وOpenJDK وPostgreSQL وRust وValkey وKafka، ولكن الصفحة لا تذكر أرقاماً. والرقم المتاح من لوحة DevStats أن حصة Amazon من مساهمات Kubernetes في آخر سنة 1.9%، وهي أقل بكثير من Google وMicrosoft مع أن AWS تبيع خدمة Kubernetes المدارة، ولم تظهر Amazon في جداول التعديلات في LWN، وظهرت مرة واحدة في جدول الأسطر المعدلة في الإصدار 6.16 بنسبة 2.6%. وأشهر انتقاد لها كتبه Shay Banon مؤسس Elastic في مقاله في 19 يناير 2021 عندما غيرت Elastic رخصة Elasticsearch، واتهم فيه Amazon بأنها أطلقت في 2015 خدمة باسم Amazon Elasticsearch Service، وعد ذلك مخالفة واضحة للعلامة التجارية Trademark، ثم كتب الرجل نفسه في 29 أغسطس 2024 أن شراكة Elastic مع AWS صارت أقوى من أي وقت عندما أضافت Elastic رخصة AGPL. وفي 16 سبتمبر 2024 نقلت AWS مشروع OpenSearch إلى مؤسسة تحت Linux Foundation، وقصة تغيير الرخص هذه شرحناها في مقال الرخص.

كيف تنظم الشركة ذلك؟ مكتب المصادر المفتوحة OSPO

الشركات التي رأيتها أعلاه لا تترك المساهمة لمزاج كل مهندس، وإنما لديها مكتب للمصادر المفتوحة Open Source Program Office، واختصاراً OSPO، يكتب السياسة ويراجع الرخص ويوافق على المساهمات ويتابع ما تعتمد عليه الشركة، وقد شرحنا دوره في مقال الجامعات ومقال الجهات الحكومية. وفي تقرير حالة مكاتب المصادر المفتوحة لسنة 2023 الذي نشرته TODO Group مع Linux Foundation Research في سبتمبر 2023 أن 66% من المؤسسات المشاركة لديها مكتب OSPO أو مبادرة للمصادر المفتوحة، بعد أن كانت النسبة نحو 38% في المتوسط بين 2018 و2021، وأن المؤسسات التي لديها OSPO أكثر احتمالاً بنحو أربع مرات أن تساهم في المشاريع الأصلية.

ويجدر أن تقرأ ملاحظة صغيرة في التقرير نفسه، فالمنطقة التي يسميها Other، وأغلبها الشرق الأوسط وأفريقيا، كانت 4% فقط من المشاركين، أي أن منطقتنا غائبة حتى عن الاستبيانات التي تقيس هذا الموضوع، ولا يوجد في التقرير رقم خاص بها.

لماذا تدفع الشركات؟ سبعة أسباب

قد يتساءل البعض: هل هذا كرم من الشركات الكبيرة؟ والإجابة أن الكرم ليس تفسيراً كافياً لشركات مسؤولة أمام مساهميها عن الربح، والأسباب الحقيقية مكتوبة في كلام هذه الشركات نفسها، وفي ورقة من Harvard Business School صدرت في يناير 2024 تقدير لحجم المسألة، فالباحثون يقدرون القيمة التي يحصل عليها مستخدمو البرمجيات المفتوحة الأكثر استخداماً بنحو 8.8 تريليون دولار، ويقولون إن الشركات كانت ستنفق على البرمجيات 3.5 أضعاف ما تنفقه الآن لو لم تكن هذه البرمجيات موجودة. والصورة التالية تجمع الأسباب السبعة التي سنمر عليها، ومع كل سبب المثال الذي يثبته:

اجعل المكمل لمنتجك رخيصاً Commoditize Your Complement

كتب Joel Spolsky في 12 يونيو 2002 مقالاً بعنوان Strategy Letter V ما زال أفضل تفسير لهذا السلوك، وفكرته أن لكل منتج منتجات مكملة له، وأن الشركة الذكية تحاول أن تجعل المكمل رخيصاً ومتاحاً للجميع، لأن الطلب على منتجها يزيد كلما رخص المكمل، وذكر أن IBM تمول المصادر المفتوحة لأن عملها هو الاستشارات، فكلما رخص البرنامج زاد الطلب على من يركبه ويشغله. وبعد 22 سنة كتب Mark Zuckerberg في رسالته في 23 يوليو 2024 الفكرة نفسها بكلماته، فقال إن بيع الوصول إلى نماذج الذكاء الاصطناعي ليس نموذج عمل Meta، لذلك لا يضر نشر Llama بإيراداتها كما يضر بالشركات التي تبيع النماذج المغلقة، أي أن النموذج عند Meta مكمل لمنتجها وليس المنتج نفسه.

تقاسم تكلفة ما لا يميزك

أغلب ما تحتاجه الشركة من برمجيات لا يميزها عن منافسيها، فلا يختار العميل بنكاً لأن نواة سيرفراته أفضل، لذلك من المنطقي أن تتقاسم الشركات تكلفة هذه الطبقة بدلاً من أن تبنيها كل شركة وحدها. ومن أوضح الأمثلة مشروع Open Compute، فقد صممت Facebook في 2009 مركز بيانات من الصفر، وتقول صفحة المشروع إنه كان أكفأ في الطاقة بنسبة 38% وأرخص تشغيلاً بنسبة 24% من مراكزها السابقة، ثم نشرت التصاميم في 2011 لتصبح مؤسسة مفتوحة، وقال Zuckerberg في الرسالة نفسها إن Meta وفرت مليارات الدولارات لأن سلاسل التوريد صارت تصنع العتاد على تصاميمها.

المشروع الأصلي أولاً Upstream First

عندما تعدل مشروعاً مفتوحاً وتحتفظ بالتعديل عندك فأنت تتحمل وحدك تكلفة صيانته مع كل إصدار جديد، والوثيقة الرسمية في النواة The Linux Kernel Driver Interface تقول ذلك بوضوح: إذا كان لديك درايفر خارج النواة الرسمية فالحل أن تدخله فيها، لأن من يغير واجهة داخلية في النواة هو من يصلح الدرايفرات التي تتأثر بالتغيير، فيبقى درايفرك يعمل بجهد قليل منك، وتقول الوثيقة إن جودة الدرايفر ترتفع بينما تنخفض تكلفة صيانته على مطوره، ويضيف الآخرون إليه ميزات ويصلحون أخطاءه. وهذا هو السبب الذي يجعل Intel وAMD في أعلى القوائم، وهو أيضاً سبب اقتصادي بحت لا علاقة له بالكرم.

التوظيف والسمعة

المساهمة العامة سجل عمل يستطيع أي شخص أن يقرأه، فالمهندس الذي يراجع كوداً في Kubernetes أو يشرف على درايفر في النواة يعرف الجميع مستواه قبل المقابلة، والشركة التي يعمل فيها مشرفو المشاريع المعروفة تجذب من يريد أن يعمل معهم. ولم أجد دراسة حديثة تقيس هذا السبب بالأرقام كما في الأسباب الأخرى، لذلك أذكره هنا بوصفه تحليلاً، ويكفي أن ترى برامج مثل Google Summer of Code التي تدرب مساهمين جدداً كل سنة مع مشاريع مفتوحة.

التأثير في الاتجاه والمعايير

من يكتب الكود يقرر اتجاه المشروع، ففي المشاريع المفتوحة يصبح المساهم الدائم مراجعاً ثم مشرفاً Maintainer، ويصبح له صوت في القرار، وقد شرحنا هذا السلم في قسم الأدوار وسلم المساهمة. وفي تقرير OSPO لسنة 2023 كانت زيادة التأثير في المجتمعات المفتوحة من الفوائد التي ذكرتها 36% من المؤسسات التي لديها مكتب، وقال Zuckerberg في رسالته إن الطريق ليصبح Llama معياراً للصناعة Industry Standard أن يبقى مفتوحاً جيلاً بعد جيل. والمعيار الذي تشارك في كتابته يناسب منتجك، والمعيار الذي يكتبه غيرك تتكيف معه.

بيع الخدمة والسحابة فوقه

Red Hat لا تبيع كوداً وإنما تبيع الاشتراك والدعم والضمان فوق كود مفتوح، وشركات السحابة تبيع Kubernetes وPostgreSQL وOpenSearch خدمات مدارة، فكلما انتشر المشروع زاد عدد من يحتاج خدمتها. وهذا السبب نفسه هو مصدر الخلاف بين Elastic وAmazon الذي ذكرته أعلاه، فالشركة التي تبيع خدمة فوق مشروع لا تساهم فيه بقدر ما تأخذ منه تحصل على الربح ويتحمل غيرها التكلفة.

أمن سلسلة التوريد Supply Chain Security

عندما يكون في مكتبة يعتمد عليها نصف الإنترنت خطأ أمني، فكل شركة تستخدمها معرضة، لذلك صار تمويل أمن هذه المكتبات مصلحة مباشرة للشركات الكبيرة. فبعد ثغرة Heartbleed التي شرحنا سببها التقني في مقال الذاكرة أنشأت Linux Foundation في 2014 مبادرة Core Infrastructure Initiative وكان من أعضائها AWS وCisco وDell وFacebook وGoogle وIBM وIntel وMicrosoft، ومن المشاريع التي مولتها OpenSSL وOpenSSH. وبعد ثغرة Log4Shell التي شرحناها في مقال السجلات أعلنت OpenSSF في 1 فبراير 2022 مشروع Alpha-Omega باستثمار أولي من Microsoft وGoogle قدره 5 ملايين دولار، ثم في 12 مايو 2022 خطة بتمويل 150 مليون دولار على سنتين تعهدت فيها Amazon وEricsson وGoogle وIntel وMicrosoft وVMware بأكثر من 30 مليوناً. أما الدفاعات التقنية فقد شرحناها في مقال أمن سلسلة التوريد البرمجية، وقصة المشرف المرهق في XZ Utils في قسم من يدفع للمشرفين.

وأين نحن؟ الأرقام أولاً

قبل أن أقول رأيي سوف أعرض الأرقام، والسبب أن الحديث عن غياب المنطقة يتحول بسهولة إلى جلد للذات أو إلى إنكار، والأرقام تمنع الاثنين. وأول ما تقوله الأرقام أن عدد المطورين عندنا كبير ويكبر بسرعة، ففي بيانات GitHub Innovation Graph المفتوحة للربع الأول من 2026 بلغ عدد حسابات المطورين في مصر 1,626,418 بزيادة 43.9% عن الربع نفسه من 2025، وفي السعودية 988,061 بزيادة 47.2%، وفي المغرب 906,406 بزيادة 43.2%، وفي الإمارات 656,185 بزيادة 44.6%، بينما كانت الزيادة في الولايات المتحدة 25.4% وفي ألمانيا 31.2%. ولاحظ أن وثيقة البيانات تحدد موقع الحساب بعنوان IP، وتعد الحسابات التي لم تعد نشطة، لذلك هي مؤشر على الحجم وليست عداً دقيقاً للمطورين. وفي تقرير Octoverse لسنة 2024 ذكرت GitHub أن عدد المطورين في الإمارات زاد 32% في سنة واحدة، وفي تقرير 2025 أن منطقة أفريقيا والشرق الأوسط أضافت 3.4 مليون مطور.

وثاني ما تقوله الأرقام أن هذا العدد الكبير لا يظهر في المشاريع التي تبني البنية التحتية، ففي لوحة الدول في CNCF DevStats حتى 1 أكتوبر 2026 عدد من ساهموا في Kubernetes منذ بدايته من السعودية 26 شخصاً بمجموع 266 مساهمة، منهم 5 فقط فتحوا Pull Requests، ومن مصر 73، ومن الإمارات 63، بينما من ألمانيا 2,915 ومنهم 988 فتحوا Pull Requests. وهذه الأرقام لا تحسب إلا من كتب موقعه في حسابه، لذلك هي حد أدنى، ولكن الفرق أكبر من أن يفسره هذا وحده. وفي لوحة الشركات من بين نحو 3,550 شركة يظهر اسمان يبدوان من المنطقة، Elm Company بـ 90 مساهمة في المرتبة 983 تقريباً، وEmirates NBD بـ 47 مساهمة. أما في إحصاءات النواة فلم تظهر أي شركة من المنطقة في جداول أكبر الجهات في أي من مقالات LWN التي راجعتها من الإصدار 2.6.24 إلى 7.2، مع التنبيه أن هذه الجداول تذكر أكبر عشرين جهة فقط.

والصورة التالية تضع الرقمين معاً، فتقسم عدد حسابات المطورين في كل دولة على عدد من ساهموا منها في Kubernetes، وكلما طال الشريط زاد عدد من يستخدمون مقابل كل من يساهم:

في الصورة أعلاه لاحظ التالي:

• القسمة تجمع مصدرين مختلفين في طريقة تحديد الموقع، لذلك لا تقرأ الأرقام بدقة الآحاد، وإنما اقرأ الفرق في الحجم: في ألمانيا مساهم لكل 1,803 حسابات تقريباً، وفي السعودية مساهم لكل 38,002.
• تونس والإمارات أقرب إلى الهند وتركيا منها إلى بقية المنطقة، وهذا يعني أن الفجوة ليست قدراً ثابتاً على المنطقة كلها.
• Kubernetes مشروع واحد، ولكنه مشروع تستخدمه شركاتنا وجهاتنا كثيراً، لذلك هو مقياس مناسب لسؤال: هل نساهم فيما نستخدم؟

ما قدمته المنطقة فعلاً

ومن الإنصاف أن أذكر ما قدمته المنطقة، وهو ليس قليلاً. فقد نشر المركز الوطني للذكاء الاصطناعي في سدايا نموذج ALLaM-7B بأوزان مفتوحة برخصة Apache 2.0، ونشرت Inception مع جامعة محمد بن زايد MBZUAI وCerebras نماذج Jais برخصة Apache 2.0، وتحول نموذج Falcon 40B من معهد الابتكار التكنولوجي TII في أبوظبي إلى رخصة Apache 2.0 في 31 مايو 2023، أما نماذج Falcon اللاحقة فقد صدرت برخص خاصة من TII مبنية على Apache 2.0 مع تعديلات، فهي ليست مفتوحة المصدر بتعريف OSI. وفي معالجة اللغة نشر مختبر CAMeL في جامعة نيويورك أبوظبي CAMeL Tools برخصة MIT، بينما Farasa من معهد قطر لبحوث الحوسبة QCRI متاحة للأغراض البحثية فقط، وقد قارنا هذه الأدوات والنماذج ورخصها في مقال معالجة اللغة العربية.

وفي الترجمة مثال يستحق أن يذكر، ففريق العربية في KDE أنهى 99.77% من نصوص الواجهات في فرع KF6 بحسب صفحة الإحصاءات في 8 أكتوبر 2026، وترتيبه العاشر في قائمة الفرق متقدماً على الفرنسية والألمانية. وعلى مستوى السياسات أصدرت المملكة قواعد ملزمة للبرمجيات الحكومية مفتوحة المصدر ومنصة لإيداعها وإعادة استخدامها، وقد شرحتها في قراءة القواعد والاستراتيجية وكتبت رأيي في مستقبلها في مقال سابق.

ولكن لاحظ أن أغلب هذه الأمثلة نشر لمشاريع نملكها، من نماذج وأدوات ومنصات، وهذا جيد ومطلوب، أما المساهمة في المشاريع التي يملكها الجميع ونعتمد عليها كل يوم، مثل النواة وKubernetes وPostgreSQL، فهي التي تكاد تغيب، وهي موضوع هذا المقال.

رأيي: نشتري وندمج ولا نبني

ما يلي في هذا القسم تحليلي الشخصي لأسباب الأرقام السابقة، وليس نتيجة دراسة منشورة، فلا أملك أرقاماً تثبت كل سبب منها، وأكتبها لأنها ما أراه، وأرحب بمن يصححها بأرقام. وخلاصة رأيي أن السوق التقني في منطقتنا بني في أغلبه على شراء البرمجيات ودمجها Integration، وليس على بنائها، ومن يشتري ويدمج لا يحتاج أن يساهم، فلا تتكون عنده ثقافة إرسال التعديل إلى المشروع الأصلي، وبالتالي لا يتكون عنده مهندسون مرجعيون يفهمون المشروع من داخله، ولا يكون له صوت في قراره. والصورة التالية تبين الحلقتين:

وأرى أن هذه الحلقة تستمر لخمسة أسباب، وكلها أسباب في طريقة عمل المؤسسات وليست في قدرة المهندسين، فالمهندس العربي الذي ينتقل إلى شركة تساهم يساهم مثل غيره:

• نماذج الشراء Procurement: أغلب العقود تشتري نتيجة جاهزة بتاريخ تسليم، ولا يوجد فيها بند يسمح للمورد أو للفريق الداخلي أن يصرف وقتاً على إرسال الإصلاح إلى المشروع الأصلي، فيبقى الإصلاح في نسخة خاصة، وقد بدأت القواعد الحكومية السعودية تغير هذا في جانب ملكية الكود.
• التسليم القصير المدى: المشروع يقاس بموعد إطلاقه، وتكلفة صيانة التعديل الخاص بعد سنتين لا تظهر في ميزانية أحد، مع أنها كما رأيت في وثيقة النواة أكبر من تكلفة إرساله الآن.
• قلة شركات المنتجات: الشركة التي تبيع منتجاً تعيش عليه سنوات تحتاج أن تؤثر في المشاريع التي يقف عليها منتجها، أما شركة المشاريع التي تنتقل من عميل إلى عميل فلا تجد هذه الحاجة.
• التوظيف بالشهادات: عندما تطلب إعلانات الوظائف شهادات المورد ولا تسأل عن مساهمات المرشح العامة، فلن يجد المهندس سبباً مهنياً ليساهم.
• غياب مكتب OSPO: لا يوجد في أغلب المؤسسات شخص يملك قرار السماح بالمساهمة، فيخاف المهندس أن يرسل كوداً كتبه في وقت العمل، لأن أحداً لم يقل له إن ذلك مسموح.

ماذا يكلفنا ذلك؟

قد يتساءل البعض: ما المشكلة إذا كانت البرمجيات تعمل ونحن نستخدمها مجاناً؟ والإجابة أن هناك ثمناً ندفعه حتى لو لم يظهر في الفاتورة، وأراه في أربعة أشياء:

1. لا توجد خبرة مرجعية محلية: عندما يتعطل نظام حرج مبني على مشروع مفتوح، فلا يوجد في المنطقة غالباً من يعرف كود المشروع من داخله، فننتظر المورد الأجنبي أو المجتمع، وهذا هو الارتهان للمورد Vendor Lock-in نفسه الذي أردنا أن نخرج منه بالمصادر المفتوحة.
2. لا صوت لنا في القرار: القرارات في المشاريع يتخذها المشرفون والمراجعون كما شرحنا في قسم اتخاذ القرار، ومن لا يساهم لا يصل إلى هذه الأدوار، فتبنى الميزات لاحتياجات غيرنا.
3. دعم أضعف للعربية: وهذا يظهر في الأرقام، فواجهة GNOME 51 مترجمة إلى العربية بنسبة 44% بينما الفرنسية والتركية والفارسية 100%، وFirefox لسطح المكتب مترجم إلى العربية بنسبة 81.1% في منصة Pontoon، وصفحات الدعم في مشاريع Mozilla بنسبة 24.6%، بينما الفارسية والتركية والفرنسية قريبة من الاكتمال. ومثال KDE أعلاه يثبت أن فريقاً صغيراً مستمراً يستطيع أن يغير هذه الأرقام.
4. تكلفة النسخ الخاصة: كل تعديل نحتفظ به في نسخة خاصة نعيد تطبيقه مع كل تحديث، أو نتوقف عن التحديث، والثاني أخطر لأنه يبقي الثغرات المعروفة في أنظمتنا، وقد شرحنا في مقال الجهات الحكومية لماذا يجب أن ترسل الجهة إصلاحاتها إلى المشروع الأصلي.

ماذا تستطيع شركتك أن تفعل في هذا الربع؟

لا تحتاج شركتك أن تصبح Red Hat حتى تبدأ، وإنما تحتاج قرارات صغيرة يملكها مدير واحد، وفيما يلي ما أقترحه لثلاثة أشهر:

1. مكتب OSPO مصغر: كلف شخصاً واحداً بجزء من وقته، مهندساً أول Senior Engineer يفهم الرخص، ليجمع قائمة المشاريع المفتوحة التي تعتمد عليها أنظمتكم الحرجة، ومن يصونها، وهل لها عامل حافلة Bus Factor واحد، واستخدم قائمة التحقق في مقال الحوكمة.
2. اسمح للموظفين بإرسال الإصلاحات: اكتب سياسة قصيرة مثل سياسة Google التي ذكرتها أعلاه، تسمح بإرسال الإصلاح إلى أي مشروع برخصة معروفة دون موافقة مسبقة، وتطلب المراجعة فقط عندما يطلب المشروع اتفاقية CLA، وقد شرحنا الفرق بين DCO وCLA في قسم DCO أم CLA.
3. أرسل أول ثلاثة إصلاحات: ابحث في مستودعاتكم عن التعديلات التي طبقتموها على مشاريع مفتوحة واحتفظتم بها، واختر أصغرها وأرسله بطريقة المشروع، كما في قسم أول مساهمة لك خطوة بخطوة.
4. ادفع لمشرف مشروع تعتمد عليه: اختر مكتبة واحدة يعتمد عليها منتجكم ويصونها شخص أو شخصان، وادعمه بمبلغ شهري عبر GitHub Sponsors أو Open Collective، وهذا أرخص من يوم توقف واحد.
5. الترجمة العربية في المشروع الأصلي: إذا كان منتجكم يعدل ترجمة مشروع مفتوح إلى العربية، فأرسل الترجمة إلى فريق العربية في المشروع، في GNOME أو Mozilla أو غيرهما، بدلاً من أن تبقيها في نسخة خاصة تعيد ترجمتها مع كل إصدار.
6. قس النتيجة: في آخر الربع اعرف عدد ما دمج من مساهماتكم في المشاريع الأصلية، وليس عدد ما أرسل، لأن المساهمة التي لا تدمج لم تخفف عنكم شيئاً.

والنموذج التالي سياسة قصيرة للمساهمة تستطيع أن تبدأ بها وتعدلها مع فريقكم القانوني، وقد كتبتها على صفحة واحدة عمداً، لأن السياسة الطويلة لا يقرؤها أحد:

سياسة المساهمة في المشاريع مفتوحة المصدر (الإصدار 1)

1. الهدف
   نشجع الموظفين على إرسال الإصلاحات والتحسينات إلى المشاريع
   مفتوحة المصدر التي نعتمد عليها، لأن ذلك يقلل تكلفة صيانتها علينا.

2. ما لا يحتاج موافقة مسبقة
   - إصلاح خطأ أو تحسين توثيق أو ترجمة في مشروع عام
   - برخصة من القائمة المعتمدة: MIT, BSD, Apache-2.0, MPL-2.0, LGPL, GPL
   - في مشروع يطلب DCO (التوقيع بـ git commit -s) أو لا يطلب شيئاً

3. ما يحتاج موافقة مكتب المصادر المفتوحة (OSPO)
   - مشروع يطلب توقيع اتفاقية CLA
   - نشر مشروع جديد من كود الشركة
   - أي كود يمس أسرار العمل أو بيانات العملاء أو مفاتيح الوصول

4. القواعد
   - استخدم بريد الشركة في المساهمات التي تكتبها في وقت العمل
   - لا ترسل أي سر أو بيانات عميل أو عنوان داخلي في الكود أو الرسائل
   - اتبع ملف CONTRIBUTING وقواعد السلوك في المشروع
   - الثغرات الأمنية تبلغ بالطريقة المذكورة في SECURITY.md وليس في Issue عام

5. المسؤوليات
   - مكتب OSPO: يحدث القائمة المعتمدة ويرد على الطلبات خلال 5 أيام عمل
   - المدير المباشر: يسمح بوقت للمساهمة ضمن خطة الفريق
   - الموظف: يسجل رابط كل مساهمة مدمجة في السجل الداخلي

6. المراجعة
   تراجع هذه السياسة كل 6 أشهر.

في النموذج أعلاه لاحظ التالي:

• البند الثاني هو الأهم، لأنه يحول الأصل من المنع إلى السماح، فالمهندس الذي يحتاج موافقة على إصلاح من ثلاثة أسطر لن يرسله.
• البند الثالث يحصر المراجعة في الحالات التي فيها خطر قانوني حقيقي، مثل CLA التي قد تنقل حقوقاً أوسع من DCO.
• الرد خلال 5 أيام عمل في البند الخامس رقم أقترحه أنا، والمهم أن تكتب مدة محددة حتى لا تموت الطلبات في البريد.
• قائمة الرخص في البند الثاني مثال، فراجعها مع فريقكم القانوني قبل اعتمادها، وخاصة الرخص من نوع Copyleft التي شرحناها في مقال الرخص.

الخلاصة

• أغلب نواة Linux اليوم يكتبها موظفون مدفوعو الأجر، فحصة من لا يعملون لدى أي جهة نزلت من 14.1% في 2008 إلى 4.5% في الإصدار 7.2، وKubernetes الذي بدأ في Google تكتب Google وRed Hat اليوم أقل من نصفه.
• الشركات تساهم لأسباب اقتصادية مكتوبة في كلامها: تجعل المكمل لمنتجها رخيصاً، وتتقاسم تكلفة ما لا يميزها، وتخفض تكلفة الصيانة بإرسال التعديل إلى المشروع الأصلي، وتؤثر في الاتجاه، وتبيع الخدمة فوقه، وتحمي سلسلة التوريد.
• عدد المطورين في منطقتنا كبير وينمو أسرع من أمريكا وألمانيا، ولكن من يساهم منهم في مشروع مثل Kubernetes قليل جداً، ولا تظهر أي شركة من المنطقة في جداول أكبر الجهات في النواة.
• في رأيي أن السبب في طريقة عمل المؤسسات، من شراء ودمج وعقود قصيرة وغياب OSPO، وليس في قدرة المهندسين، والثمن غياب الخبرة المرجعية والصوت في القرار ودعم أضعف للعربية.
• ابدأ هذا الربع بسياسة مساهمة من صفحة واحدة، وشخص يملك القرار، وثلاثة إصلاحات ترسلها إلى المشاريع الأصلية.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وقراءة إحصاءات LWN للإصدارات من 2.6.24 إلى 7.2، ولوحات CNCF DevStats للشركات والدول، وبيانات GitHub Innovation Graph للربع الأول من 2026، وإحصاءات الترجمة العربية في KDE وGNOME وMozilla.