जब 'ओपन कोर' प्रोजेक्ट प्रतिस्पर्धी EE के कारण योगदान अस्वीकार करते हैं
एक ओपन-कोर API क्लाइंट प्रोजेक्ट ने विवाद खड़ा कर दिया जब मेंटेनरों ने SSO/SAML सपोर्ट जोड़ने वाले एक सामुदायिक pull request को अस्वीकार कर दिया और उस क्षमता को अपनी पेड एंटरप्राइज़ एडिशन के लिए ही रखा। टिप्पणीकार इस पर बहस करते हैं कि क्या यह कंपनियों के लिए चल रहे विकास को फंड करने का उचित तरीका है, या फिर “ओपन सोर्स” को मुख्यतः मार्केटिंग के रूप में उपयोग करने का उदाहरण है, जबकि आवश्यक self-hosting और सुरक्षा फीचर्स रोके जा रहे हैं। यह बहस योगदानकर्ता अपेक्षाओं, मेंटेनर जिम्मेदारियों, “SSO टैक्स,” और असंतुष्ट उपयोगकर्ताओं के लिए fork करना कब एकमात्र वास्तविक विकल्प होता है, इन व्यापक तनावों को उजागर करती है।
प्रोजेक्ट संदर्भ और ट्रिगर करने वाली घटना
- चर्चा एक “ओपन कोर” प्रोजेक्ट के इर्द-गिर्द है, जिसने एक बड़े समुदाय PR को अस्वीकार कर दिया था, जिसमें SSO/SAML/OIDC सपोर्ट जोड़ा गया था और जो उसके Enterprise Edition (EE) से ओवरलैप करता था।
- PR कई महीनों तक बिना या बहुत कम मेंटेनर प्रतिक्रिया के पड़ा रहा, फिर उसे व्यावसायिक/“विज़न” तर्कों के साथ बंद कर दिया गया और थ्रेड लॉक कर दिया गया, जिसे कई लोगों ने अपमानजनक माना।
ओपन कोर मॉडल बनाम वास्तविक ओपन सोर्स
- कुछ लोग तर्क देते हैं कि यह दिखाता है कि “ओपन कोर” अक्सर जानबूझकर एक खराब मुफ्त संस्करण जारी करने का मतलब होता है, ताकि मुद्रीकरण सुरक्षित रहे।
- अन्य लोग जवाब देते हैं कि पेड फीचर्स के बिना शायद प्रोजेक्ट का अस्तित्व ही न हो; EE गेटिंग को स्थिरता के लिए आवश्यक माना जाता है।
- कई टिप्पणीकार इस बात पर ज़ोर देते हैं कि प्रोजेक्ट MIT-लाइसेंस्ड है, इसलिए यह अपने बिज़नेस मॉडल से परे, कानूनी रूप से वास्तव में ओपन सोर्स है।
SSO/“SSO टैक्स” और सुरक्षा
- कई लोग SSO को पेवॉल के पीछे रखने की आलोचना करते हैं, इसे “SSO टैक्स” कहते हैं और तर्क देते हैं कि सुरक्षा फीचर्स का मुद्रीकरण नहीं होना चाहिए।
- प्रतिवाद: SSO को एंटरप्राइज़ आवश्यकता के रूप में देखा जाता है, न कि व्यक्तियों के लिए एक मूल सुरक्षा आवश्यकता के रूप में, इसलिए यह एक स्वाभाविक मूल्य विभेदक है।
- कुछ self-hosters तर्क देते हैं कि छोटे सेटअप्स के लिए भी SSO आवश्यक है, ताकि मजबूत 2FA/WebAuthn और केंद्रीकृत खाता प्रबंधन मिल सके।
योगदान, हकदारी, और मेंटेनर की ज़िम्मेदारियाँ
- एक पक्ष योगदानकर्ता के प्रयास को उदार मानता है और लंबे समय की चुप्पी के बाद आए अस्वीकृति को हतोत्साहित करने वाला और खराब तरीके से संप्रेषित कदम मानता है।
- दूसरा पक्ष इस बात पर ज़ोर देता है कि मेंटेनर योगदानकर्ताओं के प्रति कुछ भी देय नहीं रखते: PRs दायित्व हैं, अधिकार नहीं, और बड़े बदलावों पर पहले चर्चा होनी चाहिए।
- “हकदारी” पर बहस: क्या बुनियादी संचार और गैर-शत्रुतापूर्ण प्रतिक्रिया की अपेक्षा उचित है, या यह पहले ही मुफ़्त मेंटेनरों से बहुत अधिक माँग है?
Forking और व्यावहारिक सीमाएँ
- कई लोग नोट करते हैं कि forking ही अपेक्षित सुरक्षा-वाल्व है: कोड MIT है, कोई भी अस्वीकृत फीचर्स को लागू और मेंटेन कर सकता है।
- अन्य लोग वास्तविक लागत पर प्रकाश डालते हैं: लगातार rebasing, conflict resolution, अलग releases, और diverging code में bugs को संभालना।
ओपन कोर के बारे में व्यापक निष्कर्ष
- ओपन कोर को स्वभावतः तनावपूर्ण माना जाता है: समुदाय “सबसे अच्छा संभव” OSS चाहता है; कंपनियों को जानबूझकर कुछ मूल्य रोकना पड़ता है।
- कुछ लोग निष्कर्ष निकालते हैं कि वे ओपन कोर / कंपनी-समर्थित “self-hostable” उत्पादों से बचेंगे, या कम से कम उनके प्रति संदेह रखेंगे।