InnerSource هو كذبة - رد على المفاهيم الخاطئة الشائعة
عندما تبحث عن “InnerSource” على YouTube، فإن إحدى النتائج الأولى التي ستواجهها على الأرجح هي فيديو يدعي أن “InnerSource هو كذبة.”
(الرابط: https://youtube.com/shorts/53jEP3mPP3E)
تمثل وجهة النظر هذه فخاً نموذجياً يقع فيه العديد من الأشخاص عندما يتعلمون عن InnerSource لأول مرة.
أريد استخدام هذا الفيديو كدراسة حالة لشرح نوع الاستنتاجات المضللة التي يروج لها. هذا خطأ ارتكبته في الماضي أيضاً، وهو فخ يمكن أن يقع فيه بسهولة العديد من الأشخاص الذين لم يستكشفوا هذا المجال بعمق. لهذا السبب أريد فحص هذا بتأمل ذاتي ومساعدة الآخرين في العثور على الطريق الصحيح من خلال كشف هذه المزالق.
المفهوم الخاطئ الأول: “استخدم React حتى يتمكن الآخرون من المساهمة” #
دعني أولاً أفكك الحجة في هذه الحالة. يقترح الفيديو استخدام React للتطبيقات الداخلية “استخدم React لأن الأشخاص الآخرين يمكنهم المساهمة فيه.” نادراً ما يُسمع هذا النوع من التفكير في مناقشات InnerSource الفعلية.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
يمكن تفكيك هذه الحجة إلى ثلاث قضايا رئيسية:
- سوء فهم أساسي لما يعنيه InnerSource فعلاً
- اختيار المجال الخاطئ لتطبيق InnerSource
- الخلط بين منظور الفرد والفريق
ما يعنيه InnerSource فعلاً #
InnerSource يتعلق بممارسة مبادئ المصدر المفتوح داخل الشركة. إنه ليس مجرد “المساهمة” أو “تلقي المساهمات.”
معظم الأشخاص الذين يتفاعلون مع المصدر المفتوح هم مجرد “مستخدمين.” البعض مجرد مستهلكين، والبعض الآخر يقدم تقارير الأخطاء، وجزء صغير فقط يقدم pull requests فعلاً. InnerSource يطبق تعلم المصدر المفتوح داخلياً لإنشاء مؤسسات مفتوحة، قابلة للوصول على نطاق واسع، مع اتخاذ قرارات شفافة، وعلاقات فريق مبنية على الثقة من خلال الملكية والإرشاد. هذا ينشئ ثقافة الشفافية والتعاون.
هذا ما تعنيه “ممارسة المصدر المفتوح داخلياً” - إنه ليس مجرد “تلقي pull requests.” Pull requests هي مجرد نتيجة واحدة لهذه الثقافة، وليس الهدف الأساسي.
مجال أقل مثالية لتطبيق InnerSource #
القضية الثانية هي أن هذه الحجة تتكشف في مجال حيث يواجه InnerSource والمصدر المفتوح تحديات خاصة.
إذا كنت تريد “تلقي pull requests” أو “جعل العديد من الأشخاص يستخدمون كودك لتحسين الجودة”، فقد يكون ذلك محدوداً بطبيعة منتجك. من الواضح أن مشاركة “المكونات عالية التبعية” أو أدوات مستوى المنصة ستخلق قيمة أكثر من تطبيقات المستخدم النهائي. بينما يجب على الفرق المتوافقة مع التدفق أن تتبنى ممارسات المصدر المفتوح عندما تكون مفيدة، فإن ديناميكيات التعاون تختلف بشكل كبير.
في تجربتي في العمل مع الشركات المؤسسية، استخدام InnerSource للمبادرات على مستوى المشروع حيث المستخدمون النهائيون هم “غير مهندسين” يقدم تحديات فريدة. لماذا؟ لأن هذه المنتجات في النهاية تحتاج لخدمة احتياجات “المستخدمين النهائيين” أو “مستخدمي الأعمال” الذين قد يفتقرون لمهارات التطوير وقنوات التواصل المباشر مع فرق التطوير. هذا ينشئ متطلبات معقدة وفردية وأوقات انتظار تواصل أطول.
تطبيقات InnerSource تميل للعمل بشكل جيد نسبياً عندما تُطبق على المكتبات المشتركة، مكونات المنصة، أدوات التطوير، وكود البنية التحتية—المجالات حيث “المستخدمون” هم بشكل أساسي مطورون آخرون يمكنهم المساهمة بشكل مفيد والاستفادة من ممارسات التطوير التعاونية.
بينما تطبيق ممارسات InnerSource على التطبيقات المواجهة للمستخدم يمكن أن يجلب فوائد قيمة مثل الشفافية وتحسين تتبع المشاكل (مما يجعلها مجدية وحدها).
منظور الفرد مقابل الفريق #
القضية الثالثة تتعلق بما إذا كان “أنت” يشير إلى فرد أو فريق.
من المهم ملاحظة أن InnerSource ليس بالضرورة حول انتظار شخص ما للمساهمة في “مشروعك الشخصي” داخل الشركة. عندما يُطبق InnerSource، قد تكون هناك حالات حيث يساهم الأشخاص في مشاريع طُورت خلال وقت 20%، مثل شركات التكنولوجيا الكبيرة، لكن هذا ليس بالضرورة النهج السائد.
InnerSource يُقدم ويُحافظ عليه بشكل أساسي لأنه يولد عائد استثمار من خلال تقليل التكاليف، تجنب إعادة اختراع العجلة، خلق التآزر، ضمان الجودة، وإزالة الحمل الزائد للتواصل من اتخاذ القرارات الهرمية. هذا عادة ما يتضمن المكتبات الداخلية المشتركة، مكونات الميزة التنافسية الملكية، أو الأشياء ذات التبعيات العالية التي تكون متخصصة داخل المؤسسة. وهذه “الفوائد التجارية” عادة ما تتدفق عائدة إلى “عمليات الفريق” في معظم الحالات. في النهاية، كل شيء يتعلق بعائد الاستثمار للفرق والمؤسسات. إذا لم نفكر في الفرق، فسيمنعك شخص ما من المساهمة في المشاريع. تحتاج لتبرير عائد الاستثمار سواء كان قصير المدى أو طويل المدى.
ما هو فريد حول InnerSource هو أنه بشكل أساسي حول التعاون بين الفرق. هذا هو المكان الذي تنتهي فيه معظم التطبيقات في النهاية. إنه ليس بالضرورة أفراد يساهمون عشوائياً في مشاريع شخصية مريحة. عادة ما يُطبق من خلال علاقات الفريق المضيف والفريق الضيف، حيث تتماشى الفرق الضيفة مع الأجزاء التي تحتفظ بها الفرق المضيفة. معظم المؤسسات لديها موظفون بأدوار ومسؤوليات محددة، والتعاون يميل للحدوث داخل هذه الهياكل.
لذلك، InnerSource فعال بشكل خاص عندما تُؤسس العلاقات بين فرق المنصة والفرق المتوافقة مع التدفق (الفرق الضيفة والفرق المضيفة). الإبداع المشترك النشط بين الفرق المتوافقة مع التدفق أو الأفراد أكثر عدم يقين للنجاح بشكل طبيعي.
انتقاد كل InnerSource بناء على سيناريوهات من غير المرجح أن تعمل لا يحمل منطقاً.
المفهوم الخاطئ الثاني: “هذا لا يحدث أبداً في الشركات الحقيقية” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
في الواقع، هذا يحدث. دراسات الحالة تثبت ذلك. نقطة.
المفهوم الخاطئ الثالث: “99.69% من مشاريع InnerSource ستفشل” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
قد يكون هذا صحيحاً اعتماداً على كيفية تعريف “InnerSource.” كما ذُكر سابقاً، InnerSource ليس حول “تلقي مساهمات PR.”
ومع ذلك، هناك ثلاث نقاط مهمة للنظر فيها:
- InnerSource ينطبق خاصة على المكونات الاستراتيجية - إنه ليس مطلوباً لجميع المكونات
- الفوائد تمتد بما يتجاوز المساهمات النشطة
- المصدر المفتوح لديه نفس مشكلة “معدل الفشل”
InnerSource هو استراتيجية مؤسسية #
عندما يفكر الأشخاص في InnerSource، أحياناً يتخيلون أفكاراً جذرية مثل “مشاركة جميع الأكواد داخل المؤسسة” أو “الجميع يساهم في كل شيء.” قد يتصوروا مئات من المستودعات المشتركة داخل الشركة مع الجميع يتبادل المساهمات بنشاط. مثل كون المصدر المفتوح استراتيجية للشركات، InnerSource هو أيضاً استراتيجية مؤسسية مع أولويات. الشركات تشارك “ما يستحق المشاركة” أولاً.
لذلك، العدد الفعلي لقواعد الأكواد حيث يتدفق الكود بنشاط بين الفرق ويحدث تعاون نابض بالحياة عبر الفرق صغير نسبياً. قد يكون هذا فعلاً نسب مئوية من رقم واحد. ومع ذلك، حتى بدون تعاون نشط عبر الفرق، العديد من المشاريع يمكن أن تستفيد من كونها مفتوحة وشفافة. بهذا المعنى من InnerSource، المؤسسات يمكنها غالباً مشاركة القيمة عبر حالات أكثر بكثير.
بينما InnerSource يتضمن مساهمات فردية، فهو يركز بشكل أساسي على التعاون بين الفرق. لذلك، ما يُشارك من خلال InnerSource يميل لكونه متخصصاً نسبياً داخل المؤسسات، أو عناصر محددة الغرض مثل توزيعات Linux المتفرعة لاحتياجات خاصة. أو قد يكون ببساطة ثقافة تطوير شبيهة بالمصدر المفتوح، كما عندما تشارك GitHub كود Ruby on Rails عبر جميع الموظفين.
عندما نشترط هذه المناقشة النسبية على InnerSource الذي يتعاون بنشاط ويُحافظ عليه كمتطلبات مشتركة، قد تكون النسبة فعلاً منخفضة نسبياً. ومع ذلك، التعاونات الصغيرة مثل pull requests للوثائق أو تغييرات التكوين الطفيفة (إرسال patches صغيرة) بين الفرق الضيفة وفرق المنصة/المضيفة تحدث بشكل متكرر نسبياً. عندما تتضمن هذه التعاونات الدقيقة وفوائد الشفافية التي تمنع الجهود المكررة، هذه الأرقام تزيد بشكل كبير.
المصدر المفتوح لديه نفس “المشكلة” #
من ناحية أخرى، إذا عرفناه بهذه الطريقة، فإن المصدر المفتوح سيكون أيضاً “كذبة.” لأن “99.69% من مشاريع المصدر المفتوح ستفشل.” معظم الأكواد المنشورة كمصدر مفتوح لا تتلقى مساهمات. لكن لا أحد يقول “المصدر المفتوح كذبة” بسبب ذلك. الأشخاص يسعون للمصدر المفتوح لأن هناك فوائد بما يتجاوز تلقي المساهمات.
مرة أخرى، “تلقي المساهمات” ليست القيمة الوحيدة لـ InnerSource. ونفس الشيء ينطبق على قيمة المصدر المفتوح أيضاً
الفوائد الحقيقية للشفافية #
الحفاظ على الكود الداخلي مفتوحاً بدلاً من مخفياً - في GitHub، المهندسون المعماريون أو مهندسو الحلول في فريق الإيرادات قد يكونون قادرين على فحص الكود المصدري للعثور على معلومات ذات صلة، ربما العثور على تفاصيل قريبة جداً من طلبات العملاء، تسهيل محادثات الدعم بسلاسة أكبر، واستخراج معلومات أكثر دقة من المشاكل. أعيش في طوكيو، وأحياناً يكون أسرع أن أنظر فقط إلى كود Ruby للتحقق من التطبيق، أو أذهب إلى المشاكل للتحقق من خلفية التغييرات، بدلاً من انتظار فريق المنتج المتمركز في SF للاستيقاظ لسؤال أسئلة التطبيق حول التغييرات وخلفيتها.
باستخدام أمر git blame، يمكنك تحديد أصحاب المصلحة “الحقيقيين” للكود وطرح أسئلة حول خلفية القرارات.
غني عن القول، نفس الشيء ينطبق على فرق التطوير الأخرى. وجود معلومات متاحة بسهولة حول المكونات التي قد تخلق تبعيات يقلل بوضوح من الحمل الزائد للتواصل.
InnerSource يتعلق بممارسة مبادئ المصدر المفتوح داخلياً. InnerSource ليس فقط حول إرسال pull requests ذهاباً وإياباً - إنه حول ضمان الشفافية والحصول على فوائد من خلال التعاون بنمط المصدر المفتوح. هذه الفوائد تمتد بعيداً بما يتجاوز النسبة القليلة من المستودعات المحتفظ بها بنشاط إلى فوائد تطبيق ثقافية أوسع.
المفهوم الخاطئ الرابع: “ستتلقى اتصالاً عندما تغادر” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
الموارد أحياناً تبقى بدون صيانة، لكن هذا ليس انتقاداً مناسباً لـ InnerSource نفسه - إنه انتقاد لفشل تطبيق InnerSource بشكل صحيح. هذا ليس انتقاداً لـ InnerSource، بل انتقاد لنقص ثقافة الصيانة حيث لا أحد يحافظ على الكود. هذا ينتج عن فشل تطبيق InnerSource بشكل صحيح أو عدم النظر فيه على الإطلاق - نتيجة نقص الملكية.
تشبيه DevOps #
هذا انتقاد لفشل القيام بـ InnerSource، وليس انتقاداً لـ InnerSource نفسه. أحياناً هذا يخلط المنطق. لوضع هذا في مصطلحات DevOps: إنه مثل القول “الشركات تنتهي بتبني دورات مراجعة بطيئة لعدة أشهر أو تدقيقات، أو إضافة عمليات لقرارات الإصدار، لذا الإصدارات تصبح ربع سنوية أو مرتين فقط في السنة. لذلك DevOps، الذي يدعي تمكين الإصدارات السريعة، ليس جيداً.” هذا ليس لأن منهجية DevOps سيئة، بل ببساطة لأن “كانت هناك حالات حيث لم يمكن تطبيق DevOps.”
كسر عمليات الأعمال صعب للغاية، والعديد من الشركات قالت أن DevOps مستحيل. لكن حتى عندما اعتقد الأشخاص أنه مستحيل، كان هناك رواد شجعان عملوا بجد لتغيير الثقافة وحققوا DevOps. نفس الشيء يمكن أن يحدث مع InnerSource.
المفهوم الخاطئ الخامس: “يجب أن تملك كل شيء 100%” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource يعني التخلي عن ملكية الكود” خطأ. InnerSource فعلاً يتطلب من الفرق امتلاك الكود. هذا خطأ شائع. هذا مثل الأشخاص الذين يريدون التخلي عن مسؤولية الصيانة ويقولون “دعونا نجعله مصدر مفتوح.” هذا لا يعمل.
ملكية الفرد مقابل الفريق - هل InnerSource ملكية كود قوية؟ #
أولاً، هل هذا “أنت” فردي أو جمع؟ رغم أن الأفراد قد يُدرجوا كملف CODEOWNERS في المؤسسات، الفرق في النهاية تحمل مسؤولية الكود. سياقياً، من المحتمل أنه يتحدث عن ملكية الكود القوية. لكن هذا ليس جيداً عند النظر في الصيانة التنظيمية. لأن الموظفين قد يستقيلون.
InnerSource ليس ملكية كود قوية. كحد أدنى، عدة أشخاص يحتاجون لمشاركة المسؤولية. مع ذلك، أعترف أن ملكية الكود القوية قد تظهر على المدى القصير، وفي المراحل المبكرة من المشروع، الإرادة الفردية القوية قد تؤدي بشكل طبيعي لمثل هذه الترتيبات، لكن إذا كنت تريد تحقيق نجاح طويل المدى، من الضروري تفويض السلطة حتى تتمكن المؤسسة من التعامل مع الصيانة بشكل جماعي.
أنواع ملكية الفريق - هل InnerSource ملكية كود جماعية؟ #
هذا النوع من الحجج قد يشير أحياناً إلى الملكية الجماعية. في هذه الحالة، الحجة أيضاً تبدو وكأنها تقترح أن InnerSource يعني الملكية الجماعية، لكن هذا فعلاً مختلف. InnerSource ليس ملكية كود جماعية InnerSource يتضمن الفرق المضيفة تتعامل في النهاية مع الصيانة. InnerSource هو ملكية كود ضعيفة. لذا بينما مسؤولية الصيانة 100% صحيحة، القول “يجب أن تملك 100% و InnerSource مختلف” غير منطقي تماماً. هذا فعلاً رأي غير صحيح.
كما جادل Martin Fowler بشهرة حول ملكية الكود، جعل الجميع يملك الكود 100% (الملكية الجماعية) أحياناً ينشئ مواقف حيث لا أحد يتحمل المسؤولية. هذا مشكل جداً - المسؤولية تصبح غير واضحة والمشاريع تفشل في النهاية.
نموذج ملكية الكود الضعيفة #
في ملكية الكود الضعيفة، المحافظون موجودون، الفرق المضيفة تحافظ على المشاريع، وأجزاء محددة قد تجلب committers/محافظين موثوقين من فرق أخرى. شخص ما قد يساهم، شخص ما قد يحافظ، لكن ليس 100% بواسطة “أنت” أو “فريقك” - قد يكون مختلفاً تماماً. على سبيل المثال، 98% من الكود قد يكون مملوكاً من فريقك، بينما 2% قد يكون مملوكاً من فرق أخرى.
في هذه الحالة، تذكر أنه حتى لو تم تعيين أفراد كمالكي كود في المؤسسات، الفرق في النهاية تحمل مسؤولية الكود. الفرق يجب أن تملكه، ولا تنس هذه النقطة المهمة.
المفهوم الخاطئ السادس: “شخص ما سيرمي عليك 7000 سطر” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
ظهور pull requests بـ 7000 سطر فجأة هو نفسه فشل في تقديم ثقافة InnerSource - إنه ليس شيئاً يحدث بفعل InnerSource. هذه الحالة قد تقلق من أن تقديم InnerSource يجعل مثل هذا التعاون يحدث، لكن هذا خطأ تماماً.
المشكلة الحقيقية #
هذه الحجة تمثل فشل تطبيق ثقافة InnerSource وممارسات التعاون، وليس InnerSource نفسه. تطبيقات 7000 سطر هي حالات محدودة جداً. هذا يمثل فشل ثقافة التعاون حيث 7000 سطر تُقدم كـ pull requests فجأة بدون أي إشعار - المؤسسة يجب أن تصلح مشكلة الثقافة الأساسية هذه، والتي هي ما قبل InnerSource.
إذا كنت تريد منع هذا، هناك حل. عزز ثقافة InnerSource داخل مؤسستك :)
الواقع: ما هو InnerSource فعلاً #
InnerSource هو تطبيق ثقافي - استخدام ممارسات التعاون مفتوحة المصدر للاستمتاع بفوائد مختلفة يتلقاها المصدر المفتوح من خلال التعاون. الهدف النهائي لـ InnerSource ليس فقط تلقي المساهمات (pull requests)، بل يتضمن طلبات الميزات من خلال المشاكل، تنسيق الدعم، وفوائد أخرى مختلفة، بالإضافة إلى الشفافية في اتخاذ القرارات والترويج الثقافي العملي.
لذلك، أرفض بشكل قاطع الادعاء أن “تطبيق أفضل ممارسات InnerSource للحصول على pull requests هو كذبة.”
فهم واقع المساهمة #
“لا أحد أبداً سيساهم”
في تعاون المصدر المفتوح، المساهمون فعلاً جزء صغير. من 1000 مستخدم، ربما الغالبية العظمى مجرد مستخدمين، 20 قد يقدموا مشاكل أو طلبات ميزات، 5 قد يرسلوا pull requests، وربما واحد فقط يصبح محافظاً.
مرة أخرى، أفضل ممارسات InnerSource لن تجعل كل 1000 شخص يساهمون. InnerSource يساعد في حث مثل هذا التعاون، لكنه في النهاية يهدف لكسر صوامع المؤسسة، تحسين التعاون المعاق بالقيود التنظيمية التقليدية، تقليل أوقات الانتظار من صوامع المعلومات، وتحسين تخصيص الموارد التنظيمية باستخدام ممارسات المصدر المفتوح.
الخلاصة #
بينما الحجج في هذه الحالة تلمس بعض التحديات الحقيقية، فهي مبنية على سوء فهم شائع يواجهه العديد من الأشخاص عندما يتعلمون عن InnerSource لأول مرة. هذه مزالق معروفة في المجتمع، ومن المفهوم كيف يمكن لشخص ما الوصول لهذه الاستنتاجات بدون استكشاف أعمق للمجال.
البصيرة الرئيسية هي أن InnerSource ليس حول إجبار ممارسات المصدر المفتوح في إطار صارم. بدلاً من ذلك، إنه حول العودة للسؤال الأساسي: ماذا يمكننا تعلمه من المصدر المفتوح؟ بفحص المصدر المفتوح من خلال عدسة أوسع، يمكننا تكييف هذه المبادئ داخلياً بشكل أفضل.
يمكنك الانضمام لهذه المحادثة وجلب وجهات نظر جديدة. سواء كنت تريد البناء على هذه المناقشة، استكشاف تفاصيل تطبيق أكثر تحديداً، أو حتى تحدي هذه الحجج بالكامل - جميع النهج مرحب بها. ما يهم أكثر هو الحفاظ على ذلك المنظور الواسع حول تعلم المصدر المفتوح وكيف يترجم لسياقات المؤسسة الداخلية.
للحصول على معلومات شاملة حول InnerSource، أوصي بالاطلاع على مؤسسة InnerSource Commons. إنهم يرحبون بوجهات نظر متنوعة وحوار مستمر حول كيف يمكن لمبادئ المصدر المفتوح خلق قيمة داخل المؤسسات.
