ओपन सोर्स प्रोजेक्ट कैसे बनाएं

इस सप्ताह सेंट पीटर्सबर्ग में एक आईटी महोत्सव आयोजित किया जाएगा टेकट्रेन. वक्ताओं में से एक रिचर्ड स्टॉलमैन होंगे। एमबॉक्स महोत्सव में भी भाग लेता है, और निश्चित रूप से हम मुफ्त सॉफ्टवेयर के विषय को नजरअंदाज नहीं कर सकते। इसलिए हमारी एक रिपोर्ट मंगाई गई है “छात्र शिल्प से लेकर ओपनसोर्स प्रोजेक्ट तक। एमबॉक्स अनुभव”. यह एक ओपन सोर्स प्रोजेक्ट के रूप में एमबॉक्स के विकास के इतिहास को समर्पित होगा। इस लेख में मैं उन मुख्य विचारों के बारे में बात करना चाहता हूं जो, मेरी राय में, ओपनसोर्स परियोजनाओं के विकास को प्रभावित करते हैं। रिपोर्ट की तरह लेख भी व्यक्तिगत अनुभव पर आधारित है।

आइए ओपनसोर्स शब्द की परिभाषा के साथ कुछ सरल से शुरुआत करें। जाहिर है, एक ओपन सोर्स प्रोजेक्ट एक ऐसा प्रोजेक्ट है जिसमें एक लाइसेंस होता है जो प्रोजेक्ट के सोर्स कोड तक पहुंच की अनुमति देता है। इसके अलावा, एक खुले प्रोजेक्ट का मतलब है कि तीसरे पक्ष के डेवलपर्स बदलाव कर सकते हैं। अर्थात्, यदि कोई कंपनी या डेवलपर अपने उत्पाद का कोड आंशिक या पूर्ण रूप से प्रकाशित करता है, तो यह अभी तक इस उत्पाद को एक ओपनसोर्स प्रोजेक्ट नहीं बनाता है। और अंत में, किसी भी परियोजना गतिविधि से किसी न किसी प्रकार का परिणाम अवश्य निकलेगा, और परियोजना के खुलेपन का अर्थ है कि इस परिणाम का उपयोग न केवल स्वयं डेवलपर्स द्वारा किया जाता है।

हम खुले लाइसेंस की समस्याओं पर ध्यान नहीं देंगे। यह बहुत बड़ा और जटिल विषय है जिसकी गहन जांच की आवश्यकता है। इस विषय पर बहुत सारे अच्छे लेख और सामग्रियां लिखी गई हैं। लेकिन चूंकि मैं स्वयं कॉपीराइट के क्षेत्र में विशेषज्ञ नहीं हूं, इसलिए मैं केवल इतना कहूंगा कि लाइसेंस को परियोजना के लक्ष्यों को पूरा करना चाहिए। उदाहरण के लिए, एमबॉक्स के लिए जीपीएल लाइसेंस के बजाय बीएसडी का चुनाव आकस्मिक नहीं था।

तथ्य यह है कि एक ओपन सोर्स प्रोजेक्ट को परिवर्तन करने और ओपन सोर्स प्रोजेक्ट के विकास को प्रभावित करने की क्षमता प्रदान करनी चाहिए, इसका मतलब है कि प्रोजेक्ट वितरित है। केंद्रीकृत प्रबंधन वाली परियोजना की तुलना में इसे प्रबंधित करना, अखंडता और प्रदर्शन बनाए रखना कहीं अधिक कठिन है। एक वाजिब सवाल उठता है: परियोजनाएँ आखिर क्यों खोली जाती हैं? इसका उत्तर व्यावसायिक व्यवहार्यता के क्षेत्र में है; परियोजनाओं की एक निश्चित श्रेणी के लिए, इस दृष्टिकोण के लाभ लागत से अधिक हैं। अर्थात्, यह सभी परियोजनाओं के लिए उपयुक्त नहीं है और एक खुला दृष्टिकोण आम तौर पर स्वीकार्य है। उदाहरण के लिए, किसी खुले सिद्धांत के आधार पर किसी बिजली संयंत्र या विमान के लिए नियंत्रण प्रणाली विकसित करने की कल्पना करना कठिन है। नहीं, निश्चित रूप से, ऐसी प्रणालियों में खुली परियोजनाओं पर आधारित मॉड्यूल शामिल होने चाहिए, क्योंकि इससे कई फायदे मिलेंगे। लेकिन अंतिम उत्पाद के लिए किसी को तो जिम्मेदार होना ही चाहिए। भले ही सिस्टम पूरी तरह से खुली परियोजनाओं के कोड पर आधारित हो, डेवलपर, सब कुछ एक सिस्टम में पैक करके और विशिष्ट बिल्ड और सेटिंग्स बनाकर, अनिवार्य रूप से इसे बंद कर देता है। कोड सार्वजनिक रूप से उपलब्ध हो सकता है.

ओपन सोर्स प्रोजेक्ट बनाने या उनमें योगदान करने से इन प्रणालियों को भी बहुत सारे लाभ होते हैं। जैसा कि मैंने कहा, अंतिम सिस्टम कोड सार्वजनिक रूप से उपलब्ध रह सकता है। क्यों, क्योंकि यह स्पष्ट है कि यह संभावना नहीं है कि किसी के पास सिस्टम का परीक्षण करने के लिए वही विमान होगा। यह सच है, लेकिन ऐसा कोई व्यक्ति हो सकता है जो कोड के कुछ अनुभागों की जांच करना चाहता हो, या, उदाहरण के लिए, किसी को पता चल सकता है कि उपयोग की जा रही लाइब्रेरी बिल्कुल सही तरीके से कॉन्फ़िगर नहीं की गई है।

यदि कंपनी सिस्टम के कुछ बुनियादी हिस्से को एक अलग प्रोजेक्ट में आवंटित करती है तो और भी बड़ा लाभ दिखाई देता है। उदाहरण के लिए, किसी प्रकार के डेटा एक्सचेंज प्रोटोकॉल का समर्थन करने वाली लाइब्रेरी। इस मामले में, भले ही प्रोटोकॉल किसी दिए गए विषय क्षेत्र के लिए विशिष्ट हो, आप सिस्टम के इस हिस्से को बनाए रखने की लागत को इस क्षेत्र की अन्य कंपनियों के साथ साझा कर सकते हैं। इसके अलावा, जो विशेषज्ञ सार्वजनिक डोमेन में सिस्टम के इस हिस्से का अध्ययन कर सकते हैं, उन्हें इसे प्रभावी ढंग से उपयोग करने के लिए बहुत कम समय की आवश्यकता होती है। और अंत में, एक टुकड़े को एक स्वतंत्र इकाई में अलग करना, जिसे तीसरे पक्ष के डेवलपर्स उपयोग करते हैं, हमें इस हिस्से को बेहतर बनाने की अनुमति देता है, क्योंकि हमें प्रभावी एपीआई की पेशकश करने, दस्तावेज़ बनाने की आवश्यकता है, और मैं परीक्षण कवरेज में सुधार के बारे में बात भी नहीं कर रहा हूं।

एक कंपनी ओपन-सोर्स प्रोजेक्ट बनाए बिना व्यावसायिक लाभ प्राप्त कर सकती है; यह उसके विशेषज्ञों के लिए कंपनी में उपयोग की जाने वाली तृतीय-पक्ष परियोजनाओं में भाग लेने के लिए पर्याप्त है। आख़िरकार, सभी लाभ बने रहते हैं: कर्मचारी परियोजना को बेहतर जानते हैं, इसलिए वे इसका अधिक प्रभावी ढंग से उपयोग करते हैं, कंपनी परियोजना के विकास की दिशा को प्रभावित कर सकती है, और तैयार, डिबग किए गए कोड का उपयोग स्पष्ट रूप से कंपनी की लागत को कम करता है।

ओपनसोर्स प्रोजेक्ट बनाने के लाभ यहीं समाप्त नहीं होते हैं। आइए विपणन जैसे व्यवसाय के एक महत्वपूर्ण घटक को लें। उनके लिए, यह एक बहुत अच्छा सैंडबॉक्स है जो उन्हें बाज़ार की आवश्यकताओं का प्रभावी ढंग से मूल्यांकन करने की अनुमति देता है।

और निश्चित रूप से, हमें यह नहीं भूलना चाहिए कि एक ओपनसोर्स प्रोजेक्ट खुद को किसी भी विशेषज्ञता का वाहक घोषित करने का एक प्रभावी तरीका है। कुछ मामलों में, बाज़ार में प्रवेश करने का यही एकमात्र तरीका है। उदाहरण के लिए, Embox एक RTOS बनाने के प्रोजेक्ट के रूप में शुरू हुआ। शायद यह समझाने की ज़रूरत नहीं है कि बहुत सारे प्रतिस्पर्धी हैं। एक समुदाय बनाए बिना, हमारे पास प्रोजेक्ट को अंतिम उपयोगकर्ता तक लाने के लिए, यानी तीसरे पक्ष के डेवलपर्स के लिए प्रोजेक्ट का उपयोग शुरू करने के लिए पर्याप्त संसाधन नहीं होंगे।

ओपनसोर्स प्रोजेक्ट में समुदाय महत्वपूर्ण है। यह आपको परियोजना प्रबंधन लागत को महत्वपूर्ण रूप से कम करने, परियोजना का विकास और समर्थन करने की अनुमति देता है। हम कह सकते हैं कि समुदाय के बिना कोई भी ओपनसोर्स प्रोजेक्ट मौजूद नहीं है।

ओपन सोर्स प्रोजेक्ट समुदाय कैसे बनाएं और प्रबंधित करें, इसके बारे में बहुत सारी सामग्री लिखी गई है। पहले से ज्ञात तथ्यों को दोबारा न बताने के लिए, मैं एमबॉक्स के अनुभव पर ध्यान केंद्रित करने का प्रयास करूंगा। उदाहरण के लिए, एक समुदाय बनाने की प्रक्रिया एक बहुत ही दिलचस्प मुद्दा है। यानी, कई लोग बताते हैं कि किसी मौजूदा समुदाय को कैसे प्रबंधित किया जाए, लेकिन इसके निर्माण के क्षणों को कभी-कभी यह मानकर अनदेखा कर दिया जाता है।

ओपनसोर्स प्रोजेक्ट समुदाय बनाते समय मुख्य नियम यह है कि कोई नियम नहीं हैं। मेरा मतलब है कि कोई सार्वभौमिक नियम नहीं हैं, जैसे कोई चांदी की गोली नहीं है, यदि केवल इसलिए कि परियोजनाएं बहुत अलग हैं। यह संभावना नहीं है कि आप जेएस लॉगिंग लाइब्रेरी और कुछ अत्यधिक विशिष्ट ड्राइवर के लिए समुदाय बनाते समय समान नियमों का उपयोग कर सकें। इसके अलावा, परियोजना (और इसलिए समुदाय) के विकास के विभिन्न चरणों में, नियम बदलते हैं।

एमबॉक्स की शुरुआत एक छात्र परियोजना के रूप में हुई क्योंकि इसमें सिस्टम प्रोग्रामिंग विभाग के छात्रों तक पहुंच थी। दरअसल, हम किसी दूसरे समुदाय में प्रवेश कर रहे थे. हम इस समुदाय के प्रतिभागियों, छात्रों को उनकी विशेषज्ञता में अच्छे औद्योगिक अभ्यास, सिस्टम प्रोग्रामिंग, कोर्सवर्क और डिप्लोमा के क्षेत्र में वैज्ञानिक कार्य में रुचि दे सकते हैं। अर्थात्, हमने एक समुदाय को संगठित करने के बुनियादी नियमों में से एक का पालन किया: समुदाय के सदस्यों को कुछ प्राप्त करना चाहिए, और यह कीमत प्रतिभागी के योगदान के अनुरूप होनी चाहिए।

एमबॉक्स के लिए अगला चरण तीसरे पक्ष के उपयोगकर्ताओं की खोज था। यह समझना बहुत महत्वपूर्ण है कि उपयोगकर्ता ओपनसोर्स समुदाय में पूर्ण भागीदार हैं। आमतौर पर डेवलपर्स की तुलना में अधिक उपयोगकर्ता होते हैं। और किसी परियोजना में योगदानकर्ता बनने की इच्छा के लिए, वे सबसे पहले इसका किसी न किसी रूप में उपयोग करना शुरू करते हैं।

एमबॉक्स के पहले उपयोगकर्ता सैद्धांतिक साइबरनेटिक्स विभाग थे। उन्होंने लेगो माइंडस्टॉर्म के लिए एक वैकल्पिक फर्मवेयर बनाने का सुझाव दिया। और यद्यपि ये अभी भी स्थानीय उपयोगकर्ता थे (हम उनसे व्यक्तिगत रूप से मिल सकते थे और चर्चा कर सकते थे कि वे क्या चाहते हैं)। लेकिन फिर भी यह बहुत अच्छा अनुभव था. उदाहरण के लिए, हमने ऐसे डेमो विकसित किए जो दूसरों को दिखाए जा सकते हैं, क्योंकि रोबोट मज़ेदार हैं और ध्यान आकर्षित करते हैं। परिणामस्वरूप, हमें वास्तव में तृतीय-पक्ष उपयोगकर्ता मिले जिन्होंने पूछना शुरू किया कि एमबॉक्स क्या है और इसका उपयोग कैसे करें।

इस स्तर पर, हमें प्रलेखन के बारे में, उपयोगकर्ताओं के साथ संचार के साधनों के बारे में सोचना था। नहीं, बेशक, हमने इन महत्वपूर्ण चीज़ों के बारे में पहले सोचा था, लेकिन यह समय से पहले था और इसका कोई सकारात्मक प्रभाव नहीं पड़ा। प्रभाव बल्कि नकारात्मक था. मैं आपको कुछ उदाहरण देता हूं. हमने googlecode का उपयोग किया, जिसका विकी बहुभाषावाद का समर्थन करता है। हमने कई भाषाओं में पेज बनाए, न केवल अंग्रेजी और रूसी, जिनमें हम मुश्किल से संवाद कर सकते थे, बल्कि जर्मन और स्पेनिश भी। परिणामस्वरूप, इन भाषाओं में पूछने पर यह बहुत हास्यास्पद लगता है, लेकिन हम जवाब ही नहीं दे पाते। या उन्होंने दस्तावेज़ लिखने और टिप्पणी करने के बारे में नियम पेश किए, लेकिन चूंकि एपीआई काफी बार और महत्वपूर्ण रूप से बदल गई, तो यह पता चला कि हमारा दस्तावेज़ पुराना था और इससे मदद मिलने की तुलना में अधिक भ्रामक था।

परिणामस्वरूप, हमारे सभी प्रयास, यहाँ तक कि गलत प्रयास भी, बाहरी उपयोगकर्ताओं की उपस्थिति का कारण बने। और यहां तक ​​कि एक व्यावसायिक ग्राहक भी सामने आया जो चाहता था कि उसके लिए अपना खुद का आरटीओएस विकसित किया जाए। और हमने इसे विकसित किया क्योंकि हमारे पास अनुभव और कुछ जमीनी कार्य हैं। यहां आपको अच्छे और बुरे दोनों पलों के बारे में बात करने की जरूरत है। मैं बुरे लोगों से शुरुआत करूंगा। चूंकि कई डेवलपर्स इस परियोजना में व्यावसायिक आधार पर शामिल थे, समुदाय पहले से ही काफी अस्थिर और विभाजित था, जो निश्चित रूप से परियोजना के विकास को प्रभावित नहीं कर सका। एक अतिरिक्त कारक यह था कि परियोजना की दिशा एक वाणिज्यिक ग्राहक द्वारा निर्धारित की गई थी, और उसका लक्ष्य परियोजना का आगे विकास नहीं था। कम से कम यह मुख्य लक्ष्य तो नहीं था.

दूसरी ओर, कई सकारात्मक पहलू भी थे। हमें वास्तव में तृतीय-पक्ष उपयोगकर्ता मिले। यह न केवल ग्राहक के लिए था, बल्कि उनके लिए भी था जिनके लिए यह प्रणाली बनाई गई थी। परियोजना में भाग लेने की प्रेरणा बढ़ी है। आख़िरकार, यदि आप किसी दिलचस्प व्यवसाय से भी पैसा कमा सकते हैं, तो यह हमेशा अच्छा होता है। और सबसे महत्वपूर्ण बात, हमने ग्राहकों से एक इच्छा सुनी, जो उस समय हमें पागल लगती थी, लेकिन जो अब एमबॉक्स का मुख्य विचार है, अर्थात् सिस्टम में पहले से विकसित कोड का उपयोग करना। अब Embox का मुख्य विचार Linux के बिना Linux सॉफ़्टवेयर का उपयोग करना है। अर्थात्, परियोजना के आगे के विकास में योगदान देने वाला मुख्य सकारात्मक पहलू यह अहसास था कि परियोजना का उपयोग तीसरे पक्ष के उपयोगकर्ताओं द्वारा किया जाता है, और इसे उनकी कुछ समस्याओं का समाधान करना चाहिए।

उस समय, एमबॉक्स पहले ही एक छात्र परियोजना के दायरे से आगे निकल चुका था। छात्र मॉडल के अनुसार परियोजना के विकास में मुख्य सीमित कारक प्रतिभागियों की प्रेरणा है। छात्र पढ़ाई के दौरान भाग लेते हैं, और जब वे स्नातक होते हैं, तो एक अलग प्रेरणा होनी चाहिए। यदि प्रेरणा प्रकट नहीं होती है, तो छात्र परियोजना में भाग लेना बंद कर देता है। यदि हम इस बात पर ध्यान दें कि छात्रों को पहले प्रशिक्षित करने की आवश्यकता है, तो यह पता चलता है कि स्नातक होने तक वे अच्छे विशेषज्ञ बन जाते हैं, लेकिन अनुभवहीनता के कारण परियोजना में उनका योगदान बहुत बड़ा नहीं होता है।

सामान्य तौर पर, हम आसानी से मुख्य बिंदु पर आगे बढ़ते हैं जो हमें एक ओपनसोर्स प्रोजेक्ट बनाने के बारे में बात करने की अनुमति देता है - एक ऐसा उत्पाद बनाना जो अपने उपयोगकर्ताओं की समस्याओं का समाधान करेगा। जैसा कि मैंने ऊपर बताया, एक ओपनसोर्स प्रोजेक्ट की मुख्य संपत्ति उसका समुदाय है। इसके अलावा, समुदाय के सदस्य मुख्य रूप से उपयोगकर्ता हैं। लेकिन जब उपयोग करने के लिए कुछ नहीं है तो वे कहाँ से आते हैं? तो यह पता चला है कि, एक गैर-ओपनसोर्स प्रोजेक्ट की तरह, आपको एक एमवीपी (न्यूनतम व्यवहार्य उत्पाद) बनाने पर ध्यान केंद्रित करने की आवश्यकता है, और यदि यह उपयोगकर्ताओं को रुचिकर लगता है, तो प्रोजेक्ट के आसपास एक समुदाय दिखाई देगा। यदि आप केवल सामुदायिक पीआर के माध्यम से एक समुदाय बनाने, दुनिया की सभी भाषाओं में विकी लिखने या जीथब पर गिट वर्कफ़्लो को सही करने में लगे हुए हैं, तो परियोजना के शुरुआती चरणों में इससे कोई फर्क पड़ने की संभावना नहीं है। बेशक, उचित चरणों में ये न केवल महत्वपूर्ण हैं, बल्कि आवश्यक चीजें भी हैं।

अंत में मैं बताना चाहूँगा टिप्पणी, मेरी राय में, एक ओपनसोर्स प्रोजेक्ट से उपयोगकर्ता की अपेक्षाओं को दर्शाता है:

मैं इस ओएस पर स्विच करने के बारे में गंभीरता से सोच रहा हूं (कम से कम कोशिश करें। वे सक्रिय रूप से इस पर काम कर रहे हैं और अच्छी चीजें कर रहे हैं)।

पुनश्च चालू टेकट्रेन हमारे पास कम से कम तीन रिपोर्टें होंगी। एक ओपन सोर्स के बारे में और दो एंबेडेड के बारे में (और एक व्यावहारिक है)। स्टैंड पर हम माइक्रोकंट्रोलर का उपयोग करके प्रोग्रामिंग पर एक मास्टर क्लास आयोजित करेंगे एमबॉक्स. हमेशा की तरह, हम हार्डवेयर लाएंगे और आपको इसे प्रोग्राम करने देंगे। इसमें खोज और अन्य गतिविधियाँ भी होंगी। महोत्सव में आइए और अपना रुख कीजिए, मजा आएगा।

स्रोत: www.habr.com