المصدر المفتوح: ليس الأمر مخيفًا!

تم نشر ما يلي قبل إطلاق منح Toptal للمطورين الإناث.

بصفتك مطورًا ، من المثير والتحدي مواكبة أحدث الاتجاهات في التكنولوجيا. كل يوم ، تجذب لغات وأطر عمل وأجهزة جديدة انتباهنا وتحفز المحادثات في اللقاءات والمنتديات والمحادثات. ومع ذلك ، فإن مجتمع المطورين لدينا يتكون من أشخاص وليس أدوات ، ومن الرائع استكشاف الجوانب الاجتماعية والسياسية (لعدم وجود كلمة أفضل ؛ تميل كلمة "اجتماعي" إلى الارتباط بالشبكات الاجتماعية ، في هذه الأيام).

في Toptal ، أجرينا مؤخرًا بعض المحادثات الشيقة حول مقدار مساهمة النساء في المصادر المفتوحة وما الذي قد يمنعهن من المساهمة بشكل أكبر ، لذلك قمنا بالتحقيق في الأمر. بعد أن كنت جزءًا من تلك المحادثة مع Breanden Beneschott و Bozhidar Batsov ، أصبحت أتساءل: Bozhidar هو أحد كبار المساهمين في المصادر المفتوحة على GitHub. أين أنا؟ إذا قمت بفحص حساب GitHub العام الخاص بي اعتبارًا من اليوم ، فستكون بشكل أساسي مشاريع اختبار صغيرة استخدمتها في الفصل لطلابي. إنهم نصف مخبوزين ، وبالتأكيد لا يمثلون مهاراتي أو خبرتي. (يجب أن تأخذ كلامي في هذا الأمر.) إذا كان هناك من يفكر في تعييني بناءً على ما يمكن أن يجده في هذا الحساب ، أعتقد أنني سأجد صعوبة في كسب لقمة العيش. ما زلت مطورًا محترفًا لأكثر من 20 عامًا ، وفي وظيفتي اليومية كنت أستخدم برامج مفتوحة المصدر أكثر مما يهمني أن أتذكره. بمرور الوقت ، قمت باختراق نواة Linux لربطها ببعض الاحتياجات المحددة ، وقمت بتعديل كل جهاز توجيه و NAS اشتريته ، وانتظرت بصبر لأشهر في قائمة انتظار Raspberry Pi للحصول على يدي والحصول على الدومينات محلية الصنع مثل احب ذلك. ومع ذلك ، لم يصل أي من هذه التعديلات والاختبارات إلى GitHub ليصبح مفتوح المصدر. أيضًا ، بصرف النظر عن إصلاح الخلل في أحد الإصدارات الأولى من Tomcat ، لم أساهم مطلقًا في مشروع مفتوح المصدر. فضولي ، أليس كذلك؟

قد تعتقد أنه مجرد نقص في الوقت أو الاهتمام ، لكنني أعلم أنه ليس كذلك. بالنسبة لمشاريعي الشخصية ، ربما اعتقدت أنه لا يمكن لأحد أن يهتم حقًا بما قمت به ، ولكن في الغالب هو مجرد فكرة نشر عملي هناك ، ليراها الجميع وللأجيال القادمة ، تخيفني كثيرًا. وعلى الرغم من أنه يمكنك دائمًا هدم مشروع شخصي من GitHub ، ففي اليوم الذي تحاول فيه المساهمة في مشروع مفتوح المصدر متاح على نطاق واسع ، لن يكون هناك عودة للوراء. ماذا لو لم يكن الكود الخاص بي جيدًا بما يكفي؟ ماذا لو لم أفهم المشكلة بشكل صحيح؟ ماذا لو تم رفض طلب السحب الخاص بي؟ ماذا لو كان الناس يتصيدونني؟

سرعان ما أقنعتني جولة سريعة من المكالمات مع الأصدقاء المطورين ، ومعظمهم من الإناث ، أنني لست الوحيد الذي يعاني من هذه المشكلة ، ولكن بالنسبة للمهندس ، لا توجد مشاكل ، فقط حلول ، أليس كذلك؟

هذه مشكلة مهمة يجب حلها ، لأن المساهمة في مشروع مفتوح المصدر يمكن أن تحدث فرقًا كبيرًا:

• خلال حياتك المهنية : سينظر العديد من العملاء إلى كل شيء اجتماعيًا قبل أن يقرروا تعيينك ؛ يتصدر حسابك على GitHub وسيرتك الذاتية على LinkedIn أعلى القائمة ، جنبًا إلى جنب مع ملفاتك الشخصية على Facebook و Twitter. يجب عليك استخدامها بحكمة.
• لمهاراتك التقنية : إن فحص قاعدة بيانات مكتوبة من قبل مطورين آخرين ، وغالبًا ما يكون جيدًا جدًا ، يعلمك الكثير. إن القدرة على إخراج المعنى من قاعدة بيانات مكتوبة بشكل سيئ سوف تتحدى وتعلمك بنفس القدر.
• لمهاراتك الشخصية : البرمجيات مفتوحة المصدر هي عملية تعاونية ، وتقريبًا جميع المشاريع المثيرة للاهتمام يتم إنشاؤها بواسطة فرق. تعلم العمل مع مطورين آخرين من خلال الأدوات التي يستخدمها الجميع ، للاندماج مع الفريق ، للتواصل بكفاءة ، هو ما سيجعلك مطورًا رائعًا ، وليس مجرد مطور ماهر.
• للمجتمع : كل جزء تساهم به في مشروع مفتوح المصدر مهم. كلما زادت مساهمتك ، كان ذلك أفضل ، ولكن حتى إصلاح خطأ إملائي صغير في الترجمة سيجعل المنتج النهائي أفضل.
• لشبكتك : يمكنك إرسال مئات السير الذاتية إلى الشركات ، ولكن لا شيء يعمل مثل وجود زملاء لهم اتصالات شخصية. إن الانخراط بنشاط في مشروع مفتوح المصدر سيضمن لك مقابلة الناس واكتساب احترامهم ، وستنمو سمعتك ، وهو أمر لا يقدر بثمن لأي محترف.

هذه رحلتي الشخصية الصغيرة في محاربة هذا الخوف. نشر هذه المقالة هو جزء من الرحلة نفسها. أكتبها على أمل أن أي شخص تم حظره من كتابة منشور مدونة ، أو يخشى تقديم مساهمة صغيرة ، سيرى أنه في النهاية ، لم يكن الأمر مخيفًا للغاية. أيضًا ، يُقصد به مساعدة أي شخص يرغب في المساهمة في المصدر المفتوح ، لكنه لا يعرف حقًا من أين أبدأ ، لذلك سأبدأ بالأساسيات.

ما هو برنامج مفتوح المصدر وأين أجده؟

البرمجيات مفتوحة المصدر ، أو اختصارًا OSS ، هي أي برنامج تم إصداره مع كود المصدر الخاص به ، ويتضمن ترخيصًا يسمح لك بتعديله وإعادة توزيعه. يمكن تسليمها في أي مكان: على موقع الويب أو من خلال قائمة بريدية أو مع بومة. السيناريو الأكثر شيوعًا ، والذي نهتم به ، هو عندما يتم الاحتفاظ بقاعدة الشفرة في مستودع تعاوني. هنا ، نركز على GitHub ، ولكن هناك خيارات أخرى ، مثل SourceForge و Bitbucket. GitHub ودود للغاية ، ولديه قاعدة مستخدمين ضخمة ، ويمكن استخدامه لأي نوع من التعليمات البرمجية ، ومع أي بيئة تطوير تستخدمها. الأهم من ذلك ، أنه يستخدم أيضًا على نطاق واسع للمشاريع غير مفتوحة المصدر. من المحتمل أن يتم استضافة مشروع العميل التالي هناك ، لذا فإن معرفة كيفية التعامل معه يعد مهارة مفيدة في حد ذاته.

ماذا لو كنت لا أعرف كيفية البرمجة؟

إذا كنت تقرأ هذا ، فمن المحتمل أنك تريد معرفة كيفية البرمجة. يمكنك العثور على دورات مذهلة في العديد من المواقع المجانية والمدفوعة. يجب عليك اختيار لغة واحدة لتتعلمها ؛ إذا لم يكن لديك تفضيل ، فانتقل إلى JavaScript. لديك بالفعل كل ما تحتاجه للبدء في متصفح الويب الخاص بك وهو أحد أكثر المهارات استخدامًا وقابلية للتسويق. مفضلتي الشخصية هي Python ، والتي تُستخدم في تطوير الويب والتطبيقات العلمية. لدي أيضًا دورة شخصية مفضلة للمبتدئين ، "مقدمة في علوم الكمبيوتر" على موقع Udacity. يعجبني لأنها دورة تدريبية عملية ، حيث تعمل في مشروع بينما تتعلم. يمكنك أيضًا العثور على العديد من الدورات التدريبية الأخرى في Coursera و Khan Academy و PluralSight.

ماذا لو لم أكن أعرف Git؟

كما ذكرنا سابقًا ، فإن معرفة Git أمر مهم ، لذا احضر فصلًا دراسيًا في Git. افعل ذلك حتى لو كنت تعمل مع Git لفترة ؛ أنت لا تعرف مقدار ما لا تعرفه عن Git حتى تدرسه حقًا. افعل ذلك إذا كنت لا تستطيع أن تشرح بثقة ما يفعله الأمر rebase . افعل ذلك حتى لو لم تخيفك عملية تغيير العنوان الخاطئة. سلكت مسار Git الكامل في Code School ، ولكن مرة أخرى ، يمكنك استكشاف مواقع أخرى لمزيد من الخيارات.

كيف أختار مشروعًا على GitHub؟

من المحتمل أنك تستخدم بعض OSS في تطورك اليومي. يعد اختيار إطار عمل مألوف نقطة انطلاق جيدة ؛ أنت على دراية بالميزات وكيفية عمل إطار العمل. عندما تغوص في الكود المصدري ، ستتعلم المزيد ، وستفهم منطقها بشكل أكثر وضوحًا. إذا كانت هناك تقنية أو أداة تعجبك بشكل خاص ، فابحث عن المشاريع التي تذكرها ، أو عن مشروع الأداة نفسه. كحل أخير ، يمكنك التحقق من المشاريع على GitHub Showcases والبدء باختيار فئة تهمك.

على سبيل المثال ، يُظهر البحث السريع عن "Raspberry" في بحث GitHub أكثر من 17 ألف مستودع. من السهل أن تضيع ، لذا ابحث عن مشروع يضم مجتمعًا جيدًا وتتبعًا جيدًا للمشكلات. عند اختيار مشروع ، تحقق من عدد:

• المساهمون : استهدف أي شيء يزيد عن عشرة مساهمين. يجب أن يضمن ذلك أن المشروع لديه الاهتمام الكافي وليس مجرد جهد جماعي صغير. إذا كنت جديدًا على OSS ، أو لم تكن ماهرًا جدًا ، فاقصر بحثك على المشاريع التي تضم خمسين مساهمًا على الأكثر ؛ تشير المجتمعات الكبيرة إلى قواعد أكواد أكبر ومشاريع أكثر تعقيدًا.
• الالتزامات : اذهب للمشاريع التي لديها ما لا يقل عن ألف التزام ، وحيث أن أحدث نشاط لا يزيد عن أسبوع. المشروع الذي كان غير نشط لمدة شهر أو أكثر قديم وقديم من حيث OSS ، وربما لن تحصل على أي ردود بسرعة. النشاط اليومي هو علامة على مشروع صحي.
• المشكلات : المشكلات هي مشكلات مفتوحة أو أخطاء تم الإبلاغ عنها أو طلب ميزات لتنفيذها. سوف يعطونك نقطة بداية ويكونون مقياسًا جيدًا للاهتمام بالمشروع.

تعرف أيضًا على اللغة الرئيسية للمشروع ؛ يمكنك رؤية إحصائيات اللغة في الشريط العلوي لصفحة المشروع الرئيسية. خذ بعض الوقت لقراءة نغمة المناقشة ، وانظر إلى أي مدى تكون التعليقات ودية ومتعلمة. بعض المشاريع سيئة السمعة لمجتمعاتهم العدوانية ، وبالتالي قد لا تكون نقطة البداية الصحيحة.

اخترت ScyllaDB ، وهو مشروع تخزين بيانات عمودي ، حيث إنني مولع بالبيانات - أي شيء يتعلق بالأداء. لم أعمل معها مطلقًا ، لكنني أتوقع أن أكون قادرًا على الغوص في قاعدة بياناتها. قد يكون العمل باستخدام الأدوات التي أعرفها أسهل ، لكنني أعتبر ذلك بمثابة تحدٍ ومناسبة لتعلم شيء جديد. بالنسبة للباقي ، يناسب الفاتورة تمامًا ؛ لديها 18 مساهمًا ، و 6.5 ألف التزام (آخرها كان قبل 23 ساعة وقت كتابة هذا التقرير) ، و 178 مشكلة مفتوحة ويبدو أنها نشطة.

ماذا أفعل الآن؟

أولاً ، قم باستنساخ المستودع وتثبيت البرنامج على جهازك للحصول على فكرة عن أجزائه المتحركة. ثم ابدأ بقراءة المشاكل. بمجرد أن تشعر بالاستعداد ، تحقق مما إذا كان يمكنك إعادة إنتاج المشكلة على جهازك ثم ابدأ في تحليل ما يجعل البرنامج يسيء التصرف.

هناك طريقة أخرى تتمثل في العثور على شيء يمكنك تحسينه أو تعديله بنفسك. ربما لاحظت وجود خطأ إملائي أو خط غير محاذي ، على سبيل المثال. اخترت إصلاح خطأ صغير ، وتحديدًا اسم متغير خاطئ مستخدم في وثائق البرنامج النصي.

يبدو الأمر ضئيلاً ، لكن التوثيق الخاطئ أسوأ بكثير من عدم وجود وثائق. سيقوم المستخدمون بتثبيت ScyllaDB ومتابعة خطوات التثبيت ، وسوف يعتمدون بشكل أعمى على ما هو مكتوب في هذا البرنامج النصي ، وسوف ينتهي بهم الأمر في أكوام من الإحباط. كان هذا مثاليًا لقدراتي ، وسيتطلب إصلاحه مني متابعة العملية برمتها ، والتعرف قليلاً على قاعدة التعليمات البرمجية. إصلاح الأخطاء أمر ممل ، لكنه بداية رائعة لتجد طريقك إلى المشروع.

عمل شوكة

قد يكون هذا تافهاً ، لكن في الوقت الحالي ، بالنسبة لمشروع ScyllaDB ، أنا السيدة لا أحد ؛ سيكون من الخطر السماح لي بإجراء تغييرات على التعليمات البرمجية الخاصة بهم دون إشراف. ما أحتاجه هو إنشاء "مفترق" في حسابي على GitHub. هنا شوكة ScyllaDB الخاصة بي. إنه ملعبي الخاص حيث يمكنني الوصول إلى جميع الأكواد ، ويمكنني تعديل الملفات كما أريد. إذا كنت أرغب في إنشاء نسختي الخاصة من ScyllaDB وتعديلها للقيام بشيء مختلف تمامًا عن الغرض الأصلي ، يمكنني القيام بذلك هنا. إنشاء مفترق بسيط ؛ انتقل إلى الصفحة الرئيسية للمشروع وانقر على زر "fork". ليس مخيفا على الاطلاق.

حان الوقت لإصلاح الخلل

الآن ، حان الوقت لاختبار الكود على جهاز الكمبيوتر الخاص بك وإجراء التعديلات اللازمة. بادئ ذي بدء ، تأكد من تثبيت عميل Git على جهازك. بعد ذلك ، أضف مفتاح SSH العمومي إلى GitHub ، وتأكد من تحميله بواسطة وكيل ssh. الحصول على الكود محليًا أمر بسيط ؛ فقط استخدم الأمر git clone الذي يشير إلى مفترقك ، بدلاً من الفرع الرئيسي:

 git clone [email protected]:acbellini/scylla.git

الآن ، يجب أن تكون قد اختبرت المشروع في الفرع الرئيسي ، لذلك ستقوم ببناء الكود الخاص بك محليًا واختباره بنفس الطريقة. ضع في اعتبارك أنه سيتعين عليك تفكيك أي مشاريع GitHub أخرى يعتمد عليها مشروعك ، حيث أن المراجع نسبية. في حالتي ، اضطررت إلى تفرع seastar و scylla-ami و scylla-swagger-ui.

الخطأ الذي أحتاج إلى إصلاحه بسيط نسبيًا ؛ تشير الوثائق الموجودة في conf/scylla.yaml إلى ثلاثة أدلة قابلة للتكوين: أحدها لملفات البيانات ، وواحد لسجلات الالتزام وواحد ، على ما يبدو ، لملفات التخزين المؤقت ، وكلها متخلفة عن مجلد فرعي من $CASSANDRA_HOME :

عند الغوص في الكود ، يُظهر أن الإعدادات الافتراضية مختلفة ، وكما هو مذكور في الإصدار رقم 372 الذي بدأت منه ، لا ينبغي استخدام $CASSANDRA_HOME . أقوم بالتحقق من صحة فرضيتي عن طريق اختبار الكود بعدة إعدادات مختلفة ، عن طريق إزالة الإعداد من ملف التكوين والتحقق من الدلائل المستخدمة. بمجرد التأكد من صحة كل شيء ، يمكنني إضافة الملف المعدل والتزامه ودفعه:

 git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

لاحظ أنني قدمت رقم الإصدار مسبوقًا بعلامة تجزئة في رسالة الالتزام. سيخبر هذا GitHub بربط الكود الخاص بي تلقائيًا بالمشكلة نفسها.

شيء آخر مهم يجب ملاحظته هو أنه عندما قمت بمسح الكود ، أدركت أن الدليل الثالث ، دليل ذاكرات التخزين المؤقت ، لا يتم استخدامه في الواقع. من المغري الذهاب إلى أبعد من اللازم وإزالة هذا الإعداد نفسه ، أو إضافة تعليق غير مستخدم ، ولكن سيكون ذلك خارج نطاق المشكلة رقم 372 ، وسيكون من الخطأ ارتكاب أي شيء لا يرتبط ارتباطًا وثيقًا بهذا. مشكلة. يجب أن تحافظ على تركيز تغييراتك وأن تقتصر على المهمة المطروحة.

في هذه المرحلة ، تم إصلاح الكود وهو موجود على GitHub ، في مفترقتي الخاصة. هذا هو المكان الذي يأتي فيه الجزء المخيف: مطالبة أفراد ScyllaDB بقبول الكود الخاص بي. هذا يسمى طلب السحب.

الخطوة الأخيرة: طلب السحب

أحب إنشاء طلبات سحب مباشرة من واجهة الويب على GitHub. أجده أكثر سهولة ومقاوم للخطأ من محاولة القيام بذلك من سطر الأوامر. كل ما علي فعله لإنشاء طلب السحب الخاص بي هو النقر فوق الزر الأخضر الصغير بجوار اسم الفرع الخاص بي:

لاحظ أنه تم حساب التعليق تلقائيًا بواسطة GitHub. يحتوي فرعي الآن على التزام جديد واحد ، ولكن منذ إنشاء مفترقتي ، هناك 14 التزامًا آخر في المستودع الرئيسي ، لذلك سأضغط على الأيقونة الخضراء على اليسار.

لحسن الحظ ، لا يتعارض التزامي الفردي مع الـ 14 آخرين ، لذلك أبلغني GitHub أنني على ما يرام. لست بحاجة إلى إضافة أي تعليق أو رسالة أخرى. رسالة الالتزام ، رغم كونها قصيرة جدًا ، تقول كل شيء: ما يفعله تغيير الكود وما يرتبط به. عندما أنقر على الزر الأخير لتأكيد طلبي ، أتساءل ما الذي وجدته مخيفًا جدًا قبل بضعة أيام فقط. لا يوجد وحش يزمجر في وجهي الآن ، ولا يبدو أن ألسنة اللهب تحترق. بصراحة ، لم يكن الأمر مخيفًا على الإطلاق. في الحالة غير المحتملة التي أخطأت فيها ، لن يتم قبول الإصلاح الخاص بي وسيكون الأمر كذلك.

إذا قمت الآن بالتحقق من تفاصيل المشكلة ، يمكنك أن ترى أن GitHub أضاف تلقائيًا ملاحظة تفيد بوجود طلب سحب يشير إلى هذه المشكلة. هذا هو سحر ذلك # 372 في رسالة الالتزام. سيساعد هذا في تجنب إضاعة الأشخاص الآخرين للوقت لإصلاح شيء تم إصلاحه بالفعل.

ملاحظات نهائية

أنا الآن في انتظار قبول طلب السحب الخاص بي ، وسوف أتلقى إشعارًا عند حدوث ذلك. ضع في اعتبارك أن هذا قد يستغرق بضعة أيام ، أو حتى أسابيع ؛ يجب على شخص ما مراجعة الكود الخاص بي ، واختباره يعمل على النحو الموصوف ، وإصلاح المشكلة ، وفي النهاية ، التأكد من أنه لا يؤثر سلبًا على وظائف باقي الكود (اقرأ: إنشاء أخطاء جديدة). كل هذا يستغرق وقتًا من شخص ما ، لذا كن صبورًا. في النهاية ، عندما يتم قبول طلب السحب الخاص بي ، سيكون لدى ScyllaDB مساهم واحد آخر ، مشكلة واحدة أقل وسيكون لدي أول مساهمة في OSS. الآن ، حان الوقت لتجربته أيضًا. بعد كل شيء ، إنه ليس مخيفًا على الإطلاق.