"छोटे" open source की किस्मत

• JavaScript की छोटी utility libraries अब LLM की code generation क्षमता के कारण धीरे-धीरे गैर-ज़रूरी होती जा रही हैं
• उदाहरण के तौर पर blob-util एक 10 साल पुराना npm package है, जो Blob processing toolkit है, लेकिन अब AI तुरंत मिलते-जुलते code generate कर सकता है
• यह बदलाव कम dependencies और तेज़ development को संभव बनाता है, लेकिन सीखने और समझने के अवसरों के नुकसान का कारण भी बनता है
• Node.js और browser की built-in capabilities के विस्तार के बाद, LLM अब छोटी libraries के अंत को और तेज़ कर रहा है
• आगे चलकर open source का मूल्य रचनात्मक, बड़े पैमाने के और विशेषज्ञता वाले क्षेत्रों में बना रह सकता है

---

छोटे open source के पतन और LLM का प्रभाव

• 10 साल पहले बनाया गया blob-util, JavaScript के Blob object को string या ArrayBuffer में बदलने वाली सरल utilities का संग्रह है, और इसे हर हफ्ते 50 लाख से अधिक बार download किया जाता है
  • लेखक ने इसे तब बनाया था जब उन्होंने देखा कि PouchDB users Blob handling को लेकर भ्रमित हो रहे थे
• वर्तमान में लगभग 80% developers अपने काम में AI का उपयोग कर रहे हैं, और इसकी वजह से साधारण utilities को LLM से बदला जा सकता है
  • उदाहरण के लिए Claude तुरंत Blob को ArrayBuffer में बदलने वाला TypeScript function generate कर देता है
• Claude का परिणाम blob-util से मिलता-जुलता है, लेकिन ज़्यादा verbose है और type validation जरूरत से ज़्यादा करता है, जबकि error handling बेहतर रूप में दिखाई देती है
• लेखक कहते हैं कि यह बदलाव कम dependencies और बेहतर code robustness के रूप में देखा जा सकता है

सीखने-केंद्रित open source के मूल्य में कमी

• blob-util के README में Kirby character का उपयोग करने वाला tutorial शामिल है, और इसका उद्देश्य केवल functionality देना नहीं बल्कि JavaScript सीखने में मदद करना भी था
• LLM-केंद्रित development environment में तुरंत जवाब समझ और शिक्षा पर प्राथमिकता पा लेते हैं, इसलिए ऐसे learning-oriented open source की ज़रूरत घटती जा रही है
• documentation automation के लिए llms.txt जैसे प्रयास documentation के अर्थ को ही फिर से परिभाषित कर रहे हैं

open source की नई दिशा

• लेखक अभी भी open source जारी रखे हुए हैं, लेकिन उनका मानना है कि छोटी और कम-मूल्य libraries का दौर खत्म हो चुका है
  • Node.js और browser की built-in features (node:glob, structuredClone आदि) के विस्तार से यह गिरावट पहले ही शुरू हो चुकी थी
  • LLM ने उस प्रवाह को निर्णायक रूप से तेज़ कर दिया
• जो libraries शैक्षिक भूमिका निभाती थीं, जैसे Underscore.js, उनकी ज़रूरत भी कम हो रही है
  • साधारण array grouping जैसी functionality अब standard API से हल की जा सकती है

जिन open source में मूल्य बचा रहेगा, उनकी शर्तें

• मूल्य अब उन बड़े पैमाने के, रचनात्मक और विशेषज्ञता वाले projects पर केंद्रित होगा जिन्हें LLM आसानी से generate नहीं कर सकता
  • उदाहरण के लिए fuite project और memory leak detection research ऐसे रचनात्मक काम हैं जिन्हें LLM के लिए दोहराना कठिन है
• भविष्य में open source का अर्थ नए विचारों और मानवीय रचनात्मकता में होगा
  • उदाहरण के तौर पर Dominic Gannaway द्वारा विकसित Ripple.js framework का उल्लेख करते हुए मानव प्रयोगधर्मिता पर ज़ोर दिया गया है

निष्कर्ष

• LLM ने कुछ open source को पुराना और अप्रासंगिक बना दिया है, लेकिन अब भी open source सृजन के नए रूपों के अवसर मौजूद हैं
• मानव developers की रचनात्मकता और प्रयोगधर्मिता को AI युग में open source ecosystem की स्थिरता का मुख्य तत्व बताया गया है

[savvykang]

मुझे लगता है कि अगर left-pad जैसी अजीब इकोसिस्टम आदतों को ही रोका जा सके, तो यह ठीक है।

[shakespeares]

जैसे-जैसे यह ऐसा दौर बनता जा रहा है जहाँ किए गए प्रयास के मुकाबले संतुष्टि कम मिलती है, लगता है कि छोटी utilities को maintenance में लगने वाली मेहनत की तुलना में कम मूल्यवान मानकर नज़रअंदाज़ किया जाएगा।

[haytsir]

2024 की शुरुआत में एक छोटा प्रोजेक्ट बनाते समय
मैंने claude 3.5 से pure javascript में इस्तेमाल होने वाला store state मॉड्यूल बनाने को कहा था,
और मुझे याद है कि मैं इस बात से हैरान था कि उसने कितना संक्षिप्त, लेकिन migration जैसी स्थितियों को भी संभालने वाला कोड लिख दिया।

मुझे लगता है कि यह स्वाभाविक है, क्योंकि छोटे libraries के मामले में वैसे भी बहुत-से लोग समान सोच के साथ public code जारी कर चुके होंगे, और AI के लिए उसे एक संरचित रूप में ढालना आसान होगा।

copyparty की तरह, ऐसी चीज़ें जिन्हें कोई भी सोच सकता है, लेकिन किसी एक व्यक्ति के लिए लंबे समय तक maintain करना मुश्किल होता है।
मुझे इस बात का अफसोस ज़रूर है कि आगे चलकर शायद उन projects को देखना मुश्किल हो जाए, जिन्हें ऐसे लोग आखिर तक धकेलते हैं और जो अंत में बहुत साफ़-सुथरे और परिष्कृत रूप में सामने आते हैं।

[GN⁺]

Hacker News राय

• आजकल लगभग 80% डेवलपर AI को अपने काम में इस्तेमाल कर रहे हैं
  blob-util जैसी utilities अब ज़्यादातर सीधे LLM से बनवाई जा सकती हैं
  लेकिन यह तरीका दो धार वाली तलवार है। बिना सत्यापित code आगे चलकर maintenance का बोझ छोड़ सकता है और edge cases में fail भी हो सकता है
  इसलिए Java ecosystem में Apache Commons जैसी भरोसेमंद standard utility collections ने अपनी जगह बना ली है

  • पुरानी utility libraries पहले ही अलग-अलग environments में परखी जा चुकी हैं, इसलिए स्थिर हैं
    वहीं LLM से बना code ऊपर से तार्किक दिखता है, लेकिन उसमें अजीब bugs छिपे होने की संभावना ज़्यादा होती है

• AI जब बड़े पैमाने पर code और tutorials बना रहा है, तब हम ऐसे दौर में प्रवेश कर चुके हैं जहाँ quality गिरावट और spam तेज़ी से बढ़ रहे हैं
  personal blogs या छोटी libraries बनाने की प्रेरणा कम हो रही है

  • सच तो यह है कि web बहुत पहले से ही low-quality tutorial spam से भरा हुआ था
    LLM से बने लेख भी लगभग उसी स्तर के लगते हैं, इसलिए उल्टा उन्हें filter करना आसान हो गया है
    मैं devcontainer के अंदर code चलाकर tutorial की असली value जांचता हूँ। अगर काम करता है तो देखने लायक है, नहीं तो छोड़ देता हूँ
  • आज YouTube पर एक खास विषय खोजते समय AI-generated videos ही अंतहीन रूप से आते रहे, यह देखकर हैरानी हुई
  • “low-quality spam का युग आने वाला है” जैसी बात अब पहले से ही हक़ीक़त बन चुकी है
  • एक web developer ने मज़ाक में कहा, “अब हम 10 गुना तेज़ हो गए हैं, तो यह मानवता के लिए बुरा कैसे हो सकता है”
  • किसी ने व्यंग्य में assembly code फेंकते हुए कहा, “अगर इसे समझा नहीं सकते, तो असली developer नहीं हो”

• JS का micro-dependency hell एक बुरा सपना था
  अब उम्मीद है कि वह दौर खत्म हो और डेवलपर फिर से coding सीखने वाले समय में लौटें

  • jQuery या lodash की तरह छोटी utility collections को एक package में बाँधना सबसे अच्छा नतीजा था
  • लेकिन “अब सब खत्म हो गया” वाली बात पर सवाल उठाया गया। उल्टा AI-generated code की बाढ़ से हालात और खराब हो सकते हैं
  • जैसे-जैसे LLM code बढ़ेगा, एक ही काम करने वाले functions कई versions में बिखर जाएँगे, और bug fixes भी सबको अलग-अलग करने पड़ेंगे
  • LLM इस्तेमाल करने से लोग ज़रूरी नहीं कि ज़्यादा सीखें। दिक्कत आने पर वे refactoring भी LLM से ही करवा देंगे
  • किसी ने छोटा सा जोड़ते हुए कहा, “अब vibe coder का दौर आ गया है”

• किसी ने पूछा कि “binary tree को उलटने वाली समस्या” सच में होती भी है क्या

  • शायद यह उस समस्या की ओर इशारा है जिसमें Homebrew के founder Google interview में fail हुए थे
  • संभव है कि यह लेखक की साधारण गलती हो, और अगर इसे करना भी हो तो comparison operators उलटे कर देने जैसा बेअर्थ अभ्यास ही होगा

• “छोटी और कम value वाली libraries का दौर खत्म हो गया” वाली बात से सहमति जताई गई
  Go language में शुरू से dependency hell नहीं था, और npm की समस्या ज़्यादा cultural कारणों से थी
  अब utilities से ज़्यादा वास्तव में काम करने वाले products बनाना अधिक valuable और मज़ेदार लगता है

  • Go की एक कहावत है: “थोड़ी copy करना, थोड़ी dependency लेने से बेहतर है” (Go Proverbs)
  • यह सवाल भी उठा कि Go की कौन-सी खासियत ने ऐसी dependency समस्याओं को रोका

• मेरा मानना है कि micro-dependencies अपने आप में ही बेअर्थ हैं
  बेहतर है कि function list को Markdown में लिख दिया जाए ताकि लोग उसे copy कर सकें
  C का header file-आधारित छोटी library वाला तरीका ज़्यादा practical है

  • इस पर मज़ाकिया प्रतिक्रिया आई: “तो फिर ऐसी header libraries को standard C library में शामिल क्यों नहीं कर देते?”
  • लेकिन साथ ही यह व्यावहारिक आपत्ति भी आई कि “अगर copy-paste मॉडल हो, तो security updates कैसे होंगे?”

• यह सवाल उठा कि “अब किस रूप का open source मायने रखेगा”
  क्योंकि public किया गया code आख़िरकार AI training data में समा जाता है
  इसलिए पूरी FOSS के बजाय source-available model एक विकल्प हो सकता है

  • इस पर जवाब आया, “अगर ज़्यादा लोग इस्तेमाल कर सकें, तो वही तो open source का फ़ायदा है?”
    लेखक ने ज़ोर दिया कि contribution का अर्थ सिर्फ नाम दर्ज हो जाने से बड़ा है
  • लेकिन कुछ लोगों ने संदेह जताया कि “source-available भी आख़िर training में इस्तेमाल होगा ही”
  • किसी ने कहा, “दुनिया को मुफ़्त में ज्ञान देना हमारी ज़िम्मेदारी नहीं है,” और reciprocity के बिना sharing को ठुकराया जाना चाहिए
  • एक राय यह भी थी कि “non-free code बाँटना अनैतिक है,” इसलिए free software principles पर टिके रहना चाहिए
  • एक व्यक्ति ने कहा कि “अब open source में मेरी रुचि नहीं रही,” और उसने अपने सभी projects private कर दिए

• मेरा विश्वास है कि open source गायब नहीं होगा, बल्कि और मज़बूत होगा
  सचमुच रचनात्मक डेवलपर AI का इस्तेमाल करके ऐसे innovations बनाएँगे जो कंपनियाँ नहीं बना सकतीं
  open source अब भी वास्तविक value validation का मंच है, और AI के ज़रिए सीमाएँ पार करके सीखने की जगह भी

  • असली innovation open source से ही आएगा
    लेकिन अनुमान है कि सरकारें और बड़ी कंपनियाँ local AI systems को regulate करना चाहेंगी, और जल्दी ही “नागरिक कौन-सा AI इस्तेमाल कर सकते हैं” इसकी सीमाएँ तय होंगी
  • दूसरी तरफ, open source projects पहले से ही AI-generated code submissions से परेशान हैं
    review और policy discussion में समय बर्बाद हो रहा है, और खासकर compiler जैसे जटिल क्षेत्रों में AI बिल्कुल मददगार नहीं है

• किसी ने ज़ोर दिया कि “package के रूप में न जुड़े तब भी, code को public करना अपने आप में valuable है”

  • मैं भी जब छोटे code snippets पाता हूँ, तो उन्हें copy करके अपने standards के हिसाब से बदल लेता हूँ। यह विज्ञान की साझी भावना जैसा लगता है
    अगर LLM code लिख दे, तो सीखने का बोझ कम हो जाता है और गहरे विषयों पर ध्यान देना आसान होता है
  • मुझे लगता है Copyleft licenses बेहतर हैं। इससे कंपनियाँ मनमाने ढंग से चीज़ें उठाकर इस्तेमाल नहीं कर पातीं, और उन्हें सीधे लोगों को hire करना पड़ता है
  • बिना चलाए भी दूसरे का code पढ़कर सीखना बहुत valuable है। समस्या का समाधान अपने आप में एक उपहार है
  • लेकिन open source आख़िरकार समय और श्रम का निवेश है
    उदाहरण के लिए, किसी ने बताया कि 14 साल तक rubygems.org चलाने के बाद वह corporatized structure से निराश होकर अलग हो गया

• यह भी कहा गया कि “AI से code लिखवाना भी आख़िर dependency का ही एक रूप है”
  बिना verification के copy-paste करना किसी external library को जोड़ने से अलग नहीं है

  • फिर भी, LLM से बना code ज़रूरत के हिसाब से संकीर्ण रूप में design किया जा सकता है, इसलिए अनावश्यक features कम होते हैं और efficiency बढ़ सकती है
  • साथ ही, इसमें supply chain attacks या बार-बार updates संभालने का बोझ नहीं होता, जो इसका एक फ़ायदा है
  • दूसरी तरफ, libraries समय के साथ अपने आप modernize हो जाती हैं, जबकि LLM code snippets के साथ ऐसा नहीं होता
  • आख़िरकार समस्या tool नहीं, बल्कि बिना जाँचे copy-paste करने की आदत है। गैर-जिम्मेदार डेवलपर किसी भी tool के साथ वही नतीजा देंगे