البحث في الموقع

يدعم تطبيق الشفافية ازدهار المجتمعات مفتوحة المصدر، لذا ينبغي على مديري هذه المجتمعات إدراك ذلك والسعي لتوفير الشفافية بمستوياتها الخمسة على أوسع نطاق ضمن مجتمعاتهم، وفي هذا المقال سنُعرّف كل مستوى من هذه المستويات، ونعرض أهميته وأهدافه. ما الذي يجعل الشفافية مهمة في المجتمعات مفتوحة المصدر؟ خلصنا إلى الأسباب التالية التي تجعل الشفافية مهمة في المجتمعات مفتوحة المصدر وهي: ترفع من مستوى الثقة بين المجتمعات ما يزيد التعاون المثمر بينها. تعمل بفضلها المجتمعات معًا وتتبادل الخبرات بانفتاح. تمنع الاحتكاك بين الأطراف. تتطلب من المدراء عرض النتائج والتقارير بشفافية أمام المساهمين. تشجع على عرض المعلومات الكاملة عن المجتمعات، وهو أمر صحي للغاية ويحفز بناء الثقة المتبادلة. ما هي المستويات الخمسة للشفافية؟ هنالك خمسة مستويات من الشفافية التي تساهم مساهمة كبيرة في ازدهار المجتمعات مفتوحة المصدر وهي: نشر الكود المصدري نشر الإرشادات للمجتمع الاحتفاء بالنجاح الاستماع إلى نبض المجتمع وتحليله الحفاظ على المجتمع سنشرحها تباعًا. المستوى الأول: نشر الكود المصدري يتمحور هذا المستوى حول إصدار الكود المصدري للبرمجيات بموجب ترخيص معتمد من مبادرة المصدر المفتوح OSI وبإصدار عام متاح للجميع عبر نظام خاص بإدارة الإصدارات مثل Git. يهدف المستوى الأول إذًا إلى تأسيس المشروع ليكون مفتوح المصدر. النقطة الأولى بديهية، المشروع مفتوح المصدر يعني إتاحة الكود المصدري للمشروع. الكود المصدري المرخص من مبادرة المصدر المفتوح OSI الذي يتشارك الجميع العمل عليه هو جوهر المشروع مفتوح المصدر. يتيح نظام إدارة الإصدارات التعاون ويسمح لكل من يرغب بتحليل المشروع والمساهمة فيه. المستوى الثاني: نشر الإرشادات للمجتمع يهتم المستوى الثاني من الشفافية بتوفير التوثيقات والمصادر وكل ما يلزم لإرشاد المساهمين، وتنظيم فعاليات خاصة لنشر المعرفة ضمن المجتمع. يتجلى هدف هذا المستوى بإنشاء وتنمية مجتمع المشروع مفتوح المصدر. بناء مجتمع فاعل هو مفهوم أوسع بكثير من مجرد إتاحة الكود المصدري. بقدر ما تتحلى بالشفافية حول كيفية عمل مشروعك، وكيف يمكن للآخرين المساهمة فيه، تزيد فرص انضمامهم إلى المشروع وتطويره. تتضمن تنمية المجتمع تنظيم الفعاليات والأنشطة للمساهمين. المستوى الثالث: الاحتفاء بالنجاح عندما تصل لهذا المستوى ستغدو مشاركة الأفكار والرؤى وعرض تطورات المشروع من أهم أولوياتك. ينصب هدف المستوى الثالث على الاحتفاء بالنجاح والإعلان عنه وتأمين المزيد من الدعم للمراحل اللاحقة. يزداد تتبع الأخبار صعوبةً مع توسع المجتمعات مفتوحة المصدر، ويتعذر على الجميع معرفة المستجدات في كل مكان. أن تعرض النتائج والنشاطات بشفافية في أرجاء المجتمع، يعني أن تمنح المساهمين شعورًا بالتقدير وبأن مشاركاتهم مهمة ومرئية. تتميز التقارير والتحليلات في هذا المستوى بكونها متفرقة ولا تعتمد أدواتٍ خاصة. المستوى الرابع: الاستماع إلى نبض المجتمع وتحليله الاستماع إلى نبض المجتمع ومراقبة تطوره هو جوهر المستوى الرابع من الشفافية، بالإضافة إلى تطوير برامج خاصة تساعد على اتخاذ الإجراءات التصحيحية. أما هدف هذا المستوى فيتمثل في نقل المجتمع إلى المستوى التالي عبر فهم مسار تطوره بطرق علمية ودقيقة. تساعد التقارير وأدوات التحليل في مراقبة ما يحدث. يمكنك مقارنة الأحداث في المجتمع، وتتبع تفاعل المساهمين معها. الاستماع الدائم والتحليل يقود إلى استنباط رؤى أعمق وأكثر إفادة عن المجتمع. المستوى الخامس: الحفاظ على المجتمع يركز المستوى الخامس والأخير على مقاييس المجتمع وتحسين المشاركة المجتمعية من أجل الحفاظ عليه ورعايته على المدى الطويل مهما حصلت من متغيرات. يسعى هذا المستوى إلى اتخاذ قرارات هادفة ومؤثرة تدعم المشاركة المجتمعية. تطبيق نظم مرنة للتفاعل مع التغيرات في مقاييس المجتمع. تحليل وتتبع التغيرات التي يمكن أن تطرأ على المجتمع. وضع قواعد للمشرفين والمطورين مثل اتفاقيات مستوى الخدمة SLA وتحمل المسؤولية ليجعلوا المشاركة المجتمعية في صدارة أهدافهم، مع الحرص على وجود نظم تضمن تحقيق ذلك. الخلاصة يحتاج مديرو المجتمعات مفتوحة المصدر إلى تطبيق هذه المستويات الخمسة من الشفافية حتى يدعموا تطور وازدهار هذه المجتمعات. ترجمة -وبتصرف- للمقال ‎5 levels of transparency for open source communities لأصحابه Georg Link و Anirudha Jadhav و Emilio Galeano Gryciuk. اقرأ أيضًا تراخيص البرامج مفتوحة المصدر ما الذي يحفز المساهمين لتطوير المشاريع مفتوحة المصدر؟ الفرق بين البرمجيات الحرة ومفتوحة المصدر

تتحدث كاتبة المقال عن تجربتها الشخصية مع البرمجيات مفتوحة المصدر، وبالتحديد عن الخطأ الأول الذي ارتكبته في بداية مشوارها، وكاد يثنيها عن الشروع بالعمل، وقد عنونت المقال بمتلازمة المحتال Impostor Syndrome في إشارة منها إلى ذلك الشعور الداخلي الذي يتغلب علينا في بعض الأحيان ويزعزع ثقتنا بأنفسنا عبر التشكيك بقدراتنا وما أنجزناه، علّ المقال يكون مفيدًا لكل راغب بدخول هذا المجال. تعلّمتُ -تقول الكاتبة- أساسيات البرمجة من خلال الإنترنت، اتبعت عددًا من البرامج التعليمية وأنجزت المشاريع الملحقة بها، وأحرزت تقدمًا، لكني تساءلت دومًا ماذا بعد؟ ما هي خطوتي التالية للارتقاء إلى المستوى الأعلى؟ وفي هذه المرحلة صادفني منشور على إحدى المدونات يخبر القارئ أن المساهمة في المشاريع مفتوحة المصدر هي الطريقة المثلى لكل مبتدئ يرغب بتطوير مهارته البرمجية والانتقال إلى مستوى أعلى. إذًا بعد أن قرأت ذلك المنشور انتابني شعورٌ قوي أني وصلت للطريق الصحيح، وأن المساهمة في المشاريع مفتوحة المصدر هي السبيل الوحيد لأغدو مطورًا حقيقيًا، لذا بدأت باتباع الإرشادات التي يذكرها المنشور وأولها إنشاء حساب على GitHub، وخلال أقل من عشر دقائق شعرت بالارتباك الشديد لدرجة جعلتني أتخلى عن الفكرة تمامًا. لم أكن شخصًا لا يحب التعلم بل على العكس، لكن المصادر التي اعتمدتها تتوقع من القارئ أن يمتلك معرفةً جيدة ومسبقة بمنصة Git و GitHub وكيف أنها أتاحت للعديد من المطورين حول العالم أن يتعاونوا في مشروعٍ واحد. لذا عدت إلى دروسي ولكن الرغبة في دخول المجال لم تفارقني أبدًا، وعشت صراعًا داخليًا لسنوات بين أن المساهمة في المصدر المفتوح تجربة سهلة وقيمة وينبغي أن أخوضها، وذلك الانطباع الداخلي بأني لست أهلًا بعد لكتابة الأكواد في مشاريع مفتوحة المصدر. لازمتني مشاعر عدم الثقة حتى بعد أن تآلفت مع Git، استمر جدل المحتال الداخلي بأني لم أكتب كودًا لمشاريع حقيقية بعد بل مجرد أكواد لمشاريع تعليمية وتدريبية بل حتى تجارب، وأني لست مؤهلةً للمساهمة في مشاريع حقيقية يستخدمها الآخرون ويعتمدون عليها، في الواقع حتى عندما عملت بصفتي مهندسة برمجيات وكتبت أكوادًا حقيقية، انتابتني المشاعر نفسها، وكانت الحجة أنني أعمل مع لغة برمجة واحدة، فما الذي يضمن نجاحي في مكانٍ آخر ومع أطر عمل وربما لغاتٍ برمجية أخرى. استغرقت فعليًا حوالي السنة ونصف من العمل الجاد بدوامٍ كامل، لأشعر أخيرًا بالثقة الكافية لإغلاق حجج المحتال الداخلي، وتقديم طلب السحب الأول PR على GitHub وبدء رحلتي مع البرمجيات مفتوحة المصدر. أساطير ضارة سنكشف أمامكم زيف اثنتين من أكثر الأساطير الضارة انتشارًا حول البرمجيات مفتوحة المصدر. الأسطورة الأولى: المساهمة في البرمجيات مفتوحة المصدر سهلة تكررت أمامي مرارًا خلال هذه الرحلة رسالةٌ مفادها أن المساهمة في البرمجيات مفتوحة المصدر أمرًا سهلًا، وعندما لم أتمكن من البدء بسهولة بدأت أتساءل عن مهاراتي الخاصة وأشك فيها. أما الآن أفهم معنى هذه الرسالة بطريقةٍ مختلفة، فعندما يصف الناس هذه المساهمة بالسهلة، فهم يقصدون أنها هدف قابل للتحقيق ويمكن للمبتدئين الوصول إليه إن اجتهدوا، أو أنك تستطع المساهمة في البرمجيات المفتوحة المصدر دون كتابة الكثير من التعليمات البرمجية المعقدة، هذا كله صحيح ولكن الأهم أن تعرف أن هذه المساهمة في الواقع صعبة وتتطلب منك وقتًا كافيًا تفهم خلاله قاعدة شيفرة جديدة وأدوات خاصة يستخدمها المطورون. بالتأكيد لا نريد إثناء المبتدئين عن المحاولة، لكننا نرغب في إخبارهم أن مواجهة التحديات أمرًا طبيعيًا ومتوقعًا للغاية خلال العملية. الأسطورة الثانية: لابد أن يساهم كل مطور حقيقي بالبرمجيات مفتوحة المصدر لطالما ذكرني المحتال الداخلي بأن عدم مساهمتي في البرمجيات مفتوحة المصدر يعدّ نقصًا واضحًا ووصمة عار في مسيرتي المهنية، بصراحة حتى وأنا أكتب هذا المقال أشعر بالذنب لأنني لم أساهم أكثر في المجتمع مفتوح المصدر. العمل على هذه البرمجيات طريقة رائعة للتعلم والمشاركة في مجتمع المطورين الأوسع هذا كله لا ريب فيه، إلّا أنها بالتأكيد ليست الطريقة الوحيدة، إذ يمكنك التدوين أو حضور اللقاءات أو العمل في مشاريع أخرى أو القراءة أو الإرشاد أو حتى العودة إلى المنزل في نهاية يوم عمل طويل للاستمتاع بلقاء ودي مع الأهل أو الأصدقاء. ما نريد قوله في النتيجة أن المساهمة في البرمجيات مفتوحة المصدر تحدي ممتع ومفيد حقًا، لكن بشرط أن يكون هو التحدي الذي اخترته. خطئي الأول في المساهمة بالمشاريع مفتوحة المصدر خطئي الأول كان السماح للمحتال الداخلي بالتحكم بقراري، فقد جعلني أتردد لسنوات بحجة أني لست مؤهلةً بعد، حتى أني لم أفهم في حينها حجم العمل الذي أحتاجه للوصول إلى مستوى أشعر معه بالثقة التامة لكتابة كود في مشروع غير مألوف (وهي بالمناسبة نقطة ما زلت أسعى تحقيقها حتى اليوم)، زد على ذلك أني استسلمت لفكرةٍ مفادها أن المساهمة في المجتمع مفتوح المصدر هي الطريقة الوحيدة لإثبات جدارتي بصفتي مطور جيد. في النهاية بدأت، وقدمت طلب السحب الأول على أحد المشاريع واسعة النطاق، ولكن انعدام الثقة بالنفس أفسد علي التجربة بأكملها وجعلها أقل إمتاعًا. لا تدع Git يحبط عزيمتك إذا كنت تحاول تعلم المزيد عن Git ووجدت صعوبة بذلك، أو كنت مبتدئًا ويمنعك Git من تقديم مساهمتك الأولى في هذا المجتمع، فلا تقلق لست الوحيد الذي يشعر بذلك لأن Git معقد بالفعل، ولا يُتوقع منك أن تتعلمه على الفور وتفهمه بمجرد إلقاء نظرة عليه فهو يحتاج وقتًا، ولكن ما إن تتعلمه حتى تكتشف فائدته الجمّة وما يقدم من تسهيلات للمطورين ليعملوا معًا على مشروعٍ واحد وفي وقت واحد ومن ثم قيامه بدمج تعديلاتهم الفردية في الكود النهائي. يوجد العديد من المصادر الجيدة لتتعرف على Git و GitHub (وهو الموقع الذي يستضيف الشيفرات البرمجية ويتيح للأشخاص أن يتعاون عليها باستخدام Git)، ويمكنك أن تبدأ من قسم Git على أكاديمية حسوب سيشكل نقطة انطلاق جيدة إضافة إلى أنه متاح باللغة العربية إذ فيه عدة سلاسل ومقالات مفيدة. أنصحك أن تنتقل إلى سلسلة "المساهمة في المشاريع مفتوحة المصدر" وأن تبدأ بقراءة المقال الأول فيها كيفية المساهمة في المشاريع مفتوحة المصدر: ابدأ بتعلم نظام Git فهي سلسلة مفيدة مؤلفة من ستة مقالات، كما تجد بالقسم أيضًا سلسلة عن تعلم Git مؤلفة من سبعة مقالات. ترجمة -وبتصرف- للمقال My first contribution to open source: Impostor Syndrome لصاحبته Galen Corey. اقرأ أيضًا ما هي البرمجيات مفتوحة المصدر؟ تراخيص البرامج مفتوحة المصدر الإشراف على مشاريع البرمجيات مفتوحة المصدر عبر غيت هب GitHub الفرق بين البرمجيات الحرة ومفتوحة المصدر

لطالما كانت الأسباب التي تدفع الناس للمساهمة في المشاريع الحرة ومفتوحة المصدر FOSS مثارًا للاهتمام، ومع ذلك فإن أحدث البحوث حولها يعود تاريخه لعشر سنوات سابقة أو ربما أكثر، وقد تغير العالم كثيرًا منذ ذلك الحين. لذا سنعرض في هذا المقال سبع أفكار من دراسة بحثية حديثة أثارت الموضوع مجددًا، وأعادت دراسة الأسباب القديمة، وسألت المساهمين الحاليين عن ما يحفزهم اليوم لتطوير مشاريع حرة مفتوحة المصدر، وخلُّصت في النتيجة لمجموعة أفكار من شأنها مساعدة مديري المجتمع مفتوح المصدر على تطوير مجتمعهم من جهة، وتفسير الأمر للمهتمين به من أفراد عاملين فيه أو منظمات داعمة أو دارسة له من جهةٍ ثانية، ففي النهاية معرفة الأسباب مهمة للتطوير، فمعرفة محفزات المساهمين تفيد الجميع في اتخاذ قرارات مؤثرة وداعمة لهم ولمشاريعهم. لمحة تاريخية عن البحوث التي تناولت محفزات المشاريع مفتوحة المصدر لننظر في أصول المصدر المفتوح حتى نعرف ما الذي جعل دراسة محفزات المساهمين فيه أمرًا مهمًا ومثيرًا للاهتمام. مُذ بدأت حركة البرمجيات مفتوحة المصدر عرفت بأنها تمردٌ، إذ تمردت على المألوف وتحدّت أسلوب الشركات التي تبيع البرمجيات وتعتمد حقوق النشر والرخص لتقييد حرية المستخدم والمطوّر، ولم يكن سهلًا على أحد فهم الأسباب التي أدت إلى إنتاج برمجيات بهذه الجودة العالية على أيدي مطوّرين بدأوا بتطويرها أساسًا لاستخدامهم الشخصي أو تطوّعوا بمهاراتهم في سبيل تحقيقها، فقد وجدت روح تعاونية مذهلة في صلب هذه الحركة أثارت اهتمام الجميع بما فيهم الشركات أيضًا، وبالنتيجة أصبحت البرمجيات مفتوحة المصدر بمثابة تحول فلسفي في مسار التطوير جعل طريقة التعاون هذه متاحة ومقبولة لدى أصحاب الأعمال. نشرت دراسة بحثية من أشمل الدراسات في العام 2012، تلخص المحفزات التي تدفع المساهمين في هذا المجال لكن المحفزات لابد تغيرت على مدى السنوات العشر الماضية، بالأخص مع تزايد اهتمام الشركات بالمشاريع مفتوحة المصدر ووجود موظفين بأجرٍ مدفوع يعملون حاليًا في هذا المجال، وأصبح من الضروري إعادة دراستها وتقييمها. تغير محفزات المساهمين تناولت دراستنا العلمية بعنوان الأسباب تتغير- إعادة نظر في دوافع المساهمين في المشاريع مفتوحة المصدر المحفزات التي تدفع الناس للمساهمة في المشاريع الحرة مفتوحة المصدر FOSS وما يدفعهم للاستمرار فيها بعد ذلك. هدفت هذه الدراسة في المقام الأول إلى البحث في التغيرات التي طرأت على دوافع المساهمين منذ العقد الأول من القرن الحادي والعشرين، ومن ثم إلى نقل البحث لسويةٍ أخرى تتناول تغير هذه الدوافع مع استمرار المساهمين في مساهمتهم. يستند البحث إلى استبيان أُجري في أواخر العام 2020 وأجاب عنه حوالي 300 مساهم في البرمجيات الحرة ومفتوحة المصدر. أهم سبعة محفزات للمساهمة في المشاريع مفتوحة المصدر نلخص أهم نتائج الدراسة فيما يلي. 1. تلعب الدوافع الجوهرية دورًا رئيسيًا بينت الدراسة أن أغلب الناس يساهمون في المشاريع الحرة ومفتوحة المصدر لأسبابٍ تتعلق بالمتعة بنسبة 91٪ والإيثار بنسبة 85٪ والقرابة بنسبة 80٪، أما عند تحليلنا للاختلافات بين دوافع الانضمام والاستمرار في المساهمة، وجدنا أن كلًا من الأيديولوجيا أو الاستخدام الشخصي أو البرامج التعليمية يمكن أن يشكلوا حافزًا لانضمامهم، لكنهم يستمرون لأسباب جوهرية أخرى هي المتعة والإيثار والسمعة وصلة القُربى. 2. السمعة والدافع المهني أقوى من المقابل المادي يسعى المساهمون للسمعة الطيبة بنسبة 68٪ وتدفعهم الرغبة في التطور المهني بنسبة 67٪، بينما أشار أقل من 30٪ منهم بأن دافعهم للانضمام كان ماديًا سعيًا لأجرٍ مدفوع، بموازنة هذه النتائج بالدراسات السابقة نجد أن السمعة اليوم تعد دافعًا أكثر أهمية مما كانت عليه في ما مضى. 3. ازدياد أهمية الجوانب الاجتماعية فقد ارتفعت نسب الرضا والاستمتاع بمساعدة الآخرين إلى 89٪ في التصنيف والقُربى إلى 80٪ موازنةً بالدراسات الاستقصائية التي أجريت في بدايات العقد الأول من القرن الحادي والعشرين. 4. تتغير محفزات الناس كلما زاد عهدهم بالمساهمة تباين محفزات الانضمام والاستمرار من أوضح نتائج الدراسة، فقد أعطى 155 مشارك من أصل 281 أي ما نسبته 55٪ أسبابًا متباينة بين ما انضموا أساسًا لأجله وما يدفعهم اليوم للاستمرار. لاحظ الشكل أدناه فهو يوضح التحولات في محفزات المشاركين بين ما قادهم للانضمام بدايةً وما يدفعهم للاستمرار اليوم، فحجم المربعات الموجودة على اليسار يمثل عدد المساهمين الذين قادهم هذا الحافز للانضمام وبدء المساهمة في البرمجيات الحرة والمفتوحة المصدر، أما تلك الموجودة على اليمين فتشير إلى دافع الاستمرار، وخطوط الوصل بين الطرفين تمثل التحولات من دافع لآخر، أما ثخن كل خط يتناسب مع عدد المساهمين الذين تحولوا من دافعٍ إلى آخر بين المرحلتين. 5. الاستخدام الشخصي مجرد مدخل انخفضت أهمية الحافز الناجم عن تطوير البرامج لغرض الاستخدام الشخصي منذ الأيام الأولى، وتحول أغلب من انضموا لهذا السبب، إلى محفزاتٍ أخرى مثل الإيثار والتعلم والمتعة وتبادل المنفعة والخبرة، راجع الشكل أعلاه ولاحظ ذلك. 6. تختلف المحفزات تبعًا للخبرة والعمر اتجهت حوافز المطورين ذوي الخبرة أكثر باتجاه الإيثار بمعدل 5.6 ضعفًا عن المبتدئين، والأجور بمعدل 5.2 ضعفًا، وكذلك الأيديولوجية 4.6 ضعفًا، بينما أعطى المبتدئون معدلاتٍ أعلى للأسباب المتعلقة بحياتهم المهنية بمعدل 10 أضعاف والتعلم بحوالي 5.5 ضعفًا والمتعة 2.5 ضعفًا. وبالنظر إلى التحولات في محفزات المشاركين وجدنا زيادةً كبيرة في التحول إلى الإيثار حوالي 120% لدى ذوي الخبرة، بينما انخفضت انخفاضًا طفيفًا حوالي 16% لدى المبتدئين. أما فئة المشاركين الشباب فقد انضم عددٌ قليلٌ منهم إلى البرمجيات الحرة والمفتوحة المصدر بدافع مهني، لكن الكثيرين تحولوا بعدها إلى الإيثار بزيادة بلغت 100٪. 7. المحفزات تختلف بين المبرمجين وسواهم أعطى المبرمجون أسبابًا تتعلق بالمتعة أكثر من غيرهم بنحو 4 أضعاف، أما غير المبرمجين فقد أجابوا بمحفزاتٍ تتعلق بالأيديولوجية بمعدلات تعادل 2.5 ضعفًا. تحفيز المساهمين بناء على طول عهدهم في المجال تساعد معرفة اختلاف المحفزات بين المساهمين الجدد وذوي الخبرة في اتخاذ القرارات والخطوات المناسبة لتحفيزهم والحفاظ عليهم ودعمهم بطرقٍ أفضل. فعلى سبيل المثال جذب مساهمين جدد والحفاظ عليهم ليصبحوا قوة عاملة في المستقبل يتطلب من القائمين على المجتمع الاستثمار في المشاريع التي تركز على مسيرتهم المهنية وجوانب المتعة والإيثار والقرابة والتعلم وهو الأكثر أهمية لفئة الشباب. أما بمرور الوقت وازدياد خبرة المساهمين سيميل معظمهم لحافز الإيثار، وعندها يتعين على المشاريع مفتوحة المصدر -التي تهدف إلى الاحتفاظ بالمساهمين ذوي الخبرة حتى يكونوا أعضاء أساسيين أو مشرفين لديها- أن تستثمر في الاستراتيجيات والأدوات التي توضح لهم كيف سيستفيد المجتمع من عملهم، وتدعم الميزات الاجتماعية على منصات الاستضافة لتجمع بين من يحتاج إلى المساعدة ومن يرغب بتقديمها، ومن ثم تهتم بتسليط الضوء على هذه المساعدات والأعمال الإيجابية وعلى مقدميها، وإظهار التقدير اللازم الذي يستحقونه على غرار النجوم الممنوحة للمشاريع مثلًا. كانت هذه بعض الأفكار المستخلصة من نتائج الدراسة التي نأمل أن تكون ملهمة لكل المهتمين والمؤثرين في هذا المجال ليستفيدوا منها ويبنوا عليها المزيد لتحفيز المساهمين الجدد والمتمرسين لما فيه دعم عجلة تطور البرمجيات مفتوحة المصدر ودفعها قدمًا إلى الأمام. أما في الختام نذكركم برابط الورقة البحثية التي اعتمدنا عليها والتقرير الكامل عنها مع الحفاظ على الحقوق الفكرية لكافة المساهمين فيها. ترجمة -وبتصرف- للمقال ?What motivates open source software contributors لأصحابه Igor Steinmacher و Georg Link و Anita Sarma و Gregorio Robles و Bianca Trinkenreich و Christoph Treude و Marco Gerosa و Igor Wiese. اقرأ أيضًا ما المقصود بمصطلح مفتوح المصدر (open source)؟ تراخيص البرامج مفتوحة المصدر ما هي البرمجيات مفتوحة المصدر؟ صيانة المشاريع مفتوحة المصدر الفرق بين البرمجيات الحرة ومفتوحة المصدر

يشير مصطلح مفتوح المصدر (open source) لأي شيء يمكن لأي شخص تعديله ومشاركته لأن تصميمه متاح للجميع. نشأ هذا المصطلح في سياق تطوير البرمجيات للدلالة على نهج خاص لإنشاء برامج للحاسوب. أما اليوم، فإن مصطلح "مفتوح المصدر" يشير لمجموعة أوسع من القيم - والّتي نسميها "الثقافة مفتوحة المصدر. تتبنى المشاريع، أو المنتجات، أو المبادرات مفتوحة المصدر مبادئ التبادل المفتوح والمشاركة التعاونية والنماذج الأولية السريعة والشفافية العالية والجدارة والتنمية الموجهة للمجتمع. ما هي البرمجية مفتوحة المصدر؟ البرمجيات مفتوحة المصدر: هي برمجيات يمكننا رؤية شيفرتها البرمجية وفحصها وتعديلها وتحسينها. "الشيفرة البرمجية" هي جزء من برمجية لا يراه معظم مستخدمي الحاسوب على الإطلاق، ويتلاعب مبرمجو الحاسوب بالشيفرة لتغيير طريقة عمل البرمجية - سواءً أكانت "برنامج" أو "تطبيق". يمكن للمبرمجين الّذين يستطيعون الوصول للشيفرة البرمجية لبرنامج الحاسوب تحسين هذا البرنامج من خلال إضافة ميزات إليه أو إصلاح الأجزاء الّتي لا تعمل دائمًا عملًا صحيحًا. ما الفرق بين البرمجيات مفتوحة المصدر والأنواع أخرى؟ هناك بعض البرمجيات الّتي لا تُملكُ شيفرتها أو يمكن التعديل عليها سوى الجهة الّتي أنشأتها سواءً أكانت ممثلة بشخص أو فريق أو مؤسسة وتحتفظ هذه الجهة بالسيطرة الحصرية عليها. ويطلق الناس على هذا النوع من البرمجيات "بالبرمجيات المحتكرة" (proprietary) أو "مغلقة المصدر" (closed source). يمكن لأصحاب البرمجيات المحتكرة وحدهم نسخ هذه البرمجيات، وفحصها وتغييرها بطريقة قانونية. ولاستخدام البرمجيات المحتكرة لابد أن يوافق مستخدمي الحاسوب (للتوقيع على الترخيص المعروض والّذي يعرض عادةً عند التشغيل للمرة الأولى للبرمجيات) والّتي تنص على أنهم لن يفعلوا أي شيء للبرمجية مخالف صراحةً لما يسمح به منشئي هذه البرمجية. ومن هذه البرمجيات نذكر Microsoft Office وAdobe Photoshop. تختلف البرمجيات مفتوحة المصدر عن نظيرتها المحتكرة. إذ يتيح منشئي البرمجيات المفتوحة المصدر عرض الشيفرة البرمجية، ونسخها، والتعلم منها، وتغييرها، ومشاركتها أيضًا. ومن هذه البرمجيات نذكر محرر النصوص ليبر أوفيس LibreOffice وبرنامج التلاعب بالصور Gimp. وكما هو الحال مع البرمجيات المحتكرة يجب على المستخدمين عند استخدامهم البرمجيات مفتوحة المصدر الموافقة على شروط الترخيص بيدَ أن هذه الشروط تختلف اختلافًا كبيرًا عن شروط البرمجيات المحتكرة. تحدّد تراخيص البرمجيات مفتوحة المصدر طريقة استخدام البرمجيات، وتعديلها، وتوزيعها. وعمومًا تَمنحُ هذه التراخيص إذنًا باستخدام البرمجيات لأي غرض يرغب به المستخدم. إلا أن البعض الأخر من التراخيص والّتي يسميها البعض "الحقوق المتروكة" تنص على وجوب عرض الشيفرة البرمجية الخاصة لكلّ نُسخة مُعدلة من هذه البرمجية علنيًا. علاوة على ذلك بعض التراخيص تُوجبُ على أي شخص يعدلّ البرمجية ويشاركها مع الآخرين أن يشارك أيضًا المصدر الأصلي للشيفرة بدون فرض رسوم الترخيص عليها. تعمدُ تراخيص البرمجيات مفتوحة المصدر على تعزيز روح التعاون والمشاركة لأنها تسمح للجميع بإجراء تعديلات على الشيفرات البرمجية، ودمج هذه التغييرات في مشاريعهم الخاصة. وهم بذلك يشجعون مبرمجي الحاسوب بالوصول إلى البرمجيات مفتوحة المصدر وعرضها وتعديلها بأي وقت يحلو لهم، طالما أنهم سمحوا للآخرين بفعل نفس الشيئ عندما يشاركون برمجياتهم. هل البرمجيات مفتوحة المصدر مهمة لمبرمجي الحاسوب فقط؟ بالتأكيد لا. بل إن التكنولوجيا مفتوحة المصدر والعقلية المنفتحة للمصادر المفتوحة عمومًا تفيد كلًا من المبرمجين وغير المبرمجين. لأن المخترعين الأوائل للإنترنت شيدوا جزءًا كبيرًا منه على تقنياتٍ مفتوحة المصدر - مثل: نظام التشغيل Linux وتطبيق خادم الوِب المحلي Apache - وبذلك أي شخص يستخدم الانترنت فهو في الحقيقة يستفيد من البرمجيات مفتوحة المصدر. عند كلّ عملية استعراض لصفحة وِب أو التحقق من البريد الإلكتروني، أو الدردشة مع الأصدقاء، أو استخدام منصات البث الموسيقي عبر الإنترنت، أو اللعب بألعاب فيديو متعددة اللاعبين فإن حاسوب المستخدم، أو هاتفه المحمول، أو طرفيات الألعاب ستتصل بشبكة عالمية من الحواسيب من خلال برمجيات مفتوحة المصدر من أجل توجيه ونقل البيانات إلى أجهزتهم "المحلية" الموجودة أمام أعينهم. عادةً ما تتواجد هذه الحواسيب الّتي تؤدي كلّ هذا العمل الهام في أماكن بعيدة عن أنظار المستخدمين أو لا يستطيعون الوصول إليها فعليًا - وهذا هو السبب في أن بعض الأشخاص يطلقون على هذه الحواسيب "بالحواسيب البعيدة". يعتمد الناس أكثر فأكثر على الحواسيب البعيدة عند أداء مهامهم بدلًا من أجهزتهم المحلية. فمثلًا، قد يستخدمون برمجيات معالجة الكلمات وإدارة البريد الإلكتروني وتحرير الصور وهي غير مثبتة على حواسيبهم الشخصية. وإنما، ببساطة يصلون لها عبر الحواسيب البعيدة من خلال متصفح الوِب أو تطبيق على الهاتف محمول. وعندما يفعلون ذلك، فهم ينخرطون في "الحوسبة عن بُعد". يطلق بعض الأشخاص على الحوسبة عن بُعد "بالحوسبة السحابية" وذلك لأنها تتضمن أنشطة (مثل: تخزين الملفات أو مشاركة الصور أو مشاهدة مقاطع الفيديو) والّتي لا تتضمن حواسيب محلية فقط وإنما شبكة عالمية من الحواسيب البعيدة أيضًا الّتي تشكل سحابة. تتوالى أهمية الحوسبة السحابية يومًا بعد يوم وخصيصًا في الحياة اليومية للأجهزة المتصلة بالإنترنت. ومن بعض تطبيقات الحوسبة السحابية المحتكرة Google Apps. أما بعض التطبيقات الأخرى مفتوحة المصدر نذكر: ownCloud وNextcloud. تعمل تطبيقات الحوسبة السحابية "على قمة" من البرمجيات الإضافية المساعدة لها لتعمل بسلاسة وكفاءة، لذلك غالبًا ما سيقول الناس أن البرمجيات الّتي تعمل "تحت" تطبيقات الحوسبة السحابية تعمل بمثابة "منصة" لتطبيقات الحوسبة السحابية، وتكون هذه المنصات إما مفتوحة المصدر أو مغلقة المصدر. فمثلًا المنصة OpenStack هي منصة مفتوحة المصدر. لماذا يفضل الناس استخدام برمجيات مفتوحة المصدر؟ يفضل الناس البرمجيات مفتوحة المصدر على حساب البرمجيات المحتكرة لعدد من الأسباب: زيادة السيطرة على البرمجية يفضل كثير من الناس البرمجيات مفتوحة المصدر لأنها تعطيهم مزيدًا من السيطرة والتحكم. إذ يمكنهم فحص الشيفرة البرمجية للتأكد من أنها ستؤدي نفس المهمة الّتي يريدونها، بل ويمكنهم حتى تغيير أي جزء منها لا يحبونه. كما يستفيد غير المبرمجين من هذه البرمجيات أيضًا، لأنهم يمكنهم استخدام هذه البرمجية لأي غرض يرغبون فيه - وبذلك لا تُفرض عليهم الطريقة الّتي يعتقد شخص ما -صاحب البرمجية مثلًا- بأنه يجب عليهم استخدام البرمجية وفقًا لها (كما يحدث في البرمجيات المحتكرة). التعلم والتدرب من هذه البرمجيات يحبُ البعض الآخر من الناس هذه البرمجيات لأنها تساعدهم ليصبحوا مبرمجين أفضل. نظرًا لأن الشيفرة البرمجية متاحة للجميع، وبذلك يمكن للطلاب دراستها بسهولة أثناء تعلمهم لإنشاء برمجية أفضل. يمكن للطلاب مشاركة عملهم مع الآخرين أيضًا، ودعوتهم للتعليق والنقد البناء، وبذلك يصقل الطلاب مهاراتهم. عندما يكتشف الأشخاص أخطاءً في الشيفرات البرمجية لبرامجهم، يمكنهم مشاركة هذه الأخطاء مع الآخرين لمساعدتهم على تجنب ارتكاب نفس هذه الأخطاء. الحماية والأمان يُفضل بعض الأشخاص هذه البرمجيات لأنهم يرونها أكثر أمانًا واستقرارًا من البرمجيات المحتكرة. نظرًا من كون الجميع يستطيع عرض وتعديل البرمجيات مفتوحة المصدر، فيمكن لأي شخص أن يكتشف خطأ غفِلَ عنه أصحاب البرمجية أنفسهم بل ويمكن أن يصحح أو يحذف هذا الخطأ. ولأن العديد من المبرمجين يمكنهم العمل على جزء معين من البرمجية بدون طلب إذن من أصحابها، فسيُسرّع ذلك من وتيرة إصلاح البرمجية وتحديثها وترقيتها أكثر من البرمجيات المحتكرة. الاستقرار والثبات يفضل العديد من المستخدمين البرمجيات مفتوحة المصدر على نظيرتها المحتكرة للمشاريع المهمة وطويلة الأمد. نظرًا لتوزيع المبرمجين الشيفرة البرمجية علنًا للبرمجيات مفتوحة المصدر، فيمكن للمستخدمين الّذين يعتمدون على هذه البرمجيات في المهام الحرجة التأكد من أن أدواتهم لن تختفي أو تتعطل إذا توقف أصحابها عن تطويرها -وذلك لأن لديها عدة مبرمجين آخرين مهتمين بها- علاوة عن ذلك، تميل البرمجيات مفتوحة المصدر للاندماج والعمل وفقًا للمعايير المفتوحة. المجتمع الداعم للبرمجية غالبًا ما تستقطب البرمجيات مفتوحة المصدر جمهورًا من المستخدمين والمطورين المحبين لها. وهذا ليس حكرًا على هذه البرمجيات بل العديد من التطبيقات الشعبية لها مجتمعات كبيرة ومواضيع يناقشونها في لقاءاتهم واجتماعاتهم. غير أن في البرمجيات مفتوحة المصدر يكون المجتمع ليس مجرد قاعدة جماهيرية تشتري (سواء عاطفيًا بالدعم أو ماليًا بسعر البرمجية) وتكوّن بذلك مجموعة مميزة من المستخدمين وحسب، وإنما مجموعة من الأشخاص الّذين ينتجون ويختبرون ويستخدمون ويروجون بل ويؤثرون تأثيرًا جوهريًا على البرمجية الّتي يحبونها. هل يعني مصطلح "مفتوح المصدر" بأنه مجاني؟ لا. هذا مفهوم خاطئ ومنتشر حول ما يعنيه مصطلح "مفتوح المصدر"، وممكن ألا يتعلق هذا المصطلح بالمال. يمكن لمبرمجي هذه البرمجيات أن يتقاضوا المال مقابل البرمجيات مفتوحة المصدر الّتي يصنعونها أو يساهمون فيها. ولكن في بعض الحالات، نظرًا لأن ترخيص المصدر المفتوح يتطلب منهم إصدار الشيفرة البرمجية علنًا عندما يبيعون هذه البرمجيات للآخرين، ولذلك يجدُ بعض المبرمجين أن فرض رسوم على المستخدمين مقابل الخدمات والدعم الفني للبرمجية (بدلًا من البرمجية بحد ذاتها) أكثر ربحًا. وبهذا تظل برمجياتهم مجانية، ويكسبون المال من مساعدة الآخرين في تثبيتها واستخدامها واستكشاف أخطائها وإصلاحها. على الرغم من كون بعض البرمجيات مفتوحة المصدر مجانية، إلا أن مهارة البرمجة واستكشاف الأخطاء وإصلاحها في البرمجيات مفتوحة المصدر يمكن أن تكون ذات قيمة كبيرة. يسعى الكثير من أرباب العمل لتوظيف مبرمجين لديهم خبرة سابقة بالعمل على برمجيات مفتوحة المصدر تحديدًا. ما هي الثقافة مفتوحة المصدر "أي أبعد من الشيفرة البرمجية"؟ إن التعامل مع جميع جوانب الحياة بثقافة مفتوحة المصدر يعني التعبير عن الرغبة في المشاركة والتعاون مع الآخرين بشفافية (ليتمكن الآخرين من المشاهدة أو حتى الانضمام أيضًا)، واحتضان الفشل كوسيلة للتطوّر، وتوقع -أو حتى تشجيع- الجميع ليشاركوا وينضموا إلى هذه الثقافة. ويعني الالتزام أيضًا بدور فعّال في تحسين العالم، وهو أمر ممكن في حال تمكن الجميع من الوصول للطريقة الّتي صُمّم بها هذا العالم. إن العالم مليء "بالشيفرات البرمجية" - المخططات والوصفات والقواعد - الّتي توجه طريقة تفكيرنا وتشكلها من أجل أن نتصرف على أساسها. نؤمن تمامًا بأن هذه الشيفرة الضمنية (مهما كان شكلها) يجب أن تكون مفتوحةً وقابلة للوصول والمشاركة من قِبل الجميع — ليتمكنوا من تغييرها للأفضل. ترجمة -وبتصرف- للمقال What is open source software?‎

عندما تصون مستودعًا لمشروع مفتوح المصدر، فأنت تأخذ راية القائد، فلو كنتَ مؤسس أحد المشاريع التي أطلقتها للعموم ليستخدموها ويشاركوا فيها، أو كنت تعمل في فريقٍ وكنت تصون جانبًا من جوانب المشروع، فأنت تقدم خدمةً مهمةً إلى مجتمع التطوير. وعلى الرغم من أنَّ المساهمات في المشاريع مفتوحة المصدر تكون عادةً عبر طلبيات pull وهي أمرٌ بالغ الأهمية للحفاظ على جودة البرمجيات وفائدتها للمستخدمين النهائيين، لكن المساهمين في المشروع ليس لهم نفس تأثير من يقوم بصيانته ويبلور الشكل العام للمشروع؛ فالصائنون يشاركون في صلب تطوير المشاريع مفتوحة المصدر، إذ يديرون المشروع وينظموه يوميًا ويطوروه، ويتفاعلون مع المستخدمين ويوفرون المعلومات اللازمة للمساهمين. سنستعرض في هذا المقال بعض التلميحات عن صيانة المستودعات العامة للمشاريع مفتوحة المصدر. فالمسؤولون عن المشاريع مفتوحة المصدر عليهم مسؤوليات كبيرة تقنية وغير تقنية، والعمل كصائن للمشروع يعطي الفرصة للتعلم من الآخرين، وأخذ خبرة في إدارة المشاريع، ويسمح بمراقبة مراحل نمو المشروع وكيف أصبح المستخدمون العاديون مساهمين فعالين فيه. اكتب توثيقًا مفيدًا سيزيد التوثيق سهل الفهم (والذي سيؤدي إلى جعل البرنامج سهل الاستخدام) من قاعدة مستخدميك، ويساعد في تحويل المستخدمين إلى مساهمين في مشروعك. عندما تفكر بالشيفرات التي تكتبها أثناء تطويرك للمشروع، وتكتب بعض الملاحظات الجانبية لتساعدك في دمج مختلف أجزاء مشروعك مع بعضها بعضًا، فسيسهل عليك البدء بكتابة التوثيق أثناء عملية التطوير؛ أو ربما تقرر أن تكتب التوثيق قبل برمجة التطبيق، متبعًا بذلك منهجية «التطوير الموجه بالتوثيق» (documentation-driven development) التي تقول أنَّ عليك كتابة توثيق ميزات المشروع أولًا ثم برمجة تلك الميزات اعتمادًا على توثيقها. هنالك بضعة ملفات عليك وضعها في المجلد الرئيسي لمشروعك بجانب الشيفرات وهي: - ملف README.md الذي يوفر ملخصًا عن المشروع وأهدافه. - ملف CONTRIBUTING.md الذي يحتوي على تعليمات المساهمة في المشروع. - رخصة مشروعك، والتي ستشجِّع الناس على المساهمة في موقعك، أرجو أن تراجع مقالة كيف تختار رخصة مفتوحة المصدر لبرامجك. قد يأخذ التوثيق أشكالًا عدِّة، لذا عليك أن تضع نوعية المستخدمين المحتملين ومجال المشروع في الحسبان، فمن الممكن أن يأتي التوثيق بمختلف الأشكال ويكون موجهًا نحو فئات مختلفة من مستخدمي المشروع. قد تقرر استخدام شكل أو أكثر من الأشكال الآتية اعتمادًا على مجال عملك: دليل عام لتعريف المستخدمين بالمشروع الدروس التعليمية لعرض مختلف حالات الاستخدام الأسئلة الشائعة (FAQ) للإجابة عن أكثر التساؤلات شيوعًا بين المستخدمين مقالات عن استكشاف الأخطاء التي قد يواجهها المستخدمون وكيفية إصلاحها مرجع للواجهة البرمجية (API) للتطبيق تسمح للمستخدمين معرفة معلومات عن الواجهة البرمجية بسرعة ملاحظات الإصدار (release notes) التي تُذكَر فيها العلل المعروفة والتغييرات التي حدثت في كل إصدار الميزات المستقبلية لتتبع وشرح ما هي الميزات التي ستأتي في إصدارات مستقبلية. تسجيل مقطع فيديو لتعريف المستخدمين بمشروعك عبر الوسائط المتعددة. قد تلائم بعض أشكال التوثيق السابقة مشروعك أكثر من غيرها، لكن توفير أكثر من شكل للتوثيق سيساعد مستخدمي مشروعك أن يفهموا كيف يتفاعلون معك فهمًا أعمق. عليك عند كتابة التوثيق أو تسجيل مقطع فيديو أن تكون واضحًا قدر الإمكان، ومن الأفضل ألّا تكون عندك افتراضات مسبقة عن القدرات التقنية لمستخدمي مشروعك، ومن الأفضل أن تتبع منهجية Top-Down عند تأليف التوثيق، أي أن تشرح بداية الأمر ما الذي تفعله البرمجية بشكل عام (مثلًا: أتمتة أمور إدارة النظام، أو بناء موقع إلكتروني …إلخ.) قبل التعمق في التفاصيل. وصحيحٌ أنَّ اللغة الإنكليزية هي اللغة الرائدة في عالم التقنية، لكن أبقِ في ذهنك مَن هم المستخدمون المتوقعون وما هي لغتهم الأم؛ فاللغة الإنكليزية هي خيارٌ جيدٌ إذا كانت لديك قاعدة مستخدمين واسعة ومن مختلف البلدان، لكن ضع في بالك أنَّ عدد كبيرًا ممن سيقرؤون توثيقك لا تكون اللغة الإنكليزية هي لغتهم الأم، لذا حاول استخدام لغة سهلة لا تُسبِّب لبسًا عند القراء، وإذا كان مشروعك موجّه لمنطقة أو لغة معيّنة مثل برنامج للتعرف على الكلام العربي فأنصحك حينئذٍ أن توفر التوثيق باللغة العربية. حاول أن تكتب التوثيق كما لو كنتَ تكتب لأحد المساهمين الجدد الذين يريدون أن يطلعوا على حالة المشروع، فلا تنسَ أنَّك تريد أن يتحول المستخدمون العاديون إلى مساهمين. تنظيم «القضايا» القضايا (issues) هي طريقةٌ تستعمل لتتبع أو التبليغ عن العلل، أو لطلب ميزات جديدة لتضاف إلى البرنامج. توفِّر خدمات استضافة مستودعات المشاريع مفتوحة المصدر مثل GitHub و GitLab و Bitbucket طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها. فمن المتوقع عند إطلاق مشروعك مفتوح المصدر أن تُفتَح عدِّة قضايا من قِبل مجتمع المستخدمين، لذا سيمثِّل تنظيم ووضع أولويات لهذه القضايا أمرًا مهمًا لتبيان خارطة الطريق لما عليك فعله للمشروع مستقبلًا. ولأنَّ أي مستخدم يستطيع أن يفتح قضية، فلن تكون جميع القضايا لتبليغ العلل أو لطلب الميزات، فقد تأتيك أسئلة عبرها، أو قد تأتي طلبات لتحسينات صغيرة على واجهة المستخدم مثلًا. فمن الأفضل تنظيم هذه القضايا في أفضل شكل ممكن ومحاولة التواصل مع المستخدمين الذين أنشؤوها. يجب أن تمثِّل القضايا مهامًا محددة عليك تنفيذها برمجيًا، لذا عليك تنظيمها حسب أهميتها. يجب أن يكون هنالك حدود للوقت والعمل الذي تنفقه أنت أو المساهمون في المشروع للقضايا المفتوحة فيه، ويمكنكم التعاون على اتخاذ القرارات والخروج بخطة قابلة للتنفيذ، وعندما تعلم أنَّك غير قادر على حل مشكلة معيّنة في الإطار الزمني المتاح لك، فيمكنك التعليق عليها وإخبار المستخدم أنَّك قرأت المشكلة وستفعل ما بوسعك تجاهها، وقد تستطيع أن تخبره بالوقت المتوقع للنظر في أمر هذه المشكلة مرةً أخرى. أما لطلبات الميزات أو التحسينات، فيمكنك أن تسأل الشخص الذي أنشأ القضية إن كان يستطيع المساهمة في الشيفرة لتطبيق هذه الميزة، يمكنك توجيه المستخدمين إلى ملف CONTRIBUTORS.md أو إلى أيّة صفحات أخرى من التوثيق. ولأن الأسئلة لا تمثِّل عادةً مهامًا محدَّدة، فالتعليق على السؤال لتوجيه المستخدم بلباقة إلى صفحة التوثيق هو خيارٌ ممتاز لإبقاء تفاعلك مع المستخدم احترافيًا ولطيفًا؛ وإذا لم يحتوي التوثيق على جوابٍ لهذا السؤال فحان الوقت لإضافة التوثيق الملائم، وتعبِّر عن شكرك للمستخدم لأنه دلّك على موضع النقص في التوثيق. إذا كنتَ تستقبل عددًا كبيرًا من الأسئلة عبر القضايا، فربما تفكر بإنشاء صفحة الأسئلة الشائعة (FAQ) في التوثيق، أو صفحات ويكي أو منتدى لتتيح للآخرين المساعدة والمشاركة في الإجابة عن الأسئلة. وفي كل مرة يبلِّغ فيها أحد المستخدمين عن مشكلة، فحاول أن تكون لطيفًا معه قدر الإمكان، فتفاعل المستخدمين معك يعني أنَّ المشروع قد أعجبهم ويريدون جعله أفضل. محاولة تنظيم القضايا ستجعل مشروعك محدثًا دومًا وسيشعر المستخدمون أنهم يأثرون فيه، لذا احذف القضايا التي تقع خارج نطاق مشروعك أو القضايا القديمة، وضع أولويات للبقية لكي يكون تقدمك في المشروع مستمرًا. حفِّز المساهمين كلما رحّبتَ بالمساهمين الجدد وكافأتهم على جهودهم لوجدت أنَّك تحفِّز مساهمين جدد ليشاركوا في مشروعك، ولكي تجذب المساهمين إلى المشروع فاحرص على تضمين ملف CONTRIBUTING.md في المجلد الرئيسي لمستودعك، وإشارة إلى ذاك الملف في README.md. إذا أردتَ كتابة ملف جيد للمساهمين الجدد فيجب أن يتضمن كيفية بدء العمل على المشروع كمطوِّر، فقد تكتب دليلًا يوضح ذلك خطوةً بخطوة، أو قائمةً من الأمور التي يجب على المطورين اتباعها وتنفيذها، شارحًا كيف يمكن أن يدمجوا الشيفرة التي كتبوها بشيفرة المشروع عبر طلبية pull. إضافةً إلى توثيق كيفية المساهمة في المشروع، فلا تنسَ أن تبقي شيفرات المشروع منظمة وسهلة القراءة، فإذا كانت الشيفرة سهلة الفهم وفيها تعليقات كثيرة تشرح ما تفعله وطريقة استخدامها موحدة ومتناسقة مع بعضها بعضًا فسيساهم ذلك في تحفيز المساهمين المحتملين على المشاركة في المشروع. أقترح أيضًا أن تبقي على قائمة بالمساهمين، فيمكنك أن تجذب المساهمين عبر إضافتهم إلى القائمة بغض النظر عن حجم مشاركتهم (حتى تصحيح الأخطاء اللغوية هو مشاركة ومساهمة فعالة في المشروع، ويمكن أن تؤدي إلى مزيدٍ من المساهمات مستقبلًا). وهذا يعني أنَّك تقدِّر عمل المساهمين في المشروع وتشير إليهم أمام جميع مستخدمي مشروعك، مما يحمِّس بقية المستخدمين على المشاركة. ابنِ مجتمعًا حول مشروعك بتمكين مستخدميك عبر التوثيق وبالتجاوب مع القضايا وبتحفيزهم للمشاركة، فأنت في طريقك لبناء مجتمع حول مشروعك المفتوح المصدر، فالمستخدمون السعيدون بتجاوبك معهم والذين تعدُّهم على أنهم مساهمون سيحاولون الترويج مشروعك ما استطاعوا. إضافةً إلى ما سبق، يمكنك الترويج لمشروعك بمختلف السبل: التدوين تسجيل ونشر فيديوهات تعريفية إنشاء قائمة بريدية النشاط على مواقع التواصل الاجتماعي التعاون مع المشاريع الشبيهة أو المتعلقة بمشروعك والترويج لها. عليك أن تُناسِب ترويجك للمشروع مع مجاله وعدد أعضاء الفريق الفعالين والمساهمين الذين يعملون معك. فعندما ينمو المجتمع حول مشروعك، فيمكنك أن توفِّر مساحة أكبر للمساهمين والمستخدمين والقائمين على المشروع ليتفاعلوا، بعض تلك الخيارات تتضمن: برمجيات الويكي التي توفِّر توثيقًا مصانًا من المجتمع المنتديات لمناقشة الميزات المحتملة وللإجابة على الأسئلة قائمة بريدية للتفاعل مع المجتمع عبر البريد الإلكتروني ضع ببالك قاعدة مستخدمي مشروعك ومجاله بما في ذلك عدد الأشخاص القائمين عليه والموارد المتاحة لك قبل أن تتوسّع في المجالات السابقة، واستشر مجتمعك عن الخيار الأفضل قبل الإقدام عليه. وأهم من ذلك كله أن تكون لطيفًا معهم وتريهم أنَّك تهتم بهم عبر تفاعلك معهم، أعلمُ أنَّ الاتسام بصفة اللباقة طوال الوقت ليس أمرًا سهلًا، لكن ستؤتي أُكلها على المدى البعيد. الخلاصة يلعب صائن المستودع دورًا مهمًا في مجتمع البرمجيات مفتوحة المصدر الكبير. وصحيحٌ أنَّ هذا الدور يأخذ وقتًا وعملًا كبيرًا، لكن الخبرة التي تكتسبها خلال هذا العمل ستفيدك كمطوِّر وكمساهم، ولا تنسَ أنَّ الصائن اللطيف واللبق سيساعد في دفع عجلة تطوير المشروع الذي يهتم لأجله. ترجمة –وبتصرّف– للمقال Maintaining Open-Source Software Projects لصاحبته Lisa Tagliaferri. حقوق الصورة البارزة محفوظة لـ Freepik

ماذا يحدث إن أُجبرت على تطوير كل شفراتك البرمجية Codes المفضلة والسرية والمملوكة لك في مستودع Github عام؟ بالتأكيد ستُنتقَد؛ سينتقد أقرانك هذه الشفرات البرمجية، وسيضعون تعريفًا فضفاضًا “للشفرة البرمجية السليمة”يتضمن كل شيء بدءًا بالملف وتنظيم الأصناف والتوثيق والاختبارات وتجنب وضع مفاتيح واجهات التطبيقات البرمجية API في الشفرة وتقليص اعتمادك على ” أمن المعلومات عبر الغموض” وحتى الجودة الفنية التي لا يوجد معيار لها. سيفرض عليك التطوير علانية خلق شفرة جذابة وذات جودة عالية، وما يدفعك إلى ذلك هو رغبتك في إبهار الآخرين. لعل هذا شيء جيد، لكن ماذا عن عملك التجاري؟ هل انفضحت كل أسرارك، فازدادت قوة منافسيك وتظن نفسك انتهيت؟ بمعنى أنه إن كانت شفرتك مفتوحة المصدر، فلن تكون ذات ميزة تنافسية، لأن منافسيك يستطيعون أيضًا عملها، وبالتالي عليك أن تضيف ميزة تنافسية جديدة لعملك. على سبيل المثال، إن أظهرت شركة Esty خفاياها كاملة للعلن، هل يستطيع منافس أن يحل محلها؟ بالطبع لا، لأنهم قد صنعوا سوقًا، يكون فيه حضور المشترين والبائعين أصلًا أوليًّا من أصول الشركة. وهل سيتفوّق منافس على فيسبوك لأنها فتحت الآن مصادر البنية التحتية لمركز معلوماتها، ؟ بالطبع لا. قيمة هاتين الشركتين لا يمكن تملّكها بالمال، ولهذا السبب هما قيّمتان. قد تكون الميزة التنافسية التقنية ميزة دائمة في حالات نادرة، مثل جوجل (التي استمرت في الابتكار بسرعة عالية لدرجة أنه لم يسبقها أحد) أو لأي شخص يستطيع أخيرًا فك شفرة السيارات ذاتية القيادة. لكن هذه الحالات نادرة، فالمميزات التقنية متلاشية، لأن معظمها يمكن تقليده، بل عادة ما يكون التقليد أسرع وأرخص من المنتج الأصلي، وقد ثبت أن “الأسبق” ليس دائمًا “الأنجح” في السوق. لذلك، العمل علانية يدفعك إلى خلق ميزة تنافسية دائمة. ماذا عن الأسرار الشخصية بدلًا من التقنية؟ إن أعلنت عن مفردات راتب كل شخص في شركتك، لن تستطيع بعد ذلك المنافسة على الكفاءة على أساس التعويضات بمفردها. فإن لم تكن قادرًا على دفع زيادة 10 ألاف دولار في العام لنيل الموظف الكفء ذي الخبرة المناسبة، فسيدفعك هذا إلى بناء شركة حيث تريد الكفاءات العمل مع انخفاض الأجر. توجد العديد من الإرشادات التي توضح بناء بيئة مثل تلك، لكنها بوجه عام تتلخص في: الاستقلالية: أي حرية الاكتشاف، القدرة الكاملة على ابتكار حلول للمشاكل، والقدرة على برهنة هذه الحلول بالتنفيذ، مقابل تحمل مسؤولية النتائج) النمو: أي العمل على حل أحجيات ومشاكل شيقة، سواء شخصية أو مهنية، بالإضافة إلى تحقيق رحلة مهنية مُرضية، تنتقل من نجاح إلى نجاح، الهدف: أي لماذا يجب أن توجد هذه الشركة؟ لماذا تستحق بذل العناء لرؤيتها تنجح، بالإضافة إلى الثقافة، والقيم، ومتعة العمل مع الآخرين الذين تحبهم وتحترمهم. لذلك، العمل علانية يدفعك إلى خلق شركة ذات ثقافة استثنائية ومنظمة ذات تمكين وهدف. يعد كلٌّ من خلق ميزة تنافسية دائمة (بدون أسرار البرمجيات) وبناء ثقافة شركة تجذب وتستبقي الكفاءات المميزة لأسباب تتعدى الرشوة المالية مكونيْن حاسمين لخلق شركات تقنية مُعَمَّرة لا تعيق نموها ولا تمحو هويتها الشركات الناشئة ذات الفطنة والمال والمجتهدة في العملالتي ستظهر حتما في أي سوق كبيرة كفاية ليكون العمل فيها شيقًا. لذلك عند إظهار كل شيء علانية، فأنت مجبر على تقديم “الأكثر قيمة” بالإضافة إلى تقديم “ما لا يمكن تقليده” سواء كان هذا يعني إتقان صنعتك أو إخفاء سر عملك أو جذب الكفاءات. لا يزال من الممكن أن تعمل في السر، لكن ضوء الشمس ليس فقط المُطهِّر الأفضل، بل هو أفضل طريقة للتفوق في السوق. ترجمة – بتصرّف – للمقال Building in public forces true competitive advantage لصحابه Jason Cohen. حقوق الصورة البارزة محفوظة لـ Freepik

هل لدى مشروعك مجتمعٌ نشطٌ، لكن هنالك الكثير من العمل الذي لا يستطيع ذاك المجتمع تحمل عبئه؟ هذه آخر مقالة من سلسلة المقالات حول التسويق للمشاريع مفتوحة المصدر، وقد حان الوقت للتركيز حول كيفية تنمية المجتمع. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول مشروعك المفتوح المصدر أسهل طرق التعريف بمشروعك المفتوح المصدر كيفية تحويل مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر (هذا الدرس) السبب وراء تنمية المجتمع إن بدَأ مجتمعك بالنشوء بنجاح، لكنه لم ينمو كما كنتَ متوقعًا، فربما هنالك العديد من الأسباب المُمكنة لذلك، وعليك معرفتها ولتكن واقعيًا حولها. ستنتمي تلك المسببات إلى أحد هذين التصنيفين: الأشياء التي يمكنك فعل شيءٍ حيالها الأشياء خارج نطاق قدرتك هل أصبح متتبع العلل issue tracker لديك مزدحمًا بعد ازدياد عدد الأشخاص العاملين عليه؟ ألم يزدد وقت استجابتك لاستفسارات المساهمين الجدد لأنك تقضي وقتًا أطول لمناقشة الأمور مع الأشخاص الموجودين ضمن مجتمعك؟ هل تبقي التوثيق محدثًا دومًا؟ هل مضت سنتان منذ آخر مرة نشرتَ فيها تدوينةً حول المشروع؟ ليس من الصعب نسيان هذه الأمور الصغيرة عندما يصبح المجتمع الخاص بمشروعك كبيرًا ولا يتوقف عن الحركة والعمل ويتطلب منك اهتمامًا دائمًا. لكن نسيان تلك الأمور قد تسبب توقف نمو مشروعك في المستقبل؛ فكلما كبر مشروعك، كلما أصبح معقدًا بعمليات ونقاشات كثيرة يجب على القادمين الجدد أن يعتادوا عليها، مما يؤدي إلى تصعيب انضمام المساهمين من جديد. إن كانت المسببات من التصنيف الثاني، فهذا مُشكل كبيرٍ لك، خصيصًا للمشاريع الصغيرة، فقد لا يكون المجتمع كبيرًا ليحتوي عددًا كافيًا من المساهمين؛ فربما هنالك عشرة أشخاص في هذه الكوكب مهتمين بمشروعك وقادرين على المساهمة فيه، وخمسة منهم يساهمون فيه من قبل، وثلاثة لديهم عقود عمل تجعل من الصعب عليهم المساهمة في المشاريع، واثنين آخرين يفضلون قضاء وقت فراغهم مع أولادهم الصغار. يتطور عالم التقنية بوتيرة عالية، ألم تلاحظ عدم وجود نشاط كبير في مكتبة COBOL التي كتبتَها في السنوات القليلة الماضية؟ ربما تقوم بكل شيءٍ بشكلٍ صحيح، لكن الآخرين ينتقلون إلى أشياءٍ جديدة. فعندما بدأتَ كنتَ تستبدل تقنيات قديمة بهذه المكتبة الجديدة، وهذا ما يحدث اليوم لمكتبتك. الخيارٌ عائدٌ إليك إن كنتَ تريد متابعة العمل على ما هو قديم، أم "القفز" من السفينة كما يفعل الباقون. بعد أن شرحنا المشاكل المحتملة، سنعرض كيفية حلها. حسن باستمرار أمعن النظر بمدى سهولة الانضمام إلى المشروع للوافدين الجدد، وجرِّب سلوكياتٍ وتقنياتٍ مختلفة لترى أيها أصلح لك. يتطلب الحفاظ على مجتمعك وتوسعته جهدًا كبيرًا كما هو الحال عند بناءه، لكنك لست وحدك هذه المرة. اجعل بعض العادات الجيدة في إدارة المجتمع جزءًا من خطة سير العمل. هل سبب أحدهم مشكلة في الواجهة؟ عليهم أيضًا تحسين التوثيق. شجِّع الذين أضافوا ميزات كبيرة أن يكتبوا تدوينةً عنها؛ فهذا عملهم وعليهم أن يفخروا به. اشرح كل ما تفعله في سلسلة من التدوينات على صفحة مشروعك، كي يتطلع الآخرون إلى مساعدتك؛ شاور مجتمعك في أمور المشروع، واعطِ الأعضاء الموثوقين امتيازات وصول كاملة إلى المستودع؛ وبهذا ستصنع "آلة" ذات اكتفاءٍ ذاتي تستطيع أن تعمل دون استهلاك كامل طاقتك ووقتك الفارغ. اعرض مشروعك في أحد المؤتمرات هنالك الكثير من المؤتمرات التي تُركِّز على مختلف جوانب الحواسيب حول العالم. إن أردت أن يظهر مشروعك أمام العالم، فسجِّل كي تلقي كلمةً حوله في أحد المؤتمرات؛ وستتاح لك فرصٌ عديدةً إن لم يكن منتجك تجاريًا. يمكن أيضًا عرضه على الأشخاص الذين قد يرونه مفيدًا في اللقاءات والاجتماعات المحلية المختصة بتقنية المعلومات. أحد أكبر المؤتمرات هو FOSDEM في بروكسل، سجل مشروعك لمؤتمر السنة القادمة، حتى لو كنت ستتحدث عنه للتعريف به فقط (وليس لشرح تفاصيله). اعمل مع المطورين الأقل خبرة تتوجه معظم النصائح التي قدمناها في هذه السلسلة إلى الأشخاص الذين لديهم باع طويل في مجالاتهم، أي أنهم مطورون أولي خبرةٍ متوسطة إلى متقدمة، والذين يبرمجون لفترةٍ لا بأس بها. لكن المشكلة أن لديهم عملًا بدوامٍ كامل، وربما لديهم عائلة ومشاريع فرعية عليهم العمل عليها. خصص جزءًا من وقتك كي تسهل على المساهمين الأقل خبرةً أن يعملوا على مشروعك، وهذا يساعدك في كسب مجموعة كبيرة من الأناس المتحمسين الذين يودون الحصول على الخبرة بالعمل معك؛ وهذا يتضمن الطلاب، والأشخاص الذين يغيرون مهنتهم... إلخ. ضع بذهنك أنهم لن يبقوا قليلي الخبرة إلى الأبد، فقد تحصل على أعضاءٍ رائعين في مجتمعك في المستقبل إن أقمت علاقاتٍ بناءةٍ معهم. ادفع مالا للمساهمين لن يكون هذا الخيار واقعيًا للمشاريع التي يقوم عليها أشخاص، لكنه فعالٌ جدًا للشركات. إن استعملت مواقع مثل BountySource، فيمكنك تحديد سعر للميزات التي تريد إضافتها وربما يأتي أحدهم ويقبل عرضك. خيارٌ أخرٌ هو إنشاء مسابقات حيث يعمل فيها الآخرون على مشروعك لقاء مبلغٍ مالي أو شكل من أشكال التقدير الشخصي. تختار العديد من الشركات تمويل الأشخاص المهمين في المجتمع وتدفع راتب عملٍ بدوامٍ كامل لهم ليعملوا على المشروع. هذا مثالٌ ممتاز يبيّن كيف أنَّ العمل على المشاريع مفتوحة المصدر لا يعني أنَّه بالمجان. خاتمة فتح مصدر مشروعك هو بداية جيدة، لكن ستزداد المتعة عندما يبدأ الآخرون باستعماله والمشاركة فيه؛ وحتى ولو كان أغلبنا مبرمجون، فإننا نجد أنَّ المصدر المفتوح أشبه "بمؤسسة اجتماعية". هذه آخر مقالة من سلسلة "التسويق للمشاريع مفتوحة المصدر"، شكرًا لبقائك معنا حتى النهاية، أرجو أن تكون قد وجدتها مفيدةً :-) . ترجمة -وبتصرّف- للمقال Growing the community around your open-source project لصاحبه Radek Pazdera.

يجعل المساهمون من المشاريع مفتوحة المصدر مرحةً، فالسماح للآخرين باستعمال، وإعادة استعمال، وتحسين الشيفرات الخاصة بك وتحويلها إلى شيءٍ جديد لم تكن تتخيله، هو أمرٌ رائع؛ لكن -كغيره من الأمور في هذه الحياة- لن يتشكل المجتمع من العدم. ونحن نمر في هذه السلسلة من المقالات بعدة استراتيجيات لمساعدتك في بناء مجتمع حول مشروعك المفتوح المصدر؛ وركَّزت آخر ثلاث مقالات على جذب المستخدمين، وسنلقِ نظرةً هذه المرة على كيفية تحويلهم إلى مساهمين. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين (هذا الدرس) كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر وضح أن تطبيقك مفتوح المصدر إن جعلت تطبيقك سهل التثبيت بإنشاء مُثبِّت أو حزمة، فهنالك احتمالٌ كبيرٌ ألّا يفتح المستخدمون صفحة الهبوط أو المستودع؛ ولا بأس في ذلك في أغلبية الأوقات، لكن عليك أن تضع أنَّ تطبيقك مفتوح المصدر في مكان ما فيه لأولائك الذين يريدون التواصل ومعرفة المزيد من المعلومات حول تطبيقك. قد تستعمل خيارًا في سطر الأوامر، أو مربع حوار "حول" أو "About" إن كان لتطبيقك واجهةٌ رسوميةٌ؛ وضع رابطًا لصفحة الهبوط وربما لمتتبع العِلل الخاص بك (المكان الذي يُبلِّغ الناس فيه عن المشكلات التي تواجههم). ومن المحتمل أنَّ نكتةً في التطبيق ستدفع المستخدم إلى زيارة الرابط الموجود فيها. مكانٌ جيدٌ لتضع فيه طرق التواصل معك هو عبر رسائل الخطأ ومربعات الحوار التي تظهر عند انهيار التطبيق؛ أخبر فيها المستخدمين كيف يبلغون عن المشكلة، وهذه هي أكثر الطرق شيوعًا للمشاركة في تطوير المشاريع؛ حيث يحاولون فعل شيءٍ ما، لكنه لا يعمل وسيمدون يد العون في إصلاح المشكلة. المزايا المرتقبة إحدى طرق دفع الآخرين للمشاركة هي استعمال الميزات غير المكتملة؛ ربما تدمج الميزات التي تود إضافتها للتطبيق في المستقبل إلى واجهة المستخدم وتُظهِر رسالة تشرح أن هذه الميزة لم تتم، وتدعو الآخرين إلى مساعدتك في إكمال العمل عليها. قد تستعمل خيارًا إضافيًا في سطر الأوامر الذي يعرض رسالةً (بدلًا من الميزة المطلوبة)، ويمكن فعل المثل بمربعات الحوار في التطبيقات الرسومية. ضع ببالك أن هذا قد يصبح مزعجًا بشكل سريع؛ ولهذا عليك استعماله مع الميزات غير الأساسية في مشروعك؛ فلن يُسعَد مستخدموك إن نزَّلوا مكتبتك الجديدة عن الفرز (sort) ليجدوا أنَّ الفرز السريع (quick sort) ليس مُبرمجًا بعد. اكتب توثيقا منفصلا للمطورين يجب أن يكون لمشروعك توثيقٌ من نوعٌ ما للمطورين مع لمحة من مكان تواجد الأجزاء الرئيسية من البرنامج، ومرجع للواجهات البرمجية (APIs) يمكن البحث فيه. من الأفضل أن يتم توليد ذاك التوثيق من الشيفرات المصدرية بأدواتٍ مثل doxygen، أو JSDoc، أو YARD. يساعدك وجود التوثيق مع الشيفرات بتسهيل التعديلات البرمجية على المشروع. وهنالك مواقع مثل RubyDoc يسمح لك بتوليد واستضافة التوثيق مجانًا. لا يوجد أبسط من هذا! إن كتبت لمحة للمطورين عن المشروع وأبقيتها مختصرة ومحددة، فليس من المحتمل أن تحتاج إلى إعادة كتابتها بين الحين والآخر، إلا إن كنت تعيد هيكلة المشروع بأكمله. وضح ما الذي يجب فعله من المحتمل أن يتمحور تطوير تطبيقك حول مُتتبع العلل، فستأتي العلل وسيحاول المساهمون تتبعها وحلها، وفي حال استمرت هذه العملية، فسيمسي من السهل أن يتحول إلى كومة مربكة من الأشياء التي لن يستطيع أحد غيرك أنت وبعض أفراد فريق المساهمين فهم طريقة تنظيمها. لكن كيف سيتمكن المساهمون الجدد من البدء في العمل؟ حاول أن يكون متتبع العلل منظمًا بشكلٍ جيد وكأنك ستتجه غدًا إلى العمل مزارعًا في الحقل، ولن تدخل إلى الإنترنت بعد ذاك اليوم أبدًا، وسيأتي أحدهم ليكمل ما بدأتَه. أبقِ قائمةً بالمهام البسيطة والمحددة للمساهمين الجدد ليفعلوها عندما يأتون لأول مرة، حتى لو كنت تستطيع تنفيذها أنت بخمس دقائق، ربما يأخذ تفصيلُ شرحِ مشكلةٍ ما في متتبع العلل وقتًا لا بأس به، لكنه سيؤتي أكله إن ساعدتْ تلك العلة بتثبيت مساهم جديد في المشروع. كن متجاوبا عندما يحصل مشروعك على أول المستخدمين أو حتى أول المساهمين، فستبدأ باستقبال أسئلة، وطلبات للميزات، وتبليغات عن العلل وحتى سيصلك حلولٌ لتلك العلل؛ حاول أن تستجيب وتساعد الآخرين بمشاكلهم في إطار زمني محدد، حتى لو كنت مشغولًا وتقوم بتطوعك في وقت فراغك. فستؤدي استجابتك لطلبات pull requests بعد شهر إلى فقدان المساهمين لحماسهم. أجب حتى وإن لم تستطع إنجاز ما طُلِبَ مباشرةً، فمن الأفضل أن تقول "لا" وتضع الطلب في قائمة الأعمال غير المنجزة من أن تتركه معلقًا في الهواء أو أن تعد بشيءٍ لا تستطيع تلبيته. لكن بدلًا من ذلك، ضع الطلب في متتبع العلل لعل أحدهم ينجزه؛ هذا هو جمال البرمجيات مفتوحة المصدر. أصبح مساهما إن كنت حديث العهد بهذا العالم المُربك من البرمجيات الحرة والمفتوحة المصدر، أو ربما كان مشروعك خارج "البيئة" التي نشأت بها واستخدمتها من قبل، فجرب المساهمة في مشاريع مشابهة وانظر إن كان من السهل البدء من التوثيق الذي كتبوه، وأين بدأت تواجه مشاكل معه. هل أجاب أحدهم عن تساؤلك أو قَبِلَ الرقعة (patch) التي أرسلتها؟ استخدم خبرتك من هذه التجربة لتقديم مشروعك بأفضل صورة ممكنة لتسهل انضمام المساهمين الجدد. ما التالي؟ لقد أرسيتَ أساسات مشروعك، وأعداد مستخدميه والمساهمين فيه تزداد باطراد، فما الخطوة الآتية؟ هذا ما سيكون موضوع آخر المقالات في هذه السلسلة. ترجمة -وبتصرّف- للمقال Turning users into contributors لصاحبه Radek Pazdera.

هل سبق وأن نشرتَ مشروعًا مفتوح المصدر ولم تشاهد حشدًا كبيرًا من الناس آتين لتنزيله بالآلاف، مما يعطل الخواديم في أول ليلة بعد إصداره؟ حسنًا، لا تتشكل أغلبية المجتمعات (communities) بين ليلةٍ وضحاها؛ وأصبح من الصعب جذب المساهمين -بوجود العدد الكبير من المشاريع المتوفرة في أيامنا هذه- دون القيام ببعض التسويق. لكن أغلبنا -معشرَ المبرمجين- لسنا معتادين على التسويق أو مرتاحين بفعله؛ وبذلك ستبقى الشيفرات التي نكتبها تقبع مهجورةً بالمستودعات ولا يأبه أحدٌ بأمرها، فما الحل؟ هذه السلسلة من المقالات ستأخذنا برحلةٍ عبر عددٍ من الأمور التي عليك فعلها كي تساعد باكتشاف مشروعك ولتُسهِّل على الآخرين الاشتراك به. هذا الدرس هو القسم الأول من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. الجمهور المستهدف وصفحة الهبوط (هذا الدرس) كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر يبدأ المجتمع بالمستخدمين السؤال الذي يبدأ الأشخاص بسؤاله عادةً هو "كيف أتمكن من جعل الآخرين يساهمون في مشروعي؟" وهذا السؤال -في غالب الأحيان- سابقٌ لأوانه. فقبل التفكير بالمساهمين، عليك التفكير بالمستخدمين. فدون أن يكون لديك قاعدة مستخدمين كبيرة (نسبيًا)، سيكون من الصعب جذب أيّة مساهمين على الإطلاق. فهل تساهم أنت في مشاريع لم تستعملها قط؟ ربما لا، وكذلك سيفعل البقية. سأفترض أنك أنشأت مشروعك ليحل مشكلةً واجَهتك من قبل، وربما تواجه الكثيرين غيرك، كل ما عليك فعله هو أن تجدهم. اكتشف من هم جمهورك المستهدف تعتبر أصغر المشاريع "منتجاتٍ"، فهي تحل مشكلة أو تلبي حاجة ما؛ فما هي المشكلة التي يحلها مشروعك؟ ومَن الذي سيراه مفيدًا؟ سيساعدك التفكير بهذين السؤالين على توجيه جهودك والتركيز على من يهتمون دون أن "تزعج" من لا يأبهون بمشروعك بتاتًا. هل أنشأت إضافةً لمحرر vim (محرر سطري مشهور جدًا على الأنظمة الشبيهة بيونكس)؟ ربما أنت تبحث عن الأشخاص الذين يستعملون vim، وقد لا يكون وضع تلك الإضافة في "emacs subreddit" أفضل شيءٍ تفعله. ابحث عن أولائك الأشخاص وتواصل معهم وانضم إليهم، تنجذب مجموعات من ذوي الاهتمامات المتشابهة نحو أماكن معينة أو قنوات اتصال مخصصة، وربما لديهم اجتماعات محلية أو subredits خاصة بهم. بينما مثالنا عن vim السابق بسيط، لكن الأمر ليس بهذا الوضوح خصيصًا بجمهورٍ شغوفٍ ومتحمسٍ كالمبرمجين، فيمكن أن توقع نفسك بنقاشاتٍ محتدمة (يسميها معشر المبرمجين بالمصطلح "flame wars")، وفي بعض الأحيان لا يكتفون بتجاهلك وإنما سينالون من هيبة مشروعك؛ فاستهداف الأشخاص الصحيحين يعني أيضًا أنك لن تزعج أولاءك الذين لا يشاركونك رأيك. إعداد صفحة هبوط (Landing page) قبل إخبار الناس عن مشروعك، عليك أن تهيّء مكانًا لترسلهم إليه يحتوي كل ما يحتاجونه للبدء باستعمال مشروعك؛ وهذا المكان قد يكون ملف README على Github، أو تدوينة، أو موقع مخصص لذلك. يجب على تلك الصفحة أن تلخص ماذا يفعل مشروعك، ومن أين ستحصل عليه، وكيف تجعله يعمل، وقد تنتهي (اختياريًا) بمرجع مُبسَّط وسريع حول المهام أو المشاكل الشائعة؛ فعليك تبيان الحدود القصوى لمشروعك، لكن لا تعرضها في البداية، بل ركز على ما يبرع تطبيقك بفعله ودع تلك الحالات لتكتبها في التوثيق. إن كان يعطي تطبيقك مخرجاتٍ مرئيةً من أي نوع، أو كانت له واجهةٌ رسومية، فلا تنسَ أن تضيف لقطاتٍ للشاشة، وإن لم تكن مخرجاته مرئيةً، لا بأس من أخذ لقطات للطرفية (مكان إظهار نواتج الأوامر) أو عمل صور متحركة (gifs) لها؛ ضع بعين الاعتبار أنَّ الناس سيفهمون تطبيقك أسرع "بمشاهدته" أكثر من مجرد القراءة عنه. في النهاية، يجب أن توفر صفحة الهبوط طرقًا للتواصل معك أو للمجتمع المحيط بالمشروع ليحصلوا على الدعم؛ جهّز قائمةً بريديةً، أو قناة IRC، أو غرفة على Gitter ووفرها لهم؛ أما للمشاريع الصغيرة، فقد يكفي وضع بريدك الإلكتروني. عليك أن تراعي عادات الفئة المستهدفة، فلن يُسعَد ثلةٌ من خبراء أمن المعلومات بالتسكع في مجموعتك على فيس بوك. عليك بعد أن تجهز صفحتك أن تنشرها في مختلف أماكن تواجد المبرمجين مثل موقع Hacker News و r/programming (على reddit)؛ لكن جهودك تلك ليست موجهة لفئة معيّنة، وتعتمد على الحظ كثيرًا؛ سأتحدث عن طرقٍ أفضل لنشر مشرعك في مقالاتٍ قادمة من هذه السلسلة، ابقَ معنا! عندما تصل إلى مرحلة إنشاء الصفحة، تذكر أنَّه لا يهم شكلها بقدر أهمية محتواها؛ وفي الواقع، عليك أن تقضي وقتًا أطول بالتفكير بمحتواها أكثر من بقية الأمور. هل أنت مطور واجهات محترف يتمكن من تصميم موقع مصمم تصميمًا رائعًا في ساعتين؟ هذا جميل اذهب وصمم أجمل ما تستطيع، لكن لا تنفق ثلاثة أشهر وأنت تضيع وقتك على كم يجب أن تكون قيمة الهامش لعناوين الصفحة مثلا فالأمر لا يستحق كل ذلك العناء. ملف README على GitHub سيكون كافيًا عادةً. ما التالي؟ سنتحدث في المقالة القادمة عن جعل مشروعك أكثر قابليةً للوصول للمستخدمين. فالأسوأ من عدم القدرة على فهم ما الذي يفعله المشروع هو تضييع ثلاث ساعات لمحاولة جعله يعمل! ترجمة -وبتصرّف- للمقال Marketing for open-source projects لصاحبه Radek Pazdera.

أصبحت المشاريع مفتوحة المصدر شيئًا عظيمًا؛ لكن بالتزايد الكبير لأعداد المشاريع مفتوحة المصدر، ازدادت صعوبة جذب المساهمين. وتدعم الشركات الكبرى -مثل فيسبوك و تويتر- عددًا كبيرًا من تلك المشاريع، مما جعل الجميع يتنافس لنيل مساهمات المُبرمجين ولفت انتباههم. هذا ثاني درس في هذه السلسلة من المقالات التي سترشدك إلى كيفية بناء مجتمع حول مشروعك. الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل (هذا الدرس) طرق التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر تحدث الدرس السابق عن الفئة المستهدفة وكيف تُقدِّم مشروعك إليهم؛ وفي هذه المرة سننظر إلى جعل الوصول إليه سهلًا. عندما يرى المستخدم أنَّ مشروعك يفي باحتياجاته، فسيبحث عن تعليمات حول كيفية استعماله وطريقة عمله؛ ومن المفيد لك أن تجعل عملية التثبيت أسهل ما يمكن لتجنب خسارة الأشخاص على الطريق، وهذه هي طريقة فعل ذلك: ابن حزمة يأتي المشروع الاعتيادي مع مجموعة من الخطوات لبناءه وتثبيته، لكن من الأفضل اختصار تلك المجموعة إلى خطوة وحيدة: تثبيت حزمة. هل ستجرب مشروعًا يحتاج تثبيته إلى أمر sudo apt-get install وحيد، أم ستجرب مشروعًا يحتاج إلى إعداد بيئة لبناء البرامج، وتثبيت عدد هائل من الاعتماديات، ثم البناء من المصدر؟ حزم التوزيعات أول خيار أمامك هو إنشاء حزمة خاصة بنظام التشغيل، ربما لتوزيعة لينُكس (حزم deb، أو rpm، أو pacman) أو لنظام OS X باستعمال Homebrew. أو تستطيع إنشاء حزمة على مستوى اللغة البرمجية (language-level) إن كان هذا الخيار متوفرًا للتقنية التي بنيت مشروعك بها. الحزم الموجودة في مستودعات التوزيعات هي أكثر الحلول راحةً للمستخدم، سامحةً لهم بتثبيت البرمجيات التي تُوفرها من مصدرٍ موثوق. عملية تعلم إضافة حزمة مشروعك إلى المستودعات هي عمليةٌ مرهقةٌ وصعبة وعليك المرور على عشرات الصفحات من التوثيق حتى تُقبَل حزمتك في المستودعات؛ لكن ذلك العمل سيؤتي أُكله، فسيصبح تثبيت مشروعك يتطلب تنفيذ أمرٍ وحيدٍ من المستخدم؛ وذلك يستحق كل هذا الجهد لوجود الملايين من مستخدمي نفس نظام التشغيل. الحزم على مستوى اللغة أو يمكنك إنشاء حزمة على مستوى اللغة البرمجية -إن كان هذا الخيار متوفرًا للتقنية التي تستعملها- مثل PyPI، و Rubygems، و npm وغيرها. وإنشاء تلك الحزم أبسط، وتُخَلِّصُكَ من قراءة عشرات الصفحات من التوثيق التي عليك المرور بها كي تُقبَل حزمتك في مستودعات توزيعةٍ ما. وقد تكون هذه الطريقة أفضل بناءً على فئتك المستهدفة. إنشاء حزمة على مستوى اللغة هي ضرورة مُلِحَّة للمشاريع التي ستُستعمَل من بقية المطورين مثل المكتبات. فلمطوري روبي أو JS، لن تكون مكتبةٌ ما خيارهم المفضَّل إن لم يكن لديها حزمة gem أو npm. سينتشر مشروعك أكثر عندما تضعه في تلك المستودعات، إذ سيظهر عندما يبحث المبرمجون في تلك المستودعات عن المكتبات المفيدة. ربما يكون هنالك -في بعض الأحيان- أدوات أو خوارزميات لتحويل حزمة على مستوى اللغة إلى حزمة نظام، وبهذا تستطيع أخذ حزمة مشروعك على مستوى اللغة وإعادة استعمالها في توزيعاتٍ عدِّة؛ فيتمكن Debhelper -مثلًا- من بناء تطبيق بايثون تلقائيًا إن كان يأتي مع ملف setup.py. سكربت إعداد تلقائي إن لم تسطع توفير حزمة لمشروعك، فعليك -على الأقل- أن توفِّر سكربت لبناء وتثبيت البرمجية. وهذا السكربت قد يمثل بديلًا للحزمة لأنه يوفر طريقةً سهلةً للتثبيت. هذه بعض المشاريع الأخرى الشهيرة التي تستعمل سكربتات الإعداد: oh-my-zsh rvm لا يثق بعض الأشخاص في تلك السكربتات، وهم على حق في بعض الأوقات. أنت سيد قرارك هنا، فليس لديك أداة إدارة حزم موثوقة لتضمن أمان الحزمة. كن حذرًا جدًا وتأكد أن ما تضعه في السكربت لن يضر بأنظمة المستخدمين أو بياناتهم؛ خصيصًا عندما تفعل أشياءً تتطلب امتيازات الجذر (root – أي الامتيازات الإدارية)؛ لن يساعدك خسارة عدد كبير من الأشخاص لبياناتهم بسبب تطبيقك في حملتك التسويقية له. اكتب دليلا لاستعمال تطبيقك تمكن الآن المستخدمون من تثبيت مشروعك بسهولة، وعليك الآن أن تريهم طريقة استعماله. حان الوقت الآن لكتابة دليل المستخدم؛ وليس من الضرورة أن يكون هذا الدليل طويلًا ومفصلًا؛ فيجب أن يشرح الواجهة الأساسية، ويشير إلى أيّة حدود للتطبيق. لا تكتب كثيرًا من المعلومات التقنية وركِّز على ما يحتاج المستخدم الاعتيادي إلى معرفته. لا تجاهد لكي يكون الدليل مفصلًا وكاملًا من البداية؛ ابدأ من أهم النقاط ثم أكمل الباقي أثناء تطويرك للمشروعك، وستستفيد من أسئلة المستخدمين الجدد الذين يحاولون استعمال مشروعك في كتابة محتوى الدليل. أفضل بنية وأدوات لكتابة الدليل تعتمد على طبيعة وحجم مشروعك، وعمّا إذا كنت تولِّد الدليل من الشيفرة المصدرية أم كنت تكتبه بنفسك بأكمله يدويًا. يجب أن يَسهُل البحث في الدليل النهائي (حتى لو وضعت كل المعلومات في صفحة وحيدة واستعملت خاصية البحث في المتصفح). لا تنس الرخصة خطأٌ شائعٌ يقلل كثيرًا من استعمال مشروعك هو عدم وجود رخصة مفتوحة المصدر؛ تأكد أن شيفراتك تأتي مع رخصة معترف بها من FSF أو OSI؛ راجع الدرس كيف تختار رخصة مفتوحة المصدر لبرامجك لمزيدٍ من المعلومات حول هذا الصدد. ما التالي؟ أصبح مشروعك الآن جاهزًا للاستعمال من المستخدمين، فحان الوقت لنشره، وهذا هو موضوع المقالة القادمة. ترجمة -وبتصرّف- للمقال Make your open-source project accessible لصاحبه Radek Pazdera.