AI कोड लिखने और संभावित बग खोजने की रफ्तार बढ़ा सकता है, लेकिन रिपोर्ट या योगदान सही है या नहीं, यह जाँचने का काम अब भी मेंटेनरों को करना पड़ता है। Linux Foundation के सर्वे में 25% पुल रिक्वेस्ट कम गुणवत्ता वाली मानी गईं; बड़े प्रोजेक्ट्स में यह हिस्सा 31% था।
प्रकाशितकर्ताGPT-6 Luna से संपादितGPT Image 2 से चित्र बनाए गए
शोध उत्तर

Create a landscape editorial hero image for this Studio Global article: How is AI accelerating open-source development while overwhelming maintainers with low-quality contributions and vulnerability reports, as i. Article summary: AI is making code and potential bug reports faster to produce, but that does not make them faster to validate: the bottleneck is shifting toward maintainers’ review and security judgment. OpenSSL’s report surge and the L. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fa
AI की मदद से कोड लिखना और संभावित बग पहचानना आसान हुआ है। लेकिन हर नए योगदान और सुरक्षा रिपोर्ट की जाँच भी ज़रूरी है—और यही काम अब कई ओपन-सोर्स प्रोजेक्ट्स के लिए अड़चन बन रहा है। OpenSSL में रिपोर्टों की बढ़ती संख्या और Linux Foundation के एक सर्वे के नतीजे इस दोहरी तस्वीर को सामने रखते हैं: विकास तेज़ हो सकता है, लेकिन जाँच का बोझ भी बढ़ता है। 1
21
OpenSSL ऐसा सॉफ़्टवेयर उपलब्ध कराता है जिसका इस्तेमाल इंटरनेट संचार को सुरक्षित रखने में होता है। इसलिए इसकी सुरक्षा और कोड की गुणवत्ता का असर सिर्फ़ इस प्रोजेक्ट तक सीमित नहीं रहता। 1
5
प्राग में हुई परियोजना की सालाना कॉन्फ़्रेंस में OpenSSL के कार्यकारी निदेशक मैट कैसवेल ने बताया कि मई से जुलाई 2026 के दौरान हर महीने औसतन 71 सुरक्षा रिपोर्टें और पूछताछ मिलीं। पिछले साल इसी अवधि में यह औसत नौ था। अगस्त में पूछताछ की संख्या 108 तक पहुँच गई। 1
ये आँकड़े मिली हुई रिपोर्टों और पूछताछ के हैं—पुष्ट कमजोरियों के नहीं। पिछले एक साल में OpenSSL को लगभग 500 संभावित कमजोरियों की रिपोर्ट मिलीं, लेकिन उनमें से 63 के आधार पर ही कमजोरियाँ सार्वजनिक की गईं। कई रिपोर्टें दोहराई गई थीं, मामूली खामियों से जुड़ी थीं या ऐसी समस्याओं के बारे में थीं जिन पर सुरक्षा सलाह जारी करना ज़रूरी नहीं था। फिर भी, हर रिपोर्ट को परखने में इंसानी समय लगता है। AI टूल से मिली ज़्यादातर खामियाँ भी गंभीर नहीं, बल्कि कम जोखिम वाली थीं। 1
3
यह दबाव सिर्फ़ OpenSSL तक सीमित नहीं है। कॉन्फ़्रेंस में Bouncy Castle और cryptlib के मेंटेनरों ने भी बताया कि उन्हें पहले से ज़्यादा रिपोर्टें जाँचनी पड़ रही हैं। Bouncy Castle की मेगन वुड्स ने AI से लिखे क्रिप्टोग्राफ़ी कोड के जोखिमों पर भी आगाह किया। 2
3
OpenSSL के मुख्य प्रौद्योगिकी अधिकारी के मुताबिक, AI टूल कोड की समीक्षा, रिपोर्ट की गई कमजोरियों की जाँच और सॉफ़्टवेयर के लिए टेस्ट लिखने जैसे कामों में मदद कर सकते हैं। 3 इससे मेंटेनरों का काम आसान हो सकता है, लेकिन किसी संभावित समस्या की पुष्टि अपने-आप नहीं हो जाती और मानवीय जाँच की ज़रूरत भी खत्म नहीं होती।
1
3
कमज़ोरी का पता लगाना और यह साबित करना कि वह असल में जोखिम पैदा करती है—दो अलग काम हैं। कोई टूल संदिग्ध कोड दिखा सकता है या विश्वसनीय लगने वाली रिपोर्ट बना सकता है; लेकिन मेंटेनरों को तय करना होता है कि समस्या वास्तविक और प्रासंगिक है या नहीं, और उस पर क्या कार्रवाई करनी चाहिए। रिपोर्टिंग के मुताबिक, जाँच, पैच तैयार करने और सुरक्षा सलाह प्रकाशित करने में छह से आठ हफ़्ते लग सकते हैं। 3
Red Hat द्वारा प्रायोजित Linux Foundation Research के सर्वे में पाया गया कि मेंटेनरों ने आने वाली पुल रिक्वेस्ट—यानी प्रोजेक्ट में कोड बदलाव शामिल करने के प्रस्ताव—में से 25% को कम गुणवत्ता वाला “AI slop” माना। बड़े प्रोजेक्ट्स में यह अनुमान 31% था। सर्वे में ओपन-सोर्स के 234 योगदानकर्ताओं और मेंटेनरों ने हिस्सा लिया। 20
21
दूसरी ओर, 59% प्रोजेक्ट मेंटेनरों ने बताया कि योगदानों की संख्या बढ़ी है। 21 अधिक योगदान से उपयोगी काम और नए योगदानकर्ता मिल सकते हैं, लेकिन हर प्रस्ताव की समीक्षा का भार भी बढ़ता है—खासकर तब, जब उसमें ऐसी समस्याएँ हों जिन्हें मेंटेनरों को पहचानकर समझाना पड़े।
ये सर्वे के अनुमान हैं, सभी ओपन-सोर्स प्रोजेक्ट्स की हर पुल रिक्वेस्ट की गिनती नहीं। फिर भी, वे एक व्यावहारिक चुनौती दिखाते हैं: AI योगदान तैयार करने की मेहनत घटा सकता है, लेकिन यह तय करने की मेहनत नहीं कि वह योगदान शामिल करने लायक है या नहीं। 20
21
Google के एक कदम से पता चलता है कि रिपोर्टों की बढ़ती संख्या सुरक्षा कार्यक्रमों को कैसे प्रभावित कर सकती है। 1 अक्टूबर को कंपनी ने अपने Open Source Software Vulnerability Reward Program में उत्पाद-संबंधी कमजोरियों की नई रिपोर्टें लेना रोक दिया। Google ने इसकी वजह स्वचालित रिपोर्टों में बढ़ोतरी बताई और कहा कि उनमें से बहुत बड़ी संख्या अमान्य थी। कंपनी ने 2027 की पहली तिमाही में अपडेट देने की बात कही। यह रोक उसी कार्यक्रम में उत्पाद-संबंधी रिपोर्टों पर लागू थी—Google के सभी बग-बाउंटी कार्यक्रमों पर नहीं। 18
उपलब्ध जानकारी से एक व्यावहारिक दिशा निकलती है: योगदान के नियम स्पष्ट हों, जहाँ ज़रूरी हो वहाँ समस्या को दोबारा दिखाने योग्य प्रमाण और टेस्ट माँगे जाएँ, और ऑटोमेशन का इस्तेमाल शुरुआती छँटाई में हो—मानवीय समीक्षा को हटाने के लिए नहीं। ये रिपोर्टों से निकले व्यावहारिक संकेत हैं, कोई एक तय समाधान नहीं। 1
18
21
AI कोड लिखने और संभावित खामियाँ खोजने की रफ्तार बढ़ा सकता है। लेकिन भरोसेमंद सॉफ़्टवेयर के लिए मेंटेनरों को यह जाँचने का समय और समर्थन भी चाहिए कि उनके पास क्या आ रहा है।
Studio Global AI
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
AI कोड लिखने और संभावित बग खोजने की रफ्तार बढ़ा सकता है, लेकिन रिपोर्ट या योगदान सही है या नहीं, यह जाँचने का काम अब भी मेंटेनरों को करना पड़ता है।
AI कोड लिखने और संभावित बग खोजने की रफ्तार बढ़ा सकता है, लेकिन रिपोर्ट या योगदान सही है या नहीं, यह जाँचने का काम अब भी मेंटेनरों को करना पड़ता है। Linux Foundation के सर्वे में 25% पुल रिक्वेस्ट कम गुणवत्ता वाली मानी गईं; बड़े प्रोजेक्ट्स में यह हिस्सा 31% था।
AI कोड लिखने और संभावित बग खोजने की रफ्तार बढ़ा सकता है, लेकिन रिपोर्ट या योगदान सही है या नहीं, यह जाँचने का काम अब भी मेंटेनरों को करना पड़ता है। Linux Foundation के सर्वे में 25% पुल रिक्वेस्ट कम गुणवत्ता वाली मानी गईं; बड़े प्रोजेक्ट्स में यह हिस्सा 31% था।
प्रकाशितकर्ताGPT-6 Luna से संपादितGPT Image 2 से चित्र बनाए गए
शोध उत्तर

Create a landscape editorial hero image for this Studio Global article: How is AI accelerating open-source development while overwhelming maintainers with low-quality contributions and vulnerability reports, as i. Article summary: AI is making code and potential bug reports faster to produce, but that does not make them faster to validate: the bottleneck is shifting toward maintainers’ review and security judgment. OpenSSL’s report surge and the L. Topic tags: general, general web, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fa
AI की मदद से कोड लिखना और संभावित बग पहचानना आसान हुआ है। लेकिन हर नए योगदान और सुरक्षा रिपोर्ट की जाँच भी ज़रूरी है—और यही काम अब कई ओपन-सोर्स प्रोजेक्ट्स के लिए अड़चन बन रहा है। OpenSSL में रिपोर्टों की बढ़ती संख्या और Linux Foundation के एक सर्वे के नतीजे इस दोहरी तस्वीर को सामने रखते हैं: विकास तेज़ हो सकता है, लेकिन जाँच का बोझ भी बढ़ता है। 1
21
OpenSSL ऐसा सॉफ़्टवेयर उपलब्ध कराता है जिसका इस्तेमाल इंटरनेट संचार को सुरक्षित रखने में होता है। इसलिए इसकी सुरक्षा और कोड की गुणवत्ता का असर सिर्फ़ इस प्रोजेक्ट तक सीमित नहीं रहता। 1
5
प्राग में हुई परियोजना की सालाना कॉन्फ़्रेंस में OpenSSL के कार्यकारी निदेशक मैट कैसवेल ने बताया कि मई से जुलाई 2026 के दौरान हर महीने औसतन 71 सुरक्षा रिपोर्टें और पूछताछ मिलीं। पिछले साल इसी अवधि में यह औसत नौ था। अगस्त में पूछताछ की संख्या 108 तक पहुँच गई। 1
ये आँकड़े मिली हुई रिपोर्टों और पूछताछ के हैं—पुष्ट कमजोरियों के नहीं। पिछले एक साल में OpenSSL को लगभग 500 संभावित कमजोरियों की रिपोर्ट मिलीं, लेकिन उनमें से 63 के आधार पर ही कमजोरियाँ सार्वजनिक की गईं। कई रिपोर्टें दोहराई गई थीं, मामूली खामियों से जुड़ी थीं या ऐसी समस्याओं के बारे में थीं जिन पर सुरक्षा सलाह जारी करना ज़रूरी नहीं था। फिर भी, हर रिपोर्ट को परखने में इंसानी समय लगता है। AI टूल से मिली ज़्यादातर खामियाँ भी गंभीर नहीं, बल्कि कम जोखिम वाली थीं। 1
3
यह दबाव सिर्फ़ OpenSSL तक सीमित नहीं है। कॉन्फ़्रेंस में Bouncy Castle और cryptlib के मेंटेनरों ने भी बताया कि उन्हें पहले से ज़्यादा रिपोर्टें जाँचनी पड़ रही हैं। Bouncy Castle की मेगन वुड्स ने AI से लिखे क्रिप्टोग्राफ़ी कोड के जोखिमों पर भी आगाह किया। 2
3
OpenSSL के मुख्य प्रौद्योगिकी अधिकारी के मुताबिक, AI टूल कोड की समीक्षा, रिपोर्ट की गई कमजोरियों की जाँच और सॉफ़्टवेयर के लिए टेस्ट लिखने जैसे कामों में मदद कर सकते हैं। 3 इससे मेंटेनरों का काम आसान हो सकता है, लेकिन किसी संभावित समस्या की पुष्टि अपने-आप नहीं हो जाती और मानवीय जाँच की ज़रूरत भी खत्म नहीं होती।
1
3
कमज़ोरी का पता लगाना और यह साबित करना कि वह असल में जोखिम पैदा करती है—दो अलग काम हैं। कोई टूल संदिग्ध कोड दिखा सकता है या विश्वसनीय लगने वाली रिपोर्ट बना सकता है; लेकिन मेंटेनरों को तय करना होता है कि समस्या वास्तविक और प्रासंगिक है या नहीं, और उस पर क्या कार्रवाई करनी चाहिए। रिपोर्टिंग के मुताबिक, जाँच, पैच तैयार करने और सुरक्षा सलाह प्रकाशित करने में छह से आठ हफ़्ते लग सकते हैं। 3
Red Hat द्वारा प्रायोजित Linux Foundation Research के सर्वे में पाया गया कि मेंटेनरों ने आने वाली पुल रिक्वेस्ट—यानी प्रोजेक्ट में कोड बदलाव शामिल करने के प्रस्ताव—में से 25% को कम गुणवत्ता वाला “AI slop” माना। बड़े प्रोजेक्ट्स में यह अनुमान 31% था। सर्वे में ओपन-सोर्स के 234 योगदानकर्ताओं और मेंटेनरों ने हिस्सा लिया। 20
21
दूसरी ओर, 59% प्रोजेक्ट मेंटेनरों ने बताया कि योगदानों की संख्या बढ़ी है। 21 अधिक योगदान से उपयोगी काम और नए योगदानकर्ता मिल सकते हैं, लेकिन हर प्रस्ताव की समीक्षा का भार भी बढ़ता है—खासकर तब, जब उसमें ऐसी समस्याएँ हों जिन्हें मेंटेनरों को पहचानकर समझाना पड़े।
ये सर्वे के अनुमान हैं, सभी ओपन-सोर्स प्रोजेक्ट्स की हर पुल रिक्वेस्ट की गिनती नहीं। फिर भी, वे एक व्यावहारिक चुनौती दिखाते हैं: AI योगदान तैयार करने की मेहनत घटा सकता है, लेकिन यह तय करने की मेहनत नहीं कि वह योगदान शामिल करने लायक है या नहीं। 20
21
Google के एक कदम से पता चलता है कि रिपोर्टों की बढ़ती संख्या सुरक्षा कार्यक्रमों को कैसे प्रभावित कर सकती है। 1 अक्टूबर को कंपनी ने अपने Open Source Software Vulnerability Reward Program में उत्पाद-संबंधी कमजोरियों की नई रिपोर्टें लेना रोक दिया। Google ने इसकी वजह स्वचालित रिपोर्टों में बढ़ोतरी बताई और कहा कि उनमें से बहुत बड़ी संख्या अमान्य थी। कंपनी ने 2027 की पहली तिमाही में अपडेट देने की बात कही। यह रोक उसी कार्यक्रम में उत्पाद-संबंधी रिपोर्टों पर लागू थी—Google के सभी बग-बाउंटी कार्यक्रमों पर नहीं। 18
उपलब्ध जानकारी से एक व्यावहारिक दिशा निकलती है: योगदान के नियम स्पष्ट हों, जहाँ ज़रूरी हो वहाँ समस्या को दोबारा दिखाने योग्य प्रमाण और टेस्ट माँगे जाएँ, और ऑटोमेशन का इस्तेमाल शुरुआती छँटाई में हो—मानवीय समीक्षा को हटाने के लिए नहीं। ये रिपोर्टों से निकले व्यावहारिक संकेत हैं, कोई एक तय समाधान नहीं। 1
18
21
AI कोड लिखने और संभावित खामियाँ खोजने की रफ्तार बढ़ा सकता है। लेकिन भरोसेमंद सॉफ़्टवेयर के लिए मेंटेनरों को यह जाँचने का समय और समर्थन भी चाहिए कि उनके पास क्या आ रहा है।
Studio Global AI
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
AI कोड लिखने और संभावित बग खोजने की रफ्तार बढ़ा सकता है, लेकिन रिपोर्ट या योगदान सही है या नहीं, यह जाँचने का काम अब भी मेंटेनरों को करना पड़ता है।
AI कोड लिखने और संभावित बग खोजने की रफ्तार बढ़ा सकता है, लेकिन रिपोर्ट या योगदान सही है या नहीं, यह जाँचने का काम अब भी मेंटेनरों को करना पड़ता है। Linux Foundation के सर्वे में 25% पुल रिक्वेस्ट कम गुणवत्ता वाली मानी गईं; बड़े प्रोजेक्ट्स में यह हिस्सा 31% था।