> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# من يدير المشروع مفتوح المصدر؟ نماذج الحوكمة Governance
- URL: https://arabroot.io/articles/حوكمة-المشاريع-مفتوحة-المصدر-والمساهمة-فيها/
- Published: 2026-10-05T19:15:00.000Z
- Updated: 2026-10-09T09:42:49.000Z
- Description: من يقرر في مشروع يساهم فيه آلاف الأشخاص، ومن يستطيع تغيير رخصته، وما الذي تفحصه قبل أن تعتمد على أي مشروع.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, المصادر المفتوحة, السيادة الرقمية والامتثال, الاستضافة الذاتية, أساسيات, سياسات المصادر المفتوحة

في مقال [البرمجيات مفتوحة المصدر وتراخيصها](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/) رأينا كيف غيرت شركات معروفة رخص مشاريعها، وكيف رد المجتمع ببناء نسخ بديلة خلال أيام، وقد يتساءل البعض بعد قراءة تلك القصص: من الذي يملك أصلاً أن يغير رخصة مشروع يساهم فيه آلاف الأشخاص؟ ومن يقرر أي ميزة تدخل وأي طلب دمج يرفض؟ ومن يمنع شخصاً يسيء للآخرين في النقاشات؟ والإجابة على هذه الأسئلة كلها هي ما يسمى حوكمة المشروع Project Governance، أي القواعد المكتوبة وغير المكتوبة التي تحدد من يقرر وكيف يقرر ومن يحاسب من، وهي تختلف كثيراً بين مشروع يديره شخص واحد في وقت فراغه ومشروع تستضيفه مؤسسة تمثل مئات الشركات.

وهذا الموضوع لا يهم المساهمين وحدهم، فإذا كانت شركتك أو جهتك تعتمد على أداة مفتوحة المصدر في عمل حرج، فطريقة إدارة هذه الأداة تحدد هل سوف تبقى حية بعد خمس سنوات، وهل تتغير رخصتها فجأة، وهل يصلح أحد ثغراتها عندما تظهر. وإذا كنت تبحث عن حوكمة لغات البرمجة تحديداً، أي من يقرر مستقبل Python وJava وJavaScript، فقد شرحناها في قسم [من يقرر مستقبل اللغة؟](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%87%D8%A7-%D9%88%D8%AD%D9%88%D9%83%D9%85%D8%AA%D9%87%D8%A7/#governance) في مقال مواصفات لغات البرمجة، أما هذا المقال فيتناول المشاريع مفتوحة المصدر بشكل عام، من الأدوات الصغيرة إلى المنصات الكبيرة.

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

- لماذا يجب أن تقرأ حوكمة المشروع قبل أن تعتمد عليه، وما الذي لا تخبرك به النجوم وعدد التنزيلات.
- ستة نماذج للحوكمة مع أمثلة حقيقية من ملفات المشاريع نفسها: curl وNode.js وApache وDebian وKubernetes وGitLab، ثم دور المؤسسات المحايدة.
- الأدوار وسلم المساهمة من المستخدم إلى المشرف، وملفات OWNERS وCODEOWNERS وMAINTAINERS.
- كيف يتخذ القرار: البلاغات ووثائق التصميم RFC والتوافق الصامت Lazy Consensus والتصويت.
- المساهمة عملياً: الملفات التي تقرؤها أولاً، والفرق بين DCO وCLA مع مثال حقيقي للأمر `git commit -s`، وخطوات أول مساهمة لك.
- قواعد السلوك Code of Conduct وأدوات الإشراف على النقاشات، وحدود المشرف.
- من يدفع للمشرفين، وقصة الباب الخلفي في XZ Utils، والنسخة البديلة Fork كآخر أداة رقابة بيد المجتمع.
- قائمة تحقق لتقييم حوكمة أي مشروع قبل أن تعتمد عليه، وكيف تقرؤها من GitHub ومن OpenSSF Scorecard.

## لماذا تهمك حوكمة المشروع قبل أن تعتمد عليه؟

لنفرض أن فريقك يختار مكتبة أو أداة لنظام سوف يعمل سنوات، فالطريقة التي يفكر بها أغلبنا أولاً هي أن ننظر إلى عدد النجوم Stars في GitHub وعدد التنزيلات وتاريخ آخر إصدار، فإذا كانت الأرقام كبيرة والإصدار حديثاً اعتبرنا المشروع آمناً. ولكن هذه الأرقام تقيس الشهرة ولا تقيس الإدارة، فالمشروع قد يحمل عشرات الآلاف من النجوم وكل الكود فيه يمر عبر شخص واحد، وقد يكون الإصدار الأخير حديثاً لأن شركة واحدة تدفع لفريقها، وتستطيع غداً أن تغير الرخصة لأن كل من ساهم وقع لها على اتفاقية تعطيها هذا الحق.

والطريقة الأنسب هي أن تسأل ثلاثة أسئلة لا تجيب عنها النجوم:

- **عامل الحافلة Bus Factor:** كم شخصاً يجب أن يختفي فجأة حتى يتوقف المشروع؟ وهو مصطلح مشهور بين المطورين يقصد به الأشخاص الذين لا يعرف غيرهم أجزاء أساسية من الكود أو يملكون وحدهم صلاحيات النشر، فإذا كان الرقم واحداً فالمشروع كله معلق بصحة شخص ووقته ومزاجه.
- **من يستطيع تغيير الرخصة؟** هل حقوق الكود موزعة على كل من ساهم، فيحتاج تغيير الرخصة إلى موافقتهم جميعاً، أم جمعتها شركة أو مؤسسة عبر اتفاقية المساهمين CLA، فتستطيع أن تقرر وحدها؟ وسوف نشرح الفرق في [قسم DCO وCLA](#dco-cla).
- **من يقرر خارطة الطريق Roadmap؟** هل هي لجنة منتخبة من المساهمين، أم فريق منتج في شركة يقرر بحسب مصلحة عملائه، أم شخص واحد بذوقه؟ والسبب في أهمية هذا السؤال أن الميزة التي تحتاجها قد لا تدخل أبداً إذا كانت تنافس النسخة المدفوعة.

والإجابة عن هذه الأسئلة موجودة عادة في ملفات يكتبها المشروع بنفسه، مثل `GOVERNANCE.md` و`CONTRIBUTING.md` و`MAINTAINERS`، وفي سجل المستودع نفسه، وسوف نقرأ في هذا المقال ملفات حقيقية من مشاريع معروفة حتى ترى كيف تختلف الإجابات.

## نماذج الحوكمة: من شخص واحد إلى مؤسسة

لا يوجد نموذج واحد صحيح، فلكل نموذج نقاط قوة ونقاط ضعف، والمشروع الواحد قد ينتقل بين أكثر من نموذج خلال عمره. ودليل [Open Source Guides](https://opensource.guide/leadership-and-governance/?ref=arabroot.io) الذي تنشره GitHub يذكر ثلاثة نماذج شائعة: الشخص الواحد BDFL، والجدارة Meritocracy، والمساهمة المفتوحة Liberal Contribution، ونضيف إليها ثلاثة نماذج نراها في المشاريع الكبيرة. والصورة التالية تبين النماذج الستة مع مثال حقيقي لكل منها:

![ست لوحات: BDFL بشخص يلبس تاجاً ومثاله curl، وLiberal Contribution بمجموعة مساهمين ومثاله Node.js، وMeritocracy أو Apache Way بطاولة اجتماعات ومثاله committers وPMC والتصويت بالأرقام، وConstitution + Elections بوثيقة مكتوبة ومثاله Debian، وSteering Committee بمجلس منتخب ومثاله Kubernetes بسبعة أعضاء، وSingle Vendor أو Open Core بمبنى شركة ومثاله GitLab، وفي الأسفل المؤسسات المحايدة Linux Foundation وCNCF وApache Software Foundation وEclipse Foundation](https://arabroot.io/content/images/2026/10/oss-governance-01-models.webp)

ستة نماذج لحوكمة المشاريع مفتوحة المصدر، والمؤسسات التي تستضيف كثيراً منها

### الشخص الواحد BDFL: مثال curl

BDFL اختصار Benevolent Dictator For Life، أي «الدكتاتور الخير مدى الحياة»، والاسم ساخر أكثر منه وصفاً سياسياً، ويقصد به أن شخصاً واحداً، غالباً من بدأ المشروع، يملك الكلمة الأخيرة في القرارات الكبيرة. ويذكر دليل Open Source Guides أن أغلب المشاريع الصغيرة تعمل بهذا النموذج دون أن تكتبه، لأن المشروع فيه شخص أو اثنان فقط. ولكن بعض المشاريع الكبيرة تكتبه صراحة، ومن أوضح الأمثلة أداة curl التي تجدها على كل سيرفر تقريباً، والمثال التالي يقرأ الأسطر التي تذكر هذا النموذج في ملف الحوكمة الخاص بها:

```bash
curl -s https://raw.githubusercontent.com/curl/curl/master/docs/GOVERNANCE.md | grep -n "BDFL\|That is Daniel"
```

والمخرج سوف يكون كما يلي:

```text
11:## BDFL
15:BDFL (Benevolent Dictator For Life) style project.
144:## BDFL
146:That is Daniel.
203:# Post-Daniel BDFL
209:take quick daily decisions is efficient. Without Daniel as BDFL, either
```

في المخرج أعلاه لاحظ التالي:

- الملف يسمي الشخص بالاسم، وهو Daniel Stenberg الذي بدأ المشروع، ويقول في القسم نفسه إن هذا الترتيب استخدم لأنه مريح ونجح حتى الآن، وليس لأن أحداً يعتبره أفضل نموذج لقيادة المشاريع.
- القسم في السطر 203 يتكلم عن مرحلة ما بعد Daniel، ويقترح أن يتقدم شخص آخر للقيادة أو أن ينتقل المشروع إلى مجلس، وأن يقرر الفريق الأساسي Core Team ذلك بالتصويت. وهذا هو الجواب الصحيح على مشكلة عامل الحافلة: أن يكتب المشروع خطة الخلافة Succession Plan قبل أن يحتاجها.
- وفي [الملف كاملاً](https://github.com/curl/curl/blob/master/docs/GOVERNANCE.md?ref=arabroot.io) تجد أن المشروع لا يتبع أي كيان قانوني أو مؤسسة، وأن حقوق الكود مملوكة لكل من كتب جزءاً منه، وأن القرار يتم بالتوافق أولاً، فإذا لم يحصل التوافق يقرر المشرف Maintainer الأعلم بذلك الجزء من الكود.

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

### المساهمة المفتوحة Liberal Contribution: مثال Node.js

في هذا النموذج يكون التأثير لمن يعمل الآن، وليس لمن عمل في الماضي، والقرارات الكبيرة تتم بالسعي إلى التوافق Consensus Seeking بدلاً من التصويت المباشر، ويذكر دليل Open Source Guides مشروعي Node.js وRust كمثالين مشهورين عليه. وفي [ملف الحوكمة في Node.js](https://github.com/nodejs/node/blob/main/GOVERNANCE.md?ref=arabroot.io) تجد القواعد مكتوبة بوضوح:

- أي شخص يستطيع اقتراح تغيير عبر طلب دمج Pull Request، والمتعاونون Collaborators، وهم من يملكون صلاحية الكتابة Write Access في المستودع، هم من يراجعون ويدمجون.
- يحتاج الطلب إلى موافقة اثنين من المتعاونين من غير كاتب التغيير، وتكفي موافقة واحدة إذا بقي الطلب مفتوحاً أكثر من سبعة أيام.
- إذا اعترض متعاون واحد على التغيير فلا يدمج، إلا إذا صوتت اللجنة الفنية TSC على قبوله رغم الاعتراض، ويقول الملف إن الأمر نادراً ما يصل إلى اللجنة لأن النقاش يحل أغلب الاعتراضات.
- من لم يكتب أو يوافق على تغيير دمج خلال اثني عشر شهراً ينقل تلقائياً إلى قائمة المتعاونين السابقين Emeritus، وهذا منطقي لأن صلاحية الكتابة في مشروع بهذا الحجم مسؤولية أمنية، ولا يجب أن تبقى مع حساب لا يستخدمه صاحبه.

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

### الجدارة وطريقة Apache

مؤسسة Apache Software Foundation واختصاراً ASF تستضيف أكثر من مشروع تعرفه، مثل Apache HTTP Server وKafka وCassandra، وكل مشاريعها تتبع نفس الطريقة التي تسمى The Apache Way، وتسميها صفحة [How the ASF works](https://www.apache.org/foundation/how-it-works/?ref=arabroot.io) «الجدارة» Meritocracy، أي أن من يثبت عمله يحصل على دور رسمي في القرار. ويذكر دليل Open Source Guides أن بعض المجتمعات تتحفظ على كلمة Meritocracy نفسها لتاريخها الاجتماعي، ولكن الفكرة العملية واضحة. والصورة التالية تبين الطبقات وطريقة التصويت:

![على اليمين خمس طبقات من الأعلى: ASF Members ينتخبون مجلس الإدارة كل سنة، وBoard of Directors من تسعة أعضاء ينشئ لجان المشاريع ويعين رئيس كل لجنة، وPMC مع رئيسها وأصواتها ملزمة، وCommitters لهم حق الكتابة وتنتخبهم ال PMC، وContributors وUsers يرسلون الإصلاحات وصوتهم استشاري، وعلى اليسار بطاقة التصويت: +1 نعم، 0 لا رأي، -1 لا مع السبب، وتعديل الكود يحتاج ثلاث موافقات دون اعتراض والاعتراض فيه Veto، والإصدار يحتاج ثلاث موافقات ملزمة مع الأغلبية ولا Veto فيه، والإجراءات بأغلبية بسيطة، وLazy Consensus يعني أن الصمت موافقة بعد مهلة](https://arabroot.io/content/images/2026/10/oss-governance-02-apache.webp)

طبقات الأدوار في Apache، وطريقة التصويت بالأرقام

والأدوار في كل مشروع من مشاريع Apache كما تشرحها الصفحة نفسها هي: المستخدم User، ثم المطور Developer الذي يساهم بالكود أو التوثيق، ثم صاحب صلاحية الكتابة Committer، ثم عضو لجنة إدارة المشروع PMC Member، ثم رئيس اللجنة PMC Chair الذي يعينه مجلس الإدارة ويصبح نائب رئيس في المؤسسة، ثم عضو المؤسسة ASF Member. ومجلس الإدارة Board of Directors مكون من تسعة أشخاص ينتخبهم الأعضاء من بينهم كل سنة، وهو الذي ينشئ لجان المشاريع ويستطيع إلغاءها، أما القرارات اليومية في المشروع فبيد ال PMC، وتقول الصفحة صراحة إن اللجنة هي التي تقرر وليس أصحاب صلاحية الكتابة كأفراد.

والجزء الأكثر شهرة في هذه الطريقة هو التصويت بالأرقام، وتشرحه صفحة [Voting](https://www.apache.org/foundation/voting.html?ref=arabroot.io) كما يلي:

- الصوت رقم بين `-1` و`+1`، فالأول يعني «لا» والثاني «نعم»، و`0` يعني أنه لا رأي لديك، ويستخدم البعض كسوراً مثل `-0.5` للتعبير عن عدم الارتياح دون اعتراض.
- تعديل الكود Code Modification يحتاج ثلاثة أصوات `+1` دون أي `-1`، والصوت `-1` هنا اعتراض نهائي Veto يوقف التعديل حتى يسحبه صاحبه، ولا يقبل الاعتراض إلا مع سبب تقني مثل ثغرة أمنية أو ضرر في الأداء.
- الإصدار Release يحتاج ثلاثة أصوات ملزمة Binding من أعضاء ال PMC وأن تزيد الموافقات على الاعتراضات، ولا يوجد Veto على الإصدارات.
- المسائل الإجرائية Procedural تحسم بالأغلبية البسيطة.
- التوافق الصامت Lazy Consensus، ويعرفه [قاموس المصطلحات في Apache](https://www.apache.org/foundation/glossary.html?ref=arabroot.io) بأنه افتراض الموافقة إذا لم يرد أحد خلال مهلة محددة، ومثاله في القاموس نفسه: «سوف أدمج هذا التغيير ما لم يعترض أحد خلال ثلاثة أيام». وهذه الطريقة هي التي تجعل العمل اليومي سريعاً، فلا يحتاج كل تغيير صغير إلى تصويت.

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

### الدستور والانتخابات: مثال Debian

توزيعة Debian، وهي الأساس الذي بنيت عليه Ubuntu، تدار بوثيقة اسمها [دستور Debian](https://www.debian.org/devel/constitution?ref=arabroot.io) أو Debian Constitution، صدرت نسختها الأولى في 2 ديسمبر 1998، وآخر نسخة منها 1.9 في 26 مارس 2022، وهي من أوضح الأمثلة على مشروع يدار بالانتخاب. وأهم ما فيها:

- قائد المشروع Debian Project Leader واختصاراً DPL [ينتخبه المطورون](https://www.debian.org/devel/leader?ref=arabroot.io) لمدة سنة واحدة، ثم تعاد الانتخابات.
- المطورون مجتمعين يستطيعون أن يقرروا أي شيء بقرار عام General Resolution، بما في ذلك إلغاء قرار القائد، ويحتاج تعديل الدستور نفسه إلى أغلبية ثلاثة إلى واحد، وتنشر كل الاقتراعات في [صفحة التصويت](https://www.debian.org/vote/?ref=arabroot.io).
- في التصويت يرتب كل مطور الخيارات بحسب تفضيله، ولا يختار خياراً واحداً فقط، ثم تحسب النتيجة بطريقة مكتوبة في ملحق الدستور.
- اللجنة الفنية Technical Committee مكونة من ثمانية مطورين كحد أقصى، وتحسم الخلافات التقنية بين المطورين، وتستطيع أن تلغي قرار مطور في الحزمة التي يشرف عليها بأغلبية ثلاثة إلى واحد.

ويلتقي مطورو Debian كل سنة في [مؤتمرهم DebConf](https://www.debconf.org/?ref=arabroot.io)، والصورة التالية من DebConf15 في مدينة Heidelberg بألمانيا سنة 2015، وهي تذكرك بأن الدستور والانتخابات في Debian ليست كلاماً على ورق، فخلفها مئات المطورين الذين يصوتون فعلاً:

![صورة جماعية من الأعلى لمئات المشاركين في DebConf15 واقفين على العشب، وعليها شعار DebConf15 وعبارة Debian: We are many and we keep multiplying](https://arabroot.io/content/images/2026/10/oss-governance-12-debconf15.webp)

المشاركون في DebConf15، مؤتمر مطوري Debian، في Heidelberg بألمانيا في أغسطس 2015\. الصورة: Aigars Mahinovs، بترخيص [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Debconf15%5Fgroup%5Fphoto.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP).

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

### مجالس التوجيه في المشاريع الكبيرة: Kubernetes وFedora

عندما يكبر المشروع وتعمل عليه شركات كثيرة متنافسة، يظهر سؤال جديد: كيف نمنع شركة واحدة من السيطرة عليه؟ وKubernetes يجيب عن ذلك بمجلس توجيه Steering Committee مكون من [سبعة أعضاء](https://github.com/kubernetes/steering?ref=arabroot.io)، وتنص [وثيقة المجلس](https://github.com/kubernetes/steering/blob/main/charter.md?ref=arabroot.io) على انتخابات سنوية للمقاعد المفتوحة، وتنص [قواعد الانتخاب](https://github.com/kubernetes/steering/blob/main/elections.md?ref=arabroot.io) على ألا يزيد تمثيل أي شركة في المجلس على الثلث في أي وقت، فإذا أعطت نتائج الانتخاب شركة واحدة أكثر من الثلث يستبعد أقل مرشحيها أصواتاً، وإذا تغيرت النسبة بعد ذلك بسبب انتقال وظيفي أو استحواذ وجب على بعض الأعضاء أن يستقيلوا حتى تعود النسبة. والمجلس لا يقرر التفاصيل التقنية، وإنما يدير الحوكمة والمجموعات المختصة Special Interest Groups التي تملك كل منها جزءاً من المشروع.

وفي Fedora تجد فكرة قريبة، فاللجنة الفنية [FESCo](https://docs.fedoraproject.org/en-US/fesco/?ref=arabroot.io) اختصار Fedora Engineering Steering Committee، وتصفها وثائق المشروع بأنها هيئة منتخبة بالكامل من المجتمع وتمثل القيادة الفنية في Fedora، وهي المسؤولة عن القضايا التقنية وتنسيق الموارد.

### المؤسسات المحايدة: Linux Foundation وCNCF وApache وEclipse

المؤسسة Foundation كيان قانوني غير ربحي يستضيف المشروع، فيحمل علامته التجارية Trademark وأمواله ونطاقاته وحساباته، حتى لا تكون هذه الأشياء ملكاً لشركة أو شخص. ولاحظ أن المؤسسة نفسها ليست نموذج حوكمة، فكل مشروع داخلها يختار طريقة قراره، وقد ذكرنا في [مقال الرخص](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/#today) كيف استضافت [Linux Foundation](https://www.linuxfoundation.org/about?ref=arabroot.io) مشروعي OpenTofu وValkey بعد تغيير الرخص، ولن نعيد القصة هنا. والذي يهمك عند اختيار مشروع هو أن المؤسسات الكبيرة تعطي المشاريع مراحل نضج Maturity Levels واضحة تستطيع أن تقرأها:

- **CNCF:** مؤسسة Cloud Native Computing Foundation التابعة لـ Linux Foundation، وفيها Kubernetes وPrometheus وغيرهما، وتقسم مشاريعها في [وثيقة المراحل](https://github.com/cncf/toc/blob/main/process/README.md?ref=arabroot.io) إلى ثلاث: Sandbox للمشاريع التجريبية التي قد تتغير كثيراً وقد تفشل، وIncubating للمشاريع التي بدأت تستقر ويبدأ فيها التقييم الفعلي لانتشارها، وGraduated للمشاريع الناضجة التي أثبت مستخدموها تشغيلها في بيئات الإنتاج Production، وتقيم لجنة الإشراف الفنية TOC انتقال المشروع بين المراحل بمراجعة تسمى Due Diligence. وتجد مرحلة كل مشروع في [صفحة المشاريع](https://www.cncf.io/projects/?ref=arabroot.io).
- **Apache:** المشروع الجديد يدخل أولاً إلى [Apache Incubator](https://incubator.apache.org/?ref=arabroot.io)، ولا يتخرج منه حتى يثبت أنه يعمل بطريقة Apache التي شرحناها أعلاه.
- **Eclipse:** [عملية التطوير في Eclipse](https://www.eclipse.org/projects/dev%5Fprocess/?ref=arabroot.io) تمر بمراحل مكتوبة: ما قبل الاقتراح، ثم الاقتراح Proposal، ثم الاحتضان Incubation، ثم النضج Mature، ولكل انتقال مراجعة رسمية.

لذلك إذا وجدت أن الأداة التي تفكر فيها مشروع Sandbox في CNCF، فهذا يعني أن المؤسسة نفسها تقول إنها تجريبية، ويجب أن تحسب حساب ذلك قبل أن تبني عليها نظاماً حرجاً.

### المشروع الذي تقوده شركة واحدة والنواة المفتوحة Open Core

كثير من الأدوات التي نثبتها في أدلة هذا الموقع تطورها شركة واحدة توظف أغلب المطورين وتملك العلامة التجارية، وهذا ليس عيباً في ذاته، فالشركة تدفع رواتب فريق يعمل على المشروع كل يوم، وهذا ما لا يستطيعه كثير من المتطوعين. ومن أشهر أشكال هذا النموذج النواة المفتوحة Open Core، أي أن الأساس مفتوح المصدر والميزات المتقدمة في نسخة مدفوعة، ومثاله GitLab التي تقول في [صفحة الرعاية Stewardship](https://handbook.gitlab.com/handbook/company/stewardship/?ref=arabroot.io) إنها شركة بنموذج Open Core، وتكتب فيها مجموعة وعود للمجتمع، منها ألا تنقل الميزات المفتوحة الموجودة إلى الكود المتاح Source-available، وألا تضع في الكود المفتوح قيوداً مصطنعة على عدد المستودعات أو المستخدمين أو الأداء.

ونقاط القوة في هذا النموذج هي التمويل الثابت والفريق المتفرغ ووجود جهة تبيع لك الدعم، ونقاط الضعف أن قرار خارطة الطريق بيد الشركة، وأن مصلحتها قد تختلف يوماً عن مصلحتك، وأنها تستطيع أن تغير رخصة الإصدارات الجديدة إذا كانت تملك حقوق الكود كله عبر اتفاقية المساهمين، وهذا ما حدث فعلاً في القصص التي شرحناها في [علامات تستحق الانتباه](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/#red-flags) في مقال الرخص. لذلك عندما تعتمد على مشروع تقوده شركة، اقرأ وعودها المكتوبة إن وجدت، واعرف هل تطلب CLA من المساهمين، وتذكر أن الضمان الحقيقي هو رخصة مفتوحة تسمح للمجتمع بالاستمرار من آخر إصدار إذا تغيرت الشركة.

والجدول التالي يجمع النماذج الستة:

| النموذج              | من يقرر؟                       | مثال               | نقاط القوة                                        | نقاط الضعف                      |
| -------------------- | ------------------------------ | ------------------ | ------------------------------------------------- | ------------------------------- |
| BDFL                 | شخص واحد في النهاية            | curl               | قرار سريع واتجاه متسق                             | كل شيء معلق بشخص                |
| Liberal Contribution | من يعمل الآن، بالتوافق         | Node.js            | باب مفتوح لكل من يساهم                            | التوافق يأخذ وقتاً              |
| Apache Way           | لجنة PMC بأصوات ملزمة          | مشاريع Apache      | قواعد مكتوبة ومجربة، والأفراد يصوتون وليس الشركات | بطء نسبي وطريق طويل إلى اللجنة  |
| الدستور والانتخاب    | المطورون بالتصويت، وقائد منتخب | Debian             | كل سلطة محدودة ومحاسبة                            | القرارات الكبيرة تأخذ أسابيع    |
| مجلس توجيه           | مجلس منتخب ومجموعات مختصة      | Kubernetes وFedora | توازن بين الشركات المتنافسة                       | بنية معقدة على المساهم الجديد   |
| شركة واحدة           | فريق المنتج في الشركة          | GitLab             | تمويل وفريق متفرغ ودعم مدفوع                      | الرخصة وخارطة الطريق بيد الشركة |

## من المستخدم إلى المشرف: الأدوار وسلم المساهمة

الأسماء تختلف بين المشاريع، ولكن الفكرة واحدة تقريباً: تبدأ مستخدماً، ثم تساهم بإصلاح صغير، ثم تكسب الثقة شيئاً فشيئاً حتى تصبح مراجعاً ثم صاحب صلاحية دمج ثم مسؤولاً عن جزء من المشروع. وKubernetes يكتب هذا السلم، ويسمى سلم المساهمة Contributor Ladder، بشروطه في [وثيقة العضوية](https://github.com/kubernetes/community/blob/master/community-membership.md?ref=arabroot.io)، والصورة التالية تبينه:

![درج من ست درجات من اليمين: User يستخدم ويبلغ عن الأخطاء، وContributor أول Pull Request يدمج، وMember بمساهمات متعددة ويرشحه مراجعان، وReviewer بعد ثلاثة أشهر وأكثر من 20 طلب دمج، وApprover بعد ثلاثة أشهر كمراجع وأكثر من 30 طلباً، وSubproject Owner يلبس تاجاً ويحدد الاتجاه والأولويات، وفي الأسفل ملف OWNERS فيه قائمة reviewers وapprovers](https://arabroot.io/content/images/2026/10/oss-governance-03-ladder.webp)

سلم المساهمة في Kubernetes، والترقية تتم بطلب دمج يعدل ملف OWNERS

والشروط كما تكتبها الوثيقة:

- **العضو Member:** مساهمات متعددة في المشروع، ورعاية Sponsorship من مراجعين اثنين، مع تفعيل المصادقة الثنائية Two-factor Authentication على حساب GitHub.
- **المراجع Reviewer:** عضو منذ ثلاثة أشهر على الأقل، وكان المراجع الأساسي في خمسة طلبات دمج على الأقل، وراجع أو دمج عشرين طلباً على الأقل، ويرشحه أحد الموافقين دون اعتراض من الآخرين.
- **الموافق Approver:** مراجع منذ ثلاثة أشهر على الأقل، وكان المراجع الأساسي في عشرة طلبات كبيرة على الأقل، وراجع أو دمج ثلاثين طلباً على الأقل، ويرشحه مالك المشروع الفرعي.
- **مالك المشروع الفرعي Subproject Owner:** يحدد الاتجاه والأولويات لجزء من المشروع، ويكون قد أثبت المسؤولية والحكم التقني الجيد في هذا الجزء.

ولاحظ أن الترقية نفسها تتم بطلب دمج يضيف اسمك إلى ملف `OWNERS` في المجلد المعني، فالصلاحيات في Kubernetes مكتوبة في المستودع ومراجعة مثل الكود تماماً. وهذه الفكرة موجودة في GitHub نفسه بملف [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners?ref=arabroot.io)، وتضعه في المجلد `.github/` أو في المجلد الرئيسي للمستودع أو في المجلد `docs/`، فيطلب GitHub مراجعة أصحاب الكود تلقائياً عندما يفتح أحد طلب دمج يعدل ملفاتهم، ويمكن أن تجعل موافقتهم شرطاً في حماية الفروع Branch Protection التي شرحناها في [مقال Git في العمل اليومي](https://arabroot.io/articles/git-merge-%D9%88-rebase-%D9%88-cherry-pick/#pull-requests). ونواة Linux تستخدم ملفاً أقدم اسمه `MAINTAINERS` يحدد المشرف على كل جزء من النواة والقائمة البريدية التي ترسل إليها التعديلات، وتشرح [وثيقة إرسال التعديلات](https://docs.kernel.org/process/submitting-patches.html?ref=arabroot.io) كيف يستخدم السكربت `scripts/get_maintainer.pl` لمعرفة من ترسل إليه تعديلك.

والوجه الآخر من السلم هو النزول، فكما يأخذ Node.js الصلاحية ممن لم يعمل اثني عشر شهراً، يقول ملف الحوكمة في curl إن المشرف الذي يتوقف عن النشاط تسحب منه صلاحية الدفع لأسباب أمنية، ويضيف أن ذلك ليس عقوبة، وأن كل من عمل على المشروع يبقى بطلاً بعد ذلك. وهذا مهم لك كمستخدم، فالمشروع الذي فيه مئة صاحب صلاحية لم يعمل نصفهم منذ سنوات أخطر من مشروع فيه عشرة نشطين، لأن أي حساب قديم مخترق يستطيع أن يدفع كوداً إلى المستودع.

## كيف يتخذ القرار؟ من البلاغ إلى الدمج

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

![خمس خطوات من اليمين: Issue بلاغ أو اقتراح، ثم Discussion نقاش علني مع المشرفين، ثم RFC أو KEP أو PEP وثيقة تصميم للتغيير الكبير، ثم Pull Request + Review كود ومراجعة واختبارات، ثم Merge + Release، وسهم أخضر متقطع يبين أن الإصلاح الصغير ينتقل من البلاغ إلى طلب الدمج مباشرة، وفي الأسفل ثلاث طرق لحسم القرار: Lazy Consensus، وFinal Comment Period كما في Rust، وVote عند الخلاف](https://arabroot.io/content/images/2026/10/oss-governance-04-decisions.webp)

طريق القرار في المشروع، والطرق الثلاث الشائعة لحسمه

ووثائق التصميم لها أسماء مختلفة بحسب المشروع:

- **KEP في Kubernetes:** اختصار [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements?ref=arabroot.io)، وهي طريقة لاقتراح العمل الجديد والتواصل حوله وتنسيقه، وتبدأ بالتأكد من أن آخرين يرون أن العمل يستحق ويستعدون لمراجعته.
- **RFC في Rust:** التغييرات الكبيرة تمر عبر [مستودع RFCs](https://github.com/rust-lang/rfcs?ref=arabroot.io)، ويوجه كل طلب إلى الفريق المختص، وينتهي بفترة تعليق أخيرة Final Comment Period قبل القرار، وقد شرحنا ذلك مع حوكمة Rust في [مقال مواصفات اللغات](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%87%D8%A7-%D9%88%D8%AD%D9%88%D9%83%D9%85%D8%AA%D9%87%D8%A7/#rust)، وفي المقال نفسه تجد PEP في Python وRFC في PHP مع بقية اللغات.

وقد يتساءل البعض: لماذا كل هذه الكتابة؟ أليس الأسرع أن يكتب المطور الكود ويرسله؟ والإجابة أن الكود الكبير الذي يرفض بعد شهر من العمل خسارة للمساهم وللمراجعين، ووثيقة من صفحتين تكشف الاعتراض في يومين. والسبب الثاني أن القرار المكتوب يبقى، فبعد خمس سنوات يستطيع أي شخص أن يقرأ لماذا صمم المشروع بهذه الطريقة ومن اعترض وماذا كان الرد. أما مراجعة طلب الدمج نفسه وحماية الفروع فقد شرحناها في [مقال Git للمبتدئين](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D9%88-git-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#pull-requests) ولن نعيدها هنا.

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

## المساهمة في مشروع مفتوح المصدر عملياً

### الملفات التي تقرؤها أولاً

قبل أن تكتب سطراً واحداً، اقرأ الملفات التي كتبها المشروع للمساهمين، وأغلبها في المجلد الرئيسي للمستودع أو في المجلد `.github/`:

- **README:** ما المشروع وكيف تشغله، وأين يتم النقاش: Issues أو قائمة بريدية أو منتدى.
- **LICENSE:** الرخصة التي سوف تدخل بها مساهمتك، وقد شرحنا قراءتها في [مقال الرخص](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/#check-license).
- **CONTRIBUTING.md:** طريقة بناء المشروع وتشغيل الاختبارات، وشكل رسالة ال Commit المطلوب، وهل يحتاج المشروع DCO أو CLA.
- **CODE\_OF\_CONDUCT.md:** قواعد السلوك وطريقة الإبلاغ عن المخالفات.
- **GOVERNANCE.md:** من يقرر وكيف، كما رأينا في curl وNode.js.
- **SECURITY.md:** كيف تبلغ عن ثغرة أمنية دون أن تنشرها، والإصدارات التي ما زالت تتلقى إصلاحات أمنية.

والصورة التالية تجمع هذه الملفات بالترتيب الذي نقترحه للقراءة، مع ملفات الصلاحيات MAINTAINERS وCODEOWNERS التي شرحناها في قسم الأدوار أعلاه، لأنها تخبرك من سوف يراجع طلبك:

![على اليسار شجرة مستودع فيها README.md وLICENSE وCONTRIBUTING.md وCODE_OF_CONDUCT.md وGOVERNANCE.md وSECURITY.md وMAINTAINERS والمجلد .github وفيه CODEOWNERS، وعلى اليمين سبع بطاقات مرقمة: README ما المشروع وأين النقاش، وLICENSE الرخصة التي تدخل بها مساهمتك، وCONTRIBUTING كيف تبني وتختبر وهل يطلب DCO أو CLA، وCODE_OF_CONDUCT السلوك المقبول وأين تبلغ، وGOVERNANCE من يقرر وكيف، وSECURITY كيف تبلغ عن ثغرة بسرية، وMAINTAINERS وCODEOWNERS من يراجع الجزء الذي تعدله، وبطاقة Community Profile في GitHub](https://arabroot.io/content/images/2026/10/oss-governance-07-files.webp)

الملفات التي تقرؤها قبل أول مساهمة، والسؤال الذي يجيب عنه كل ملف

وتسمى هذه الملفات في GitHub ملفات صحة المجتمع Community Health Files، وتستطيع المنظمة أن تضع [نسخة افتراضية منها](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file?ref=arabroot.io) في مستودع خاص اسمه `.github` فتظهر في كل مستودعاتها التي لا تحمل ملفاتها الخاصة، وفي المستودعات العامة تعرض صفحة [ملف المجتمع Community Profile](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/about-community-profiles-for-public-repositories?ref=arabroot.io) هل هذه الملفات موجودة أم لا.

### DCO أم CLA؟ من يملك حقوق كودك بعد الدمج

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

![لوحتان: على اليمين DCO حيث يكتب المساهم git commit -s فيضاف السطر Signed-off-by: Alice إلى ال Commit ثم يدخل المستودع، والحقوق تبقى لكل مساهم والكود يدخل بالرخصة نفسها التي يخرج بها وتغيير الرخصة يحتاج موافقة أصحاب الحقوق، ومثاله Linux kernel وGit، وعلى اليسار CLA حيث يوقع المساهم اتفاقية مرة واحدة تذهب إلى الشركة أو المؤسسة، وتمنحها ترخيصاً واسعاً وتسمح لها غالباً بإصدار المشروع برخصة أخرى، ومثاله Apache ICLA وRedis CLA](https://arabroot.io/content/images/2026/10/oss-governance-05-dco-cla.webp)

DCO سطر في كل Commit والحقوق تبقى معك، وCLA اتفاقية توقعها مرة وتعطي صاحب المشروع حقوقاً أوسع

شهادة أصل المطور [Developer Certificate of Origin](https://developercertificate.org/?ref=arabroot.io) واختصاراً DCO نص قصير من أربع فقرات، الإصدار الحالي منه 1.1 وحقوقه لـ Linux Foundation منذ 2004 و2006، وتقر فيه بأنك كتبت المساهمة أو أنها مبنية على كود برخصة مفتوحة تسمح لك بإرسالها، وأن سجل مساهمتك بما فيه اسمك وبريدك عام ويبقى للأبد. ولا توقع على شيء ورقي، وإنما تضيف سطر `Signed-off-by` في آخر رسالة ال Commit، وهو ما تشترطه [نواة Linux](https://docs.kernel.org/process/submitting-patches.html?ref=arabroot.io) و[مشروع Git نفسه](https://github.com/git/git/blob/master/Documentation/SubmittingPatches?ref=arabroot.io). والخيار `-s` في Git يضيف السطر تلقائياً من الاسم والبريد في إعداداتك، والمثال التالي ينشئ مستودعاً مؤقتاً ويجرب ذلك:

```bash
mkdir dco-demo && cd dco-demo
git init -q -b main
git config user.name "Alice"
git config user.email "alice@example.com"
printf "# demo\n" > README.md
git add README.md
git commit -s -q -m "docs: add README"
git log -1 --format=%B
```

والمخرج سوف يكون كما يلي:

```text
docs: add README

Signed-off-by: Alice <alice@example.com>
```

والآن نكسرها لنفهمها، فنضيف Commit ثانياً دون الخيار `-s`، ثم نطلب من Git أن يعرض سطر التوقيع لكل Commit، وهذا تقريباً ما تفعله أدوات فحص DCO التي تعمل على طلبات الدمج في المشاريع:

```bash
printf "x\n" >> README.md
git commit -a -q -m "docs: fix typo"
git log --format='%h %s | %(trailers:key=Signed-off-by,valueonly,separator=%x2C)'
```

والمخرج سوف يكون كما يلي:

```text
739c759 docs: fix typo |
d4cea01 docs: add README | Alice <alice@example.com>
```

في المخرج أعلاه لاحظ التالي:

- ال Commit الثاني لا يحمل توقيعاً، والمشروع الذي يشترط DCO سوف يرفض طلب الدمج حتى تصلحه، والإصلاح لآخر Commit هو `git commit --amend -s --no-edit` ثم دفع الفرع من جديد بالقوة الآمنة `--force-with-lease` التي شرحناها في [مقال Git في العمل اليومي](https://arabroot.io/articles/git-merge-%D9%88-rebase-%D9%88-cherry-pick/#force-with-lease).
- التوقيع يأخذ الاسم والبريد من إعدادات Git، فإذا كان بريدك في الإعدادات بريداً شخصياً وأنت تساهم باسم جهة عملك، فصحح الإعداد قبل أن تبدأ، لأن السجل كما تقول الشهادة نفسها عام ودائم.
- الهاش في المخرج يختلف عندك لأنه يعتمد على الوقت والاسم، وقد شرحنا سبب ذلك في [مقال Git للمبتدئين](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D9%88-git-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#snapshots).

أما اتفاقية ترخيص المساهمين Contributor License Agreement واختصاراً CLA فهي وثيقة قانونية توقعها مرة واحدة قبل أول مساهمة، ومن أشهرها [اتفاقيات Apache](https://www.apache.org/licenses/contributor-agreements.html?ref=arabroot.io) للأفراد ICLA وللشركات CCLA، وتقول صفحتها إن المساهم يحتفظ بالحق الكامل في استخدام مساهمته الأصلية لأي غرض خارج Apache، بينما تحصل المؤسسة ومشاريعها على حق توزيع عمله والبناء عليه. والفرق الذي يهمك هو ما ذكرناه في سؤال «من يستطيع تغيير الرخصة؟» أول المقال: مع DCO تبقى الحقوق موزعة على كل من ساهم، فتغيير رخصة المشروع كله يحتاج إلى موافقتهم أو إعادة كتابة كودهم، ومع CLA واسعة لشركة واحدة تستطيع الشركة أن تصدر الإصدارات الجديدة برخصة أخرى. لذلك لا تقم بتوقيع CLA دون أن تقرأها، والسبب أن الاتفاقيات تختلف كثيراً، فبعضها يمنح ترخيصاً محدوداً لمؤسسة محايدة، وبعضها يمنح شركة حقوقاً واسعة على كل ما تكتبه.

### أول مساهمة لك خطوة بخطوة

1. **اختر مشروعاً تستخدمه فعلاً:** لأنك تعرف مشكلاته من الاستخدام، وتستطيع أن تختبر إصلاحك في عملك اليومي.
2. **ابدأ بالبلاغات المعلمة للمبتدئين:** كثير من المشاريع تضع الوسم `good first issue` على البلاغات المناسبة، وتذكر [وثائق GitHub](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/encouraging-helpful-contributions-to-your-project-with-labels?ref=arabroot.io) أن هذا الوسم يزيد احتمال ظهور البلاغ للمساهمين الجدد في أماكن مختلفة من الموقع.
3. **اكتب في البلاغ قبل أن تبدأ العمل:** قل إنك تريد العمل عليه واسأل عن الطريقة التي يفضلها المشرفون، والسبب أن شخصاً آخر قد يعمل عليه الآن، أو أن المشرفين يريدون حلاً مختلفاً عما في ذهنك.
4. **اعمل على فرع في نسختك:** انسخ المستودع إلى حسابك Fork، ثم استنسخه وأنشئ فرعاً للإصلاح، وقد شرحنا أوامر `clone` و`push` في [قسم المستودع البعيد](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D9%88-git-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#remote) في مقال Git للمبتدئين.
5. **اجعل الطلب صغيراً:** تغيير واحد في طلب واحد، مع اختبار يثبته، ورسالة Commit بالشكل الذي يطلبه CONTRIBUTING، ووقعه بالخيار `-s` إذا كان المشروع يطلب DCO، وتأكد قبل الدفع أن ال Commits لا تحتوي على توكن أو باسورد من بيئتك، والسبب أن طلب الدمج في مشروع عام يقرؤه الجميع، وقد شرحنا فحص ذلك آلياً في [دليل اكتشاف الأسرار المسربة](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D8%B3%D8%B1%D8%A7%D8%B1-%D8%A7%D9%84%D9%85%D8%B3%D8%B1%D8%A8%D8%A9-%D9%85%D8%B9-gitleaks-%D9%88-trufflehog/).
6. **تعامل مع المراجعة كنقاش تقني:** المراجع الذي يطلب تغييرات لا يرفضك، وإنما يحمي مشروعاً سوف يصونه هو بعد أن تذهب. أجب عن كل ملاحظة، وإذا لم تتفق معها فاشرح السبب بهدوء.
7. **لا تنس المساهمات التي ليست كوداً:** ترجمة الواجهة إلى العربية ومراجعتها، وإصلاحات الكتابة من اليمين إلى اليسار RTL، وتحسين التوثيق، والبلاغ الجيد الذي يحتوي على خطوات إعادة المشكلة ومخرج الخطأ، كلها مساهمات يحتاجها المشروع وقد تكون أصعب عليه من الكود.

### الثغرة الأمنية لا تفتح لها Issue عاماً

إذا وجدت ثغرة أمنية في مشروع، فلا تقم بفتح بلاغ عام عنها، والسبب أن البلاغ العام يخبر المخترقين بالثغرة قبل أن يصدر الإصلاح، وكل سيرفر يعمل بالإصدار الحالي يصبح هدفاً. وإنما ابحث عن الملف `SECURITY.md`، وتشرح [وثائق GitHub](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository?ref=arabroot.io) أنه يحتوي عادة على الإصدارات المدعومة وطريقة الإبلاغ، وكثير من المشاريع تفعل في GitHub خاصية [الإبلاغ الخاص عن الثغرات](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability?ref=arabroot.io) Private Vulnerability Reporting، فيصل بلاغك إلى المشرفين وحدهم. وفي curl مثلاً يذكر ملف الحوكمة فريقاً أمنياً صغيراً يستقبل البلاغات عبر قائمة بريدية خاصة.

## قواعد السلوك والإشراف على النقاشات

المشروع المفتوح مكان عام، يدخله أشخاص من ثقافات ولغات وأعمار مختلفة، وأغلبهم متطوعون، فإذا تحولت النقاشات إلى إهانات أو ضغط مستمر على المشرفين، يترك أفضل المساهمين المشروع بهدوء دون أن يعلن أحد ذلك. لذلك تكتب أغلب المشاريع قواعد سلوك Code of Conduct تحدد السلوك المقبول وغير المقبول، وكيف تبلغ عن المخالفة، ومن يحقق فيها، وما العقوبات الممكنة.

وأشهر هذه القواعد [Contributor Covenant](https://www.contributor-covenant.org/?ref=arabroot.io)، ويقول موقعه إنه موجود منذ 2014، وإنه أكثر قواعد السلوك انتشاراً في المشاريع مفتوحة المصدر، وإن له ترجمات بأكثر من أربعين لغة. والإصدار الذي يعرضه الموقع اليوم كأحدث إصدار هو [الإصدار 3.0](https://www.contributor-covenant.org/version/3/0/code%5Fof%5Fconduct/?ref=arabroot.io)، ولكنك سوف تجد في أغلب المستودعات الإصدار [2.1](https://www.contributor-covenant.org/version/2/1/code%5Fof%5Fconduct/?ref=arabroot.io) الذي [صدر في أغسطس 2021](https://github.com/EthicalSource/contributor%5Fcovenant/releases?ref=arabroot.io). وفي الإصدارين سلم لتطبيق العقوبات Enforcement Ladder، والصورة التالية تبين درجات الإصدار 3.0 مع الأدوات التي يوفرها GitHub للمشرف:

![درج من أربع درجات من اليمين: Warning تحذير مكتوب على انفراد، وTemporarily Limited Activities تحذير مع فترة تهدئة في بعض القنوات، وTemporary Suspension إيقاف مؤقت بشروط للعودة، وPermanent Ban منع دائم من كل مساحات المجتمع، وتحتها أن الدرجات الأولى يمكن تخطيها إذا كانت المخالفة خطيرة، وفي الأسفل أدوات GitHub: Hide comment لإخفاء تعليق خارج الموضوع أو مسيء، وLock conversation لإيقاف التعليقات على Issue محتدم، وInteraction limits لتقييد التفاعل من 24 ساعة إلى 6 أشهر، وBlock user لمنع مستخدم لمدة محددة أو دائماً](https://arabroot.io/content/images/2026/10/oss-governance-06-moderation.webp)

سلم العقوبات في Contributor Covenant 3.0، والأدوات التي تطبقه في GitHub

ودرجات السلم في الإصدار 3.0 هي: التحذير Warning، ثم تقييد النشاط مؤقتاً Temporarily Limited Activities مع فترة تهدئة قد تقتصر على قنوات معينة أو على التعامل مع أشخاص معينين، ثم الإيقاف المؤقت Temporary Suspension بشروط مكتوبة للعودة، ثم المنع الدائم Permanent Ban الذي يقول النص إنه يجب أن يكون نادراً وبأسباب قوية. وفي الإصدار 2.1 الدرجات هي التصحيح Correction ثم التحذير Warning ثم المنع المؤقت Temporary Ban ثم المنع الدائم Permanent Ban. ويضيف الإصدار 3.0 لكل درجة طريقة لإصلاح الضرر Repair، مثل الاعتذار المكتوب، وينص على أن الدرجات الأولى يمكن تخطيها إذا كانت المخالفة خطيرة. ولاحظ أن قواعد السلوك بلا شخص يطبقها مجرد ملف، فقبل أن تعتمد ملفاً منها اكتب فيه بريداً حقيقياً للإبلاغ، وحدد من يستقبل البلاغات، كما يفعل curl الذي يحيل بلاغات مخالفة قواعد السلوك إلى فريقه الأساسي لأنها تحتاج سرية.

### أدوات الإشراف في GitHub وGitLab

توفر المنصات أدوات تطبق بها هذه الدرجات دون أن تحذف تاريخ المشروع، وفي GitHub أهمها ما يلي:

- **إخفاء التعليق Hide Comment:** للتعليق الخارج عن الموضوع أو القديم أو الذي حل، أو للتعليق المسيء والمزعج، وتقول [الوثائق](https://docs.github.com/en/communities/moderating-comments-and-conversations/managing-disruptive-comments?ref=arabroot.io) إن التعليق المخفي يصغر ويستطيع من لديه صلاحية القراءة أن يفتحه، فالإخفاء يحافظ على النقاش مركزاً دون أن يمحو شيئاً.
- **قفل النقاش Lock Conversation:** يوقف التعليقات على Issue أو طلب دمج محتدم، ويظهر في سجل النقاش حدث يقول إن النقاش قفل، كما تشرح [وثائق القفل](https://docs.github.com/en/communities/moderating-comments-and-conversations/locking-conversations?ref=arabroot.io).
- **حدود التفاعل Interaction Limits:** عندما يأتي سيل من الحسابات إلى مستودعك، مثلاً بعد أن ينتشر بلاغ في مواقع التواصل، تستطيع أن [تقيد التفاعل](https://docs.github.com/en/communities/moderating-comments-and-conversations/limiting-interactions-in-your-repository?ref=arabroot.io) لمدة 24 ساعة أو 3 أيام أو أسبوع أو شهر أو 6 أشهر، وهناك ثلاثة أنواع: تقييد الحسابات التي عمرها أقل من 24 ساعة ولم تساهم من قبل، أو تقييد من لم يساهم في الفرع الرئيسي من قبل، أو قصر التفاعل على أصحاب صلاحية الكتابة فقط.
- **منع المستخدم Block User:** تستطيع المنظمة أن [تمنع مستخدماً](https://docs.github.com/en/communities/maintaining-your-safety-on-github/blocking-a-user-from-your-organization?ref=arabroot.io) لمدة محددة يرفع عنه المنع بعدها تلقائياً، أو دون مدة حتى ترفعه يدوياً.

وفي GitLab تجد خاصية [قفل النقاش Lock Discussion](https://docs.gitlab.com/user/discussions/?ref=arabroot.io) التي تمنع التعليقات العامة على ال Issue أو طلب الدمج Merge Request.

### كيف تتعامل مع بلاغ غاضب؟ وأين حدود المشرف؟

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

1. رد مرة واحدة بهدوء على الجزء التقني فقط: هل الخطأ مؤكد؟ وهل يوجد حل مؤقت؟ وهل يقبل المشروع طلب دمج لإصلاحه؟
2. أشر إلى قواعد السلوك في جملة واحدة إذا تجاوز الكلام الحد، دون محاضرة.
3. إذا استمر النقاش في الاحتداد، اقفل البلاغ وأخف التعليقات المسيئة، وإذا تكرر ذلك من نفس الشخص فطبق درجات السلم كما كتبتها.
4. تذكر أن المشروع لا يدين لأحد بدعم مجاني، وملف الحوكمة في curl يقول صراحة إن المشرفين ليس عليهم واجبات إلزامية، وإن المشروع لا يقدم دعماً تجارياً، فالشركة التي تحتاج سرعة في الإصلاح تستطيع أن تشتري الدعم من جهة تقدمه، أو أن تدفع لمطور يرسل الإصلاح.

ومن حدود المشرف أيضاً أن يكتب في README أو في ملف `SUPPORT.md` أين يجيب عن الأسئلة وأين لا يجيب، وأن يغلق البلاغات التي ليست بلاغات أخطاء بأدب مع رابط للمكان الصحيح، فالمشرف الذي يجيب عن كل شيء في كل مكان سوف يحترق سريعاً.

## من يدفع للمشرفين؟ الإرهاق Burnout والتمويل Funding

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

- **GitHub Sponsors:** تمويل مباشر للمطورين والمنظمات من حساباتهم في GitHub، وتقول [الوثائق](https://docs.github.com/en/sponsors/getting-started-with-github-sponsors/about-github-sponsors?ref=arabroot.io) إن الرعاية من الحسابات الشخصية بلا رسوم فيصل المبلغ كاملاً، أما الرعاية من حسابات المنظمات فعليها رسوم تصل إلى 6%.
- **Open Collective:** منصة تجمع التبرعات وتصرفها بشفافية، ويقول ملف الحوكمة في curl إن أفضل طريقة للتبرع للمشروع هي [صندوقه في Open Collective](https://opencollective.com/curl?ref=arabroot.io)، وإن جهة غير ربحية أمريكية تحفظ المال للمشروع وتصرف منه نفقاته.
- **المؤسسات:** مثل Linux Foundation وApache، فهي تحمل الأموال والعلامات التجارية وتدفع للبنية التحتية، وبعضها يمول مطورين.
- **التمويل الحكومي:** ومن أوضح أمثلته [Sovereign Tech Agency](https://www.sovereign.tech/?ref=arabroot.io) الألمانية التي يأتي تمويلها بقرار من البرلمان الألماني Bundestag، ويستثمر برنامجها [Sovereign Tech Fund](https://www.sovereign.tech/programs/fund?ref=arabroot.io) في مكونات البرمجيات المفتوحة التي تعتمد عليها البرمجيات الأخرى، مثل مكتبات لغات البرمجة ومديري الحزم وأدوات التشفير، ويقول البرنامج في صفحته إن عدد من يستخدمون البرمجيات المفتوحة أكبر بكثير ممن يساهمون فيها.

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

![في الوسط المشروع ومشرفوه، وعلى اليمين ثلاث بطاقات ترسل مالاً: GitHub Sponsors بلا رسوم من الحساب الشخصي وحتى 6% من المنظمات، وOpen Collective صندوق شفاف مثل صندوق curl، والمؤسسات Foundations مثل Linux Foundation وApache، وعلى اليسار التمويل الحكومي مثل Sovereign Tech Fund بمال، والشركات Companies والمتطوعون Volunteers بوقت عمل، وفي الأسفل أن المشروع الذي يعتمد على متطوع واحد يصبح عامل الحافلة فيه واحداً كما في XZ Utils](https://arabroot.io/content/images/2026/10/oss-governance-08-funding.webp)

مصادر المال ووقت العمل التي يعيش عليها المشروع المفتوح

والوقت التطوعي لا يقتصر على كتابة الكود، فمؤتمر FOSDEM في بروكسل مثلاً، كما [يقول موقعه](https://fosdem.org/2026/about/?ref=arabroot.io)، حدث مجاني وغير تجاري ينظمه متطوعون حتى يلتقي فيه مطورو البرمجيات المفتوحة ومشاريعها، والصورة التالية من قاعته الكبرى في دورة 2025:

![قاعة محاضرات كبيرة متدرجة ممتلئة بمئات الحضور أمام شاشة ومنصة في الأسفل، وعلى الجدار شعار جامعة ULB](https://arabroot.io/content/images/2026/10/oss-governance-13-fosdem-2025.webp)

قاعة Janson في جامعة ULB ببروكسل ممتلئة بالحضور في FOSDEM 2025\. الصورة: Lambroso، بترخيص [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:FOSDEM%5F2025%5FClosing%5FTalk%5Ffrom%5Fthe%5Ftop%5Fof%5Fthe%5Fauditorium.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP، والنسخة متاحة بالرخصة نفسها).

📌

في 8 يونيو 2022 كتب Lasse Collin، المشرف على مكتبة الضغط XZ Utils الموجودة في أغلب توزيعات Linux، [رداً في القائمة البريدية للمشروع](https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html?ref=arabroot.io) على رسائل تضغط عليه وتطالب بمشرف جديد، فذكر أن قدرته على العمل محدودة بسبب مشكلات صحية نفسية طويلة، وأن المشروع هواية غير مدفوعة، وأنه يعمل مع شخص اسمه Jia Tan قد يكون له دور أكبر في المستقبل، وكان Jia Tan قد [أرسل أول تعديل صغير](https://www.mail-archive.com/xz-devel@tukaani.org/msg00512.html?ref=arabroot.io) إلى القائمة نفسها في 29 أكتوبر 2021، ثم بنى ووقع أول إصدار باسمه وهو [الإصدار 5.4.2](https://github.com/tukaani-project/xz/releases/tag/v5.4.2?ref=arabroot.io) في 18 مارس 2023\. وفي 29 مارس 2024 [نشر Andres Freund](https://www.openwall.com/lists/oss-security/2024/03/29/4?ref=arabroot.io) في قائمة oss-security أن مستودع xz وملفاته المنشورة تحتوي على باب خلفي Backdoor يؤدي إلى اختراق سيرفرات SSH، وأخذت الثغرة الرقم CVE-2024-3094، و[صفحة المشروع عن الحادثة](https://tukaani.org/xz-backdoor/?ref=arabroot.io) تذكر أن الملفات المضغوطة للإصدارين [5.6.0](https://github.com/tukaani-project/xz/releases/tag/v5.6.0?ref=arabroot.io) الصادر في 24 فبراير 2024 و[5.6.1](https://github.com/tukaani-project/xz/releases/tag/v5.6.1?ref=arabroot.io) الصادر في 9 مارس 2024 تحتوي على الباب الخلفي، وأن Jia Tan هو من أنشأها ووقعها. والدرس هنا للحوكمة قبل الأمن: مشرف واحد مرهق بلا تمويل هو نقطة ضعف في كل سيرفر يعتمد على مشروعه، والثقة التي تمنح لمساهم جديد بسبب الضغط وقلة الوقت قد تستغل بصبر سنوات، لذلك اعرف عامل الحافلة في المشاريع التي تعتمد عليها، وساهم في تمويلها أو مراجعتها، أما الدفاعات التقنية ضد هذا النوع من الهجمات فقد شرحناها في [مقال أمن سلسلة التوريد البرمجية](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#social-engineering).

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

![خط زمني من 2021 إلى 2024: في 29 أكتوبر 2021 يرسل Jia Tan أول تعديل صغير إلى القائمة البريدية، وفي يونيو 2022 رسائل تطالب بمشرف جديد ورد Lasse Collin بأن قدرته محدودة والمشروع هواية غير مدفوعة، وفي 18 مارس 2023 أول إصدار يبنيه Jia Tan ويوقعه وهو 5.4.2، وتحت الخط شريط دور Jia Tan من مساهم بتعديلات صغيرة إلى من يعمل مع المشرف ثم من يبني الإصدارات، وعلى اليمين الأسابيع الخمسة الأخيرة: 24 فبراير 2024 الإصدار 5.6.0 بالباب الخلفي، و9 مارس 2024 الإصدار 5.6.1، و29 مارس 2024 إعلان Andres Freund والرقم CVE-2024-3094](https://arabroot.io/content/images/2026/10/oss-governance-09-xz-timeline.webp)

قصة XZ Utils من أول تعديل في 2021 إلى اكتشاف الباب الخلفي في 29 مارس 2024

## النسخة البديلة Fork: آخر أداة رقابة بيد المجتمع

الرخصة المفتوحة تعطي أي شخص الحق في أخذ الكود وإكمال تطويره باسم جديد، وهذا الحق هو الضمان الأخير ضد أي حوكمة سيئة، فإذا لم يعد المجتمع يثق بمن يدير المشروع، يستطيع أن يخرج بنسخته. وقد شرحنا في [مقال الرخص](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/#today) النسخ البديلة التي ولدت بسبب تغيير الرخص مثل OpenTofu وValkey، وهنا مثالان على نسخ ولدت بسبب الحوكمة نفسها:

- **LibreOffice:** تقول صفحة [تاريخ The Document Foundation](https://www.documentfoundation.org/history?ref=arabroot.io) إن المؤسسة أعلنت في سبتمبر 2010 بفريق من المساهمين القدامى في OpenOffice.org، وإن مهمتها أن تحول مجتمع LibreOffice إلى منظمة جديدة مفتوحة ومستقلة، وقد بدأت بلجنة توجيه مؤقتة يحل محلها مجلس إدارة منتخب خلال سنة. والمشروع اليوم [يصف نفسه](https://www.libreoffice.org/about-us/who-are-we/?ref=arabroot.io) بأنه مبني في الأصل على OpenOffice.org وأنه أكثر خلفائه نشاطاً في التطوير.
- **io.js وNode.js:** صدر io.js 1.0.0 في يناير 2015 كما في [سجل تغييراته](https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG%5FIOJS.md?ref=arabroot.io)، مبنياً على كود Node.js من مستودع joyent/node، ثم أعلن قادة المشروعين في مايو 2015 أنهم [يبنون مؤسسة محايدة لـ Node.js](https://nodejs.org/en/blog/community/node-leaders-building-open-neutral-foundation?ref=arabroot.io) بحوكمة مفتوحة، وفي سبتمبر 2015 [صدر Node.js 4.0.0](https://nodejs.org/en/blog/announcements/foundation-v4-announce?ref=arabroot.io) الذي جمع المشروعين في قاعدة كود واحدة. أي أن النسخة البديلة هنا لم تقتل المشروع الأصلي، وإنما غيرت حوكمته ثم عادت إليه.

والصورة التالية ترسم المثالين على خط زمني، فالأول انفصل وبقي مستقلاً، والثاني انفصل ثم عاد:

![مساران: الأول خط رمادي OpenOffice.org يتفرع منه في سبتمبر 2010 خط أخضر LibreOffice بعد إعلان The Document Foundation، مع لجنة توجيه مؤقتة ثم مجلس إدارة منتخب، والثاني خط رمادي joyent/node يتفرع منه في يناير 2015 خط برتقالي io.js 1.0.0، وفي مايو 2015 إعلان بناء مؤسسة محايدة، ثم يعود الخطان في سبتمبر 2015 إلى خط أخضر واحد Node.js 4.0.0](https://arabroot.io/content/images/2026/10/oss-governance-10-forks.webp)

النسخة البديلة كأداة رقابة، حيث انفصل LibreOffice وبقي مستقلاً، وعاد io.js إلى Node.js بحوكمة جديدة

ومجتمع LibreOffice الذي خرج من OpenOffice.org يلتقي اليوم في مؤتمر خاص به اسمه [LibreOffice Conference](https://conference.libreoffice.org/?ref=arabroot.io).

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

## قائمة تحقق Checklist قبل أن تعتمد على مشروع

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

- **الرخصة License:** هل هي معتمدة من OSI؟ وهل تغيرت من قبل؟
- **حقوق المساهمات DCO أو CLA:** هل تبقى الحقوق مع المساهمين، أم تجمعها جهة واحدة تستطيع تغيير الرخصة؟
- **الجهة المستضيفة Foundation:** هل المشروع في مؤسسة محايدة، وفي أي مرحلة نضج؟ أم تملكه شركة واحدة؟
- **عدد المشرفين النشطين Active Maintainers:** كم شخصاً يدمج الكود فعلاً في آخر ستة أشهر؟ ومن أي شركات؟
- **طريقة القرار Decision Process:** هل يوجد GOVERNANCE.md أو ما يقوم مقامه؟ وهل تكتب القرارات الكبيرة في RFC أو ما يشبهها؟
- **قواعد السلوك Code of Conduct:** هل توجد، ومعها طريقة حقيقية للإبلاغ؟
- **سياسة الأمان Security Policy:** هل يوجد SECURITY.md، وهل تصدر الإصلاحات الأمنية بانتظام؟
- **التمويل Funding:** من يدفع للمشرفين؟ وهل يمكن لجهتك أن تساهم؟

والصورة التالية تجعل القائمة بطاقة تقييم تملؤها لكل مشروع، مع المكان الذي تجد فيه إجابة كل بند:

![بطاقة تقييم من ثمانية بنود، لكل بند سؤال ومكان الإجابة وثلاث خانات واضح وغير واضح وخطر: الرخصة License في LICENSE، وحقوق المساهمات DCO أو CLA في CONTRIBUTING.md، والجهة المستضيفة Foundation في صفحة المؤسسة، والمشرفون النشطون في تبويب Insights ثم Contributors، وطريقة القرار في GOVERNANCE.md ووثائق RFC، وقواعد السلوك في CODE_OF_CONDUCT.md، وسياسة الأمان في SECURITY.md ونتيجة Scorecard، والتمويل في Sponsors أو Open Collective، وفي الأسفل أن OpenSSF Scorecard يجيب آلياً عن جزء من البنود بفحوص Code-Review وMaintained وSecurity-Policy وLicense](https://arabroot.io/content/images/2026/10/oss-governance-11-checklist.webp)

قائمة التحقق كبطاقة تقييم تملؤها قبل أن تعتمد على أي مشروع

ولاحظ أن البطاقة تقيم المشروع نفسه، أما الثغرات المعروفة في الإصدار الذي تستخدمه فعلاً فيكشفها فحص الاعتماديات SCA الذي شرحناه في [دليل OSV-Scanner وDependency-Track](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF%D9%8A%D8%A7%D8%AA-sca-%D9%85%D8%B9-osv-scanner-%D9%88-dependency-track/).

وتستطيع أن تقرأ جزءاً من هذه الإجابات من GitHub مباشرة، ففي تبويب Insights ثم Contributors [رسم بياني](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors?ref=arabroot.io) لأكثر مئة مساهم، ولا تحسب فيه التزامات الدمج Merge Commits والالتزامات الفارغة، ولاحظ أن بعض هذه الإحصاءات لا تتوفر للمستودعات التي فيها أكثر من عشرة آلاف Commit. والطريقة الثانية هي مشروع [OpenSSF Scorecard](https://github.com/ossf/scorecard?ref=arabroot.io) الذي يفحص المستودعات العامة آلياً ويعطي كل فحص درجة من 0 إلى 10، وتستطيع تشغيله بنفسك من سطر الأوامر Command Line، أو قراءة نتائجه المنشورة للمستودعات المشهورة من الواجهة البرمجية API دون تثبيت شيء. والمثال التالي يقرأ نتيجة Kubernetes ويعرض الفحوص المتعلقة بالحوكمة، ويستخدم `jq` لتنسيق ملف JSON:

```bash
curl -s https://api.securityscorecards.dev/projects/github.com/kubernetes/kubernetes \
  | jq -r '"\(.date) score=\(.score)", (.checks[] | select(.name | IN("Code-Review","Maintained","Security-Policy","License","CII-Best-Practices")) | "\(.name)=\(.score): \(.reason)")'
```

والمخرج سوف يكون كما يلي:

```text
2026-10-05 score=7.6
Code-Review=10: all changesets reviewed
Maintained=10: 30 commit(s) and 17 issue activity found in the last 90 days -- score normalized to 10
Security-Policy=10: security policy file detected
CII-Best-Practices=5: badge detected: Passing
License=10: license file detected
```

في المخرج أعلاه لاحظ التالي:

- السطر الأول تاريخ آخر فحص والدرجة الكلية، والنتيجة تتغير مع الوقت، فإذا شغلت الأمر بعد أسابيع سوف ترى تاريخاً ودرجة مختلفين.
- Code-Review يقيس هل تمر التغييرات بمراجعة قبل الدمج، وMaintained يقيس النشاط في آخر 90 يوماً، وSecurity-Policy يبحث عن ملف سياسة الأمان، وCII-Best-Practices يقرأ شارة [OpenSSF Best Practices](https://www.bestpractices.dev/?ref=arabroot.io) التي تمنح للمشاريع بعد إجابتها عن قائمة معايير.
- الدرجة رقم مساعد وليست حكماً، فالفحص الآلي لا يعرف هل المشرفون الثلاثون من شركة واحدة أم من عشر شركات، ولا يقرأ ملف الحوكمة، لذلك استخدمه مع القائمة أعلاه وليس بدلاً منها.

ولاحظ أن الواجهة لا تحتوي على نتيجة لكل مستودع، وقد تجد لبعض المشاريع نتيجة قديمة منذ سنوات، فانظر إلى التاريخ في السطر الأول قبل أن تعتمد على الأرقام، وقد شرحنا مكان Scorecard بين بقية دفاعات السلسلة في [مقال أمن سلسلة التوريد البرمجية](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#scorecard).

## كيف تساهم الجامعات والفرق في المنطقة؟

أغلب ما تعتمد عليه جامعاتنا وجهاتنا وشركاتنا الناشئة من أدوات مفتوحة يصونه أشخاص خارج المنطقة، والمساهمة فيه ليست تبرعاً، وإنما طريقة لضمان أن تبقى هذه الأدوات حية وأن تدعم العربية جيداً. وقد شرحنا في مقال [المصادر المفتوحة للجامعات](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%A7%D8%AF%D8%B1-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D9%84%D9%84%D8%AC%D8%A7%D9%85%D8%B9%D8%A7%D8%AA/#contribute) كيف تجعل الجامعة المساهمة جزءاً من مشاريع التخرج والتدريب، وكيف ينظمها مكتب المصادر المفتوحة OSPO، وفي مقال [المصادر المفتوحة للجهات الحكومية](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%A7%D8%AF%D8%B1-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D9%84%D9%84%D8%AC%D9%87%D8%A7%D8%AA-%D8%A7%D9%84%D8%AD%D9%83%D9%88%D9%85%D9%8A%D8%A9/#contributing) لماذا يجب أن ترسل الجهة إصلاحاتها إلى المشروع الأصلي بدلاً من الاحتفاظ بها في نسخة خاصة. وما يضيفه هذا المقال هو أن تقرأ حوكمة المشروع قبل أن تبدأ: هل يطلب DCO أم CLA، ومن يراجع الترجمة العربية، وهل يوجد فريق للترجمة يمكن أن ينضم إليه طلابك، فالمساهمة التي تتبع طريقة المشروع تدمج، والمساهمة التي تتجاهلها تبقى مفتوحة سنوات.

[![](https://arabroot.io/content/images/2026/10/oss-universities-cover-cover.webp)دليلالمصادر المفتوحة للجامعات: خطة وأدوات بالترتيبدليل لقيادة الجامعة يشرح ما تكسبه فعلاً من المصادر المفتوحة وما تكلفه، وبأي ترتيب تنقل خدماتها إليها.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%A7%D8%AF%D8%B1-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D9%84%D9%84%D8%AC%D8%A7%D9%85%D8%B9%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/oss-startups-cover-cover.webp)دليلالمصادر المفتوحة في الشركة الناشئة: ماذا تستضيف بنفسك ومتى؟دليل للمدير التقني في الشركة الناشئة يبين ما تستضيفه بنفسك من اليوم الأول، وما تتركه للخدمات المدارة حتى يكبر الفريق.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B5%D8%A7%D8%AF%D8%B1-%D8%A7%D9%84%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D9%84%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%AA%D9%82%D9%86%D9%8A-%D9%81%D9%8A-%D8%A7%D9%84%D8%B4%D8%B1%D9%83%D8%A7%D8%AA-%D8%A7%D9%84%D9%86%D8%A7%D8%B4%D8%A6%D8%A9/)

## أخطاء شائعة

- **الحكم على المشروع بعدد النجوم:** النجوم تقيس الشهرة، والذي يهمك هو عدد المشرفين النشطين وطريقة القرار ومن يملك الرخصة.
- **إرسال طلب دمج كبير دون نقاش:** اسأل في البلاغ أولاً، والسبب أن المشرفين قد يرفضون الفكرة نفسها فتضيع أسابيع من عملك.
- **نسيان التوقيع في المشاريع التي تطلب DCO:** فيفشل الفحص على طلبك، واستخدم `git commit -s` من البداية.
- **توقيع CLA دون قراءتها:** خاصة إذا كنت تساهم باسم جهة عملك، فقد تحتاج موافقة الجهة نفسها.
- **فتح بلاغ عام عن ثغرة أمنية:** استخدم SECURITY.md أو الإبلاغ الخاص.
- **الرد على البلاغ الغاضب بغضب:** رد مرة واحدة على الجزء التقني، ثم استخدم أدوات الإشراف إذا احتجت.
- **إضافة ملف قواعد سلوك دون بريد للإبلاغ ودون شخص يطبقه:** القواعد التي لا يطبقها أحد أسوأ من غيابها، لأنها تعطي انطباعاً كاذباً بالأمان.
- **الاعتماد على حق النسخ البديلة وحده:** النسخة البديلة تحتاج مجتمعاً يحملها، فتأكد أنه موجود قبل أن تعتبرها خطة بديلة.

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- حوكمة المشروع تحدد من يقرر وكيف ومن يستطيع تغيير الرخصة، وهي أهم من النجوم وعدد التنزيلات عند اختيار أداة لنظام حرج.
- النماذج الشائعة ستة: شخص واحد مثل curl، ومساهمة مفتوحة بالتوافق مثل Node.js، وطريقة Apache بلجانها وأصواتها، ودستور وانتخابات مثل Debian، ومجلس توجيه مثل Kubernetes وFedora، وشركة واحدة مثل GitLab، والمؤسسات المحايدة تستضيف كثيراً منها.
- سلم المساهمة يبدأ بالمستخدم وينتهي بمالك جزء من المشروع، والصلاحيات تكتب في ملفات مثل OWNERS وCODEOWNERS وMAINTAINERS، وتسحب ممن توقف عن العمل.
- التغييرات الكبيرة تمر بوثيقة تصميم مثل RFC وKEP قبل الكود، والقرار يحسم بالتوافق الصامت أو بفترة تعليق أخيرة أو بالتصويت.
- DCO سطر توقيع في كل Commit والحقوق تبقى مع المساهمين، وCLA اتفاقية قد تسمح لصاحب المشروع بتغيير الرخصة، فاقرأها قبل التوقيع.
- قواعد السلوك تحتاج من يطبقها، وسلم Contributor Covenant يبدأ بالتحذير وينتهي بالمنع الدائم، وفي GitHub أدوات للإخفاء والقفل وحدود التفاعل والمنع.
- قصة XZ Utils تبين أن المشرف الواحد المرهق بلا تمويل نقطة ضعف في كل سيرفر يعتمد على مشروعه، والتمويل والمراجعة جزء من الأمان.
- النسخة البديلة هي الضمان الأخير، كما في LibreOffice وio.js، ولكنها تحتاج مجتمعاً حقيقياً يحملها.

[![](https://arabroot.io/content/images/2026/10/open-source-licenses-cover-cover.webp)دليلما هي البرمجيات مفتوحة المصدر؟ القصة وأشهر الرخصكيف بدأت البرمجيات الحرة والمفتوحة، وما الفرق بين الحر والمجاني، وكيف تعرف ما تسمح به رخصة أي مشروع قبل أن تبني عليه.](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/language-specs-cover-cover.webp)دليلاللغة شيء والمترجم شيء آخر: من يقرر مستقبل لغات البرمجة؟لماذا لا تصح جمل مثل «Python بطيئة»، وما الفرق بين مواصفة اللغة والبرامج التي تطبقها، ومن يقرر مستقبلها.](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%87%D8%A7-%D9%88%D8%AD%D9%88%D9%83%D9%85%D8%AA%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/git-basics-cover-cover.webp)دليلإدارة النسخ وGit للمبتدئين: لماذا نحتاجها وكيف تعمللماذا تضيع الملفات بأسماء final\_v2 ويمسح الزملاء عمل بعضهم، وكيف يحل Git ذلك على مشروع حقيقي من أول commit.](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D9%88-git-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/git-workflows-cover-cover.webp)دليلGit في العمل اليومي: الدمج والتراجع دون أن تخسر عملكمتى تستخدم Merge ومتى تستخدم Rebase، وكيف تنقل إصلاحاً إلى فرع الإصدار أو تسترجع عملاً ظننت أنه ضاع.](https://arabroot.io/articles/git-merge-%D9%88-rebase-%D9%88-cherry-pick/)[![](https://arabroot.io/content/images/2026/10/supply-chain-cover-cover.webp)دليلأمن سلسلة التوريد البرمجية Software Supply Chain للمبتدئينكل ما بين كود غيرك وسيرفرك قد يحمل كود المهاجم، وهنا تعرف التهديدات الحقيقية بحوادث موثقة والدفاع المناسب لكل حلقة.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)

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

- أكتوبر 2026: كتابة المقال، وقراءة ملفات الحوكمة من مصادرها الرسمية، وتنفيذ مثال `git commit -s` في مستودع مؤقت على Git 2.48.1، وقراءة نتيجة OpenSSF Scorecard ل Kubernetes من الواجهة البرمجية مع jq 1.8.2 داخل Container.
- أكتوبر 2026: إضافة رسومات للاستدامة والتفرعات والقائمة، وصور حقيقية.