InnerSource ایک جھوٹ ہے - عام غلط فہمیوں کا جواب
جب آپ YouTube پر “InnerSource” تلاش کرتے ہیں، تو آپ کو سب سے پہلے جو نتائج ملیں گے ان میں سے ایک ویڈیو یہ دعویٰ کرتی ہے کہ “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 حاصل کرنا” چاہتے ہیں یا “بہت سے لوگوں کو اپنا کوڈ استعمال کرنے دینا چاہتے ہیں تاکہ معیار بہتر ہو”، تو یہ آپ کے پروڈکٹ کی نوعیت سے محدود ہو سکتا ہے۔ یہ واضح ہے کہ “high-dependency components” یا پلیٹ فارم لیول ٹولز کا اشتراک end-user applications سے زیادہ قدر پیدا کرے گا۔ جبکہ stream-aligned teams کو اب بھی اوپن سورس practices اپنانی چاہیئں جب فائدہ مند ہو، لیکن تعاون کی dynamics نمایاں طور پر مختلف ہیں۔
انٹرپرائز کمپنیوں کے ساتھ کام کرنے کے میرے تجربے میں، پروجیکٹ لیول کی پہل کاریوں کے لیے InnerSource استعمال کرنا جہاں آخری صارف “غیر انجینئرز” ہیں، منفرد چیلنجز پیش کرتا ہے۔ کیوں؟ کیونکہ بالآخر، ان پروڈکٹس کو “آخری صارفین” یا “کاروباری صارفین” کی ضروریات پوری کرنی ہیں جن کے پاس ترقیاتی مہارت اور ڈیولپمنٹ ٹیموں کے ساتھ براہ راست رابطے کے چینلز نہیں ہو سکتے۔ یہ پیچیدہ، انفرادی ضروریات اور طویل رابطے کی lead times پیدا کرتا ہے۔
InnerSource کے نفاذ shared libraries، platform components، development tools، اور infrastructure code پر لاگو ہونے پر نسبتاً اچھا کام کرتے ہیں—وہ علاقے جہاں “صارف” بنیادی طور پر دوسرے ڈیولپرز ہیں جو تعاونی ترقیاتی practices میں معنی خیز تعاون کر سکتے ہیں اور ان سے فائدہ اٹھا سکتے ہیں۔
جبکہ user-facing applications پر InnerSource practices کا اطلاق قیمتی فوائد لا سکتا ہے جیسے شفافیت اور بہتر issue tracking (جو اکیلے ہی اسے قابل قدر بناتا ہے)۔
انفرادی بمقابلہ ٹیم کا نقطہ نظر #
تیسرا مسئلہ اس بات سے متعلق ہے کہ آیا “آپ” سے مراد کوئی فرد ہے یا ٹیم۔
یہ نوٹ کرنا اہم ہے کہ InnerSource ضروری نہیں کہ کمپنی کے اندر کسی کے “ذاتی پروجیکٹ” میں تعاون کا انتظار کرنے کے بارے میں ہو۔ جب InnerSource لاگو کیا جاتا ہے، تو ایسے کیسز ہو سکتے ہیں جہاں لوگ 20% وقت کے دوران تیار کیے گئے پروجیکٹس میں تعاون کریں، جیسا کہ بڑی ٹیک فرموں میں ہوتا ہے، لیکن یہ ضروری نہیں کہ mainstream approach ہو۔
InnerSource بنیادی طور پر اس لیے متعارف اور برقرار رکھا جاتا ہے کہ یہ cost reduction، پہیے کو دوبارہ ایجاد کرنے سے بچنے، synergies پیدا کرنے، quality assurance، اور hierarchical فیصلہ سازی سے communication overhead کو ہٹانے کے ذریعے ROI پیدا کرتا ہے۔ اس میں عام طور پر shared internal libraries، proprietary competitive advantage components، یا انٹرپرائز کے اندر niche لیکن high dependencies والی چیزیں شامل ہیں۔ اور یہ “کاروباری فوائد” عام طور پر زیادہ تر کیسز میں “ٹیم کی operations” میں واپس آتے ہیں۔ بالآخر، یہ سب ٹیموں اور تنظیموں کے لیے ROI کے بارے میں ہے۔ اگر ہم ٹیموں کے بارے میں نہیں سوچتے، تو کوئی آپ کو پروجیکٹس میں تعاون کرنے سے روک دے گا۔ آپ کو اپنے ROI کا جواز پیش کرنا ہوگا چاہے وہ قلیل مدتی ہو یا طویل مدتی۔
InnerSource کے بارے میں جو چیز منفرد ہے وہ یہ ہے کہ یہ بنیادی طور پر ٹیم سے ٹیم کے تعاون کے بارے میں ہے۔ یہیں زیادہ تر implementations بالآخر پہنچتی ہیں۔ یہ ضروری نہیں کہ افراد بے ترتیب طریقے سے آسان ذاتی پروجیکٹس میں تعاون کریں۔ یہ عام طور پر host team اور guest team کے رشتوں کے ذریعے نافذ کیا جاتا ہے، جہاں guest teams host teams کے برقرار رکھے گئے حصوں کے ساتھ ride along کرتی ہیں۔ زیادہ تر انٹرپرائزز میں متعین کردار اور ذمہ داریوں والے ملازمین ہیں، اور تعاون عام طور پر ان ڈھانچوں کے اندر ہوتا ہے۔
لہذا، InnerSource خاص طور پر اس وقت مؤثر ہے جب platform teams اور stream-aligned teams (guest teams اور host teams) کے درمیان رشتے قائم ہوں۔ Stream-aligned teams یا افراد کے درمیان فعال co-creation کی کامیابی فطری طور پر زیادہ غیر یقینی ہے۔
ایسے scenarios کی بنیاد پر تمام 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 contributions حاصل کرنے” کے بارے میں نہیں ہے۔
تاہم، تین اہم نکات پر غور کرنا ضروری ہے:
- InnerSource خاص طور پر strategic components پر لاگو ہوتا ہے - یہ تمام components کے لیے ضروری نہیں
- فوائد فعال تعاون سے کہیں زیادہ ہیں
- اوپن سورس میں بھی یہی “failure rate” کا مسئلہ ہے
InnerSource ایک کارپوریٹ حکمت عملی ہے #
جب لوگ InnerSource کے بارے میں سوچتے ہیں، تو وہ کبھی کبھی radical خیالات کا تصور کرتے ہیں جیسے “انٹرپرائز کے اندر تمام کوڈ کا اشتراک” یا “ہر کوئی ہر چیز میں تعاون کرے۔” وہ کمپنی کے اندر سینکڑوں shared repositories کا تصور کر سکتے ہیں جہاں ہر کوئی فعال طور پر تعاون کا تبادلہ کر رہا ہو۔ جیسے اوپن سورس کمپنیوں کے لیے ایک حکمت عملی ہے، InnerSource بھی ترجیحات کے ساتھ ایک کارپوریٹ حکمت عملی ہے۔ کمپنیاں پہلے “جو اشتراک کے قابل ہے” اس کا اشتراک کرتی ہیں۔
لہذا، codebases کی اصل تعداد جہاں کوڈ فعال طور پر ٹیموں کے درمیان بہتا ہے اور متحرک cross-team collaboration ہوتا ہے، نسبتاً کم ہے۔ یہ واقعی single-digit percentages ہو سکتے ہیں۔ تاہم، فعال cross-team collaboration کے بغیر بھی، بہت سے پروجیکٹس کھلے اور شفاف ہونے سے فائدہ اٹھا سکتے ہیں۔ InnerSource کے اس معنی میں، انٹرپرائزز اکثر کہیں زیادہ کیسز میں قدر کا اشتراک کر سکتے ہیں۔
جبکہ InnerSource میں انفرادی تعاون شامل ہے، یہ بنیادی طور پر ٹیم سے ٹیم کے تعاون پر مرکوز ہے۔ لہذا، InnerSource کے ذریعے جو کچھ شیئر کیا جاتا ہے وہ انٹرپرائزز کے اندر نسبتاً niche ہوتا ہے، یا خاص ضروریات کے لیے purpose-specific items جیسے forked Linux distributions۔ یا یہ صرف اوپن سورس جیسی development culture ہو سکتی ہے، جیسا کہ جب GitHub تمام ملازمین میں Ruby on Rails کوڈ کا اشتراک کرتا ہے۔
جب ہم اس percentage بحث کو InnerSource پر condition کرتے ہیں جو فعال طور پر تعاون کرتا ہے اور common requirements کے طور پر برقرار رکھا جاتا ہے، تو percentage واقعی نسبتاً کم ہو سکتا ہے۔ تاہم، چھوٹے تعاون جیسے documentation pull requests یا minor configuration changes (چھوٹے patches بھیجنا) guest teams اور platform/host teams کے درمیان نسبتاً اکثر ہوتے ہیں۔ جب آپ ان micro-collaborations اور transparency benefits کو شامل کرتے ہیں جو duplicate efforts کو روکتے ہیں، تو یہ نمبرز نمایاں طور پر بڑھ جاتے ہیں۔
اوپن سورس میں بھی یہی “مسئلہ” ہے #
دوسری طرف، اگر ہم اسے اس طرح define کریں، تو اوپن سورس بھی ایک “جھوٹ” ہوگا۔ کیونکہ “99.69% اوپن سورس پروجیکٹس ناکام ہوں گے۔” اوپن سورس کے طور پر شائع کیے گئے زیادہ تر کوڈ کو contributions نہیں ملتے۔ لیکن کوئی بھی اس وجہ سے “اوپن سورس ایک جھوٹ ہے” نہیں کہتا۔ لوگ اوپن سورس کا پیچھا اس لیے کرتے ہیں کہ contributions حاصل کرنے کے علاوہ بھی فوائد ہیں۔
دوبارہ، “تعاون حاصل کرنا” InnerSource کی واحد قدر نہیں ہے۔ اور یہی بات اوپن سورس کی قدر کے لیے بھی درست ہے۔
شفافیت کے حقیقی فوائد #
اندرونی کوڈ کو چھپانے کے بجائے کھلا رکھنا - GitHub میں، revenue team کے architects یا solution engineers source code کا جائزہ لے کر متعلقہ معلومات تلاش کر سکتے ہیں، ممکنہ طور پر customer requests کے بہت قریب کی تفصیلات تلاش کر سکتے ہیں، smoother support conversations کی سہولت فراہم کر سکتے ہیں، اور issues سے زیادہ درست معلومات نکال سکتے ہیں۔ میں Tokyo میں رہتا ہوں، اور کبھی کبھی changes اور ان کی background کے بارے میں implementation کے سوالات پوچھنے کے لیے SF-based product team کے جاگنے کا انتظار کرنے کے بجائے صرف Ruby کوڈ دیکھ کر implementation چیک کرنا، یا issues میں جا کر changes کی background چیک کرنا تیز ہوتا ہے۔
git blame کمانڈ استعمال کرتے ہوئے، آپ کوڈ کے “حقیقی” stakeholders کی شناخت کر سکتے ہیں اور فیصلوں کی background کے بارے میں سوالات پوچھ سکتے ہیں۔
بے شک، یہی بات دوسری development teams پر بھی لاگو ہوتی ہے۔ ایسے components کے بارے میں معلومات کا آسانی سے دستیاب ہونا جو dependencies پیدا کر سکتے ہیں، واضح طور پر communication overhead کو کم کرتا ہے۔
InnerSource اوپن سورس اصولوں کو اندرونی طور پر عملی جامہ پہنانے کے بارے میں ہے۔ InnerSource صرف pull requests کو آگے پیچھے بھیجنے کے بارے میں نہیں ہے - یہ شفافیت کو یقینی بنانے اور اوپن سورس طرز کے تعاون کے ذریعے فوائد حاصل کرنے کے بارے میں ہے۔ یہ فوائد فعال طور پر برقرار رکھے جانے والے repositories کے چند فیصد سے کہیں زیادہ وسیع cultural implementation benefits تک پھیلے ہوئے ہیں۔
چوتھی غلط فہمی: “جب آپ چھوڑیں گے تو آپ کو واپس بلایا جائے گا” #
“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”
Resources کبھی کبھی unmaintained رہ جاتے ہیں، لیکن یہ خود InnerSource کی مناسب تنقید نہیں ہے - یہ InnerSource کو صحیح طریقے سے نافذ کرنے میں ناکامی کی تنقید ہے۔ یہ InnerSource کی تنقید نہیں ہے، بلکہ maintenance culture کی کمی کی تنقید ہے جہاں کوئی کوڈ کو maintain نہیں کرتا۔ یہ InnerSource کو صحیح طریقے سے نافذ کرنے میں ناکامی یا اس پر بالکل غور نہ کرنے کا نتیجہ ہے - ownership کی کمی کا نتیجہ۔
DevOps کی مثال #
یہ InnerSource کرنے میں ناکامی کی تنقید ہے، خود InnerSource کی تنقید نہیں۔ کبھی کبھی یہ logic کو confuse کر دیتا ہے۔ اسے DevOps کی اصطلاحوں میں ڈالنے کے لیے: یہ کہنے کی طرح ہے کہ “کمپنیاں کئی مہینوں کے slow review cycles یا audits اپنانے پر مجبور ہو جاتی ہیں، یا release decisions کے لیے processes شامل کرتی ہیں، تو releases quarterly یا سال میں صرف دو بار ہو جاتی ہیں۔ لہذا DevOps، جو fast releases کو enable کرنے کا دعویٰ کرتا ہے، اچھا نہیں ہے۔” یہ اس لیے نہیں کہ DevOps methodology خراب ہے، بلکہ صرف اس لیے کہ “ایسے کیسز تھے جہاں DevOps کو implement نہیں کیا جا سکا۔”
کاروباری processes کو توڑنا انتہائی مشکل ہے، اور بہت سی کمپنیوں نے کہا کہ DevOps ناممکن ہے۔ لیکن جب لوگوں نے سوچا کہ یہ ناممکن ہے، تب بھی بہادر pioneers تھے جنہوں نے culture تبدیل کرنے کے لیے سخت محنت کی اور DevOps حاصل کیا۔ InnerSource کے ساتھ بھی یہی ہو سکتا ہے۔
پانچویں غلط فہمی: “آپ کو ہر چیز کا 100% مالک ہونا چاہیے” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource کا مطلب code ownership کو ترک کرنا ہے” غلط ہے۔ InnerSource دراصل ٹیموں سے کوڈ کا مالک ہونے کا تقاضا کرتا ہے۔ یہ ایک عام غلطی ہے۔ یہ ان لوگوں کی طرح ہے جو maintenance کی ذمہ داری چھوڑنا چاہتے ہیں اور کہتے ہیں “آئیے اسے اوپن سورس بنا دیتے ہیں۔” یہ کام نہیں کرتا۔
انفرادی بمقابلہ ٹیم کی ملکیت - کیا InnerSource مضبوط کوڈ ملکیت ہے؟ #
پہلے، یہ “آپ” انفرادی ہے یا جمع؟ اگرچہ تنظیموں میں افراد کو CODEOWNERS فائل میں listed کیا جا سکتا ہے، لیکن ٹیمیں بالآخر کوڈ کی ذمہ داری رکھتی ہیں۔ سیاق و سباق کے لحاظ سے، یہ ممکنہ طور پر Strong Code Ownership کے بارے میں بات کر رہا ہے۔ لیکن یہ تنظیمی maintenance کے لحاظ سے اچھا نہیں ہے۔ کیونکہ ملازمین چھوڑ سکتے ہیں۔
InnerSource Strong Code Ownership نہیں ہے۔ کم سے کم، متعدد لوگوں کو ذمہ داری شیئر کرنی ہوگی۔ یہ کہنے کے ساتھ، میں تسلیم کرتا ہوں کہ Strong Code Ownership قلیل مدت میں ابھر سکتی ہے، اور پروجیکٹ کے ابتدائی مراحل میں، مضبوط انفرادی will فطری طور پر ایسے انتظامات کا باعث بن سکتی ہے، لیکن اگر آپ طویل مدتی کامیابی حاصل کرنا چاہتے ہیں، تو اختیارات کو delegate کرنا ضروری ہے تاکہ تنظیم اجتماعی طور پر maintenance کو handle کر سکے۔
ٹیم کی ملکیت کی اقسام - کیا InnerSource اجتماعی کوڈ ملکیت ہے؟ #
اس قسم کی دلیل کبھی کبھی Collective Ownership کا حوالہ دے سکتی ہے۔ اس کیس میں، دلیل یہ بھی suggest کرتی ہے کہ InnerSource کا مطلب collective ownership ہے، لیکن یہ دراصل مختلف ہے۔ InnerSource Collective Code Ownership نہیں ہے InnerSource میں host teams بالآخر maintenance handle کرتی ہیں۔ InnerSource Weak Code Ownership ہے۔ تو جبکہ maintenance کی ذمہ داری 100% درست ہے، یہ کہنا کہ “آپ کو 100% own کرنا چاہیے اور InnerSource مختلف ہے” بالکل غیر منطقی ہے۔ یہ دراصل ایک غلط رائے ہے۔
جیسا کہ Martin Fowler نے code ownership کے بارے میں مشہور طور پر دلیل دی، ہر کسی کو کوڈ کا 100% مالک بنانا (collective ownership) کبھی کبھی ایسے حالات پیدا کرتا ہے جہاں کوئی ذمہ داری نہیں لیتا۔ یہ بہت problematic ہے - ذمہ داری unclear ہو جاتی ہے اور پروجیکٹس بالآخر ناکام ہو جاتے ہیں۔
Weak Code Ownership Model #
Weak Code Ownership میں، maintainers موجود ہیں، host teams پروجیکٹس کو maintain کرتی ہیں، اور مخصوص حصے دوسری ٹیموں سے trusted committers/maintainers لا سکتے ہیں۔ کوئی contribute کر سکتا ہے، کوئی maintain کر سکتا ہے، لیکن “آپ” یا “آپ کی ٹیم” کی طرف سے 100% نہیں - یہ کافی مختلف ہو سکتا ہے۔ مثال کے طور پر، 98% کوڈ آپ کی ٹیم کا ہو سکتا ہے، جبکہ 2% دوسری ٹیموں کا ہو سکتا ہے۔
اس کیس میں، یاد رکھیں کہ اگرچہ تنظیموں میں افراد کو code owners کے طور پر assign کیا جاتا ہے، ٹیمیں بالآخر کوڈ کی ذمہ داری رکھتی ہیں۔ ٹیموں کو اس کا مالک ہونا چاہیے، اور اس اہم نکتے کو نہ بھولیں۔
چھٹی غلط فہمی: “کوئی آپ پر 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
7000-line pull requests کا اچانک ظاہر ہونا خود InnerSource culture متعارف کرانے میں ناکامی ہے - یہ کوئی ایسی چیز نہیں جو InnerSource کرنے سے ہوتی ہے۔ یہ کیس اس بات کی فکر کر سکتا ہے کہ InnerSource متعارف کرانے سے ایسا تعاون ہوتا ہے، لیکن یہ بالکل غلط ہے۔
اصل مسئلہ #
یہ دلیل InnerSource culture اور collaborative practices کو نافذ کرنے میں ناکامی کی نمائندگی کرتی ہے، خود InnerSource کی نہیں۔ 7000-line implementations بہت محدود کیسز ہیں۔ یہ collaboration culture کی ناکامی کی نمائندگی کرتا ہے جہاں 7000 لائنز بغیر کسی اطلاع کے اچانک pull requests کے طور پر submit کی جاتی ہیں - تنظیم کو اس بنیادی cultural مسئلے کو ٹھیک کرنا چاہیے، جو pre-InnerSource ہے۔
اگر آپ اس سے بچنا چاہتے ہیں، تو حل موجود ہے۔ اپنی تنظیم کے اندر InnerSource culture کو فروغ دیں :)
حقیقت: InnerSource دراصل کیا ہے #
InnerSource cultural implementation ہے - اوپن سورس collaboration practices استعمال کرنا تاکہ مختلف فوائد حاصل کیے جا سکیں جو اوپن سورس کو collaboration کے ذریعے حاصل ہوتے ہیں۔ InnerSource کا حتمی مقصد صرف contributions (pull requests) حاصل کرنا نہیں ہے، بلکہ اس میں issues کے ذریعے feature requests، support coordination، اور مختلف دوسرے فوائد، نیز فیصلہ سازی میں شفافیت اور عملی cultural promotion شامل ہے۔
لہذا، میں اس دعوے کو قطعی طور پر مسترد کرتا ہوں کہ “pull requests حاصل کرنے کے لیے InnerSource best practices کو نافذ کرنا ایک جھوٹ ہے۔”
Contribution کی حقیقت کو سمجھنا #
“Nobody ever is going to contribute”
اوپن سورس collaboration میں، contributors واقعی ایک چھوٹا حصہ ہیں۔ 1000 صارفین میں سے، شاید زیادہ تر صرف users ہیں، 20 issues یا feature requests submit کر سکتے ہیں، 5 pull requests بھیج سکتے ہیں، اور شاید صرف ایک maintainer بنتا ہے۔
دوبارہ، InnerSource best practices تمام 1000 لوگوں کو contribute نہیں کرائیں گے۔ InnerSource ایسے collaboration کو induce کرنے میں مدد کرتا ہے، لیکن بالآخر اس کا مقصد enterprise silos کو توڑنا، روایتی تنظیمی constraints سے رکاوٹ والے collaboration کو بہتر بنانا، information silos سے lead times کم کرنا، اور اوپن سورس practices استعمال کرتے ہوئے تنظیمی resource allocation کو optimize کرنا ہے۔
نتیجہ #
جبکہ اس کیس میں دلائل کچھ حقیقی چیلنجز کو چھوتے ہیں، وہ عام غلط فہمیوں پر مبنی ہیں جن کا سامنا بہت سے لوگوں کو اس وقت ہوتا ہے جب وہ پہلی بار InnerSource کے بارے میں سیکھتے ہیں۔ یہ community میں معروف pitfalls ہیں، اور یہ قابل فہم ہے کہ کوئی شخص اس شعبے کی گہری تلاش کے بغیر ان نتائج تک کیسے پہنچ سکتا ہے۔
اہم insight یہ ہے کہ InnerSource اوپن سورس practices کو ایک سخت framework میں زبردستی ڈالنے کے بارے میں نہیں ہے۔ اس کے بجائے، یہ بنیادی سوال پر واپس جانے کے بارے میں ہے: ہم اوپن سورس سے کیا سیکھ سکتے ہیں؟ اوپن سورس کو وسیع تر lens کے ذریعے دیکھ کر، ہم ان اصولوں کو اندرونی طور پر بہتر طریقے سے adapt کر سکتے ہیں۔
آپ اس بات چیت میں شامل ہو سکتے ہیں اور تازہ نقطہ نظر لا سکتے ہیں۔ چاہے آپ اس بحث پر آگے بڑھنا چاہتے ہوں، زیادہ مخصوص implementation کی تفصیلات دیکھنا چاہتے ہوں، یا یہاں تک کہ ان دلائل کو مکمل طور پر challenge کرنا چاہتے ہوں - تمام approaches کا خیرمقدم ہے۔ سب سے اہم بات یہ ہے کہ اوپن سورس learnings پر اس وسیع نقطہ نظر کو برقرار رکھا جائے اور یہ کہ وہ اندرونی تنظیمی contexts میں کیسے translate ہوتے ہیں۔
InnerSource کے بارے میں جامع معلومات کے لیے، میں InnerSource Commons Foundation کو check کرنے کی سفارش کرتا ہوں۔ وہ متنوع viewpoints اور اس بارے میں جاری dialogue کا خیرمقدم کرتے ہیں کہ اوپن سورس اصول تنظیموں کے اندر کیسے قدر پیدا کر سکتے ہیں۔
