स्रोत कोड खोना कितना गंभीर है? [बन्द है]


9

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

संपादित करें: मान लें कि यह डिस्क ड्राइव के दुर्घटनाग्रस्त होने, प्राकृतिक आपदा या ऐसा कुछ भी नहीं है। बस उन्होंने इसे गलत बताया।


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

4
@ जोश के - बुरा सादृश्य! एक बच्चे को बदला नहीं जा सकता। स्रोत कोड कर सकते हैं। (और अगर आप उस सोर्स_कोड == बच्चे को सोचते हैं तो मैं बुरी तरह से हिल गया हूं)। लेकिन, मुझे लगता है कि आपके पास एक (अभी तक) नहीं है।
रूक

6
@Rook: यह एक बुरा सादृश्य क्यों है? स्रोत कोड को ठीक से प्रतिस्थापित नहीं किया जा सकता है, इसे केवल इसी तरह दोहराया जा सकता है। दी यह एक बच्चे को खोने के रूप में चरम नहीं है, लेकिन उपमा अभी भी ध्वनि है।
जोश के

6
@Rook: आप इस बिंदु को याद कर रहे हैं कि जबकि एक (बच्चे) स्पष्ट रूप से बहुत महत्वपूर्ण हैं, फिर स्रोत कोड, दोनों का कब्जा अभी भी क़ीमती है। आप मेरी सादृश्य को खारिज कर रहे हैं क्योंकि बच्चे अधिक महत्वपूर्ण हैं तो स्रोत कोड याहू को खारिज करने जैसा होगा! एक खोज कंपनी के रूप में क्योंकि Google इतना बड़ा है। मेरा कहना यह है कि दोनों बहुत बड़े हैं, तथ्य यह है कि एक ~ 10x के रूप में सार्थक / महत्वपूर्ण है तो दूसरा कोई मायने नहीं रखता है। आपको बताते हैं कि, आपकी कंपनियों के मुख्य आवेदन के लिए रिपॉजिटरी (और कोड की सभी प्रतियां) को ढीला करें और 5-10 में मेरे पास वापस जाएं।
जोश के

5
मुझे समझ में नहीं आता कि पहली जगह में "गलत" होने के लिए केवल एक प्रति कैसे हो सकती है? मैं आम तौर पर कम से कम दो या तीन प्रतियां अपने आप को ठीक करता है, अद्यतन और पैच है कि मैं पर काम कर रहा हूँ के विभिन्न चरणों में। मेरे सहयोगियों की अपनी प्रतियाँ होंगी। सबसे खराब रूप से, आप अपने स्रोत भंडार में इतिहास खो सकते हैं (यदि आप बिना बैकअप के केंद्रीय भंडार का उपयोग कर रहे हैं) ... मैं सिर्फ यह नहीं देखता कि यह कैसे संभव है ...
डीन हार्डिंग

जवाबों:


27

मान लीजिए कि एमएस विंडोज फोन 7 के लिए स्रोत खो देता है ... इसे विकसित करने के लिए अनुमानित लागत $ 400 मिलियन से कम वायाए के लिए लोग मारे गए हैं ।

उत्पाद के आधार पर, ऐसा कोई शब्द नहीं है जो मैं सोच सकता हूं कि 'बहुत मजबूत' है।


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

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

18

एक कंपनी के लिए यह ताज रत्नों को खोने जैसा है। यदि यह एक एम्बेडेड प्रोसेसर वाला उत्पाद है, तो वे उत्पाद को "जैसा है" बना सकते हैं, लेकिन वे इसे सुधारने या किसी भी समस्या को ठीक करने की क्षमता खो देते हैं।

आज के बाजारों में एक कंपनी है यह आईपी है। वह हार गया और वह व्यवसाय से बाहर चला गया।


13

जैसा कि दूसरों ने नोट किया है, यह संभावना "यह सब निर्भर करता है" शीर्षक के अंतर्गत आता है, इसलिए कुछ जोड़े

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

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

विकास में एक खेल के लिए स्रोत - अधिकांश वीडियो गेम कंपनियां वर्तमान में विकास में एक गेम के लिए कोड खोने का जोखिम नहीं उठा सकती हैं जब तक कि यह विकास चक्र (यानी दिनों, शायद हफ्तों में।) एक छोटी कंपनी के लिए स्रोत को खोना नहीं है। उनके प्रमुख रिलीज के कारण उन्हें व्यवसाय से बाहर जाना पड़ सकता है।

एक सीमित रिलीज वाले दर्शकों के साथ एक छोटे व्यवसाय के लिए स्रोत - कंपनी के लिए किसी भी समस्या का कारण बनने के लिए, हालांकि वे कुछ ग्राहकों को खो सकते हैं।

एक सीमित रिलीज वाले दर्शकों के साथ एक बड़े व्यावसायिक अनुप्रयोग के लिए स्रोत - एक और स्थिति जहां यह कंपनी को अपने ग्राहकों से विश्वास के नुकसान के कारण व्यवसाय से बाहर जाने का कारण हो सकता है। यहां तक ​​कि अधिकांश छोटे बाजारों में एक से अधिक कंपनियों का संचालन होता है और यह व्यवसाय के लिए एक प्रतियोगी के लिए पर्याप्त हो सकता है।

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

हालांकि बोर्ड के पार, मैं यह कहूंगा कि कोड खोने वाला व्यक्ति एक नई नौकरी की तलाश में होगा (और उसे ढूंढना मुश्किल हो सकता है!) और उन्हें कंपनी से मुकदमों का सामना भी करना पड़ सकता है।


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

3

हालांकि निश्चित रूप से ऐसे मामले हैं जहां यह प्रलयकारी हो सकता है, मुझे लगता है कि बहुत सारे हैं जहां यह नहीं है (कम से कम सॉफ्टवेयर के नजरिए से)।

मुझे लगता है कि कंबल का जवाब देने के लिए अभी तक कई चर हैं जैसे कि कोई कानूनी नतीजे हैं, लेकिन यह निर्धारित करने में विचार करने के लिए कुछ मुट्ठी भर प्रश्न शामिल होंगे:

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

और मुझे यकीन है कि बहुत सारे अन्य कारक हैं जिन पर विचार किया जाना चाहिए। बेझिझक जोड़ें।

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


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

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

3

आह, यह स्पष्टीकरण आपको दिया गया है (टिप्पणियों में):

यह एक लंबे समय से पहले विकसित किया गया था, स्रोत नियंत्रण के बिना, वे यह सब इस समय बेच रहे हैं और अब अचानक उन्हें इसे अपडेट करने की आवश्यकता है

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

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

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


हां, यह सिर्फ उन कई उत्पादों में से एक है जो वे बेचते हैं
जोएलफैन

यह सिर्फ 1 ग्राहक नहीं है ... यह अब ओएस की नवीनतम रिलीज पर काम नहीं करेगा
जोएलफैन

1

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

इसका मतलब यह नहीं है कि यह कंपनी के लिए पूर्ण आपदा नहीं है । लेकिन यह एक वित्तीय आपदा है; कानूनी नहीं है। मैं शायद "सकल अक्षमता" शब्द के साथ शुरू करूंगा और वहां से अपना रास्ता काम करूंगा।


-1: "मुझे नहीं लगता कि वे मुसीबत में हैं" वे बग-फिक्स, पैच, या परिवर्तन नहीं कर सकते हैं जब Microsoft ऑपरेटिंग सिस्टम को "अपग्रेड" करता है। वे पूरी तरह से एक तेजी से घटते ग्राहक आधार के लिए बर्बाद हो रहे हैं और केवल नई बिक्री बेवकूफों को पूरा करने के लिए होगी। (एक गैर-शून्य आबादी, लेकिन sfotware पर खर्च करने के लिए बहुत सारे पैसे के बिना।)
S.Lott

@ S.Lott: क्या अधिक महत्वपूर्ण हो सकता है, वे भी recompile नहीं कर सकते। यदि ग्राहक के वातावरण में कुछ भी परिवर्तन होता है, तो सॉफ्टवेयर काम नहीं करेगा।
डेविड थोरले

1

सच कहूं तो, मुझे लगता है कि यह इस्तेमाल की जाने वाली भाषा पर निर्भर करता है। यदि आप C # कोडबेस खोते हैं, तो इसे बहुत आसानी से विघटित किया जा सकता है, लेकिन यदि आप C ++ कोडबेस खो देते हैं, तो यह बहुत बुरा है।


इस बिंदु पर विघटित जहां यह अभी भी बनाया और चलाया जा सकता है, लेकिन क्या यह अभी भी बनाए रखा जा सकता है?
Jay

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

जब तक आपके पास केवल कोड ही बाधित न हो, उस स्थिति में यह दर्द का एक छोटा सा हिस्सा होने वाला है।
मिया

1

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

"अविश्वसनीय मूर्खता" के बारे में कैसे?


0

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

ऐसे कई काम हैं जिनकी तुलना सॉफ्टवेयर बनाने के लिए शारीरिक तुलना है।


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

@ डेविड: मुझे नहीं लगता कि आप मेरी उपमा को समझ पाए हैं। यदि कोई वास्तुकार किसी भवन की योजनाओं को खो देता है, तो उसे एक नया निर्माण करने के लिए योजनाओं को फिर से बनाना होगा। मैं यह भी नहीं देखता कि दूसरे वास्तुकार किसी इमारत में बदलाव की देखरेख कैसे कर सकते हैं यदि उनके पास जाने की योजना नहीं है। आपने ऑटोमोबाइल सादृश्य को पूरी तरह से गलत बताया। हालाँकि, आपने बताया कि यह किसी भी तरह कमज़ोर समानांतर था।
मेंढकप्रात्र fro

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

@ डेविड: मैं असहमत हूं।
frogstarr78

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

0

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

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

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

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

चीयर्स,

केविन

पुनश्च मुझे उम्मीद है कि यह केवल एक सैद्धांतिक सवाल है ... :)


-1

यदि उन्हें कोई कीड़े ठीक करने की जरूरत नहीं है, तो यह शायद एक बड़ा सौदा नहीं है। उदाहरण के लिए, यदि कंपनी कस्टम ActiveX नियंत्रण बनाती है, और वे अपने एक विरासत उत्पाद को स्रोत खो देते हैं, तो वास्तव में कौन परवाह करता है? उत्पाद शायद सक्रिय रूप से बनाए नहीं रखा गया है, और संभवतः आक्रामक रूप से विपणन नहीं किया जा रहा है। वे इसे तब तक बेचेंगे जब तक लोग अभी भी 32-बिट ActiveX का उपयोग करते हैं, और फिर इसके बारे में भूल जाते हैं।

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


-1: "यदि उन्हें किसी भी कीड़े को ठीक करने की ज़रूरत नहीं है" तो पूर्णता का एक महत्वपूर्ण स्तर क्या है। सॉफ्टवेयर कौन अच्छा है? किसी को?
एस.लूट

1
"बग्स को ठीक नहीं करना"! = "बग्स नहीं"। कंपनियों के बहुत सारे EOL'd सॉफ़्टवेयर को उन ज्ञात बग्स की सूची के साथ बेचना जारी रखते हैं जिनका उनके पास फिक्सिंग का कोई इरादा नहीं है। Win98 के लिए USB ड्राइवर की तरह - वे वहां से बाहर हैं, वे शायद सही नहीं हैं, लेकिन मुझे संदेह है कि किसी के भी बग फिक्सिंग में हैं।
TMN
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.