سرکاری شعبے میں سافٹ ویئر انجینئرنگ اور پلیٹ فارم

عوامی قدر میں یہ کیوں اہم ہے

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

اس موضوع کو چلانے والی کشمکش ساختی ہے۔ سافٹ ویئر فطری طور پر تدریجی ہے — ضروریات اس وقت واضح ہوتی ہیں جب صارفین کام کرتے نظام سے تعامل کرتے ہیں، اور بہترین انجینئرنگ کی مشق یہ ہے کہ کچھ چھوٹا بنایا جائے، سیکھا جائے، اور ڈھلا جائے۔ عوامی خریداری اور جوابدہی کے چکر (دیکھیں موضوع 3.7 — عوامی خریداری اور کمیشننگ)، اس کے برعکس، سرمایہ جاتی کاموں اور دفاعی معاہدوں کے لیے بنے تھے: مقررہ وضاحت، ایک بڑا ایوارڈ، سنگِ میل کی ادائیگیاں، اور ڈیلیوری شروع ہونے سے برسوں پہلے منظور شدہ کاروباری مقدمہ۔ جب مقننہ یا آڈیٹر مقررہ قیمت، مقررہ دائرے کے معاہدے کی توقع رکھے اور انجینئرنگ ٹیم کو پہلی ریلیز کے بعد راستہ بدلنے کی ضرورت ہو تو عدم مطابقت دائرے کے پھیلاؤ، بجٹ سے تجاوز، یا ایسے نظام کے طور پر ظاہر ہوتی ہے جو 2019 میں درست وضاحت کیا گیا اور اس کے ڈیلیور ہونے تک متروک ہو چکا۔

وہ پلیٹ فارم جنہیں بنانے کے لیے اس موضوع کی انجینئرنگ کی مشق موجود ہے — مشترکہ شناختی نظام، ادائیگی کی راہیں، محکموں میں دوبارہ استعمال ہونے والے کیس مینجمنٹ کے آلات — موضوع 5.1 کا مضمون ہیں (دیکھیں موضوع 5.1 — ڈیجیٹل حکومت اور ڈیجیٹل تبدیلی)؛ یہ موضوع اس سافٹ ویئر کو بنانے اور خریدنے کے نظم و ضبط کے بارے میں ہے جو کسی بھی ایسے پلیٹ فارم، یا کسی بھی واحد خدمت کو، معتبر، قابلِ تبدیل، اور اس عوامی ادارے کی ملکیت بناتا ہے جو اس پر انحصار کرتا ہے، اس سپلائر کی نہیں جس نے اتفاق سے اسے پہلے لکھا۔

بنیادی تصورات

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

تکنیکی قرض ایک استعارہ ہے، جو سافٹ ویئر انجینئر وارڈ کننگھم نے 1992 میں وضع کیا، اس زیادہ مکمل طریقے کے بجائے جو زیادہ وقت لیتا، سافٹ ویئر کو ابھی بھیجنے کے لیے فوری طریقہ چننے کی جمع شدہ لاگت کے لیے۔ تکنیکی قرض، مالیاتی قرض کی طرح، بذاتی طور پر لینا غلط نہیں — کننگھم کا اپنا نکتہ یہ تھا کہ کام کرتا کوڈ جلدی بھیجنا اور بعد میں اسے دوبارہ ترتیب دینا درست فیصلہ ہو سکتا ہے — مگر وہ قرض جو کبھی ادا نہ ہو سست ڈیلیوری، زیادہ نقائص، اور بڑھتے خطرے کی صورت میں سود جمع کرتا ہے، اور عوامی ادارہ جو اپنا قرض دیکھ نہیں سکتا وہ طے نہیں کر سکتا کہ اسے ادا کرے یا بڑھنے دے۔

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

سافٹ ویئر کی جدت کاری پرانے نظام کو موجودہ فن تعمیر، زبان، یا پلیٹ فارم پر تبدیل کرنے، دوبارہ لکھنے، یا منتقل کرنے کی عمومی اصطلاح ہے۔ سافٹ ویئر کی جدت کاری مکمل ازسرِنو تحریر سے لے کر زیادہ محتاط اختیارات جیسے وہی کوڈ جدید بنیادی ڈھانچے پر دوبارہ میزبانی تک پھیلی ہے، اور ان کے درمیان انتخاب تکنیکی کے ساتھ اتنا ہی خطرے کے انتظام کا فیصلہ ہے۔

اسٹرینگلر فگ نمونہ (strangler fig pattern) تدریجی جدت کاری کا طریقہ ہے، جس بیل کے نام پر جو میزبان درخت کے گرد اگتی اور آہستہ آہستہ اس کی جگہ لیتی ہے، جس میں نئی فعالیت پرانے نظام کے ساتھ بنائی جاتی ہے اور ٹریفک ٹکڑا ٹکڑا اس کی طرف موڑا جاتا ہے، پورے نظام کو ایک ہی بار کٹ اوور میں بدلنے کے بجائے۔ اسٹرینگلر فگ نمونہ اس لیے اہم ہے کہ یہ ہر اضافے کو پورے سروس کو نیچے لائے بغیر آزمانے، واپس لینے، یا روکنے دیتا ہے — بگ بینگ متبادل کے برعکس، جہاں پرانا نظام بند اور نیا ایک لمحے میں چالو ہوتا ہے اور اگر کچھ غلط ہو تو واپسی کا کوئی راستہ نہیں۔

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

آزاد اور اوپن سورس سافٹ ویئر وہ سافٹ ویئر ہے جو ایسے لائسنس کے تحت تقسیم ہوتا ہے جو صارفین کو سورس کوڈ استعمال کرنے، مطالعہ کرنے، ترمیم کرنے، اور دوبارہ تقسیم کرنے کی آزادی دیتا ہے۔ آزاد اور اوپن سورس سافٹ ویئر اوپن سورس بذریعہ ڈیفالٹ پالیسی کی بنیاد ہے، جس کے تحت عوامی ادارہ ڈیفالٹ طور پر وہ سورس کوڈ شائع کرتا ہے جو وہ کمیشن کرتا ہے جب تک کہ کوئی مخصوص وجہ — سلامتی کی حساسیت، تیسرے فریق کے حقوق — اسے روکنے کا جواز نہ دے؛ جواز عموماً یوں خلاصہ ہوتا ہے «عوامی رقم، عوامی کوڈ»: عوامی فنڈز سے ایک بار ادا شدہ سافٹ ویئر کو دوسرے دائرۂ اختیار میں، اسی مسئلے کو حل کرنے والے دوسرے عوامی ادارے کے ہاتھوں دوبارہ ادا کرنے کی ضرورت نہیں ہونی چاہیے۔

ڈیجیٹل عوامی اثاثہ (digital public good) کھلا سافٹ ویئر، ڈیٹا، یا مواد ہے، کھلے لائسنس کے تحت جاری، جو تجارتی منافع پیدا کرنے کے بجائے عوامی ترقی یا حکمرانی کے مقصد کو پورا کرنے میں مدد کے لیے ڈیزائن ہوا ہے۔ ڈیجیٹل عوامی اثاثے ایک حکومت کی اوپن سورس ریلیز کو وسیع تر، مشترکہ بنیادی ڈھانچے کا حصہ ازسرِنو بیان کرتے ہیں جس سے دیگر حکومتیں اور سول سوسائٹی کی تنظیمیں براہِ راست استفادہ کر سکتی ہیں، صرف اندرونی شفافیت کا اشارہ نہیں۔

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

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

بہترین طریقے

1. غیر امتیازی ضروریات کے لیے خریدنے کو ڈیفالٹ بنائیں، اور بنانا حقیقتاً منفرد چیز کے لیے محفوظ رکھیں۔ تنخواہ، ای میل، اور عمومی کیس مینجمنٹ کی ضروریات شاذ و نادر کسی دوسرے ادارے کی ضروریات سے اتنی مختلف ہوتی ہیں کہ مخصوص سافٹ ویئر کا جواز بنیں؛ صرف وہاں بنائیں جہاں ضرورت، پیمانہ، یا دہائیوں تک صلاحیت کے مالک ہونے اور اسے ارتقا دینے کی ضرورت اس سے حقیقتاً مختلف ہو جو منڈی پیش کرتی ہے۔
2. تکنیکی قرض کو اس سے پہلے نظر آنے والا بنائیں کہ طے کریں کتنا اٹھانا ہے۔ خدمت میں ہر نظام کے لیے معلوم شارٹ کٹ، مؤخر شدہ اصلاحات، اور غیر معاون انحصار کا رجسٹر رکھیں، مقررہ چکر پر جائزہ لیا جائے، تاکہ قرض ایک اور سال اٹھانا کسی کے نہ دیکھنے کے بجائے دانستہ سمجھوتہ ہو۔
3. اہم پرانے نظام سے نکلنے کے واحد راستے کے طور پر کبھی واحد، ناقابلِ واپسی کٹ اوور کا منصوبہ نہ بنائیں۔ اسٹرینگلر فگ نمونے جیسے تدریجی طریقوں کو ترجیح دیں جو ہر ٹکڑے کو آزمانے، الٹنے، اور بتدریج جاری کرنے دیتے ہیں؛ ایسے نظام کا بگ بینگ متبادل جس پر لاکھوں انحصار کرتے ہیں برسوں کا خطرہ ایک ہفتے کے اختتام میں مرتکز کرتا ہے جس میں کچھ ناکام ہو تو واپسی کا کوئی راستہ نہیں۔
4. جو سورس کوڈ آپ کا ادارہ لکھوانے کے لیے ادا کرتا ہے اسے ایسا اثاثہ سمجھیں جس کا وہ مالک ہے، کرائے کی خدمت نہیں۔ معاہدہ کرتے وقت سورس کوڈ ایسکرو یا مکمل ملکیت پر بات کریں، تنازع شروع ہونے کے بعد نہیں، کیونکہ آپ کی اہم خدمت کے کوڈ کی واحد کاپی رکھنے والا سپلائر ڈیزائن کے لحاظ سے وینڈر لاک اِن ہے۔
5. سورس کوڈ کو ڈیفالٹ طور پر کھلا شائع کریں، اور اسے روکنے کے لیے مخصوص جواز کا تقاضا کریں۔ مستقل مزاجی سے لاگو اوپن سورس بذریعہ ڈیفالٹ پالیسی ہر محکمے کے اپنی مرضی کے بنے سافٹ ویئر کو ایک بار کی لاگت کے بجائے مشترکہ بین الحکومتی اثاثہ بناتی ہے، اور بیرونی ماہرین کو وہ سلامتی کے نقائص ڈھونڈنے دیتی ہے جو اکیلی اندرونی ٹیم چھوڑ دیتی۔
6. سافٹ ویئر کے معاہدے ایسے لکھیں جو تدریجی ڈیلیوری کو قانونی بنائیں، محض تکنیکی طور پر ممکن نہیں۔ وہ معاہدہ جو صرف دستخط پر طے شدہ مقررہ وضاحت کے مقابل ادائیگی کرتا ہے ٹیم کو ایماندار چست مشق اور معاہداتی تعمیل کے درمیان انتخاب پر مجبور کرتا ہے؛ آخر میں ایک سنگِ میل کے بجائے مظاہرہ شدہ کام کرتے سافٹ ویئر سے بندھے مرحلہ وار فنڈنگ کے دروازے استعمال کریں۔
7. جدت کاری کی فنڈنگ کو ایک بار کے سرمایہ جاتی منصوبے کے بجائے مسلسل پروگرام کے طور پر کریں۔ پرانا نظام جو ایک بار جدید بنا کر مزید بیس سال چھوڑ دیا جائے وہی خطرہ جمع کرتا ہے جس سے شروع ہوا تھا؛ مسلسل، تدریجی تجدید کے لیے بجٹ بنائیں جیسے سڑک کا ادارہ نئی تہہ کے لیے بجٹ بناتا ہے، نسل میں ایک بار عظیم متبادل کے لیے نہیں۔
8. تجارتی سافٹ ویئر خریدتے وقت بھی کھلے معیار اور منتقل پذیر ڈیٹا فارمیٹ منتخب کریں۔ سپلائر کے نظام سے کھلے، دستاویزی فارمیٹس میں ڈیٹا ذخیرہ اور برآمد کرنے کا تقاضا کرنا منتقلی کی لاگت کم رکھتا ہے چاہے سافٹ ویئر خود ملکیتی ہو، اور اکثر لاک اِن کے خلاف اس اصرار سے زیادہ قابلِ حصول قریبی حفاظت ہے کہ ہر نظام اوپن سورس ہو۔
9. مکمل دائرے کا عزم کرنے سے پہلے کم از کم قابلِ عمل مصنوع بنائیں اور حقیقی صارفین کو دکھائیں۔ حقیقتاً کم سے کم ورژن جاری کرنا، پھر جو سیکھا اس پر تدریجی بہتری، غلط مفروضوں کو اس وقت پکڑتا ہے جب انہیں ٹھیک کرنا ابھی سستا ہے، ان کے مقابل مکمل پیمانے کا نظام بن جانے کے بعد نہیں۔
10. ذہین خریدار بننے کے لیے کافی اندرونی انجینئرنگ کی صلاحیت برقرار رکھیں، چاہے ڈیلیوری ٹھیکے پر ہو۔ عوامی ادارہ جس نے اپنی تکنیکی مہارت کھوکھلی کر دی ہو سپلائر کی تجویز جانچ نہیں سکتا، مصیبت زدہ منصوبے کی ابتدائی انتباہی علامات نہیں دیکھ سکتا، یا لاک اِن سے نکلنے کی بات چیت نہیں کر سکتا، کاغذ پر اس کے خریداری کے قواعد کچھ بھی کہیں۔
11. پرانے نظام کے خطرے کی پروفائل کو اس کے صارف انٹرفیس سے پہلے ختم کریں۔ غیر معاون زبانوں، بغیر پیچ کے بنیادی ڈھانچے، اور غیر دستاویزی انضمام کو — وہ ناکامیاں جو بندش اور خلاف ورزیاں پیدا کرتی ہیں — بصری جدت کاری سے پہلے بدلنے کو ترجیح دیں جو عملیاتی طور پر کہیں کم خطرہ رکھتی ہے۔
12. ڈیلیوری کی صحت کو انجینئرنگ کے اشاریوں سے ناپیں، صرف بجٹ اور شیڈول کے فرق سے نہیں۔ تعیناتی کی تعدد، نقائص کی شرحیں، اور سب سے پرانے غیر حل شدہ تکنیکی قرض کی عمر حکمرانی کے بورڈ کو بتاتی ہے کہ پروگرام کامیاب ہوگا یا نہیں، اس سے زیادہ کہ وہ فی الحال بجٹ پر ہے، جو اکثر حرکت کرنے والا آخری اشاریہ ہے۔

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

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

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

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

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

کیا ہماری خریداری اور جوابدہی کا عمل واقعی ایماندار چست ڈیلیوری کی اجازت دیتا ہے، یا محض آبشار کے سنگِ میلوں کو اسپرنٹ کا نام دیتا ہے؟ یہ عام ہے کہ ٹیم برائے نام چست رسومات چلائے جبکہ اب بھی معاہدے کے دستخط پر طے شدہ مقررہ وضاحت کے مقابل فنڈ، حکمرانی، اور رپورٹ ہو، جو چست لیبل کے تحت آبشار کی ہر ناکامی کا طریقہ دوبارہ بناتا ہے۔ اس سوال کو ایک زندہ ڈیجیٹل پروگرام کو اس کے کاروباری مقدمے سے موجودہ حکمرانی کی رپورٹنگ تک کھوجنے اور پوچھنے کے لیے استعمال کریں کہ آیا فنڈنگ کا ڈھانچہ پروگرام کو حقیقی ابتدائی ریلیز سے سیکھے ہوئے کی بنیاد پر سمت بدلنے کی برداشت کرے گا۔ بحث کریں کہ تدریجی ڈیلیوری کو آرائشی کے بجائے حقیقی بنانے کے لیے پروگرام کی فنڈنگ اور رپورٹنگ کے طریقے میں کیا بدلنا ہوگا (دیکھیں موضوع 3.7 — عوامی خریداری اور کمیشننگ)۔

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

عملی صورت: عوامی قدر کی ایک مثال

ایک فرضی علاقائی حکومت — صرف مثال کے لیے، کسی حقیقی دائرۂ اختیار کی وضاحت نہیں — اپنے بے روزگاری کے فائدے کے دعوے ایسے نظام کے ذریعے چلاتی تھی جو تیس سال سے زیادہ پہلے لکھا گیا تھا، ان انجینئروں کی گھٹتی تعداد کے ذریعے برقرار جو اس کی اصل پروگرامنگ زبان سمجھتے تھے۔ دعووں کا حجم اس سے بہت بڑھ چکا تھا جس کا نظام کے ڈیزائنرز نے اندازہ لگایا تھا، رات کی پروسیسنگ کے رن بڑھتی تعداد میں صبح کے لین دین شروع ہونے سے پہلے مکمل ہونے میں ناکام رہتے تھے، اور ایجنسی کی ٹیکنالوجی قیادت نے خبردار کیا کہ فوائد کی ادائیگیوں کو متاثر کرنے والی غیر منصوبہ بند بندش اب «اگر» کا نہیں «کب» کا معاملہ ہے۔

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

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

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

چار شعبہ جاتی زاویے

مقامی حکومت

مقامی حکومت عموماً چند قومی پیمانے کے پلیٹ فارموں کے بجائے بڑی تعداد میں چھوٹے، غیر مربوط نظام چلاتی ہے، جس کا مطلب ہے کہ تکنیکی قرض ایک نظر آنے والے نمایاں نظام میں نہیں بلکہ بہت سی الگ سے خریدی، الگ سے برقرار رکھی درخواستوں میں جمع ہوتا ہے۔ مقامی اتھارٹیوں کے پاس عموماً حکومت کے کسی بھی درجے سے کم اندرونی انجینئرنگ کی صلاحیت ہوتی ہے، جو مخصوص بنانے کے بجائے قابلِ ترتیب عمومی سافٹ ویئر خریدنے کا مقدمہ خاص طور پر مضبوط بناتا ہے، اور مشترکہ علاقائی یا قومی پلیٹ فارم — موضوع 5.1 کا مضمون (دیکھیں موضوع 5.1 — ڈیجیٹل حکومت اور ڈیجیٹل تبدیلی) — کو ہر اتھارٹی کے الگ سے وہی صلاحیت دوبارہ بنانے سے بچنے کا خاص طور پر اعلیٰ قدر کا راستہ بناتا ہے۔

قومی حکومت

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

سماجی شعبہ اور غیر منافع بخش ادارے

غیر منافع بخش ادارے اور خیراتی تنظیمیں شاذ و نادر خود بڑے مخصوص پلیٹ فارم بناتی ہیں، مگر وہ اکثر حکومتی مالی معاون کے کمیشن یا لازمی کردہ سافٹ ویئر کی وصول کنندہ ہوتی ہیں — رپورٹنگ پورٹل، کیس مینجمنٹ کا نظام جسے گرانٹ یا معاہدہ انہیں استعمال کرنے کا تقاضا کرتا ہے — اس کے ڈیزائن، اس کے تکنیکی قرض، یا اس کے وینڈر پر بہت کم اثر کے ساتھ۔ سماجی شعبے کا ادارہ جو حکومت کے لازمی کردہ نظام پر منحصر ہے اس نظام کی ناکامی کے طریقے وراثت میں پاتا ہے بغیر انہیں ٹھیک کرنے کی کوئی بھی برتری وراثت میں پائے، جو ایک اور وجہ ہے کہ نتائج پر مبنی فنڈنگ کے رشتوں کو صرف نتیجے کے پیمانے ہی نہیں بلکہ لازمی ٹیکنالوجی کے عملیاتی بوجھ کا حساب رکھنا ہوگا (دیکھیں موضوع 3.7 — عوامی خریداری اور کمیشننگ)۔

کثیر فریقی اور بین الاقوامی ادارے

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

ناکامی کے عام طریقے

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

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

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

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

پائیداری کے منصوبے کے بغیر اوپن سورس پالیسی۔ عوامی ادارہ اوپن سورس بذریعہ ڈیفالٹ پالیسی کو پورا کرنے کے لیے سورس کوڈ شائع کرتا ہے مگر ریلیز کو ایک بار کا تعمیل کا قدم سمجھتا ہے، بیرونی تعاون کا جائزہ لینے، کمزوریوں کو پیچ کرنے، یا دستاویزات برقرار رکھنے کے لیے کوئی وسائل نہیں دیتا۔ لاگت شائع شدہ ریپوزیٹری ہے جو کھلی لگتی ہے مگر غیر برقرار مردہ سرے کے طور پر کام کرتی ہے، جو وسیع تر اوپن سورس بذریعہ ڈیفالٹ پروگرام کے اعتماد کو کبھی شائع نہ کرنے سے زیادہ نقصان پہنچاتی ہے۔

پختگی کا نمونہ

فہرستِ جانچ

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

بنیادی ماخذ

• GOV.UK Service Standard، گورنمنٹ ڈیجیٹل سروس، برطانیہ — قومی ڈیجیٹل خدمت کا معیار جو عوامی خدمات کے لیے تدریجی، صارف مرکوز ڈیلیوری اور کھلے معیار کا تقاضا کرتا ہے۔
• آفس آف مینجمنٹ اینڈ بجٹ، Federal Source Code Policy (M-16-21)، ریاستہائے متحدہ — وفاقی پالیسی جو ایجنسیوں سے مخصوص طور پر تیار کردہ سرکاری سافٹ ویئر کے دوبارہ استعمال اور اوپن سورس ریلیز پر غور کرنے کا تقاضا کرتی ہے۔
• فری سافٹ ویئر فاؤنڈیشن یورپ، Public Money, Public Code مہم — عوامی طور پر فنڈ شدہ سافٹ ویئر کا سورس کوڈ آزاد اور اوپن سورس لائسنس کے تحت جاری کرنے کا جواز، جو یورپی سامعین کے لیے تیار کیا گیا۔
• وارڈ کننگھم، "The WyCash Portfolio Management System" (OOPSLA 1992 کی تجرباتی رپورٹ) — تکنیکی قرض کے استعارے کا اصل بیان۔
• Digital Public Goods Alliance — کئی فریقوں پر مشتمل اقدام جو عوامی ترقی کے مقاصد کی خدمت کے لیے ڈیزائن کردہ کھلے سافٹ ویئر، ڈیٹا، اور مواد کے لیے معیار اور رجسٹری برقرار رکھتا ہے۔

حوالہ جات

1. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
2. Ward Cunningham — Wikipedia — https://en.wikipedia.org/wiki/Ward_Cunningham
3. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
4. COBOL — Wikipedia — https://en.wikipedia.org/wiki/COBOL
5. Software modernization — Wikipedia — https://en.wikipedia.org/wiki/Software_modernization
6. Strangler fig pattern — Wikipedia — https://en.wikipedia.org/wiki/Strangler_fig_pattern
7. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
8. Free and open-source software — Wikipedia — https://en.wikipedia.org/wiki/Free_and_open-source_software
9. Digital public good — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_good
10. Agile software development — Wikipedia — https://en.wikipedia.org/wiki/Agile_software_development
11. Waterfall model — Wikipedia — https://en.wikipedia.org/wiki/Waterfall_model
12. Minimum viable product — Wikipedia — https://en.wikipedia.org/wiki/Minimum_viable_product
13. Service Standard — GOV.UK, Government Digital Service — https://www.gov.uk/service-manual/service-standard
14. Requirements for Achieving Efficiency, Transparency, and Innovation Through Reusable and Open Source Software (M-16-21) — Digital.gov, Office of Management and Budget — https://digital.gov/resources/requirements-for-achieving-efficiency-transparency-and-innovation-through-reusable-and-open-source-software/
15. Public Money, Public Code — Free Software Foundation Europe — https://publiccode.eu/
16. "The WyCash Portfolio Management System" (OOPSLA 1992 experience report) — Ward Cunningham — http://c2.com/doc/oopsla92.html
17. Digital Public Goods Alliance — https://digitalpublicgoods.net/