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

تظهر لنا الإحصاءات أن أكثر من 80٪ من تطبيقات الويب ومواقع الويب مدعومة بخوادم الويب مفتوحة المصدر. في هذه المقالة، سألقي نظرة على خوادم الويب المفتوحة المصدر الأكثر شعبية، وأراجع تاريخها وتقنياتها وميزاتها وغير ذلك. وسوف أقدم أيضًا بعض النصائح حتى تتمكن من النشر بسهولة على واحد من خوادم الويب هذه بنفسك. وفقًا لويكيبيديا ، فإن خادوم الويب هو "نظام حاسوبي يعمل على معالجة الطلبات عبر بروتوكول HTTP، وهو بروتوكول الشبكة الأساسي المستخدم لتوزيع المعلومات على الشبكة العالمية، ويمكن أن يشير المصطلح إلى النظام بأكمله، أو تحديدًا إلى البرنامج الذي يشرف على الطلبات" ، في هذه المقالة سنتعامل مع البرامج التي تعالج طلبات الويب من المستخدمين النهائيين. Apache HTTP تم إطلاق خادوم Apache HTTP - والذي غالبا ما يشار إليه باسم httpd أو Apache- في عام 1995، واحتُفل بعيد ميلاده العشرين في فبراير 2015. يشغل Apache 52٪ من جميع المواقع على مستوى العالم، وهو خادوم الويب الأكثر شعبية في العالم. يغلب أن يكون Apache مشغلا على لينكس ، ولكن يمكنك أيضا تشغيله على OS X و ويندوز. ليس غريبا أن Apacheمرخص بموجب رخصة Apache الإصدار 2. وهو يستخدم معمارية الوحدات، والتي يمكن بها إضافة وحدات جديدة لتمديد عمل الخادوم وزيادة ميزات أخرى . على سبيل المثال سيؤدي تحميل الوحدة mod_proxy إلى السماح للبروكسي على الخادوم الخاص بك، وسيعمل mod_proxy_balancer على تمكين موازنة التحميل لجميع البروتوكولات المدعومة. اعتبارا من الإصدار 2.4 صار Apache يدعم HTTP/2 من خلال الوحدة الجديدةmod_http2. وبما أن خادوم Apache HTTP هو خادوم الويب الأكثر شعبية منذ عام 1996، فإنه "يستفيد من الوثائق الكبيرة والدعم المتكامل من مشاريع البرامج الأخرى ." يمكنك العثور على مزيد من المعلومات حول Apache في صفحة مشروع. NGINX بدأ Igor Sysoev تطوير NGINX مرة أخرى في عام 2002. وقد طوّر NGINX جوابًا على ما يسمى مشكلة C10K ، وهو اختصار لــ "كيف يمكنك تصميم خادوم الويب الذي يمكنه التعامل مع عشرة آلاف اتصال متزامن ؟ " . NGINX يحل هذا المشكل وهو الثاني على قائمة خوادم الويب المفتوحة المصدر حسب الاستخدام، فهو يشغل ما يزيد عن 30٪ من المواقع. يعتمد NGINX على معمارية الأحداث الموجهة (event-driven) غير المتزامنة ، وذلك ما يساعده في تحقيق هدفه ، ألا وهو التعامل مع أكبر عدد ممكن من الاتصالات ، وبسبب ذلك أصبح خادوم الويب الأكثر شعبية جدًا بين مديري الأنظمة بسبب استخدامه لموارد خفيفة وقدرته على التوسع بسهولة. يتم إصدار NGINX تحت رخصة BSD-like ، ولا يقتصر استخدامه على خدمة الويب فحسب، بل أيضًا كخادوم وكيل proxy أو موازن التحميل load-balancer ، يمكنك العثور على مزيد من المعلومات حول NGINX في موقع المجتمع. Apache Tomcat Apache Tomcat هو حاوية جافا (اسمها الكامل Java servlet) مفتوح المصدر. وهو برنامج جافا بقدرات ملقمات الويب، على الرغم من أن servlet يمكن أن تستجيب لأي أنواع من الطلبات، فإنها استخدامها شائع فقط في تنفيذ التطبيقات المستضافة على خوادم الويب. servlet هي نظير تقنيات الويب الديناميكية الأخرى مثل PHP و ASP.NET، تم التبرع بالشيفرة المصدرية لــ Apache Tomcat من قبل شركة Sun Microsystems إلى مؤسسة Apache للبرمجيات في عام 1999، وأصبحت مشروع Apache الأعلى قيمة في عام 2005. وهي حاليًا تحتل 1٪ فقط من جميع المواقع. يستخدم Apache Tomcat -والذي يصدر تحت رخصة Apache الإصدار 2- عادة لتشغيل تطبيقات الجافا . ومع ذلك، فإنه يمكن تمديده بـ Coyote لأداء دور خادوم الويب العادي لكي يخدم الملفات المحلية كوثائق HTTP ، يمكنك الإطلاع على مزيد من المعلومات على موقع المشروع. غالبًا ما يتم ذكر Apache Tomcat مع خوادم تطبيقات الجافا المفتوحة المصدر الأخرى. مثل JBoss و Wildfly و Glassfish Node.js Node.js هي بيئة جافا سكريبت من جانب الخادوم ، وهي تعمل لتشغيل تطبيقات الشبكة، لا تحتل Node.js إلا مكانة منخفضة في السوق ، فنسبة تشغيلها لا تتجاوز 0.2٪ من المواقع . طور هذه البيئة في الأصل Ryan Dahl في عام 2009 ، وتسيرها الآن مؤسسة Node.js وبمساعدة مؤسسة لينكس. الفرق بين Node.js وغيرها من خوادم الويب الشعبية الأخرى هو أنها بيئة تشغيل عابرة للمنصات لتشغيل تطبيقات الشبكة، تطبّق Node.js معمارية الأحداث الموجهة event-driven القادرة على الإدخال والإخراج غير المتزامن. هذه الخيارات في التصميم هي الأمثل إنتاجية وقابلية للتوسع في تطبيقات الويب مما يسمح بتشغيل الاتصالات وألعاب المتصفح في الوقت الحقيقي، يظهر الفرق أيضًا في أن Node.js هو في الحقيقة جزء من مراحل تطوير الويب (HTML, CSS, and JavaScript)، على عكس Apache أو NGINX التي هي جزء من العديد من البرامج المختلفة. يتم إصدار Node.js تحت مزيج من التراخيص . يمكن الحصول على مزيد من المعلومات على الموقع الإلكتروني للمشروع . Lighttpd أطلق Lighttpd في أول إصدار له في مارس 2003. وهو حاليًا يشغل 0.1٪ من المواقع ويتم توزيعه تحت رخصة BSD. يميز Lighttpd أنه يعمل بموارد أقل مقارنة بالخوادم الأخرى (من حيث الذاكرة ، والمعالج) وهذا يجعله أسرع أداء واستجابة ، وهو يستخدم معمارية الأحداث الموجهة event-driven architecture ، ويعتبر الخيار الأمثل في حال كثرة الاتصالات المتزامنة وموارد أقل من العتاد، يدعم Lighttpd الكثير من التقنيات مثل : FastCGI, SCGI, Auth, Output-compression, URL-rewriting. كثيرًا ما يستعمل Lighttpd مع إطار العمل Ruby on Rails وإطار العمل Catalyst. لمزيد من المعلومات حوله قم بزيارة الصفحة الرئيسية للمشروع . نصائح إذا كنت ترغب أن تجرب واحدا من خوادم الويب الأكثر شعبية فأنا أوصي بشدة بتحميل التجميعية LAMP (Linux, Apache, MySQL, PHP) أو التجميعية LEMP (Linux, NGINX, MySQL, PHP) ، هناك الكثير من هذه التجميعيات المتاحة التي توفير نكهات مختلفة ، وعادة ما يتم توفيرها كمثبتات بنقرة واحدة، أو متوفرة كحزمة في مدير برامجك على لينوكس. بعد الانتهاء بنجاح من عملية التثبيت يمكنك بدء تشغيل خادوم الويب الخاص بك، ومحاولة إخراج المثال المشهور مرحبا بالعالم . انها طريقة رائعة للبدء في اكتشاف مداخل ومخارج خادوم الويب الخاص بك، وكيف تعمل خوادم الويب في الحياة التقنية الحقيقية. ترجمة -وبتصرّف- للمقال Top 5 open source web servers لصاحبه Robin Muilwijk حقوق الصورة البارزة محفوظة لـ Freepik

حتى لو لم تكن تطلب من الأشخاص مالًا لقاء استعمالهم لتطبيقك، لكن ما يزال علينا التسويق قليلًا له قبل أن يسطع نجمه. كيف إذًا سيعلم الآخرون عنه؟! الناس مشغولون هذه الأيام التي أصبحت فيها المشاريع مفتوحة المصدر لا تُعد ولا تحصى، وأصبحت المنافسة قوية جدًا على المساهمين في المشاريع. عرفنا -في آخر مقالين من هذه السلسلة- الجمهور الهدف لمشرعنا ثم تأكدنا أنه متاحٌ -وبسهولة- لمن شاء أن يستعمله؛ هذا الدرس هو القسم الثالث من سلسلة التسويق للمشاريع مفتوحة المصدر وسيركِّز على كيفية التعريف بمشروعك. أقسام هذه السلسلة: الجمهور المستهدف وصفحة الهبوط كيف تجعل الوصول إلى مشروعك مفتوح المصدر أسهل طرق التعريف بمشروعك مفتوح المصدر (هذا الدرس) كيف تحول مستخدمي مشروعك مفتوح المصدر إلى مساهمين كيف تنمي المجتمع الخاص بمشروعك مفتوح المصدر الفكرة بسيطةٌ للغاية: عليك أن تعرض المشروع على الأشخاص المناسبين في الوقت الملائم (عندما يحتاجون إلى التعرف على مشروعك)؛ كل برنامج له وظائف معيّنة تجعله مفيدًا لمجموعة بسيطة من المستخدمين. لا ترسل رسائل عشوائية لأكبر عدد تستطيعه من الأشخاص؛ لكن وجِّه جهودك إلى المجتمعات التي ستستفيد من المعرفة عن مشروعك. لنقل أنَّك برمجت إطار عملٍ مثل 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.

ما الذي يجعل مشروعك مفتوح المصدر؟ أن تكون الشّيفرة متوفرةً مجانًا على الإنترنت؟ أو أن تستطيع استعماله، أو تعديله وإرساله إلى صديقك؟ إذا ابتغينا الدقة، فإن الرخصة هي التي تعطيك الامتيازات لفعل كل ما سبق ذكره. فعندما "تفتح" مصدر مشروعك، فعليك أن تُضمِّن ملف رخصة يُحدِّد ما هي الشروط التي سيُسمَح للآخرين باستعمال مشروعك وفقًا لها. لحسن الحظ، هنالك خياراتٌ عديدةٌ يمكنك الاختيار بينها، فلا حاجة إلى أن تكون محاميًا لفعل ذلك؛ لكن لسوء الحظ هنالك الكثير من الرخص، مما يجعلك تحتار أيهم ستختار. تنبيه: هذه هي طريقة ترخيص مشاريعي الخاصة، لكنني لست محاميًا وهذه المقالة لا تُمثِّل نصيحة قانونية. ما هي الرخص؟ عدد الرخص التي يمكن اعتبارها "حرة" (free) أو مفتوحة المصدر (open-source) بالمئات! إذا كنت تريد قوائم طويلة، فراجع القوائم الموجودة على موقع مشروع GNU و opensoucre.org أو على ويكيبيديا، وحتى تلك القوائم الطويلة ليست شاملة لجميع الرخص. وعلى الرغم من التعداد الكبير للرخص، لكن الفروقات بينها ليست محورية؛ والسبب وراء وجود عدد كبير منها هو أنَّ كاتبيها صعيبو المراس في اختيار الكلمات وبعض التفاصيل، لكن يمكن اعتبار شروط الكثير منها متماثلة. ادخل إلى موقع tl;drLegal لمراجعة سريعة لشروط مختلف الرخص. الرخص المتساهلة و Copyleft أكبر أمر يُفرِّق بين الرخص هو Copyleft، وهو مصطلحٌ أوجده مشروع غنو (GNU) لمنع الأشخاص الذين سيعيدون توزيع البرمجيات في المستقبل من تقييد الحريات التي أعطيتَها للمشروع عند إطلاقه، وهذا يعني أنَّه على أيّ شخصٍ يريد أن يُعيد توزيع نسخةٍ مُعدَّلةٍ من الشيفرة التي كتبتَها أن ينشر تعديلاته أيضًا. تُطبِّق بعض الرخص ذاك المبدأ (مثل GPL، و LGPL، وMPL) بينما لا تُطبقه الأخرى (مثل MIT، و Apache، و BSD). قد تكون رخص "copyleft" مفيدةً جدًا لمنع إساءة استعمال مشروعك، وقد تكون في بعض الأحيان معيقةً لاستعماله من الشركات التي قد لا تقدر على استعمال شيفرات مرخصة بتلك الرخصة في برمجياتها التجارية. مجال مشروعك أحد أهم الأشياء التي يجب أخذها بعين الاعتبار عند اختيار رخصة لمشروعك هو "المجال"؛ هل هو مكتبة برمجية، أم أداة للمطورين، أم تطبيق كامل للمستخدم النهائي؟ إذا كان سيُستعمَل مع مكتباتٍ أخرى، فعليك أن تكون حذرًا في اختيارك للرخصة بسبب مشاكل في التوافقية بين الرخص (سنشرح ذلك بعد قليل). أختارُ للتطبيقات الكاملة أو المنتجات، مثل تطبيقات الأندرويد أو تطبيقات سطح المكتب أو الأدوات التي تعمل من سطر الأوامر، رخصًا من نمط copyleft مثل GPLv3 التي تطمئنني أنَّ المشروع سيبقى مفتوح المصدر دومًا. وعندما تُطلِقُ مكتبة أو إطار عمل ليستعمله المطورون في مشاريعهم، فإن اختيارك سيصبح أكثر صعوبةً. فعدم السماح لهم بتوزيع برمجياتهم التي تعتمد على مكتبتك دون التضمين الكود المصدري قد يمنع الشركات من استعمالها في مشاريعهم، مما يمنع انتشارها انتشارًا واسعًا. شخصيًا، أستعمل رخصًا متساهلة في هذه الحالة، مثل MIT أو BSD؛ وبينما تترك تلك الرخص احتمال أن تشتق الشركات مصدر المشروع الخاص بك، وتطوره ولا تعطيك التعديلات عليه، لكن ذلك غير عملي أو منطقي لكثيرٍ من الشركات؛ لأن الاختلاف من مصدر الشيفرة الأصلي سيجعلهم يتحملون عبء تكاليف الصيانة التي تتجاوز عادةً قيمة التّعديل الذي أجروه على شيفرة مشروعك. رخصة LGPL ليست خيارًا سيئًا أيضًا، إذ تسمح للآخرين باستعمال نسخة مُصرَّفة (compiled) من المكتبة مع شيفراتهم المملوكة (proprietary أو الاحتكارية)، وفي نفس الوقت ستحافظ على حقوق مصدر المكتبة. المشاكل في التوافقية تحتوي بعض الرخص بنودًا تتعارض مع غيرها من الرخص؛ مما يجعلها غير متوافقة، مما يعني أنك لا تستطيع أن تدمج بين حزمتين برمجيتين أو مكتبتين مرخصتين برخصتين فيهما بنود متعارضة. انظر إلى الحزم البرمجية التي تستعملها في مشروعك، وحاول أن تختار رخصةً لا تتعارض مع بنود تلك الحزم. هنالك مصادرٌ عدِّة تستطيع الحصول على معلومات توافقية الرخص منها، بما في ذلك ويكيبيديا. تؤثر عادةً المشاكل في التوافقية على الرخص المعقَّدة والمحدَّدة مثل GPLv3؛ فكلما ازداد طول الرخصة وتخصيصها للبنود، كما ازدادت احتمالية حدوث مشاكل في التوافقية. تحقق من مجتمعك اعتمادًا على التقنيات التي يستعملها مشروعك، قد تجد أنَّ إحدى الرخص أفضل وأنسب من الأخرى، آخذًا بعين الاعتبار سهولة دمج مشروعك وتبنيه، وخصيصًا لو كان مكتبةً. فاستعمال أكثر رخصة شائعة في مجالك ستُسهِّل الأمر على مستعمليها، لأنهم سيكونون معتادين على شروط تلك الرخصة، وسيتم تقليل احتمالية وجود تعارض في الرخص في المشاريع. على سبيل المثال، مجتمعَا JavaScript و Ruby يُحبذون الرخص الأكثر سماحيةً مثل MIT، بينما تُنشَر المشاريع المكتوبة بلغة C/C++‎ برخصة GPL. عليك أن تبحث قليلًا في المجتمع التطويري المحيط بك عندما تنشر مكتبة برمجية وفق رخصةٍ معينة، فذاك المجتمع قد يساعدك بقرارك. لكن لا تُكرِه نفسك على رخصة معينة لأن الآخرين يستعملونها، فقد لا تكون خيارًا صائبًا لمشروعك. الخلاصة هي أنه اختيارك سيكون سديدًا إن كانت تتوافق الرخصة التي اخترها مع أغلبية المكتبات في مجتمعك. بدون رخصة إحصائيات الاستخدام التي نُشِرَت من Ben Balter على مدونة Github في مطلع عام 2015 تُظهِر أنَّ حوالي 80% من المستودعات على الموقع لا تُضمِّن رخصة؛ وهذا يعني أنَّ لا يُسمَح لأي شخص قانونيًا أن يستعمل الشيفرة الخاصة بهم حتى لو كانت متوفرة على الإنترنت لأنه لا يمكن اعتبارها "مفتوحة المصدر". هذا أمرٌ كارثي! إن لم يكن هذا ما تطمح له، فخذ وقتك للتفكير برخصة مناسبة، وإلا فلن "يلمس" أي مبرمج خبير الشيفرة الخاصة بك، ويعرض سمعته للخطر بدعوى قضائية. الخلاصة هذه هي الطريقة التي أتبعها لاختيار رخصة لمشروعي. لا يوجد خيار صائب أو خيار خاطئ في اختيارك للرخصة إن كنت تعي ما تفعل. اختر واحدةً تناسب احتياجاتك، وتأكد أن تختار رخصةً واحدةً على الأقل. ما هي الرخصة التي استعملتها لآخر مشروعٍ لك؟ أخبرنا في التعليقات. ترجمة -وبتصرّف- للمقال How to pick an open source licence for your code لصاحبه Radek Pazdera.

وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".