مقدمة:
يبين تقرير Lyrasis عن البرمجيات المفتوحة المصدر، الذي أعده روزن وغروغ عام 2021 ، أن المكتبات تهتم بالاستدامة عند اختيار هذه البرمجيات. فهي تريد ضمان استمرار التحديثات، سواء لإضافة وظائف جديدة أو لمعالجة المشكلات الأمنية، وأن يبقى المشروع متاحًا على المدى الطويل ويتطور ويحافظ على أمنه.
الاستدامة ليست الاعتبار الوحيد عند الاختيار؛ فالوظائف وسهولة النشر ودعم المورد وغيرها عوامل مهمة أيضًا. لكنها قد تكون شرطًا سابقًا لهذه الاعتبارات. وإذا كانت صحة المجتمع مؤشرًا إلى استدامة المشروع، فينبغي فحصها ووزنها قبل التبني؛ إذ يساعد ذلك المكتبة، وفق لينوكَر وزملائه (2022)، على تقدير مخاطر استخدام البرمجية بحالتها القائمة، ثم تقرير المساهمة في تحسين صحتها أو اختيار بديل.
يصعب التنبؤ باستدامة المشروع طويلًا، لكن قياس صحة المجتمع الداعم له قد يفيد. ويعرّف مشروع CHAOSS ، التابع لمؤسسة Linux والمعني بتحليلات صحة مجتمعات البرمجيات المفتوحة، الصحة بأنها «قدرة المشروع على الاستمرار في إنتاج برمجيات جيدة» (غوغنز وزملاؤه، 2021).
تفيد المقاييس جهات كثيرة، منها الممولون والقائمون على الصيانة. لكن هذا المقال ينظر إليها أساسًا من موقع المتبني: المكتبة التي تفكر في استخدام مشروع قائم والدخول في علاقة تعاونية مع مجتمعه، قبل أن تحدد إسهاماتها المستقبلية.
في هذه المرحلة تقيّم المكتبة البرمجية، وتفكر كذلك في مساهمات استراتيجية تدعم استدامة مجتمعها. والمساهمة مفهوم واسع لا يقتصر على كتابة الشيفرة. ويساعد فحص المقاييس عند البداية على معرفة كيفية الإسهام، والتحقق من توافر الموارد اللازمة لتبني البرمجية والمشاركة الفاعلة في المجتمع.
مقاييس CHAOSS ونماذجه
طور CHAOSS أكثر من 80 مقياسًا لتقييم صحة مجتمعات البرمجيات المفتوحة المصدر. ولتيسير استخدامها على المشروعات والمتبنين، جُمعت مقاييس كثيرة في نماذج تسمح بالنظر إلى علاقتها بعضها ببعض، بدل قراءتها منفردة؛ وهو ما يساعد على فهم النظم الواقعية التي تمثلها.
ومن هذه النماذج «النموذج الأولي لصحة المشروع» [1] الذي نعرضه لاحقًا. يضم أربعة مقاييس تتصل بصحة المشروع الحالية، وبخاصة الاستجابة لطلبات التغيير، ومتانة قاعدة المساهمين في الشيفرة، ونشاط المستودع. وتقدم مجتمعة تصورًا أوليًا للصحة وإمكانات الاستدامة. وقد صُمم النموذج نقطة بداية للمبتدئين في جمع هذه المقاييس.
الأدوات المتاحة
يحتاج موظفو المكتبة عند التجريب الأول إلى جمع البيانات باستثمار محدود من الوقت والجهد. وتوجد وسائل عدة لذلك. فإذا كان المشروع مستضافًا علنًا على GitHub ويستخدم خصائص مجتمعه، تتيح GitHub Insights تصورات محدودة لفحص بعض المقاييس. لكنها تفتقر إلى تخصيص معظم التصورات أو التعمق فيها وإلى مرشحات لمعظم المقاييس. وكلما كبر المشروع، صعب تكوين صورة شاملة من هذه الأداة، بخلاف مجرد معرفة أنه نشط.
يمكن أيضًا استخدام واجهة GitHub البرمجية لإنشاء وسائل خاصة لجمع البيانات وتصويرها (تشيو وزملاؤه، 2023).
يتعاون مجتمع CHAOSS في مشروعات برمجية متعددة تطبق مقاييسه. وتستند cauldron.io ، المستخدمة في أمثلة المقال، إلى مكونات GrimoireLab [2]. ويتيح GrimoireLab دمج بيانات من مصادر متنوعة وتوحيد هويات المشاركين عبرها؛ كالتعرف إلى أن حسابين على GitHub يعودان إلى شخص واحد. لكن الجمع والتوحيد المعقدين غير متاحين في نسخة cauldron.io المجانية، ويحتاجان إلى وصول مصرح به إلى البيانات.
وينتج CHAOSS أيضًا Augur [3] لتحليل بيانات المشروع وتصويرها. ويركز أكثر على الآثار التي تولدها المستودعات، بينما يدعم GrimoireLab مصادر أوسع لبيانات المجتمع. وكلاهما مفتوح المصدر ويمكن استضافته أو تشغيله محليًا [4]. وتوفر cauldron.io تجربة استخدام مريحة للمقاييس؛ لذا نستخدمها في العرض هنا. ولا تتيح تحليل بيانات مستخدم GitHub خارج المعرّف الفريد UUID واسم نطاق بريده الإلكتروني.
للمشروعات غير المستضافة على GitHub ، أو المستضافة عليه بصورة خاصة، يتيح GrimoireLab و Augur التعامل مع المستودعات ونظم إضافية مثل JIRA ، عند استضافة برنامج المقاييس ذاتيًا أو دفع تكلفة خدمة مستضافة، شريطة الحصول على حق الوصول إلى البيانات. وإذا ربطت المكتبة مصادر أخرى، فينبغي مراعاة الخصوصية والتحفظ في الجمع. فإمكان استيعاب المنتديات والقوائم البريدية والمحادثات في GrimoireLab لا يعني حكمة فعل ذلك دون تفكير عميق في الآثار الأخلاقية وآثار الخصوصية. ويقدم CHAOSS دليلًا لهذه المسائل [5].
استكشاف النموذج الأولي لصحة المشروع
بعد اختيار الأداة، قد تكون أسهل طريقة لفهم المقاييس تطبيقها على مستودع وفحص النتائج. وسنطبق النموذج على DSpace ، وهو مشروع مفتوح المصدر ذو صلة بالمكتبات، باستخدام cauldron.io. مستودعاته عامة على GitHub ، ويستخدم نظام تتبع المشكلات المدمج فيه، فتتوفر بيانات عامة مناسبة للتجريب.
كل مقياس نقطة بداية لمزيد من الاستقصاء وفهم العلاقة التعاونية التي تدخلها المكتبة بانضمامها إلى مجتمع برمجي. والأشكال في الأصل مأخوذة من cauldron.io.
وقبل عرض المقاييس، ينبغي توضيح أن هدفها تقييم حالة المشروع ومجتمعه، وهما نظامان معقدان قد يشملان أشخاصًا ومؤسسات وقوى خارجية كثيرة. وليس الهدف تقييم الأشخاص أو أداءهم، بل فهم المشروع والعثور على أكثر طرق المشاركة فيه إنتاجية.
المقياس الأول: زمن الاستجابة الأولى
يدل زمن الاستجابة الأولى [6] على سرعة رد المجتمع على نشاط مثل فتح مشكلة أو تقديم طلب سحب. وفي ضوء قلق المكتبات بشأن استمرار تطوير الخصائص، قد يشير إلى استعداد المشروع لمناقشة الطلبات والاقتراحات أو تقديم إجابات لاستكشاف الأعطال. لكن النقاش لا يحدث كله بالضرورة على المنصة التي تفحصها؛ إذ تحتفظ مشروعات كثيرة بقوائم بريدية. وقد يعني ضعف التفاعل على GitHub ضرورة استكشاف ساحات أخرى. وحتى إن لم تجمع بياناتها مباشرة، فمن المهم معرفة وجودها.
يساعد فحص النشاط الحواري قبل التبني على توقع مقدار الدعم والتفاعل، وفهم أثر ذلك في الموظفين الذين سيبحثون عن إجابات. وقد يكشف أيضًا فرصة للمساهمة بالتوثيق إذا احتاج المجتمع إلى مساعدة في دعم المستخدمين.
يعرض الشكل الأول في الأصل لوحة توقيت cauldron.io. وتتألف من تصورات داخل نسخة Elastic Kibana ، وهي أكثر مرونة من التقارير الجاهزة على الموقع. وبعد إنشاء حساب وتقرير مستودع، ينقل رابط «تفاصيل أكثر» المستخدم إلى Kibana. وفي المثال جُمعت بيانات مستودعين: واجهة DSpace البرمجية وواجهة المستخدم المبنية بـ Angular. وهذه القدرة على الجمع ميزة لنظام التقارير مقارنة بـ GitHub Insights.
توضح اللوحة تحسن كفاءة التوقيت للمستودعين بمرور الزمن، وتعرض المتوسط والوسيط لمقاييس الزمن. وغالبًا يكون الوسيط أدل؛ إذ توجد عادة مشكلات غامضة أو صعبة الحل تبقى مفتوحة طويلًا فترفع متوسط زمن الاستجابة أو الإغلاق.
المقياس الثاني: نسبة إغلاق طلبات التغيير
تقارن نسبة إغلاق طلبات التغيير [7] بين عدد طلبات السحب أو الدمج المنشأة أسبوعيًا وعدد المغلق منها. وهي مؤشر إلى قدرة المجتمع على مواكبة الطلبات الواردة.
وقد تعكس هذه النسبة وزمن الاستجابة الأولى قدرة المشروع على متابعة التحديثات الأمنية اللازمة لتبعياته، فتقدمان معلومات متصلة باهتمام المكتبات بأمن البرمجيات.
يعرض الشكل الثاني أعداد المشكلات المفتوحة والمغلقة شهريًا في مستودعي DSpace. ويتحرك العددان معًا في معظم الفترات، مما يرجح أن القائمين على الصيانة يواكبون وتيرة المشكلات الجديدة.
المقياس الثالث: عامل الاعتماد على عدد محدود من الأفراد
يمثل Bus factor [8] عدد الأشخاص الذين يقدمون 50% من مساهمات الشيفرة. ويحاول تقدير قدرة المشروع على الاستمرار إذا غادر أحد مساهميه الأساسيين. وكلما صغر العدد، ربما انخفضت الاستدامة. لكن تفسيره في المشروعات المدعومة مؤسسيًا يتطلب حذرًا: فقد يصون مشروعًا مهمًا عدد قليل تدعمه مؤسسات ملتزمة طويلًا، حتى عند تغير الموظفين. ومن ثم قد يخفف الالتزام المؤسسي الخطر الذي يوحي به العدد الصغير.
ومع ذلك، قد يكون فقدان المعرفة عند مغادرة مساهم نشط شديد الأثر، ولا ضمان لامتلاك الموظف البديل الاهتمام نفسه أو المهارة نفسها. فالمساهمون ليسوا قابلين للاستبدال لمجرد عملهم في المؤسسة ذاتها.
ويرتبط بذلك مقياس التنوع المؤسسي [9]، وإن كان خارج النموذج الأولي. فهو يقيس عدد المؤسسات الممثلة في المشروع. وإذا كانت مؤسسة واحدة وحدها تسهم، انخفض التنوع وربما ازداد خطر الاستدامة، كما في عامل الاعتماد. ويؤثر أيضًا مقدار الالتزام المؤسسي ونفوذ المؤسسة داخل المشروع [10]، وهو مقياس آخر.
ويزداد الأمر تعقيدًا لأن عدّ المساهمين على GitHub يعتمد على طريقة تعريفهم أنفسهم؛ فقد يستخدمون بريدًا شخصيًا، وقد يملكون حسابات متعددة على مر الزمن. لذلك تظل أرقام الاعتماد والتنوع تقديرات، لكنها مؤشرات أولية مفيدة لتحديد الأسئلة والمشكلات المحتملة.
يعرض الشكل الثالث في الأصل تصورًا دائريًا تقريبيًا لمستودع DSpace الخلفي وحده؛ إذ بدا فصل المستودعين أنسب هنا. يقدم ثمانية مساهمين نصف الالتزامات البرمجية، فيكون العامل 8 وفق الرسم. لكن تعدد حسابات الشخص الواحد يستدعي مزيدًا من التحقق للوصول إلى رقم محكم. ويغطي الرسم العامين الأخيرين، مع استبعاد الروبوتات. وليس من رسوم cauldron.io الجاهزة، بل أُنشئ عبر «مساحة عملي» في Kibana التي تتيح تصورات خاصة لبيانات المستودع.
ويسهل هذا التصور فهم توزيع المساهمين الحالي مقارنة بصفحة المساهمين في GitHub Insights التي تعرض قائمة طويلة تغطي حياة المشروع كلها.
المقياس الرابع: تواتر الإصدارات
يقيس تواتر الإصدارات [11] عدد مرات إصدار المشروع نسخًا جديدة. وقد يُعرّف «الإصدار» بطرق مختلفة، لذلك يلزم فهم آلية المشروع قبل القياس. وللتبسيط ننظر هنا إلى إصدارات GitHub ، وإن كانت الإصدارات المهمة قد تظهر في مواضع أخرى وبوسائل أخرى. وبسبب تعدد التعريفات، لا توفر cauldron.io إحصائية جاهزة لهذا التواتر. أما المشروع المستضاف والمصدر عبر GitHub ، فيمكن فحص صفحة إصداراته، مثل https://github.com/DSpace/DSpace/releases.
ومن الأمور المرغوبة عند الفحص استخدام الترقيم الدلالي للإصدارات [12]؛ إذ يميز الإصدارات الرئيسية والفرعية والترقيعات. فقد يرتبط تواتر الرئيسية بإضافة وظائف جديدة، بينما تشير الأنواع الأخرى إلى وتيرة إصلاح العيوب وإصدار التحديثات الأمنية.
خاتمة:
تفيد المقاييس لسببين على الأقل. أولًا، قد لا يملك المنخرطون بعمق في المشروع صورة شاملة دقيقة عنه؛ فتساعد المقاييس على تأكيد انطباعاتهم أو كشف مواضع تعارض القياس معها.
وثانيًا، غالبًا لا يكون من يقررون استثمار الموارد في البرمجيات هم من ينفذونها عمليًا. وهنا تساعد المقاييس على شرح حاجة مشروع مفتوح إلى الدعم، أو سبب صعوبة تنفيذ مشروع اختاره مسؤول إداري.
كما أن مراجعة المقاييس تدعو إلى التفكير المتأني والاستراتيجي في علاقة المكتبة المتبنية بالمجتمع الذي تنضم إليه. لقد تجاوزنا الاعتقاد بأن المصدر المفتوح يعني انعدام التكلفة، لكننا ما زلنا نحتاج إلى لغة تناقش اختلاف التوقعات والموارد بين المتبنين والمجتمعات؛ والمقاييس أداة لاستكشاف هذه الفجوات.
ينبغي الانضمام إلى المجتمع بعناية وتفكير، وإدراك أن البرمجيات المفتوحة ساحة مهمة للتعاون بين المكتبات. وإذا أردنا مواصلة إنتاج برمجياتنا ومنافستها للحلول التجارية، فعلينا استخدام الأدوات المتاحة لجعل شراكاتنا أكثر إنتاجية.
شكر وتقدير:
تشكر الكاتبة بولا ديمبسي وبرنامج الإرشاد التابع للمائدة المستديرة للبحوث المكتبية في جمعية المكتبات الأمريكية على الدعم.
المراجع:
Metrics Model: Starter Project Health. CHAOSS. [accessed 2023 Jun 1]. https://chaoss.community/kb/metrics-model-starter-project-health/.
Gamalielsson, Jonas, and Björn Lundell. “Sustainability of Open Source Software Communities beyond a Fork: How and Why Has the LibreOffice Project Evolved?” Journal of Systems and Software 89 (March 2014): 128–45. https://doi.org/10.1016/j.jss.2013.11.1077.
Goggins S, Lumbard K, Germonprez M. 2021. Open Source Community Health: Analytical Metrics and Their Corresponding Narratives. In: 2021 IEEE/ACM 4th International Workshop on Software Health in Projects, Ecosystems and Communities (SoHeal). p. 25–33. https://doi.org/10.1109/SoHeal52568.2021.00010.
Linåker, Johan, Efi Papatheocharous, and Thomas Olsson. “How to Characterize the Health of an Open Source Software Project? A Snowball Literature Review of an Emerging Practice.” In The 18th International Symposium on Open Collaboration, 1–12. Madrid Spain: ACM, 2022. https://doi.org/10.1145/3555051.3555067.
Qiu HS, Lieb A, Chou J, Carneal M, Mok J, Amspoker E, Vasilescu B, Dabbish L. 2023. Climate Coach: A Dashboard for Open-Source Maintainers to Overview Community Dynamics. In: Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems. New York, NY, USA: Association for Computing Machinery. (CHI ’23). p. 1–18. https://dl.acm.org/doi/10.1145/3544548.3581317.
Rosen H. (orcid: 0000-0001-6804-7073), Grogg J. (orcid: 0000-0001-5136-4507). 2021 Aug. LYRASIS 2021 Open Source Software Report: Understanding the Landscape of Open Source Software Support in American Libraries. http://hdl.handle.net/20.500.12669/97.
https://chaoss.community/kb/metrics-model-starter-project-health/
https://github.com/chaoss/community/blob/main/data-use-statement.md
https://chaoss.community/kb/metric-time-to-first-response/
https://chaoss.community/kb/metric-change-request-closure-ratio/
https://chaoss.community/kb/metric-bus-factor/
https://chaoss.community/kb/metric-organizational-diversity/
https://chaoss.community/kb/metric-organizational-influence/
https://chaoss.community/kb/metric-release-frequency/
https://github.com/DSpace/DSpace/releases
https://chaoss.github.io/grimoirelab-tutorial/
https://github.com/chaoss/augur
https://semver.org/
https://doi.org/10.1016/j.jss.2013.11.1077
https://doi.org/10.1109/SoHeal52568.2021.00010
https://doi.org/10.1145/3555051.3555067
https://dl.acm.org/doi/10.1145/3544548.3581317
https://orcid.org/0000-0001-6804-7073
https://orcid.org/0000-0001-5136-4507
http://hdl.handle.net/20.500.12669/97