ओपन सोर्स सॉफ्टवेयर भी जल्द ही जारी [बंद]

Question

ओपन सोर्स सॉफ्टवेयर को भी जल्द जारी करने की नैतिक जिम्मेदारी क्या है? उदाहरण के लिए, एक क्लोज-टू-कंप्लीट प्रोडक्ट जिसे पूरी तरह से टेस्ट नहीं किया गया है।

प्रोग्रामर की क्या उम्मीद है? जब तक यह पूरी तरह से परीक्षण नहीं किया जाता है, तब तक प्रतीक्षा करें, या स्रोत खोलने के लिए जारी करें और फिर आगे विकास, परीक्षण और प्रगति जारी रखें?

डर यह है कि सॉफ्टवेयर खुला है और उपभोक्ताओं के लिए समस्या पैदा कर सकता है।

क्या यह एक निराधार डर है?

Comments

यदि आप चिंतित हैं तो एक अस्वीकरण जोड़ें। :)

— वॉन हिल्ट्स

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

— डेविड एमएच 4'15

@ विघ्नहिल्ट्स मुझे किसी के क्रोधित होने की चिंता नहीं है, यह चिंता पूरी तरह से सॉफ्टवेयर वितरण और उपभोग की बेहतरी के लिए है। यह बाद की बात है कि मैं एक रिलीज के लिए बहुत उत्सुक होने के कारण पीड़ित नहीं होना चाहता।

— थॉमस स्ट्रिंगर

@ दाविद्म: यह मेरी मुख्य चिंता का विषय भी होगा, "एक बार जला दिया, दो बार शर्मीला"।

— Matthieu M.

स्रोत जारी करना लेकिन बायनेरिज़ तैयार होने से पहले अपने सॉफ़्टवेयर का उपयोग करने से गलत उम्मीदों वाले लोगों को रोकने के लिए एक अच्छा तरीका नहीं हो सकता है।

— मोनिका

Answer 1

मैं इसके विपरीत मानता हूं कि आपको जल्द से जल्द एक ओपन सोर्स सॉफ्टवेयर जारी करना चाहिए। उसके लिए कोई "बहुत जल्द" नहीं है (लेकिन यह संकलन करना चाहिए)।

^{या कम से कम स्रोत कोड को बहुत जल्दी और लगातार प्रकाशित करें (जैसे कि जीथब पर लगातार पुश द्वारा ), बिना औपचारिक रिलीज किए।}

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

मुफ्त सॉफ्टवेयर के साथ , जो सबसे अच्छा होना चाहिए वह यह है कि कोई व्यक्ति स्रोत कोड में नज़र रखता है और आपको एक छोटे से पैच को सुधारने का प्रस्ताव देता है। यही कारण है कि आप अपने सॉफ़्टवेयर को मुफ्त बनाते हैं!

^{इसलिए, आपको अपने मुफ्त सॉफ्टवेयर पर अपने दैनिक कार्य को दिखाई देने की आवश्यकता है! यदि उनके पैच के साथ काम नहीं करेगा, या आपके हालिया सॉफ़्टवेयर स्रोत कोड का डुप्लिकेट है, तो बाहरी योगदानकर्ताओं को नाराज कर दिया जाएगा।}

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

Answer 2

टी एल; डॉ:

जल्दी रिलीज। अक्सर रिलीज।

व्यक्तिगत किस्सा:

मैं उस परियोजना के बारे में वास्तव में उत्साहित था जिस पर मैं काम कर रहा था। जैसे, वास्तव में उत्साहित। मैं रात को उत्तेजित होकर सो नहीं सका। इसलिए, मैंने अपने सह-देव को v1.0 तेज़ी से जारी करने में धकेल दिया, जिससे वह चाहता था।

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

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

यह आसानी से भले ही दूसरे रास्ते से जा सकता था। हम उन बग रिपोर्ट की अनदेखी कर सकते थे। या हम जल्दी से प्रतिक्रिया नहीं कर सकते थे। यह एक अलग कहानी हो सकती है अगर कुछ हफ्तों के बजाय हमें v1.1 जारी करने में 3 महीने लग गए।

Comments

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

— आर ..

हाँ। मैं हिंद में दृष्टि से सहमत हूँ। हालांकि निष्पक्ष होने के लिए, मुझे लगा कि मैंने इसका पूरी तरह से परीक्षण किया है। मैंने सोचा था कि यह उस समय 1.0 था @R ... मैं गलत था।

— रबरडैक

Answer 3

यह बंद स्रोत सॉफ़्टवेयर के समान है। संचार महत्वपूर्ण है।

उपयोगकर्ताओं को सूचित करें कि सॉफ्टवेयर की स्थिति क्या है और यह डाउनलोड के लिए क्यों उपलब्ध है।

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

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

Comments

क्या हमें यह अनुमान लगाना चाहिए कि "बीटा" ठोस नहीं होना चाहिए ? मैं "बड़ी सॉफ्टवेयर कंपनियों" को "बीटा" कह रहा हूं, जब यह उत्पादन-तैयार होने वाला है, सॉफ्टवेयर को वास्तविक दुनिया के डेटा से सामना करने के लिए। शायद इसे एक प्रोटोटाइप कहते हैं ?

— पियरे अरलाउड

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

— पीटर

मैं प्रोटोटाइप बिल्ड के लिए अब "अल्फा बिल्ड" शब्द का उपयोग करता हूं। यह लोगों को यह समझ देता है कि "यह बात अभी तक लोगों को भी नहीं आई है! उम्मीद मत करो कि यह लगभग पूरा हो जाएगा।"

— रबरडैक

आप इसे एक अलग रूप में वितरित कर सकते हैं, उदाहरण के लिए केवल स्रोत रूप में, बाइनरी पैकेज के बिना।

— el.pescado

गेमिंग इंडस्ट्री बदलने से पहले @SteveJessop का मतलब था "बीटा" से, मैं आपसे सहमत होता। =)

— रबरडैक

Answer 4

कोई भी नैतिक जिम्मेदारी नहीं है। किसी को भी आपके आधे बेक्ड सॉफ़्टवेयर का उपयोग करने के लिए मजबूर नहीं किया जा रहा है।

केवल एक ही चीज की चिंता करना आपकी विश्वसनीयता होगी।

Comments

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

— gnat

@gnat: यह असत्य है कि यह उत्तर स्पष्टीकरण के बिना है - स्पष्टीकरण बहुत ही अगला वाक्य है: "किसी को भी आपके आधे-बेक्ड सॉफ़्टवेयर का उपयोग करने के लिए मजबूर नहीं किया जा रहा है"। यह एक छोटी व्याख्या है, हाँ, लेकिन यह अभी भी "कोई नैतिक जिम्मेदारी नहीं है" कहने के लिए REASON है

— स्लीपबेटमैन

@gnat: वही अधिकांश उत्तरों के बारे में कह सकता है। "मुझे विश्वास नहीं है कि आपको रिलीज़ करना चाहिए [...] इसे ध्वजांकित करना बहुत महत्वपूर्ण नहीं है [...]"। क्या आप इस उत्तर के लिए अधिक बाहरी स्रोतों की अपेक्षा कर रहे हैं?

— पियरे अरलाउड

वहाँ अच्छी राय और बुरा राय है। मैं आपसे सहमत हूं, लेकिन आपको एक मजबूत तर्क के साथ इसे देखना अच्छा लगेगा।

— रबरडक

Answer 5

मेरा अनुभव यह है कि हासिल करने के लिए एक संतुलन है।

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

दूसरी ओर, कम-गुणवत्ता वाले रिलीज़ एक नई परियोजना को खराब कर सकते हैं इससे पहले कि यह जमीन पर भी उतर जाए। मैंने देखा है कुछ नुकसान:

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

अंतिम बिंदु के लिए, मैं चीजों की तरह सोच रहा हूं:

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

इस प्रकार की समस्याएं एक "वेपरवेयर" छवि को उधार देती हैं जो तब तक हिलाना मुश्किल हो सकता है जब तक कि आप शुरू करने के लिए काम करने वाले कोड की कमी के बारे में बहुत खुले नहीं होते।

अंत में, अपने वर्जन नंबरों को समझ में आता है। अपने प्रोजेक्ट "1.0" को तब तक कॉल न करें जब तक कि यह ऐसा न हो कि उपयोगकर्ता इसे बिना दुर्घटनाग्रस्त होने की उम्मीद करें। मुझे हमेशा प्रारंभिक सार्वजनिक रिलीज के लिए "0.5" के आसपास संस्करण संख्याओं का उपयोग करने और वहां से जाने के साथ किस्मत मिली है, लेकिन मैंने "0.1" या "0.10" जैसी चीजों को भी देखा है जो समझ में आते हैं।

Answer 6

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

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

लियू क्यूओओ और सियारन ओ'रियार्डन द्वारा माइक्रोसॉफ्ट के 'ओपन सोर्स' .NET के बारे में " 4 शिफ्टी विवरण " एक समान तरीके से CLR के अपूर्ण कार्यान्वयन को बाहर करने के लिए .NET लाइब्रेरी और रनटाइम घटकों के लिए Microsoft पेटेंट वाद की व्याख्या करने की संभावना का उल्लेख करता है। । लेकिन फिर, यह CLR में चलने वाले अनुप्रयोगों पर लागू नहीं होता है।

Comments

यह केवल तभी महत्वपूर्ण है जब आप JRE / JDK कार्यान्वयन बनाना चाहते हैं, न कि उस पर चलने वाले किसी जावा प्रोग्राम को, AFAIK।

— sjas

@ एसजेज क्या आप यह अनुमान लगाने की कोशिश कर रहे हैं कि जेएलएस एकमात्र युक्ति है जिससे किसी को मुठभेड़ होने की संभावना है कि यह "अपने आप को पूरा करने या इसे रखने" का प्रतिबंध है?

— दामियन येरिक

आप यह थोपने की कोशिश कर रहे हैं कि मैं इसे थोपता हूं। ;)

— सुजास

@ तेजस धन्यवाद। क्या कोई और तरीका है जिससे मैं इस उत्तर को उपयोगी बना सकता हूँ?

— डेमियन येरिक

मैंने btw को कम नहीं किया। मैंने पहले से ही गलतफहमी को दूर कर दिया, जो कि जब मैंने पहली बार आपके उत्तर को पढ़ा था। यदि आप कुछ बदलना चाहते हैं तो आप इसे अपनी पोस्ट में शामिल कर सकते हैं।

— साजास