مقدمة
منذ وقت قريب، كان النموذجان الأكثر تميزًا في صناعة البرمجيات: نموذج المصدر المفتوح، والنموذج الخاص. استفادت برمجيات المصدر المفتوح من انفتاح علامتها التجارية: بحيث يُسمح لأي شخص بتقديم مساهمات؛ وهذا ما فعله الكثير من الناس. ومن ناحية أخرى، فإن البرمجيات الاحتكارية تحد من الوصول عن طريق نظام مغلق يُقدِّر خصوصية ملكيته الفكرية (IP).
لنفترض أنك قائد في شركة قامت باستثمارات كبيرة في برامجها الخاصة. ولا يجب أن تكون شركة متخصصة في مجال التكنولوجيا؛ فالشركات من جميع الأشكال والأحجام تقوم ببناء البرامج الخاصة بهم وغيرها من الملكيات الفكرية وصيانتها؛ للتمتع بميزة تنافسية في مجالها. ومع ذلك، قمت بتطوير احترام كبير للأنماط المستخدمة في مصدر مفتوح، مثل رؤية التعليمات البرمجية المصدر، والوعي بأخطاء المشروع، وشفافية طلب الميزة. كما أنك تحب نموذج طلب السحب الذي يبسط تكامل المساهمات الخارجية. وأنت ترغب حقًا في توفير تلك الفوائد لفرق التطوير الخاصة بك؛ ولكن لا تريد فتح مصدر البرمجيات القيّمة الخاصة بالشركة. ما تحتاجه هو هجين يوفر مزايا كلا النهجين. ما تحتاجه هو InnerSource.
في هذه الوحدة، تعرف على كيفية إدارة برنامج InnerSource ناجح على GitHub من خلال إمكانية الاكتشاف والتوجيه والصيانة الفعالة.
الأهداف التعليمية
في هذه الوحدة النمطية، تتعلم كيفية:
- تباين المشاريع المملوكة للمستخدم مقابل المشاريع المملوكة للمؤسسة.
- تقديم توصيات حول عدد مؤسسات GitHub التي يجب أن يكون لديك.
- إنشاء مستودعات قابلة للاكتشاف.
- إنشاء READMEs لمستودع قوي.
- استخدم قوالب المشكلة وطلب السحب.
- بناء الشفافية في المستودعات.
- قياس نجاح InnerSource داخل مؤسستك.
- توزيع مجموعة أدوات InnerSource.
المتطلبات الأساسية
- حساب GitHub.
- القدرة على التنقل وتحرير الملفات في GitHub.
- كن على إلمام بطلبات السحب.
يوصى بإكمال مقدمة GitHub قبل البدء في هذه الوحدة.