المحتوى عن 'المصدر المفتوح'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 5 نتائج

  1. يجعل المساهمون من المشاريع مفتوحة المصدر مرحةً، فالسماح للآخرين باستعمال، وإعادة استعمال، وتحسين الشيفرات الخاصة بك وتحويلها إلى شيءٍ جديد لم تكن تتخيله، هو أمرٌ رائع؛ لكن -كغيره من الأمور في هذه الحياة- لن يتشكل المجتمع من العدم. ونحن نمر في هذه السلسلة من المقالات بعدة استراتيجيات لمساعدتك في بناء مجتمع حول مشروعك المفتوح المصدر؛ وركَّزت آخر ثلاث مقالات على جذب المستخدمين، وسنلقِ نظرةً هذه المرة على كيفية تحويلهم إلى مساهمين. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين (هذا الدرس) كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر وضح أن تطبيقك مفتوح المصدر إن جعلت تطبيقك سهل التثبيت بإنشاء مُثبِّت أو حزمة، فهنالك احتمالٌ كبيرٌ ألّا يفتح المستخدمون صفحة الهبوط أو المستودع؛ ولا بأس في ذلك في أغلبية الأوقات، لكن عليك أن تضع أنَّ تطبيقك مفتوح المصدر في مكان ما فيه لأولائك الذين يريدون التواصل ومعرفة المزيد من المعلومات حول تطبيقك. قد تستعمل خيارًا في سطر الأوامر، أو مربع حوار "حول" أو "About" إن كان لتطبيقك واجهةٌ رسوميةٌ؛ وضع رابطًا لصفحة الهبوط وربما لمتتبع العِلل الخاص بك (المكان الذي يُبلِّغ الناس فيه عن المشكلات التي تواجههم). ومن المحتمل أنَّ نكتةً في التطبيق ستدفع المستخدم إلى زيارة الرابط الموجود فيها. مكانٌ جيدٌ لتضع فيه طرق التواصل معك هو عبر رسائل الخطأ ومربعات الحوار التي تظهر عند انهيار التطبيق؛ أخبر فيها المستخدمين كيف يبلغون عن المشكلة، وهذه هي أكثر الطرق شيوعًا للمشاركة في تطوير المشاريع؛ حيث يحاولون فعل شيءٍ ما، لكنه لا يعمل وسيمدون يد العون في إصلاح المشكلة. المزايا المرتقبة إحدى طرق دفع الآخرين للمشاركة هي استعمال الميزات غير المكتملة؛ ربما تدمج الميزات التي تود إضافتها للتطبيق في المستقبل إلى واجهة المستخدم وتُظهِر رسالة تشرح أن هذه الميزة لم تتم، وتدعو الآخرين إلى مساعدتك في إكمال العمل عليها. قد تستعمل خيارًا إضافيًا في سطر الأوامر الذي يعرض رسالةً (بدلًا من الميزة المطلوبة)، ويمكن فعل المثل بمربعات الحوار في التطبيقات الرسومية. ضع ببالك أن هذا قد يصبح مزعجًا بشكل سريع؛ ولهذا عليك استعماله مع الميزات غير الأساسية في مشروعك؛ فلن يُسعَد مستخدموك إن نزَّلوا مكتبتك الجديدة عن الفرز (sort) ليجدوا أنَّ الفرز السريع (quick sort) ليس مُبرمجًا بعد. اكتب توثيقا منفصلا للمطورين يجب أن يكون لمشروعك توثيقٌ من نوعٌ ما للمطورين مع لمحة من مكان تواجد الأجزاء الرئيسية من البرنامج، ومرجع للواجهات البرمجية (APIs) يمكن البحث فيه. من الأفضل أن يتم توليد ذاك التوثيق من الشيفرات المصدرية بأدواتٍ مثل doxygen، أو JSDoc، أو YARD. يساعدك وجود التوثيق مع الشيفرات بتسهيل التعديلات البرمجية على المشروع. وهنالك مواقع مثل RubyDoc يسمح لك بتوليد واستضافة التوثيق مجانًا. لا يوجد أبسط من هذا! إن كتبت لمحة للمطورين عن المشروع وأبقيتها مختصرة ومحددة، فليس من المحتمل أن تحتاج إلى إعادة كتابتها بين الحين والآخر، إلا إن كنت تعيد هيكلة المشروع بأكمله. وضح ما الذي يجب فعله من المحتمل أن يتمحور تطوير تطبيقك حول مُتتبع العلل، فستأتي العلل وسيحاول المساهمون تتبعها وحلها، وفي حال استمرت هذه العملية، فسيمسي من السهل أن يتحول إلى كومة مربكة من الأشياء التي لن يستطيع أحد غيرك أنت وبعض أفراد فريق المساهمين فهم طريقة تنظيمها. لكن كيف سيتمكن المساهمون الجدد من البدء في العمل؟ حاول أن يكون متتبع العلل منظمًا بشكلٍ جيد وكأنك ستتجه غدًا إلى العمل مزارعًا في الحقل، ولن تدخل إلى الإنترنت بعد ذاك اليوم أبدًا، وسيأتي أحدهم ليكمل ما بدأتَه. أبقِ قائمةً بالمهام البسيطة والمحددة للمساهمين الجدد ليفعلوها عندما يأتون لأول مرة، حتى لو كنت تستطيع تنفيذها أنت بخمس دقائق، ربما يأخذ تفصيلُ شرحِ مشكلةٍ ما في متتبع العلل وقتًا لا بأس به، لكنه سيؤتي أكله إن ساعدتْ تلك العلة بتثبيت مساهم جديد في المشروع. كن متجاوبا عندما يحصل مشروعك على أول المستخدمين أو حتى أول المساهمين، فستبدأ باستقبال أسئلة، وطلبات للميزات، وتبليغات عن العلل وحتى سيصلك حلولٌ لتلك العلل؛ حاول أن تستجيب وتساعد الآخرين بمشاكلهم في إطار زمني محدد، حتى لو كنت مشغولًا وتقوم بتطوعك في وقت فراغك. فستؤدي استجابتك لطلبات pull requests بعد شهر إلى فقدان المساهمين لحماسهم. أجب حتى وإن لم تستطع إنجاز ما طُلِبَ مباشرةً، فمن الأفضل أن تقول "لا" وتضع الطلب في قائمة الأعمال غير المنجزة من أن تتركه معلقًا في الهواء أو أن تعد بشيءٍ لا تستطيع تلبيته. لكن بدلًا من ذلك، ضع الطلب في متتبع العلل لعل أحدهم ينجزه؛ هذا هو جمال البرمجيات مفتوحة المصدر. أصبح مساهما إن كنت حديث العهد بهذا العالم المُربك من البرمجيات الحرة والمفتوحة المصدر، أو ربما كان مشروعك خارج "البيئة" التي نشأت بها واستخدمتها من قبل، فجرب المساهمة في مشاريع مشابهة وانظر إن كان من السهل البدء من التوثيق الذي كتبوه، وأين بدأت تواجه مشاكل معه. هل أجاب أحدهم عن تساؤلك أو قَبِلَ الرقعة (patch) التي أرسلتها؟ استخدم خبرتك من هذه التجربة لتقديم مشروعك بأفضل صورة ممكنة لتسهل انضمام المساهمين الجدد. ما التالي؟ لقد أرسيتَ أساسات مشروعك، وأعداد مستخدميه والمساهمين فيه تزداد باطراد، فما الخطوة الآتية؟ هذا ما سيكون موضوع آخر المقالات في هذه السلسلة. ترجمة -وبتصرّف- للمقال Turning users into contributors لصاحبه Radek Pazdera.
  2. حتى لو لم تكن تطلب من الأشخاص مالًا لقاء استعمالهم لتطبيقك، لكن ما يزال علينا التسويق قليلًا له قبل أن يسطع نجمه. كيف إذًا سيعلم الآخرون عنه؟! الناس مشغولون هذه الأيام التي أصبحت فيها المشاريع مفتوحة المصدر لا تُعد ولا تحصى، وأصبحت المنافسة قوية جدًا على المساهمين في المشاريع. عرفنا -في آخر مقالين من هذه السلسلة- الجمهور الهدف لمشرعنا ثم تأكدنا أنه متاحٌ -وبسهولة- لمن شاء أن يستعمله؛ هذا الدرس هو القسم الثالث من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. أقسام هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر (هذا الدرس) كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر الفكرة بسيطةٌ للغاية: عليك أن تعرض المشروع على الأشخاص المناسبين في الوقت الملائم (عندما يحتاجون إلى التعرف على مشروعك)؛ كل برنامج له وظائف معيّنة تجعله مفيدًا لمجموعة بسيطة من المستخدمين. لا ترسل رسائل عشوائية لأكبر عدد تستطيعه من الأشخاص؛ لكن وجِّه جهودك إلى المجتمعات التي ستستفيد من المعرفة عن مشروعك. لنقل أنَّك برمجت إطار عملٍ مثل ExpressJS، عمومًا ستكون جهودك موجهة نحو الأشخاص الذين يطورون مواقع الويب؛ وربما تود أن تستهدف أولاءك الذين "يفكرون" في صنع موقع إلكتروني لكن لم يبدؤوا بعد، أما البقية فسيقولون "هذا رائع!" لكنهم سيواصلون استعمال Sinatra أو Flask لأن الشيفرات التي كتبوها تعتمد عليها. حل المشكلات وهذا ما يبرع المبرمجون بفعله. لِمَ لا تستعمل ذلك لصالحك؟ لقد أنشأت مشروعك لحل مشكلة واجهتك ومن المحتمل أنَّ الآخرين يحاولون حل نفس المشكلة. أنشِئ محتوى حول المشاكل التي يحلها مشروعك، وما الذي يفعله بشكلٍ جيد. وهذا يعني أنَّ عليك كتابة مقالات، أو صنع مقاطع فيديو، أو تسجيل بودكاست، أو حتى إلقاء محاضرات أو التعليم في دورات تدريبية، أيها تُفضِّل. لكن النص يبقى هو الأفضل لأنه دائم وقابل للبحث. يمكنك نشر تلك المواد في عددٍ من الأماكن، مثل مدونتك الشخصية أو أن تنشر منشورًا على مدونة خاصة بالمجتمع التقني الذي ينتمي إليه مشروعك. ثم شارك ذاك المقال مع مَن تظن أنهم سيجدونه مفيدًا. وهذا يتضمن منتديات النقاش، والمجموعات البريدية، وقنوات Gitter، و Reddit أو Hacker News. تأكد أنَّ ذاك المجتمع سيرحب بذلك (بعض الأقسام الفرعية من Reddit [يسمونها subreddits]) لا تسمح بنشر روابط)، وكن حذرًا جدًا بالتعامل مع القوائم البريدية، فراعي أنَّ رسالتك ستصل إلى البريد الوارد لكثيرٍ من الأشخاص. إن كانت هنالك العديد من قنوات التواصل لجمهورك المستهدف، فلا تُرسِل الرسائل إليها جميعًا، اختر قناتين أو أكثر منهم فقط، وإن أُعجِبَ الجمهور بمشروعك فسيتنشر تلقائيًا. اجعل تواتر نشرك للمقالات في حدود المعقول وعدِّلها بناءً على ردة فعل القراء، فإن أعجبتهم، فذاك أمرٌ حسن، وأتبعها أخرى في الأسبوع القادم؛ وإن لم يكونوا متحمسين، فحاول شيئًا جديدًا في المرة القادمة، وستكون الردود على مشروعك أفضل إن كنت تشارك في المجتمع مشاركةً فعالةً (بجانب مشاركتك لدعايتك إلى مشروعك). الإجابة عن الأسئلة إن كان مشروعك يحل مشكلة مخصصة جدًا، فربما من المفيد أن تراقب المواقع التي يسأل الناس فيها عادةً عنها، مثل StackOverflow أو Reddit، وأن تساعدهم في الأمر. وعندما تُجيب، حاول دائمًا أن تسهب في الموضوع قليلًا لإعطاء مجال لتشرح كيف يعمل حلّك للمشكلة، ولا بأس أن تُعدِّد الخيارات الأخرى المتاحة. ربما ذلك يستهلك وقتًا أكثر من إعطاء مجموعة روابط، لكن ربما تستفيد من سؤالك بتحويله إلى تدوينة لاحقًا. تلك المواقع هي مولدات أفكار رائعة؛ فإن أردت أن تعرف ما هي المشاكل التي يعاني منها الناس، فألقِ نظرةً على الأسئلة التي يسألونها. العمل مع الآخرين لا يتواجد مشروعك في الفراغ، وإنما بُنِيَ باستعمال بعض المكتبات الأخرى، وهنالك أشياءٌ أخرى يمكن أن تُدمَج أو تتعاون معه. أخبر الناس كيف يستطيعون استعمال مكتباتك وأرهم كيف يدمجون مشروعك مع الأدوات الأخرى. قدِّم ما لديك لأعضاء المجتمعات التي تلتف حول تلك المشاريع، وسينظرون إليها إن وجدوها مفيدةً؛ وعلى الرغم من أنك تعتمد على شعبية مشروع قائم، إلا أنك تساهم في نشره في نفس الوقت. وما لم يثر المحتوى الذي تقدم جدلًا، فلا يوجد سببٌ يمنع أصحاب تلك المشاريع من الترحيب لكتابتك عن مشاريعهم، وربما يشاركون ما كتبتَ أيضًا: "رائع! أحدهم أنشأت روبوتًا باستخدام مكتبتي". كن لطيفا لا تقلل من شأن عمل غيرك لكي تعلي من شأن عملك. ربما تظن أن مشروعك هو الأفضل، صحيح؟ هذا لأنك من أنشأه وقد يكون هذا صحيحًا، ولا بأس من عمل مقارنات، لكن لا تقل أشياءً مثل "على عكس مكتبة RottenWatermelon JS، هذا الإطار يحتوي على sane API" أو "اضطررت على مر السنين أن أتعامل مع الخردة المسماة ‎OMG++‎، لكنني أتيت اليوم لأفتح مصدر اللغة Gobbledygook: لغة البرمجة للقرن الحادي والعشرين". قد يلفت الجدار النظر إليك، لكنه لن يُنشِئ بيئةً صحية وودودةً لكي ينمو بها المجتمع المحيط بمشروعك؛ تذكر أنه في خمس سنين سيصبح مشروعك تقنيةً قديمةً جدًا ولن يستعملها أحد. ما التالي؟ أصبح مشروعك موجودًا وأصبح يحصل على أول مستخدميه؛ عليك الاستمرار في جهودك وسيؤتي عملك أُكله، سننظر في المقالة التالية كيف نحول المستخدمين إلى مساهمين. ترجمة -وبتصرّف- للمقال Spreading the word about your open-source project لصاحبه Radek Pazdera.
  3. هل سبق وأن نشرتَ مشروعًا مفتوح المصدر ولم تشاهد حشدًا كبيرًا من الناس آتين لتنزيله بالآلاف، مما يعطل الخواديم في أول ليلة بعد إصداره؟ حسنًا، لا تتشكل أغلبية المجتمعات (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.
  4. أصبحت المشاريع مفتوحة المصدر شيئًا عظيمًا؛ لكن بالتزايد الكبير لأعداد المشاريع مفتوحة المصدر، ازدادت صعوبة جذب المساهمين. وتدعم الشركات الكبرى -مثل فيسبوك و تويتر- عددًا كبيرًا من تلك المشاريع، مما جعل الجميع يتنافس لنيل مساهمات المُبرمجين ولفت انتباههم. هذا ثاني درس في هذه السلسلة من المقالات التي سترشدك إلى كيفية بناء مجتمع حول مشروعك. الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل (هذا الدرس) طرق التعريف بمشروعك مفتوح المصدر كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر تحدث الدرس السابق عن الفئة المستهدفة وكيف تُقدِّم مشروعك إليهم؛ وفي هذه المرة سننظر إلى جعل الوصول إليه سهلًا. عندما يرى المستخدم أنَّ مشروعك يفي باحتياجاته، فسيبحث عن تعليمات حول كيفية استعماله وطريقة عمله؛ ومن المفيد لك أن تجعل عملية التثبيت أسهل ما يمكن لتجنب خسارة الأشخاص على الطريق، وهذه هي طريقة فعل ذلك: ابن حزمة يأتي المشروع الاعتيادي مع مجموعة من الخطوات لبناءه وتثبيته، لكن من الأفضل اختصار تلك المجموعة إلى خطوة وحيدة: تثبيت حزمة. هل ستجرب مشروعًا يحتاج تثبيته إلى أمر 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.
  5. هل لدى مشروعك مجتمعٌ نشطٌ، لكن هنالك الكثير من العمل الذي لا يستطيع ذاك المجتمع تحمل عبئه؟ هذه آخر مقالة من سلسلة المقالات حول التسويق للمشاريع مفتوحة المصدر، وقد حان الوقت للتركيز حول كيفية تنمية المجتمع. الدروس السابقة في هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول مشروعك المفتوح المصدر أسهل طرق التعريف بمشروعك المفتوح المصدر كيفية تحويل مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر (هذا الدرس) السبب وراء تنمية المجتمع إن بدَأ مجتمعك بالنشوء بنجاح، لكنه لم ينمو كما كنتَ متوقعًا، فربما هنالك العديد من الأسباب المُمكنة لذلك، وعليك معرفتها ولتكن واقعيًا حولها. ستنتمي تلك المسببات إلى أحد هذين التصنيفين: الأشياء التي يمكنك فعل شيءٍ حيالها الأشياء خارج نطاق قدرتك هل أصبح متتبع العلل issue tracker لديك مزدحمًا بعد ازدياد عدد الأشخاص العاملين عليه؟ ألم يزدد وقت استجابتك لاستفسارات المساهمين الجدد لأنك تقضي وقتًا أطول لمناقشة الأمور مع الأشخاص الموجودين ضمن مجتمعك؟ هل تبقي التوثيق محدثًا دومًا؟ هل مضت سنتان منذ آخر مرة نشرتَ فيها تدوينةً حول المشروع؟ ليس من الصعب نسيان هذه الأمور الصغيرة عندما يصبح المجتمع الخاص بمشروعك كبيرًا ولا يتوقف عن الحركة والعمل ويتطلب منك اهتمامًا دائمًا. لكن نسيان تلك الأمور قد تسبب توقف نمو مشروعك في المستقبل؛ فكلما كبر مشروعك، كلما أصبح معقدًا بعمليات ونقاشات كثيرة يجب على القادمين الجدد أن يعتادوا عليها، مما يؤدي إلى تصعيب انضمام المساهمين من جديد. إن كانت المسببات من التصنيف الثاني، فهذا مُشكل كبيرٍ لك، خصيصًا للمشاريع الصغيرة، فقد لا يكون المجتمع كبيرًا ليحتوي عددًا كافيًا من المساهمين؛ فربما هنالك عشرة أشخاص في هذه الكوكب مهتمين بمشروعك وقادرين على المساهمة فيه، وخمسة منهم يساهمون فيه من قبل، وثلاثة لديهم عقود عمل تجعل من الصعب عليهم المساهمة في المشاريع، واثنين آخرين يفضلون قضاء وقت فراغهم مع أولادهم الصغار. يتطور عالم التقنية بوتيرة عالية، ألم تلاحظ عدم وجود نشاط كبير في مكتبة COBOL التي كتبتَها في السنوات القليلة الماضية؟ ربما تقوم بكل شيءٍ بشكلٍ صحيح، لكن الآخرين ينتقلون إلى أشياءٍ جديدة. فعندما بدأتَ كنتَ تستبدل تقنيات قديمة بهذه المكتبة الجديدة، وهذا ما يحدث اليوم لمكتبتك. الخيارٌ عائدٌ إليك إن كنتَ تريد متابعة العمل على ما هو قديم، أم "القفز" من السفينة كما يفعل الباقون. بعد أن شرحنا المشاكل المحتملة، سنعرض كيفية حلها. حسن باستمرار أمعن النظر بمدى سهولة الانضمام إلى المشروع للوافدين الجدد، وجرِّب سلوكياتٍ وتقنياتٍ مختلفة لترى أيها أصلح لك. يتطلب الحفاظ على مجتمعك وتوسعته جهدًا كبيرًا كما هو الحال عند بناءه، لكنك لست وحدك هذه المرة. اجعل بعض العادات الجيدة في إدارة المجتمع جزءًا من خطة سير العمل. هل سبب أحدهم مشكلة في الواجهة؟ عليهم أيضًا تحسين التوثيق. شجِّع الذين أضافوا ميزات كبيرة أن يكتبوا تدوينةً عنها؛ فهذا عملهم وعليهم أن يفخروا به. اشرح كل ما تفعله في سلسلة من التدوينات على صفحة مشروعك، كي يتطلع الآخرون إلى مساعدتك؛ شاور مجتمعك في أمور المشروع، واعطِ الأعضاء الموثوقين امتيازات وصول كاملة إلى المستودع؛ وبهذا ستصنع "آلة" ذات اكتفاءٍ ذاتي تستطيع أن تعمل دون استهلاك كامل طاقتك ووقتك الفارغ. اعرض مشروعك في أحد المؤتمرات هنالك الكثير من المؤتمرات التي تُركِّز على مختلف جوانب الحواسيب حول العالم. إن أردت أن يظهر مشروعك أمام العالم، فسجِّل كي تلقي كلمةً حوله في أحد المؤتمرات؛ وستتاح لك فرصٌ عديدةً إن لم يكن منتجك تجاريًا. يمكن أيضًا عرضه على الأشخاص الذين قد يرونه مفيدًا في اللقاءات والاجتماعات المحلية المختصة بتقنية المعلومات. أحد أكبر المؤتمرات هو FOSDEM في بروكسل، سجل مشروعك لمؤتمر السنة القادمة، حتى لو كنت ستتحدث عنه للتعريف به فقط (وليس لشرح تفاصيله). اعمل مع المطورين الأقل خبرة تتوجه معظم النصائح التي قدمناها في هذه السلسلة إلى الأشخاص الذين لديهم باع طويل في مجالاتهم، أي أنهم مطورون أولي خبرةٍ متوسطة إلى متقدمة، والذين يبرمجون لفترةٍ لا بأس بها. لكن المشكلة أن لديهم عملًا بدوامٍ كامل، وربما لديهم عائلة ومشاريع فرعية عليهم العمل عليها. خصص جزءًا من وقتك كي تسهل على المساهمين الأقل خبرةً أن يعملوا على مشروعك، وهذا يساعدك في كسب مجموعة كبيرة من الأناس المتحمسين الذين يودون الحصول على الخبرة بالعمل معك؛ وهذا يتضمن الطلاب، والأشخاص الذين يغيرون مهنتهم... إلخ. ضع بذهنك أنهم لن يبقوا قليلي الخبرة إلى الأبد، فقد تحصل على أعضاءٍ رائعين في مجتمعك في المستقبل إن أقمت علاقاتٍ بناءةٍ معهم. ادفع مالا للمساهمين لن يكون هذا الخيار واقعيًا للمشاريع التي يقوم عليها أشخاص، لكنه فعالٌ جدًا للشركات. إن استعملت مواقع مثل BountySource، فيمكنك تحديد سعر للميزات التي تريد إضافتها وربما يأتي أحدهم ويقبل عرضك. خيارٌ أخرٌ هو إنشاء مسابقات حيث يعمل فيها الآخرون على مشروعك لقاء مبلغٍ مالي أو شكل من أشكال التقدير الشخصي. تختار العديد من الشركات تمويل الأشخاص المهمين في المجتمع وتدفع راتب عملٍ بدوامٍ كامل لهم ليعملوا على المشروع. هذا مثالٌ ممتاز يبيّن كيف أنَّ العمل على المشاريع مفتوحة المصدر لا يعني أنَّه بالمجان. خاتمة فتح مصدر مشروعك هو بداية جيدة، لكن ستزداد المتعة عندما يبدأ الآخرون باستعماله والمشاركة فيه؛ وحتى ولو كان أغلبنا مبرمجون، فإننا نجد أنَّ المصدر المفتوح أشبه "بمؤسسة اجتماعية". هذه آخر مقالة من سلسلة "التسويق للمشاريع مفتوحة المصدر"، شكرًا لبقائك معنا حتى النهاية، أرجو أن تكون قد وجدتها مفيدةً :-) . ترجمة -وبتصرّف- للمقال Growing the community around your open-source project لصاحبه Radek Pazdera.