The State of Open Science in Software Engineering Research: A Case Study of ICSE Artifacts
यह अध्ययन 2015-2024 के 100 ICSE रेप्लिकेशन पैकेज का मूल्यांकन करता है और प्रकट करता है कि व्यापक आर्टिफैक्ट साझाकरण के बावजूद, केवल 40% पूरी तरह से निष्पादन योग्य हैं और उनमें से मात्र 35% ही मूल निष्कर्षों को सफलतापूर्वक पुनरुत्पादित कर पाते हैं, जो उपलब्धता और व्यावहारिक उपयोगिता के बीच एक महत्वपूर्ण अंतर को उजागर करता है जिसके लिए बेहतर तैयारी, दस्तावेजीकरण और समीक्षा दिशानिर्देशों की आवश्यकता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप और आपके दोस्त मिलकर एक विशाल, जटिल लेगो (Lego) महल बनाने की कोशिश कर रहे हैं। आपका एक दोस्त, जिसे हम "द आर्किटेक्ट" (The Architect) कह सकते है, एक सुंदर महल बनाता है और उसकी फोटो ऑनलाइन पोस्ट करता है। वह कहता है, "यह रहा ब्लूप्रिंट! यदि कोई मेरे निर्देशों का पालन करे, तो वह बिल्कुल यही महल बना सकता है।"
यह लेख इस बारे में है कि जब अन्य लोग वास्तव में उन ब्लूप्रिंट्स का पालन करने की कोशिश करते हैं, तो क्या होता है।
बड़ी समस्या: "भूतिया" निर्देश (The "Ghost" Instructions)
इस अध्ययन के लेखकों (अल मुत्तकिन, साइकाट मोंडल और चंचल के. रॉय) ने बिल्डर्स की भूमिका निभाने का निर्णय लिया। उन्होंने पिछले 10 वर्षों के टॉप-टियर सॉफ्टवेयर इंजीनियरिंग सम्मेलनों से 100 अलग-अलग "ब्लूप्रिंट्स" (जिन्हें रेप्लिकेशन पैकेज कहा जाता है) को देखा।
वे देखना चाहते थे कि क्या ये ब्लूप्रिंट्स वास्तव में काम करते हैं। उन्होंने इन डिजिटल महलों को बनाने में लगभग 650 घंटे (यानी 16 पूरे कार्य सप्ताह!) बिताए।
यहाँ उन्हें क्या मिला, जिसे सरल उपमाओं (analogies) के साथ समझाया गया है:
1. "खुला दरवाजा" बनाम "बंद कमरा" (Executability/निष्पादन क्षमता)
- स्थिति: कई शोधकर्ता अपना कोड साझा करते हैं, यह सोचकर कि वे मददगार हो रहे हैं। यह आपके घर का सामने का दरवाजा खुला छोड़ने जैसा है।
- वास्तविकता: सिर्फ इसलिए कि दरवाजा खुला है, इसका मतलब यह नहीं है कि आप अंदर जा सकते हैं।
- परिणाम: 100 ब्लूप्रिंट्स में से, केवल 40 वास्तव में काम कर पाए (वे सॉफ्टवेयर को चला सके)।
- अच्छी खबर: उन 40 में से 32% बिना किसी परेशानी के तुरंत काम करने के लिए तैयार थे।
- बुरी खबर: बाकी 68% के लिए बिल्डरों को टूटे हुए पाइपों को ठीक करने, वायरिंग बदलने या लाइट जलाने के लिए निर्देशों के हिस्सों को फिर से लिखने में घंटों बिताने पड़े।
- सबसे खराब स्थिति: 100 में से 36 ब्लूप्रिंट पूरी तरह से खराब थे। वे एक बंद कमरे की तरह थे जिसमें कोई चाबी नहीं थी। आप अंदर भी नहीं जा सकते थे।
2. "गायब मैनुअल" की समस्या (Documentation/दस्तावेजीकरण)
इतने सारे ब्लूप्रिंट्स क्यों विफल हुए? अध्ययन से पता चला कि निर्देश अक्सर बहुत खराब थे।
- उपमा: कल्पना कीजिए कि एक रेसिपी कहती है, "थोड़ा आटा डालें और बेक करें।" लेकिन यह नहीं बताती कि कितना आटा, किस तरह का ओवन उपयोग करना है, या कितनी देर तक बेक करना है।
- निष्कर्ष:
- गायब सामग्री: कई ब्लूप्रिंट्स में आवश्यक टूल्स या "सामग्री" (सॉफ्टवेयर वर्शन्स) की सूची नहीं थी।
- गलत नक्शा: निर्देश अक्सर उन फाइलों की ओर इशारा करते थे जो मौजूद नहीं थीं या गलत फोल्डर में थीं।
- "यह मेरे कंप्यूटर पर चल रहा था" वाला सिंड्रोम: आर्किटेक्ट ने महल को एक विशिष्ट प्रकार की लेगो टेबल (एक विशिष्ट कंप्यूटर सेटअप) पर बनाया था, लेकिन उसने बिल्डरों को यह नहीं बताया कि उन्हें उसी सटीक टेबल की आवश्यकता होगी। जब बिल्डरों ने इसे अपनी रसोई की मेज पर बनाने की कोशिश की, तो यह ढह गया।
3. "नकली महल" की समस्या (Reproducibility/पुनरुत्पादकता)
भले ही बिल्डर सॉफ्टवेयर को चलाने में सफल रहे, लेकिन क्या इसने वास्तव में वही परिणाम दिया जो आर्किटेक्ट ने दावा किया था?
- उपमा: आपने निर्देशों का पालन किया, लाइटें जल गईं, और महल खड़ा है। लेकिन जब आप मीनार को देखते हैं, तो वह लाल के बजाय नीली है, या उसमें एक खिड़की गायब है।
- परिणाम: 40 ब्लूप्रिंट्स में से जो वास्तव में चल सके, उनमें से केवल 14 (35%) ने बिल्कुल वही परिणाम दिए जिसका मूल पेपर ने दावा किया था।
- बाकी ने अलग नंबर, अलग ग्राफ, या कोई परिणाम नहीं दिया।
- इसका मतलब है कि भले ही कोड चल रहा हो, हम हमेशा मूल पेपर द्वारा किए गए वैज्ञानिक दावों पर भरोसा नहीं कर सकते।
बेहतर ब्लूप्रिंट्स के लिए तीन स्वर्णिम नियम
लेखकों ने केवल शिकायत नहीं की; उन्होंने इस गड़बड़ी को ठीक करने के लिए तीन सरल नियम दिए, जिन्हें वे "एक्शन योग्य दिशानिर्देश" (Actionable Guidelines) कहते हैं:
एक असली मैनुअल लिखें (व्यापक दस्तावेजीकरण):
सिर्फ इंटरनेट पर फाइलों का फोल्डर न फेंकें। एक स्पष्ट मार्गदर्शिका लिखें जो कहे: "आपको क्या चाहिए (OS, हार्डवेयर), इसे कैसे इंस्टॉल करें, और इसे ठीक से कैसे चलाएं।"- उपमा: एक ऐसी रेसिपी जो सटीक माप, विशिष्ट ओवन तापमान और तैयार व्यंजन कैसा दिखना चाहिए, उसकी फोटो के साथ हो।
एक साफ किचन में टेस्ट करें (Configuration Leakage से बचें):
यह न मान लें कि सबके पास आपका विशिष्ट सेटअप है। अपने कोड को एक बिल्कुल नए, खाली वातावरण में टेस्ट करें ताकि यह सुनिश्चित हो सके कि यह उन छिपी हुई फाइलों या सेटिंग्स पर निर्भर नहीं है जो केवल आपके पास हैं।- उपमा: यदि आप किसी को बेकिंग सिखा रहे हैं, तो अपनी रसोई के किसी गुप्त मसाले का उपयोग न करें। सुनिश्चित करें कि रेसिपी उन सामग्रियों के साथ काम करती है जिन्हें कोई भी दुकान से खरीद सकता है।
उन्हें एक प्री-बिल्ट किट और कच्चा माल दोनों दें (Containers + Code):
दो चीजें प्रदान करें:- कच्चा कोड (Raw Code): ताकि विशेषज्ञ देख सकें कि यह कैसे काम करता है और इसमें बदलाव कर सकें।
- "कंटेनर" (Container): एक पहले से पैक किया गया डिजिटल बॉक्स (जैसे Docker कंटेनर) जिसमें सब कुछ पहले से इंस्टॉल हो ताकि कोई भी बस "रन" पर क्लिक कर सके।
- उपमा: बिल्डर को ढीले लेगो ब्रिक्स (ताकि वे सीख सकें) और एक पहले से असेंबल किया गया मॉडल (ताकि वे तुरंत अंतिम परिणाम देख सकें) दोनों दें।
निचोड़
पेपर निष्कर्ष निकालता है कि हालांकि सॉफ्टवेयर इंजीनियरिंग समुदाय अपने काम को साझा करने (दरवाजा खोलने) में बेहतर हो रहा है, लेकिन वे इस बात में अभी भी खराब हैं कि उस काम को उपयोगी (कमरे को अनलॉक करना) कैसे बनाया जाए।
यदि शोधकर्ता वास्तव में "ओपन" होना चाहते हैं, तो उन्हें अपने कोड को एक गुप्त रेसिपी की तरह नहीं, बल्कि एक सार्वजनिक उत्पाद की तरह मानना होगा जिसे कोई भी ट्रबलशूटिंग में पीएचडी की आवश्यकता के बिना उपयोग कर सके।
संक्षेप में: कोड साझा करना अच्छा है, लेकिन काम करने वाला, अच्छी तरह से प्रलेखित (well-documented) कोड साझा करना ही वास्तव में विज्ञान को आगे बढ़ाता है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।