Left-Pad घटना पर 8 साल बाद पुनरावलोकन (2024)
(azerkoculu.com)- left-pad घटना 8 साल बाद भी open source dependencies और package management अधिकारों से जुड़ा एक प्रतिनिधि उदाहरण बनी हुई है, और Azer Koçulu ने उस समय के अपने फैसले को फिर से समझाया
- unpublish करने का फैसला गुस्से या लालच से ज्यादा आत्मचिंतन से निकला चयन था, और मुख्य पृष्ठभूमि यह थी कि NPM ने अपने ही बनाए नियम तोड़े थे
- Kik Messenger के दबाव में NPM ने open source community से ऊपर दूसरे मूल्यों को प्राथमिकता दी, ऐसा उन्होंने माना, और इसी फैसले ने सभी packages हटाने की ओर ले गया
- हटाए जाने वाले 350 से ज्यादा packages थे, लेकिन usage statistics और GitHub activity भर से वास्तविक प्रभाव का दायरा समझना कठिन था
- NPM script चलाने के करीब 10 मिनट बाद ही React सहित कई projects टूट गए, और कुछ घंटों के भीतर module restore हो गया व स्थिति सामान्य हो गई
left-pad घटना के समय का फैसला
- left-pad घटना को 8 साल हो चुके हैं, और Azer Koçulu ने वास्तविक काम पर ध्यान देने के लिए अब तक इस विषय से बचना बेहतर समझा
- 2016 में, जब वे अधिकतर weekends signal न पहुंचने वाली दूर-दराज जगहों पर camping करते थे, उसी दौर में उन्होंने unpublish करने का फैसला लिया
- उन्होंने बताया कि यह logic, गुस्से या लालच से नहीं, बल्कि प्रकृति के बीच आत्मचिंतन और मन से निकला चुनाव था
- फैसले का सिद्धांत सरल था
- अगर NPM अपने ही नियम तोड़कर उनके किसी एक package को हटाता है, तो उसी मानक से उनके सभी packages भी हटाए जाने चाहिए
- उन्होंने नियमों से ज्यादा नियमों के पीछे की भावना को महत्वपूर्ण माना
- वे मानते हैं कि किसी दूसरे context में अच्छे कारणों से owner की अनुमति के बिना package हटाने की मांग की जा सकती है
- लेकिन इस मामले में उनके अनुसार Kik Messenger ने “we’ll bang on your door”, “take down your accounts” जैसी धमकियों के जरिए NPM-आधारित open source community पर दबाव डाला
- घटना को सिर्फ “एक नाराज व्यक्ति ने corporate interests का विरोध किया” के रूप में देखने से email dates और timeline, दबाव में टिके रहने की स्थिति, और बदली हुई चेतना-स्थिति में फैसले कैसे बदलते हैं—ये सब छूट जाते हैं
हटाने की प्रक्रिया और प्रभाव
- उनके अनुसार NPM के नजरिए से यह हटाना अचानक या अप्रत्याशित नहीं था
- उन्होंने पहले NPM से अपने modules हटाने का अनुरोध किया और जवाब का इंतजार किया
- क्योंकि उन्होंने कोई deadline तय नहीं की थी, NPM के पास API और tools को adjust करके transition को smooth बनाने का मौका था
- इसके बजाय NPM ने सभी packages को एक साथ हटाने वाली script दी
- उनका open source काम ज्यादातर Unix philosophy की तरह छोटे packages का था, जो एक समय में एक ही काम करते थे
- packages 350 से ज्यादा थे और सभी optimized व tested थे
- ऊपर से वे popular नहीं दिखते थे, NPM usage statistics नहीं दिखाता था, और 90% में GitHub activity भी लगभग नहीं थी
- एक सामान्य user के लिए यह जानना मुश्किल था कि unpublish करने से क्या असर पड़ेगा
- NPM द्वारा दी गई script चलाने के बाद वे कुछ मिनट के लिए दूर चले गए, और करीब 10 मिनट के भीतर एक दोस्त ने बताया कि यह Twitter पर चर्चा का विषय बन गया है
- 350 से ज्यादा packages में से एक ने React और कई projects को तोड़ दिया
- इसके बाद उन्होंने एक छोटा blog post लिखा और अपना open source काम सौंप दिया, साथ ही GitHub repositories का ownership volunteers को transfer कर दिया
- कुछ घंटों के भीतर module restore हो गया और स्थिति सामान्य हो गई
- कुछ महीनों बाद उन्होंने नौकरी छोड़ दी और स्थायी रूप से अमेरिका से चले गए, फिर Morocco, Jordan, Türkiye और Indonesia में 1 साल बिताया
- left-pad उनके लिए मृत्यु और पुनर्जन्म जैसा क्षण था, जिसमें open source से गहराई से जुड़ा उनका एक हिस्सा गायब हो गया और कुछ नया उसकी जगह आ गया; अब वे programming जितना ही company बनाने और चलाने को लेकर भी उत्साही हैं
2 टिप्पणियां
यह एक बहुत प्रभावशाली घटना थी, लेकिन पैकेज लेखक का लेख पढ़े बिना भी मुझे लगता है कि गलती उसकी तुलना में इसमें उलझी कंपनियों और सिस्टम की ज्यादा थी।
Hacker News की राय
ब्लॉग पोस्ट का आधा हिस्सा संदर्भ से कटा हुआ लगा, इसलिए ठीक से समझ नहीं आया, लेकिन यह अच्छा है कि left-pad से जुड़े व्यक्ति ने पोस्टमॉर्टम लिखा
हालांकि यह दावा अजीब लगता है कि “NPM को यह जांचना चाहिए था कि मेरा module व्यापक रूप से इस्तेमाल हो रहा है या नहीं, और बिना तोड़े unpublish करने का तरीका सोचना चाहिए था।” यह सही है कि NPM के unpublish feature का design गलत था, लेकिन अगर इसका मतलब यह है कि हर बार कोई unpublish करे तो कंपनी के कर्मचारी manually सब कुछ review करें, तो यह उचित नहीं लगता। NPM नाम की कंपनी registry को curate करने के बजाय public service की तरह host करने के ज्यादा करीब है
फिर भी लेखक को बहुत ज्यादा दोष देना मुश्किल है। अगर उसने left-pad incident न भी किया होता, तो जल्द ही कोई और इसे trigger कर देता, और NPM ने बेहतर unpublish policy से समस्या ठीक कर दी: https://docs.npmjs.com/policies/unpublish#packages-published...
Koçulu ने 22 मार्च 2016 को बस वही command चलाकर अपने publish किए हुए सभी packages हटाए, और बाद में NPM ने अपनी विफलता का दोष लेखक पर डाल दिया
JavaScript और उसके ecosystem को 21वीं सदी के Visual Basic plague की तरह टालने वाले व्यक्ति के रूप में, इस कहानी का सबसे रोचक हिस्सा यह है कि Koçulu ने कुछ समय तक tech जगत से दूरी बनाकर शानदार hiking, camping और trail exploration किया, फिर भी 8 साल बाद भी उसे लगता है कि उसे अब भी खुद को explain करना पड़ रहा है
Technology एक चंचल muse जैसी है। हम nerds technology से obsessed रहते हैं और उसकी सेवा में खुद को घिसते रहते हैं, लेकिन technology हमेशा फिर से हमें रोशनी में बुला लेती है
Morris worm के समय मैं मौके पर मौजूद था और कई हफ्तों तक उसके प्रभाव को कम करने पर काम किया था; उस अनुभव से मुझे लगता है कि मौजूदा tools से दुनिया बदलने वाली technology बनाने की हमारी क्षमता में मूलभूत समस्या है। Technology की organizational और ethical failures को समझने की जितनी कम कोशिश हम करते हैं, technology अपने लागू होने वाले क्षेत्रों में productive बदलाव लाने में उतनी ही मुश्किल महसूस करती है
मुझे भी लगता है कि अब शायद करीब एक महीने, और compile failures के कुछ सौ rounds बाद, मैं sabbatical लेने वाला हूं; और सोचता हूं कि कुछ साल बाद लौटने पर मेरी जरूरतों के हिसाब से अलग scale और context में बनाया गया technical space कैसा दिखेगा
शायद technologists के लिए ज्यादा बार, और ज्यादा गंभीरता से sabbatical लेना कुछ हद तक standard होना चाहिए। तभी हमें उन ethical dilemmas को समझने का context मिलेगा जो हमारी technical capabilities पर बोझ डालते हैं
छोटी-सी बात है, लेकिन “अधिकांश open source काम Unix philosophy का पालन करता था, और packages एक बार में एक ही काम करते थे” वाला वाक्य अस्पष्ट है
सबसे obvious उदाहरण के तौर पर, आम तौर पर कोई libc को Unix philosophy के खिलाफ नहीं मानता। बहस इस बात पर होती है कि commands या daemons बहुत ज्यादा काम कर रहे हैं या नहीं, या composable नहीं हैं क्या। हाल का प्रमुख उदाहरण systemd है
आधुनिक libc Unix philosophy के काफी खिलाफ है। पारंपरिक Unix की libc कहीं ज्यादा सरल थी और कई functions बस system calls थे। आज की libc के कुछ हिस्से libm जैसी अलग libraries में split थे, और NSS या जटिल DNS resolution frameworks जैसी चीजें तो थीं ही नहीं
Eclipse के बारे में भी कहा जा सकता है कि वह “IDE platform नाम का एक काम” करता है, लेकिन मुझे नहीं लगता Unix developers का मतलब यह था। इसी तरह, शायद उनका मतलब यह भी नहीं था कि 11 lines वाली सिर्फ एक function रखने वाली library बनाई जाए
असली सलाह शायद इतनी होनी चाहिए कि “program या library को न तो बहुत ज्यादा करने की कोशिश करनी चाहिए, न बहुत कम।” कितना ज्यादा या कम है, यह आखिरकार कई programming guidelines की तरह sense और experience मांगता है
Lions book या APUE पढ़कर, और दूसरी तरफ pthreads manual या ANSI C के
setlocale()specification पढ़कर यह निष्कर्ष निकालना संभव नहीं लगता कि ये दोनों एक ही philosophy को दर्शाते हैं। यह वैसा ही है जैसे Ayn Rand को Epicurus वाली ही philosophy की प्रतिनिधि मानना—जिसका मतलब है कि आपने दोनों में से किसी के साथ भी गंभीरता से engagement नहीं कियाइस घटना से सबसे गहराई से जो बात रह गई, वह यह थी कि JavaScript community dependencies पर बहुत ज़्यादा निर्भर थी
बस 11 लाइनों वाले code package https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... को unpublish किया गया था, फिर भी समझ नहीं आता कि इतनी ज़्यादा आलोचना क्यों हुई। लेख में यह भी कहा गया है कि इससे कितनी बड़ी निराशा पैदा होगी, यह पूरी तरह समझा नहीं गया था
NPM में usage statistics नहीं थे और GitHub activity भी लगभग नहीं थी, इसलिए users के लिए package unpublish होने का असर जानना संभव नहीं था। मेरे हिसाब से मूल कारण akoculu का package हटाना नहीं, बल्कि dependency overuse, npm policies, और code को cache या vendor न करने वाले build systems थे
Azer Koçulu कभी भी NPM ecosystem के लिए आपदा नहीं था। किसी ने भी किसी को left-pad इस्तेमाल करने के लिए मजबूर नहीं किया था, और इतने सारे projects में उसके पहुंचने की वजह गंदी transitive dependencies थीं
दूसरी ओर Jon Schlinkert ने ऐसे micro libraries जानबूझकर बनाए, उन्हें व्यापक रूप से इस्तेमाल होने वाले वैध project handlebars-helpers में डाला, लेकिन उन्हें असल में इस्तेमाल करने वाले projects में integrate करने की उसकी कोई इच्छा नहीं दिखती। अगर फंसना है तो handlebars-helpers इस्तेमाल करें, नहीं तो उस library का इस्तेमाल बंद कर दें
समस्या यह थी कि NPM ने उसका package जबरन ले लिया, और ऐसा script दिया जिसके चलाने पर खतरनाक होना साफ था। Azer Koçulu को दोष दिया गया, यह अपने आप में हास्यास्पद है
Jon Schlinkert एक typical marketing-style nuisance व्यक्ति जैसा दिखता है, और निजी तौर पर मुझे लगता है कि उसे NPM और Github से ban किया जाना चाहिए
kik package का version history अजीब है। 9 साल पहले उसे security के लिए कब्ज़ा किए गए package से replace किया गया था: https://www.npmjs.com/package/kik?activeTab=versions
Kik एक लापरवाह और काफी घिनौनी company निकली। cryptocurrency से जुड़ा विवाद भी था, लेकिन जो मुख्य बात याद रहती है वह यह कि Kik पर porn, खासकर child sexual exploitation material, खूब फैला हुआ था, और इस Darknet Diaries episode में भी इसे कवर किया गया है: https://darknetdiaries.com/episode/93/
उस नज़रिए से देखें तो Azer Koçulu का उन्हें दफा हो जाने को कहना काफी संतोषजनक लगता है
left-pad का package होना ही काफी मज़ेदार है। एक बेहद छोटी utility function के लिए CDN, proxies, build pipeline आदि से कितने bytes गुज़रे होंगे, यह सोचने पर मजबूर करता है
मौजूदा solutions का इस्तेमाल करना अच्छी बात है, लेकिन जब string padding की ज़रूरत हो तो “शायद इसके लिए कोई package होगा” सोचना मुझे ठीक से समझ नहीं आता
popularity पाने और GitHub stars लेने के लिए packages publish करने की culture भी थी, और ऐसे developers भी थे जो NPM से install हो सकने वाली चीज़ को खुद implement करने पर “reinventing the wheel” कहकर अड़ जाते थे। आज भी मैं ऐसे कई developers के साथ काम करता हूं जो simple feature के लिए भी micro packages पसंद करते हैं, क्योंकि उनके लिए इसका मतलब “maintenance कम होना” है
दोनों बिल्कुल एक जैसे नहीं हैं, लेकिन अगर tools पर्याप्त विकसित हों, तो दोनों को मिलते-जुलते ढंग से treat करना चाहने वालों को समझना असंभव हो, इतने दूर भी नहीं लगते
यह copy-paste में बस एक और step जोड़ने जैसा है
“NPM की तरफ से developers को नीचा समझने वाला एक सामान्य रवैया दिखा, जिसने अविवेकपूर्ण फैसलों की एक श्रृंखला पैदा की और आखिरकार सारी लागत मेरे सिर मढ़ दी” वाला हिस्सा है; लगता है NPM ने इस घटना के बाद भी कुछ खास नहीं सीखा
यह अच्छा हुआ कि यह घटना हुई। name squatting एक असली समस्या है, और जब स्थिति अस्पष्ट हो तो वह विकल्प चुनना चाहिए जिससे users को सबसे कम झटका लगे
usage statistics न होना भी बड़ी समस्या थी, और बस unpublish कर पाना भी बड़ी समस्या थी। infrastructure का किसी राय-प्रबल व्यक्ति के बनाए मामूली 10-line code पर निर्भर होना तब भी और आज भी असली समस्या है। इस स्थिति में सचमुच किसी एक को जिम्मेदार मानना मुश्किल है, और कोई किसी का ऋणी नहीं है, लेकिन सभी इससे सीख सकते हैं
top-10 npm पैकेजों में से कुछ को maintain करने वाले के नज़रिए से देखें तो यह लेख पूरी तरह समझ में आता है
किसी समय के बाद NPM ने community के साथ सहयोग करना बंद कर दिया था। Microsoft acquisition से यह पक्का हो गया, लेकिन उससे बहुत पहले से ही यह साफ था
npm के संचालन के तरीके में कई दरारें थीं, और वह community या mainline Node team के साथ भी अच्छे से सहयोग नहीं करता था। commercial sustainability की ओर उसका धक्का देना बहुत खटकने वाला और दबावपूर्ण लगता था। टीम के कई सदस्यों की reputation भी कुछ हद तक कठोर थी
मैं Oakland office भी गया था, वहाँ कुछ काफी दिलचस्प interactions हुए; वे खास तौर पर positive नहीं थे, लेकिन details छोड़ रहा हूँ
उस समय unpublish वाला loophole अच्छी तरह जाना जाता था। सबने left-pad पर इंटरनेट तोड़ने का आरोप लगाया, लेकिन इस पूरे मामले को गंभीर रूप से गलत manage करने की npm की जिम्मेदारी तय करने वाले बहुत कम लोग थे
अगर मेरी याद सही है, तो npm ने maintainer की इच्छा के खिलाफ package को जबरन restore किया था। अच्छे से अच्छा देखें तो यह उन लोगों से disconnect था जिनकी सेवा करने का वह दावा करता था, और बुरे से देखें तो legal तौर पर भी संदिग्ध था। उसके तुरंत बाद से platform abuse की भी खास परवाह नहीं की गई, core.js ad spam जैसी चीजें हुईं, और standards व compatibility आदि पर भी community के साथ ठीक से सहयोग नहीं हुआ
npm@5 release एक आपदा था। package lock file की शुरुआत इससे ज्यादा खराब नहीं हो सकती थी, और मेरी याद में अगले Node.js major release के साथ निकालने का दबाव था। ऐसा लगा कि Node team ने npm के तैयार होने का इंतज़ार नहीं किया, और यह देखते हुए कि npm एक for-profit company था, या कम से कम वैसा व्यवहार कर रहा था, मुझे लगता है वह उल्टा अच्छी बात थी
अंतहीन गंभीर bugs के दौर में community response, दबाव डालने वाली community को शर्मिंदा करने वाला रवैया, और पवित्रता का दिखावा—ये सब सबूत थे कि npm अब free और open-source software का प्रतिनिधि नहीं रह गया था। left-pad इससे पहले था या बाद में, याद नहीं, लेकिन मेरे दिमाग में यह ecosystem के लंबे decline की एक ही धारा के रूप में दर्ज है
आज npm packages छोटी-छोटी trivial चीजें करने वाले छोटे packages का meme बन गए हैं और हर कोई उनका मजाक उड़ाता है। पीछे मुड़कर देखें तो शायद यह सबसे अच्छा तरीका नहीं था। लेकिन context अहम है। npm एक नए उभरते popular tech के लिए पहला बेहद accessible package manager था, लगभग पूरी तरह community द्वारा managed था, उसका search system भी अच्छा था और वह GitHub की “social coding” spirit के साथ गहराई से integrated था
यह Node के शुरुआती दिनों में मौजूद था, जब ES5 भी नहीं था और लोग
varऔरprototypeइस्तेमाल करते थे। JavaScript best practices भी ठीक से नहीं बनी थीं, Joyent ने Node.js को community को सौंपा नहीं था, और Io.js fork तथा Node 0.10/0.12 की लंबी stagnation से बाहर निकलना भी बाकी थाकिसी को भी best approach नहीं पता थी
मैं लेखक को पूरी तरह समझता हूँ। security के नज़रिए से, सच में शुक्र है कि left-pad हुआ। लेखक का इरादा चाहे जो रहा हो, इसने लोगों को साफ दिखा दिया कि जिस community की सेवा करने का दावा किया जाता है, उससे अलग corporate interests पर निर्भर होने में क्या जोखिम हैं। इसने supply chain security, redundancy आदि पर कई बातचीत शुरू कीं, और लंबे समय में industry को थोड़ा बेहतर बनाया
npm, और कुल मिलाकर JavaScript, मुख्य रूप से trend का शिकार हैं