स्रोत नहीं-लाभ-लाभ कोड खोलने का कारण नहीं है? [बन्द है]


34

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

इससे पहले कि मैं बाहर जाकर धर्म-परिवर्तन शुरू, मैं जानना चाहता हूँ: वहाँ के लिए किसी भी अच्छे तर्क हैं नहीं नहीं के लिए लाभ कोड सार्वजनिक रूप से जारी है, और एक ओएसआई अनुरूप लाइसेंस के साथ?

(मुझे लगता है कि कुछ ऐसे ही सवाल हैं जो आसपास हैं, लेकिन ज्यादातर उन स्थितियों पर ध्यान केंद्रित करते हैं जहां कोड का इस्तेमाल मुख्य रूप से पैसा कमाने के लिए किया जाता है, और मैं उत्तरों में ज्यादा प्रासंगिक नहीं हो सकता।)

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


+1 जैसा कि मुझे लगता है कि एक दिलचस्प सवाल है। लेकिन मुझे आश्चर्य है कि क्या यह पूछने के लिए सही जगह है। हो सकता है कि आपको PM.SE साइट की तरह अन्य SE साइटों से अलग दृष्टिकोण मिले। केवल एक सलाह।
जाइलम

@ हाइलम, मैंने PM.SE नहीं देखा था, लेकिन ऐसा लगता है कि यह परियोजना प्रबंधन के तकनीकी पहलुओं के लिए अधिक है?
n

क्या आप बाद में परियोजना को सक्रिय रूप से बनाए रखेंगे या यह एक कोड कब्रिस्तान है। दूसरे शब्दों में, परियोजना का भविष्य क्या है।

@ ThorbjørnRavnAndersen: हाँ, मैं सक्रिय रखरखाव, विकास और कोड का उपयोग कर रहा हूँ।
n

जवाबों:


28

आपको यह ध्यान रखने की आवश्यकता है कि आपके कोड को खोलने वाले सोर्स को अतिरिक्त प्रयास की आवश्यकता हो सकती है।

एक उदाहरण के रूप में, इस ब्लॉग प्रविष्टि में सन / ओरेकल इंजीनियर उन प्रयासों का वर्णन करता है जो उन्हें अपने कोड सोर्सिंग करते समय लेने थे: ओपन सोर्स या डर्टी लॉन्ड्री?

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

एक अन्य तैयारी गतिविधि मालिकाना जानकारी, विशेष ग्राहकों, डेवलपर्स, प्रौद्योगिकियों आदि के उल्लेख को "स्क्रबिंग" करती है। यह थोड़ा कम स्पष्ट है, लेकिन निम्नलिखित उदाहरण पर विचार करें:

/\*
 \* HACK - insert a time delay here because the stupid Intertrode
 \* Technologies framebuffer driver will hang the system if we
 \* don't. Those guys over there must really be idiots.
 \*/

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

"स्क्रबिंग" गतिविधि का एक अन्य हिस्सा अपवित्रता और अन्य "अवांछनीय" शब्दों को दूर करना है ...

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


2
खैर, यह मौजूदा कोड-बेस वाली बड़ी कंपनियों के लिए लागू होता है, कोड के लिए बहुत कम है जो स्क्रैच से ओपन सोर्स लिखा जाता है।
कोनराड रुडोल्फ

1
@KonradRudolph ओपी ने उल्लेख किया कि मुझे काम करना है ... कोड जो खुला स्रोत नहीं है (या तो यह मालिकाना है, या यह सार्वजनिक नहीं है) जिसका अर्थ है कि यह खरोंच से नहीं हुआ है
gnat

क्या ऐसा ही 3 डीओएम 3 के साथ नहीं हुआ था? पेटेंट मुद्दा देरी कयामत 3 स्रोत कोड रिलीज
user16764

11

सुरक्षा।

उदाहरण के लिए, मान लें कि आप एक वेब फ्रेमवर्क बनाते हैं और आप स्वयं इसका उपयोग करते हैं।

एक गैर-लाभकारी परियोजना के रूप में, आपके पास एक हमले या किसी अन्य के लिए भेद्यता के लिए हर बिट कोड का निरीक्षण करने के लिए समर्पित करने का समय नहीं है:

  • CSRF
  • XSS
  • एसक्यूएल इंजेक्षन
  • सत्र निर्धारण
  • छोटी गाड़ी तीसरे पक्ष के पुस्तकालयों या यहां तक ​​कि भाषाओं का उपयोग

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

बेशक, यह उस प्रकार के सॉफ़्टवेयर पर लागू नहीं हो सकता है जिस पर आप काम कर रहे हैं; और हमेशा की तरह अस्पष्टता सुरक्षा में आलस्य के लिए कोई बहाना नहीं है।

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


7
यह बहस युगों से चली आ रही है, और मेरी धारणा यह थी कि सुरक्षा के लिए खुला स्रोत बेहतर है, लेकिन केवल अगर परियोजना काफी लोकप्रिय है (डेवलपर्स के बीच कम से कम)। यह अजीब है कि 'नेट पर कहीं भी तर्क का एक बहुत अच्छा रन-डाउन नहीं है (जो मुझे मिल सकता है, वैसे भी)।
n

1
Naught101s टिप्पणी के साथ संयोजन में जो बहुत कुछ समझ में आता है। यदि कम लोग आपके स्रोत की परवाह करते हैं और आप उत्पादन में उपयोग कर रहे हैं तो संभावना बहुत अच्छी है कि कोई "दुष्ट" इसका निरीक्षण करेगा और इसका उपयोग आपके खिलाफ (अंततः) करेगा
schlingel

1
अस्पष्टता के माध्यम से सुरक्षा?
डेन्यूबियन सेलर

3
@lechlukasz क्या आपने भी पूरी पोस्ट पढ़ी?
निकोल

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

10

स्रोत न खोलने का एक अच्छा कारण यह है कि आपके कुछ स्रोत कॉपीराइट हो सकते हैं। आप कितनी बार किसी समस्या के त्वरित समाधान के लिए वेब पर नहीं खोजते हैं और कोड का स्निपेट लेते हैं?

ठीक है, उन लोगों को कॉपीराइट किया जा सकता है और मुझे नहीं पता कि क्या लेखक एक अलग लाइसेंस के तहत अपने कोड को दोबारा प्राप्त कर सकता है।


1
कॉपीराइट के लिए +1। साथ ही पेटेंट भी जोड़ना चाहते थे। आपको बस यह पता चल सकता है कि आपका ओपन-सोर्स प्रोजेक्ट हजारों में से कुछ पर हजारों सॉफ्टवेयर पेटेंट का उल्लंघन कर रहा है, जो "कॉर्प्स" द्वारा बसाए गए हैं। वीडियो चल रहा है? पेटेंट। भुगतान-प्रति-क्लिक विज्ञापन? पेटेंट। बस कुछ उदाहरण हैं। हालांकि, संभावना है कि "कॉर्प्स" परवाह नहीं करते हैं - जब तक आप एक प्रतियोगी नहीं हैं।
आमादेस हेन

1
हेहे। यह वास्तव में खुले स्रोत के खिलाफ तर्क नहीं है, लेकिन चोरी के खिलाफ है। लेकिन आप सही कह रहे हैं, मुझे यकीन है कि यह बहुत बड़े निजी कोड में एक समस्या है।
n

1
@ n-0101 सहमत। खुला स्रोत ही समस्या को उजागर करता है। इस मामले में बंद मालिकाना पकड़े जाने का मामला नहीं है;)
एंड्रेस एफ।

तो आप कह रहे हैं कि स्रोत को बंद रखने का एक कारण आपको आकस्मिक कॉपीराइट उल्लंघन को छिपाने की अनुमति देना है? क्या आपको नहीं लगता कि यह उपयोग करने के लिए एक अनैतिक कारण है?
मार्क बूथ

1
अनैतिक .... शायद, स्रोत नहीं खोलने का एक बहुत अच्छा कारण, निश्चित रूप से।
पीटर बी

6

संभावित दायित्व मुद्दों से बचने के लिए आपको अपने लाइसेंस का चयन करने के तरीके से सावधान रहने की आवश्यकता है।

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


1
हां, यह एक अच्छा बिंदु है, और अधिकांश ओएस लाइसेंस में आमतौर पर कहीं न कहीं कुछ गधा-आवरण पाठ होता है। मुझे लगता है कि मैं एक "नो-लाइबिलिटी एक्सेप्टेड" टाइप लाइसेंस मान रहा था।
n

4

चेतावनी: आई एम नॉट ए लॉयर

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

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

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

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

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

जट मेरे 2 सेंट विषय पर।

(मैंने विश्वविद्यालयों के साथ बहुत काम किया है, और हाल ही में जैव सूचना विज्ञान और स्वास्थ्य सेवा में ... यह मेरे और मेरे सहयोगियों के लिए एक आवर्तक प्रश्न है :))


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

प्रश्न को स्पष्ट किया। परेशानी के लिए क्षमा कीजिए।
naught101

मैं आपके क्षेत्र को लाभदायक मानता हूँ। इसका व्यापक बाजार नहीं हो सकता है, लेकिन इसका मतलब यह नहीं है कि यह लाभदायक नहीं है। Fqct में, मैं इस पर विचार करूंगा कि इसमें काफी बड़ी धनराशि शामिल होगी। आप अन्यथा क्यों महसूस करते हैं?
जाइलम ha

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

1
@psr: मुझे लगता है कि यह शून्य की बात है: मॉडल के उपयोग के परिणामों के लिए लाभदायक परिणाम हैं, लेकिन जरूरी नहीं कि मॉडल को लागू करने वाले सॉफ़्टवेयर को बेचने में बहुत अधिक धन हो। मुझे भी आश्चर्यचकित करता है, लेकिन बहुत अच्छी तरह से हो सकता है।
१२:२२ बजे १२:२२

1

खुले स्रोत के कम से कम दो अलग-अलग प्रकार हैं।

यदि आपका दृष्टिकोण "यहाँ कुछ उपयोगी है, तो मैं इसके साथ काम कर रहा हूं" (और यह सटीक हो जाता है) तो थोड़ा नकारात्मक है।

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


3
मैं वास्तव में यह नहीं देखता कि समर्थन जारी करने वाला कोड किसी को समर्थन प्रदान करने के लिए कैसे बाध्य करता है? और विज्ञान में, कम से कम, अधिकांश उपयोगकर्ता बहुत क्लिस्ड हैं, कम से कम प्रक्रिया के बारे में, यदि कोड ही नहीं।
n

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

1
अपदस्थ क्योंकि यह उत्तर वास्तव में कई अन्य लोगों की तुलना में कम लागू नहीं है। @JoonasPulakka: बेशक यह लोगों को मदद मांगने से नहीं रोकना चाहिए। लेकिन इससे उन्हें जवाब की उम्मीद करना बंद कर देना चाहिए। इसके अलावा, आप सार्वजनिक रूप से बाहर वास्तविक सॉफ्टवेयर मिल गया है, तो शायद आप उपयोगकर्ताओं को एक ही जिम्मेदारी है परवाह किए बिना कि क्या आपके के कोड सार्वजनिक है (EULA पर निर्भर करता है, शायद)। हो सकता है कि यदि आप कोड जारी करते हैं, तो आपको डेवलपर्स से अधिक प्रश्नों की अपेक्षा करनी होगी, लेकिन यह
सोचकर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.