On credit attribution and research software: A case study from lattice QCD

एक ऐसी दुनिया की कल्पना करें जहाँ सबसे महत्वपूर्ण खोजें दूरबीनों या पार्टिकल कोलाइडर से नहीं, बल्कि कंप्यूटर कोड की पंक्तियों से की जाती हैं। यह लैटिस क्वांटम क्रोमोडायनेमिक्स (Lattice QCD) का क्षेत्र है, जो भौतिकी की एक ऐसी शाखा है जो ब्रह्मांड के सबसे छोटे निर्माण खंडों को आपस में जोड़े रखने वाले नन्हे, चिपचिपे 'ग्लू' (glue) को समझने की कोशिश करती है। क्योंकि गणित इतना कठिन है कि इसे पेंसिल से हल नहीं किया जा सकता, इसलिए वैज्ञानिक विशाल डिजिटल सिमुलेशन बनाते हैं। इस दुनिया में, सॉफ्टवेयर केवल एक कैलकुलेटर नहीं है; यह पूरा प्रयोगशाला है। यदि कोड टूट जाता है, तो प्रयोग रुक जाता है।

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

---

अदृश्य निर्माताओं की कहानी

यह शोध पत्र लैटिस QCD की दुनिया से एक सच्ची कहानी बताता है, जो जर्मनी के एक विश्वविद्यालय में हुए एक विशिष्ट संघर्ष पर केंद्रित है। यह एक प्रतिभाशाली युवा शोधकर्ता, अलेसांद्रो (Alessandro) की कहानी है, जिसने वर्षों तक एक विशाल, जटिल सॉफ्टवेयर सिस्टम बनाया जिस पर उसकी पूरी टीम निर्भर थी। अलेसांद्रो को एक गगनचुंबी इमारत के मास्टर आर्किटेक्ट के रूप में समझें जिसने पूरे आधार (foundation), प्लंबिंग और इलेक्ट्रिकल ग्रिड को डिजाइन और निर्मित किया है।

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

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

रेफरी का निर्णय और "स्व-संरक्षण" प्रणाली

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

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

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

लेखक एक व्यक्तिगत परिणाम भी उजागर करता है: सहयोग के फंडिंग आवेदन में उसे तीसरे फंडिंग काल में शामिल करने की पूर्व प्रतिबद्धता के बावजूद, उसे तीसरे काल के शुरू होने से कुछ ही सप्ताह पहले एकतरफा रूप से बाहर कर दिया गया, जबकि वह पितृत्व अवकाश (parental leave) पर था।

वह सुझाव देता है कि प्रणाली "स्व-संरक्षक" (self-protecting) हो सकती है। कल्पना कीजिए कि एक स्कूल में प्रिंसिपल कहता है, "यदि आप किसी शिक्षक के बारे में शिकायत करते हैं, तो हम सुनेंगे, लेकिन आप किसी को नहीं बता सकते कि हमने क्या कहा, और हम आपको यह नहीं बताएंगे कि हमने जो निर्णय लिया वह क्यों लिया।" यदि किसी छात्र को लगता है कि उसके साथ अन्याय हुआ है, तो उसके पास निर्णय को साबित करने या अपील करने का कोई तरीका नहीं है। लेखक को डर है कि इस तरह की गोपनीयता वैज्ञानिकों को तब बोलने से रोकती है जब उन्हें लगता है कि उनके कठिन परिश्रम को चुराया जा रहा है।

"उपकरण" बनाम "आर्किटेक्ट"

यह शोध पत्र एक मजेदार विचार प्रयोग (thought experiment) का उपयोग करके समझाता है कि यह एक बड़ी बात क्यों है। कल्पना कीजिए कि एक शोधकर्ता 20 साल तक अपने क्षेत्र की हर समस्या को हल करने वाला "अल्टीमेट सॉफ्टवेयर" लिखने में बिताता है। हर कोई इसका उपयोग करता है। इसे हजारों बार उद्धृत (cite) किया जाता है। लेकिन क्योंकि उसने अपना सारा समय कोडिंग में बिताया और पेपर नहीं लिखे, इसलिए उसे कभी भी उन प्रसिद्ध अध्ययनों का लेखक नहीं माना जाता जिनमें उसके सॉफ्टवेयर का उपयोग किया गया है।

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

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

यह शोध पत्र वास्तव में क्या कहता है (और क्या नहीं कहता)

यह शोध पत्र यह दावा नहीं करता कि टीम के नेताओं ने कोई कानून तोड़ा है। यह स्वीकार करता है कि कानूनी रूप से, विश्वविद्यालय कोड का स्वामी है, और नेताओं को प्रकाशित करने की अनुमति थी। शोध पत्र यह नहीं कहता कि सॉफ्टवेयर त्रुटिहीन था या नए वैज्ञानिक परिणाम गलत थे।

इसके बजाय, शोध पत्र सुझाव देता है कि हम श्रेय कैसे देते हैं, यह पुराना हो चुका है। इसका तर्क है कि वर्तमान नियम, जो तब बनाए गए थे जब कंप्यूटर केवल साधारण सहायक थे, आज की दुनिया में फिट नहीं बैठते जहाँ सॉफ्टवेयर ही मुख्य घटना है। लेखक को संदेह है कि जर्मनी में विवाद समाधान प्रणाली संस्था की रक्षा करने पर अधिक केंद्रित है न कि व्यक्ति की मदद करने पर, यह देखते हुए कि समिति ने "उपकरण" बनाम "वैचारिक योगदान" के रूप में सॉफ्टवेयर की भूमिका के संबंध में विशिष्ट तर्कों पर विचार नहीं किया।

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

संक्षेप में, यह एक ऐसे निर्माता की कहानी है जिसने घर बनाया, लेकिन जो लोग उसमें रहने आए उन्हें अंदर की पार्टी का सारा श्रेय मिला। लेखक पूछ रहा है: "क्या यह समय है कि नियमों को बदला जाए ताकि निर्माता को भी मेज पर जगह मिले?"