हाल के एप्लिकेशन डेवलपर डेज़ 2012 के सम्मेलन में, मुझे एक छोटी रिपोर्ट पढ़ने का मौका मिला कि ओपन सोर्स प्रोजेक्ट्स को ओपनवीजेड वेब पैनल का एक उदाहरण के रूप में उपयोग करके कैसे बनाया जाता है। दुर्भाग्य से, मेरे पास निर्धारित 30-40 के बजाय 10 मिनट थे, और परिणामस्वरूप तैयार की गई सामग्री का 80% "ओवरबोर्ड" था। आयोजकों ने, किसी कारण से, अंतिम क्षण में अपना विचार बदल दिया और यहां तक ​​कि प्रश्नों के साथ 5 मिनट के खंड को हटा दिया, ताकि प्रतिक्रिया के बिना छोड़ दिया गया। लेकिन मैं आयोजकों में बहुत भाग नहीं करूंगा - उन्होंने जितना संभव हो सके उतना प्रयास किया और सम्मेलन स्पष्ट रूप से सफल रहा, जिसके लिए उन्हें बहुत धन्यवाद। अधिकांश रिपोर्टों की गुणवत्ता से भी बहुत खुश हैं।


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

नीचे लिखी गई अधिकांश चीजें पूरी तरह से व्यक्तिपरक हैं। कुछ चीजों को राजद्रोही माना जा सकता है, लेकिन बहुत कुछ सचमुच अनुभव से ग्रस्त हो गया है।

बहुत सारे पाठ हैं। सबसे अधीर के लिए - आप केवल स्लाइड के माध्यम से देख सकते हैं।

प्रयोगात्मक खरगोश परियोजना के बारे में थोड़ा

OpenVZ वेब पैनल OpenVZ तकनीक का उपयोग करके वर्चुअल सर्वर के लिए एक काफी लोकप्रिय मुफ्त वेब-आधारित नियंत्रण कक्ष है। इसकी पुष्टि में, हम कह सकते हैं कि संस्करण 2.0 को 17,000 से अधिक सर्वरों पर स्थापित किया गया है। एक सर्वर उत्पाद के लिए एक ठोस आंकड़ा है।

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



विकास पूरी तरह से उनकी जरूरतों को पूरा करने के लिए था, इसलिए एक निश्चित स्तर पर एक ओपन सोर्स प्रोजेक्ट बनाने का निर्णय लिया गया था। अपनी सर्वश्रेष्ठ प्रथाओं को अन्य लोगों के साथ साझा करें जो इस तरह के पैनल की तलाश में भी रहे होंगे।

आपके प्रोजेक्ट का आइडिया

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

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

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

अभिप्रेरकों-demotivatory

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

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

प्रभावी विकास

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

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

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

दक्षता के मामले में एक कठिन मुद्दा प्रक्रिया स्वचालन का मुद्दा है। एक तरफ, आप एक प्रोग्रामर हैं और "एक घंटे में लिखें और 5 मिनट में उड़ान भरें" के सिद्धांत पर कार्य करना पसंद करते हैं। यह सिद्धांत आपके समय की कीमत पर बहुत बार काम करता है। यह केवल समय-समय पर वास्तव में दोहराए जाने वाले को स्वचालित करने के लिए आवश्यक है।

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

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

OpenVZ वेब पैनल पर काम के हिस्से के रूप में, मुझे बार-बार अपने "पसंदीदा OS" के लिए पैकेज के रूप में उत्पाद को इकट्ठा करने के लिए कहा गया था। इसके अलावा, आपके पसंदीदा OS के अंतर्गत, ArchLinux और Gentoo कभी-कभी दिखाई देते हैं। मेरे पास इन वितरणों के खिलाफ कुछ भी नहीं है, लेकिन उपयोगकर्ता समुदाय CentOS या डेबियन की तुलना में इतना छोटा है कि मैं लाभ के मामले में बहुत संदिग्ध कार्य पर बहुत समय बिताऊंगा। पैनल में एक अद्भुत शैल इंस्टॉलर है। मुझे पता है कि यह पैकेज की तुलना में कम पसंद किया जाता है। हालांकि, मैं यह भी अच्छी तरह से जानता हूं कि संकुल को उचित स्तर पर बनाए रखना, कहते हैं, पाँच लिनक्स वितरण एक बहुत ही समय लेने वाला कार्य है। जबकि शेल इंस्टॉलर मुझे विकास के बहुत से समय बचाता है। मजेदार बात यह है कि अगर कोई डेबियन प्रेमी (जो पहले से ही पांचवें नंबर पर है, पैकेज भेजने का वादा करता है, लेकिन उसने एक भी सामान्य पैकेज नहीं भेजा है), तो मैं आपसे सेंटोस के लिए एक पैकेज बनाने की कोशिश करने के लिए भी कहूंगा, तो ... अच्छा है, आप मुझे समझें।

उत्पाद की गुणवत्ता

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

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

नीचे wget डाउनलोड मैनेजर के लिए फ्रंट एंड का स्क्रीनशॉट है। अपने शुद्ध रूप में इंटरफ़ेस डिज़ाइन के लिए प्रोग्रामर का दृष्टिकोण: "एक विकल्प है - यह स्क्रीन पर होना चाहिए"।



यहाँ वर्डप्रेस का स्क्रीनशॉट दिया गया है। आप इस उत्पाद को पसंद या नापसंद कर सकते हैं, लेकिन यह मानने योग्य है कि लोग स्पष्ट रूप से उत्पाद की गुणवत्ता पर काम कर रहे हैं।



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

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

प्रौद्योगिकी के

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

हालांकि, अंत उपयोगकर्ताओं के बारे में मत भूलना। यदि आपके पास एक वेब एप्लिकेशन है, तो सुनिश्चित करें कि उनमें से अधिकांश शायद ही समझें कि HTML3 HTML5 से कैसे भिन्न है। हालांकि, यदि आप IE के लिए पूरी तरह से समर्थन से इनकार करते हैं, तो वे निश्चित रूप से इस पर ध्यान देंगे और बस समझ नहीं पाएंगे। उपयोगकर्ता सामग्री में मुख्य रूप से रुचि रखता है, न कि आपकी तकनीकी घंटियाँ और सीटी।

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

एक विकास बजट की कमी भी महंगे भुगतान वाले घटकों के विकल्प पर जोर दे रही है। यह अक्सर पता चलता है कि ऐसे घटक व्यावसायिक समकक्षों की तुलना में एकीकृत करने और बनाए रखने में आसान परिमाण का एक क्रम है। अंत में, आप कुछ समस्याओं को ठीक करके किसी अन्य ओपन सोर्स प्रोजेक्ट के विकास में भी योगदान कर सकते हैं।

उपकरण

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

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

समुदाय

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

कच्चे उत्पाद का परीक्षण करने के लिए लोगों को राजी करना बहुत मुश्किल है। यहां तक ​​कि उपयोगकर्ता द्वारा अनुरोधित सुविधाएँ भी, वह रिलीज़ होने के बाद ही जांच करना पसंद करती हैं।

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



यदि आपको इंटरफ़ेस को किसी अन्य भाषा में अनुवाद करने की आवश्यकता है, तो दस्तावेज़ का मुकाबला करने की कोशिश करें, चर्चा के लिए कुछ पेश करें - समुदाय हमेशा आपकी सेवा में है। होलीवर और अंतहीन चर्चाओं का आयोजन भी लगभग किसी भी समुदाय में कुछ लोगों का शौक है।

और हमेशा की तरह, किसी भी समुदाय में कोई ऐसा व्यक्ति है जो किसी चीज से असंतुष्ट है और उसका मानना ​​है कि आपको सब कुछ छोड़ देना चाहिए और केवल अपनी समस्याओं से निपटना चाहिए। अंत में, उन्होंने आपको $ 10 का दान दिया।

पैसा!

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

मेरे कुछ दोस्त, किसी कारण से, पवित्र रूप से मानते हैं कि इस तरह की परियोजनाएं दान पर अच्छी तरह से रह सकती हैं। वे नहीं कर सकते ऑफहैंड, मुझे एक भी परियोजना याद नहीं आ रही है, जहाँ मुझे दान बटन के बगल में अधिक या कम अलग से एकत्रित राशि दिखाई दी (यह प्रायोजन और दान को भ्रमित करने के लिए महत्वपूर्ण नहीं है)। यदि आप विकिपीडिया के निर्माता नहीं हैं और परियोजना की वेबसाइट पर उदास आँखों के साथ कोई व्यक्तिगत तस्वीर नहीं है, तो परियोजना वेबसाइट की मेजबानी के लिए दान भी शायद ही पर्याप्त हो। मैं अपने खुद के प्रोजेक्ट के बारे में बात नहीं करूंगा, क्योंकि उसके लिए, आंकड़े सार्वजनिक नहीं हैं। लेकिन हाल ही में मैंने Gitlab प्रोजेक्ट साइट को देखा। काफी दिलचस्प है, कई दिलचस्पी। नीचे $ 1,000 की राशि एकत्र करने की प्रगति के साथ एक "थर्मामीटर" है। मैंने 3 हफ्ते पहले और आज वहां देखा। एकत्र की गई राशि में 150 डॉलर से भी कम का बदलाव हुआ है। इसके अलावा, यह दूसरों की तुलना में बहुत अच्छा है।

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

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

निष्कर्ष, उनके बिना कहाँ

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

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

अपने सबसे महंगे संसाधन - समय के बारे में याद रखें। अंत में, आपके पास शायद एक मुख्य काम है और कम से कम किसी तरह का निजी जीवन है।

अंत में, एक तैयार उत्पाद बनाएं जिस पर आपको गर्व हो। "सुपर टेक" पर रोक न दें, लेकिन अल्फा संस्करण। वाणिज्यिक और मुक्त स्रोत विकास दोनों में सबसे कठिन हिस्सा उत्पाद को रिलीज करने के लिए लाना है। फिर आप सम्मेलनों में जा सकते हैं और अपने सफल उपक्रम के बारे में सभी को बता सकते हैं (उदाहरण के लिए, स्फ़िंक्स के लेखक इसे करते हैं :))।

PS उपरोक्त सभी विशुद्ध रूप से व्यक्तिगत राय है। मैं, कई अन्य लोगों की तरह, गलतियाँ करना, अपनी गलतियों से सीखना और कई काम गलत करना, लेकिन दूसरों को सिखाने की कोशिश करना :)