هڪ آئي ٽي ميلو هن هفتي سينٽ پيٽرسبرگ ۾ منعقد ڪيو ويندو . ڳالهائيندڙن مان هڪ هوندو رچرڊ اسٽالمن. فيسٽيول ۾ پڻ حصو وٺندو آهي، ۽ يقينا اسان مفت سافٽ ويئر جي موضوع کي نظرانداز نه ڪري سگهون ٿا. انهي ڪري اسان جي رپورٽن مان هڪ کي سڏيو ويندو آهي . اهو هڪ اوپن سورس پروجيڪٽ جي طور تي Embox جي ترقي جي تاريخ لاءِ وقف ڪيو ويندو. هن آرٽيڪل ۾ آئون انهن بنيادي خيالن جي باري ۾ ڳالهائڻ چاهيان ٿو، جيڪي منهنجي خيال ۾، اوپن سورس منصوبن جي ترقي تي اثر انداز ڪن ٿا. مضمون، رپورٽ وانگر، ذاتي تجربو تي ٻڌل آهي.
اچو ته ڪجھ سادو سان شروع ڪريون، اصطلاح اوپن سورس جي تعريف سان. ظاهر آهي، هڪ اوپن سورس پروجيڪٽ هڪ پروجيڪٽ آهي جنهن ۾ هڪ لائسنس آهي جيڪو پروجيڪٽ جي سورس ڪوڊ تائين رسائي جي اجازت ڏئي ٿو. ان کان علاوه، هڪ کليل منصوبي جو مطلب آهي ته ٽئين پارٽي ڊولپرز تبديليون ڪري سگهن ٿيون. اھو آھي، جيڪڏھن ڪجھ ڪمپني يا ڊولپر پنھنجي پراڊڪٽ جو ڪوڊ شايع ڪري ٿو، جزوي يا مڪمل طور تي، اھو اڃا تائين ھن پراڊڪٽ کي اوپن سورس پروجيڪٽ نٿو بڻائي. ۽ آخرڪار، ڪنهن به منصوبي جي سرگرمي کي ڪجهه قسم جي نتيجن جي اڳواڻي ڪرڻ گهرجي، ۽ منصوبي جي آزاديء جو مطلب اهو آهي ته اهو نتيجو نه رڳو ڊولپرز طرفان استعمال ڪيو ويندو آهي.
اسان کليل لائسنس جي مسئلن تي هٿ نه ڪنداسين. هي تمام وڏو ۽ پيچيده موضوع آهي، جنهن ۾ گهڻي تحقيق جي ضرورت آهي. هن موضوع تي ڪافي سٺا مضمون ۽ مواد لکيو ويو آهي. پر جيئن ته مان پاڻ ڪاپي رائيٽ جي شعبي ۾ ماهر نه آهيان، مان صرف ايترو چوندس ته لائسنس منصوبي جي مقصدن کي پورو ڪرڻ گهرجي. مثال طور، ايمباڪس لاءِ BSD جو انتخاب هڪ GPL لائسنس جي بجاءِ حادثاتي نه هو.
حقيقت اها آهي ته هڪ اوپن سورس پروجيڪٽ کي تبديل ڪرڻ جي صلاحيت مهيا ڪرڻ گهرجي ۽ اوپن سورس پروجيڪٽ جي ترقي تي اثر انداز ٿئي ٿي ته اهو منصوبو ورهايو ويو آهي. ان کي منظم ڪرڻ، سالميت کي برقرار رکڻ ۽ ڪارڪردگي مرڪزي انتظام سان گڏ هڪ منصوبي جي مقابلي ۾ تمام گهڻو ڏکيو آهي. هڪ معقول سوال پيدا ٿئي ٿو: ڇو پراجيڪٽ کي کوليو وڃي؟ جواب تجارتي فزيبلٽي جي علائقي ۾ آهي؛ منصوبن جي هڪ خاص طبقي لاء، هن طريقي جا فائدا خرچن کان وڌيڪ آهن. اهو آهي، اهو سڀني منصوبن لاء مناسب ناهي ۽ هڪ کليل طريقو عام طور تي قابل قبول آهي. مثال طور، اهو تصور ڪرڻ ڏکيو آهي ته پاور پلانٽ يا هوائي جهاز لاء هڪ ڪنٽرول سسٽم ٺاهي هڪ کليل اصول جي بنياد تي. نه، يقينا، اهڙي سسٽم ۾ شامل ٿيڻ گهرجي ماڊلز جي بنياد تي کليل منصوبن تي، ڇاڪاڻ ته اهو ڪيترن ئي فائدن کي فراهم ڪندو. پر ڪنهن کي حتمي پيداوار لاء ذميوار هجڻ گهرجي. جيتوڻيڪ سسٽم مڪمل طور تي کليل منصوبن جي ڪوڊ تي ٻڌل آهي، ڊولپر، هر شي کي هڪ سسٽم ۾ پيڪ ڪيو ۽ مخصوص تعميرات ۽ سيٽنگون ٺاهي، لازمي طور تي ان کي بند ڪري ٿو. ڪوڊ عوامي طور تي دستياب ٿي سگھي ٿو.
اوپن سورس پروجيڪٽ ٺاهڻ يا ان ۾ حصو وٺڻ کان انهن سسٽم لاءِ پڻ ڪيترائي فائدا آهن. جيئن مون اڳ ۾ ئي چيو آهي، آخري سسٽم ڪوڊ عوامي طور تي دستياب ٿي سگهي ٿو. ڇو، ڇو ته اهو واضح آهي ته اهو ممڪن ناهي ته ڪنهن وٽ به ساڳيو جهاز هوندو سسٽم کي جانچڻ لاءِ. اهو سچ آهي، پر شايد ڪو ماڻهو هجي جيڪو ڪوڊ جي ڪجهه حصن کي چيڪ ڪرڻ چاهي، يا، مثال طور، ڪو ماڻهو ڳولي سگهي ٿو ته لائبريري جيڪا استعمال ڪئي پئي وڃي سا بلڪل صحيح ترتيب نه آهي.
اڃا به وڏو فائدو ظاهر ٿئي ٿو جيڪڏهن ڪمپني مختص ڪري ٿي سسٽم جو ڪجهه بنيادي حصو هڪ الڳ منصوبي ۾. مثال طور، هڪ لائبريري ڪجهه قسم جي ڊيٽا مٽائڻ واري پروٽوڪول کي سپورٽ ڪرڻ لاء. انهي صورت ۾، جيتوڻيڪ پروٽوڪول مخصوص موضوع واري علائقي لاء مخصوص آهي، توهان هن علائقي جي ٻين ڪمپنين سان سسٽم جي هن ٽڪري کي برقرار رکڻ جي قيمت کي حصيداري ڪري سگهو ٿا. ان کان علاوه، ماهرن جيڪي عوامي ڊومين ۾ سسٽم جي هن حصي جو مطالعو ڪري سگهن ٿا، ان کي مؤثر طريقي سان استعمال ڪرڻ لاء تمام گهٽ وقت جي ضرورت آهي. ۽ آخرڪار، هڪ ٽڪرا الڳ ڪرڻ هڪ آزاد ادارو ۾ جيڪو ٽئين پارٽي ڊولپرز استعمال ڪندا آهن اسان کي هن حصي کي بهتر بڻائڻ جي اجازت ڏئي ٿو، ڇو ته اسان کي موثر APIs پيش ڪرڻ جي ضرورت آهي، دستاويز ٺاهي، ۽ مان ٽيسٽ ڪوريج کي بهتر ڪرڻ بابت به نه ڳالهائي رهيو آهيان.
هڪ ڪمپني اوپن سورس پروجيڪٽ ٺاهڻ کان سواءِ تجارتي فائدا حاصل ڪري سگهي ٿي؛ اهو ڪافي آهي ان جي ماهرن لاءِ ڪمپني ۾ استعمال ٿيندڙ ٽئين پارٽي منصوبن ۾ حصو وٺڻ لاءِ. آخرڪار، سڀئي فائدا باقي آهن: ملازمن کي پروجيڪٽ کي بهتر ڄاڻو ٿا، تنهن ڪري اهي ان کي وڌيڪ اثرائتو استعمال ڪن ٿا، ڪمپني منصوبي جي ترقي جي هدايت تي اثر انداز ڪري سگهي ٿي، ۽ تيار ڪيل، ڊيبڊ ڪوڊ جو استعمال واضح طور تي ڪمپني جي قيمتن کي گھٽائي ٿو.
اوپن سورس پروجيڪٽ ٺاهڻ جا فائدا اتي ختم نٿا ٿين. اچو ته ڪاروبار جو هڪ اهم حصو وٺون جيئن مارڪيٽنگ. هن لاءِ، هي هڪ تمام سٺو سينڊ باڪس آهي جيڪو هن کي اجازت ڏئي ٿو ته مؤثر انداز سان مارڪيٽ جي گهرج جو جائزو وٺي.
۽ يقينا، اسان کي اهو نه وسارڻ گهرجي ته هڪ اوپن سورس پروجيڪٽ هڪ مؤثر طريقو آهي پاڻ کي ڪنهن به ماهر جي ڪيريئر طور اعلان ڪرڻ جو. ڪجهه حالتن ۾، اهو بازار ۾ داخل ٿيڻ جو واحد طريقو آهي. مثال طور، Embox هڪ منصوبي جي طور تي شروع ڪيو هڪ RTOS ٺاهڻ لاءِ. هتي شايد وضاحت ڪرڻ جي ڪا ضرورت ناهي ته اتي ڪيترائي مقابلا آهن. ڪميونٽي ٺاهڻ کان سواءِ، اسان وٽ ڪافي وسيلا نه هجن ها ته پروجيڪٽ کي آخري صارف تائين آڻي سگهون، يعني ٽئين پارٽي ڊولپرز لاءِ پراجيڪٽ کي استعمال ڪرڻ شروع ڪرڻ لاءِ.
ڪميونٽي هڪ اوپن سورس پروجيڪٽ ۾ اهم آهي. اهو توهان کي منصوبي جي انتظام جي خرچن کي خاص طور تي گهٽائڻ، پروجيڪٽ کي ترقي ۽ سپورٽ ڪرڻ جي اجازت ڏئي ٿو. اسان اهو چئي سگهون ٿا ته ڪميونٽي کان سواءِ ڪو به اوپن سورس پروجيڪٽ ناهي.
هڪ اوپن سورس پروجيڪٽ ڪميونٽي کي ڪيئن ٺاهيو ۽ منظم ڪرڻ بابت تمام گهڻو مواد لکيو ويو آهي. اڳ ۾ ئي ڄاڻايل حقيقتن کي ٻيهر نه ٻڌائڻ لاء، آئون ايمباڪس جي تجربي تي ڌيان ڏيڻ جي ڪوشش ڪندس. مثال طور، ڪميونٽي ٺاهڻ جو عمل هڪ تمام دلچسپ مسئلو آهي. اهو آهي، ڪيترائي ٻڌائين ٿا ته موجوده ڪميونٽي کي ڪيئن منظم ڪجي، پر ان جي تخليق جي لمحن کي ڪڏهن ڪڏهن نظر انداز ڪيو ويندو آهي، هن کي ڏنو ويو آهي.
بنيادي قاعدو جڏهن هڪ اوپن سورس پروجيڪٽ ڪميونٽي ٺاهيندي آهي ته ڪو به ضابطو ناهي. منهنجو مطلب آهي ته ڪي آفاقي ضابطا نه آهن، جيئن ته چانديء جي گولي ناهي، جيڪڏهن صرف ان ڪري ته منصوبا تمام مختلف آهن. اهو ممڪن ناهي ته توهان ساڳيا ضابطا استعمال ڪري سگهو ٿا جڏهن هڪ ڪميونٽي ٺاهڻ لاءِ js لاگنگ لائبريري ۽ ڪجهه انتهائي خاص ڊرائيور. ان کان علاوه، منصوبي جي ترقي جي مختلف مرحلن تي (۽ انهي ڪري ڪميونٽي)، ضابطن کي تبديل ڪري ٿو.
Embox هڪ شاگرد منصوبي جي طور تي شروع ڪيو ڇاڪاڻ ته ان کي سسٽم پروگرامنگ ڊپارٽمينٽ جي شاگردن تائين رسائي هئي. حقيقت ۾، اسان ڪنهن ٻئي ڪميونٽي ۾ داخل ٿي رهيا هئاسين. اسان هن ڪميونٽي جي شرڪت ڪندڙن کي دلچسپي ڏئي سگهون ٿا، شاگردن، سٺي صنعتي مشق ۾ انهن جي خاصيت ۾، سائنسي ڪم ۾ سسٽم پروگرامنگ، ڪورس ڪم ۽ ڊپلوما. اهو آهي، اسان هڪ ڪميونٽي کي منظم ڪرڻ جي بنيادي قاعدن مان هڪ تي عمل ڪيو آهي: ڪميونٽي جي ميمبرن کي ڪجهه وصول ڪرڻ گهرجي، ۽ اها قيمت شرڪت ڪندڙ جي مدد سان مطابقت رکي ٿي.
ايمباڪس لاءِ ايندڙ اسٽيج ٽئين پارٽي استعمال ڪندڙن جي ڳولا هئي. اهو سمجهڻ تمام ضروري آهي ته صارفين اوپن سورس ڪميونٽي ۾ مڪمل شرڪت ڪندڙ آهن. عام طور تي ڊولپرز کان وڌيڪ استعمال ڪندڙ آهن. ۽ انهي لاءِ ته ڪنهن منصوبي ۾ حصو وٺندڙ بڻجڻ چاهين، اهي پهريان ان کي ڪنهن نه ڪنهن طريقي سان استعمال ڪرڻ شروع ڪن ٿا.
ايمباڪس جا پهريان استعمال ڪندڙ نظرياتي سائبرنيڪس ڊپارٽمينٽ جا هئا. هنن Lego Mindstorm لاءِ متبادل فرم ویئر ٺاهڻ جي تجويز ڏني. ۽ جيتوڻيڪ اهي اڃا تائين مقامي صارف هئا (اسان انهن سان ذاتي طور تي ملن ٿا ۽ بحث ڪري سگهون ٿا جيڪي اهي چاهيندا هئا). پر اهو اڃا تائين تمام سٺو تجربو هو. مثال طور، اسان ڊيمو ٺاهيا آهن جيڪي ٻين کي ڏيکاري سگهجن ٿيون، ڇاڪاڻ ته روبوٽس مزيدار آهن ۽ ڌيان ڇڪائي رهيا آهن. نتيجي طور، اسان کي واقعي ٽئين پارٽي استعمال ڪندڙ مليا جن پڇڻ شروع ڪيو ايمباڪس ڇا آهي ۽ ان کي ڪيئن استعمال ڪجي.
هن مرحلي تي، اسان کي دستاويز جي باري ۾ سوچڻو پيو، صارفين سان رابطي جي ذريعن جي باري ۾. نه، يقينا، اسان انهن اهم شين بابت اڳ ۾ سوچيو، پر اهو وقت کان اڳ هو ۽ مثبت اثر نه ڏنو. اثر بلڪه منفي هو. مان توهان کي ڪجهه مثال ڏيان ٿو. اسان استعمال ڪيو googlecode، جن جي wiki گھڻن لسانيات جي حمايت ڪئي. اسان ڪيترن ئي ٻولين ۾ صفحا ٺاهيا، نه رڳو انگريزي ۽ روسي، جن ۾ اسان مشڪل سان گفتگو ڪري سگهون ٿا، پر جرمن ۽ اسپينش پڻ. نتيجي طور، اهو تمام مضحکہ خیز ڏسڻ ۾ اچي ٿو جڏهن انهن ٻولين ۾ پڇيو ويو، پر اسان جواب نه ٿا ڪري سگهون. يا انهن دستاويزن لکڻ ۽ تبصرو ڪرڻ بابت ضابطا متعارف ڪرايا، پر جڏهن کان API تبديل ٿي چڪو آهي اڪثر ۽ خاص طور تي، اهو ظاهر ٿيو ته اسان جي دستاويز پراڻي هئي ۽ ان جي مدد ڪرڻ کان وڌيڪ گمراهه ڪندڙ هئي.
نتيجي طور، اسان جون سڀئي ڪوششون، جيتوڻيڪ غلط به، خارجي صارفين جي ظاهر ٿيڻ جي ڪري. ۽ جيتوڻيڪ هڪ تجارتي گراهڪ ظاهر ٿيو جيڪو چاهي ٿو ته هن لاءِ پنهنجو RTOS ٺاهي وڃي. ۽ اسان ان کي ترقي ڪئي ڇاڪاڻ ته اسان وٽ تجربو ۽ ڪجهه بنيادي ڪم آهي. هتي توهان کي سٺي لمحن ۽ خراب ٻنهي بابت ڳالهائڻ جي ضرورت آهي. مان خرابين سان شروع ڪندس. جيئن ته ڪيترائي ڊولپر هن منصوبي ۾ تجارتي بنيادن تي ملوث هئا، ڪميونٽي اڳ ۾ ئي ڪافي غير مستحڪم ۽ ورهايل هئي، جيڪا يقيناً منصوبي جي ترقي کي متاثر نه ڪري سگهي. هڪ اضافي عنصر اهو هو ته منصوبي جي هدايت هڪ تجارتي گراهڪ طرفان مقرر ڪئي وئي هئي، ۽ هن جو مقصد منصوبي جي وڌيڪ ترقي نه هئي. گهٽ ۾ گهٽ اهو بنيادي مقصد نه هو.
ٻئي طرف، اتي ڪيترائي مثبت پهلو هئا. اسان کي واقعي ٽئين پارٽي استعمال ڪندڙ مليا. اهو نه رڳو گراهڪ هو، پر اهي به جن لاءِ هي نظام هو. منصوبي ۾ حصو وٺڻ جي حوصلا افزائي ڪئي وئي آهي. آخرڪار، جيڪڏهن توهان پڻ پئسا ڪمائي سگهو ٿا هڪ دلچسپ ڪاروبار مان، اهو هميشه سٺو آهي. ۽ سڀ کان وڌيڪ اهم، اسان گراهڪن کان هڪ خواهش ٻڌي، جيڪا ان وقت اسان کي چريو لڳي، پر جيڪو هاڻي ايمباڪس جو بنيادي خيال آهي، يعني، سسٽم ۾ اڳ ۾ ئي ترقي يافته ڪوڊ استعمال ڪرڻ لاء. هاڻي ايمباڪس جو بنيادي خيال لينڪس کانسواءِ لينڪس سافٽ ويئر استعمال ڪرڻ آهي. اهو آهي، منصوبي جي وڌيڪ ترقي ۾ حصو وٺندڙ مکيه مثبت پاسو اهو احساس هو ته اهو منصوبو ٽئين پارٽي جي صارفين طرفان استعمال ڪيو ويندو آهي، ۽ اهو انهن جي ڪجهه مسئلن کي حل ڪرڻ گهرجي.
ان وقت، ايمباڪس اڳ ۾ ئي شاگردن جي منصوبي جي دائري کان ٻاهر نڪري چڪو هو. شاگردن جي ماڊل جي مطابق منصوبي جي ترقي ۾ بنيادي محدود عنصر شرڪت ڪندڙن جي حوصلا افزائي آهي. شاگرد حصو وٺندا آهن جڏهن اهي پڙهندا آهن، ۽ جڏهن اهي گريجوئيشن ڪندا آهن، اتي هڪ مختلف حوصلا هجڻ گهرجي. جيڪڏهن حوصلا ظاهر نه ٿئي، شاگرد صرف منصوبي ۾ حصو وٺڻ بند ڪري ٿو. جيڪڏهن اسان ان ڳالهه کي ذهن ۾ رکون ٿا ته شاگردن کي پهرين تربيت ڏيڻ جي ضرورت آهي، اهو ظاهر ٿئي ٿو ته اهي گريجوئيشن وقت تائين سٺا ماهر بڻجي ويندا آهن، پر پروجيڪٽ ۾ انهن جو حصو، اڻ تجربي جي ڪري، تمام وڏو ناهي.
عام طور تي، اسان آساني سان مکيه نقطي ڏانهن وڃون ٿا جيڪو اسان کي هڪ اوپن سورس پروجيڪٽ ٺاهڻ بابت ڳالهائڻ جي اجازت ڏئي ٿو - هڪ پيداوار ٺاهي جيڪا ان جي استعمال ڪندڙن جا مسئلا حل ڪندي. جيئن مون مٿي بيان ڪيو، اوپن سورس پروجيڪٽ جي مکيه ملڪيت ان جي ڪميونٽي آهي. ان کان علاوه، ڪميونٽي جا ميمبر بنيادي طور تي استعمال ڪندڙ آھن. پر اهي ڪٿان اچن ٿا جڏهن استعمال ڪرڻ لاء ڪجهه ناهي؟ تنهن ڪري اهو ظاهر ٿئي ٿو ته، هڪ غير اوپن سورس پروجيڪٽ وانگر، توهان کي هڪ MVP (گهٽ ۾ گهٽ قابل عمل پراڊڪٽ) ٺاهڻ تي ڌيان ڏيڻ جي ضرورت آهي، ۽ جيڪڏهن اهو صارفين جي فائدي ۾ آهي، ته پوء هڪ ڪميونٽي منصوبي جي چوڌاري ظاهر ٿيندي. جيڪڏهن توهان صرف ڪميونٽي پي آر ذريعي ڪميونٽي ٺاهڻ ۾ مصروف آهيو، دنيا جي سڀني ٻولين ۾ هڪ وڪي لکڻ، يا gitub تي git ورڪ فلو کي درست ڪريو، پوء اهو ممڪن ناهي ته منصوبي جي شروعاتي مرحلن ۾. يقينا، مناسب مرحلن تي اهي نه رڳو اهم آهن، پر ضروري شيون پڻ.
آخر ۾ مان اشارو ڪرڻ چاهيان ٿو ، منهنجي خيال ۾، هڪ اوپن سورس پروجيڪٽ کان صارف جي اميدن کي ظاهر ڪندي:
مان سنجيدگي سان هن او ايس کي تبديل ڪرڻ بابت سوچي رهيو آهيان (گهٽ ۾ گهٽ ڪوشش ڪريو. اهي فعال طور تي ان جي پيروي ڪري رهيا آهن ۽ سٺيون شيون ڪري رهيا آهن).
پي ايس آن اسان وٽ ٽي رپورٽون هونديون. هڪ اوپن سورس بابت ۽ ٻه ايمبيڊڊ بابت (۽ هڪ عملي آهي). اسٽينڊ تي اسان پروگرامنگ مائڪرو ڪنٽرولرز استعمال ڪندي ماسٽر ڪلاس ڪنداسين . هميشه وانگر، اسان هارڊويئر آڻينداسين ۽ توهان کي پروگرام ڏينداسين. اتي به هڪ جستجو ۽ ٻيون سرگرميون. عيد تي اچو ۽ اسان جو اسٽينڊ، مزو ٿيندو.
جو ذريعو: www.habr.com