एक वाणिज्यिक सॉफ्टवेयर उत्पाद में खुले स्रोत कोड का उपयोग करने की बुद्धि

13

मैं अपने ASP.NET वेब ऐप (विशेष रूप से डैपर ) में कुछ ओपन सोर्स कोड का उपयोग कर रहा हूं । प्रबंधन एक प्रशंसक नहीं है, क्योंकि खुले स्रोत को एक जोखिम के रूप में देखा जाता है जिसने हमें पहले काट लिया है। खुले स्रोत के घटक विफल होने के बाद जाहिर तौर पर पिछले डेवलपर्स को चीजों को फिर से लिखना पड़ा है।

पेशेवरों को लगता है:

यह मेरे लिए बहुत सा सामान करता है जिसमें या तो बहुत सारे बॉयलरप्लेट कोड या माइक्रोसॉफ्ट के अनुशंसित लेकिन धीमे समाधान (एंटिटी फ्रेमवर्क) शामिल होंगे।

विपक्ष:

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

यहां सर्वसम्मति क्या है? क्या मेरी परियोजना में खुले स्रोत कोड का उपयोग करना नासमझी है जिसे मैं स्वयं अपना कोड नहीं जानता / समझता / समझता हूं?

open-source management risk-assesment

— श्री जेफरसन
स्रोत

15

ASP.NET और यह स्टैक खुला हुआ है।

— एंड्रयू टी फिननेल

11

"क्या यह मेरी परियोजना में खुले स्रोत कोड का उपयोग करने के लिए नासमझ है जिसे मैं स्वयं अपना कोड नहीं जानता / समझा जा सकता है?" ब्लैक-बॉक्स वाले बंद-स्रोत पुस्तकालयों के विपरीत?

— user16764

5

@AndrewFinnell: FLOSS आंदोलन की अपनी परिभाषा से नहीं।

— tdammers

6

आप के बारे में सोच रहे हैं कि विशिष्ट ओएस परियोजना, यह ब्याज की हो सकती है कि Dapper StackExchange द्वारा उपयोग किया जाता है ...

— मार्जन

4

यह तकनीकी प्रश्न नहीं है, यह ऐसा नहीं है जो बेहतर है। कौन सा गलत होगा MFC मृत है, XP 2 साल से कम समय में मृत हो जाएगा आदि नि: शुल्क और ओपनसोर्स परियोजना मर नहीं जाएगी यदि वे किसी भी अच्छे हैं, जैसा कि आप या कोई और उन्हें ले सकता है। यह इस बारे में है कि किसे दोषी ठहराया जाएगा। यदि आप Microsoft चुनते हैं, तो अप्रत्याशित होगा, या माइक्रोसॉफ़्ट दोष होगा। यदि आप फ्री / ओपनसोर्स के लिए जाते हैं तो यह आपकी गलती होगी।

— ctrl-alt-delor

20

यह एक विकल्प है जो आपको विशिष्ट परिस्थितियों के आधार पर बनाना होगा। आप अपने जोखिमों को कम कर सकते हैं:

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

अंततः, एक भारी-भरकम उपयोग किए जाने वाले ओपन-सोर्स प्रोजेक्ट के साथ, आप अपने द्वारा चलाए जा रहे कुछ मुद्दों को ठीक करने की तुलना में अपना स्वयं का लेखन करने में बहुत अधिक समय व्यतीत करने की संभावना रखते हैं।

— StriplingWarrior
स्रोत

16

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

एक बार जब आप अपने व्यवसाय के डोमेन में आने लगते हैं तो आपकी आवश्यकताओं को पूरा करने वाले ओएसएस को खोजने के लिए आपको और अधिक कठिन हो जाएगा। लेकिन अभी तक एक और ओआरएम उत्पाद को फिर से लागू करने की आवश्यकता नहीं है। यदि डॅपर पर्याप्त जटिल है कि आप डिबग नहीं कर पाएंगे और उनके कोड को ठीक कर सकते हैं तो आप इसे स्क्रैच के साथ लिखने वाले सभी आदमी घंटे खर्च करने को कैसे सही ठहराएंगे? इसके अलावा, आप अपने (उस समय) NoSQL समाधान के बॉक्स के बाहर हमेशा देख सकते हैं।

यहां तक कि लिनस ने स्वीकार किया कि उन्होंने एससीएम समाधान खोजने का प्रयास किया था जो गिट विकसित करने से पहले उनके सभी मानदंडों को पूरा करता था। कम से कम वह समझाने में सक्षम था कि मौजूदा समाधानों में से कोई भी पर्याप्त क्यों नहीं था।

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

— एंड्रयू टी फिनेल
स्रोत

2

+1 मैं उन सभी से सहमत हूं, जहां आप कहते हैं कि सिवाय इसके कि वह "(चाहिए)" NoSQL को देखें; प्रत्येक NoSQL डेटा भंडारण समाधान - कई हैं - व्यापार-नापसंद का एक विशेष सेट "मानक" SQL रिलेशनल डेटाबेस है, इसलिए बहुत सारी जानकारी के बिना "कहना" मुश्किल है। कभी-कभी वे अच्छे ट्रेड-ऑफ होते हैं, और कभी-कभी नहीं, लेकिन आप इसके बारे में कंबल बयान नहीं कर सकते। '' NoSQL '' बहुत ही आम डेटा स्टोरेज स्कीम नहीं होने की तुलना में आम तौर पर कम प्रौद्योगिकियों के एक समूह के आसपास बकवास ब्रांडिंग कर रहा है।

— डोनाल्ड फेलो

लेकिन बाकी सब आप लिखते हैं, मैं निश्चित रूप से सहमत हूं। अच्छे काम करने वाले डेवलपर के कंधों से अच्छा OSS बहुत प्रयास करता है (और कौन बुरा OSS का उपयोग करना चाहेगा?)

— डोनल फेलो

डैपर जटिल है क्योंकि यह सामान्यीकृत है। यदि मुझे अपना समाधान लिखना होता, तो मैं बहुत सारे बॉयलरप्लेट डेटासेट-टू-ऑब्जेक्ट रूपांतरण कोड (यानी MyClass.Property = set.Tables[0].Rows[i]["Property"].ToString()) करता।

— श्री जेफरसन

एक बार जब आप अपने व्यवसाय के डोमेन में आने लगते हैं, तो आपको अपनी आवश्यकताओं को पूरा करने वाले --OSS-- कुछ भी खोजने के लिए अधिक कठिन हो जाएगा । जब तक Microsoft का व्यवसाय आपका व्यवसाय नहीं है। (लेकिन आपने जो कहा, वह मुझे पसंद है।)

— ctrl-alt-delor

@richard मेरे कुछ उत्तर अस्पष्ट हो सकते हैं। आपका कथन जो मैं कह रहा हूं वह भी है। क्यों उन टुकड़ों पर ध्यान केंद्रित करें जिन्हें ओआरएम की तरह बार-बार हल किया गया है। बिजनेस डोमेन पर ध्यान दें। ORM व्यवसाय डोमेन नहीं है जब तक कि आप ORM उत्पाद नहीं बेच रहे हैं।

— एंड्रयू टी फिननेल

15

नोट: मैं Microsoft कर्मचारी नहीं हूं। राय पूरी तरह से व्यक्तिगत है। कई विचार डेवलपर के रूप में बड़े विक्रेताओं के साथ मिश्रण में दोनों खुले स्रोत का उपयोग करने के पिछले 5-7 वर्षों से हैं।

मोनोकल्चर अच्छा है: ASP.NET के लिए मेरा व्यक्तिगत नियम Microsoft को वरीयता देना है और जब तक कोई अन्य विकल्प नहीं है तब तक 3 पार्टी कोड (ओपन सोर्स या नहीं) का चयन न करें। मोनोकल्चर पुरस्कृत कर रहा है, क्योंकि आपको बड़े विक्रेता द्वारा ले जाया जा रहा है, और एक ही अनुभव को दोहराने वाले उपयोगकर्ताओं की मात्रा किसी भी समय बड़ी है जो मदद पाने और वर्कअराउंड ढूंढने के लिए पर्याप्त है।

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

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

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

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

3

+1: मैं यह नहीं कह सकता कि मैं पूरी तरह से सहमत हूं, लेकिन इसका बहुत अच्छा तर्क नहीं है .....

— मैटनज़ 30'12

14

"ओपन सोर्स प्रोजेक्ट बजट जैसी कोई चीज नहीं है।" असत्य है। Google ने ओपन-सोर्स प्रोजेक्ट्स के लिए एक बजट तैयार किया है, और उदाहरण के लिए Red Hat Inc. अपना व्यवसाय नहीं चला सकता है यदि वे अपने सॉफ़्टवेयर में पर्याप्त कोडर नहीं डालते हैं। और इस बारे में क्या? microsoft.com/opensource/directory.aspx

— ONOZ

14

मैं आपके द्वारा कहे गए एक शब्द से सहमत नहीं हूँ।

— एवियो

11

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

— फिलिप

3

मुझे इसका विपरीत अनुभव हुआ। हमने SQLite को एक उपकरण में पोर्ट किया और उस आदमी से सीधे समर्थन प्राप्त करने में सक्षम थे जिसने इसे सबसे अधिक लिखा था। वहाँ कोई रास्ता नहीं है हम बंद स्रोत कंपनी से सेवा के उस स्तर मिल गया है। कुछ ओपन सोर्स प्रोजेक्ट बिल्कुल मजबूत हैं और कुछ बंद स्रोत प्रोजेक्ट्स की तुलना में बेहतर सपोर्ट है। मैं OS / 2 के लिए "उद्योग मानक" Microsoft C ++ कंपाइलर का उपयोग करने के बारे में एक कहानी बता सकता हूं और जब Microsoft ने OS / 2 पर जमानत का फैसला किया तो उसके लिए समर्थन कैसे चला गया।

— को रोबोट

7

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

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

LGPL भी है, जो एक दिलचस्प बॉर्डर केस है जिसमें आप बाइनरी डायरी तक पहुंच को प्रतिबंधित करते हुए अपना कोड नहीं खोलते हुए इनका उपयोग कर सकते हैं। (यानी लाइब्रेरी को केवल डायनेमिक लाइब्रेरी के रूप में एक्सेस करता हूं।) एलजीपीएल लाइब्रेरी का उपयोग बहुत ही उल्लेखनीय है, बस आपको अधिक सावधान रहना होगा।

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

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

— रोबोट को पकड़ें
स्रोत

7

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

ऐसा लगता है कि आप परिपक्व परियोजनाओं का उपयोग करना चाहते हैं जो समर्थन प्रदान करते हैं। कुछ ओपन सोर्स प्रोजेक्ट्स पेड सपोर्ट प्रदान करते हैं, या एक बड़ा पर्याप्त समुदाय होता है जिसे आप सार्वजनिक मंच पर उत्तर प्राप्त कर सकते हैं। हो सकता है कि आपको पुस्तकालय चुनते समय परिपक्वता और समर्थन मानदंड प्राथमिकताएं बनाने चाहिए, चाहे वह बंद हो या खुला स्रोत।

यदि आप अपरिपक्व परियोजना का उपयोग करने का निर्णय लेते हैं, या सीमित समर्थन के साथ निर्णय लेने के लिए आपको यह स्वीकार करने की आवश्यकता है कि आप अधिक जोखिम उठा रहे हैं। जैसे कि आपको यह निर्धारित करने की आवश्यकता है कि आपकी जोखिम शमन योजना क्या है। उदाहरण के लिए, आप तृतीय-पक्ष सॉफ़्टवेयर पर अधिक परीक्षण कर सकते हैं।

— एम। डुडले
स्रोत

6

मान लिया जाए कि लाइसेंसिंग की समस्या यहां कोई समस्या नहीं है: डैपर पर एक त्वरित नज़र रखने पर, मैंने देखा कि यह अच्छी तरह से प्रलेखित, पठनीय कोड की सिर्फ 2255 पंक्ति थी । अर्थात्

इतना बड़ा कि आप कई दिनों या हफ्तों तक तुलनीय गुणवत्ता वाले कोड का उत्पादन करने के लिए निवेश कर सकते हैं
काफी छोटा है कि आप समझ सकते हैं कि यह क्या करता है और उस कोड के किसी भी कीड़े को ठीक करता है यदि वे उत्पादन में दिखाई देते हैं

यदि आप अपने दम पर ऐसा कुछ लिखने जा रहे हैं और "पहिया को फिर से मजबूत करें", तो आपको बहुत अधिक जोखिम है कि आपका खुद का कोड उत्पादन में कीड़े दिखाएगा, और आप वास्तव में "उन्हें ठीक करने के लिए कड़ी मेहनत" करेंगे।

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

हमारी एक परियोजना में, हमने भी, कुछ खुले स्रोत घटकों को पेश किया, जो छोटे से डैपर के रूप में पुस्तकालयों तक थे जिनमें कोड के लगभग 20K से 30K लाइनें थीं। हमारे पास हमेशा कुछ बदलाव करने, कुछ कीड़े ठीक करने, कुछ कम करने आदि थे, लेकिन यह ठीक था, क्योंकि हमें उम्मीद थी कि। यहां तक कि डिबगिंग के लिए समय भी शामिल था, खुले स्रोत का उपयोग करके हमें बहुत काम मिला।

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

— डॉक्टर ब्राउन
स्रोत

1

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

— लूनीवर

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

— श्री जेफरसन

दूसरी ओर, EF पर एक कस्टम समाधान चाहते हैं NIHS की तरह एक सा लगता है। मेरा डेटा स्कीमा बहुत सारे रिश्तों (विदेशी कुंजियों) के साथ काफी जटिल है, और उस बिंदु पर पहुंच रहा है जहां मेरा कस्टम समाधान उन रिश्तों का प्रबंधन करता है और साथ ही साथ ईएफ आउट-ऑफ-द-बॉक्स निश्चित रूप से थोड़ी देर लगेगा।

— श्री जेफरसन

@ Mr.Jefferson: गंभीरता से, मैं आपको एक अच्छी सलाह नहीं दे सकता कि आपके मामले में बेहतर समाधान क्या है, यह कुछ ऐसा है जिसे आपको अपने दम पर करना होगा। मैं बस आपको कुछ संकेत देने की कोशिश कर रहा था कि क्या विचार करना है।

— डॉक ब्राउन

+1। आपने इस पोस्ट के साथ कुछ बहुत ही बेहतरीन बिंदुओं को सामने लाया। @ Mr.Jefferson: मैं पिछले कुछ समय से एंटिटी फ्रेमवर्क का उपयोग कर रहा हूं, और यह खोजने में अड़चन के माध्यम से प्रदर्शन को प्रबंधित करने में काफी हद तक सफल रहा है कि अड़चनें कहां हैं। इसके अलावा, हमारा उत्पाद बहुत जटिल है, लेकिन मुझे अभी भी एक एसक्यूएल क्वेरी लिखने का सहारा नहीं लेना पड़ा है। मुझे लगता है कि ईएफ ने मुझे बहुत नियंत्रण दिया है।

— स्ट्रिपिंगवर्यर

2

जैसा कि मैंने इसे देखा है, यह एक संतुलन कार्य है।

यदि आप अपने आप को एक विक्रेता पर निर्भर करते हैं, तो यह लगभग निश्चित है कि समर्थन लंबे समय से पहले गायब हो जाएगा

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

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

— माइक डनलवे
स्रोत

1

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

प्रबंधन से पूछें कि यह पहले क्यों विफल हो गया था, क्या पर्याप्त परिश्रम किया गया था?

— टर्नकी
स्रोत

मुझे नहीं पता कि क्या हुआ है। इससे पहले कि मैं यहां पहुंचता।

— श्री जेफरसन

0

jquery के पास MIT लाइसेंस का उपयोग करने का विकल्प है, इसलिए कई वाणिज्यिक और सरकारी वेबसाइट भी jquery का उपयोग करती हैं। Microsoft की वेबसाइट का उपयोग jquery भी! इसलिए चिंता लाइसेंसिंग है। GPL / LGPL के उपयोग से बचें पर्याप्त है।

"कब तक एक रिपोर्ट दोष को ठीक करने के लिए?" बग की रिपोर्ट करने के बाद, यह मिनट, घंटे या दिनों के भीतर ठीक हो सकता है। तत्काल स्थिति के लिए, कर्मचारी स्रोत को प्राप्त करने और इसे स्वयं संकलित करने के लिए बस "गिट पुल" कर सकते हैं। वह केवल प्रबंधन को "v1.2.3-101-gd62fdae" जैसे संस्करण की रिपोर्ट करता है, जो ट्रेस करने योग्य है।

— linquize
स्रोत

0

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

— निमंजा ट्रिफ़ुनोविक
स्रोत

-1

क्या आप सुनिश्चित हैं कि प्रबंधन की समस्या तकनीकी चिंता है।

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

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

और याद करने के लिए एक और बिंदु - "कोई भी आईबीएम खरीदने के लिए निकाल दिया गया है"। (यानी प्रबंधन "यदि आप बहुत सारा पैसा खर्च करते हैं तो यह एक ऐसा उत्पाद है जो मुफ़्त है"

— mattnz
स्रोत

5

फिर विडंबना यह है कि आईबीएम शायद ओपन सोर्स आधारित सॉफ्टवेयर का सबसे बड़ा विक्रेता है। अपाचे http सर्वर, ग्रहण आदि आदि

— जेम्स एंडरसन

7

ओएसएस बेचना अवैध नहीं है। ऐसा क्यों होगा?

— tdammers

1

IBMS httpServer शुद्ध अपाचे है, यह सिर्फ एक समर्थन समझौते के साथ आता है।

— जेम्स एंडरसन

2

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

— एविओ

2

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

— Jan Hudec