خمسة التزامات للقائمين على صيانة المشروعات المفتوحة المصدر

مقدمة:

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

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

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

1. تضمين مدونة لقواعد السلوك

عدّ جونو بيكون «عدم إنفاذ مدونة السلوك» ضمن مقاله «سبعة أخطاء ترتكبها على الأرجح». وبالطبع، لا يمكنك إنفاذ مدونة قبل أن تكون لديك واحدة. أنوي اعتماد Contributor Covenant خيارًا افتراضيًا، ولك أن تختار غيرها. وكما هي الحال مع التراخيص، فالأفضل غالبًا استخدام نص جاهز بدل كتابة نص جديد. والمهم أن تجد ما يحدد السلوك الذي تريده لمجتمعك، أيًّا كان تصوره. وحين تُكتب القواعد وتُطبق، يستطيع الناس تقرير ما إذا كان هذا هو المجتمع الذي يرغبون في الانضمام إليه.

2. توضيح الترخيص وتحديده بدقة

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

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

3. فرز بلاغات العلل والأسئلة سريعًا

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

4. عدم دفع مزايا أو إصلاحات من دون توثيق مصاحب

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

5. إعلان التخلي عن المشروع بوضوح

أنا سيئ جدًّا في قول «لا». قلت للمحررين إنني سأكتب مقالًا أو اثنين لـOpensource.com، وها أنا أقترب من ستين مقالًا! لكن الأشياء التي كانت تهمني قد تفقد جاذبيتها في وقت ما. ربما لم يعد المشروع لازمًا بعد أن استوعب مشروع أكبر وظائفه، وربما تعبت منه فحسب. ومع ذلك، فمن غير المنصف للمجتمع، وقد يكون خطرًا أيضًا كما أظهر حقن البرمجية الخبيثة في event-stream أخيرًا، أن نترك المشروع معلقًا. للقائمين على الصيانة حق الانسحاب متى شاؤوا ولأي سبب، لكن ينبغي أن يكون انسحابهم واضحًا.

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

المراجع

• https://www.contributor-covenant.org/
• https://opensource.org/licenses/gpl-license
• https://creativecommons.org/share-your-work/licensing-types-examples/
• https://opensource.org/
• https://Opensource.com
• https://arstechnica.com/information-technology/2018/11/hacker-backdoors-widely-used-open-source-software-to-steal-bitcoin/