Left-Pad (2024)

 (azerkoculu.com)
1 पॉइंट द्वारा GN⁺ 2025-06-12 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • left-pad घटना open source community, NPM, और कंपनियों के बीच नियमों और मूल्यों के टकराव को दिखाने वाला एक प्रतिनिधि उदाहरण है
  • package हटाने का निर्णय तर्क, गुस्से या लालच से नहीं बल्कि सच्ची भावना और आंतरिक सिद्धांतों से निकला कदम था
  • NPM ने Kik Messenger की मांग के आगे झुकते हुए अपने ही नियम तोड़े, और इसी स्थिति में लेखक ने अपने सभी package हटाने का फैसला किया
  • घटना के बाद open source के प्रति जुनून बदल गया और रुचि business, marketing, team management जैसे नए क्षेत्रों की ओर चली गई
  • left-pad घटना ने developers और startup उद्योग को open source के सार और निर्णय-प्रक्रिया की जटिलता पर फिर से सोचने का मौका दिया

घटना की पृष्ठभूमि और निर्णय

  • left-pad घटना के 8 साल बाद, लेखक अपने व्यक्तिगत अनुभव और विचार साझा करता है
  • घटना के समय वह अपना ज़्यादातर समय ऐसी प्राकृतिक जगहों में बिता रहा था जहाँ कोई signal नहीं पहुँचता था, और package हटाने का निर्णय भी इसी आत्मचिंतन की प्रक्रिया में लिया गया था
  • यह निर्णय तार्किक गणना, गुस्से या लालच से नहीं बल्कि अपने भीतर के उस सिद्धांत से शुरू हुआ: "अगर NPM अपने नियम तोड़ता है, तो मेरे सभी package भी मिटा दिए जाने चाहिए"
  • वह किसी सख्त "rule absolutist" से ज़्यादा नियमों की मूल भावना को महत्व देने वाला व्यक्ति था
  • Kik Messenger जैसी कंपनियाँ जब open source community पर धमकी और दबाव डाल रही थीं, तब NPM ने अपने ही बनाए नियमों को नज़रअंदाज़ कर corporate हित को प्राथमिकता दी

NPM और community के बीच टकराव की संरचना

  • लेखक Kik की धमकियों से नहीं डरता था, लेकिन NPM को Kik को खोने का डर था
  • इस घटना को सिर्फ "एक गुस्सैल आदमी ने बड़ी कंपनी का विरोध किया" कहकर समझना उसके संदर्भ, समयक्रम और निर्णय के वजन को नज़रअंदाज़ करने वाली सरलीकृत दृष्टि है
  • NPM की तरफ़ से यह कोई अचानक या अप्रत्याशित घटना नहीं थी, फिर भी उसने कुल मिलाकर developers के प्रति दबंग रवैया दिखाया और कई असंगत फैसलों के ज़रिए सारी ज़िम्मेदारी लेखक पर डाल दी

package संरचना और प्रभाव

  • लेखक का ज़्यादातर open source काम Unix philosophy के अनुसार छोटे-छोटे कामों में बँटा हुआ था, इसलिए वह 350 से अधिक packages से बना था
  • ऊपर से देखने पर उपयोग के बहुत कम संकेत दिखते थे, लेकिन NPM usage statistics सार्वजनिक नहीं करता था, इसलिए वास्तविक प्रभाव-क्षेत्र समझना संभव नहीं था
  • users के पास package हटाने के असली असर को जानने का कोई तरीका नहीं था, और NPM ने भी impact analysis या बेतरतीब deletion से होने वाली समस्याओं को रोकने के लिए कोई खास प्रयास नहीं किया

8 साल बाद का बदलाव और विकास

  • left-pad घटना के कुछ महीनों बाद लेखक ने अपनी मुख्य नौकरी छोड़ दी, अमेरिका से निकल गया, और मोरक्को, जॉर्डन, तुर्किये, इंडोनेशिया जैसी नई जगहों में अपना रास्ता तलाशना शुरू किया
  • उसने open source के प्रति जुनून के टूटकर मर जाने जैसे पल और नई रुचियों के रूप में फिर जन्म लेने वाले पल दोनों का अनुभव किया
  • अब वह business, marketing, company और team management जैसे विविध क्षेत्रों में उसी जुनून से काम करता है, जैसे पहले programming में करता था
  • वह यह संदेश देता है कि ज़िंदगी चलती रहती है, और left-pad घटना स्वतंत्र निर्णय, community के मूल्य, और decision-making process की जटिलता पर फिर से विचार करने का एक अवसर बनकर रह गई

संबंधित पढ़ाई

2 टिप्पणियां

 
ndrgrd 2025-06-12

यह एक बहुत प्रभावशाली घटना थी, लेकिन पैकेज लेखक का लेख पढ़े बिना भी मुझे लगता है कि गलती उसकी तुलना में इसमें उलझी कंपनियों और सिस्टम की ज्यादा थी।
 
GN⁺ 2025-06-12
Hacker News राय

  • सच कहूँ तो इस ब्लॉग पोस्ट का आधा हिस्सा समझ नहीं आया, जैसे कोई संदर्भ छूट गया हो, लेकिन यह अच्छी बात लगी कि "left pad guy" खुद इस घटना को समेट रहा है
    लेकिन नीचे दिया गया दावा थोड़ा अजीब लगा

    लेकिन मैं अब भी समझ नहीं पाता कि NPM ने यह पता लगाने की कोशिश क्यों नहीं की कि मेरे modules कितने ज़्यादा इस्तेमाल हो रहे थे, और unpublishing को इस तरह कैसे संभाला जाए कि कुछ भी टूटे नहीं
    बेशक NPM का unpublish मॉडल खराब तरीके से डिज़ाइन किया गया था, लेकिन लेखक की बात कुछ ऐसी लगती है मानो वह उम्मीद कर रहे थे कि जब भी कोई unpublish करे, तब हर बार कोई हाथ से जाकर जाँच करे। ऐसी उम्मीद तर्कसंगत नहीं लगती। मेरी नज़र में NPM कोई curated registry चलाने वाला संगठन नहीं, बल्कि एक public service देने वाला पक्ष था
    फिर भी लेखक को दोष देना कठिन है; अगर "left-pad incident" लेखक ने न किया होता, तो शायद जल्दी ही कोई और कर देता। NPM ने समस्या ठीक की, और बेहतर unpublish policy भी बनाई
    संदर्भ के लिए NPM की नई unpublish policy

    • आप कहते हैं कि आपको इस ब्लॉग पोस्ट का आधा हिस्सा समझ नहीं आता
      शायद वजह यह है कि आपने अभी तक al-Ghazali को नहीं पढ़ा है।
      (यह पोस्ट का सबसे घमंडी और आत्मकेंद्रित हिस्सा है)

    • संदर्भ के लिए Npm left-pad incident Wikipedia देख सकते हैं

    • 18 मार्च 2016 को npm के CEO Isaac Z. Schlueter ने Kik Interactive और Koçulu, दोनों को ईमेल भेजकर बताया कि वह kik package का ownership हाथ से Kik Interactive को transfer करेंगे
      जब Koçulu ने npm के फ़ैसले पर निराशा जताई और कहा कि वह अब platform पर भाग नहीं लेना चाहते, तो Schlueter ने उन्हें एक command दी जिससे वे अपने registered सभी 273 modules हटा सकते थे
      Koçulu ने 22 मार्च को वह command चलाकर अपने अपलोड किए गए सभी packages मिटा दिए
      लेखक ने बस वही command चलाई थी जो NPM ने खुद बताई थी, लेकिन बाद में NPM ने पूरी ज़िम्मेदारी उन्हीं पर डाल दी

    • NPM नाम की कंपनी NPM registry को curate नहीं करती
      वास्तव में करती है, जैसे security vulnerability reports लेना और users को notify करना, या malicious packages हटाना

    • जब मैं पहले Sourceforge इस्तेमाल करता था, तब project delete करने से पहले अनुमति माँगना ज़रूरी होता था
      left-pad के बाद मुझे उसकी वजह पूरी तरह समझ आ गई

  • छोटी-सी बात, लेकिन

    मेरे open source projects ज़्यादातर Unix philosophy का पालन करते हुए बनाए गए थे, जहाँ packages एक समय में सिर्फ़ एक ही काम करते हैं
    कोई यह दावा नहीं करता कि libc Unix philosophy के ख़िलाफ़ है। बहस अक्सर इस पर होती है कि क्या commands या daemons में बहुत ज़्यादा features हैं (systemd इसका प्रमुख उदाहरण है), या उनकी composability कमज़ोर है

    • मुझे लगता है left-pad घटना ने दिखाया कि NPM packages का modularization इतना सूक्ष्म हो गया था कि package simplification के फ़ायदों से कहीं ज़्यादा overhead पैदा हो रहा था

    • कोई नहीं कहता कि libc Unix philosophy के ख़िलाफ़ है
      इसके उलट, बहुत से लोगों ने ऐसा कहा है, और मैं भी मानता हूँ कि यह सही है
      आधुनिक libc पारंपरिक Unix philosophy से बिल्कुल अलग है
      पहले का libc ज़्यादा सरल था, कई features libm जैसी अलग libraries में बँटे थे, और जटिल DNS जैसी चीज़ें मौजूद नहीं थीं

    • 'do one thing' का उलटा यह है कि 'उस एक काम को पूरी तरह किया भी जाए'
    • Unix philosophy, 16-bit minicomputer पर एक शक्तिशाली interactive programming environment बनाने के लिए दिशानिर्देश थी
      आज मैं अपने फ़ोन पर जो libc इस्तेमाल करता हूँ, वह 1MiB है, यानी पारंपरिक Unix से 16 गुना बड़ा
      निष्कर्ष यह निकलता है कि libc का कम-से-कम 90% हिस्सा Unix philosophy के ख़िलाफ़ है
      अगर आप Lions Book या APUE पढ़ने के बाद pthreads manual या ANSI C setlocale() spec देखें, तो साफ़ दिखता है कि यह बिल्कुल अलग philosophy है
      अगर कोई अलग-अलग philosophies को एक ही समझे, तो यह इस बात का संकेत है कि वह दोनों में से किसी को भी गंभीरता से नहीं ले रहा
    • "Unix philosophy" एक बेकार, बल्कि नुकसानदेह philosophy है
      क्योंकि 'one thing' का मतलब साफ़ नहीं है, इसलिए यह व्यवहार में कोई मदद नहीं करती और सिर्फ़ बहस कराती है
      Eclipse को भी 'IDE नाम का एक काम' करने वाला कहा जा सकता है, लेकिन Unix developers का आशय वह नहीं था
      इसका मतलब यह भी नहीं कि 11-line functions वाली library बना दो
      असली सलाह शायद बस इतनी होनी चाहिए: "programs या libraries न बहुत ज़्यादा करें, न बहुत कम"
      कहाँ तक ज़्यादा है और कहाँ तक कम, यह अंततः अनुभव और समझ का मामला है

  • यह लिखने के लिए akoculu का धन्यवाद
    मुझे लगता है यह घटना JavaScript community का, यानी dependencies पर ज़रूरत से ज़्यादा निर्भर ecosystem का, एक स्पष्ट उदाहरण है
    लोग तुम्हें इतना दोष क्यों देते हैं, यह समझ नहीं आता
    तुमने बस 11 lines के code वाले एक package को unpublish किया था, और उससे होने वाले side effects का पूरी तरह अनुमान लगाना शायद संभव नहीं था
    लेखक ने पोस्ट में खुद कहा

    NPM भी usage stats ठीक से नहीं दिखाता था, और Github पर भी लगभग कोई activity नहीं थी
    एक user के रूप में package unpublish करने के असर को समझना मुश्किल था
    मुझे लगता है असली कारण akoculu का unpublish नहीं, बल्कि dependency overload, npm policy, और build systems में caching/vendoring की कमी थी
    संदर्भ: incident background wiki

  • kik package का version history अजीब है
    9 साल पहले इसे एक security holding package से बदल दिया गया था
    kik package version history

    इस पूरे मामले की सबसे बड़ी विडंबना kik package ही है
    जिस kik package को kik इतनी शिद्दत से पाना चाहता था, वह अंत में किसी काम का निकला ही नहीं
    और Kik नाम की कंपनी बाद में लापरवाह और समस्याग्रस्त साबित हुई
    crypto से जुड़े विवाद भी थे, और यह भी कहा गया कि वह चुपचाप child porn जैसी चीज़ों के distribution platform के रूप में इस्तेमाल होती थी
    संदर्भ: Darknet Diaries episode 93
    इसलिए Azer Koçulu का Kik को लेकर सख़्त रुख़ लेना उल्टा संतोषजनक लगता है

    तो आख़िरकार इस सबका नतीजा यह निकला कि... अंत में कुछ भी मायने नहीं रखा?

  • यह अपने-आप में काफ़ी मज़ेदार है कि left-pad एक package के रूप में मौजूद था
    सिर्फ़ एक string padding function के लिए CDN, proxy, build pipeline वगैरह से होकर बेहिसाब bytes इधर-उधर गए
    मैं existing solutions के अच्छे इस्तेमाल के पक्ष में हूँ, लेकिन सिर्फ़ string के आगे padding लगाने वाले function के लिए यह सोचना कि "शायद इसका कोई package होगा" समझना मुश्किल है

    उस समय की बहस का एक हिस्सा web developers के micro-packages के प्रति अंधे लगाव को लेकर जागरूकता पैदा करने वाला था
    popularity और Github stars के लिए packages release करने की culture भी थी
    और दूसरी तरफ़ npm से install हो सकने वाली किसी भी चीज़ को खुद implement न करने की भी मज़बूत culture थी
    आज भी मेरे साथ काम करने वाले बहुत से developers सरल packages को तरजीह देते हैं
    उनका तर्क होता है, "maintenance burden कम हो जाता है"
    वाकई विडंबनापूर्ण स्थिति है

    package का मूल implementation भी शायद O(n) नहीं, बल्कि O(n^2) जैसा inefficient operation करवाता था
    Wikipedia संदर्भ

    किसी और के project की utility function को देखकर इस्तेमाल करना, और पूरे ecosystem में पहले से फैले package का इस्तेमाल करना—क्या quality के लिहाज़ से इन दोनों में बहुत बड़ा फ़र्क है?
    दोनों एक जैसे नहीं हैं, लेकिन पर्याप्त विकसित tooling वाले environment में मुझे नहीं लगता कि दोनों approaches व्यवहार में बहुत दूर हैं

    code reuse को हर हाल में अधिकतम करने की प्रवृत्ति, और copy-paste को पुराना तरीका मानने का आग्रह

    क्या यह AI जैसा ही मामला नहीं है?
    वह समस्या जो साधारण search से हल हो सकती है, उसे आज लोग अनगिनत prompts के साथ AI से फिर पूछते हैं
    यानी C&P पर एक और अनावश्यक step जोड़ देना

  • Unix philosophy कहती है, "एक काम अच्छे से करो"
    left-pad ने दूसरा हिस्सा (अच्छे से करो) छोड़ दिया
    मुझे यह देखकर हैरानी हुई कि इतने सारे projects ने यह naïve implementation ज्यों का त्यों इस्तेमाल किया
    एक बेहतर optimized implementation तेज़ भी हो सकती थी और छोटी भी

    मुझे JavaScript culture की ज़्यादा जानकारी नहीं, लेकिन याद है कि npm downloads बढ़ाने की एक प्रतिस्पर्धी प्रवृत्ति थी
    left-pad के साप्ताहिक 14 लाख downloads थे, is-even के 1.6 लाख
    कुछ लोग मज़ाक में, और कुछ library popularity metrics बढ़ाने के लिए micro-packages को dependencies में जोड़ते थे
    react-आधारित एक मशहूर library के अंदर is-even जैसा package डालने का भी विरोध हुआ था
    इसकी वजह "जो code खुद लिखा जा सकता है, उसे भी हर हाल में बाहर से लाओ" जैसे सख़्त सिद्धांत थे
    संबंधित कहानी: is-odd package एक हफ़्ते में 30 लाख बार install क्यों हुआ

    'nonnative implementation' का उदाहरण जानने में दिलचस्पी है

  • मैं एक popular npm package maintainer हूँ
    इससे सचमुच सहमत हो सकता हूँ
    npm एक समय के बाद community collaboration से दूर जाने लगा
    Microsoft द्वारा अधिग्रहण के बाद यह और मज़बूत हुआ, लेकिन उससे पहले भी संकेत बहुत थे
    npm के कई operational तौर-तरीके, community/Node team के साथ उसका असहयोगी रवैया, commercialization पर ज़रूरत से ज़्यादा ज़ोर, और कुछ सदस्यों की reputation—कई चीज़ें खटकती थीं
    मुझे Oakland office की अपनी एक visit याद है, लेकिन उस दिन के interactions बहुत सकारात्मक नहीं थे, इसलिए विस्तार में नहीं जाऊँगा
    unpublish loophole तब सबको पता था
    सबने "left-pad ने internet तोड़ दिया" कहकर लेखक को ही दोष दिया, लेकिन मुझे लगता है असली समस्या npm की खराब operation थी
    अगर याद सही है, तो maintainer की इच्छा के ख़िलाफ़ package को forcefully restore भी किया गया था, और यह ऐसा कदम था जो उस community से पूरी तरह कटा हुआ था जिसका प्रतिनिधित्व npm खुद को बताता था (कम-से-कम कानूनी तौर पर भी अजीब)
    इसके बाद npm ने abuse, spam आदि के management में लगभग कोई रुचि नहीं दिखाई (जैसे core.js ad spam), और community के साथ standards तथा compatibility पर भी बहुत कम बातचीत की
    npm@5 release भी बड़ी विफलता थी, package lockfile की शुरुआत भी भारी अफ़रा-तफ़री में हुई
    (मुझे तो यह भी लगता है कि Node team का npm के तैयार होने का इंतज़ार किए बिना release कर देना अच्छा फ़ैसला था)
    उस समय community से संवाद की हालत बड़े bugs, community को दोष देना, और दबंग रवैये जैसी चीज़ों से बेहद खराब थी
    यह सब इस बात का संकेत था कि npm अब open source spirit का प्रतिनिधि नहीं रहा
    left-pad इससे पहले हुआ या बाद में, यह अब धुंधला है, लेकिन उस दौर में पूरा ecosystem लंबे ठहराव और अव्यवस्था से गुजर रहा था
    npm packages को अक्सर मामूली functions के standalone packages (meme) के रूप में देखा जाता है, लेकिन संदर्भ में देखें तो npm उभरती हुई लोकप्रिय technology के लिए पहला आसानी से उपलब्ध package manager था, community-led था, और Github के साथ organically integrated system था
    यह Node के शुरुआती दिन थे (जब ES5 भी नहीं था और var, prototype चलते थे), Joyent द्वारा Node.js को community को सौंपने से भी पहले, Io.js fork और Node 0.10/0.12 की लंबी ठहराव अवधि से भी पहले
    तब किसी को ठीक-ठीक नहीं पता था कि best practices क्या हैं
    लेखक के नज़रिये से गहरी सहानुभूति है
    security perspective से देखें तो left-pad घटना, भले इरादे से न हुई हो, ecosystem के भीतर companies/communities के अलगाव और supply chain security पर एक बड़ा wake-up call थी
    इसने redundancy बढ़ाने और security पर महत्वपूर्ण चर्चाएँ शुरू कराईं
    मुझे लगता है कि इससे industry अंततः बेहतर हुई
    बहुत समय बाद फिर पढ़ना दिलचस्प लगा

    npm किसी भी language का पहला package manager नहीं था, और इतनी छोटी-छोटी packages की अधिकता को लेकर पहले से बहुत लोग चेतावनी दे रहे थे
    मुझे लगता है npm और पूरा JS ecosystem trend का शिकार था

  • left-pad के समय की संबंधित चर्चा
    Hacker News discussion

  • Java में Apache Commons, Google Guava जैसी भरोसेमंद utility libraries हैं, तो JS में ऐसी चीज़ क्यों नहीं है?

    JavaScript में भी Lodash जैसी भरोसेमंद utility library है। पहले की तुलना में इसके ज़्यादातर features अब standard library में आ चुके हैं
    सच तो यह है कि Lodash ने left-pad घटना से 3 महीने पहले ही pad/padStart/padEnd functions दिए थे
    Lodash pad docs

    मेरे हिसाब से सबसे बड़ा कारण culture है, फिर अच्छी standard library, और फिर ऐसे tools की मौजूदगी जो 300 से ज़्यादा बेकार packages को dependencies में ठूँसने से रोकें

    Maven सच में बहुत अच्छे से डिज़ाइन किया गया tool है (विडंबना यह कि इसकी हमेशा बुराई ही होती है), और यह Java की सफलता के रहस्यों में एक है
    npm जैसे commercial compromises वहाँ इसलिए नहीं हैं क्योंकि Java के पास अच्छी तरह समर्थित non-profit, community-based Apache Foundation है (ऐसी संरचना बहुत दुर्लभ है, और Java के जटिल कानूनी इतिहास की वजह से मिला एक सौभाग्यशाली परिणाम भी)
    (JS में भी शानदार libraries बहुत हैं। समस्या यह थी कि package management बहुत ज़्यादा centralized था और management कमजोर था)

    Google Guava, lodash के अधिक क़रीब है, left-pad के नहीं

    पहले Jquery और Underscore जैसी libraries यह भूमिका निभाती थीं

  • मुझे यह देखकर हैरानी होती है कि कितनी कंपनियाँ build के लिए ज़रूरी सभी dependencies को internally mirror नहीं करतीं
    पूरी build process को offline clean build के रूप में चलाया जा सकना चाहिए, और सिर्फ़ download cache पर निर्भर रहना किस्मत के भरोसे रहने जैसा है

    मैं अपने projects में हमेशा dependencies को अंदर vendor करके रखता हूँ
    इससे चीज़ें predictable रहती हैं, offline build संभव होता है, और storage की लागत भी सस्ती है