تأليف: فيليب أورتج من كتاب النصيحة المفتوحة، ترجمة فهد السعيدي
فيليب أورتج باحث و مدير مشروع في Libresoft وهي مجموعة بحثية في جامعة ري جون كارلوس URJC بأسبانيا. طور فيليب منهجية جديدة لتحليل المجتمعات التعاونية المفتوحة ( من مثل المشاريع الحرة، و ويكيبيديا و الشبكات الاجتماعية). وقد قام بدراسة مكثفة حول مشروع ويكيبديا ومجتمعها من المؤلفين. وهو نشط بالمشاركة في البحوث و الترويج و التدريس والتدريب في البرمجيات الحرة وخصوصا في ماجستير البرمجيات الحرة بجامعة URJC. وهو ناشط ومؤيد قوي في المصادر التعليمية المفتوحة، و الوصول المفتوح في النشرات العلمية، و البيانات المفتوحة في العلوم.
في كتابه المشهور " الكدترائية والبازار " قدم إريك ريموند أحد أوائل الدروس المهمة التي يجب على المبرمج تعلمها: "يبدأ أي عمل جيد في البرمجيات بتلبية حاجات المطور الخاصة". إنك لن تدرك مدى صحة هذه الفرضية ما لم تخابر تلك التجربة بنفسك. في الحقيقة، غالبية مبرمجي البرمجيات الحرة (إن لم يكن كلهم) اجتازوا هذه العملية بدون شك، عندما وضعوا أيديهم في مشروع جديد، أو انضموا إلى مشروع قائم طمعا للمساعدة في تحسينه للأفضل. وعلى كل، فإن العديد من المطورين و المساهمين الآخرين في مجتمعات البرمجيات الحرة (من مثل الموثقين و المترجمين إلخ) يتغاضوا عن درس مهم آخر ركز عليه ريموند متأخرا في كتابه: "عندما تفقد الاهتمام في البرنامج، فإن آخر مهمة لك أن تسمله إلى كفؤ ناجح". هذا هو الموضوع الرئيسي الذي أريد أن أغطيه هنا. فأنت يجب أن تفكر في مستقبل مشروعك و القادمين الجديد الذين في أحد الأيام سيأخذون عملك و يستمروا في تحسينه.
تعاقب الأجيال
في أحد مراحل عمرها، يجب أن تواجه مشاريع البرمجيات الحرة تعاقب الأجيال. حين يغادر المطورون الأوائل المسؤولين عن صيانة الشفرة المصدرية وتطويرها في النهاية تاركين المشروع ومجتمعه لطيف واسع من الأسباب. وهذه تشمل المشاكل الشخصية، وظيفة جديدة لا تترك لهم متسع من الوقت، البدء في مشروع جديد، الانتقال إلى مشروع آخر يبدو أكثر إغراء... والقائمة تطول.
دارسة تعاقب الأجيال ( أو تحول المطورين) في مشاريع البرمجيات الحرة ما زالت مجال جديد للدراسة تحتاج للمزيد من البحوث لتحسين فهمنا لهذه الحالات. وبالرغم من ذلك، جمع بعض الباحثين بالفعل دليل موضوعي يمكنه أن يلقي بعض الضوء على هذه العمليات. في OSS 2006 قام زملائي جوسوس ج. باراهونا و جوريج روبلس بعرض عمل بعنوان: "تحول المساهمين في المشاريع البرمجيات الحرة". في هذا العمل، استعرضوا منهجية لتحديد أغلب المساهمين النشطين (في الغالب يعرفون بالمساهمين الأساسين) في عدة فترات زمنية مختلفة، على مدار تاريخ المشروع المعطى بالكامل. ثم قاموا بتطبيق هذه الطريقة لدراسة 21 مشروعا ضخما، وبالخصوص جمب، و موزيلا (النسخة السابقة من المتصفح المشهور) و إيفولوشن. وباختصار، فإن ما خلصوا إليه هو أننا نستطيع أن نحدد ثلاثة أنواع من المشاريع اعتمادا على معدل انتقال المطورين:
- مشاريع ذات سلاطين الشفرة: هذه المشاريع تعتمد بشكل كبير على عمل منشئيها، وهناك نسبة قليلة من تعاقب الأجيال، أو لا شيء على الإطلاق. يقع مشروع جمب في هذا التصنيف.
- مشاريع ذات أجيال متعددة: مشاريع مثل موزيلا تظهر انسياب واضح في تحول المطورين، فمع مجموعات جديدة من المطورين النشطين يأخذون زمام تطوير الشفرة والصيانة من أيدي المساهمين الرئيسين السابقين.
- مشاريع مركبة: ينتمى مشروع إيفولوشن إلى التصنيف الثالث من المشاريع، حيث يظهر معدل تحول لا بأس به ولكن ليس بوضوح الحالة السابقة، مخففة من حدة التحول بسبب بقاء بعض المساهمين الأساسين على مدار تاريخ المشروع.
يقودنا هذا التصنيف إلى سؤال واضح: إذن، ما أكثر النماذج شهرة في الواقع في المشاريع الحرة؟
حسنا، توضح نتائج تحليل كال مجموعة 21 مشروعا في هذا العمل ملخصا واضحا، وهو أن المشاريع ذات الأجيال المتعددة و المشاريع المركبة هي أكثر الحالات شهرة وجودا في بيئة البرمجيات الحرة FLOSS. إلا أن مشروع Gnumeric و مشروع مونو أظهرا نموذجا مختلفا من قوة بقاء المطورين السابقين، مظهرا أنه ربما أن الناس التي تساهم لهذين المشروعين لديها العديد من الأسباب المغرية للاستمرار بالمساهمة لمدة طويلة من الزمن.
وبالرغم من ذلك، فإن هذه ليست الصورة العادية. وبالمقابل، تعطينا هذه الدراسة الدعم للنصيحة التي يجب أن نأخذها بعين الاعتبار، وهي يجب أن نستعد لنقل، في لحظة ما في المستقبل، دورنا و معرفتنا في المشروع إلى المساهمين المستقبلين المنضمين إلى مجتمعاتنا.
فجوة المعرفة
أي شخص يواجه تغيير جليل في حياته يجب أن يتعامل ويتكيف مع الأوضاع الجديدة. فعلى سبيل المثال، عندما تستقيل من وظيفتك للحصول على وظيفة أخرى فإنك تعد نفسك لمدة معينة تستطيع أن تتكيف فيها مع المكان الجديد، وتكامل نفسك مع مجموعة عمل مختلفة. متأملا، بعد فترة أن تستقر في النهاية في وظيفتك الجديدة، ولكن، في بعض الأحيان، تبقي بعض الأصدقاء الجيدين من الوظيفة السابقة، ويمكنك أن تلتقي بهم مجددا بعد انتقالك. وربما لاحقا، يمكنك التحدث مع زملاء العمل السابقين لتعرف ماذا حدث مع الشخص الذي وظف ليحل في مكانك السابق.
هذا نادرا ما يحدث في مشاريع البرمجيات الحرة.
ربما يظهر الجانب السيئ في تعاقب الأجيال في المشاريع الحرة في هيئة قاسية جدا يطلق عليها فجوة المعرفة. فعندما يغادر المطور السابق المشروع وخصوصا إذا ما كان لديه خبرة واسعة في مجتمع المشروع، فإنه يترك خلفه المعرفة الحسية و المجردة معا والتي ربما لن تنتقل إلى القادمين الجدد.
أوضح مثال هو الشفرة المصدرية. فمثل أي عمل فكري (حسنا على الأقل الواحد يمكنه توقع ذلك، أليس صحيحا) فإن المطورين يتركون بصمتهم الشخصية في كل مرة ينتجون فيها شفرة جديدة. ففي بعض الأحيان، فإنك تشعر بالامتنان الأبدي لذلك المبرمج الذي كتب قطعة برمجية أنيقة ذكية تشرح نفسها بنفسها و سهلة الصيانة. وفي مرات أخرى، فإن الموقف هو العكس، فإنك تناضل لفهم شفرة مبهمة غامضة من دون أي تعليق أو إشارة يمكن أن تساعدك.
هذا ما حاولنا قياسه في عام 2009م في دراسة قدمناها في HICSS 2009 بعنوان" استخدام علم آثار البرمجيات لقياس فقدان المعرفة في المشاريع البرمجية بسبب تحول المطورين". في حال أنك متعجب من العنوان، فإنه ليس له علاقة بالسياط و الكنوز و المغامرات المشوقة، بالرغم أنها كانت دراسة ممتعة. فما قمنا بقياسه ( مع أشياء أخرى) كان نسبة الأكواد اليتيمة المتبقية بواسطة المطورين الذين تركوا المشاريع الحرة، ولم يستلمها أي من المطورين الحاليين بعد. وفي هذه الدراسة اخترنا أربعة مشاريع ( إيفولوشن [عميل للبريد الإلكتروني] و جمب [محرر رسوميات شهير] و إيفنس [مستعرض وثائق] و نوتيلس [مستعرض ملفات]) لاختبار نظريتنا في الدراسة. ولقد وجدنا نتائج مثيرة حقا.
أظهر مشروع إيفولوشن نموذجا مقلقا بعض الشيء، فبالنسبة للشفرة اليتيمة كانت تتزايد مع الوقت. ففي عام 2006م كانت قرابة 80% من أسطر الشفرة المصدرية تخلى عنها المطورين السابقين وظلت هكذا من غير تعديل من بقية الفريق. وفي المقابل، يظهر جمب نموذجا مختلفا كليا، ففريق التطوير يبذل جهدا واضحا و بارعا في تقليل عدد الأسطر اليتيمة في الشفرة المصدرية. وبالمناسبة، تذكر أن جمب مصنف أنه من نوع المشاريع ذات سلاطين الشفرة، وهكذا فإنه يستفيد من فريق التطوير الثابت لمواجهة هذه المهمة المثبطة.
فهل هذا يعني أن مطوري جمب لديهم خبرة أفضل من فريق إيفولوشن؟ إذا أردت الصدق، فنحن لا نعلم. وبالرغم من ذلك، فإننا نستطيع التنبأ بخطر واضح و متوقع وهو: كلما ارتفعت نسبة الشفرة اليتيمة، كلما زاد حجم الجهد المبذول لصيانة المشروع. فعندما تحتاج لإصلاح علة، أو تطوير ميزة جديدة، أو تحسين ميزة موجودة، فإنك ستصطدم بشفرة لم ترها من قبل. وربما بلا شك أنك مبرمج بارع، ولكن لا يهم ما مدى براعتك، فإن مطوري جمب يملكون ميزة واضحة في هذه الحالة، حيث أنهم لديهم دائما شخص ما في الفريق ذو معرفة شاملة بمعظم الشفرة التي يحتاجوا لصيانتها. بالإضافة، إلى أنهم يعملون على تقليل كمية الشفرة غير المعروفة باستمرار على مدى الطويل.
يبدو وكأنه البيت
استطاعت بعض المشاريع بشكل مثير أن تحافظ على المستخدمين لمدة زمنية أطول مما يتوقعها أي شخص. ومجددا يمكننا أن نجد الدليل التجريبي لدعم هذا الادعاء. ففي OSS 2005، قدم مشيلمير، و روبلس و جونزليز بارهونا بعض النتائج ذات صلة تدعم هذا التوجه. فقد قاموا بدارسة استمرار المساهمة لمشرفي البرمجيات في مشروع دبيان، حاسبين ما يطلق عليه معدل نصف العمر. وهو الوقت اللازم لشهرة معينة من المشرفين حتى تتراجع إلى نصف حجمها المبدئي. وكانت النتيجة أن معدل نصف العمر لمشرفي برمجيات دبيان يقدر بحوالي 7.5 سنة. و بكلمات أخرى، فإن الدراسة التي امتدت على مدار ست سنوات ونصف (ما بين يوليو 1998م إلى ديسمبر 2004م)، وشملت من دبيان 2.0 إلى دبيان 3.1 (الإصدارات المستقرة فقط)، أظهرت أن أكثر من 50% من مشرفي برمجيات دبيان 2.0 ظلوا مساهمين في دبيان 3.1.
لقد أنشئ مشروع دبيان إجراء رسميا لقبول مشرفي البرمجيات الجدد (والذين يعرفون أيضا بمطوري دبيان) تشمل قبول عقد دبيان الاجتماعي و إظهار معرفة جيدة بسياسة دبيان. وكنتيجة، فإن الواحد يتوقع إيجاد مساهمين ملتزمين لا بأس بهم. وفي الواقع هذه هي الحالة، حيث أن الباحثين وجدوا أن الحزم التي تترك من قبل مشرفين سابقين تستلم عادة من قبل مطورين آخرين باقين في المجتمع. ما عدا في الحالة التي تصبح فيه الحزمة غير مفيدة فإنها تستبعد ببساطة. وأظن أننا نستطيع تعلم بعض الخلاصات المفيدة من هذه الدراسات:
1- اقض بعض الوقت في تطوير الأدلة الإرشادية الأساسية لمشروعك. ويمكن أن تبدأ في مستند واحد صغير تشرح فيه بعض التوصيات و الممارسات التي ينصح بها. ويجب أن يتطور مع تطور ونمو المشروع، ليخدم ككبسولة تعليم للقادمين الجدد ليفهموا بسرعة القيم الأساسية لفريقك، بالإضافة إلى سمات أسلوب عملك.
2- أجبر نفسك على اتباع معايير معروفة في كتابة الشفرة البرمجية، والممارسات الجيدة و أسلوب أنيق. وثق شفرتك. ضمن تعليقات تشرح الأقسام وخصوصا التي يمكن أن تكون صعبة على الفهم. أبعد نفسك عن الشعور بأنك تهدر وقتك. ففي الواقع، أنت تصبح أكثر نفعية، تستثمر الوقت من أجل مستقبل مشروعك.
3- إذا كان ممكنا، عندما يأتي الوقت لخروجك من المشروع، اجعل الآخرين يعلمون بقرارك بفترة زمنية كافية. تأكد من فهمهم أي من الأجزاء الحساسة التي ستحتاج لمشرف جديد. وبشكل مثالي، إذا كنت مدير مجتمع، جهز إجراء بسيط على الأقل لأتمتة هذه العملية والتأكد بأنك لم تنس أي نقطة مهمة قبل أن يغادر ذلك الشخص المشروع (وخصوصا إذا كان مطورا رئيسيا).
4- أبق عينيك مفتوحتين على حجم الأكواد اليتيمة. فإذا زادت بشكل متسارع، أو أنها وصلت لنسبة كبيرة في مشروعك، فإنها مؤشر واضح بأنك ستواجه مشاكل في القريب العاجل، وخصوصا إذا زاد عدد تقارير العلل أو أنك تخطط لإعادة تنظيم شفرتك بهيكلة جديدة جدا.
5- تأكد دائما بوضع إرشادات و ملاحظات كافية للشخص القادم الذي سيستلم عملك في المستقبل.
أتمنى لو كنت أعرفك أنك قادمٌ ( قبل أن أخرج)
أنا أعترف أنه ليس بالسهولة بأن تفكر بنجاحاتك أثناء عملك بالبرمجة. ففي العديد من الأوقات، أنت لا تدرك أن شفرتك ربما ينتهي بها المطاف في مشروع آخر، أو تستخدم من قبل أناس آخرين، أو تستبدل من قبل شخص آخر مستعد لإكمال عملك بعد ذلك. على كل، فإن أكثر الأصول تميزا في المشاريع الحرة هو هذا بالتحديد: الشفرة سيعاد استخدامها، وتعتمد و تكامل و تطور من قبل شخص آخر. قابلية الصيانة هي ميزة حساسة في هندسة البرمجيات، ولكنها تصبح ميزة أساسية عظمى في البرمجيات الحرة. ولا تقتصر على الشفرة المصدرية، إنها تدور حول الناس و العلاقات الاجتماعية و السلوك الرقمي. إنها تفوق الذوق الجيد بكثير. وكما يقول المثل (" تحصد ما زرعته" ) وتذكر ذلك، ففي المرة القادمة، ربما تكون أن القادم الجديد الذي سيملأ فجوة المعرفة الذي تركها مطور سابق.