دليل الممارس: البدء في إنهاء مشروع مفتوح المصدر

المقاييس الأولية:

إذا لم تكن قد قرأت بالفعل دليل الرؤى: المقدمة - الأمور التي يجب التفكير فيها عند تفسير المقاييس، يرجى التوقف الآن وقراءة هذا الدليل.

يتم التخلي عن العديد من مشاريع المصدر المفتوح، حتى تلك المستخدمة على نطاق واسع، لأسباب متنوعة (على سبيل المثال، الاهتمامات المتطورة، والظروف العائلية، وتغييرات التوظيف)، ولكن يمكن أن يتم التخلي عنها بطريقة مسؤولة من خلال إنهاء المشروع بشكل استباقي (ميلر وآخرون 2025). يعد إنهاء المشروع اعتبارًا مهمًا لبيئات الشركات حيث قد يكون من السهل فقدان مسار المشاريع التي أنشأها الموظفون الذين انسحبوا لاحقًا من المشروع وغادروا إذا تم التخلي عنه. أنت لا تريد مشاريع المصدر المفتوح المهجورة التي بها ثغرات أمنية موجودة في مستودعات التعليمات البرمجية المصدرية لمؤسستك حيث قد يثق شخص ما في هذا المشروع لمجرد أنه يثق في مؤسستك. يعد العثور على المشاريع غير النشطة وإنهائها بشكل مسؤول قرارًا تجاريًا جيدًا وهو شيء تقوم به العديد من فرق المصدر المفتوح / مكاتب برامج المصدر المفتوح (OSPOs) بشكل منتظم.

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

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

الخطوة 1: تحديد الاتجاهات

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

تغيير الطلبات

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

مشروع مهجور - طلبات التغيير

قضايا جديدة

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

مشروع مهجور - قضايا جديدة

شوكات فنية

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

الخطوة الأولى: التشخيص

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

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

الخطوة 3: جمع بيانات إضافية إذا لزم الأمر

تحتوي CHAOSS على مقاييس أخرى لفهم نشاط المشروع واستخدامه والتي يمكن أن تكون مفيدة عند اتخاذ قرار بشأن إنهاء المشروع.

مقاييس إضافية:

الخطوة 4: إجراء التغيير

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

التواصل

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

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

  • ملف README: وضّح في أعلى ملف README أن المشروع قد أصبح قديمًا ولن يُحدَّث بعد الآن. إن أمكن، اقترح مشاريع بديلة توفر وظائف مماثلة.
  • قنوات الاتصال بالمشروع: قد يشمل ذلك Slack وقوائم البريد والمنتديات ووسائل التواصل الاجتماعي وأي قنوات أخرى تستخدم للتواصل داخل المشروع.
  • التوثيق: يجب تحديث وثائق المشروع أيضًا، بما في ذلك مواقع الويكي، ومواقع الويب، وغيرها من وثائق المشروع.
  • مديرو الحزم / قنوات التوزيع: نظرًا لأن معظم المشاريع يتم توزيعها عبر مديري الحزم (على سبيل المثال، npm، PyPI، RubyGems)، فيجب أيضًا تحديثها باستخدام تحذير الإهمال الذي ينص بوضوح على أن المشروع لم يعد قيد الصيانة أو التحديث.
  • قنوات إضافية: إذا كان هذا مشروعًا مؤسسيًا، فيجب أيضًا إخطار فرق التسويق والفرق الداخلية الأخرى.
  • المستخدمون: يجب أيضًا إخطار المستخدمين المعروفين للمشروع.

أرشيفي

يجب أرشفة المشروع رسميًا باستخدام طريقة أرشفة مشابهة لطريقة GitHub. قد يكون من الجيد أيضًا الاحتفاظ بهذه المشاريع في مكان منفصل لتوضيح انتهاء عمرها الافتراضي. على سبيل المثال، لدى VMware تنظيم منفصل باسم "vmware-archive"، ولدى Apache تنظيم مشابه يُسمى "Apache Attic".

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

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

حالة خاصة: إنهاء المشاريع النشطة

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

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

تحذيرات واعتبارات

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

قراءة إضافية

المساهمين

ساهم الأشخاص التالية أسماؤهم في هذا الدليل:

  • داون فوستر
  • ريا شالنات
  • داميان فيسينو
  • مات جيرمونبريز
  • إليزابيث بارون
  • تارا تاراكيي

مراجع حسابات

أدلة ممارس CHAOSS هي وثائق حية مرخصة من معهد ماساتشوستس للتكنولوجيا (MIT)، ونحن نرحب بتعليقاتك ومدخلاتك. يمكنك اقتراح تعديلات على هذا المستند على https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/sunset.md