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

هل سبق وأن نشرتَ مشروعًا مفتوح المصدر ولم تشاهد حشدًا كبيرًا من الناس آتين لتنزيله بالآلاف، مما يعطل الخواديم في أول ليلة بعد إصداره؟ حسنًا، لا تتشكل أغلبية المجتمعات (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.