Visual Studio Code की डिज़ाइन खामियाँ (2022)

 (ghuntley.com)
4 पॉइंट द्वारा GN⁺ 2024-09-30 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • Visual Studio Code में MIT लाइसेंस वाले source code और Microsoft द्वारा वितरित proprietary license product अलग-अलग हैं, इसलिए VSCodium और OpenVSCode Server जैसे forks आधिकारिक ecosystem से टकराते हैं
  • आधिकारिक build product.json में telemetry, gallery, logo जैसी Microsoft-विशिष्ट settings जोड़कर वितरित किया जाता है, जबकि community build “clean” build बनता है लेकिन Visual Studio Code Marketplace से connect नहीं कर सकता
  • VSCodium और OpenVSCode Server आधिकारिक release की telemetry को हटाते हैं या शामिल नहीं करते, लेकिन extension के अपने data collection और Marketplace access restrictions के कारण उपयोगकर्ताओं को अपेक्षित VS Code experience वैसा का वैसा देना मुश्किल होता है
  • अगर Pylance, C# extension roadmap, और C/C++ tools license की तरह Microsoft extensions और language servers आधिकारिक products और services से बंध जाते हैं, तो Gitpod, GitLab, Datacoves, OpenBB, Foam जैसी competing services के लिए वही functionality कानूनी रूप से देना कठिन हो जाता है
  • OpenVSX, open language tools development, और open source maintainers के support को विकल्प के रूप में पेश किया जाता है, लेकिन जब Microsoft defaults को proprietary tools की ओर बदलता है, तब community और competing products को feature differences, settings differences, और legal restrictions एक साथ झेलने पड़ते हैं

Source code खुला है, लेकिन product अलग तरीके से वितरित होता है

  • Visual Studio Code, रिलीज़ के 7 साल बाद, software development में de facto standard editor बन चुका है
  • Microsoft ने Visual Studio Code का source code MIT license के तहत जारी किया, लेकिन जो Visual Studio Code product users download करते हैं, वह अलग proprietary license के तहत वितरित होता है
  • Visual Studio Code maintainers के अनुसार, Microsoft build vscode repository को clone करने के बाद Microsoft-विशिष्ट product.json को उस पर overwrite करता है
    • इस file में telemetry, gallery, logo जैसी Microsoft-विशिष्ट features शामिल होती हैं
    • इस तरह तैयार build Microsoft license के तहत वितरित होता है
  • लेख की मुख्य आलोचना यह है कि यही विभाजन वह मुख्य mechanism है जिससे Microsoft open source community को विभाजित करता है

VSCodium और OpenVSCode Server की सीमाएँ

  • VSCodium community-led free license desktop distribution है
    • यह upstream MIT project को अपने-आप follow करता है और binary builds बनाता है
    • यह आधिकारिक release में मौजूद telemetry हटाकर builds प्रदान करता है
    • default product.json में Microsoft endpoints configured नहीं होते, इसलिए Microsoft customization के बिना “clean” build बनता है
  • VSCodium वही codebase इस्तेमाल करने के बावजूद सभी data collection को पूरी तरह रोक नहीं सकता
    • extensions स्वतंत्र रूप से data collect कर सकते हैं, इसलिए कौन-से extensions install किए जाते हैं इस पर ध्यान देना ज़रूरी है
  • OpenVSCode Server, Gitpod की नींव बनने वाली free license server distribution है
    • यह upstream MIT project को अपने-आप follow करता है
    • gp-code/main branch में कुछ overlay customizations हैं
    • इसमें आधिकारिक release की telemetry शामिल नहीं होती
  • दोनों distributions Microsoft Visual Studio Code Marketplace से connect नहीं कर सकतीं, और यही restriction ecosystem fragmentation की ओर ले जाती है

Microsoft का service-centric बदलाव और developer tools strategy

  • Microsoft ने लगभग 9 साल पहले software delivery का तरीका बदलना शुरू किया
    • dedicated QA team द्वारा builds test करने वाले मॉडल से sprint-based development, rolling release, और Insider Build telemetry feedback-आधारित मॉडल की ओर बदलाव हुआ
  • इसी दौरान organizational restructuring के साथ Microsoft एक services company में बदल गया
    • Azure इस अवधि में AWS का वास्तविक competitor बनकर उभरा
  • consumer perspective से सबसे बड़ा बदलाव यह था कि customer base installable on-premise products से Microsoft द्वारा दिए जाने वाले service consumption model की ओर शिफ्ट हो गया
  • developer tools क्षेत्र में भी subscription के बिना IDEs घटते हुए trend के रूप में देखे जाते हैं
    • Apple के Xcode जैसे cases, जहाँ दूसरी revenue streams हैं, उन्हें अपवाद के रूप में बताया गया है
  • Visual Studio Code पर यह आलोचना है कि यह developer tools ecosystem को end-to-end consumption-based service model की ओर ले जाने का entry point है
    • GitHub Codespaces को Visual Studio Online, Microsoft Dev Box, और Microsoft Azure DevTest Labs से जुड़े मौजूदा services का white label बताया गया है

GitHub Codespaces और Microsoft DevDiv

  • Microsoft ने 2018 में GitHub का अधिग्रहण किया और 2019 में Visual Studio Online पेश किया
    • इसमें local स्तर पर “codespace” host करने वाले components शामिल थे
    • बाद में Codespaces team सहित संबंधित components GitHub में स्थानांतरित कर दिए गए
  • GitHub Codespaces को GitHub के भीतर आया DevDiv project बताया गया है
  • Nat Friedman के CEO पद छोड़ने वाले दिन Microsoft की internal reorganization mail साझा हुई
    • Julia Liuson को Microsoft Developer Division की President बनाया गया
    • GitHub CEO Thomas Dohmke, Julia Liuson को report करने लगे
    • Developer Division में Visual Studio, Visual Studio Code, .NET, C#, TypeScript, OpenJDK, Azure developer SDK, Azure App Services, Functions, Logic Apps, API Management, Dapr, Redis Cache, Spring Cloud आदि शामिल हैं
  • उस mail के अनुसार Visual Studio और Visual Studio Code ने 2014 के बाद से 16 गुना से अधिक usage growth दर्ज की
  • Julia Liuson का उल्लेख उस व्यक्ति के रूप में किया गया है जिसने promotion से पहले .NET community को बाँट देने वाला last-minute change लागू किया
    • The Verge के हवाले से Microsoft के एक anonymous internal source ने इस बदलाव को business-driven decision माना

ऐसा ecosystem structure जो “designed fracture” की तरह काम करता है

  • Gitpod जैसे competing products Visual Studio Code ecosystem के भीतर मौजूद रह सकते हैं, लेकिन आलोचना यह है कि Microsoft किसी भी समय legal risk पैदा करके market को बाँट सकता है
  • Visual Studio Code का open source source code users को आकर्षित करता है, लेकिन competing services के लिए आधिकारिक Visual Studio Code या GitHub Codespaces जैसा seamless experience देना मुश्किल बना देता है
  • सिर्फ Gitpod ही नहीं, बल्कि GitLab, Datacoves, OpenBB, Foam जैसी वे कंपनियाँ भी जो VS Code source code के आधार पर Microsoft या GitHub से compete करना चाहती हैं, इसी समस्या का सामना करती हैं
  • Microsoft tools पर निर्भर होने से जिन क्षेत्रों में competing services के लिए कानूनी रूप से offer करना कठिन हो सकता है, उनमें ये शामिल हैं
    • Microsoft .NET C#
    • Python का general-purpose और data science market
    • Project Jupyter और data science market का बड़ा हिस्सा
    • C या C++
    • अनुमान है कि अगर Microsoft tools, RedHat tools के स्तर तक पहुँचते हैं, तो Java अगला target हो सकता है
  • TIOBE index के अनुसार ऊपर बताए गए language-ecosystems में से 5 सबसे लोकप्रिय श्रेणियों में आते हैं, और कहा गया है कि Microsoft के पास TypeScript के ज़रिए 7वें सबसे लोकप्रिय JavaScript पर भी लगभग वैसा control है

Defaults बदलना और proprietary extensions की समस्या

  • आलोचना यह है कि पर्याप्त adoption हासिल करने के बाद Microsoft extension updates के ज़रिए proprietary offerings को default बना सकता है
  • Python community में open source Microsoft Python Language Server बंद कर दिया गया और proprietary Pylance नया default बन गया
    • Visual Studio Magazine के हवाले से Microsoft ने users को force नहीं किया, लेकिन Pylance को नया default सेट किया
    • Python extension ने VS Code Marketplace पर लगभग 5 करोड़ downloads दर्ज किए, और इसे अगले सबसे लोकप्रिय Jupyter extension से लगभग 2 गुना बताया गया
  • .NET community में भी C# extension roadmap के माध्यम से ऐसा ही default shift जारी उदाहरण के रूप में पेश किया गया है
  • भले ही Open.NET जैसे alternative tools बनाए जाएँ, users को platform-specific settings अलग से जोड़नी पड़ती हैं
    • desktop पर devcontainer.json में ms-dotnettools.csharp डाला जा सकता है
    • Gitpod में gitpod.yml में ऐसे open tools डालने पड़ेंगे जो अभी मौजूद भी नहीं हो सकते
  • Microsoft के आधिकारिक ecosystem के भीतर वही devcontainer.json setting desktop Visual Studio Code और GitHub Codespaces दोनों में single source of configuration की तरह काम करती है

License से पैदा होने वाली कानूनी पाबंदियाँ

  • चेतावनी दी गई है कि अगर Gitpod, GitLab, Datacoves, OpenBB, Foam आदि restrictions को bypass करके ms-dotnettools.csharp जैसे Microsoft extensions अपनी service में दें, तो उन्हें Microsoft legal team की कड़ी कार्रवाई का सामना करना पड़ सकता है
  • competing cloud development environments के users अगर उस extension को manually install भी करें, तब भी यह license violation हो सकता है
  • Microsoft C/C++ extension license में कहा गया है कि software को केवल Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, और उनके बाद आने वाले Microsoft products और services के साथ ही install और use किया जा सकता है
  • इस शर्त के कारण आधिकारिक Microsoft distribution न होने वाले VS Code-based products के लिए वे Microsoft language tools देना कठिन हो जाता है जिनकी users अपेक्षा करते हैं

आगे की दिशा: OpenVSX और open language tools

  • आलोचना की गई है कि आज बनाए जा रहे software development tools का भविष्य अधिक बंद होता जा रहा है
    • भले ही कुछ components OSI definition पूरी करते हों, पूरा composition graph ऐसा ज़रूरी नहीं कि हो
  • open source को मूल रूप से proprietary on-premise software पर नियंत्रण रखने और file format openness बनाए रखने के financial weapon के रूप में बताया गया है
    • साथ ही इसे इस बात से जोड़ा गया है कि open source से पैसा कमाना कठिन क्यों होता है
  • सुझाव दिया गया है कि proprietary SaaS के खिलाफ computing freedom की openness सुनिश्चित करने के लिए किसी नए movement, या 1970s के free software movement की पुनर्समीक्षा, की ज़रूरत हो सकती है
  • Gitpod का Open-Source Sustainability Fund इस ecosystem fracture समस्या के प्रति एक प्रतिक्रिया के रूप में पेश किया गया है
    • 1.5 साल में open source community के language server tool maintainers को 32 हजार डॉलर से अधिक वितरित किए गए
  • Gitpod ने Visual Studio Code open source ecosystem की Marketplace समस्या को आंशिक रूप से हल करने के लिए Open VSX बनाया और उसे Eclipse Foundation को दान कर दिया
  • आगे की सबसे बड़ी चुनौती यह है कि जिन-जिन क्षेत्रों में Microsoft community को proprietary language servers की ओर ले गया है, वहाँ open language tools विकसित किए जाएँ

बाद के edits में जोड़ा गया

  • 31 अगस्त 2022 के edit में संक्षेप में कहा गया कि Microsoft ने VSCode बनाया, proprietary free distribution और proprietary free extensions दिए, और फिर language-specific best experience को closed-form VSCode से बाँध दिया
  • 16 दिसंबर 2022 के edit में जोड़ा गया कि GitLab का VSCode MIT-based Web IDE और remote development experience भी इसी समस्या से जूझता है
  • 13 अक्टूबर 2023 के edit में कहा गया कि Google का Project IDX भी VSCode MIT-based है, और .NET तथा Python में Visual Studio Code LSP के वैसे ही काम करने की उम्मीद न तो संभव है और न ही कानूनी
  • 24 अप्रैल 2025 के edit में आलोचना की गई कि Microsoft ने Windsurf और Cursor जैसे AI coding assistant competitors को दबाने के लिए जानबूझकर VSCode ecosystem को तोड़ा
    • उसी दिन Microsoft के competing product launch और C/C++ extension की VS Code forks तक पहुँच सीमित करने की बात को जोड़ा गया

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

5 टिप्पणियां

 
unsure4000 2024-09-30

मैं vim या zed इस्तेमाल करने के विकल्प पर विचार कर रहा हूँ।

मैं opacity सेट किए हुए टर्मिनल का इस्तेमाल कर रहा हूँ,
क्या आपको nvim की background color हटाने का तरीका पता है?
बस यही मिल जाए तो मैं nvim ज़रूर इस्तेमाल करके देखना चाहता हूँ...
 
siscof 2024-10-01

अगर आप kitty terminal इस्तेमाल कर रहे हैं, तो उसे वही background color देकर transparency लागू हो जाएगी.
नहीं तो ऐसे plugin पर भी विचार कर सकते हैं..

https://github.com/xiyaowong/transparent.nvim
 
unsure4000 2024-10-02

धन्यवाद। मैं एक बार देखूंगा।
 
unsure4000 2024-10-02

यह सफल रहा। धन्यवाद। आपका दिन शुभ हो।
 
GN⁺ 2024-09-30
Hacker News की राय

  • कुछ मायनों में यह स्थिति एक अवसर भी हो सकती है। VSCode ecosystem कई तरह से काफी कमजोर है
    cpptools में कुछ बेहतरीन बातें हैं, लेकिन यह अक्सर गड़बड़ करता है और असल में debugging लगभग नामुमकिन है; दूसरे extensions से भी बहुत बेहतर होने की उम्मीद करना मुश्किल है
    इससे बड़ा मुद्दा यह है कि security model बहुत कमजोर है: extensions sandboxed नहीं होते, और remote repositories तक पहुंचने वाले clients भी design के हिसाब से बहुत असुरक्षित हैं
    जब आप सिर्फ कंपनी का code देखते हैं, तो repository द्वारा खुद आप पर हमला करने की संभावना की चिंता कम हो सकती है, लेकिन malicious extensions की चिंता तो当然 करनी चाहिए, और हम development tools पर बहुत आसानी से भरोसा करने के आदी हो चुके हैं
    LLM पर कभी भरोसा नहीं करना चाहिए, और ऐसे LLM को, जो user पर हमला करने की कोशिश कर सकता है, repository में सीधे लिखने या VSCode के कुछ contexts में JS code चलाने का अधिकार देना सुरक्षित नहीं है
    बेहतर ecosystem में cpptools जैसा tool internet access के बिना होना चाहिए, इसलिए कोई telemetry भी न हो; उसे बस workspace पढ़ने, अपनी cache files बनाने और UI manipulate करने जितनी ही क्षमता होनी चाहिए

    • VSCode design के स्तर पर development environment की वास्तविक स्थिति को छिपा देता है, इसलिए जब फंसे हुए users की मदद की जाती है, तो अक्सर यह भी पता नहीं होता कि वे किस computer में logged in हैं, file filesystem में कहां है, कौन-सा Python interpreter इस्तेमाल हो रहा है, या HTTPS_PROXY किस पर set है
      SSH extension भी हर उस client के लिए server process चला देता है जिससे user connect करता है, और disconnect के बाद state preservation भी consistent नहीं दिखता
      आखिरकार VSCode इस्तेमाल करते हुए users ने जो समस्याएं खुद पैदा की हैं, उन्हें ठीक कराने में काफी समय लग जाता है
    • VSCode security model हमारी information security team के लिए भी बड़ी चिंता है
      Marketplace के सभी extensions को open access देने या उसे पूरी तरह lock down करके सिर्फ local files से extensions install कराने—इन दो विकल्पों के बीच कोई middle ground नहीं है
      दूसरा विकल्प VSCode maintenance पर काफी बोझ डालता है
    • अगर आपके पास compile_commands.json है या आप उसे generate कर सकते हैं, और खासकर CMake में यह अपेक्षाकृत आसान है, और आप clangd को इसे देखने दे सकते हैं, तो मेरे लिए clangd extension कहीं बेहतर रहा
    • अगर remote repositories तक पहुंचने वाला client design के हिसाब से बेहद असुरक्षित है, तो मैं जानना चाहूंगा कि third-party extension security के मामले में सबसे अच्छा editor कौन-सा है
      जो Emacs मैं इस्तेमाल करता हूं, उसमें भी supply-chain attacks रोकने के लिए खास व्यवस्था नहीं है, और ज्यादातर लोग community extension aggregators इस्तेमाल करते हैं जो सीधे Git repositories से चीजें लाते हैं
      हालांकि एक बहुत छोटा फायदा यह है कि Emacs users के किसी extension को लाते समय उसका source code सचमुच देखने की संभावना शायद काफी ज्यादा होती है
    • अगर यह सच है कि extensions sandboxed नहीं हैं, तो यह काफी चौंकाने वाला है
      Microsoft सालों से कहता आया है कि “security ही सब कुछ है और अभी सबसे अहम है”, फिर भी ऐसे users के लिए—जिन पर SSH keys जैसी चीजें चोरी होने का असर सबसे ज्यादा होगा और जो security को सबसे ज्यादा समझने वाले developers हैं—उन्होंने इतनी बुनियादी चीज भी नहीं संभाली, यह अजीब है
      लोग random extensions install करते हैं और Visual Studio Code “language support” के नाम पर मनमाने extensions recommend करता है—यह स्थिति सोचे से कहीं ज्यादा खराब लगती है

  • cpptools extension के बारे में एक अच्छी thread है: https://github.com/microsoft/vscode-cpptools/discussions/126...
    मैंने source से build करने की प्रक्रिया में गहराई से नहीं झांका, लेकिन इस post को देखकर लगता है कि यह बिल्कुल असंभव है
    शायद हमें यह बताने के लिए एक नया शब्द चाहिए कि कोई codebase OSS license में है या नहीं, और उसकी build dependencies भी OSS license में हैं या नहीं

    • यह वाकई गंभीर है। अगर बाद में Microsoft उस thread को दबा दे, तो भविष्य के लोग सोचेंगे कि हम आखिर किस बारे में बात कर रहे थे
    • Debian distribution को तीन components में बांटता है: main free software है, non-free non-free software है, और contrib ऐसा free software है जो main के बाहर के, आम तौर पर non-free software पर निर्भर करता है
      मुझे contrib शब्द खुद बहुत पसंद नहीं, लेकिन यह classification काफी उचित लगता है
    • इन छोटे-छोटे comments से ही बड़े ecosystem के सामने खड़ी समस्या साफ दिख जाती है, और यह सोचे से कहीं ज्यादा जल्दी और ज्यादा खराब हो सकती है
    • VSCode open source नहीं है, और यह extension भी open source नहीं है
      Windows पर बहुत-से F/OSS और macOS पर लगभग सभी F/OSS में MSVC, Xcode, Apple frameworks·GUI toolkits जैसी proprietary build dependencies होती हैं, फिर भी वे खुद F/OSS हो सकते हैं
      लेकिन यहां मामला वह नहीं है; यहां Microsoft के एक ऐसे कर्मचारी ने, जो maintainer लगता है, कहा कि “हमारा license वैकल्पिक VS Code distributions में extension इस्तेमाल करने को भी रोकता है, और इसे केवल Microsoft द्वारा बनाए official distribution में ही इस्तेमाल किया जा सकता है”
      यह सीधे-सीधे proprietary software है
      free software definition की freedom 0 है किसी भी उद्देश्य के लिए program चलाने की freedom, और अगर VSCode के third-party distributions को official distribution जैसे extension rights या compatible extensions के साथ इस्तेमाल करने का अधिकार नहीं है, तो code के कुछ हिस्सों के license से अलग, यह freedom 3 भी pass नहीं करता
      “अगर आप language server binary को अपनी offering के रूप में redistribute करना चाहते हैं, तो runtime license इसे रोकता है” का मतलब है कि यह open source definition की condition 1, यानी redistribution criteria, pass नहीं करता; और VSCode, जो modified redistributions को original जैसे rights नहीं देता, condition 3, derivative works criteria, भी pass नहीं करता
      VSCode और यह extension दोनों open source नहीं हैं; ये proprietary software हैं जिनमें कुछ open source components शामिल हैं
      free software definition: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
      open source definition: https://opensource.org/osd
      यह भी अहम है कि ये definitions सामान्य dictionary meanings नहीं हैं, बल्कि खास social और technical उद्देश्यों के साथ आंदोलनों के भीतर बनाए गए terms हैं
    • मेरी समझ के मुताबिक यह extension EDG से commercial license के तहत लिया गया proprietary C++ frontend इस्तेमाल करता है
      वही frontend Visual Studio IDE में भी शामिल है
      मुझे पता है कि विकल्प के रूप में clangd-based पूरी तरह open source C++ extension मौजूद है, लेकिन मैं गलत भी हो सकता हूं

  • “Microsoft जो मुफ्त में free software देता है, वह पर्याप्त खुला नहीं है” — यह बात आज के मानकों से भी काफी अजीब दावा लगती है
    पहले “free IDE” का मतलब Eclipse या ढेर सारे extensions वाला Vim होता था
    देखने में ऐसा लगता है कि Microsoft खुले विकल्पों को रोक नहीं रहा, बल्कि वे विकल्प बस कम अच्छे हैं; और जब आप ऐसी कंपनी का software इस्तेमाल करते हैं जिसे कर्मचारियों को वेतन भी देना है और मुनाफा भी कमाना है, तो इसमें ऐसी बातें स्वाभाविक हैं
    जिन्हें लगता है कि उन्हें Microsoft के सबसे अच्छे software का source code मिलना ही चाहिए, वे देख लें कि किसी स्वतंत्र non-profit द्वारा maintain किया गया असली open source कैसा दिखता है
    वह काम तो करेगा और शायद उसमें सचमुच debugger भी होगा, लेकिन बहुत संभव है कि ज्यादा देर नहीं लगेगी और आप वापस लौटना चाहेंगे
    लोग मुफ्त मिले software को बहुत ज्यादा हल्के में ले रहे हैं। बहुत समय पहले की बात नहीं है जब IDE के लिए सैकड़ों से हजारों डॉलर देने पड़ते थे, और कुछ साल बाद नया version चाहिए होता तो upgrade fee भी देनी पड़ती थी

    • यह कहना मुश्किल है कि Microsoft खुले विकल्पों को नहीं रोकता
      VSIX extensions कुछ हद तक open standard होने चाहिए, लेकिन Pylance जैसे Microsoft extensions अगर detect करें कि वे Microsoft build नहीं, बल्कि किसी और VS Code में चल रहे हैं, तो वे सक्रिय रूप से काम करने से इनकार कर देते हैं
    • “Microsoft जो मुफ्त में free software देता है, वह पर्याप्त खुला नहीं है” — यह न तो लेख का quote है और न ही लेख का दावा
      मुख्य बात इससे ज्यादा इस ओर है कि developers को धोखा दिया जा रहा है और Microsoft का लक्ष्य जरूरी हिस्सों को बंद करते जाना है
    • Asahi Linux project को देखें तो बात मिलती-जुलती है। वे शानदार काम कर रहे हैं, लेकिन 3 साल पुराने laptop के साथ basic feature parity लाने का काम भी अभी जारी है
      feature parity पूरी हो भी जाए तो अगला मुद्दा performance का रहेगा, और वह कब हल होगा, पता नहीं
      open source software का विचार अच्छा है, लेकिन आज का सबसे अच्छा software लगभग हमेशा पैसे देकर ही मिलता है
    • मेरी समस्या यह है कि मुझे Microsoft की बड़ी योजना नहीं पता
      Emacs और Vim इस्तेमाल करने की कीमत मुझे पता है। सिद्धांत रूप में वे पूरी तरह मुफ्त हों, फिर भी असल में समय, धैर्य और समर्पण की लागत है, और मुझे पता है कि मेरे चुनाव से मुझे, community को और industry को फायदा होता है
      पहले जब मैं IntelliJ इस्तेमाल करता था, तब भी मुझे ठीक-ठीक पता था कि JetBrains कैसे कमाई करता है। मैं license fee देता था और हर साल renew करता था
      लेकिन Microsoft का हिसाब क्या है? वह इतना सुंदर और अच्छा tool पूरी तरह “free” दे रहा है, तो भविष्य में मुझे इसकी क्या कीमत चुकानी पड़ेगी?
      जर्मनी की GDP के बराबर market cap वाली विशाल कंपनी केवल developers से प्यार के कारण भारी संसाधन लगाकर “free” code editor बनाती है — यह मानना मुश्किल है, और developers को कम-से-कम थोड़ा संदेह तो रखना ही चाहिए
    • “Microsoft का सबसे अच्छा software” सुनने में मजाक जैसा लगता है
      मुझे Microsoft software किसी डरावने कचरे के ढेर जैसा ज्यादा लगता है
      लेख का point यह है कि closed source software जब open source होने का ढोंग करता है, तो उसका असर उन लोगों पर भी पड़ता है जो उसे इस्तेमाल नहीं करना चाहते, लेकिन यह बात छूट रही है
      उदाहरण के लिए, मैं Azure DevOps हो या GitHub Actions, किसी का भी इस्तेमाल नहीं करना चाहता, लेकिन जिस संगठन में मैं काम करता हूं उसे project GitHub पर डालना पड़ता है, इसलिए मुझे मजबूरन इस्तेमाल करना पड़ता है
      नतीजा यह है कि मेरी मेहनत और जानकारी Microsoft द्वारा users के शोषण में लग रही है, ऐसा महसूस होता है
      एकमात्र सांत्वना यह है कि यह paid work है; निजी तौर पर मैं GitHub इस्तेमाल नहीं करता और दूसरों को भी यही सलाह दूंगा

  • अगर आप यह model नहीं बताते कि VS Code बनाने वाले 50 से ज्यादा full-time कर्मचारियों के लिए सालाना करीब 20 million dollar का budget कैसे justify होगा, तो यह आलोचना ऐसी लगती है: “उनकी engineering उपलब्धि को हमारी कंपनी उठाकर product की सतह भर बदल दे, और अपनी development cost के बिना सस्ता बेचकर मुनाफा कमाए — इसे थोड़ा मुश्किल बना दिया, यह झुंझलाहट की बात है”

    • Microsoft का अपने कई divisions के internal use के लिए अपना IDE बनाना, और flexible modern tool के लिए budget लगाना समझ में आता है
      इसे open source के रूप में जारी करने से दूसरी communities का trust मिलता है, मुफ्त code और bug checking मिलती है, Microsoft ecosystem के बाहर extensions लिखने और support करने वाले लोग भी मिलते हैं, और Microsoft भी इसका इस्तेमाल जारी रख सकता है
      यह इतना जटिल मुद्दा नहीं लगता
    • वह मेरी समस्या नहीं है। मेरी समस्या यह है कि मेरी job skills Microsoft की लगातार सदाशयता पर निर्भर न हो जाएं
      इतिहास में यह obsolete होने की guaranteed राह रही है
      उनकी engineering उपलब्धियों के बिना भी Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox वगैरह हैं
      Microsoft का उदार blanket gift मुझे तभी दिलचस्प लगता है जब उसके साथ smallpox न आया हो
    • उनका business model खराब है या नहीं, यह मेरी चिंता नहीं है। वे गलत फैसलों का फायदा उठाए जाने वाले गरीब बच्चे नहीं हैं
      बस इसे किसी बड़ी हैरानी की तरह report करना थोड़ा हास्यास्पद है। यह शुरू से साफ था, बस लड़ने लायक नहीं लगा इसलिए ध्यान नहीं दिया
      BSD/MIT license वाले developers के शोषण का मुद्दा उतनी ही कम दिलचस्पी का है जितनी यह चिंता कि telemetry बंद करने से Microsoft का business model हिल सकता है
      सबने “बड़ी tech company का senior हमें पहचान देगा” सोचकर, जानते-बूझते चुना कि वे किसमें जा रहे हैं, और सच में पहचान मिल गई, तो बधाई
      मैं AGPL से कमजोर license में कुछ भी upload नहीं करूंगा, लेकिन आखिरकार software से कहीं ज्यादा जरूरी चीजें भी हैं

  • अभी भी यह समझने की कोशिश कर रहा हूँ कि समस्या आखिर है क्या
    ऐसा लगता है कि मतलब यह है कि Microsoft बेहतर cpptools/C++ extension बना रहा है, लेकिन Microsoft के कई components बंद हैं, इसलिए पूरी तरह OSS version build नहीं किया जा सकता
    और जब users को पता चलता है कि वे किसी भी web interface में native extensions इस्तेमाल नहीं कर सकते, तो क्या वह web interface वालों की समस्या बन जाती है, ऐसा लगता है
    अगर लोग OSS के बजाय freeware इस्तेमाल करना चाहते हैं, तो यह निराशाजनक हो सकता है, लेकिन सच में समस्या है या नहीं, पता नहीं
    अगर कोई जवाब है, तो शायद यह ज्यादा साफ़ बताने में है कि जिम्मेदार कौन होना चाहिए
    open-source vendors को developers को ज्यादा स्पष्ट रूप से बताना चाहिए कि उनकी offerings open-source हैं और एक खुले ecosystem का हिस्सा हैं, कि सभी extensions ऐसे नहीं होते, और Microsoft का alternative extension ऐसा नहीं है
    अगर प्रमुख extension projects एकमत हो जाएँ, तो marketplace descriptions में ऐसा नोट लगाया जा सकता है कि vscode-cpptools OSI-approved license नहीं है, उसमें कई बिना review किए हुए binary blobs हैं, और Microsoft native open-source builds या web services के लिए VSCode उपलब्ध कराने में redistribution की अनुमति नहीं देता
    कानूनी और सांस्कृतिक दोनों लिहाज से Microsoft शायद सिर्फ इसलिए कुछ OSS projects की marketplace access रोकना नहीं चाहेगा कि उन्होंने अपनी license terms की तुलना Microsoft की terms से की
    Apple भी अभी marketplace lawsuit झेल रहा है, और Microsoft marketplace या किसी और antitrust lawsuit को नहीं चाहेगा

    • एक आसान उदाहरण लें: एक public function वाला API बनाइए और उस API को closed-source license वाले binary में compile कर दीजिए
      फिर एक दूसरा API बनाइए जिसमें एक public function हो, और वह function बस उस library binary को extern call करे
      दूसरे API को GitHub पर MIT license के साथ डाल दीजिए और उसे open-source घोषित कर दीजिए
      व्यापक रूप से सवाल यह है कि अगर software की functionality का 100% closed-source compiled binary के अंदर है, तो क्या उसे open-source कहना false advertising माना जाना चाहिए
      दूसरे शब्दों में, जब कोई शोषणकारी वजहों से open-source की मंशा से आगे निकल जाता है, तो रेखा कौन खींचता है, यही मुद्दा है
      मुझे नहीं पता cpptools की functionality 100% बंद है या नहीं, लेकिन असल में MIT license बताए गए repository के अंदर तीन और licenses हैं जिनसे सहमत होना पड़ता है

  • असली मुद्दा क्या है, यह समझने के लिए बहुत ज्यादा पढ़ना पड़ता है, और “fragmented ecosystem” की अवधारणा बिना explanation के कई बार आती है
    “fragment करने के लिए designed Venus flytrap” जैसे expressions का आखिर मतलब क्या है, समझ नहीं आता
    VS Code Microsoft से free में download करके इस्तेमाल किया जा सकने वाला IDE है; यह कोई जादुई open-source platform या ecosystem नहीं है जिसे Microsoft control नहीं करता, बल्कि एक product है
    लगता है हर कोई “universal” developer services बनाना चाहता है, लेकिन IDE बनाना या उसे fund करना नहीं चाहता, या फिर यह बहुत मुश्किल है
    यह Microsoft की गलती नहीं है

  • Microsoft का बचाव करने की कोशिश नहीं है, लेकिन उसने एक विशाल codebase free में दिया और उसके ऊपर ज्यादातर free product बनाया
    fork करने पर बस Microsoft servers तक access नहीं मिलता, और मुझे लगता है कि यह काफी fair है
    और Monaco बहुत अच्छा editor है, इसलिए frontends उसे इस्तेमाल करते हैं। पहले जब CodeMirror या Ace सबसे अच्छे विकल्प थे, तो वही लगाए जाते थे
    Monaco बनाने के पीछे कोई विशाल masterplan था, ऐसा कम लगता है; ज्यादा ऐसा लगता है कि उन्होंने यह अवसर देखा कि इसे independent project बनाने से अनगिनत web UIs संभव हो सकती हैं

  • यह बहुत बड़ी समस्या है कि “भविष्य में बनने वाले software development tools का future पूरी तरह बंद है, लेकिन कुछ components OSI definition पूरी करते हैं, इसलिए लोग big picture छोड़कर इसे ठीक मान लेते हैं”
    खासकर VC-funded कई companies open-source शब्द को बहुत ढीले तौर पर इस्तेमाल कर रही हैं और भाषा, अर्थ, और open-source movement की spirit तक को खराब दिशा में बदल रही हैं
    YC भी ऐसी कई companies को support कर रहा है जो open-source होने का दावा करती हैं, लेकिन उसकी spirit का बिल्कुल पालन नहीं करतीं

    • समस्या यह नहीं है कि companies ऐसा करती हैं, बल्कि यह है कि users और developers ज्यादा परवाह नहीं करते या ऐसी चिंताएँ share नहीं करते
      spirit या ethics जैसी moral arguments उतनी relevant नहीं हैं
      महत्वपूर्ण बात यह है कि software licenses legal documents होते हैं, और उनकी interpretation जहाँ मायने रखती है वह अदालत है
      VS Code से जुड़े lawsuits ज्यादा नहीं दिखते, और Microsoft आम तौर पर उस हिस्से को काफी हद तक व्यवस्थित रखता है
      कानूनी अर्थ में VS Code काफी safe दिखता है। यह सही है कि कुछ extensions OSS license वाले नहीं हैं या पूरी तरह closed-source हैं, लेकिन अगर यह पसंद नहीं है तो उन्हें इस्तेमाल न करें
      उससे आगे, खुद open-source बनाकर उसे ठीक कर सकते हैं। open-source कोई अधिकार नहीं, बल्कि creator के discretion पर दी जाने वाली privilege है; इसे मांग कर नहीं लिया जा सकता
      VS Code एक closed-source product है जिसमें कई OSS components शामिल हैं, और ऐसे components इतने ज्यादा हैं कि पूरी तरह OSS VS Codium भी मौजूद है
      उन OSS components में से कई दूसरे products में भी इस्तेमाल होते हैं, और कुछ पूरी तरह open-source हैं
      VS Code ecosystem की value इसी में है कि यह ऐसे components और product ecosystem को फलने-फूलने देता है

  • किसी को भी VS Code मुफ्त में पाने का अधिकार नहीं है। सच कहें तो किसी भी चीज़ को मुफ्त में पाने का अधिकार नहीं है
    विकल्प है फूले हुए commercial IDE के लिए पैसे देना
    VS Code ठीक-ठाक है, general-purpose है, मुफ्त है, और इतना खुला है कि इसे fork किया जा सके
    लोग भूल जाते हैं कि यह engineering के लिहाज़ से एक कमाल की चीज़ है। code में झांककर देखें तो यह मुफ्त में मिलने लायक स्तर की चीज़ नहीं है
    Microsoft हो या कोई और कंपनी, किसी पर भी किसी को मुफ्त में कुछ देने का कर्ज़ नहीं है, और इस तरह की अधिकार-भावना पर नियंत्रण जरूरी है

    • सही है, बेहतर तो यह होगा कि इस पर price tag लगा दें। यहां के लोग भी VSCode से काफी उपयोगिता पाते हैं, इसलिए पैसे देंगे
      समस्या तब होती है जब मुफ्त पेशकश असल में आपको कानूनी जिम्मेदारियों और बिना ऊपरी सीमा वाली वित्तीय जिम्मेदारियों के दलदल में फंसाने के लिए design की गई हो
      खासकर VSCode जैसी service में, जहां यह one-time purchase नहीं है और extensions व updates के जरिए Microsoft पर लगातार निर्भर रहना पड़ता है; और असल में इसे ऐसे ही design किया गया है
      एक बार साफ-सुथरा payment करके बात खत्म करने वाला आसान विकल्प बनाने के बजाय, उन्होंने user के resistance के स्तर के हिसाब से लंबे समय में अस्पष्ट रकम निकालने का रास्ता चुना है
    • JetBrains products में value थी, इसलिए मैंने कई साल तक पैसे दिए। Eclipse की functionality से तुलना करें तो वे काफी आगे थे, और उसके लिए पैसे देना बनता था
      open source के बारे में भी मैं हमेशा कहता हूं कि जिसके पीछे बड़ा पैसा न हो, ऐसे framework को अपनाने को लेकर मैं skeptical रहता हूं
      किसी random internet genius engineer की सनक पर निर्भर रहना जोखिम भरा है
      Microsoft VSCode से पैसा कमाएगा। बस यह उतना direct नहीं होगा जितना Google Chrome से पैसा कमाता है
    • क्या यह वाकई engineering के लिहाज़ से कमाल है? फूली हुई browser technology और ऐसे language से, जो जैसे napkin पर design की गई हो, किसी तरह काम चलाऊ IDE बनाना मुझे उतना ही “impressive” लगता है जितना ice-cream sticks और chewing gum से एक मील लंबा pedestrian bridge बनाना

  • मुझे लगता है OSS शानदार है, लेकिन मैं VS Code इसलिए इस्तेमाल नहीं करता
    मैं इसे इसलिए इस्तेमाल करता हूं क्योंकि इसने मेरी यह समस्या हल की कि मुझे Eclipse जैसे राक्षस के बजाय एक usable editor चाहिए था
    इस क्षेत्र में Sublime जैसे दूसरे विकल्प भी हैं, लेकिन VS Code हमेशा सबसे कम बाधा डालने वाला लगा
    पहले इसी तरह का Adobe Brackets भी था, लेकिन न जाने क्यों वह बहुत धीमा और bug-heavy था
    अगर आप OSS enthusiast हैं तो लेख की बातें सही हैं। लेकिन आखिरकार source code मौजूद है, और चाहें तो आप अपना marketplace भी चला सकते हैं
    इसमें समय और पैसा लगेगा, लेकिन अगर आप उस idea में विश्वास करते हैं तो किसी बड़ी कंपनी पर निर्भर रहने के बजाय invest करना चाहिए
    अगर कोई proprietary extension है जो आपको नहीं मिल सकता, तो अफसोस है, लेकिन कोई उसका OSS version बना सकता है
    कुल मिलाकर मैं लेख से सहमत हूं, लेकिन मुझे यह भ्रम नहीं है कि Microsoft open source में आस्था के कारण ऐसा कर रहा है, और सबसे खराब स्थिति में भी दूसरे विकल्प मौजूद हैं, इसलिए ठीक है