10.18 اوپن سورس پروگرام آفس (OSPO) اور اپ اسٹریم شراکت

جائزہ اور محرکات

آپ کا ادارہ پہلے ہی اوپن سورس سافٹ ویئر پر چلتا ہے: آپریٹنگ سسٹمز، زبانیں، ڈیٹا بیس، اور لائبریریاں جو آپ کی پروڈکٹ اٹھاتی ہیں زیادہ تر ان لوگوں کی لکھی ہیں جو آپ کے لیے کام نہیں کرتے۔ باب 10.3 خریداری اور لائسنس کی تعمیل کا احاطہ کرتا ہے، اور باب 10.12 کھلے بمقابلہ بند کے فیصلے کا۔ یہ باب اس فنکشن کے بارے میں ہے جو یہ سب مربوط کرتا ہے: اوپن سورس پروگرام آفس (OSPO)، وہ ٹیم جو اس کی مالک ہے کہ کمپنی اوپن سورس کیسے استعمال کرتی، اس میں حصہ ڈالتی، اور جاری کرتی ہے۔ OSPO اس تعلق کا مرکز ثقل ہے جو ورنہ ہر اس انجینئر میں بکھرا ہے جو import ٹائپ کرتا ہے۔

زیادہ تر ادارے ایک وقت میں ایک انحصار کے ساتھ اوپن سورس میں داخل ہوتے ہیں، پھر جمع شدہ نمائش ایک ساتھ دریافت کرتے ہیں: حصول کی due diligence کے دوران لائسنس کا سوال، ایک تھکا ہوا واحد maintainer والی نازک لائبریری، اس کوڈ میں سیکیورٹی advisory جسے بھیجنے کا کسی کو علم نہ تھا۔ OSPO اس افراتفری کو منظم صلاحیت میں بدلتا ہے۔ یہ استعمال کی پالیسی طے کرتا ہے جو روکنے کی بجائے ممکن بنائے، فیصلہ کرتا ہے کہ اپ اسٹریم شراکت کب کاروبار کی خدمت کرتی ہے، آپ کے جاری کردہ پراجیکٹس کی نگرانی کرتا ہے، اور InnerSource کے ذریعے کمپنی کے اندر کھلا تعاون لاگو کرتا ہے۔ یہ اسٹریٹجک فنکشن ہے، آپ کی سافٹ ویئر انجینئرنگ کی اقدار (باب 1.1) سے جڑا، تعمیل کا خانہ نہیں۔

انٹرپرائز کے لیے محرک پیمانہ ہے: ہزاروں انحصار، دائرہ ہائے اختیار میں برآمد اور لائسنس کی ذمہ داریاں، اور سینکڑوں انجینئر جو روزانہ چھوٹے اوپن سورس فیصلے کرتے ہیں۔ ایک دفتر اس پھیلاؤ کو ریڑھ دیتا ہے۔ حکومت کے لیے محرک پالیسی اور عوامی اعتماد ہے۔ “ڈیفالٹ طور پر اوپن سورس” اور “عوامی پیسہ، عوامی کوڈ” تیزی سے قانون بن رہے ہیں، اس لیے عوامی اداروں کو کوئی ایسا چاہیے جو کوڈ محفوظ طریقے سے شائع کرے، ایجنسیوں میں دوبارہ استعمال کرے، اور فروخت کنندگان کو کھلے معیارات کا پابند کرے۔ دونوں ترتیبوں میں OSPO نادیدہ، بغیر قیمت خطرے کو دانستہ، بجٹ شدہ کام میں بدل کر اپنی ادائیگی خود کرتا ہے۔

بنیادی اصول

اوپن سورس دو طرفہ تعلق ہے، مفت گودام نہیں۔ آپ استعمال کرتے ہیں، حصہ ڈالتے ہیں، اور جاری کرتے ہیں، اور OSPO تینوں کا مالک ہے۔
شراکت حکمت عملی ہے، خیرات نہیں۔ اپ اسٹریم کرنا نجی patches اٹھانے کی لاگت گھٹاتا اور اثر خریدتا ہے۔
تیز راستہ ممکن بنائیں، دروازے پر پہرہ نہ دیں۔ کوڈ کاپی کرنے سے سست پالیسی نظر انداز ہوگی، اس لیے مطابق راستے کو تیز ترین بنائیں۔
جن maintainers پر آپ منحصر ہیں انہیں فنڈ کریں۔ مشترکہ خود کفیل نہیں، اور آپ کی سب سے نازک لائبریری کا ایک بلا معاوضہ مصنف ہو سکتا ہے۔
جو جاری کریں اس کی نگرانی کریں، یا جاری نہ کریں۔ متروک پراجیکٹ آپ کی ساکھ کو کسی بھی پراجیکٹ کے نہ ہونے سے زیادہ نقصان پہنچاتا ہے۔
شمولیت کو ناپیں تاکہ بہتر کر سکیں۔ شراکتیں، انحصار کی صحت، اور منظوری کا وقت گنیں، اخباری اعلانات نہیں۔
حکومت میں، ڈیفالٹ کھلا رکھیں اور ڈیفالٹ شائع کریں۔ کھلا پن معمول ہے؛ بندش دستاویزی استثنا ہے۔

سفارشات

اپنی حقیقت کے مطابق OSPO کھڑا کریں

شروع کرنے کو آپ کو بڑی ٹیم نہیں چاہیے۔ اسٹارٹ اپ میں OSPO ایک انجینئر ہو سکتا ہے جس کا تحریری مینڈیٹ ہو اور ہفتے میں چند گھنٹے۔ انٹرپرائز میں یہ چھوٹا مرکزی گروپ ہے جس کے ساتھ پروڈکٹ ٹیموں میں پیوست champions کا وفاقی نیٹ ورک ہے۔ سائز جو بھی ہو، اسے چار ذمہ داریاں ڈھانپنے والا واضح چارٹر دیں: استعمال کی پالیسی اور تعمیل، اپ اسٹریم شراکت، اپنے پراجیکٹس جاری کرنا اور ان کی نگرانی، اور کمیونٹی اور فنڈنگ کے تعلقات۔ اسے وہاں رکھیں جہاں وہ انجینئرنگ اور قانونی دونوں دیکھ سکے، اکثر CTO یا انجینئرنگ کے VP کو رپورٹ کرتے ہوئے قانونی اور سیکیورٹی سے ڈاٹڈ لائن کے ساتھ۔ ناکامی کا طریقہ وہ OSPO ہے جو مکمل طور پر قانونی کے اندر رہتا ہے اور رکاوٹ بن جاتا ہے؛ حل اسے ship کرنے والے انجینئروں سے عملہ دینا ہے، تاکہ اس کی رہنمائی ان ٹیموں پر ساکھ رکھے جن کی وہ خدمت کرتا ہے۔

ذمہ داری سے استعمال کریں، اور محفوظ راستے کو آسان راستہ بنائیں

استعمال وہ جگہ ہے جہاں زیادہ تر خطرہ داخل ہوتا ہے، اس لیے اچھے رویے کو بے کوشش بنائیں۔ پہلے سے جانچے اجزا کی منتخب اندرونی فہرست، pipeline میں خودکار لائسنس اور کمزوری کی اسکیننگ، اور واضح ڈیفالٹس فراہم کریں جن پر ڈویلپر ٹکٹ فائل کیے بغیر چل سکے۔ باب 10.3 کے لائسنس نظم و ضبط اور باب 2.18 کی سپلائی چین اور انحصار کی صحت کے عمل پر تکیہ کریں: ورژن pin کریں، software bill of materials بنائیں، سمجھوتہ شدہ یا متروک پیکجز کے لیے سافٹ ویئر سپلائی چین پر نظر رکھیں، اور اس سے پہلے end-of-life ٹریک کریں کہ وہ منتقلی پر مجبور کرے۔ OSPO کا کام ہر انحصار کو ہاتھ سے منظور کرنا نہیں۔ یہ حفاظتی جنگلے بنانا ہے تاکہ پچانوے فیصد انتخاب خود بخود محفوظ ہوں اور صرف واقعی غیر معمولی معاملات انسان تک پہنچیں۔

اپ اسٹریم میں حصہ اس لیے ڈالیں کہ یہ ادا کرتا ہے، اس لیے نہیں کہ اچھا ہے

اپ اسٹریم شراکت کو معاشی فیصلہ سمجھیں۔ انحصار پر جو ہر نجی patch آپ اٹھاتے ہیں وہ ہر اپ گریڈ پر ہمیشہ کے لیے ادا ہوتا ٹیکس ہے، جب تک تبدیلی اپ اسٹریم میں نہ اتر جائے یا fork اتنا بھٹک نہ جائے کہ آپ اس کے مکمل مالک بن جائیں۔ اصلاح واپس دینا وہ ٹیکس مٹا دیتا ہے۔ اپ اسٹریم کرنا سمت پر اثر بھی خریدتا ہے، اس لیے جس جزو پر آپ انحصار کرتے ہیں اس کا روڈ میپ آپ کی ضروریات کی طرف مڑتا ہے، اور یہ ان انجینئروں کو صلاحیت کا اشارہ دیتا ہے جنہیں آپ بھرتی کرنا چاہتے ہیں۔ اپنے ڈویلپرز کو تیز، دستاویزی راستہ دیں: پہلے سے منظور شدہ contributor licence agreement یا developer certificate of origin، ہلکی منظوری جو تصدیق کرے کہ تبدیلی بانٹنے کے لیے محفوظ ہے، اور کام کے لیے بجٹ شدہ انتظامیہ کا وقت۔ جب متبادل ایسے پراجیکٹ کا مستقل fork برقرار رکھنا ہو جسے آپ کنٹرول نہیں کرتے، تو واپس حصہ ڈالنا تقریباً ہمیشہ سستا ہے۔

اپنے پراجیکٹس حقیقی نظم و نسق کے ساتھ جاری کریں

جب آپ اپنا بنایا سافٹ ویئر اوپن سورس کریں تو دانستہ کریں یا بالکل نہ کریں۔ پہلے طے کریں کہ کوڈ بانٹنے کے لائق عام چیز ہے یا بند رکھنے کے لائق امتیاز، باب 10.12 کی دلیل سے۔ اگر جاری کریں تو اپنے ارادے سے ملتا لائسنس چنیں (اپنانا زیادہ سے زیادہ کرنے کو permissive، ماحولیاتی نظام کو باہمی رکھنے کو copyleft)، تحریری نظم و نسق کے ماڈل سے دستاویزی کریں کہ کون کیا طے کرتا ہے، اور پراجیکٹ کے نام پر trademark رجسٹر کریں تاکہ کوڈ کو آزاد رکھتے ہوئے اسے غلط استعمال سے بچا سکیں۔ حقیقی نگرانی کا عہد کریں: عوامی issue tracker، شراکت کی گائیڈ، code of conduct، اور مربوط افشا والی سیکیورٹی پالیسی تاکہ رپورٹ کرنے والے جانیں آپ تک کیسے پہنچیں (باب 4.2)۔ maintainer کا نام لیں اور ان کا وقت بجٹ کریں۔ وہ پراجیکٹ جو آپ دھوم دھام سے شروع کریں اور سال بھر میں چھوڑ دیں آپ کی ساکھ کو اس سے زیادہ نقصان پہنچاتا ہے جو آپ نے کبھی ship نہ کیا ہو۔

کمپنی کے اندر تعاون کے لیے InnerSource لاگو کریں

وہ عادات جو اوپن سورس کو کام کراتی ہیں (عوامی ریپوزٹریاں، واضح شراکت کی گائیڈز، میرٹ پر ریویو، پہلے patch کی کم رکاوٹ) فائر وال کے پیچھے بھی اتنا ہی کام کرتی ہیں۔ InnerSource کا مطلب ہے کہ کوئی بھی انجینئر کسی بھی اندرونی پراجیکٹ کو تلاش، استعمال، اور بہتر کر سکتا ہے، ٹکٹ فائل کر کے انتظار کرنے کی بجائے ٹیم کی حدوں کے پار pull request بھیج کر۔ یہ silos توڑتا، کوڈ کا دوبارہ استعمال پھیلاتا، اور آپ کے لوگوں کو بالکل اس ورک فلو کی تربیت دیتا ہے جو وہ بیرونی شراکت پر استعمال کریں گے۔ OSPO InnerSource کا فطری گھر ہے کیونکہ وہ پہلے سے ٹولنگ اور ثقافتی playbook کا مالک ہے۔ چند اونچی قدر کی مشترک لائبریریوں سے شروع کریں، ان کی شراکت کی گائیڈز اندرونی طور پر شائع کریں، اور ان ٹیموں کو انعام دیں جو بیرونی patches خوش اسلوبی سے قبول کریں۔

جن maintainers پر آپ منحصر ہیں انہیں فنڈ اور سہارا دیں

آپ کا production نظام ایسی لائبریری پر ٹکا ہو سکتا ہے جسے ایک شخص فارغ وقت میں برقرار رکھتا ہے۔ یہ سپلائی چین کا خطرہ ہے، اور ایماندار ردعمل بوجھ اٹھانے میں مدد کرنا ہے۔ اپنے bill of materials سے سب سے نازک انحصار پہچانیں، وہ ڈھونڈیں جن کے maintainers کی بنیاد پتلی ہے، اور ہر ایک کے لیے ردعمل چنیں: maintainer کو براہ راست sponsor کریں، انجینئرنگ کا وقت دیں، پراجیکٹ کو فنڈ کرنے والی فاؤنڈیشن میں شامل ہوں، یا، آخری سہارے کے طور پر، fork یا تبدیلی کی تیاری کریں۔ مشترکہ کو فنڈ کرنا اس کے ڈھنے کے بعد کی ہنگامی صورت سے سستا ہے، اور یہ ان اجزا کو صحت مند اور اس سمت میں چلتا رکھتا ہے جس پر آپ اثر ڈال سکیں جن پر آپ انحصار کرتے ہیں۔

ایسی شراکت کی پالیسی طے کریں جو جلد منظور کرے

شراکت کی پالیسی جلدی ہاں کہنے کے لیے ہے، آہستہ نہ کہنے کے لیے نہیں۔ وضاحت کریں کہ انجینئر بغیر پوچھے کیا حصہ ڈال سکتا ہے (bug fixes، دستاویزات، ان پراجیکٹس میں چھوٹے فیچرز جنہیں آپ پہلے سے استعمال کرتے ہیں)، کس کو ہلکی جانچ چاہیے (امتیاز یا patent کو چھونے والی کوئی بھی چیز)، اور دانشورانہ ملکیت اور شراکت کے معاہدے ہر شراکت کے حساب کی بجائے ایک بار، مرکزی طور پر کیسے سنبھالے جاتے ہیں۔ بورنگ حصے خودکار کریں: لائسنس کی جانچ، پہلے سے دستخط شدہ کارپوریٹ contributor معاہدہ، اور bot جو نادر جمع آوری کو نشان زد کرے جسے انسانی آنکھوں کی ضرورت ہے۔ منظوری کا وقت ناپیں اور سست قطار کو پالیسی کا bug سمجھیں۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
مرکزی OSPO	مستقل پالیسی، گہری مہارت، واضح ملکیت	رکاوٹ بن سکتا ہے اگر صرف روکے اور کبھی ممکن نہ بنائے
وفاقی OSPO (ٹیموں میں champions)	پھیلتا ہے، فیصلے انجینئروں کے قریب رکھتا ہے	مضبوط ہم آہنگی چاہیے ورنہ پالیسی الگ ہو جاتی ہے
اپ اسٹریم میں حصہ ڈالنا	نجی-patch کا ٹیکس مٹاتا ہے، اثر خریدتا ہے، بھرتی میں مدد	جاری کوشش، IP ریویو، کسی اور کے شیڈول پر کام
نجی forks اٹھانا	مکمل کنٹرول، اپنی ٹائم لائن پر ship	مستقل دیکھ بھال کا ٹیکس، اپ اسٹریم سیکیورٹی اصلاحات سے بھٹکتا ہے
اپنا پراجیکٹ جاری کرنا	ماحولیاتی نظام، ساکھ، مشترک دیکھ بھال	حقیقی نگرانی کی لاگت؛ ترک ساکھ کو نقصان پہنچاتا ہے
maintainers کو فنڈ کرنا	نازک انحصار کی حفاظت، خیر سگالی خریدتا ہے	براہ راست لاگت، اور کسے فنڈ کرنا ہے چننا سیاسی ہے
کوئی OSPO نہیں (ad hoc)	صفر سیٹ اپ لاگت	نادیدہ قانونی، سیکیورٹی، اور پائیداری کا قرض

مرکزی کھنچاؤ کنٹرول اور ممکن بنانے کے درمیان ہے۔ وہ OSPO جو ہر انحصار اور ہر شراکت کو ہاتھ سے ریویو کرے محفوظ لگتا ہے، مگر یہ وہ چیز بن جاتا ہے جس کے گرد انجینئر راستہ نکالتے ہیں، جو وہی نادیدہ سایہ انحصار پیدا کرتا ہے جنہیں آپ روکنا چاہتے تھے۔ وہ OSPO جو بغیر خودکار نفاذ کے صرف خوش مزاج رہنمائی شائع کرے ڈیڈ لائن آتے ہی نظر انداز ہو جاتا ہے۔ حل وہی ہے جو باب 10.3 میں چلتا ہے: عام صورت خودکار کریں تاکہ مطابق راستہ تیز ترین راستہ ہو، اور انسانی فیصلہ واقعی نئی چیزوں کے لیے رکھیں۔ یہ توازن ٹھیک پائیں تو دفتر طاقت بڑھانے والا ہے؛ کسی بھی سمت غلط ہو تو یا وہ بریک ہے یا آرائش۔

اپنی ٹیم کے ساتھ بحث کے سوالات

آج اوپن سورس سے آپ کے تعلق کا مالک کون ہے، اور کیا وہ کل مشکل سوال کا جواب دے سکتا ہے؟ اگر ممکنہ خریدار کے وکلا آپ کی لائسنس فہرست مانگیں، یا صحافی پوچھے کہ آپ کے ادائیگی کے راستے میں کون سی غیر برقرار لائبریری بیٹھی ہے، تو کیا جواب کے ساتھ کوئی نام جڑا ہے؟ زیادہ تر اداروں کے لیے ایماندار ردعمل “کوئی نہیں” ہے، جس کا مطلب ہے کہ ہر انجینئر خاموشی سے پالیسی بنا رہا ہے اور مجموعے کا کوئی جوابدہ نہیں۔ شہادت میٹنگ میں لائیں: منظور شدہ لائسنس فہرست، software bill of materials، اور وہ شخص جو due diligence کے دوران copyleft کا سوال سنبھالے گا بنانے کی کوشش کریں۔ اگر یہ دستاویزات موجود نہیں یا کسی کی طرف اشارہ نہیں کرتیں تو آپ کو اپنا پہلا OSPO کام مل گیا۔ فیصلہ یہ نہیں کہ فنکشن ہو یا نہیں بلکہ اس کا مالک کون ہے اور وہ کیا مینڈیٹ رکھتا ہے، چاہے دفتر ہفتے میں ایک دن کے لیے ایک شخص ہو۔
کیا آپ ایسے نجی patches اٹھا رہے ہیں جنہیں آپ اپ اسٹریم کر سکتے ہیں، اور یہ آپ کو کیا لاگت دے رہا ہے؟ بہت سی ٹیمیں اپنے انحصار پر مقامی ترامیم کا خاموش ڈھیر برقرار رکھتی ہیں، ہر اپ گریڈ پر انہیں ہاتھ سے دوبارہ لاگو کرتی اور merge کی تکلیف کو قدرت کے قانون کی طرح جذب کرتی ہیں۔ ان میں سے ہر patch بار بار کا ٹیکس ہے، اور ہر ایک واپس دینے کا امیدوار ہے تاکہ ٹیکس ختم ہو۔ تفصیل لائیں: وہ forks اور مقامی patches فہرست کریں جو آپ کا build واقعی اٹھاتا ہے، ہر ایک کی سالانہ انجینئرنگ گھنٹوں کی لاگت کا اندازہ لگائیں، اور نوٹ کریں کہ کون سے اپ اسٹریم پراجیکٹس تبدیلی قبول کرنے کا امکان رکھتے ہیں۔ متصادم غور حقیقی ہے، کیونکہ اپ اسٹریم کرنا ابھی کوشش لیتا اور maintainer کے شیڈول پر چلتا ہے، مگر موازنہ patch کا ٹیکس ہمیشہ ادا کرنے سے ہے۔ جواب کو “ہم بس اسے دوبارہ لاگو کر دیتے ہیں” کو دانستہ انتخاب میں بدلنا چاہیے، ایسے شراکت کے راستے کے ساتھ جو انجینئروں کے استعمال کے لیے کافی تیز ہو۔
کون سا انحصار سب سے زیادہ نقصان پہنچائے گا اگر اس کا maintainer چھوڑ دے، اور آپ اس کے بارے میں کیا کریں گے؟ آپ کے اسٹیک میں کہیں ایسا جزو ہے جو ٹوٹنے پر آمدنی یا مشن کے لیے نازک سروس روک دے گا، اور اسے ایک شخص یا چند لوگ برقرار رکھتے ہیں جنہیں آپ نے کبھی فنڈ نہیں کیا یا شکریہ نہیں کہا۔ مشترکہ مفت لگتا ہے ٹھیک اس لمحے تک جب نہ ہو، اور اس سبق کا مہنگا ورژن ترک یا غیر patch شدہ کمزوری کے بعد کی بھاگ دوڑ ہے۔ اپنا bill of materials لائیں اور انحصار کو blast radius سے رینک کریں، پھر اوپر کے چند کے maintainer کی تعداد اور فنڈنگ کی حالت نوٹ کریں۔ ہر نازک، کم عملہ والے کے لیے پہلے سے طے کریں کہ آپ sponsor کریں گے، وقت دیں گے، فاؤنڈیشن میں شامل ہوں گے، یا تبدیلی کی تیاری کریں گے۔ یہ پوشیدہ واحد ناکامی کے نقطے کو منظم تعلق میں بدلتا ہے، کسی بھی دوسرے آپریشنل خطرے کے معیار پر رکھا (باب 2.18)۔
اگلا اندرونی ٹول اوپن سورس کرنے سے پہلے، کیا آپ برسوں اس کی نگرانی کے لیے تیار ہیں، یا آپ launch اور آخرکار معذرت ship کر رہے ہیں؟ عوامی ریلیز کھڑا عہد ہے: issue tracker جسے کسی کو triage کرنا ہے، سیکیورٹی inbox جسے کسی کو دیکھنا ہے، اور نام جس کا کسی کو دفاع کرنا ہے۔ ٹیمیں بھرتی یا خیر سگالی کے لیے اوپن سورس کی طرف جاتی ہیں، پھر دریافت کرتی ہیں کہ پرانے issues والا متروک پراجیکٹ اس ساکھ کو، جو انہوں نے بنانی چاہی، کچھ بھی ship نہ کرنے سے زیادہ نقصان پہنچاتا ہے۔ شہادت لائیں: وہ پراجیکٹس فہرست کریں جو آپ پہلے جاری کر چکے ہیں، اور ہر ایک کے لیے دکھائیں اس کے کھلے issues کی عمر، کیا نام زد maintainer کے بجٹ شدہ گھنٹے ہیں، کیا اس کا نظم و نسق کا ماڈل، رجسٹرڈ trademark، اور مربوط افشا کی پالیسی ہے، اور کیا کوڈ بانٹنے کے لائق عام چیز ہے یا امتیاز جو آپ کو بند رکھنا چاہیے (باب 10.12)۔ متصادم غور یہ ہے کہ حقیقی نگرانی انجینئرنگ کا وہ وقت لیتی ہے جو آپ پروڈکٹ پر خرچ کر سکتے تھے، اس لیے ایماندار انتخاب اکثر کم چیزیں جاری کرنا اور انہیں مناسب طور پر سنبھالنا ہے۔ انٹرپرائز کے لیے اس کا مطلب launch سے پہلے قانونی اور برانڈ کا ریویو ہے؛ حکومت کے لیے اس کا مطلب ہے کہ ریپوزٹری عوامی ہونے سے پہلے trademark، افشا کا چینل، اور publish-by-default استثنا کا عمل طے ہو۔
انجینئر کو انحصار منظور کرانے یا شراکت کلیئر کرانے میں اصل میں کتنا وقت لگتا ہے، اور کیا یہ آپ کے گرد راستہ نکالنے سے سست ہے؟ اوپن سورس کی پالیسی براہ راست اس تیز ترین متبادل سے مقابلہ کرتی ہے جو انجینئر ڈھونڈ سکے، اور کوئی بھی عمل جو کوڈ کاپی کرنے سے سست ہو نظر انداز ہو جاتا ہے، جو وہی نادیدہ سایہ انحصار پیدا کرتا ہے جنہیں دفتر روکنے کے لیے بنا تھا۔ کھنچاؤ کنٹرول بمقابلہ ممکن بنانا ہے: ہر ہاتھ کا ریویو آڈٹ کا راستہ جوڑتا اور نادر حقیقی مسئلہ پکڑتا ہے، مگر یہ تاخیر بھی جوڑتا ہے جو عام صورت کو مطابق راستے سے ہٹا دیتی ہے۔ اعداد میٹنگ میں لائیں: معیاری انحصار اور معیاری شراکت کے لیے ناپا گیا منظوری کا وقت، خودکار بمقابلہ انسان کے ہاتھ سے سنبھالے گئے فیصلوں کا حصہ، اور پچھلی سہ ماہی میں استثنا کی گنتی جنہیں واقعی فیصلہ چاہیے تھا۔ سینکڑوں انجینئروں والے انٹرپرائز میں، جو روزانہ چھوٹے فیصلے کرتے ہیں، دو دن کی قطار خاموشی سے ہزاروں بائی پاس شدہ ریویو بن جاتی ہے؛ حکومت میں وہی تاخیر خریداری اور آڈٹ کی ان ذمہ داریوں سے ٹکراتی ہے جو وہ کاغذی راستہ چاہتی ہیں جسے راستہ نکالنا چھوڑ دیتا ہے، اس لیے حل بڑا دروازہ عملہ دینے کی بجائے عام صورت خودکار کرنا ہے۔
کون سے اندرونی پراجیکٹس کو InnerSource سے سب سے زیادہ فائدہ ہوگا، اور آج دوسری ٹیم کو آپ کو pull request بھیجنے سے کیا روکتا ہے؟ وہ عمل جو اوپن سورس کو کام کراتے ہیں (عوامی ریپوزٹریاں، شراکت کی گائیڈز، میرٹ پر ریویو، پہلے patch کی کم رکاوٹ) فائر وال کے پیچھے silos توڑ کر، دوبارہ استعمال پھیلا کر، اور لوگوں کو بالکل اس ورک فلو کی تربیت دے کر ادائیگی کرتے ہیں جو وہ بیرونی شراکت کے لیے استعمال کریں گے۔ متصادم غور یہ ہے کہ اندرونی پراجیکٹ کھولنا شراکت کی گائیڈ، فاضل ریویو کی صلاحیت، اور اس فیصلے کا تقاضا کرتا ہے کہ سیکیورٹی یا ضابطے کی وجوہات سے کون سا کوڈ محدود رہنا چاہیے۔ تفصیل لائیں: اونچی قدر کی مشترک لائبریریوں کا نام لیں، نوٹ کریں کون سی پہلے ہی اندرونی شراکت کی گائیڈ شائع کرتی ہیں، اور بیان کریں کہ آج کراس ٹیم pull request کیسے سنبھالا جاتا ہے، آیا اس کا خیرمقدم ہوتا ہے یا قطار میں کھو جاتا ہے۔ انٹرپرائز کے لیے فائدہ بہت سی ٹیموں میں بچی ہوئی دہری اندرونی تعمیرات میں ناپا جاتا ہے؛ حکومت کے لیے وہی عادت ایجنسیوں کی حدوں کے پار بین ایجنسی دوبارہ استعمال کے طور پر پھیلتی ہے، تاکہ publish-by-default اور مشترک اجزا دہرا عوامی خرچ بڑھانے کی بجائے گھٹائیں۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ دفتر ایک نام زد انجینئر کو ہفتے میں چند گھنٹوں کے لیے ایک صفحے کے چارٹر کے ساتھ دیں، کمیٹی نہیں۔ pipeline میں اسکینر کے ساتھ permissive لائسنسوں کو ڈیفالٹ کریں، صرف وہ مٹھی بھر نجی patches اپ اسٹریم کریں جو واقعی ہر اپ گریڈ پر تکلیف دیتے ہیں، اور اس واحد-maintainer لائبریری کے لیے چھوٹی ماہانہ sponsorship رکھیں جس کے بغیر آپ واقعی نہیں چل سکتے۔ یہاں رفتار coverage سے اہم ہے: کوڈ کاپی کرنے سے تیز مطابق راستہ اس مکمل پالیسی سے بہتر ہے جسے کوئی فالو نہیں کرتا۔

چھوٹا کاروبار۔ آپ مخصوص OSPO کو عملہ نہیں دیں گے، اس لیے وہ صلاحیت خریدیں جو ان آلات میں پیوست ہے جو آپ پہلے سے چلاتے ہیں: اسکینر جو لائسنس اور کمزوری کے مسائل نشان زد کرے، اور پہلے سے جانچے اجزا کی منتخب فہرست۔ کام کو پروگرام کی بجائے لائسنس کی تعمیل اور انحصار کی صحت کی صفائی کے طور پر تشکیل دیں: جانیں آپ کے software bill of materials میں کیا ہے، جانیں ہر لائسنس کیا پابند کرتا ہے، اور جانیں کون سا واحد-maintainer انحصار غائب ہو جانے پر نقصان کرے گا۔ اپنی اسکیننگ اور فہرست سازی بنانے کی بجائے خریدنے کو ترجیح دیں۔

بڑا ادارہ۔ چھوٹا مرکزی دفتر اور پروڈکٹ ٹیموں میں پیوست champions کا وفاقی نیٹ ورک چلائیں، تاکہ پالیسی مستقل رہے جبکہ فیصلے انجینئروں کے قریب رہیں۔ لائسنس، کمزوری، اور برآمد کی اسکیننگ خودکار کریں، ہر انجینئر کو پہلے سے منظور شدہ contributor معاہدے سے ڈھانپیں، اور منظوری کا وقت رپورٹ شدہ میٹرک کے طور پر ٹریک کریں۔ اپنے نازک انحصار کے پیچھے فاؤنڈیشنز کو فنڈ کریں، بہت سی ریپوزٹریوں میں InnerSource چلائیں، اور پوری ملکیت کو انفرادی فیصلوں کے بکھراؤ کی بجائے صحت اور شمولیت کے میٹرکس والے پورٹ فولیو کے طور پر منظم کریں۔

حکومت۔ ڈیفالٹ-طور-پر-اوپن-سورس اور عوامی-پیسہ-عوامی-کوڈ کے تحت کام کریں: نئی سروسز عوامی ریپوزٹری میں شائع کریں جب تک سیکیورٹی یا رازداری کا دستاویزی استثنا لاگو نہ ہو۔ بین حکومتی فہرست چلائیں تاکہ ٹیمیں بنانے سے پہلے دوبارہ استعمال کریں، خریداری میں اوپن سورس اور کھلے معیارات کے تقاضے لکھیں تاکہ فروخت کنندگان حقوق محفوظ رکھتے ہوئے دوبارہ قابل استعمال کوڈ دیں، اور جو آپ شائع کریں اس کے لیے مربوط افشا سنبھالیں۔ ان مشترک لائبریریوں کی دیکھ بھال کو فنڈ کریں جن پر کئی ایجنسیاں منحصر ہیں، تاکہ کوئی ایک ٹیم خاموشی سے وہ انفراسٹرکچر نہ رکھے جس پر پوری حکومت انحصار کرتی ہے۔

مثالیں

اسٹارٹ اپ۔ بیس افراد کا اسٹارٹ اپ اپنے لیڈ پلیٹ فارم انجینئر کو ایک صفحے کے چارٹر کے ساتھ جز وقتی OSPO مالک بناتا ہے۔ وہ سادہ استعمال کی پالیسی طے کرتی ہے (permissive لائسنس پہلے سے منظور، copyleft کا ریویو، pipeline میں اسکینر)، اور نوٹس کرتی ہے کہ ٹیم اوپن سورس queue لائبریری پر تین نجی patches اٹھاتی ہے، جو ہر اپ گریڈ پر تکلیف سے دوبارہ لاگو ہوتے ہیں۔ وہ تینوں اپ اسٹریم کرتی ہے؛ دو ایک مہینے میں قبول ہو جاتے ہیں، اپ گریڈ کا ٹیکس ہمیشہ کے لیے مٹاتے ہوئے۔ وہ ایک چھوٹا اندرونی ٹول حقیقی README، لائسنس، اور سیکیورٹی رابطے کے ساتھ اوپن سورس کرتی ہے، زیادہ تر انجینئر متوجہ کرنے کو، اور اس واحد-maintainer parser کے لیے ماہانہ sponsorship رکھتی ہے جس پر پروڈکٹ منحصر ہے۔ اس میں سے کسی کو عملہ نہیں چاہیے، صرف نام زد مالک اور واضح مینڈیٹ۔

بڑا ادارہ۔ عالمی بینک چھ افراد کا مرکزی OSPO اور ہر پروڈکٹ گروپ میں پیوست اوپن سورس champions کا وفاقی نیٹ ورک چلاتا ہے۔ مرکزی ٹیم پالیسی، خودکار لائسنس اور برآمدی تعمیل کی اسکیننگ، اور contributor licence agreement کی مالک ہے جس سے ہر انجینئر پہلے دن سے ڈھکا ہے۔ Champions مقامی ریویو سنبھالتے اور اپنی ٹیموں کو شراکت پر کوچ کرتے ہیں۔ بینک ان کئی فاؤنڈیشنز کو فنڈ کرتا ہے جن کے پراجیکٹس اس کے ٹریڈنگ سسٹمز کی بنیاد ہیں، وسیع استعمال شدہ ڈیٹا فریم ورک میں اپ اسٹریم اصلاحات دیتا ہے تاکہ fork برقرار رکھنا بند کرے، اور دو سو اندرونی ریپوزٹریوں میں InnerSource چلاتا ہے تاکہ کوئی بھی ٹیم کسی بھی دوسری کو pull request بھیج سکے۔ معیاری شراکت کی منظوری کا وقت دو دن سے کم ہے، ایسے میٹرک کے طور پر ٹریک ہوتا جسے OSPO سہ ماہی رپورٹ کرتا ہے۔

حکومت۔ قومی ڈیجیٹل ایجنسی “ڈیفالٹ طور پر اوپن سورس” اور عوامی-پیسہ-عوامی-کوڈ کے مینڈیٹ کے تحت کام کرتی ہے۔ اس کا OSPO نئی سروسز عوامی ریپوزٹری میں شائع کرتا ہے جب تک سیکیورٹی یا رازداری کا دستاویزی استثنا لاگو نہ ہو، بین حکومتی فہرست چلاتا ہے تاکہ ایجنسیاں بنانے سے پہلے کوڈ دوبارہ استعمال کریں، اور خریداری میں اوپن سورس اور کھلے معیارات کے تقاضے لکھتا ہے تاکہ فروخت کنندگان دوبارہ قابل استعمال، اچھی طرح دستاویزی کوڈ دیں اور حکومت حقوق رکھے۔ دفتر اپنے شائع کردہ کوڈ کے لیے مربوط سیکیورٹی افشا بھی سنبھالتا ہے اور مشترک شناختی لائبریری کی دیکھ بھال کو فنڈ کرتا ہے جس پر اب کئی ایجنسیاں منحصر ہیں، تاکہ کوئی ایک ٹیم خاموشی سے وہ جزو نہ رکھے جس پر پوری حکومت انحصار کرتی ہے۔

کاروباری جواز: محرکات، ROI اور TCO

سب سے واضح واپسی قابل گریز، مہنگی حیرتوں کا خاتمہ ہے۔ غیر منظم اوپن سورس ایسے بحران پیدا کرتا ہے جو اپنے شیڈول پر آتے ہیں: حصول کی due diligence میں سامنے آئی copyleft کی خلاف ورزی، مردہ جزو سے ہنگامی منتقلی، اس انحصار سے جڑا breach جسے کوئی فہرست نہ دکھاتی تھی۔ OSPO ان کم امکان، اونچی لاگت کے واقعات کو مستحکم، بجٹ شدہ کام میں بدلتا ہے۔ اپ اسٹریم کرنے سے بار بار کی بچتیں اوپر رکھیں: ہر نجی patch جو آپ ریٹائر کرتے ہیں ہر مستقبل کے اپ گریڈ پر ٹیکس لگانا بند کرتا ہے، اور بڑی ملکیت میں یہ مرکب ہو کر حقیقی انجینئرنگ کی صلاحیت پروڈکٹ کے کام کو لوٹاتا ہے۔

ملکیت کی کل لاگت کے کھاتے پر، دفتر اس کے مقابل سستا ہے جس کی وہ حفاظت کرتا ہے۔ اس کی لاگت چھوٹی ٹیم، کچھ اسکیننگ اور فہرست سازی کی ٹولنگ، اور معمولی maintainer کی فنڈنگ ہے۔ اسے نہ ہونے کی لاگت کے مقابل رکھیں: قانونی ذمہ داری، ناکام یا تاخیر شدہ due diligence، سیکیورٹی کے واقعات، ان چیزوں کی دہری اندرونی تعمیرات جو پہلے سے اوپن سورس موجود ہیں، اور ان forks کا آہستہ خون بہنا جنہیں رکھنا کسی نے نہیں چنا تھا۔ اوپر کی واپسیاں بھی ہیں جن کی قیمت لگانا مشکل مگر حقیقی ہے: ان اجزا کی سمت پر اثر جن پر آپ منحصر ہیں، معتبر اوپن سورس موجودگی سے بھرتی اور ساکھ کا فائدہ، اور تیز ترسیل کیونکہ انجینئر دوبارہ بنانے کی بجائے دوبارہ استعمال کرتے ہیں۔ جب آپ قیادت کے سامنے دلیل رکھیں تو OSPO کو اپنے کوڈ بیس کے اکثریتی حصے کے سپلائی چین انتظام کے طور پر تشکیل دیں، اوپر اسٹریٹجک منافع کے ساتھ۔ حکومت میں تعمیل کا پہلو جوڑیں، کیونکہ کھلا پن اکثر لازم ہے اور اسے اچھی طرح کرنا عدم تعمیل اور دہرے عوامی خرچ دونوں سے بچاتا ہے۔

ضد نمونے اور خامیاں

OSPO بطور دروازہ۔ دفتر جو صرف ریویو کرتا اور روکتا ہے، کبھی ممکن نہیں بناتا، اس کے گرد راستہ نکالا جاتا ہے، وہی سایہ انحصار پیدا کرتے ہوئے جنہیں روکنے کو بنا تھا۔
شراکت کا تھیٹر۔ اوپن سورس حکمت عملی کا اعلان جبکہ منظوری کا عمل اتنا سست بنانا کہ کوئی واقعی حصہ نہیں ڈالتا۔
متروک ریلیز۔ launch بلاگ پوسٹ کے ساتھ پراجیکٹ شائع کرنا، پھر کبھی issue triage نہ کرنا، خاموشی سے زیادہ ساکھ کو نقصان پہنچاتے ہوئے۔
Fork کر کے بھول جانا۔ ایک اصلاح کے لیے انحصار کو fork کرنا اور پھر ہمیشہ اٹھائے رکھنا، اپ اسٹریم سیکیورٹی patches سے بھٹکتے ہوئے۔
نازک maintainers پر مفت سواری۔ نازک واحد-maintainer لائبریری پر انحصار اور اس کے پیچھے شخص کو کبھی فنڈ، شکریہ، یا مدد نہ دینا۔
Trademark سے غفلت۔ پراجیکٹ کا نام محفوظ کیے بغیر جاری کرنا، پھر fork یا فروخت کنندہ کو آپ کی ساکھ پر تجارت کرتے دیکھنا۔
صرف قانونی ملکیت۔ OSPO کو مکمل طور پر قانونی میں رکھنا تاکہ اس کی رہنمائی انجینئرنگ کی ساکھ نہ رکھے اور ٹیمیں اسے نظر انداز کریں۔
دکھاوے کے میٹرکس۔ انحصار کی صحت، منظوری کا وقت، اور ریٹائر ہوئے نجی patches کی بجائے stars اور اخباری ذکر گننا۔

پختگی کا ماڈل

سطح 1، آغاز: انجینئر بغیر پالیسی اور مالک کے اوپن سورس شامل، patch، اور کبھی شائع کرتے ہیں۔ استعمال، شراکت، اور ریلیز ردعملی اور ad hoc ہیں، انفرادی پہل سے چلتی ہیں۔ نجی forks نظر نہ آتے جمع ہوتے ہیں، کوئی کسی اپ اسٹریم پراجیکٹ کو فنڈ نہیں کرتا، اور کوئی due diligence کے دوران لائسنس کے سوال کا جواب نہیں دے سکتا۔
سطح 2، ترقی: بنیادی عمل ظاہر ہوتے ہیں مگر ٹیم سے ٹیم مختلف ہیں۔ موٹی استعمال کی پالیسی اور منظور شدہ لائسنس فہرست موجود ہے، اور کوئی ڈھیلے طریقے سے ذمہ دار ہے، پھر بھی شراکت سست اور معاملہ بہ معاملہ ہے اور کچھ گروہ دوسروں سے کہیں زیادہ کرتے ہیں۔ چند نازک انحصار معلوم ہیں، مگر پائیداری، ریلیزز، اور نگرانی غیر مستقل رہتی ہیں۔
سطح 3، معیار بندی: چارٹر شدہ OSPO استعمال، شراکت، ریلیز، اور کمیونٹی کا مالک ہے، اور عمل دستاویزی اور ادارے بھر نافذ ہیں۔ اسکیننگ اور software bill of materials خودکار ہیں، پہلے سے منظور شدہ contributor معاہدہ اور تیز منظوری کا راستہ موجود ہے، جاری شدہ پراجیکٹس حقیقی نظم و نسق، trademarks، اور سیکیورٹی پالیسیاں رکھتے ہیں، اور InnerSource پھیل رہا ہے۔ سرکاری ٹیمیں ڈیفالٹ طور پر شائع کرتی ہیں۔
سطح 4، انتظام: اوپن سورس کا فنکشن بنیادی خطوط کے مقابل ناپا اور کنٹرول کیا جاتا ہے۔ منظوری کا وقت ہدف کے مقابل ٹریک ہوتا ہے، شراکت کا حجم اور اپ اسٹریم قبولیت کی شرح رپورٹ ہوتی ہے، انحصار کی صحت اور maintainer کی تعداد کے ڈیش بورڈز واحد ناکامی کے نقطوں کو نشان زد کرتے ہیں، سب سے زیادہ خطرے والے انحصار کی فنڈ شدہ-maintainer coverage مانیٹر ہوتی ہے، اور نجی patches اور forks کی فہرست سہ ماہی بہ سہ ماہی گھٹتی ہے۔ جاری شدہ پراجیکٹس کے issue کے جواب کے اوقات ناپے جاتے ہیں، استثنا تال پر ریویو ہوتے ہیں، اور stars جیسے دکھاوے کے میٹرکس ان کے حق میں چھوڑ دیے جاتے ہیں۔
سطح 5، ہم آہنگی: اوپن سورس منظم اسٹریٹجک صلاحیت ہے، انجینئرنگ، قانونی، سیکیورٹی، اور خریداری کی منصوبہ بندی سے مربوط اور مسلسل ڈھلتی ہے۔ شراکت معمول ہے، نازک maintainers اور فاؤنڈیشنز فنڈ ہوتی ہیں، ادارہ اچھے چلتے پراجیکٹس کی نگرانی کرتا اور جن ماحولیاتی نظاموں پر منحصر ہے انہیں سمت دیتا ہے، اور InnerSource معیار ہے۔ شمولیت اور صحت کے میٹرکس مسلسل بہتری کو کھلاتے ہیں، اور انحصار، خطرات، اور مینڈیٹ بدلنے پر پورٹ فولیو دوبارہ متوازن ہوتا ہے۔

بحث کے لیے خیالات

ممکن بنانے والے اور روکنے والے OSPO کے درمیان لکیر کہاں ہے، اور آپ باہر سے کیسے جانیں گے کہ آپ نے کون سا بنایا ہے؟
آپ کے کون سے نجی patches یا forks آپ ضرورت کی بجائے عادت سے اٹھا رہے ہیں، اور اوپر کے تین اپ اسٹریم کرنے کو کیا چاہیے؟
جب نازک انحصار کی فہرست بجٹ سے لمبی ہو تو آپ کیسے فیصلہ کریں کہ کن maintainers اور فاؤنڈیشنز کو فنڈ کرنا ہے؟
آپ کی اگلی ریلیز میں واقعی کیا بدلے گا اگر آپ کو اسے پہلے دن سے حقیقی نظم و نسق، trademark، اور مربوط افشا کی پالیسی کے ساتھ شائع کرنا ہو؟
عوامی شعبے کے قارئین کے لیے: اصول کو خاموشی سے کھوکھلا کیے بغیر کوڈ کو publish-by-default سے مستثنیٰ کرنے کا قابل دفاع عمل کیا ہے؟
کون سی اندرونی لائبریریوں کو InnerSource سے سب سے زیادہ فائدہ ہوگا، اور آج دوسری ٹیم کو آپ کو pull request بھیجنے سے کیا روکتا ہے؟

اہم نکات

OSPO اوپن سورس سے پورے تعلق کا مالک ہے: ذمہ داری سے استعمال، اپ اسٹریم شراکت، اپنے پراجیکٹس جاری کرنا، اور جن maintainers پر آپ منحصر ہیں انہیں سہارا دینا۔
اپ اسٹریم میں حصہ ڈالنا حکمت عملی ہے، خیرات نہیں؛ یہ نجی patches کا بار بار کا ٹیکس مٹاتا، سمت پر اثر خریدتا، اور بھرتی میں مدد دیتا ہے۔
خودکار کاری اور فہرست سازی سے مطابق راستے کو تیز ترین راستہ بنائیں، تاکہ دفتر انجینئروں کو روکنے کی بجائے ممکن بنائے۔
اپنے پراجیکٹس صرف حقیقی نظم و نسق، چنے ہوئے لائسنس، محفوظ trademark، اور مربوط سیکیورٹی افشا کے ساتھ جاری کریں، یا بالکل جاری نہ کریں۔
ان نازک maintainers کو فنڈ اور مدد دیں جن پر آپ کا production نظام ٹکا ہے، کیونکہ مشترکہ خود کفیل نہیں۔
اوپن سورس کا تعاون کمپنی کے اندر لانے کو InnerSource لاگو کریں، اور حکومت میں ڈیفالٹ کھلا رکھیں، ڈیفالٹ شائع کریں، اور بنانے سے پہلے دوبارہ استعمال کریں۔

حوالہ جات اور مزید مطالعہ

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labour Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
U.S. Federal Source Code Policy and Code.gov guidance