اس ہفتے سینٹ پیٹرزبرگ میں آئی ٹی فیسٹیول کا انعقاد کیا جائے گا۔ . مقررین میں سے ایک رچرڈ اسٹال مین ہوں گے۔ فیسٹیول میں بھی شرکت کرتا ہے، اور یقیناً ہم مفت سافٹ ویئر کے موضوع کو نظر انداز نہیں کر سکتے تھے۔ اسی لیے ہماری ایک رپورٹ طلب کی جاتی ہے۔ . یہ ایک اوپن سورس پروجیکٹ کے طور پر Embox کی ترقی کی تاریخ کے لیے وقف ہوگا۔ اس مضمون میں میں ان اہم خیالات کے بارے میں بات کرنا چاہتا ہوں جو میری رائے میں اوپن سورس پروجیکٹس کی ترقی کو متاثر کرتے ہیں۔ رپورٹ کی طرح مضمون بھی ذاتی تجربے پر مبنی ہے۔
آئیے اوپن سورس کی اصطلاح کی تعریف کے ساتھ، کچھ آسان کے ساتھ شروع کریں۔ ظاہر ہے، اوپن سورس پروجیکٹ ایک ایسا پروجیکٹ ہوتا ہے جس میں ایک لائسنس ہوتا ہے جو پروجیکٹ کے سورس کوڈ تک رسائی کی اجازت دیتا ہے۔ اس کے علاوہ، ایک کھلے منصوبے کا مطلب ہے کہ تیسرے فریق کے ڈویلپر تبدیلیاں کر سکتے ہیں۔ یعنی، اگر کوئی کمپنی یا ڈویلپر اپنی پروڈکٹ کا کوڈ جزوی طور پر یا مکمل طور پر شائع کرتا ہے، تو یہ ابھی تک اس پروڈکٹ کو اوپن سورس پروجیکٹ نہیں بناتا ہے۔ اور آخر میں، کسی بھی پروجیکٹ کی سرگرمی کو کسی نہ کسی طرح کا نتیجہ ضرور نکلنا چاہیے، اور پروجیکٹ کی کشادگی کا مطلب یہ ہے کہ یہ نتیجہ نہ صرف خود ڈویلپر استعمال کرتے ہیں۔
ہم کھلے لائسنس کے مسائل پر ہاتھ نہیں ڈالیں گے۔ یہ بہت بڑا اور پیچیدہ موضوع ہے جس کے لیے گہرائی سے تفتیش کی ضرورت ہے۔ اس موضوع پر کافی اچھے مضامین اور مواد لکھا گیا ہے۔ لیکن چونکہ میں خود کاپی رائٹ کے شعبے کا ماہر نہیں ہوں، اس لیے میں صرف اتنا کہوں گا کہ لائسنس کو پروجیکٹ کے اہداف کو پورا کرنا چاہیے۔ مثال کے طور پر، Embox کے لیے GPL لائسنس کے بجائے BSD کا انتخاب حادثاتی نہیں تھا۔
حقیقت یہ ہے کہ اوپن سورس پروجیکٹ کو تبدیلیاں کرنے اور اوپن سورس پروجیکٹ کی ترقی پر اثر انداز ہونے کی صلاحیت فراہم کرنی چاہئے اس کا مطلب یہ ہے کہ پروجیکٹ تقسیم کیا گیا ہے۔ اس کا نظم و نسق، سالمیت اور کارکردگی کو برقرار رکھنا سنٹرلائزڈ مینجمنٹ والے پروجیکٹ کے مقابلے میں بہت مشکل ہے۔ ایک معقول سوال یہ پیدا ہوتا ہے کہ پراجیکٹس کیوں کھولے جاتے ہیں؟ اس کا جواب تجارتی فزیبلٹی کے علاقے میں ہے؛ ایک مخصوص طبقے کے منصوبوں کے لیے، اس نقطہ نظر کے فوائد لاگت سے کہیں زیادہ ہیں۔ یعنی، یہ تمام منصوبوں کے لیے موزوں نہیں ہے اور ایک کھلا نقطہ نظر عام طور پر قابل قبول ہے۔ مثال کے طور پر، کھلے اصول پر مبنی پاور پلانٹ یا ہوائی جہاز کے لیے کنٹرول سسٹم تیار کرنے کا تصور کرنا مشکل ہے۔ نہیں، یقیناً، ایسے نظاموں میں کھلے منصوبوں پر مبنی ماڈیولز شامل ہونے چاہئیں، کیونکہ اس سے بہت سے فوائد حاصل ہوں گے۔ لیکن حتمی مصنوع کے لیے کسی کو ذمہ دار ہونا چاہیے۔ یہاں تک کہ اگر سسٹم مکمل طور پر اوپن پروجیکٹس کے کوڈ پر مبنی ہے، ڈویلپر، ہر چیز کو ایک سسٹم میں پیک کر کے اور مخصوص بلڈ اور سیٹنگز بنا کر اسے لازمی طور پر بند کر دیتا ہے۔ کوڈ عوامی طور پر دستیاب ہوسکتا ہے۔
ان سسٹمز کے لیے اوپن سورس پروجیکٹس بنانے یا ان میں تعاون کرنے سے بھی بہت سے فوائد ہیں۔ جیسا کہ میں پہلے ہی کہہ چکا ہوں، اینڈ سسٹم کوڈ عوامی طور پر دستیاب رہ سکتا ہے۔ کیوں، کیونکہ یہ ظاہر ہے کہ اس بات کا امکان نہیں ہے کہ سسٹم کو جانچنے کے لیے کسی کے پاس ایک ہی ہوائی جہاز ہو۔ یہ سچ ہے، لیکن ہو سکتا ہے کوئی ایسا شخص ہو جو کوڈ کے کچھ حصوں کو چیک کرنا چاہتا ہو، یا، مثال کے طور پر، کسی کو معلوم ہو سکتا ہے کہ جو لائبریری استعمال کی جا رہی ہے وہ بالکل درست طریقے سے ترتیب نہیں دی گئی ہے۔
اس سے بھی بڑا فائدہ ظاہر ہوتا ہے اگر کمپنی سسٹم کے کچھ بنیادی حصے کو الگ پروجیکٹ میں مختص کرتی ہے۔ مثال کے طور پر، کسی قسم کے ڈیٹا ایکسچینج پروٹوکول کو سپورٹ کرنے کے لیے ایک لائبریری۔ اس صورت میں، یہاں تک کہ اگر پروٹوکول کسی مخصوص موضوع کے لیے مخصوص ہے، آپ اس نظام کے اس حصے کو برقرار رکھنے کے اخراجات اس علاقے کی دوسری کمپنیوں کے ساتھ بانٹ سکتے ہیں۔ اس کے علاوہ، ماہرین جو عوامی ڈومین میں نظام کے اس ٹکڑے کا مطالعہ کر سکتے ہیں، انہیں مؤثر طریقے سے استعمال کرنے کے لیے بہت کم وقت درکار ہوتا ہے۔ اور آخر میں، ایک ٹکڑے کو ایک آزاد ہستی میں الگ کرنا جسے فریق ثالث کے ڈویلپرز استعمال کرتے ہیں ہمیں اس حصے کو بہتر بنانے کی اجازت دیتا ہے، کیونکہ ہمیں موثر APIs پیش کرنے، دستاویزات بنانے کی ضرورت ہے، اور میں ٹیسٹ کوریج کو بہتر بنانے کی بات بھی نہیں کر رہا ہوں۔
ایک کمپنی اوپن سورس پروجیکٹس بنائے بغیر تجارتی فوائد حاصل کرسکتی ہے؛ اس کے ماہرین کے لیے کمپنی میں استعمال ہونے والے تھرڈ پارٹی پروجیکٹس میں حصہ لینا کافی ہے۔ بہر حال، تمام فوائد باقی ہیں: ملازمین پراجیکٹ کو بہتر طور پر جانتے ہیں، اس لیے وہ اسے زیادہ مؤثر طریقے سے استعمال کرتے ہیں، کمپنی پروجیکٹ کی ترقی کی سمت کو متاثر کر سکتی ہے، اور ریڈی میڈ، ڈیبگڈ کوڈ کا استعمال ظاہر ہے کمپنی کے اخراجات کو کم کرتا ہے۔
اوپن سورس پروجیکٹس بنانے کے فوائد وہیں ختم نہیں ہوتے ہیں۔ آئیے کاروبار کے ایک اہم جز کو مارکیٹنگ کے طور پر لیتے ہیں۔ اس کے لیے، یہ ایک بہت اچھا سینڈ باکس ہے جو اسے مارکیٹ کی ضروریات کو مؤثر طریقے سے جانچنے کی اجازت دیتا ہے۔
اور یقیناً، ہمیں یہ نہیں بھولنا چاہیے کہ اوپن سورس پروجیکٹ اپنے آپ کو کسی بھی مہارت کے کیریئر کے طور پر اعلان کرنے کا ایک مؤثر طریقہ ہے۔ کچھ معاملات میں، مارکیٹ میں داخل ہونے کا یہ واحد راستہ ہے۔ مثال کے طور پر، Embox ایک RTOS بنانے کے منصوبے کے طور پر شروع ہوا۔ شاید یہ بتانے کی ضرورت نہیں ہے کہ بہت سارے حریف ہیں۔ ایک کمیونٹی بنائے بغیر، ہمارے پاس پراجیکٹ کو آخری صارف تک پہنچانے کے لیے کافی وسائل نہیں ہوتے، یعنی تھرڈ پارٹی ڈویلپرز کے لیے پروجیکٹ کا استعمال شروع کرنا۔
اوپن سورس پروجیکٹ میں کمیونٹی کلیدی حیثیت رکھتی ہے۔ یہ آپ کو پراجیکٹ مینجمنٹ کے اخراجات کو نمایاں طور پر کم کرنے، پراجیکٹ کی ترقی اور معاونت کرنے کی اجازت دیتا ہے۔ ہم کہہ سکتے ہیں کہ کمیونٹی کے بغیر کوئی اوپن سورس پروجیکٹ بالکل نہیں ہے۔
اوپن سورس پروجیکٹ کمیونٹی کو بنانے اور اس کا انتظام کرنے کے طریقے کے بارے میں بہت سا مواد لکھا گیا ہے۔ پہلے سے معلوم حقائق کو دوبارہ نہ بتانے کے لیے، میں Embox کے تجربے پر توجہ مرکوز کرنے کی کوشش کروں گا۔ مثال کے طور پر کمیونٹی بنانے کا عمل ایک بہت ہی دلچسپ مسئلہ ہے۔ یعنی، بہت سے لوگ یہ بتاتے ہیں کہ موجودہ کمیونٹی کو کس طرح منظم کیا جائے، لیکن اس کی تخلیق کے لمحات کو بعض اوقات نظر انداز کر دیا جاتا ہے، اس پر غور کیا جاتا ہے۔
اوپن سورس پروجیکٹ کمیونٹی بناتے وقت بنیادی اصول یہ ہے کہ کوئی اصول نہیں ہیں۔ میرا مطلب ہے کہ کوئی آفاقی اصول نہیں ہیں، جیسے کہ کوئی چاندی کی گولی نہیں ہے، اگر صرف اس وجہ سے کہ منصوبے بہت مختلف ہیں۔ یہ امکان نہیں ہے کہ آپ js لاگنگ لائبریری اور کچھ انتہائی ماہر ڈرائیور کے لیے کمیونٹی بناتے وقت وہی اصول استعمال کر سکتے ہیں۔ اس کے علاوہ، منصوبے کی ترقی کے مختلف مراحل میں (اور اس وجہ سے کمیونٹی)، قوانین تبدیل ہوتے ہیں.
Embox ایک طالب علم کے منصوبے کے طور پر شروع ہوا کیونکہ اسے سسٹم پروگرامنگ ڈیپارٹمنٹ کے طلباء تک رسائی حاصل تھی۔ درحقیقت ہم کسی اور کمیونٹی میں داخل ہو رہے تھے۔ ہم اس کمیونٹی کے شرکاء، طلباء، ان کی خصوصیت، سسٹم پروگرامنگ، کورس ورک اور ڈپلوموں کے شعبے میں سائنسی کام میں اچھے صنعتی عمل میں دلچسپی لے سکتے ہیں۔ یعنی، ہم نے کمیونٹی کو منظم کرنے کے بنیادی اصولوں میں سے ایک کی پیروی کی: کمیونٹی کے اراکین کو کچھ وصول کرنا چاہیے، اور یہ قیمت شرکت کنندہ کے تعاون کے مطابق ہونی چاہیے۔
Embox کے لیے اگلا مرحلہ تھرڈ پارٹی صارفین کی تلاش تھا۔ یہ سمجھنا بہت ضروری ہے کہ صارفین اوپن سورس کمیونٹی میں مکمل شریک ہیں۔ عام طور پر ڈویلپرز سے زیادہ صارفین ہوتے ہیں۔ اور کسی پروجیکٹ میں شراکت دار بننے کے لیے، وہ پہلے اسے کسی نہ کسی طریقے سے استعمال کرنا شروع کر دیتے ہیں۔
Embox کے پہلے صارفین نظریاتی سائبرنیٹکس ڈیپارٹمنٹ تھے۔ انہوں نے Lego Mindstorm کے لیے متبادل فرم ویئر بنانے کا مشورہ دیا۔ اور اگرچہ یہ اب بھی مقامی صارفین تھے (ہم ان سے ذاتی طور پر مل سکتے تھے اور اس پر بات کر سکتے تھے کہ وہ کیا چاہتے ہیں)۔ لیکن یہ پھر بھی بہت اچھا تجربہ تھا۔ مثال کے طور پر، ہم نے ایسے ڈیمو تیار کیے جو دوسروں کو دکھائے جاسکتے ہیں، کیونکہ روبوٹ تفریحی ہوتے ہیں اور توجہ مبذول کرتے ہیں۔ نتیجے کے طور پر، ہمیں واقعی تیسرے فریق کے صارفین ملے جنہوں نے پوچھنا شروع کیا کہ Embox کیا ہے اور اسے کیسے استعمال کیا جائے۔
اس مرحلے پر، ہمیں دستاویزات کے بارے میں، صارفین کے ساتھ رابطے کے ذرائع کے بارے میں سوچنا پڑا۔ نہیں، یقینا، ہم نے ان اہم چیزوں کے بارے میں پہلے سوچا تھا، لیکن یہ قبل از وقت تھا اور اس نے مثبت اثر نہیں دیا۔ اس کا اثر کافی منفی تھا۔ میں آپ کو ایک دو مثالیں دیتا ہوں۔ ہم نے گوگل کوڈ استعمال کیا، جس کی ویکی نے کثیر لسانی کی حمایت کی۔ ہم نے کئی زبانوں میں صفحات بنائے، نہ صرف انگریزی اور روسی، جن میں ہم مشکل سے بات چیت کر سکتے تھے، بلکہ جرمن اور ہسپانوی بھی۔ نتیجے کے طور پر، ان زبانوں میں پوچھنے پر یہ بہت مضحکہ خیز لگتا ہے، لیکن ہم بالکل جواب نہیں دے سکتے ہیں. یا انہوں نے دستاویزات لکھنے اور تبصرہ کرنے کے بارے میں قواعد متعارف کرائے، لیکن چونکہ API اکثر اور نمایاں طور پر تبدیل ہوتا ہے، اس لیے یہ معلوم ہوا کہ ہماری دستاویزات پرانی تھیں اور اس سے زیادہ گمراہ کن تھیں۔
نتیجے کے طور پر، ہماری تمام کوششیں، یہاں تک کہ غلط بھی، بیرونی صارفین کی ظاہری شکل کا باعث بنیں۔ اور یہاں تک کہ ایک تجارتی گاہک نمودار ہوا جو چاہتا تھا کہ اس کے لیے اس کا اپنا RTOS تیار کیا جائے۔ اور ہم نے اسے تیار کیا کیونکہ ہمارے پاس تجربہ اور کچھ بنیادی کام ہے۔ یہاں آپ کو اچھے لمحات اور برے دونوں کے بارے میں بات کرنے کی ضرورت ہے۔ میں برے لوگوں سے شروع کروں گا۔ چونکہ بہت سے ڈویلپر اس پروجیکٹ میں تجارتی بنیادوں پر شامل تھے، اس لیے کمیونٹی پہلے ہی کافی غیر مستحکم اور منقسم تھی، جو یقیناً اس منصوبے کی ترقی کو متاثر نہیں کر سکتی تھی۔ ایک اضافی عنصر یہ تھا کہ پروجیکٹ کی سمت ایک تجارتی گاہک نے طے کی تھی، اور اس کا مقصد پروجیکٹ کی مزید ترقی نہیں تھا۔ کم از کم یہ بنیادی مقصد نہیں تھا۔
دوسری طرف، بہت سے مثبت پہلو تھے. ہمارے پاس واقعی تھرڈ پارٹی صارفین ہیں۔ یہ نہ صرف گاہک تھا بلکہ وہ بھی جن کے لیے یہ نظام بنایا گیا تھا۔ منصوبے میں حصہ لینے کا حوصلہ بڑھا ہے۔ بہر حال، اگر آپ کسی دلچسپ کاروبار سے بھی پیسہ کما سکتے ہیں، تو یہ ہمیشہ اچھا ہوتا ہے۔ اور سب سے اہم بات یہ ہے کہ ہم نے صارفین کی طرف سے ایک خواہش سنی، جو اس وقت ہمیں پاگل لگتی تھی، لیکن جو اب ایمباکس کا بنیادی خیال ہے، یعنی سسٹم میں پہلے سے تیار شدہ کوڈ کو استعمال کرنا۔ اب Embox کا بنیادی خیال لینکس کے بغیر لینکس سافٹ ویئر استعمال کرنا ہے۔ یعنی، پروجیکٹ کی مزید ترقی میں اہم مثبت پہلو یہ احساس تھا کہ اس پروجیکٹ کو تھرڈ پارٹی صارفین استعمال کرتے ہیں، اور اس سے ان کے کچھ مسائل حل ہونے چاہییں۔
اس وقت، Embox پہلے ہی طالب علم کے منصوبے کے دائرہ کار سے باہر چلا گیا تھا۔ طلباء کے ماڈل کے مطابق پروجیکٹ کی ترقی میں اہم محدود عنصر شرکاء کی حوصلہ افزائی ہے۔ طالب علم اس وقت حصہ لیتے ہیں جب وہ پڑھ رہے ہوتے ہیں، اور جب وہ فارغ التحصیل ہوتے ہیں، تو ایک مختلف حوصلہ افزائی ہونی چاہیے۔ اگر حوصلہ افزائی ظاہر نہیں ہوتی ہے، تو طالب علم اس منصوبے میں حصہ لینا چھوڑ دیتا ہے۔ اگر ہم اس بات کو مدنظر رکھیں کہ طلباء کو سب سے پہلے تربیت دینے کی ضرورت ہے، تو یہ پتہ چلتا ہے کہ وہ فارغ التحصیل ہونے تک اچھے ماہر بن جاتے ہیں، لیکن ناتجربہ کاری کی وجہ سے اس منصوبے میں ان کا تعاون بہت زیادہ نہیں ہے۔
عام طور پر، ہم آسانی سے مرکزی نقطہ کی طرف بڑھتے ہیں جو ہمیں ایک اوپن سورس پروجیکٹ بنانے کے بارے میں بات کرنے کی اجازت دیتا ہے - ایک ایسی پروڈکٹ بنانا جو اس کے صارفین کے مسائل کو حل کرے۔ جیسا کہ میں نے اوپر بیان کیا ہے، اوپن سورس پروجیکٹ کی اصل خاصیت اس کی کمیونٹی ہے۔ مزید برآں، کمیونٹی کے ارکان بنیادی طور پر صارف ہیں۔ لیکن جب استعمال کرنے کے لیے کچھ نہیں ہے تو وہ کہاں سے آئیں گے؟ تو یہ پتہ چلتا ہے کہ، بالکل ایک غیر اوپن سورس پروجیکٹ کی طرح، آپ کو ایک MVP (کم سے کم قابل عمل پروڈکٹ) بنانے پر توجہ مرکوز کرنے کی ضرورت ہے، اور اگر اس میں صارفین کو دلچسپی ہے، تو پروجیکٹ کے ارد گرد ایک کمیونٹی نمودار ہوگی۔ اگر آپ صرف کمیونٹی PR کے ذریعے کمیونٹی بنانے میں مصروف ہیں، دنیا کی تمام زبانوں میں وکی لکھ رہے ہیں، یا گیتھب پر گٹ ورک فلو کو درست کر رہے ہیں، تو پروجیکٹ کے ابتدائی مراحل میں اس سے کوئی فرق نہیں پڑتا۔ یقیناً مناسب مراحل پر یہ نہ صرف اہم بلکہ ضروری چیزیں بھی ہیں۔
آخر میں میں اشارہ کرنا چاہوں گا۔ ، میری رائے میں، اوپن سورس پروجیکٹ سے صارف کی توقعات کی عکاسی کرتا ہے:
میں سنجیدگی سے اس OS پر سوئچ کرنے کے بارے میں سوچ رہا ہوں (کم از کم کوشش کریں۔ وہ فعال طور پر اس کا تعاقب کر رہے ہیں اور اچھی چیزیں کر رہے ہیں)۔
PS آن ہمارے پاس زیادہ سے زیادہ تین رپورٹیں ہوں گی۔ ایک اوپن سورس کے بارے میں اور دو ایمبیڈڈ کے بارے میں (اور ایک عملی ہے)۔ اسٹینڈ پر ہم پروگرامنگ مائیکرو کنٹرولرز کے استعمال پر ایک ماسٹر کلاس کا انعقاد کریں گے۔ . ہمیشہ کی طرح، ہم ہارڈ ویئر لائیں گے اور آپ کو پروگرام کرنے دیں گے۔ تلاش اور دیگر سرگرمیاں بھی ہوں گی۔ میلے میں آئیں اور ہمارا موقف، مزہ آئے گا۔
ماخذ: www.habr.com