دليل الممارس: تقييم الجدوى
إذا لم تكن قد قرأت بالفعل دليل الممارس: مقدمة - الأشياء التي يجب التفكير فيها عند تفسير المقاييس، يرجى التوقف الآن وقراءة هذا الدليل.
الجمهور / النطاق
هذا الدليل مخصص في المقام الأول لمكاتب برامج المصدر المفتوح (OSPOs) والفرق الأخرى داخل المؤسسات التي تحتاج إلى فهم جدوى المخاطر المرتبطة ببرامج المصدر المفتوح التي تستهلكها.
المقدمة
يمكن العثور على برامج مفتوحة المصدر في 97٪ من قواعد التعليمات البرمجية (Black Duck 2025)، ولكن مثل معظم البرامج، تتفاوت الجودة على نطاق واسع، وبعض مشاريع المصدر المفتوح أكثر قابلية للتطبيق من غيرها على المدى الطويل. إن تقييم قابلية التطبيق والمخاطر التي تأتي مع الانخراط في مشاريع مفتوحة المصدر محددة أمر مهم لتجنب الانقطاعات في عملك التي تعيق القدرة على تقديم المنتجات والخدمات للعملاء، وخاصة عندما يصبح الاعتماد الرئيسي غير قابل للتطبيق فجأة. من المهم التفكير في قابلية التطبيق والمخاطر على أنهما على استمرارية لأن المشاريع ستكون أكثر أو أقل قابلية للتطبيق عبر مجموعة متنوعة من الفئات، وما إذا كان يجب عليك تبني مشروع وقبول المخاطر التي تأتي معه هو قرار استراتيجي يعتمد على احتياجات مؤسستك وحالات استخدامك للتقنيات المرتبطة بها. إن تقييم قابلية تطبيق مشاريع المصدر المفتوح، وخاصة تلك التي لديها القدرة على التأثير على عملك، هو خطوة أولى جيدة نحو إدارة المخاطر وتقليل فرص حدوث اضطرابات محتملة في الأعمال.
الشركات التي تستخدم برامج مفتوحة المصدر (أي، كلهم) بدأوا يفكرون أكثر فأكثر في فواتير المواد، والثغرات الأمنية، ومخاطر التراخيص. وقد شُجِّع هذا بشكل خاص من خلال التطورات الأخيرة جهود الولايات المتحدة و مبادئ السلوك قانون المرونة السيبرانية للاتحاد الأوروبي (CRA) فيما يتعلق بقوائم مواد البرمجيات (SBOMs). يُعد هذا التوجه فرصة جيدة لرصد سلاسل توريد البرمجيات والإبلاغ عنها. يمكننا جميعًا أن نتعلم من معرفة ما تحتويه برمجياتنا من تبعيات! انتشار SBOMS, كبار المستشارين (اختبار أمان التطبيقات الثابتة)، و SCA تتيح أدوات فحص (تحليل تركيب البرمجيات) لمستخدمي ومطوري البرمجيات فهم محفظة مخاطرهم بشكل أفضل. ويجد معظم الناس فائدة كبيرة من استخدام هذه التقارير للكشف عن الثغرات الأمنية بالغة الأهمية، ومعلومات التراخيص، وغيرها من المشكلات التي قد تؤثر على جدوى مشروع مفتوح المصدر تستخدمه.
يمكن أن يكون الأمان عاملاً مهماً في تحديد جدوى مشروع مفتوح المصدر، ولكن أمان أي مكون برمجي لا يرقى إلى مستوى أمان تبعياته، لذا فإن تقييم الجدوى يتطلب النظر إلى ما هو أبعد من مجرد مشروع فردي. من المهم ملاحظة أن الحزم الشائعة لا تتبع ممارسات أمان جيدة (امتياز، ٢٠٢٢). ويتجاوز هذا مجرد التفكير في اختيار التبعيات إلى النظر في خطط تحديث هذه التبعيات، حيث يزداد احتمال مواجهة مشاكل أمنية بأربع مرات عند استخدام تبعيات قديمة (كوكس وآخرون، ٢٠١٥).
مع أن الأمان قد يكون من أهم الأولويات عند التفكير في جدوى مشروع مفتوح المصدر، إلا أن هناك عوامل أخرى يجب أخذها في الاعتبار. من المهم أيضًا تقييم كيفية إدارة المشروع وكيفية تعاون المجتمع لبناء البرنامج. لدينا أيضًا بعض المقاييس الاستراتيجية لتقييم جدوى أي مشروع. يقدم هذا الدليل نصائح لتقييم الجدوى عبر جميع هذه الفئات الأربع: الامتثال والأمان، والحوكمة، والمجتمع، والاستراتيجية.
التحديات
في العديد من الشركات، لا توجد عملية دقيقة لاختيار التبعيات الأنسب للاستمرار مع مرور الوقت. غالبًا ما تختار فرق الإنتاج، أو حتى مطورو البرامج الأفراد، مشاريع مفتوحة المصدر لتلبية حاجة تقنية معينة دون أي تقييم لجدوى المشروع أو المخاطر التي قد يتعرضون لها عند استخدامه. تشمل الأسئلة الصعبة ما يلي:
- ما الذي يجب علينا البحث عنه أيضًا في اختياراتنا للبرمجيات مفتوحة المصدر؟
- ما هي الإرشادات التي يمكننا تقديمها لتشجيع اتخاذ القرارات الجيدة ليس فقط فيما يتعلق بصيانة البرامج؟
- هل ينبغي أن تكون هذه الإرشادات مختلفة عما يجب أن تكون عليه عندما يقرر الأشخاص البرنامج الذي يريدون استخدامه؟
- هل يمكننا توفير الأدوات والمقاييس لتوجيه القرارات؟
- كيف يمكننا تقليل المخاطر في اختياراتنا، وتوفير بنية تحتية أكثر استدامة للبرمجيات؟
غالبًا ما تضطر الفرق المهتمة بتوجيه النقاشات التقنية إلى الاعتماد على هياكل أمنية أو تراخيص قائمة. يتمثل التحدي الرئيسي الذي يواجه خبراء الموضوع الذين يتعاملون مع هذه الأطر في نقص المقاييس والأنظمة التي توضح الجوانب المهمة الأخرى عند اختيار تبعية مفتوحة المصدر. باستخدام قابلية التطبيق، يمكننا إنشاء قياسات تسمح بتحليل أكثر شمولاً لتبعيات البرامج.
الدروس المستفادة
لقد شهدنا مؤخرًا موجة من مشاريع المصدر المفتوح ذات المصدر الواحد، والتي تُعاد ترخيصها بموجب اتفاقيات ترخيص المساهمين (CLAs)، بتراخيص أكثر تقييدًا. وفي بعض الحالات، أدت إعادة الترخيص إلى انقسام جذري للمشروع الأصلي. ومن الأمثلة على ذلك Elasticsearch/OpenSearch، وTerraform/OpenTofu، وRedis/Valkey. قد تُسبب عمليات إعادة الترخيص هذه والانقسامات الناتجة عنها اضطرابًا للشركات والأفراد الذين يستخدمون مشاريع المصدر المفتوح الأصلية (فوستر 2024). عند حدوث ذلك، غالبًا ما تُسارع الشركات إلى اتخاذ قرار بشأن ما إذا كان بإمكانها الاستمرار في استخدام المشروع بموجب الترخيص الجديد، وما إذا كان عليها دفع رسوم ترخيص، أو الانتقال إلى تقنية أخرى (ربما الانقسام).
بالإضافة إلى إعادة الترخيص، قد تتخذ الشركات قرارات تجارية أخرى قد تؤدي إلى وقف تمويل الموظفين للعمل على مشاريع مفتوحة المصدر، مما قد يؤدي إلى فقدان المشاريع لعدد كبير من المشرفين عليها دفعة واحدة (إيجبال، ٢٠١٦)، مما يجعلها أقل جدوى. وجد أفيلينو وآخرون (٢٠١٩) أنه حتى المشاريع الشائعة قد تُهمل نهائيًا، وإذا كان معظم العمل يُنجزه شخص واحد أو عدد قليل من الأشخاص، فإن ذلك يزيد من خطر عدم استدامة المشروع إذا لم يعد هذا الشخص أو هؤلاء الأشخاص يعملون فيه.
على مدار السنوات القليلة الماضية، واجهنا العديد من الثغرات الأمنية البارزة التي أظهرت مدى خطورة المشاكل المتعلقة بجدوى المشاريع واسعة الانتشار. في حالة OpenSSL، علم الكثيرون وقت ثغرة Heartbleed الأمنية أن هذا المشروع واسع الانتشار كان يُدار من قِبل شخصين مُرهقين بالعمل ويتقاضون أجورًا زهيدة، وكانا يُكافحان لمواكبة العمل الذي يتطلبه OpenSSL. أظهر مثال مشابه، بعد بضع سنوات، في مشروع XZ ما يُمكن أن يحدث عندما يُشارك شخص ما في المشروع ويُقدم مساهمات جيدة كافية لإقناع مُشرف مُرهق بالعمل بالسماح له بالمساعدة في صيانة المشروع قبل إدخال برمجيات خبيثة في النهاية. يُسلط هذان المثالان الضوء على أهمية تقييم جدوى مشاريع المصدر المفتوح التي نستخدمها. بناءً على ذلك، نُقيّم مُعامل غياب المُساهمين لفهم عدد المُشرفين الذين يُساهمون في غالبية برمجيات المشروع كما في حالة XZ. يُمكننا أيضًا فهم حجم التغييرات، وكيف تتطور مع مرور الوقت، لفهم متى تُعاني المشاريع من التعقيد ونقص المساهمة - كما في حالة OpenSSL.
هذه مجرد أمثلة قليلة على ما قد يجعل المشاريع أكثر خطورةً وأقل جدوى بمرور الوقت. بتقييم الجدوى مُسبقًا، قد تُقرر المؤسسة عدم استخدام مشروع مفتوح المصدر مُعين. في حالات أخرى، قد تُقرر المؤسسة استخدام مشروع أقل جدوى، مع العمل ضمن نطاق المشروع على تحسين الجدوى، وبالتالي التخفيف من بعض المخاطر التي تم تحديدها أثناء التقييم.
كيفية اتخاذ الإجراءات
من الشائع التركيز على الثغرات الأمنية والترخيص عند تقييم المخاطر المرتبطة باستخدام مشروع برمجيات مفتوحة المصدر؛ ومع ذلك، هناك العديد من الجوانب الأخرى التي ينبغي أخذها في الاعتبار. تُقسّم نماذج مقاييس قابلية البقاء في CHAOSS قابلية البقاء إلى أربع فئات رئيسية، تحتوي كل فئة على العديد من المقاييس، ولكن مع وجود بعض التداخل في المقاييس التي تظهر في أكثر من فئة من هذه الفئات: الامتثال والأمن والحوكمة والمجتمع و الإستراتيجيات.
يتناول باقي هذا القسم المقاييس التي نستخدمها وأسباب ترابطها. لقد لخّصنا المقاييس في كل فئة، مع لمحة عامة عن أسباب ترابطها. سنتناول أيضًا عرض القيمة للمقاييس التي تتداخل بين الفئات، ونقدم اقتراحات للإجراءات والتخفيف.
الامتثال والأمان
يُقيّم قسم الامتثال والأمان مدى ملاءمة ترخيص المشروع، ومخاطر الثغرات الأمنية، وأنشطة الصيانة. من المهم أن يلتزم المستخدمون بأي مسؤوليات قد تقع على عاتقهم تجاه المؤسسة أو تجاه مُنشئي مشروع OSS.
مقاييس الفوضى:
- هذا مقياس بديل لضمان استجابة المشروع للحوادث الأمنية، ووجود حماية كافية لتفسير استراتيجية امتثال وأمان موثوقة بشكل عام. كما أنه يتجنب استخدام فحص SCA/SAST المكلف في كل مشروع مفتوح المصدر.
- يتم استخدام تغطية الترخيص لاتخاذ القرارات بشأن مخاطر استخدام البرامج غير المرخصة.
- توفر التراخيص المعلنة الشفافية بشأن تعارضات التراخيص المحتملة الموجودة في حزم البرامج، ويمكن استخدامها لتحديد ما إذا كانت حالة استخدام البرنامج متوافقة مع الترخيص المقدم ومتوافقة مع سياسات الترخيص التنظيمية.
- توفر التراخيص التي تتوافق مع معيار OSI الثقة في كيفية استخدام البرنامج بما يتوافق مع تلك التراخيص.
- يوفر هذا المقياس طريقة للنظر في معدلات الاستجابة المختلفة للعيوب عندما تحدث بين المشاريع.
- ويضمن هذا تضمين تبعيات المشروع أيضًا في أي تقييم للجدوى من خلال النظر في كل من المشروع الذي يتم تقييمه إلى جانب تبعياته.
- يوفر هذا المقياس مقياسًا لمدى حداثة اعتماد البرامج والذي يسلط الضوء على المخاطر المرتبطة باستخدام المشاريع التي قد تنطوي على تكلفة صيانة مخفية أو ثغرات أمنية بسبب عدم تحديث التبعيات بانتظام.
اعتبارات إضافية:
- وهذا يسمح لنا بالتفكير في كيفية استجابة المشروع للثغرات الأمنية.
- ينبغي أن تتضمن وثائق سياسة أمن المشروع آليةً تسمح لأي شخص بالإبلاغ عن الثغرات الأمنية سرًا، والتعامل معها بسرعة وكفاءة. كما ينبغي أن تتضمن آليةً لحظر الإبلاغ سرًا عن الثغرات الأمنية للمؤسسات التي تستخدم المشروع، وذلك لإعطائها الوقت الكافي لتطبيق إصلاحات أمنية قبل الكشف عنها.
ما يعنيه الامتثال والأمان للاستمرارية
يساعد نموذج القياسات هذا على قياس مدى مراعاة كلٍّ من مجتمع المطورين ومشرفي التطبيق لأمن تطبيقهم وتوافقه مع المعايير. نتوقع استخدام هذه المؤشرات لقياس المخاطر. لدينا معايير فعّالة، مثل الترخيص، حيث قد لا يتوافق الترخيص مع حالة الاستخدام المقصودة، من خلال الشارات والمقاييس الأمنية، إلى سرعة وانتظام صيانة الفريق للتبعيات والعيوب المُبلغ عنها في تطبيقه.
بالإضافة إلى ذلك، وكما هو الحال في النماذج الأخرى، يصعب تتبع أو تصور بعض المقاييس. نترك مرونة في كيفية تصنيف التطبيقات مقارنةً بالمقاييس التي يصعب جمعها. على سبيل المثال: كما هو الحال مع مدة حل العيوب، فإن تحديد عدد سنوات المكتبة المناسب لمشروع ما يبقى دائمًا بيد القائمين على الصيانة. ويتطلب الأمر التفكير في سنوات المكتبة بشكل نقدي، وذلك وفقًا لكيفية أو مكان تشغيل التطبيق، ومدى تكرار تحديثه.
الحكم
يركز مجال الحوكمة بشكل كبير على القائمين على الصيانة وجهودهم، إذ تُسهم حوكمة مشاريع المصدر المفتوح في تحديد عمليات اتخاذ القرار. يُعد فهم "الصيانة" جزءًا مهمًا من جدوى المشروع بشكل عام، لأن القائمين على صيانة المشروع هم حراس التغييرات الواردة والإصدارات الجديدة وتوجهات المشروع المستقبلية.
المقاييس الموجودة فقط في هذه الفئة:
- يقيس تصنيف القضايا مدى إمكانية الوصول إلى قضايا المشروع ومدى شمولها للمساهمين من مختلف مستويات المهارة والخلفيات.
- يقوم تقييم قابلية استخدام المستندات بتقييم مدى نجاح مستندات مشروع مفتوح المصدر في خدمة المساهمين من خلال ضمان الوضوح والقابلية للقراءة والشمولية وإمكانية الوصول.
- يقيس هذا المدة التي يستغرقها المساهمة للوصول إلى المشروع
- ينظر عمر المشكلة إلى المدة التي تظل فيها الأسئلة والاقتراحات والقضايا الأخرى في المشروع دون حلها أو إغلاقها.
- يساعد هذا على فهم ما إذا كان المشروع لديه عدد كافٍ من الصيّانين لمواكبة المساهمات في المشروع.
- هذا المقياس عبارة عن مجموعة من المقاييس الأصغر الأخرى (على سبيل المثال، الإعجابات والنجوم والشارات والشوك والاستنساخ) التي توفر مؤشرات على الاستخدام والتبني (Vargas et. al.، 2024).
- يساعد تكرار الإصدار على فهم المدة التي يستغرقها المشروع لدمج التغييرات وإصلاحات الأمان في إصدار بالإضافة إلى موعد توقع تصحيحات الأمان وإصلاحات الأخطاء والميزات الجديدة.
- يوفر هذا المقياس مقياسًا لمدى حداثة اعتماد البرامج والذي يسلط الضوء على المخاطر المرتبطة باستخدام المشاريع التي قد تنطوي على تكلفة صيانة مخفية أو ثغرات أمنية بسبب عدم تحديث التبعيات بانتظام.
اعتبارات إضافية:
- إن معرفة كيفية حدوث التعاون وكيفية اتخاذ القرارات أمر مهم لتحقيق الجدوى لأنه يوفر الوضوح حول كيفية إدارة المشروع ويعني أن الأشخاص قادرون على تقديم مساهمات من المرجح أن يتم قبولها.
- ينبغي توثيق عمليات التعاون واتخاذ القرار بشكل واضح كجزء من حوكمة المشروع.
- ينبغي توثيق القيادة في المشروع، بما في ذلك هوية هؤلاء القادة وكيفية اختيارهم. ويفضل أن تكون هناك عملية عادلة وشفافة لاختيار القادة، على أن يشغل مناصبهم القيادية أفراد يتمتعون بالخبرة المناسبة والوقت الكافي لقيادة المشروع.
- غالبًا ما يؤثر هيكل الملكية العام على كيفية إدارة المشروع على أساس يومي وكيفية إدراك الآخرين للمشروع.
- توفر المؤسسات المحايدة مجالًا متساويًا حيث يمكن للمساهمين الأفراد المساهمة على قدم المساواة، مما يسمح للشركات بالتعاون معًا في بيئة محايدة حيث لا توجد شركة واحدة تتحكم في المشروع.
- قد تكون المشاريع المملوكة لشركة أو فرد أقل قابلية للتطبيق لأنها يمكن أن تتخذ قرارات أحادية الجانب تؤثر على مستخدمي المشروع (على سبيل المثال، تغيير الترخيص) أو تتوقف عن مواصلة التطوير والصيانة (على سبيل المثال، تغيير كبير في الحياة أو الخروج من العمل).
ماذا تعني الحوكمة من أجل الاستمرارية
هذه المقاييس مفيدة لإظهار النية أو عدم النية في حوكمة المشروع. على سبيل المثال، إذا كان هناك نقص في التسميات الشاملة للمشكلات، فهذا يُشير إلى وجود فجوة في الترحيب بالمساهمين الجدد وفرز المساهمين الحاليين عبر مسارات العمل. ترتبط القدرة على المساهمة في مشروع ما، أو فهمه، أو الاعتماد عليه ارتباطًا وثيقًا بالجهد المبذول في الحوكمة.
هذا لا يعني أن ضعف مقاييس الحوكمة يشير إلى أن المشروع يُدار من قِبل أشخاص غير مؤهلين. على سبيل المثال، قد يشير انخفاض معدل إغلاق طلبات التغيير ببساطة إلى قلة عدد المشرفين على المشروع لدعم مجتمع مساهم. قد يكون نقص المشكلات الجديدة نتيجةً لإصدار حديث كبير يعالج العديد من المشكلات المتكررة. تُعد هذه المقاييس مهمةً لتجميع هذه الأسباب، وليس لإثارة الشكوك المهنية حول مشرفي المشاريع. تساعد هذه المقاييس في تحديد قدرة الحوكمة والجهود المبذولة في جميع المشاريع ضمن محفظة البرامج.
إذا بدت بعض هذه المقاييس مقاييس مجتمعية قوية، فهي كذلك. العديد من المقاييس المشتركة هنا هي مزيج من جهود المجتمع في المشروع، وجهود الجهة التي تديره. يُجسّد تداخل المقاييس المشتركة هذه العلاقة بوضوح، بالنظر إلى المسؤولية المشتركة التي يتحملها المساهمون والمشرفون على تطوير برمجيات مفتوحة المصدر.
المجتمع
من أهم جوانب قابلية التطبيق للاستمرار نشاط المجتمع وتبنيه، فبدون مجتمع نشط، من غير المرجح أن يستمر مشروع مفتوح المصدر في التطور والنمو. تكمن الفكرة في أن وجود مجتمع نشط يحيط بالمشروع يُرجّح أن يُحسّن الأداء، ويُحسّن إدارة الثغرات الأمنية، ويُحسّن اكتمال الميزات، مما يُسهّل عملية التطوير اللاحقة.
مقاييس الفوضى:
- يقيس عدد الاستنساخات عدد المرات التي تم فيها سحب مشروع من مستودع إلى جهاز محلي كمؤشر على التبني.
- يشير عدد الشوكات إلى مدى الاهتمام بالمساهمة في المشروع.
- إن المشاريع مفتوحة المصدر هي أكثر من مجرد كود، وتشير أنواع أخرى من المساهمات (على سبيل المثال، الاستراتيجية، والقضايا، والمراجعات، والأحداث، وكتابة المقالات) إلى القدرة على استدامة المشروع.
- يمكن أن يساعد حجم الطلبات المنتظمة في فهم قوة وأنماط واستدامة مجتمع المشروع.
- يمكن أن توفر الاتجاهات المرتبطة بعدد المشاركين رؤى حول دورة حياة المشروع وما إذا كان لديه عدد متزايد أو مستقر أو متناقص من المساهمين.
- يساعد هذا على فهم ما إذا كان المشروع لديه عدد كافٍ من الصيّانين لمواكبة المساهمات في المشروع.
- هذا المقياس عبارة عن مجموعة من المقاييس الأصغر الأخرى (على سبيل المثال، الإعجابات والنجوم والشارات والشوك والاستنساخ) التي توفر مؤشرات على الاستخدام والتبني (Vargas et. al.، 2024).
- يوفر هذا المقياس مقياسًا لمدى حداثة اعتماد البرامج والذي يسلط الضوء على المخاطر المرتبطة باستخدام المشاريع التي قد تنطوي على تكلفة صيانة مخفية أو ثغرات أمنية بسبب عدم تحديث التبعيات بانتظام.
اعتبارات إضافية:
الشمول في الاتصالات:
- المشاريع التي تسودها ثقافة الاحترام واللطف في التعامل بين الأعضاء أكثر جدوى، لأن الأعضاء سيرغبون في مواصلة المساهمة، لذا انتبه جيدًا لكيفية تعامل الأعضاء مع بعضهم البعض في المناقشات، ومراجعات الأكواد، ومنصة Slack، وغيرها من قنوات التواصل. من ناحية أخرى، تُعرّض المشاريع التي تسودها ثقافة سلبية أعضاء المجتمع (بما في ذلك موظفو المؤسسة) للخطر.
ماذا يعني المجتمع بالنسبة للاستدامة
من خلال المجتمع، نسعى لفهم "التعديلات" التي تحدث في أي مشروع، بالإضافة إلى القدرة على قياس المساهمات المُقدمة. تشير النسخ والشوك إلى عدد مستخدمي البرنامج الذين استخدموه للبناء من المصدر، أو فحص شيفرته المصدرية، أو تقديم مساهمة، أو تطوير المشروع. يُعدّ هذا النوع من الشعبية مفيدًا لتتبع تفاعل المجتمع في أي مشروع. ومن الأمور التي تُقلل من خطر تبني مشروع مفتوح المصدر تبنّيه من قِبل مجموعة من المؤسسات الأخرى، حيث إن المشاريع النشطة التي تضم عددًا كبيرًا من المستخدمين أقل عرضة للتخلي عنها. فوجود قاعدة مستخدمين قوية يُقلل من خطر التخلي عن المشروع.
من خلال اتجاهات الملتزمين، وأنواع المساهمات، وطلبات التغيير، يمكننا رؤية كيفية تفاعل المجتمع. ربما يتم إنشاء طلبات تغيير بصيغة Markdown أكثر من الميزات، وربما العكس. بفهم أنواع المساهمات المقدمة، ومدى انتظامها، يمكننا إصدار حكم أكثر دقة على جدوى المشروع. على سبيل المثال، من المنطقي توقع أن يكون المشروع الذي فقد 90% من ملتزميه خلال فترة ثلاثة أشهر أقل جدوى من اتجاه مستقر (ثابت) للملتزمين. قد يشير العكس إلى مشروع متنامٍ أو مستقر يكتسب شعبية حول اتجاه تقني معين. في حين تبدو بعض مقاييس "التعديل" محدودة، فإن مقاييس أخرى تأخذ منظورًا كليًا.
من خلال قياس بعض المقاييس المشتركة، نتيح لهذا النموذج فرصةً للنظر إليه من منظور كيفية إدارة المجتمع للمشروع ومدى الاهتمام به عمومًا. ونجد أن هذا يختلف من منظور الحوكمة، حتى مع وجود تداخل كبير، إذ إن اتجاهات هذه المقاييس نادرًا ما تكون مسؤولية المجتمع أو القائمين على مشروع معين بالكامل. قد تكون الأرقام ذات دلالة في أيٍّ من المجالين، لذا فهي موجودة في كلا النموذجين.
الإستراتيجيات
قد تبدو استراتيجية المشروع أقل تميزًا من حيث العدد مقارنةً بالعديد من فئات الجدوى الأخرى. تُقاس الاستراتيجية بالعوامل التي يُمكن رصدها، وبالتأثير الذي قد يُمارسه الأفراد والمنظمات على المشروع.
مقاييس الفوضى:
- يمكن أن تؤثر لغات البرمجة المستخدمة في المشروع على ما إذا كانت المنظمة تمتلك المهارات اللازمة للمساهمة في المراحل الأولية، وهو ما قد يؤثر على قابلية الاستمرار إذا لم يكن من الممكن دمج إصلاحات الأخطاء.
عامل غياب المساهم (يُطلق عليه أحيانًا اسم عامل الحافلة أو عامل اليانصيب)
- إحصاء أقل عدد من المشاركين الذين يشكلون 50% من النشاط خلال فترة زمنية معينة لفهم مخاطر استخدام مشروع معين أو مجموعة من المشاريع بشكل أفضل فيما يتعلق بمقدار الدعم الذي قد يحصل عليه المشروع إذا غادر المساهمون الرئيسيون.
- يحسب عامل الفيل أقل عدد من المنظمات التي تشكل 50% من النشاط في مشروع ما ويُستخدم لاستنتاج التأثير الذي تتمتع به منظمات محددة على مشروع ما إلى جانب مدى الضرر الذي قد يحدث إذا غيرت هذه الشركة أولوياتها وتوقفت عن المساهمة.
- يقيس التأثير التنظيمي مدى سيطرة المؤسسة على مشروع ما. وهو تقديرٌ ومجموعٌ لعدة مقاييس أخرى، بما في ذلك: التنوع التنظيمي.
- يساعد تكرار الإصدار على فهم المدة التي يستغرقها المشروع لدمج التغييرات وإصلاحات الأمان في إصدار بالإضافة إلى موعد توقع تصحيحات الأمان وإصلاحات الأخطاء والميزات الجديدة.
اعتبارات إضافية:
اتفاقيات ترخيص المساهمين (CLAs)
- قد يؤدي توقيع اتفاقية ترخيص المساهم (CLA) المطلوبة قبل المساهمة إلى تقليل قابلية الاستمرار، حيث إن اتفاقية ترخيص المساهم (CLA) غالبًا ما تمنح المنظمة المسيطرة القدرة على إعادة الترخيص أو القيام بأعمال أخرى تسحب البساط.
ماذا تعني الاستراتيجية بالنسبة للاستدامة
المقاييس التي نتتبعها في هذا النموذج تتتبع الاستراتيجية، أو التأثير المتوقع من الأفراد والمؤسسات. على سبيل المثال، مع معامل غياب مساهم واحد، من المحتمل جدًا أن يؤدي الإرهاق أو عوامل أخرى إلى توقف المساهم الوحيد عن صيانة المشروع. مع عدد مساهمين أكثر مرونة، من المرجح أن نرى استراتيجية صيانة مستقرة وقابلة للتطبيق.
نتشارك في وتيرة الإصدارات بين الاستراتيجية والحوكمة. يُحدد هذا التداخل بين كيفية قيام المشرفين على المشروع بتوفير كلٍّ من خطة الحوكمة واستراتيجية الصيانة.
الإجراءات والتخفيف
لقد غطت الأقسام الأربعة السابقة فئات ذات مقاييس يمكن استخدامها لفهم العديد من الجوانب المختلفة للجدوى بشكل أفضل، ولكن تحتاج المنظمات إلى تجاوز الفهم واتخاذ الإجراءات.
المساهمة كاستراتيجية للتخفيف من المخاطر
من قيم مشاريع المصدر المفتوح أنه يمكننا جميعًا العمل معًا لتحسين جدوى هذه المشاريع وتقليل مخاطر استخدامها. ويعتمد قرار استخدام مشروع مفتوح المصدر غالبًا على التوازن بين المخاطر والمكافآت، حيث تُقرر المؤسسات مدى جدوى المشروع بما يكفي لحالة الاستخدام الخاصة بها.
أفضل طريقة لفهم جدوى أي مشروع والتأثير عليها وتحسينها هي تخصيص وقت للموظفين للمساهمة في المشاريع. إن عمل موظفيك ضمن المشروع يساعدك على فهم نقاط القوة والضعف فيه، كما يُمكّنك من التأثير على مساره المستقبلي من الداخل.
يمكن للمنظمات أيضًا المساهمة في التمويل والموارد الأخرى للمساعدة في استدامة مشاريع المصدر المفتوح وتحسين جدواها.
إدارة التبعية
يُفعّل تطبيق هذه المقاييس مهام اختيار البرمجيات وصيانتها. أثناء تقييم التبعيات، يُكوّن المهندسون فكرةً أفضل عن جوانب مشروع مفتوح المصدر التي تتفوق، وتلك التي قد لا ترقى إلى المستوى المطلوب. بناءً على التطبيق المُراد، يُمكن لمديري المشاريع مفتوحة المصدر وفرق التطبيقات وفرق العمليات تحديد ما إذا كان من المجدي تحمّل المخاطرة في مشروعٍ ما معًا.
يُساعد تقييم الجدوى على تحديد التبعيات التي يجب تحديثها. فبدلاً من تجميع التبعيات القديمة في كتلة من "الديون الفنية" الغامضة، يُمكننا تقدير مدى ملاءمة الامتثال والترخيص، والمجتمع، والاستراتيجية، والحوكمة لمشروع مُحدد. كما يُمكننا تقدير مخاطر عدم معالجة المشاريع بطريقة قابلة للقياس الكمي من قِبل أصحاب المصلحة، مع مراعاة الأولويات.
إعادة التقييم كممارسة
تعمل فرق التطوير بانتظام في ظروف لا تتيح لها الوقت الكافي لمراجعة قواعد الأكواد بحثًا عن التحسينات. من الضروري تحديد أولويات المهام التي تُقدم قيمة ملموسة لأي مؤسسة تعمل فيها. يسمح إطار العمل هذا بإعادة صياغة الدين الفني على أنه تخفيف للمخاطر. وكما نتجنب الثغرات الأمنية أو مشاكل الترخيص، فإننا نتجنب مشاريع مفتوحة المصدر غير المجدية.
إن وجود أداة وإطار عمل لممارسة التقييم وإعادة التقييم طوال عمر المشروع يتيح إجراء حوار قائم على المقاييس حول ما قد يكون أحيانًا أهدافًا نبيلة للمهندس. نوصي بإجراء حوارات حول هذه المقاييس مرة كل ثلاثة أشهر، خلال المناقشات حول تحديد أولويات مشاريع المصدر المفتوح. وبذلك، تُبرَّر المساهمة في المصدر المفتوح وتحديث إصدارات التبعيات الرئيسية (وبالتالي تعلم ممارسات الترميز المُحدَّثة) بشكل أفضل كإجراء لتخفيف المخاطر. يُعد تقييم الجدوى إحدى طرق إدارة حوار مثمر مع أصحاب المصلحة غير التقنيين بشكل منتظم.
الخاتمة
بناءً على حالة استخدامك، قد تجد فرصًا مختلفة لاستخدام إطار عمل تقييم الجدوى هذا. طُوّر هذا الإطار في الأصل لتقييم استخدام منتجات المصدر المفتوح داخل شركة محددة، لذا ستختلف حدود كل فئة نموذجية بناءً على تقدير مؤسستك للمخاطر.
فمثلا:
- تبدأ المنظمات التي تبدأ رحلتها في تطوير عمليات برمجيات مفتوحة المصدر بشكل رسمي عادةً بالامتثال والأمان، باستخدام معلومات الترخيص والثغرات الأمنية لاختيار برامجها.
- تُعد الحوكمة أمرًا بالغ الأهمية للمؤسسات التي تنوي إشراك مجتمع المصادر المفتوحة أو المساهمة في مشروع لتطوير وظائف جديدة. إذا كانت المؤسسة مستعدة لتخصيص الوقت والموارد اللازمة لصيانة مشروع ما، فإن حوكمة هذا المشروع تُصبح أمرًا بالغ الأهمية.
- يُعدّ المجتمع مهمًا لتطبيقات التكنولوجيا الحديثة أو المتطورة. في حين أن التكنولوجيا القديمة غالبًا ما يكون مجتمعها أقل تقلبًا، حيث يُمكن الحكم على المُحافظين وتدفق المساهمات الجديدة بمرور الوقت، قد يحتاج المشروع الجديد إلى مجتمع أقوى وأكثر يقظة تجاه منافسيه لضمان عدم التخلي عن حزمة البرامج.
تتلخص معظم قرارات الأعمال في تقييم المخاطر واتخاذ القرارات المناسبة. ينبغي على المؤسسات التفكير استراتيجيًا في مخاطر المشاريع في ضوء كيفية استخدامها لها. إذا كان المشروع جزءًا أساسيًا من حزمة التكنولوجيا، فيجب أن يكون مستوى المخاطر فيه منخفضًا قدر الإمكان. من ناحية أخرى، إذا استُخدم مشروع مفتوح المصدر كجزء صغير من بنية تحتية غير حرجة، فيمكن للمؤسسة تقبّل المزيد من المخاطر. يُعدّ تقييم الجدوى والتفكير فيها من منظور المخاطر وتحديد المخاطر التي يجب تقبّلها خطوة أولى مهمة، ولكن من المهم أيضًا التفكير في المخاطر التي يمكن التخفيف منها لتحسين الجدوى. أفضل طريقة للتخفيف من العديد من هذه المخاطر هي دفع رواتب للموظفين للمساهمة في المشاريع الأكثر أهمية لمؤسستك. يوفر هذا فرصة لتحسين الجدوى والاستدامة، كما يوفر نظرة ثاقبة على مسار المشروع وكيفية سير الأمور، بحيث إذا طرأ أي تغيير على المشروع يزيد من المخاطر، فقد يكون من الأسهل توقع هذه التغييرات.
تحذيرات واعتبارات
- تعتمد كيفية تقييمك للجدوى وقدرتك على تحمل المخاطر بشكل كبير على احتياجات مؤسستك الخاصة وحالة استخدامك الخاصة، لذا لا يوجد نهج واحد يناسب الجميع. قد لا تكون المخاطر المقبولة لشركة ناشئة في مجال التكنولوجيا هي نفسها لشركة خدمات مالية. وبالمثل، فإن استخدام مشروع بنية تحتية مفتوح المصدر كأساس لمنتجات مدرة للدخل للمؤسسة من المرجح أن يكون أقل تحملاً للمخاطر وقدرتك على الاستمرار مقارنةً باستخدام المشروع من قِبل فريق تطوير صغير.
- في حين أن بعض ما لدينا في هذا الدليل يمكن أتمتة وتقييمه على نطاق واسع، فإن المقاييس الأخرى والاعتبارات الإضافية تحتاج إلى تقييم يدوي أكثر، لذلك قد يكون من الأفضل استخدامها فقط للمشاريع حيث تكون القدرة على البقاء أمرًا بالغ الأهمية بالنسبة للمنظمة.
- لا يُمكن توقع جميع المخاطر، وقد يُصبح المشروع فجأةً غير قابل للاستمرار بطرقٍ لا يُمكن توقعها. يُغطي هذا الدليل جوانبَ عديدةً من قابلية الاستمرار التي يُمكن تقييمها، ولكن في الواقع، تُدار مشاريع المصادر المفتوحة من قِبل أشخاص، وقد يتخذ هؤلاء الأشخاص أحيانًا إجراءاتٍ غير متوقعة تُؤثر على الآخرين.
- قد يكون هذا الدليل مُربكًا بعض الشيء للمؤسسات الجديدة في تقييم الجدوى، لذا قد يكون اختيار بعض المجالات للتركيز عليها الآن والبناء عليها لاحقًا نهجًا جيدًا للعديد من المؤسسات. نوصي بالبدء بنموذج أو نموذجين، أو حتى النموذج العام. نموذج البداية كخطوة أولى.
قراءات إضافية
- لدينا فيديو قصير (<8 دقائق) مخصصة لهذا الدليل على قناة CHAOSS على اليوتيوب.
- 5 نماذج لقياس الجدوى: مبتدئ, الامتثال + الأمن, الحكم, المشاركة المجتمعيةو الإستراتيجيات
- الجدوى: نموذج مقياسي (فائق) مفتوح المصدر للفوضى
- مقاييس صلاحية OSS
- دليل صلاحية OSS: نموذج متري للفوضى
- دليل ممارسي CHAOSS
- تقرير تحليل المخاطر والأمن مفتوح المصدر لعام 2024
- السحابات والترميز والتحكم: صراع القوة الجديد في مجال المصادر المفتوحة
- CHAOSScast الحلقة 84: قابلية المجتمع للاستمرار - كيف تنظر Verizon إلى مخاطر OSS
المساهمين
ساهم الأشخاص التالية أسماؤهم في هذا الدليل:
- غاري وايت
- داون فوستر
- مات جيرمونبريز
مراجع حسابات
- أفيلينو، جي، كونستانتينو، إي، فالينتي، إم تي، وسيريبرينيك، أ. (2019، سبتمبر). حول التخلي عن المشاريع مفتوحة المصدر وبقائها: دراسة تجريبية. في ندوة ACM/IEEE الدولية لعام 2019 حول هندسة البرمجيات التجريبية والقياس (ESEM) (ص 1-12). IEEE.
- البطة السوداء (2025). تقرير تحليل المخاطر والأمن مفتوح المصدر لعام 2025.
- كوكس جيه، بويرز إي، فان إيكلين إم، وفيسر جيه (2015، مايو). قياس مدى حداثة التبعية في أنظمة البرمجيات. في المؤتمر الدولي السابع والثلاثون لهندسة البرمجيات IEEE/ACM 2015 (المجلد 2، ص 109-118). معهد مهندسي الكهرباء والإلكترونيات.
- إقبال، ن. (2016). الطرق والجسور: العمل غير المرئي وراء بنيتنا التحتية الرقمية. نيويورك، نيويورك: مؤسسة فورد.
- فوستر، د.، 2024، "الديناميكيات الجديدة للمصدر المفتوح: إعادة الترخيص، والشوك، والتأثير المجتمعي"، ورقة بحثية مقدمة إلى ندوة أكاديمية OpenForum، بوسطن، ماساتشوستس، 13-14 نوفمبر، متوفرة على https://doi.org/10.48550/arXiv.2411.04739
- امتياز، ن.، خانوم، أ.، وويليامز، ل. (2022). مفتوح أم متستر؟ سريع أم بطيء؟ خفيف أم ثقيل؟: التحقيق في إصدارات الأمان الخاصة بحزم المصدر المفتوح. معاملات IEEE في هندسة البرمجيات, 49(4)، 1540-1560.
- فارغاس، س.، لينك، ج.، ولي، ج. (2024، أبريل). تقدير استخدام مشاريع المصدر المفتوح. في وقائع المؤتمر الدولي الحادي والعشرين لمستودعات برمجيات التعدين (pp. 652-653).
أدلة ممارس CHAOSS هي وثائق حية مرخصة من معهد ماساتشوستس للتكنولوجيا (MIT)، ونحن نرحب بتعليقاتك ومدخلاتك. يمكنك اقتراح تعديلات على هذا المستند على https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/viability.md