खुला स्रोत परियोजना कसरी सिर्जना गर्ने

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

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

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

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

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

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

एक कम्पनीले खुला स्रोत परियोजनाहरू सिर्जना नगरी व्यावसायिक लाभहरू प्राप्त गर्न सक्छ; यो कम्पनीमा प्रयोग हुने तेस्रो-पक्ष परियोजनाहरूमा भाग लिन यसको विशेषज्ञहरूको लागि पर्याप्त छ। आखिर, सबै फाइदाहरू रहन्छन्: कर्मचारीहरूलाई परियोजना राम्रोसँग थाहा छ, त्यसैले उनीहरूले यसलाई अझ प्रभावकारी रूपमा प्रयोग गर्छन्, कम्पनीले परियोजनाको विकासको दिशालाई प्रभाव पार्न सक्छ, र तयार-निर्मित, डिबग गरिएको कोडको प्रयोगले स्पष्ट रूपमा कम्पनीको लागत घटाउँछ।

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

र निस्सन्देह, हामीले यो बिर्सनु हुँदैन कि ओपनसोर्स प्रोजेक्ट आफैलाई कुनै पनि विशेषज्ञताको वाहकको रूपमा घोषणा गर्ने प्रभावकारी तरिका हो। केहि अवस्थामा, यो बजार प्रवेश गर्ने एक मात्र तरिका हो। उदाहरण को लागी, Embox एक RTOS सिर्जना गर्न को लागी एक परियोजना को रूप मा शुरू भयो। त्यहाँ धेरै प्रतिस्पर्धीहरू छन् भनेर व्याख्या गर्न आवश्यक छैन। समुदाय सिर्जना नगरीकन, हामीसँग परियोजनालाई अन्तिम प्रयोगकर्तामा ल्याउन पर्याप्त स्रोतहरू हुने थिएन, अर्थात् तेस्रो-पक्ष विकासकर्ताहरूले परियोजना प्रयोग गर्न सुरु गर्न।

समुदाय एक खुला स्रोत परियोजना मा महत्वपूर्ण छ। यसले तपाईंलाई परियोजना व्यवस्थापन लागतहरू घटाउन, परियोजनाको विकास र समर्थन गर्न अनुमति दिन्छ। हामी भन्न सक्छौं कि समुदाय बिना त्यहाँ कुनै पनि खुला स्रोत परियोजना छैन।

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

खुला स्रोत परियोजना समुदाय सिर्जना गर्दा मुख्य नियम भनेको कुनै नियमहरू छैनन्। मेरो मतलब त्यहाँ कुनै सार्वभौमिक नियमहरू छैनन्, जस्तै त्यहाँ कुनै चाँदीको बुलेट छैन, यदि केवल परियोजनाहरू धेरै फरक छन्। js लगिङ लाइब्रेरी र केही उच्च विशिष्टीकृत ड्राइभरका लागि समुदाय सिर्जना गर्दा तपाईले समान नियमहरू प्रयोग गर्न सक्नुहुन्छ भन्ने सम्भावना छैन। यसबाहेक, परियोजनाको विकासको विभिन्न चरणहरूमा (र त्यसकारण समुदाय), नियमहरू परिवर्तन हुन्छन्।

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

Embox को लागी अर्को चरण तेस्रो-पक्ष प्रयोगकर्ताहरूको खोजी थियो। यो बुझ्न धेरै महत्त्वपूर्ण छ कि प्रयोगकर्ताहरू खुला स्रोत समुदायमा पूर्ण सहभागीहरू हुन्। त्यहाँ सामान्यतया विकासकर्ताहरू भन्दा धेरै प्रयोगकर्ताहरू छन्। र कुनै परियोजनामा ​​योगदानकर्ता बन्न चाहने क्रममा, तिनीहरूले पहिले यसलाई कुनै न कुनै रूपमा प्रयोग गर्न थाल्छन्।

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

यस चरणमा, हामीले कागजात, प्रयोगकर्ताहरूसँग सञ्चारको माध्यमको बारेमा सोच्नुपर्‍यो। होइन, निस्सन्देह, हामीले यी महत्त्वपूर्ण कुराहरूको बारेमा पहिले सोच्यौं, तर यो समयपूर्व थियो र सकारात्मक प्रभाव दिन सकेन। प्रभाव अलि नकारात्मक थियो। म तपाईंलाई एक दुई उदाहरण दिन्छु। हामीले गुगलकोड प्रयोग गर्यौं, जसको विकीले बहुभाषिकतालाई समर्थन गर्‍यो। हामीले धेरै भाषाहरूमा पृष्ठहरू सिर्जना गर्यौं, अंग्रेजी र रुसी मात्र होइन, जसमा हामीले संवाद गर्न नसक्ने तर जर्मन र स्पेनिस पनि। नतिजाको रूपमा, यी भाषाहरूमा सोध्दा यो धेरै हास्यास्पद देखिन्छ, तर हामी जवाफ दिन सक्दैनौं। वा तिनीहरूले कागजातहरू लेख्ने र टिप्पणी गर्ने बारे नियमहरू प्रस्तुत गरे, तर जबदेखि API धेरै पटक र महत्त्वपूर्ण रूपमा परिवर्तन भयो, यसले हाम्रो कागजात पुरानो थियो र यसले मद्दत गरेको भन्दा बढी भ्रामक थियो।

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

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

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

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

अन्तमा म औंल्याउन चाहन्छु टिप्पणी, मेरो विचारमा, खुला स्रोत परियोजनाबाट प्रयोगकर्ता अपेक्षाहरू प्रतिबिम्बित गर्दै:

म यस OS मा स्विच गर्ने बारे गम्भीरताका साथ सोच्दै छु (कम्तिमा प्रयास गर्नुहोस्। तिनीहरू सक्रिय रूपमा यसलाई पछ्याउँदै छन् र राम्रो चीजहरू गर्दैछन्)।

PS अन TechTrain हामीसँग तीनवटा रिपोर्टहरू हुनेछन्। एउटा खुला स्रोतको बारेमा र दुई इम्बेडेडको बारेमा (र एउटा व्यावहारिक छ)। स्ट्यान्डमा हामी प्रोग्रामिङ माइक्रोकन्ट्रोलरहरू प्रयोग गरेर मास्टर क्लास सञ्चालन गर्नेछौं Embox। सामान्य रूपमा, हामी हार्डवेयर ल्याउनेछौं र तपाईंलाई प्रोग्राम गर्न दिनेछौं। त्यहाँ खोज र अन्य गतिविधिहरू पनि हुनेछन्। चाडपर्वमा आउनुहोस् र हाम्रो अडान, रमाइलो हुनेछ।

स्रोत: www.habr.com