कृपया मत पूछिए कि कोई ओपन सोर्स प्रोजेक्ट मृत है या नहीं
ओपन-सोर्स maintainers और users के बीच तनाव तब सामने आता है जब लोग पूछते हैं कि कोई प्रोजेक्ट “dead” है या नहीं, खासकर उन repos में जो शांत दिखते हैं या जिनमें unresolved issues हैं। टिप्पणीकारों का तर्क है कि उपयोगकर्ताओं को यह जानने का उचित अधिकार है कि सॉफ़्टवेयर पर निर्भर होने से पहले वह maintained है या नहीं, जबकि maintainers कहते हैं कि वे ongoing support के लिए बाध्य नहीं हैं और ऐसे सवालों से दबाव या हतोत्साह महसूस कर सकते हैं। कई लोग README में स्पष्ट status संकेत, बेहतर GitHub tooling (archiving, badges, succession paths), और अधिक considerate phrasing का सुझाव देते हैं ताकि दोनों पक्षों की अपेक्षाएँ बेहतर ढंग से मेल खाएँ।
क्या “क्या यह प्रोजेक्ट मृत है?” पूछना असभ्य है
- कई लोगों का तर्क है कि यह पूरी तरह उचित, बल्कि ज़रूरी सवाल है: उपयोगकर्ताओं को पता होना चाहिए कि किसी लाइब्रेरी पर निर्भर रहना सुरक्षित है या नहीं, खासकर सुरक्षा सुधारों और upstream के breaking changes के लिए।
- अन्य लोग कहते हैं कि “dead/abandoned” जैसी शब्दावली भावनात्मक रूप से बोझिल है और आरोप लगाने जैसी लगती है; वे “current maintenance status” या “actively maintained?” जैसी तटस्थ भाषा सुझाते हैं।
- कई टिप्पणीकारों का मानना है कि लेख में दिया गया विशेष उदाहरण इश्यू विनम्र था, और उसे “pressure” या “rude” कहना तनाव और burnout से उपजी एक अति-प्रतिक्रिया थी।
रखरखाव, इकोसिस्टम, और “पूरी” हो चुकी सॉफ़्टवेयर
- कुछ लोग कहते हैं कि सॉफ़्टवेयर “done” हो सकता है और उसे बार-बार commits की ज़रूरत नहीं होती; गतिविधि का अभाव अपने-आप में समस्या नहीं है।
- दूसरे लोग जवाब देते हैं कि Node/npm या तेज़ी से बदलते APIs जैसे इकोसिस्टम में bit-rot और dependency security issues के कारण निरंतर रखरखाव आवश्यक है।
- “code rot” पर बहस: कुछ लोग मूल code की बजाय बदलते platforms और कमजोर backwards compatibility को दोष देते हैं।
Forking और प्रोजेक्ट उत्तराधिकार
- कई लोग मानते हैं कि जब कोई maintainer प्रतिक्रिया नहीं देता या PRs में रुचि नहीं रखता, तो fork करना मानक समाधान है।
- बताई गई कमियाँ: कई आधे-रखे forks, अस्पष्ट “successor,” सामाजिक विखंडन, और अगर मूल प्रोजेक्ट बाद में फिर जीवित हो जाए तो rebases की पीड़ा।
- दूसरे लोग बताते हैं कि महत्वपूर्ण प्रोजेक्ट (Linux, BSDs, office suites, browser engines) forks से ही उभरे; अधिकांश forks का विफल होना सामान्य माना जाता है।
अपेक्षाएँ, संचार, और GitHub सुविधाएँ
- बार-बार दी गई सलाह: README/CONTRIBUTING में स्थिति और अपेक्षाएँ स्पष्ट लिखें (जैसे, “finished,” “security-fixes only,” PR policy, forks के प्रति रुख)।
- GitHub का archive flag inactivity दिखाने का उपयोगी, लेकिन कम इस्तेमाल किया गया तरीका माना जाता है; कुछ लोग सक्रिय forks को हाइलाइट करने के लिए अधिक समृद्ध status/badge तंत्र और UI चाहते हैं।
- कई लोग कहते हैं कि अगर आप बातचीत नहीं चाहते, तो issues/PRs बंद कर देना उचित है।
जिम्मेदारियाँ और मानसिक स्वास्थ्य
- व्यापक सहमति: maintainers पर उपयोगकर्ताओं के प्रति कोई अनुबंधात्मक दायित्व नहीं है; users और contributors पर भी maintainers के प्रति कोई दायित्व नहीं है।
- फिर भी, कई लोग बुनियादी शिष्टाचार, आभार, और मदद या sponsorship की पेशकश पर ज़ोर देते हैं।
- कुछ लोग लेख को burnout का संकेत मानते हैं और सलाह देते हैं कि ऐसे निर्देशात्मक, भावनात्मक रूप से बोझिल “मत पूछिए” नियम प्रकाशित करने के बजाय थोड़ा पीछे हट जाना बेहतर होगा।