# البرمجية الداخلية المفتوحة

البرمجيات الداخلية المفتوحة (بالإنجليزية: Inner source)‏ هي استخدام أفضل الممارسات في تطوير البرمجيات مفتوحة المصدر وتأسيس ثقافة مشابهة للبرمجيات مفتوحة المصدر داخل المنظمات، وذلك لتطوير البرمجيات الخاصة بها والتي لا تكون مفتوحة المصدر أو التي هي ملكية. تم ابتكار هذا المصطلح بواسطة تيم أوريلي في عام 2000 في عموده الصحفي.

## تحفيز

يُعترف بأن البرمجيات مفتوحة المصدر قادرة على تقديم برمجيات عالية الجودة. علاوة على ذلك، فإن التعاون المفتوح في البرمجيات مفتوحة المصدر يتيح التعاون حتى بين الشركات المنافسة (مثل عمل شركتي ARM وIntel معًا على نواة لينكس بناءً على قرارات قائمة على الجدارة).
نتيجة لذلك، تسعى منظمات تطوير البرمجيات للاستفادة من نتائج البرمجيات (المكونات والأدوات البرمجية)، ولكن أيضًا من الممارسات التطويرية التي تمارس وتُثبت في عالم البرمجيات مفتوحة المصدر.

## إستخدام الممارسات مفتوحة المصدر

بجانب العديد من الممارسات التي تم تأسيسها في المنظمات مثل Apache Software Foundation وLinux Foundation وEclipse Foundation، تتطلب البرمجيات الداخلية المفتوحة (InnerSource) والمشاريع مفتوحة المصدر التعاون المفتوح، والتواصل المفتوح، وضمان الجودة المناسب.

### التعاون المفتوح

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

### التواصل المفتوح

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

### ضمان الجودة من خلال فصل المساهمة عن التكامل

تضمن مراجعة الكود المخصصة وفصل المساهمين عن المدمجين (المطورين الذين لديهم صلاحيات الكتابة) جودة المشروع مفتوح المصدر، وبالتالي أيضًا جودة المشروع البرمجي الداخلي المفتوح (InnerSource).

## فوائد

بالإضافة إلى سمات الجودة للبرمجيات مفتوحة المصدر، تم الإبلاغ عن الفوائد التالية:

### تطوير أكثر كفاءة وفعالية

   * وقت أسرع للوصول إلى السوق
   * انخفاض تكاليف التطوير

### التغلب على حدود الوحدة التنظيمية

   * تقاسم التكاليف والمخاطر بين الوحدات التنظيمية
   * التعاون عبر حدود الوحدة التنظيمية
   * تبادل المعلومات على مستوى البرنامج

### إعادة الاستخدام أكثر نجاحا

   * استخدام الكفاءات المفقودة لدى مقدمي المكونات
   * الاستقلال بين المستخدمين الجدد والمزودين
   * إعفاء مقدمي المكونات

### منتج برمجي أفضل

   * تحسين جودة الكود
   * مزيد من التطوير المبتكر

### استخدام أكثر مرونة للمطورين

   * نشر المطور بشكل مبسط
   * التعاون بين المطورين المنفصلين

### تحسين إدارة المعرفة

   * التعلم القائم على المجتمع
   * الانفتاح وتوافر المعرفة

### تحفيز الموظفين بشكل أكبر
## انتشار

ومن بين الشركات الأخرى المعروفة بتبني InnerSource:
* HP
* " الحلاقة الحمراء "
* شركة "فيليبز"
* "مُتَمَرّد"
* نوكيا
* شركة IBM
* الـ DTE
* روبرت بوش
* جوجل
* مايكروسوفت
* SAP
* تريد ميكرو
* (بايبال)
* العاصمة الأولى
* أدوك
* جهاز مسح السماء
* المكونات المكونة
* ت-موبايل
* سيمنس
* وول مارت

## العوامل الرئيسية لاعتماد InnerSource

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

### عوامل المنتج

* منتج البذور لجذب المجتمع
* أصحاب مصلحة متعددون لمجموعة متنوعة من المساهمات
* إمكانية التعديل لجذب المساهمين والمستخدمين

### عوامل العملية والأدوات

* الممارسات التي تدعم التنمية على طريقة "البازار"
* الممارسات التي تدعم ضمان الجودة "على طريقة البازار"
* توحيد الأدوات لتسهيل التعاون

### عوامل التنظيم والمجتمع

* التنسيق والقيادة لدعم ظهور نظام الجدارة الداخلية
* الشفافية لفتح المنظمة
* دعم الإدارة والتحفيز لإشراك الناس

## مراجع

* ↑ Capraro، Maximilian؛ Riehle، Dirk (1 ديسمبر 2016). "InnerSource Definition, Benefits, and Challenges". ACM Comput. Surv. ج. 49 ع. 4: 67:1–67:36. DOI:10.1145/2856821. ISSN:0360-0300. S2CID:5385511. مؤرشف من الأصل في 2023-06-20.
* ↑ Microsoft Internal Solorigate Investigation Update. مؤرشف من الأصل في 2021-01-01.
* ↑ Oram، Andy (2015). Getting Started with InnerSource. O’Reilly Media, Inc. ISBN:978-1-491-93758-7. مؤرشف من الأصل في 2020-05-31.
* ↑ Smith، Jared (2016). Using open source methods for internal software projects. O’Reilly Media, Inc. مؤرشف من الأصل في 2016-05-10.
* ↑ Archived at Ghostarchive and the Commit San Francisco 2020: Shucking Corporate Oysters-Kickstarting an Innersource Culture @ T-Mobile. يوتيوب. مؤرشف من الأصل في 2020-06-23. اطلع عليه بتاريخ 2024-11-08.{{استشهاد بوسائط مرئية ومسموعة}}: صيانة الاستشهاد: BOT: original URL status unknown (link): Commit San Francisco 2020: Shucking Corporate Oysters-Kickstarting an Innersource Culture @ T-Mobile. يوتيوب. مؤرشف من الأصل في 2023-06-20.
* ↑ "Watch: Creating an InnerSource Hub at Siemens". JFrog (بالإنجليزية الأمريكية). 28 Jul 2020. Archived from the original on 2024-08-04. Retrieved 2020-12-09.
* بوابة تقانة
* بوابة تقانة المعلومات
* بوابة علم الحاسوب