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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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