التعاون في المصدر المفتوح
مقدمة
هل تريد المشاركة في مشاريع المصدر المفتوح لكنك لا تعرف من أين تبدأ؟ المصدر المفتوح ليس مجرد "استخدام كود الآخرين مجانًا"، بل هو أيضًا طريقة للتعاون ومُسرّع مهني. مساهمة عالية الجودة في مشروع مفتوح المصدر قد تكون أكثر إقناعًا من عشرة مشاريع شخصية في سيرتك الذاتية.
سيساعدك هذا الفصل على فهم العملية الكاملة للتعاون في المصدر المفتوح، من البحث عن المشاريع إلى إرسال طلبات السحب، خطوتك الأولى كمُساهم.
ماذا ستتعلم في هذه المقالة؟
| الفصل | المحتوى | المفهوم الأساسي |
|---|---|---|
| الفصل 1 | عملية المساهمة | السلسلة الكاملة من Fork إلى PR |
| الفصل 2 | تراخيص المصدر المفتوح | الفروق بين التراخيص المختلفة |
| الفصل 3 | آداب التعاون | كيف تكون مساهمًا مرحبًا به |
| الفصل 4 | البدء من الصفر | إيجاد المشاريع المناسبة للمبتدئين |
بعد إكمال هذا الفصل، ستتقن العملية الكاملة وآداب التعاون في المصدر المفتوح، مع الثقة لإرسال مساهمات لأي مشروع مفتوح المصدر.
0. نظرة عامة: قيمة المصدر المفتوح
المصدر المفتوح ليس مجرد مشاركة الكود، بل هو نموذج تعاون عالمي. Linux، React، Vue، Node.js — كل هذه المشاريع التي غيّرت العالم هي مشاريع مفتوحة المصدر.
فوائد المشاركة في المصدر المفتوح
- النمو التقني: قراءة كود ممتاز، تلقي مراجعات من خبراء
- التطوير المهني: مساهمات المصدر المفتوح هي أفضل بطاقة تعريف تقنية
- الانتماء للمجتمع: أن تصبح عضوًا في مجتمع المطورين العالمي
- المساهمة في النظام البيئي: الأدوات التي تستخدمها يوميًا تحتاج أيضًا إلى من يصونها
1. عملية المساهمة في المصدر المفتوح
من خلال المكون التفاعلي التالي، تعرف خطوة بخطوة على العملية الكاملة من Fork إلى Merge:
🍴 Fork
Fork the target repository on GitHub into your own account to get a full copy.
# Click the Fork button on GitHub1.1 ملخص العملية
Fork → Clone → Branch → Commit → Push → PR → Review → Merge1.2 تفاصيل الخطوات الرئيسية
إنشاء فرع للميزة: لا تطوّر مباشرة على main.
git checkout -b fix/typo-in-readmeكتابة رسائل التزام واضحة: اتبع اتفاقيات الالتزام الخاصة بالمشروع.
git commit -m "fix: تصحيح خطأ إملائي في أمر التثبيت في README"إنشاء طلب سحب (Pull Request): يجب أن يتضمن وصف PR:
- ماذا تغير ولماذا
- رقم Issue المرتبط (مثل
Fixes #123) - كيفية اختبار تغييراتك
2. تراخيص المصدر المفتوح
من خلال المكون التفاعلي التالي، قارن بين الفروق بين تراخيص المصدر المفتوح الأكثر شيوعًا:
Open-source license comparison tool
| License | Commercial use | Modify | Distribute | Patent grant | Private use | Open derivatives | Liability waiver |
|---|---|---|---|---|---|---|---|
| MITVery permissive, almost no restrictions | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ |
| Apache 2.0Permissive plus patent protection | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ |
| GPL 3.0Strong copyleft, derivatives must be open source | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| BSD 2-ClauseSimilar to MIT, minimal and permissive | ✓ | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ |
| MPL 2.0File-level copyleft, a middle ground | ✓ | ✓ | ✓ | ✓ | ✓ | ⚠ | ✓ |
2.1 التراخيص الشائعة
| الترخيص | الخصائص | مشاريع تمثيلية |
|---|---|---|
| MIT | الأكثر تساهلًا،几乎没有 قيود | React, Vue, jQuery |
| Apache 2.0 | يتطلب الاحتفاظ بإشعار حقوق النشر، يمنح ترخيص براءات اختراع | Android, Kubernetes |
| GPL | الأعمال المشتقة يجب أن تكون مفتوحة المصدر أيضًا | Linux, WordPress |
| BSD | مشابه لـ MIT، مع اختلافات طفيفة | FreeBSD, Flask |
2.2 كيف تختار؟
- إذا كنت تريد أن يستخدمه المزيد من الناس: اختر MIT
- إذا كنت تريد حماية براءات الاختراع: اختر Apache 2.0
- إذا كنت تريد ضمان أن المشتقات مفتوحة المصدر أيضًا: اختر GPL
3. آداب التعاون
3.1 آداب فتح Issues
<!-- سيء -->
العنوان: لا يعمل
المحتوى: منتجكم فيه خطأ
<!-- جيد -->
العنوان: v2.1.0 شاشة بيضاء في صفحة تسجيل الدخول على Safari 17
المحتوى:
- البيئة: macOS 14.2, Safari 17.2
- خطوات إعادة الإنتاج: 1. فتح صفحة تسجيل الدخول 2. إدخال اسم المستخدم وكلمة المرور 3. النقر على تسجيل الدخول
- السلوك المتوقع: الانتقال إلى الصفحة الرئيسية
- السلوك الفعلي: شاشة بيضاء، خطأ في وحدة التحكم TypeError: xxx
- لقطة شاشة: [إرفاق صورة]3.2 آداب إرسال PRs
- اقرأ
CONTRIBUTING.mdأولاً لمعرفة قواعد المساهمة في المشروع - PR واحد يفعل شيئًا واحدًا فقط، لا تخلط تغييرات متعددة
- حافظ على PRs صغيرة ومركزة لتسهيل المراجعة
- انتظر المراجعة بصبر واستجب للملاحظات بلطف
3.3 مراجعة كود الآخرين
- أثنِ على ما هو جيد أولاً، ثم اقترح التحسينات
- اسأل بدلاً من أن تأمر: "هل تم النظر في استخدام النهج X هنا؟"
- قدم الأسباب والبدائل، لا تقل فقط "سيء"
4. البدء بالمساهمة من الصفر
4.1 أنواع المساهمات المناسبة للمبتدئين
| النوع | الصعوبة | الوصف |
|---|---|---|
| تصحيح أخطاء التوثيق | منخفضة | أخطاء إملائية، روابط قديمة، شروحات غير واضحة |
| الترجمة | منخفضة | ترجمة التوثيق إلى لغات أخرى |
| إضافة اختبارات | متوسطة | إضافة اختبارات للكود غير المغطى |
إصلاح أخطاء موسومة بـ good first issue | متوسطة | مشاكل يحددها المشرفون كمناسبة للمساهمين الجدد |
| ميزات جديدة | عالية | ناقش النهج في Issue أولاً، ثم ابدأ بعد الحصول على الموافقة |
4.2 إيجاد المشروع المناسب
- ابدأ بالأدوات التي تستخدمها يوميًا
- ابحث في GitHub عن العلامة
good first issue - تحقق من نشاط المشروع (هل يتم صيانته بنشاط مؤخرًا؟)
5. دعم الذكاء الاصطناعي: تسريع المساهمات في المصدر المفتوح بالنماذج اللغوية
يمكن للنماذج اللغوية مساعدتك في فهم قواعد الكود غير المألوفة بسرعة، وكتابة أوصاف PR عالية الجودة، بل وحتى المساعدة في مراجعة الكود.
5.1 فهم قاعدة كود غير مألوفة بسرعة
Prompt:
لقد استنسخت للتو مشروعًا مفتوح المصدر. يرجى تحليل هيكل الدليل التالي، وشرح مسؤولية كل دليل/ملف، والبنية العامة وتدفق البيانات للكود. أريد إصلاح خطأ متعلق بتسجيل الدخول، من أين يجب أن أبدأ؟ [الصق مخرجات أمر tree أو هيكل الدليل]
5.2 كتابة أوصاف PR
Prompt:
بناءً على git diff التالي، اكتب وصف طلب سحب يتضمن: - العنوان (مختصر، يوضح ما تم تغييره) - شرح التغييرات (لماذا وماذا تم تغييره) - طريقة الاختبار (كيفية التحقق من صحة التغيير) - Issue المرتبط (إن وُجد) اكتب بالإنجليزية، بنبرة مهنية وودودة. [الصق مخرجات git diff]
5.3 المساعدة في ترجمة التوثيق
Prompt:
ترجم المستند التقني الصيني التالي إلى الإنجليزية، مع المتطلبات التالية: 1. استخدم المصطلحات التقنية المعتمدة في المجال 2. لا تترجم تعليقات الكود وأسماء المتغيرات 3. حافظ على تنسيق Markdown كما هو 4. النبرة يجب أن تكون طبيعية وسلسة، بدون طابع الترجمة الآلية [الصق المستند الصيني]
نصائح استخدام الذكاء الاصطناعي
عند استخدام الذكاء الاصطناعي لكتابة أوصاف PR، تأكد من أنك تفهم كل سطر من التغييرات. قد يسألك المراجع لماذا قمت بهذا التغيير — إذا لم تستطع الإجابة، فهذا يعني أنك لم تفهمه حقًا.
6. الخلاصة
- العملية: Fork → Branch → Commit → PR → Review → Merge
- التراخيص: MIT الأكثر تساهلًا، GPL الأكثر صرامة، اختر حسب احتياجاتك
- الآداب: Issues واضحة، PRs مركزة، تواصل ودود
- البداية: ابدأ بتصحيح التوثيق والمشاكل ذات علامة
good first issue
تأمل أخير
جوهر المصدر المفتوح هو التعاون. القدرات التقنية مهمة، لكن مهارات التواصل والوعي بالتعاون لا يقلان أهمية. PR بتعامل ودود ووصف واضح هو أكثر ترحيبًا من PR بكود مثالي لكن بتواصل عدواني. PR الأول لك لا يحتاج أن يكون مثاليًا، تحتاج فقط إلى اتخاذ الخطوة الأولى.
قراءات إضافية
- دليل البدء: Open Source Guide من GitHub هو أفضل مصدر للبدء في المصدر المفتوح.
- نصائح عملية: ابحث عن مشروع يعجبك، ضع له نجمة أولاً، ثم اقرأ الكود، وأخيرًا ابحث عن فرصة للمساهمة.
- المشاركة المجتمعية: شارك في فعاليات مثل Hacktoberfest للحصول على دعم المجتمع.
- منظور المشرف: افهم عبء العمل والضغط على المشرفين، وكن مساهمًا مراعيًا.