आर्थिक रूप से जीएनयू सॉफ्टवेयर विकास कैसे बरकरार है?


10

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

सिद्धांत रूप में, GNU सॉफ्टवेयर पूरी तरह से स्वयंसेवकों द्वारा अपने खाली समय के दौरान, या उन कंपनियों द्वारा विकसित किया जाता है जो GNU सॉफ़्टवेयर (अपनी गतिविधि के दूसरे क्षेत्र से आय का उपयोग करके) विकसित करने के लिए स्वैच्छिक निधि प्रोग्रामर हैं।

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

समस्या यह है कि यह निम्न कारणों से बड़े कार्यक्रमों के लिए बेहद खराब है:

  1. प्रोग्रामिंग जितना मजेदार है, उतनी ही परियोजना को कार्यान्वित करना बड़ा हो जाता है, लेकिन वांछित कार्यक्षमता को लागू करने में लगने वाला समय बहुत जल्दी बढ़ता है। एक बड़े पैमाने पर कार्यक्रम को विकसित करने के लिए एक अविश्वसनीय मात्रा में समय लगता है, उदाहरण के लिए किसी ऑपरेटिंग सिस्टम को प्रोग्राम करने के लिए किसी व्यक्ति के लिए आसानी से खाली समय और छुट्टी का समय 15 साल लग सकते हैं, और जब तक उसका सॉफ्टवेयर जारी नहीं हो जाता, तब तक वह पूरी तरह से अप्रचलित हो जाएगा। ।
  2. जैसा कि अन्य लोग दूसरे तरीके से प्रोग्राम लिखते हैं कि जिस तरह से आपने इसे किया होगा, किसी और के कोड को पढ़ने और समझने में बहुत समय लगता है , ज्यादातर मामलों में खरोंच से अपना खुद का कोड लिखना जितना होता है। अन्य लोगों के कोड को संशोधित करना और इसे बेहतर बनाने का प्रयास करना, क्योंकि यह GNU दर्शन द्वारा प्रोत्साहित किया जाता है, लगभग उतनी ही समय लगता है जितना कि आप जिस कार्यक्षमता को जोड़ना चाहते हैं, उसके साथ उक्त कार्यक्रम का अपना क्लोन विकसित करना है।
  3. जैसे ही 2 या अधिक लोगों को एक बड़े कार्यक्रम को विकसित करने के लिए सहयोग करना होगा, इससे बहुत सारे निर्णय लेने की समस्या पैदा होती है जो कभी भी एक एकल-डेवलपर परियोजना पर नहीं पैदा होती। इसका परिणाम यह है कि, उदाहरण के लिए, यदि 2 प्रोग्रामर का एक समूह एक ऐसी परियोजना के लिए सहयोग करता है जिसे बनाने में 10 साल लगेंगे, तो वे इसे 5 साल में नहीं बनाएंगे, लेकिन शायद 8 में।
  4. यदि उसी परियोजना के लिए सहयोग करने वाले लोग पूरी तरह से इंटरनेट पर मिलते हैं, तो परियोजना के एक सदस्य के लिए अचानक गायब हो जाना आसान है (या तो क्योंकि वह रुचि खो देता है या क्योंकि वह शारीरिक रूप से इंटरनेट पर अब और नहीं हो सकता है), इस प्रकार से भी सहयोग करना और जोर से

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

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

  • एक बड़े कार्यक्रम का विकास इतनी लंबी अवधि की विशाल परियोजना है, वे अपने खाली समय का उपयोग अन्य गतिविधियों के लिए करते हैं जो अल्पावधि में अधिक फायदेमंद या अधिक सुखद होते हैं।
  • यदि वे वैसे भी एक बड़े कार्यक्रम को विकसित करने के लिए थे, तो वे इसे एक कंपनी के लिए करेंगे जो उन्हें मुफ्त में करने से भुगतान करेगा

लंबे समय में जीएनयू / लिनक्स, जीसीसी या ओपन ऑफिस जैसे कार्यक्रम को विकसित करने में रुचि रखने वाले लोगों को प्राप्त करने के लिए, इसे पुरस्कृत किया जाना चाहिए। तो मेरा सवाल यह है कि जीएनयू परियोजना में लोगों का योगदान क्यों है, अगर उन्हें इसके लिए वेतन नहीं मिल रहा है?


क्या आप अंक 2, 3 और 4 के लिए कुछ सबूत दे सकते हैं? मैं बिंदु 2 से सबसे अधिक असहमत हूं, लेकिन 3 और 4 भी देखने के दिलचस्प बिंदु हैं जो मैंने ओपन सोर्स सॉफ़्टवेयर विकसित करते समय वास्तव में अनुभव नहीं किए हैं। मैं अपने खुद के अनुभवों के साथ अद्यतन करूँगा जब मुझे समय मिलेगा
क्रिस्टोफरोवेल्ल

खैर 2 प्रोग्रामिंग भाषा पर बहुत अधिक निर्भर करता है, और कार्यक्रम की वास्तुकला के प्रलेखन में डाल दिया गया प्रयास। सबूत के लिए, मैं यह , यह और यह देख सकता
हूं

@ आपकी टिप्पणी में आपके दो उदाहरण 9 साल से अधिक पुराने हैं। ओपन सोर्स सॉफ्टवेयर ने तब से एक लंबा सफर तय किया है, जो वेब के विकास और जीआईटी जैसे उपकरणों के लोकप्रियकरण द्वारा सक्षम है जो साझा करना और विकास करना अच्छा है, पठनीय कोड बहुत आसान है।
क्रिस्टोफरोवेल

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

जवाबों:


5

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

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

लेकिन स्केलेबिलिटी के बारे में अपने बिंदुओं के बारे में बात करते हैं।

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

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

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

  4. लोग हर समय परियोजनाओं में और बाहर जाते हैं। लेकिन अगर यह परियोजना लोकप्रिय है, तो इस पर पर्याप्त काम किया जाएगा।

यहाँ कुछ कारण हैं कि क्यों खुला स्रोत काम करता है।

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

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

यदि आप अभी भी रुचि रखते हैं, तो मेरा सुझाव है कि आप कैथेड्रल और बाज़ार को पढ़ें


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

हो सकता है कि आप इसे स्टैकओवरफ़्लो पर पोस्ट करें और कुछ वास्तविक प्रोग्रामर से उत्तर प्राप्त करें। वे आपको वास्तविक अनुभव के आधार पर उचित उत्तर दे सकते हैं।
रुड फादेन

1
रेड हैट के बारे में आपकी बात, लेकिन उनके नौकरी के प्रस्तावों पर एक त्वरित नज़र डालने के बाद, उनमें से ज्यादातर बिक्री, विपणन और तकनीकी सहायता से संबंधित हैं, और केवल एक छोटा प्रतिशत विकास का उद्घाटन है। (यह एक अच्छा संकेत देता है जैसे कि उनकी आय कहाँ से आती है और उनका राजस्व कैसे वितरित किया जाता है)। इसके अलावा, इस सवाल को संभवतः स्टैक ओवरफ्लो पर ऑफ-
टॉप

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

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

2

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

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

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

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

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

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

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

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.