ओपन सोर्स प्रोजेक्ट मैनेजमेंट मॉडल (भाग 1)

एक अनुवादक से: यह अनुवाद ओपन सोर्स परियोजनाओं के प्रबंधन पर प्रकाशनों की श्रृंखला जारी रखता है जो यहां शुरू हुई थीं।

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

परियोजना को सामान्य रूप से प्रबंधन मॉडल की आवश्यकता क्यों है?

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

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

तालिका 1 विशिष्ट प्रबंधन मॉडल

परियोजना का प्रकार	लक्ष्य	नियंत्रण शैली	सामुदायिक संरचना	उदाहरण
अनुसंधान उन्मुख	नवाचार और ज्ञान का आदान-प्रदान	कैथेड्रल विधि, केंद्रीय प्रशासन	प्रोजेक्ट लीडर, कई पाठक	पर्ल, लिनक्स कर्नेल
उन्मुख का उपयोग करें	व्यक्तिगत जरूरतों को पूरा करना	बाजार विधि, विकेंद्रीकृत प्रबंधन	कई परिधीय डेवलपर्स, निष्क्रिय उपयोगकर्ताओं के बीच आपसी समर्थन	GNU / Linux (कर्नेल को छोड़कर)
सेवा उन्मुख	स्थिर सेवा प्रदान करें	सलाहकार केंद्रीय प्रबंधन	एक परियोजना के नेता के बजाय प्रतिभागियों का नेतृत्व करना, कई उपयोगकर्ता अंतिम उपयोगकर्ताओं के लिए सिस्टम विकसित कर रहे हैं	Apache, PostgreSQL

एक्शन में प्रबंधन मॉडल

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

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

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

एक प्रबंधन मॉडल को लागू करने में बाधाएं

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

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

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

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

लाल फीता

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

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

दिशा की हानि

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

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

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

नियंत्रण की हानि

शायद सभी का सबसे मजबूत डर यह डर है कि प्रबंधन मॉडल परियोजना प्रबंधन पर कब्जा करने के लिए तीसरे पक्ष के लिए रास्ता खोल देगा। अंत में, शासन मॉडल परियोजना में तीसरे पक्ष की भागीदारी का पक्ष लेता है, जो उन्हें परियोजना पर अधिकार देता है। हालांकि, जैसा कि यहां उल्लेखित अन्य सभी मामलों के साथ है, एक अच्छी तरह से डिज़ाइन किया गया प्रबंधन मॉडल विश्वास दिलाता है कि नियंत्रण वही रहेगा जहाँ परियोजना नेता इसे चाहते हैं। इसका अर्थ यह हो सकता है कि किए गए सभी निर्णय एक केंद्रीय संगठन (जैसे MySQL या SuragCRM) द्वारा नियंत्रित किए जाते हैं, या यह कि सभी निर्णय पूरी तरह से समुदाय द्वारा किए जाते हैं (उदा। अपाचे HTTPD सर्वर या DoJo)।

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

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

जब कोई समुदाय विभाजित होता है (कांटा)

ओपन सोर्स लाइसेंसिंग मॉडल की एक ताकत यह है कि कोई भी सोर्स कोड ले सकता है और स्वतंत्र विकास शुरू कर सकता है। इसे कांटा कहते हैं। इसका मतलब यह है कि परियोजना के नेताओं द्वारा नियंत्रित नियंत्रण परियोजना समुदाय द्वारा इन नेताओं के समर्थन के रूप में मजबूत है।

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

परियोजना अभी भी युवा या छोटी है

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

यह सही प्रबंधन मॉडल चुनने के लिए कभी भी जल्दी नहीं है। इसके बिना, संभावना है कि तीसरे पक्ष परियोजना में भाग लेना चाहते हैं, बहुत कम हो गए हैं। और इसके कई कारण हैं:

• संभावित प्रतिभागियों को पता नहीं है कि कैसे भाग लेना है
• उन्हें यकीन नहीं है कि वे समझते हैं कि परियोजना में उनके योगदान से क्या होगा
• तीसरे पक्ष के साथ बातचीत के मामले में परियोजना पर्याप्त गंभीर नहीं है
• इस बात की कोई स्पष्ट गारंटी नहीं है कि परियोजना में योगदान का सही तरीके से निपटारा किया जाएगा, जिसने उस प्रतिभागी का उल्लेख बरकरार रखा है जिसने इसे बनाया है

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

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

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

लगभग। लेन: लेख बड़ा है, इसलिए इसे दो भागों में विभाजित किया गया है। जारी रखने के लिए ...