تأليف: ماركس كروتزسش من كتاب النصيحة المفتوحة، ترجمة: فهد السعيدي
ماركس كروتزسش باحث ما بعد الدكتوراة في شعبة علوم الحاسوب بجامعة إكسفورد. نال درجة الدكتوراه من معهد المعلومات التطبيقية و أساليب الوصف الرسمي بـ بمعهد كارلسروه للتكنولوجيا في 2010. كان اهتمام بحثه في عمليات أتمتة المعلومات الذكية ممتدا من أساسيات ممثلات المعرفة الأساسية إلى مجال التطبيقات مثل الوب دلالي. وهو المطور الرئيسي في منصة تطبيق الوب الدلالي الناجحة MediaWiki الدلالية، و محرر مشارك في مواصفات W3C OWL 2، و المدير الرئيسي في مجتمع بوابة semanticweb.org، و مؤلف مشارك في كتاب Foundations of Semantic Web Technologies.
يطور الباحثون الأكاديميون كمية كبيرة من البرمجيات، وسواء أكان ذلك للتحقق من فرضية، أو لتوضيح نهج جديد، أو فقط مجرد أداة مساعدة في بعض نواحي الدراسة. ففي معظم الحالات، يؤدي نموذج صغير مركز الوظيفة المطلوبة، ثم يتخلص منه بسرعة بعد أن يتحول تركيز الدارسة إلى مواضيع أخرى. ومع ذلك، فمن حين إلى آخر، يظهر نهج جديد أو تقنية قادمة تحمل القدرة على التغيير الفعلي في الطريقة التي تحل بها المشكلة. وهذا ما يعد بالمكانة المهنية و النجاح التجاري و الرضاء النفسي بإدراك الإمكانية الكاملة للفكرة الجديدة. والباحث الذي صنع هذا الاكتشاف سينجذب لاحقا لتعدي مرحلة النموذج إلى مرحلة المنتج الذي سيسخدم فعلا، وسيواجه بمجموعة جديدة من المشاكل العملية.
الخوف من المستخدم
أعطى فرديريك ب. بروك في أحد أشهر أبحاثه في هندسة البرمجيات صورة جيدة عن الجهود المتعلقة بصيانة البرامج الحقيقة، وحذرنا من المستخدم حيث يقول:
"الكلفة الإجمالية لصيانة برنامج واسع الاستخدام في العادة 40 بالمئة أو أكثر من تكلفة تطويره. ويال الدهشة، هذه التكلفة تتأثر بشكل قوي بعدد المستخدمين.فمستخدمين أكثر سيجدون علل أكثر." (1)
وبينما هذه الصورة ستكون مختلفة قليلا في بيئة اليوم، فإن الملاحظة الأساسية تظل صحيحة، أو حتى أنها أصبحت أسوأ مع استخدام الاتصالات العالمية الفورية. والأسوأ، أنه ليس مستخدمين أكثر فقط سيجدون علل أكثر، ولكن أيضا سيطلبون تحسينات أكثر في الغالب. وسواءا أكان خطأ حقيقا، أو طلب ميزة، أو مجرد سوء فهم أساسي لعمليات البرنامج، فإن طلبات المستخدمين عادة ما تكون أبعد شي عن كونها تقرير تقني دقيق للمشكلة. مما يدفع المطورين لمراجعة كل طلب على حده، مستهلكا بذلك الوقت الثمين الذي لا يتوفر لكتابة الشفرة الحقيقة.
وقد يطور الذهن التحليلي للباحث الذي يتنبأ بهذه المشكلة ،وفي ظل مقاومته الطبيعية لمنع المستقبل المظلم لخدمة العملاء، خوفا حقيقيا من المستخدم. وفي أسوأ الظروف، قد يقود هذا إلى قرار ضد المشروع بالكامل، وفي حالة أضعف قد يتعمد الباحث إلى إخفاء منتجات البرامج المذهلة من المستخدمين المحتملين. لقد سمعت أكثر من باحث يقول: "نحن لا نحتاج للمزيد من الإشهار، لقد حصلنا على رسائل بما يكفي!" وفي الواقع، هناك العديد من الحالات حيث يتجاوز جهد التواصل المتعلق بأداة برمجية الجهد الذي يمكن للباحث أن يستثمره من دون الحاجة لترك وظيفته الرئيسة.
وغالبا، على كل حال، يمكن بسهولة منع هذه المخرجات المأساوية. لقد كان من الصعب لبروك أن يتنبأ بهذا. فعندما كتب أبحاثه، كان المستخدمون في الحقيقة زبائنا، و كانت صيانة البرنامج جزءا من المنتج الذي اشتروه. كان لابد من وجود التوزان بين جهود التطوير، و حجم السوق، و السعر. وهذه الحالة ما زالت قائمة للعديد من البرامج التجارية ليومنا هذا، ولكن ليس لها علاقة قوية بواقعية تطوير برامج مفتوحة المصدر ذات نطاق صغير. ففي العادة لا يدفع مستخدموا البرامج المفتوحة المصدر في مقابل الخدمة التي يحصلون عليها. وعلى ذلك فهم ليسوا في موقف الزبون المطالب ولكن عادة في موقف الداعم الشاكر المتحمس. لا يوجد جزءا صغيرا من فن صيانة البرمجيات الحرة الناجح يحول هذه الحماسة إلى دعم مطلوب بشدة، موازنا بين زيادة اهتمام المستخدمين بزيادة مشاركتهم.
وفهم أن مستخدمي البرمجيات المفتوحة المصدر ليسوا مجرد" زبائن لا يدفعون " هو إدارك مهم، ولكن يجب أن لا يقودنا أيضا إلى أن نبالغ في تقدير إمكانياتهم. فالنظير المتفائل للخوف غير العقلاني هو الاعتقاد بأن مجتمعات البرمجيات المفتوحة المصدر النشطة والداعمة تنمو طبيعيا بناءا فقط على الرخصة المختارة لنشر الشفرة المصدرية. إن هذا الخطأ المميت في الحكم لا يزال منتشرا بدهشة، وختم بالفشل للعديد من المحاولات لإنشاء مجتمعات مفتوحة.
الغرس والحصاد
إن الجمع من " مستخدم " ليس " مجتمع ". فبينما ينمو الأول بالأعداد، فإن الأخير لا ينمو بنفسه، أو ينمو جامحا من دون الحاجة للأمل بالدعم للمشروع. إن مهمة مدير المشروع الذي يطمح إلى الاستفادة من طاقة المستخدمين غير المستغلة تشبه المزارع الذي يحتاج لإعداد أرض خصبة و يغرس الحبوب ويسقيها، و ربما يشذب الأغصان غير المرغوبة قبل أن يستطيع قادرا على جني الثمار. ومقارنة مع المكافأة فإن الجهد العام يعتبر قليلا، ولكن من المهم جدا بأن تفعل الأشياء الصحيحة في الوقت الصحيح.
إعداد الأرضية التقنية
يبدأ بناء مجتمعا حتى قبل أن يظهر أول مستخدم. فلغة البرمجة المختارة يحدد عدد الناس الذين سيكونون قادرين على نشر و تنقيح شفرتنا. فلغة Caml الغرضية تبدو لغة جميلة، ولكن استخدام لغة جافا بدلا عنها سيزيد عدد المستخدمين المحتملين بأضعاف كثيرة. لذى يجب على المطورين أن يوازنوا الأمور، حيث أن أشهر التقنيات المنتشرة عادة غير فعالة ولا ذكية. وعمليا تعتبر هذه خطوة صعبة غالبا على الباحثين الذين يفضلون عادة تصميم اللغات المتفوقة. فعندما أعمل على مشروع MediaWiki السياقي، فإني أسئل عادة لماذا بحق السماء نستخدم لغة PHP بينما لغة جافا للمخدمات ستكون أكثر نظافة وأكثر فعالية. وربما المقارنة بين حجم مجتمع MediaWiki السياقي وبين مجتمعات مشاريع جافا المشابة ستكون الإجابة لهذا السؤال. ويرسم هذا المثال أيضا أن الجمهور المستهدف يحدد أفضل خيار للتكنولوجيا الأساسية. يجب على المطور نفسه أن يمتلك الفطنة اللازمة لصنع القرار الأكثر ملائمة للموقف.
إعداد الأرضية بالكامل
مسألة ذات صلة وهي إنشاء شفرة مصدرية مقروء وموثقة بشكل جيد منذ البداية. ففي بيئة أكاديمية، بعض المشاريع البرمجية يتعامل معها من قبل العديد من المساهمين المؤقتين. تغير الموظفين و الطلبة في المشاريع قد يفسد جودة الشفرة. فأنا أتذكر مشروعا برمجيا صغيرا في جامعة TU Dresden قد أدير بشكل جيد من قبل طالب مساعد. وبعد أن تخرج، اكتشف بأنه شفرته وثقت بالكامل باللغة التركية. يتوفر الباحثين ببرنامج جزئي عادة، لذي يجب أن يكون هناك نظاما خاصا لفرض العمل الإضافي اللازم للموصولية الشفرة. وستكون المكافأة بفرصة أكبر لتقارير علل ذات فائدة، أو إصلاحات مفيدة، أو حتى مطورين خارجيين في مرحلة لاحقة.
نشر بذور المجتمعات
يظن عادة مطوروا البرمجيات المفتوحة المصدر غير الخبراء أن نشر شفرتهم بشكل مفتوح خطوة كبيرة. لكن في الحقيقة لن يلاحظ ذلك أحد غيرهم. لجذب مستخدمين ومساهمين على السواء يجب على أحدهم أن ينشر الكلمة. التواصل العام للمشروع الحقيقي يجب على الأقل أن يتضمن على نشرات لكل إصدارة جديدة. القوائم البريدية هي على الأرجح أفضل قناة لهذا. هناك حاجة لبعض المهارة الاجتماعية لإيجاد موازنة بين البريد المزعج و الإعلان المكبوح الخجل. المشاريع التي تندفع بواسطة إيمان راسخ بأنها ستساعد المستخدمين على حل مشاكل حقيقية يفترض أن تكون من السهولة أن يعلن عنها بشكل جيد.سيلاحظ المستخدمين بسهولة الفرق بين الإعلان الوقح و المعلومات المفيدة. وبشكل جلي، يجب أن تأجل النشرات النشطة حتى يصبح المشروع جاهزا. وهذا ليس مقتصرا على الشفرة الحقيقية ولكن يتضمن الموقع الرئيسي و توثيق الاستخدامات الأساسية.
وعلى مدى عمر المشروع، يجب أن يذكر في الأماكن المناسبة، والتي تشمل مواقع الوب (بدءا من موقعك!)، والعروض التقديمية، و الأوراق العلمية، و مناقشات الانترنت. فالواحد لا يمكن أن يقدر بشكل كامل قوة رابط واحد يقود مساهم رئيسي لاحق إلى أول زيارة لصفحة المشروع.ويجب أن لا ينس الباحثون أن ينشروا برامجهم خارج مجتمعاتهم الأكاديمية المباشرة. الباحثون الآخرون في النادر هم أفضل قاعدة لمجتمع نشط.
توفير مساحة للنمو
تعتبر مهمة سهلة جدا ولكنها عادة مهملة أن يقوم مدراء المشاريع بتوفير مساحة للتواصل يمكن للمجتمعات أن تنمو فيها. فإذا لم يتوفر للمشروع قائمة بريدية مخصصة، فإن كل طلبات الدعم سترسل بشكل خاص إلى المدير. وإذا لم يكن هناك متتبع عام للعلل، فإن تقارير العلل ستكون قليلة و أقل مساعدة. ومن دون توفير ويكي قابل للتحرير للوثائق المستخدم، فإن المطور سيضاف عليه مهمة توسعة و تنقيح التوثيقات بشكل مستمر. وإذا لم تكن هناك قناة تطوير الشفرة المصدرية قابلة للوصول، فإن المستخدمين لن يتمكنوا من فحص آخر إصدارة قبل أن يتذمروا من العلل. وإذا كان مخزن الشفرة مغلق بشكل متصلب، فإنه من المستحيل السماح بمساهمين آخرين. كل هذه البنية التحتية متوفرة بالمجان بواسطة العديد من مقدمي الخدمات.
ليس كل أشكال التفاعل تكون مرغوبا بها، فعلى سبيل المثال، هناك أسباب لجعل مجموعة المطورين مغلقة. ولكن سيكون من الحماقة أن تتوقع الدعم من مجتمع من دون الإعداد للمساحات الأساسية لهذا الدعم.
تشجيع النمو والتحكم به
يقلق المطورون غير المحنكين عادة من فتح القوائم البريدية، والمنتديات و الويكي للمستخدمين لأنه سيتطلب المزيد من العبء الإضافي في الصيانة. إنه من النادر حدوث ذلك، ولكن هناك بلا شك بعض الأنشطة الأساسية ضرورية. تبدأ بالتطبيق الصارم لاستخدام التواصل العام. يجب أن يعلّم المستخدمين بأن يسألوا الأسئلة بشكل عام، وأن يبحثوا عن الإجابة في الوثائق قبل أن يسألوا، وأن يبلغوا عن العلل في متتبع العلل بدلا عن البريد الإلكتروني. فأنا أميل إلى رفض كل طلبات الدعم الخاصة أو تمرير الإجابات إلى القائمة البريدية العامة. وهذا يضمن أيضا أن الحلول ستتوفر في الوب للمستخدمين المستقبلين ليجدوها. وفي كل حالة، يجب أن يُشكر المستخدمون بشكل واضح على كل أنواع المساهمات، فمن الضروري لبناء مجتمع صحي أن يكون هناك الكثير من الناس المتحمسة و الراغبة بالمساعدة .
وعند وصول لحد معين من كثافة المستخدمين، سيبدأ الدعم بالظهور من مستخدم لمستخدم. وهذه عادة لحظة سحرية في المشروع، و إشارة أكيدة بأنه في الطريق الصحيح. وبشكل مثالي، يجب أن يستمر قائد المشروع الأساسي بتقديم الدعم للأسئلة المعقدة، ولكن في نقطة معينة سيأخذ مستخدمون معينون القيادة في النقاشات، ومن الأهمية بمكان أن تشكرهم (شخصيا) وأن تشركهم أكثر في المشروع.والعكس بالعكس، فيجب إيقاف التطوير غير الصحي حيثما أمكن، ففي بعض التصرفات العدوانية يمكن أن تكون خطرا حقيقا على تطوير المجتمعات. وبطريقة مماثلة، ليس كل الحماسة بالمساعدة تعتبر منتجة، وإنه من الضرورة عادة قول لا، بشكل ودي ولكن واضح، لمنع المشاكل المستقبلية.
المستقبل مفتوحٌ
بناء المجتمع الأولي حول مشروع هو أهم جزء من نقل نموذج بحثي إلى برنامج مفتوح المصدر ناضج. وإذا نجح هذا الجزء، فهناك العديد من الخيارات للتطوير المستقبلي للمشروع، اعتمادا على أهداف مدير المشروع والمجتمع. فمن بعض الاتجاهات العامة تشمل:
- الاستمرار بنمو المشروع والمجتمع وتطويرهما، وتوسيع فريق التطوير الأساسي ومدرائه، ليصل في النهاية إلى الاستقلال عن أصله الأكاديمي. قد يتطلب هذا المشاركة بأنشطة اجتماعية إضافية ( من مثل أحداث مخصصة) وربما تأسيس دعم منظمي.
- إنشاء شركة للاستثمار التجاري لما يبني على المشروع، على سبيل المثال، الترخيص المزدوج أو نموذج الاستشارات. فالأدوات الجاهزة و المجتمعات النابضة بالنشاط تعتبر أصول رئيسية لأي شركة ناشئة، وقد تكون ذات فائدة للعديد من استراتيجات الأعمال من دون إبعاد أصل المنتج المفتوح المصدر.
- الانسحاب من المشروع، فهناك العديد من الأسباب لماذا لا يستطيع الواحد صيانة علاقة وطيدة مع المشروع. ويرفع إنشاء مجتمع مفتوح صحي فرص إمكانية استمرار المشروع إلى الحد الأقصى. وفي أي حالة، يعتبر أكثر احتراما أن يكون ذلك أكثر وضوحا بدلا من إقصاء المشروع بصمت، وقتله بعدم النشاط حتى يصل من الضعف إلى نقطة عدم إيجاد مدير مستقبلي له.
سيكون شكل المجتمع مختلفا عندما تعمل على أحد هذه الخيارات الرئيسية. ولكن في كل حالة، يتغير دور الباحث في هدف المشروع. فقد يتحول العالم والمبرمج إلى مدير أو مدير تقني. وفي هذا المعني، يكون الفرق الأساسي بين مشروع مفتوح المصدر مؤثر و نموذج بحثي مستمر ليس كبيرا من ناحية العمل ولكن من ناحية نوعية العمل المطلوب للنجاح. وفهم هذا يعتبر جزءا من النجاح، وتبقى الجزئية الأخرى الوحيدة المطلوبة وهي قطعة برمجية رائعة.
(1) Frederick P. Brooks, Jr.: The Mythical Man-Month. Essays on Software Engineering. Anniversary Edition. Addison-Wesley, 1995.