"सॉफ्टवेयर एंड-ऑफ-लाइफ" स्थितियों से कैसे निपटें?


14

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

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

चीजें जो मैं सोच सकता हूं:

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

कोई अन्य विचार?

  • यह मानते हुए कि कोई "परिधि" शामिल नहीं है (कोई DRM, कोई DMCA), डेटा रिकवरी या रिवर्स इंजीनियरिंग कानूनी / स्वीकार्य है?

संपादित नोट:

यह कई किस्सों, लेकिन वास्तविक कहानियों का एक संयोजन है। मैं सीधे तौर पर उनमें से किसी में भी शामिल नहीं हूं। यह केवल "सॉफ़्टवेयर एंड-ऑफ़-लाइफ" स्थिति को सामान्य रूप से कैसे नियंत्रित किया जाता है, इसके बारे में जानने की मेरी इच्छा है। मूल कहानी को हल करने के लिए "मुश्किल" की तरह ध्वनि बनाना मेरा उद्देश्य नहीं है।


समय रेखा यहाँ क्या है? क्या आप एक ग्राहक हैं या उक्त विक्रेता के ऊपर एक उत्पाद का निर्माण करते हैं?

3
आप विक्रेता से स्रोत कोड खरीदने की कोशिश कर सकते हैं फिर अपना समर्थन करें? यह एक बहुत ही कठिन स्थिति है।
बीटी

2
यह जानने के लिए कि डेटा को किसी तरह के ओपन फॉर्मेट में स्टोर नहीं किया गया है, को आश्चर्यचकित करता है ... अगर इसे db में प्लेन टेक्स्ट के रूप में संग्रहीत किया जाता है, तो आप इसे कॉपी कर सकते हैं। यदि यह xml / सादे पाठ में संग्रहीत है, तो आप इसे कॉपी कर सकते हैं। यदि यह बाइनरी / एन्क्रिप्टेड है, तो आपको इसे क्रैक करने की आवश्यकता है। यह सब करने योग्य है।
नौकरी

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

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

जवाबों:


2

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

चूँकि आप जानते हैं कि यह एप्लिकेशन आपके लिए आवश्यक कुछ है, शायद अगर यह संभव है, तो घर में विकसित प्रणाली के लिए इसका समय? इस तरह आप फिर से इस स्थिति में समाप्त नहीं होंगे।


2

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


2
इंटर्न: आउटसोर्सिंग के स्थानीय समकक्ष
अर्लज़

Internsourcing!
पॉल नाथन

0

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

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

एक नोट: अगर सिस्टम कुछ जनता के सामने आता है तो यह एक बुरा तरीका है क्योंकि आपके पास सुरक्षा अद्यतन लागू करने का कोई तरीका नहीं है।

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