ओपन सोर्स कम्युनिटी का निर्माण कैसे करें

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

ओपन सोर्स प्रोजेक्ट क्यों शुरू होते हैं?

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

एक समुदाय क्या है और एक ओपन सोर्स प्रोजेक्ट क्यों बनाया जाता है?

समुदाय सामान्य हितों को साझा करने वाले व्यक्तियों के समूह हैं। बंद और खुली दोनों परियोजनाओं के अपने उपयोगकर्ता समुदाय हैं, जिनमें से अधिकांश अपेक्षाकृत निष्क्रिय हैं, बाकी समुदाय के साथ उनकी बातचीत के बारे में बात करने के लिए। दूसरी ओर, किसी भी प्रकार के समुदाय में वे सदस्य शामिल हो सकते हैं जो अधिक सक्रिय भाग लेने का निर्णय लेते हैं, उदाहरण के लिए, बग रिपोर्ट भेजना, अन्य उपयोगकर्ताओं की मदद करना, दस्तावेज लिखना या प्रचार करना।
सबसे सक्रिय प्रतिभागियों को उनके प्रयासों के लिए पुरस्कृत किया जाना चाहिए। उदाहरण के लिए, Microsoft उपयोगकर्ता समुदाय में उन लोगों को पुरस्कृत करता है जो MVP के माध्यम से अधिकांश Microsoft तकनीक का निर्माण करने में लोगों की मदद करते हैं (Most Valued Professional)। ओपन सोर्स समुदायों में, सक्रिय सदस्य परियोजना की बढ़ती पहुंच और उस पर नियंत्रण बढ़ाने के रूप में पुरस्कार की उम्मीद करते हैं।

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

विशिष्ट ओपन सोर्स सामुदायिक पथ

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

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

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

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

भित्तियों पर पारदर्शी प्रबंधन

समुदाय के नेताओं की जिम्मेदारी इस विश्वास में निहित है कि ओपन सोर्स की क्षमता का दोहन करने के लिए परिस्थितियाँ उपयुक्त हैं। यह अपने आप नहीं आता है और इसे सावधानी से प्रबंधित किया जाना चाहिए।

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

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

जाने दो

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

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

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

निष्कर्ष

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