💵 🦆 😞 सुविधा-दान से संचालित विकास 🕝 🚉 🕚

हेलो हब्र!

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

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

तो, किन विचारों ने आधार बनाया:

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

इन समस्याओं का हल थोड़ा संशोधित भीड़ धन मॉडल, स्वागत है ...

सुविधा-दान से संचालित विकास

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

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

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

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

स्वाभाविक रूप से, इसके नुकसान भी हैं:

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

सुविधाएँ जीवनचक्र सुविधाएँ

सभी सुविधाएँ एक सामान्य पूल में हैं। कोई भी पूल में एक सुविधा जोड़ सकता है, जबकि इसमें चर्चा की स्थिति होगी।

चर्चा

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

वित्त पोषण

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

डिज़ाइन

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

सार्वजनिक परीक्षण

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

स्थिर संस्करण में एकीकरण

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

समस्याओं और संभव समाधान

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

समस्या : उपयोगकर्ता परियोजना के विकास के लिए दान नहीं करते हैं।
समाधान : इसके कई कारण हो सकते हैं। सबसे अविश्वसनीय - उत्पाद का मौजूदा संस्करण एकदम सही है और इसे अंतिम रूप देने की आवश्यकता नहीं है। इस मामले में, कोई केवल ऐसे उत्कृष्ट सॉफ़्टवेयर के डेवलपर्स के लिए उपयोगकर्ताओं के आभार की उम्मीद कर सकता है। एक अधिक वास्तविक कारण यह है कि डेवलपर अनुरोध बहुत अधिक हैं। सहमत हूँ, कोई भी किसी भी बटन की पृष्ठभूमि को बदलने के लिए $ 1000 का भुगतान नहीं करेगा, भले ही यह 146% से प्रयोज्य बढ़ जाए। वास्तविक लक्ष्य निर्धारित करें और पर्याप्त मात्रा में पूछें (उदाहरण के लिए, आप आवश्यक समय और आपके काम के एक घंटे की लागत के आधार पर दान की राशि की गणना कर सकते हैं)। इसके अलावा, यह संभव है कि उत्पाद के लक्षित दर्शक केवल दिवालिया हो। फिर आपको या तो एक अलग दर्शक वर्ग को पुनर्गठित करने की जरूरत है, या दान में संलग्न होना शुरू करना होगा।

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

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

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

निष्कर्ष

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

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

आपका ध्यान देने के लिए धन्यवाद।

सुविधा-दान से संचालित विकास