ماذا يحدث عندما يفقد مشروع المصادر المفتوحة قائده؟

عندما تنحى ريان دال عن Node.js، نجا المشروع، لكن ذلك استغرق سنوات من إعادة هيكلة الحوكمة، وتفرّع عنه مشروع io.js، ثم مصالحة قبل أن يستقر. وعندما استقال غيدو فان روسوم من منصب «الديكتاتور الخيّر مدى الحياة» في Python، قضى المجتمع شهورًا في النقاش حول نماذج الحوكمة قبل أن يستقر على مجلس توجيه. وحين واجه مشروع Deno أسئلة قيادية خاصة به، وصلت تداعياتها إلى كل مطور راهن على هذه البيئة التشغيلية.

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

مشكلة عامل الحافلة

«عامل الحافلة» هو عدد الأشخاص الذين يجب أن تدهسهم حافلة قبل أن ينهار المشروع، وهو رقم منخفض بشكل مقلق في معظم مشاريع المصادر المفتوحة. وجدت دراسة عام 2015 أن أكثر من 60% من حزم npm لها مُشرف واحد. كما وجد تحليل أحدث للبنية التحتية الحرجة في المصادر المفتوحة أن كثيرًا من المشاريع التي لها ملايين المعتمدين عليها يُدار كل منها شخص أو شخصان، غالبًا كعمل هواية غير مدفوع.

هذه ليست مشكلة افتراضية. كانت OpenSSL، المكتبة التي أمّنت معظم حركة التشفير على الإنترنت، يعمل عليها بشكل رئيسي شخصان في أوقات فراغهما عندما اكتُشفت ثغرة Heartbleed. وحين حذف مؤلف حزمة left-pad، وهي حزمة npm بسيطة من 11 سطرًا، تعطلت آلاف عمليات البناء. أما core-js، التي تُحمَّل أكثر من 25 مليون مرة أسبوعيًا، فيُشرف عليها مطور واحد وصف نفسه علنًا بأنه بالكاد يستطيع تحمل تكلفة الطعام.

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

نماذج الحوكمة وموازناتها

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

نموذج BDFL

يتخذ شخص واحد القرارات النهائية. Python (غيدو فان روسوم)، وLinux (لينوس توروالدز)، وRuby (ماتس)، فأنجح المشاريع غالبًا لديها قائد تقني قوي تشكّل ذوقه وحكمه ملامح المشروع. ميزته واضحة: اتجاه محدد، ورؤية متسقة، وسرعة في اتخاذ القرار. يستطيع الـBDFL أن يقول «لا» للميزات التي لا تناسب المشروع، فيبقى المشروع مركّزًا.

أما فشله فواضح بالقدر نفسه: يرحل الـBDFL ولا توجد خطة لخلافته. كان انتقال Python بعد استقالة غيدو متعثرًا رغم عقود من بناء المجتمع. والمشاريع ذات المجتمعات الأقل نشاطًا كثيرًا ما تنطفئ ببساطة حين يمضي قائدها.

نموذج المؤسسة

مشاريع مثل Apache وEclipse وLinux Foundation تقع تحت مؤسسات غير ربحية لها هياكل حوكمة رسمية: لجان توجيه تقنية، وانتخابات للمساهمين المعتمدين، وعمليات واضحة لاتخاذ القرار. هذا يوفر استمرارية مؤسسية، إذ ينجو المشروع من رحيل الأفراد لأن الهيكل يبقى.

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

نموذج الراعي المؤسسي

React (تابعة لـMeta)، وGo (لـGoogle)، وRust (بدأت مع Mozilla وأصبحت الآن مؤسسة مستقلة)، وTypeScript (لـMicrosoft). كثير من المشاريع الكبرى تدعمها شركات توظف المُشرفين الأساسيين. هذا يحل مشكلة التمويل: يحصل المُشرفون على أجر، ويعملون بدوام كامل، ويستفيد المشروع من الموارد الهندسية للشركة.

الخطر يكمن في التوافق. أولويات الشركات تتغير. أعلنت Mozilla تسريح فريق Rust، وقلّصت Google الاهتمام بمشاريع مفتوحة المصدر وخفضت تمويلها حين تحول تركيز الأعمال. وعندما تختلف المصالح الاستراتيجية للشركة عن مصالح مجتمع المشروع، يكون الاحتكاك حتميًا. والاتجاه الأخير لتغيير التراخيص من قبل الرعاة المؤسسيين (Redis وTerraform وElastic) يوضح مدى هشاشة هذا النموذج.

متى تكون التفرعات صحية

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

أدى تفرع io.js من Node.js إلى دفع Node نحو نموذج حوكمة أكثر انفتاحًا ودورات إصدار أسرع. وعندما اندمج المشروعان من جديد، استفاد Node من ذلك. وأنقذ تفرع LibreOffice من OpenOffice.org المشروع من تراجع اهتمام Sun وOracle. أما MariaDB، المتفرعة عن MySQL بعد استحواذ Oracle، فتستمر كبديل يقوده المجتمع.

وفي الآونة الأخيرة، أدت تغييرات التراخيص إلى تفرعات مثمرة. فعندما غيّرت Elastic ترخيص Elasticsearch، تفرعت عنه Amazon باسم OpenSearch. وعندما غيّرت HashiCorp ترخيص Terraform، تفرّع عنه المجتمع باسم OpenTofu تحت مظلة Linux Foundation. هذه التفرعات موجودة لأن حق التفرع هو الضابط النهائي للمجتمع على قيادة المشروع.

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

دوامة الإرهاق

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

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

إرهاق مُشرفي المصادر المفتوحة ليس قصورًا شخصيًا، بل مشكلة بنيوية: المشاريع تولّد طلبًا لا نهائيًا على وقت وانتباه عدد محدود من الناس، دون آلية مدمجة لإدارة هذا الطلب.

وجد بعض المُشرفين طرقًا للتعامل مع الأمر: حدود صارمة لأوقات الرد، وتفويض فرز المشكلات لأعضاء المجتمع، والصيانة المدفوعة عبر GitHub Sponsors أو Open Collective، أو ببساطة القبول بأوقات استجابة أبطأ. لكن هذه الحلول تتطلب مقاومة واعية للضغط للبقاء متاحًا دائمًا، وهو ما يتعارض مع ثقافة كثير من مجتمعات المصادر المفتوحة.

شكل الخلافة الصحية

نجحت مشاريع قليلة في إدارة انتقالات القيادة بشكل جيد، وتشترك في أنماط مشتركة.

• معرفة موزعة، لا كود موزع فقط. «المعرفة القبلية» للمشروع، أي لماذا اتُّخذت قرارات معينة، وما البدائل التي نوقشت، وما مبادئ التصميم، موثقة ولا تقتصر على رأس شخص واحد. تخدم سجلات قرارات المعمارية (ADRs) ومقترحات RFC التفصيلية هذا الغرض.
• أشخاص متعددون لديهم صلاحية الدمج وسلطة الإصدار. إذا كان شخص واحد فقط يستطيع إطلاق إصدار، فهو نقطة فشل واحدة. المشاريع الصحية لديها 3-5 أشخاص على الأقل يستطيعون إصدار نسخ جديدة بشكل مستقل.
• وثائق حوكمة صريحة. كيف تُتخذ القرارات؟ من يملك السلطة على ماذا؟ كيف يُضاف مُشرفون جدد؟ المشاريع التي تجيب عن هذه الأسئلة قبل الأزمة تدير الخلافة بشكل أفضل من تلك التي ترتجل.
• انتقالات تدريجية، لا رحيل مفاجئ. أفضل انتقالات القيادة تحدث حين يقلّص القائد المغادر مشاركته عمدًا على مدى شهور، ويرشد خلفاءه، ويسلّمهم السلطة بشكل صريح. الرحيل المفاجئ، حتى لو كان بنوايا حسنة، يخلق فراغًا.
• الاستدامة المالية. المشاريع ذات التمويل الموثوق، سواء من المؤسسات أو الرعاة المؤسسيين أو تمويل المجتمع، تنجو من الانتقالات بشكل أفضل لأن المُشرفين الجدد يمكن تعويضهم عن وقتهم. طلب من شخص أن يرث وظيفة بدوام كامل غير مدفوعة أمر يصعب قبوله.

ماذا ينبغي على المستخدمين والشركات أن يفعلوا

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

1. دقّق عامل الحافلة في اعتمادياتك. انظر إلى مشاريع المصادر المفتوحة الحرجة في منظومتك. كم عدد المُشرفين النشطين فيها؟ متى كان آخر إصدار؟ ما مدى سرعة معالجة الثغرات الأمنية؟ المشروع الذي له مُشرف واحد وثغرة أمنية عمرها ستة أشهر خطر يجب أن تعرفه.
2. موّل ما تستخدمه. إذا كان مشروع حرجًا لعملك، ساهم في تمويله. توفر GitHub Sponsors وOpen Collective وTidelift آليات لذلك. تكلفة تمويل مُشرف تبدو تافهة مقارنة بتكلفة توقف اعتمادية حرجة عن الصيانة.
3. ساهم في المشروع الأصلي. إصلاحات الأخطاء وتحسين الوثائق وفرز المشكلات تخفف العبء عن المُشرف، وتمنح فريقك إلمامًا بقاعدة الكود. وإذا احتاج المشروع يومًا إلى مُشرفين جدد، ستكون في موقع يسمح لك بالتقدم.
4. ضع خطة طوارئ. بالنسبة للاعتماديات الحرجة، اعرف ما الذي ستفعله إذا هُجر المشروع. هل يمكنك التفرع عنه وصيانته؟ هل هناك بديل يمكنك الانتقال إليه؟ الوقت المناسب للإجابة عن هذه الأسئلة هو قبل أن تحتاجها.

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