Cacat Desain Visual Studio Code (2022)

• Visual Studio Code memisahkan kode sumber berlisensi MIT dari produk berlisensi proprietary yang didistribusikan Microsoft, sehingga fork seperti VSCodium dan OpenVSCode Server berbenturan dengan ekosistem resmi
• Build resmi didistribusikan dengan memasukkan konfigurasi khusus Microsoft seperti telemetri, gallery, logo ke product.json, sementara build komunitas menjadi build “clean” tetapi tidak dapat terhubung ke Visual Studio Code Marketplace
• VSCodium dan OpenVSCode Server menghapus atau tidak menyertakan telemetri dari rilis resmi, tetapi karena pengumpulan data oleh ekstensi itu sendiri dan pembatasan akses Marketplace, sulit memberikan pengalaman VS Code persis seperti yang diharapkan pengguna
• Ketika ekstensi dan language server Microsoft, seperti Pylance, roadmap ekstensi C#, dan lisensi alat C/C++, diikat ke produk dan layanan resmi, layanan pesaing seperti Gitpod, GitLab, Datacoves, OpenBB, dan Foam sulit menyediakan fungsi yang sama secara legal
• OpenVSX, pengembangan alat bahasa terbuka, dan dukungan bagi maintainer open source disebut sebagai alternatif, tetapi ketika Microsoft mengubah default ke alat proprietary, komunitas dan produk pesaing harus menanggung bersama kesenjangan fitur, perbedaan konfigurasi, dan batasan hukum

---

Kode sumbernya terbuka, tetapi produknya didistribusikan secara berbeda

• Tujuh tahun setelah dirilis, Visual Studio Code telah menjadi editor standar de facto dalam pengembangan perangkat lunak
• Microsoft membuka kode sumber Visual Studio Code di bawah lisensi MIT, tetapi produk Visual Studio Code yang diunduh pengguna didistribusikan dengan lisensi proprietary terpisah
• Menurut penjelasan maintainer Visual Studio Code, build Microsoft dibuat dengan meng-clone repositori vscode, lalu menimpa product.json khusus Microsoft
  • File ini berisi fitur khusus Microsoft seperti telemetri, gallery, dan logo
  • Build yang dibuat dengan cara ini didistribusikan di bawah lisensi Microsoft
• Kritik utama tulisan ini adalah bahwa pemisahan tersebut merupakan mekanisme inti yang digunakan Microsoft untuk memecah komunitas open source

Batasan yang dihadapi VSCodium dan OpenVSCode Server

• VSCodium adalah distribusi desktop berlisensi bebas yang digerakkan komunitas
  • Secara otomatis mengikuti proyek upstream MIT dan membuat build biner
  • Menyediakan build yang menghapus telemetri yang ada pada rilis resmi
  • Karena endpoint Microsoft tidak diatur dalam product.json default, build “clean” tanpa kustomisasi Microsoft dihasilkan
• VSCodium, yang memakai basis kode yang sama, juga tidak dapat sepenuhnya memblokir semua pengumpulan data
  • Ekstensi dapat mengumpulkan data secara independen, sehingga pengguna perlu berhati-hati terhadap ekstensi yang dipasang
• OpenVSCode Server adalah distribusi server berlisensi bebas yang menjadi fondasi Gitpod
  • Secara otomatis mengikuti proyek upstream MIT
  • Ada sebagian kustomisasi overlay pada branch gp-code/main
  • Telemetri dari rilis resmi tidak disertakan
• Kedua distribusi tersebut tidak dapat terhubung ke Microsoft Visual Studio Code Marketplace, dan pembatasan ini menyebabkan terputusnya ekosistem

Pergeseran Microsoft ke layanan dan strategi alat pengembangan

• Sekitar 9 tahun lalu, Microsoft mulai mengubah cara penyediaan perangkat lunaknya
  • Beralih dari cara kerja tim QA khusus yang menguji build ke pengembangan berbasis sprint, rolling release, dan pendekatan berbasis umpan balik telemetri Insider Build
• Pada periode yang sama, melalui reorganisasi, Microsoft bertransformasi menjadi perusahaan layanan
  • Selama periode ini, Azure tumbuh menjadi pesaing nyata AWS
• Dari sudut pandang konsumen, perubahan terbesar adalah pergeseran basis pelanggan dari produk on-premise yang diinstal ke model konsumsi layanan yang disediakan Microsoft
• Di ranah alat pengembangan, IDE yang bukan berbasis langganan diperlakukan sebagai tren yang menyusut
  • Kasus seperti Xcode milik Apple, yang memiliki sumber pendapatan lain, disebut sebagai pengecualian
• Visual Studio Code dikritik sebagai pintu masuk untuk memindahkan ekosistem alat pengembangan ke model layanan konsumsi end-to-end
  • GitHub Codespaces dijelaskan sebagai white label dari layanan yang sudah ada dan terhubung dengan Visual Studio Online, Microsoft Dev Box, dan Microsoft Azure DevTest Labs

GitHub Codespaces dan Microsoft DevDiv

• Microsoft mengakuisisi GitHub pada 2018 dan memperkenalkan Visual Studio Online pada 2019
  • Di dalamnya terdapat komponen untuk meng-host “codespace” secara lokal
  • Setelah itu, elemen terkait, termasuk tim Codespaces, dipindahkan ke GitHub
• GitHub Codespaces dijelaskan sebagai proyek DevDiv yang menjadi bagian dari GitHub
• Pada hari Nat Friedman mundur dari posisi CEO, email reorganisasi internal Microsoft dibagikan
  • Julia Liuson dipromosikan menjadi presiden Microsoft Developer Division
  • Struktur pelaporan membuat CEO GitHub Thomas Dohmke melapor kepada Julia Liuson
  • Developer Division mencakup 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, dan lainnya
• Menurut email tersebut, Visual Studio dan Visual Studio Code mencatat pertumbuhan penggunaan lebih dari 16 kali lipat sejak 2014
• Julia Liuson disebut sebagai sosok yang menjalankan perubahan menit terakhir yang memecah komunitas .NET sebelum promosinya
  • Menurut kutipan The Verge, sumber anonim internal Microsoft melihat perubahan ini sebagai keputusan yang berorientasi bisnis

Struktur ekosistem yang bekerja sebagai “keterputusan yang dirancang”

• Produk pesaing seperti Gitpod dapat berada di dalam ekosistem Visual Studio Code, tetapi dikritik karena Microsoft dapat kapan saja menciptakan risiko hukum untuk membagi pasar
• Kode sumber open source Visual Studio Code menarik pengguna, tetapi membuat layanan pesaing sulit menyediakan pengalaman mulus seperti Visual Studio Code resmi atau GitHub Codespaces
• Bukan hanya Gitpod, perusahaan seperti GitLab, Datacoves, OpenBB, dan Foam yang ingin bersaing dengan Microsoft atau GitHub berbasis kode sumber VS Code juga menghadapi masalah yang sama
• Jika bergantung pada alat Microsoft, area berikut disebut sebagai wilayah yang sulit disediakan secara legal oleh layanan pesaing
  • Microsoft .NET C#
  • Pasar Python tujuan umum dan data science
  • Project Jupyter dan sebagian besar pasar data science
  • C atau C++
  • Java diperkirakan dapat menjadi target berikutnya jika alat Microsoft mendekati level alat RedHat
• Berdasarkan indeks TIOBE, 5 dari bahasa dan ekosistem di atas termasuk poros paling populer, dan Microsoft dijelaskan memiliki tingkat kontrol yang mendekati JavaScript, bahasa ke-7 paling populer, melalui TypeScript

Peralihan default dan masalah ekstensi proprietary

• Microsoft dikritik karena, setelah memperoleh adopsi yang cukup, mereka dapat menjadikan penawaran proprietary sebagai default melalui pembaruan ekstensi
• Di komunitas Python, Microsoft Python Language Server yang open source dihentikan dan Pylance yang proprietary menjadi default
  • Menurut kutipan Visual Studio Magazine, Microsoft tidak memaksa pengguna untuk beralih, tetapi menetapkan Pylance sebagai default baru
  • Ekstensi Python mencatat sekitar 50 juta unduhan di VS Code Marketplace, dan disebut sekitar 2 kali lebih banyak dibanding ekstensi Jupyter yang paling populer berikutnya
• Di komunitas .NET, roadmap ekstensi C# juga disajikan sebagai contoh peralihan default serupa yang sedang berlangsung
• Sekalipun alat alternatif seperti Open.NET dibuat, pengguna harus menautkan konfigurasi berbeda per platform
  • Di desktop, ms-dotnettools.csharp dapat dimasukkan ke devcontainer.json
  • Di Gitpod, akan muncul perbedaan seperti harus memasukkan alat terbuka yang belum ada ke gitpod.yml
• Di dalam ekosistem resmi Microsoft, konfigurasi devcontainer.json yang sama menjadi sumber konfigurasi tunggal yang berfungsi apa adanya di Visual Studio Code desktop dan GitHub Codespaces

Batasan hukum yang diciptakan lisensi

• Diperingatkan bahwa jika Gitpod, GitLab, Datacoves, OpenBB, Foam, dan lainnya mengakali pembatasan lalu menyediakan ekstensi Microsoft seperti ms-dotnettools.csharp di layanan mereka, mereka dapat menghadapi tindakan hukum kuat dari tim legal Microsoft
• Bahkan jika pengguna lingkungan pengembangan cloud pesaing memasang ekstensi tersebut secara manual, itu dapat menjadi pelanggaran lisensi
• Teks lisensi ekstensi Microsoft C/C++ menyatakan bahwa perangkat lunak hanya boleh dipasang dan digunakan bersama Microsoft Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps, Team Foundation Server, serta produk dan layanan Microsoft penerusnya
• Karena syarat ini, produk berbasis VS Code yang bukan distribusi resmi Microsoft sulit menyediakan alat bahasa Microsoft yang diharapkan pengguna secara apa adanya

Arah respons: OpenVSX dan alat bahasa terbuka

• Ada kritik bahwa masa depan alat pengembangan perangkat lunak yang sedang dibangun bergerak ke arah tertutup
  • Meski sebagian komponennya memenuhi definisi OSI, keseluruhan graph konfigurasinya belum tentu demikian
• Open source pada awalnya dijelaskan sebagai senjata finansial untuk menahan perangkat lunak on-premise proprietary dan menjaga keterbukaan format file
  • Pada saat yang sama, hal ini juga terkait dengan alasan mengapa sulit menghasilkan uang dari open source
• Diusulkan bahwa mungkin diperlukan gerakan baru untuk menjamin keterbukaan kebebasan komputasi melawan proprietary SaaS, atau peninjauan kembali gerakan perangkat lunak bebas era 1970-an
• Open-Source Sustainability Fund milik Gitpod adalah salah satu respons terhadap masalah keterputusan ekosistem ini
  • Selama 1,5 tahun, lebih dari 32 ribu dolar AS telah didistribusikan kepada maintainer alat language server di komunitas open source
• Gitpod membuat Open VSX dan menyumbangkannya ke Eclipse Foundation untuk sebagian menyelesaikan masalah Marketplace dalam ekosistem open source Visual Studio Code
• Tantangan terbesar ke depan adalah mengembangkan alat bahasa terbuka untuk setiap area tempat Microsoft memindahkan komunitas ke language server proprietary

Konten yang ditambahkan melalui suntingan berikutnya

• Suntingan 31 Agustus 2022 merangkum bahwa Microsoft membuat VSCode, menyediakan distribusi gratis proprietary dan ekstensi gratis proprietary, lalu mengikat pengalaman terbaik per bahasa ke VSCode dalam bentuk tertutup
• Suntingan 16 Desember 2022 menambahkan bahwa Web IDE berbasis VSCode MIT milik GitLab dan pengalaman remote development-nya juga menghadapi masalah yang sama
• Suntingan 13 Oktober 2023 menyatakan bahwa Project IDX milik Google juga berbasis VSCode MIT, dan ekspektasi bahwa Visual Studio Code LSP akan berjalan begitu saja pada .NET dan Python tidak mungkin serta tidak legal
• Suntingan 24 April 2025 mengkritik bahwa Microsoft sengaja merusak ekosistem VSCode untuk menekan persaingan asisten coding AI seperti Windsurf dan Cursor
  • Pada hari yang sama, disebutkan pula kaitan antara peluncuran produk pesaing Microsoft dan pembatasan akses fork VS Code terhadap ekstensi C/C++

[unsure4000]

Saya sedang mempertimbangkan untuk memakai vim atau zed.

Saya menggunakan terminal dengan opacity yang diatur,
apakah Anda tahu cara menghilangkan warna latar belakang di nvim?
Kalau hanya ini yang bisa saya temukan, saya benar-benar ingin mencoba nvim...

[siscof]

Jika Anda menggunakan terminal kitty, kemungkinan transparansi akan diterapkan jika diatur dengan warna latar yang sama.
Atau Anda juga bisa mempertimbangkan plugin seperti ini..

https://github.com/xiyaowong/transparent.nvim

[unsure4000]

Terima kasih. Saya akan mencobanya.

[unsure4000]

Berhasil. Terima kasih. Semoga harimu menyenangkan.

[GN⁺]

Opini Hacker News

• Dalam beberapa hal, situasi ini bisa menjadi peluang. Ekosistem VSCode cukup rapuh dalam banyak aspek
  cpptools memang punya sisi yang hebat, tetapi sering bermasalah dan praktis tidak bisa di-debug; sulit berharap ekstensi lain jauh lebih baik
  Masalah yang lebih besar adalah model keamanannya sangat lemah: ekstensi tidak di-sandbox, dan klien yang mengakses repositori jarak jauh juga sangat tidak aman secara desain
  Saat hanya melihat kode perusahaan sendiri, kekhawatiran bahwa repositori akan menyerang kita mungkin lebih kecil, tetapi ekstensi berbahaya tentu harus dikhawatirkan, dan kita sudah terbiasa terlalu mudah mempercayai alat pengembangan
  LLM sama sekali tidak boleh dipercaya, dan tidak aman memberi LLM yang mungkin mencoba menyerang pengguna hak untuk menulis langsung ke repositori atau menjalankan kode JS dalam sebagian konteks VSCode
  Dalam ekosistem yang lebih baik, alat seperti cpptools seharusnya tidak punya akses internet sehingga tidak ada telemetri, dan hanya boleh membaca workspace, membuat file cache miliknya sendiri, serta memanipulasi UI

  • Secara desain, VSCode menyembunyikan keadaan nyata lingkungan pengembangan, sehingga ketika membantu pengguna yang buntu, sering kali kita bahkan tidak tahu mereka login ke komputer mana, file berada di mana dalam filesystem, interpreter Python apa yang dipakai, atau HTTPS_PROXY disetel ke apa
    Ekstensi SSH juga menjalankan proses server untuk setiap klien yang tersambung, dan pelestarian status setelah koneksi terputus tampaknya tidak konsisten
    Pada akhirnya, banyak waktu habis untuk membantu orang memperbaiki masalah yang mereka ciptakan sendiri dengan memakai VSCode
  • Model keamanan VSCode juga menjadi kekhawatiran besar bagi tim keamanan informasi kami
    Tidak ada wilayah tengah di antara dua pilihan: mengizinkan akses terbuka ke semua ekstensi di Marketplace, atau menguncinya sepenuhnya dan hanya mengizinkan pemasangan ekstensi dari file lokal
    Opsi terakhir memberi beban yang cukup besar untuk pemeliharaan VSCode
  • Jika Anda punya atau bisa membuat compile_commands.json, terutama di CMake yang relatif mudah, dan bisa membuat clangd melihatnya, ekstensi clangd jauh lebih baik bagi saya
  • Jika klien yang mengakses repositori jarak jauh secara desain sangat tidak aman, saya penasaran editor mana yang terbaik dalam hal keamanan ekstensi pihak ketiga
    Emacs yang saya pakai juga tidak punya banyak mekanisme untuk mencegah serangan rantai pasok, dan kebanyakan orang memakai agregator ekstensi komunitas yang mengambil langsung dari repositori Git
    Namun ada sedikit kelebihan: rasanya persentase pengguna Emacs yang benar-benar melihat kode sumber ekstensi yang mereka ambil jauh lebih tinggi
  • Kalau benar ekstensi tidak di-sandbox, itu cukup mengejutkan
    Microsoft selama bertahun-tahun berkata “keamanan adalah segalanya dan hal paling penting saat ini”, jadi aneh jika mereka bahkan tidak mengurus hal mendasar seperti itu untuk kelompok pengguna yang dampaknya paling besar saat hal seperti kunci SSH dicuri, sekaligus kelompok developer yang seharusnya paling sadar keamanan
    Situasi ketika orang memasang ekstensi secara acak dan Visual Studio Code merekomendasikan ekstensi sembarang atas nama “dukungan bahasa” tampak jauh lebih buruk daripada yang dibayangkan

• Ada thread bagus terkait ekstensi cpptools: https://github.com/microsoft/vscode-cpptools/discussions/126...
  Saya belum menggali proses build dari source secara mendalam, tetapi dari tulisan ini tampaknya itu sama sekali tidak mungkin
  Sepertinya kita akan membutuhkan istilah baru untuk menyatakan apakah suatu codebase berlisensi OSS, dan apakah dependensi build-nya juga berlisensi OSS

  • Ini benar-benar serius. Kalau nanti Microsoft mengubur thread itu, orang-orang di masa depan akan bertanya-tanya apa yang sedang kita bicarakan
  • Debian membagi distribusinya menjadi tiga komponen: main adalah perangkat lunak bebas, non-free adalah perangkat lunak tidak bebas, dan contrib adalah perangkat lunak bebas tetapi bergantung pada sesuatu di luar main, biasanya perangkat lunak tidak bebas
    Saya tidak terlalu suka istilah contrib itu sendiri, tetapi klasifikasi ini terlihat cukup masuk akal
  • Hanya dari beberapa komentar kecil ini saja sudah terlihat persis masalah yang dihadapi ekosistem yang lebih besar, dan besar kemungkinan masalah itu akan menjadi jauh lebih buruk jauh lebih cepat daripada yang kita kira
  • VSCode bukan open source, dan ekstensi ini juga bukan open source
    Banyak F/OSS di Windows dan hampir semua F/OSS di macOS memiliki dependensi build proprietari seperti MSVC, Xcode, framework Apple, atau toolkit GUI, tetapi perangkat lunak itu sendiri tetap bisa F/OSS
    Namun dalam kasus ini masalahnya bukan itu; seorang karyawan Microsoft yang tampaknya maintainer mengatakan, “lisensi kami juga melarang penggunaan ekstensi di distribusi VS Code alternatif, dan hanya boleh digunakan di distribusi resmi yang dibuat Microsoft”
    Ini hanyalah perangkat lunak proprietari
    Kebebasan 0 dalam definisi perangkat lunak bebas adalah kebebasan menjalankan program untuk tujuan apa pun yang diinginkan, dan jika distribusi pihak ketiga VSCode tidak memiliki hak ekstensi yang sama dengan distribusi resmi atau hak untuk dipakai bersama ekstensi yang kompatibel, maka terlepas dari lisensi sebagian kodenya, ia juga tidak lolos kebebasan 3
    Pernyataan “jika yang ingin Anda lakukan adalah mendistribusikan ulang binary language server sebagai penawaran Anda sendiri, lisensi runtime melarangnya” berarti ia tidak lolos syarat 1 dalam Definisi Open Source, yaitu kriteria redistribusi; dan VSCode yang tidak mengizinkan distribusi ulang hasil modifikasi memiliki hak yang sama seperti aslinya juga tidak lolos syarat 3, yaitu kriteria karya turunan
    VSCode dan ekstensi ini keduanya bukan open source, melainkan perangkat lunak proprietari yang menyertakan sebagian komponen open source
    Definisi perangkat lunak bebas: https://www.gnu.org/philosophy/free-sw.html.en#four-freedoms
    Definisi open source: https://opensource.org/osd
    Penting juga dicatat bahwa definisi-definisi ini bukan makna kamus umum, melainkan istilah yang dibuat di dalam gerakan tertentu dengan tujuan sosial dan teknis tertentu
  • Sepemahaman saya, ekstensi ini menggunakan frontend C++ proprietari yang diambil dari EDG dengan lisensi komersial
    Frontend yang sama juga masuk ke Visual Studio IDE
    Saya tahu ada ekstensi C++ yang sepenuhnya open source berbasis clangd sebagai alternatif, tetapi saya bisa saja keliru

• “Perangkat lunak bebas yang diberikan Microsoft secara gratis tidak cukup terbuka” terdengar seperti argumen yang cukup aneh bahkan menurut standar sekarang
  Dulu, “IDE gratis” berarti Eclipse atau Vim yang dipasangi banyak ekstensi
  Dari luar, sepertinya bukan Microsoft yang menghalangi alternatif terbuka, melainkan alternatif-alternatif itu memang kurang bagus; dan ketika memakai perangkat lunak yang dibuat perusahaan yang harus membayar gaji karyawan sekaligus menghasilkan laba, memang ada sisi seperti itu
  Orang-orang yang merasa berhak mendapatkan kode sumber perangkat lunak terbaik Microsoft sebaiknya melihat seperti apa open source sungguhan yang dipelihara organisasi nirlaba independen
  Mungkin berfungsi dan mungkin bahkan punya debugger sungguhan, tetapi besar kemungkinan tak lama kemudian mereka ingin kembali
  Orang terlalu menganggap wajar perangkat lunak yang mereka dapatkan gratis. Belum terlalu lama yang lalu, IDE harus dibayar ratusan hingga ribuan dolar, dan kalau beberapa tahun kemudian perlu versi baru, biaya upgrade juga harus dibayar

  • Sulit mengatakan Microsoft tidak menghalangi alternatif terbuka
    Ekstensi VSIX semestinya menjadi standar yang cukup terbuka, tetapi ekstensi Microsoft seperti Pylance secara aktif menolak bekerja jika mendeteksi sedang berjalan di VS Code yang bukan build Microsoft
  • “Perangkat lunak bebas yang diberikan Microsoft secara gratis tidak cukup terbuka” bukan kutipan dari tulisan itu dan juga bukan argumen tulisan itu
    Intinya lebih dekat pada bahwa para developer sedang dikelabui dan tujuan Microsoft adalah menutup bagian-bagian yang esensial
  • Kalau melihat proyek Asahi Linux, situasinya mirip. Mereka melakukan pekerjaan luar biasa, tetapi bahkan menyamai paritas fitur dasar dengan laptop berusia 3 tahun pun masih berjalan
    Setelah paritas fitur selesai, berikutnya masih ada masalah performa, dan entah kapan itu akan teratasi
    Gagasan tentang perangkat lunak open source memang bagus, tetapi perangkat lunak terbaik saat ini hampir selalu harus diperoleh dengan membayar
  • Masalah saya adalah saya tidak tahu rencana besar Microsoft
    Saya tahu harga yang harus dibayar untuk memakai Emacs dan Vim. Secara teori sepenuhnya gratis, tetapi dalam praktiknya ada biaya berupa waktu, kesabaran, dan dedikasi; dan saya tahu bahwa pilihan saya menguntungkan saya, komunitas, dan industri
    Saat dulu memakai IntelliJ pun saya tahu persis bagaimana JetBrains mendapat keuntungan. Karena saya membayar lisensi dan memperbaruinya setiap tahun
    Namun apa perhitungan Microsoft? Mereka memberikan alat yang begitu indah dan layak ini sepenuhnya “gratis”; harga apa yang akan saya bayar di masa depan?
    Sulit percaya bahwa raksasa perusahaan dengan kapitalisasi pasar setara PDB Jerman menggelontorkan sumber daya besar untuk membuat editor kode “gratis” hanya karena mencintai developer, dan developer setidaknya harus sedikit skeptis
  • Ungkapan “perangkat lunak terbaik Microsoft” terdengar seperti lelucon
    Menurut saya perangkat lunak Microsoft lebih mirip tumpukan sampah mimpi buruk
    Poin tulisan itu adalah bahwa ketika perangkat lunak closed source berpura-pura menjadi open source, dampaknya juga terasa pada orang yang tidak ingin memakainya, dan poin itu terlewat
    Misalnya saya juga tidak ingin memakai Azure DevOps ataupun GitHub Actions, tetapi organisasi tempat saya bekerja harus menaruh proyek di GitHub, jadi saya dipaksa memakainya
    Akibatnya, saya merasa tenaga dan pengetahuan saya dipakai untuk membantu Microsoft mengeksploitasi para pengguna
    Satu-satunya penghiburan adalah bahwa ini pekerjaan berbayar; secara pribadi saya tidak memakai GitHub dan akan menyarankan orang lain juga begitu

• Jika tidak mengajukan model untuk membenarkan anggaran tahunan sekitar 20 juta dolar bagi lebih dari 50 karyawan penuh waktu yang membuat VS Code, kritik ini terdengar seperti “menyebalkan karena mereka membuat perusahaan kami sedikit tidak nyaman untuk mengambil hasil rekayasa mereka, mengganti permukaan produknya saja, lalu menjualnya lebih murah tanpa biaya pengembangan sendiri demi laba”

  • Bisa dipahami jika Microsoft membuat IDE sendiri untuk penggunaan internal berbagai divisi, dan mengalokasikan anggaran untuk alat modern yang fleksibel
    Jika mereka membukanya sebagai open source, mereka mendapat kepercayaan dari komunitas lain, memperoleh kode gratis serta pemeriksaan bug, juga penulisan dan dukungan ekstensi dari luar ekosistem Microsoft, sementara Microsoft tetap bisa terus menggunakannya
    Ini tidak tampak sebagai masalah yang begitu rumit
  • Itu bukan masalah saya. Masalah saya adalah tidak membuat kemampuan kerja saya bergantung pada niat baik Microsoft yang berkelanjutan
    Secara historis, itu adalah jalan yang terjamin menuju keusangan
    Bahkan tanpa hasil rekayasa mereka, masih ada Emacs, Vim, Clang, GCC, IDEA, Eclipse, Firefox, dan sebagainya
    Saya hanya tertarik pada hadiah selimut murah hati dari Microsoft jika tidak disertai cacar
  • Model bisnis mereka buruk bukanlah kekhawatiran saya. Mereka bukan anak miskin yang dimanfaatkan karena membuat keputusan keliru
    Hanya saja agak lucu melihat ini diberitakan seolah-olah kejutan besar. Sejak awal sudah jelas, hanya saja orang tidak peduli karena tampak tidak layak diperjuangkan
    Masalah developer lisensi BSD/MIT yang dieksploitasi sama tidak menariknya bagi saya dengan masalah bahwa model bisnis Microsoft bisa terganggu jika telemetri dimatikan
    Semua orang memilih dengan sadar apa yang mereka masuki sambil berpikir “kakak korporat besar akan memperhatikan kita,” dan ternyata memang diperhatikan, jadi selamat
    Saya tidak akan mengunggah apa pun dengan lisensi yang lebih lemah daripada AGPL, tetapi pada akhirnya ada banyak hal yang jauh lebih saya pedulikan daripada perangkat lunak

• Masih mencoba memahami apa sebenarnya masalahnya
  Kedengarannya seperti Microsoft membuat ekstensi cpptools/C++ yang lebih baik, tetapi banyak komponen Microsoft tertutup sehingga versi OSS yang utuh tidak bisa dibangun
  Lalu ketika pengguna menyadari bahwa mereka tidak bisa memakai ekstensi native di antarmuka web mana pun, apakah itu jadi masalah pihak antarmuka web?
  Kalau orang ingin memakai freeware alih-alih OSS, mungkin mengecewakan, tetapi saya tidak tahu apakah itu benar-benar masalah
  Jika ada jawabannya, sepertinya arahnya adalah membuat lebih jelas siapa yang bertanggung jawab
  Para penyedia open source perlu lebih tegas menyatakan bahwa penawaran mereka adalah open source sekaligus ekosistem terbuka, dan memberi tahu developer bahwa tidak semua ekstensi demikian, serta ekstensi alternatif dari Microsoft tidak demikian
  Jika proyek-proyek ekstensi utama sepakat, mereka bisa menambahkan keterangan di deskripsi marketplace semacam: vscode-cpptools bukan berlisensi yang disetujui OSI, berisi banyak blob biner yang tidak ditinjau, dan Microsoft tidak mengizinkan redistribusi untuk build native open source atau penyediaan VSCode sebagai layanan web
  Baik secara hukum maupun budaya, Microsoft tidak akan ingin memblokir akses marketplace hanya karena beberapa proyek OSS membandingkan ketentuan lisensi mereka dengan ketentuan Microsoft
  Apple juga sekarang sedang menghadapi gugatan marketplace, dan Microsoft tentu tidak menginginkan gugatan marketplace atau gugatan antimonopoli lain

  • Contoh sederhananya, buat API dengan satu fungsi publik lalu kompilasi API itu menjadi biner berlisensi closed source
    Lalu buat API lain yang juga hanya punya satu fungsi publik, dan fungsi itu hanya melakukan pemanggilan extern ke biner library tersebut
    Unggah API kedua ke GitHub dengan lisensi MIT dan nyatakan sebagai open source
    Secara luas, jika 100% fungsi software berada di dalam biner terkompilasi yang closed source, persoalannya adalah apakah menyebutnya open source seharusnya dianggap iklan menyesatkan
    Dengan kata lain, persoalannya adalah siapa yang menarik garis ketika seseorang melampaui maksud open source demi alasan yang eksploitatif
    Saya tidak tahu apakah fungsi cpptools 100% tertutup, tetapi dalam praktiknya, di dalam repositori yang disebut berlisensi MIT itu ada tiga lisensi lain yang harus disetujui

• Terlalu banyak tulisan yang harus dibaca untuk mengetahui apa poin sebenarnya, dan konsep “ekosistem yang terfragmentasi” muncul berkali-kali tanpa penjelasan
  Ungkapan seperti “perangkap lalat Venus yang dirancang untuk memecah-belah” itu maksudnya apa, saya sama sekali tidak mengerti
  VS Code adalah IDE yang bisa diunduh dan dipakai gratis dari Microsoft; ia adalah produk, bukan platform atau ekosistem open source ajaib yang tidak dikendalikan Microsoft
  Semua orang ingin membuat layanan developer yang “universal”, tetapi sepertinya tidak benar-benar mau membuat atau mendanai IDE, atau mungkin itu terlalu sulit
  Itu bukan kesalahan Microsoft

• Bukan bermaksud membela Microsoft, tetapi mereka sudah menyediakan codebase raksasa secara gratis dan membuat produk yang sebagian besarnya gratis di atasnya
  Kalau di-fork, hanya saja tidak bisa mengakses server Microsoft; menurut saya itu sudah cukup adil
  Dan Monaco dipakai oleh frontend karena memang editor yang sangat bagus. Dulu ketika CodeMirror atau Ace adalah pilihan terbaik, orang memasangnya
  Dibanding adanya masterplan besar di balik pembuatan Monaco, tampaknya lebih seperti mereka melihat peluang bahwa menjadikannya proyek independen akan memungkinkan banyak UI web

• Poin bahwa “masa depan alat pengembangan software yang akan dibuat ke depan sepenuhnya tertutup, tetapi karena sebagian komponennya memenuhi definisi OSI, orang melewatkan gambaran besarnya dan menganggapnya baik-baik saja” adalah masalah yang sangat besar
  Terutama karena banyak perusahaan yang didanai VC memakai istilah open source terlalu longgar, sehingga merusak bahasa, makna, bahkan semangat gerakan open source
  YC juga mendukung sejumlah perusahaan yang mengaku open source tetapi sama sekali tidak mengikuti semangatnya

  • Masalahnya bukan sekadar perusahaan melakukan itu, melainkan pengguna dan developer tidak terlalu peduli atau tidak berbagi kekhawatiran tersebut
    Argumen moral seperti semangat atau etika tidak terlalu relevan
    Yang penting adalah lisensi software merupakan dokumen hukum, dan tempat penafsirannya bermakna adalah pengadilan
    Tampaknya tidak banyak gugatan terkait VS Code, dan Microsoft pada umumnya cukup membereskan bagian itu
    Dalam arti hukum, VS Code tampak cukup aman. Memang benar sebagian ekstensi bukan berlisensi OSS atau bahkan sepenuhnya closed source, tetapi kalau tidak suka, cukup jangan dipakai
    Lebih jauh lagi, buat sendiri open source untuk memperbaikinya. Open source bukan hak, melainkan privilese yang diberikan atas kebijaksanaan pembuatnya, bukan sesuatu yang bisa dituntut
    VS Code adalah produk closed source yang menyertakan banyak komponen OSS, dan karena komponennya banyak, ada juga VS Codium yang sepenuhnya OSS
    Banyak dari komponen OSS itu juga dipakai di produk lain, dan sebagian sepenuhnya open source
    Nilai ekosistem VS Code terletak pada kemampuannya membuat komponen dan ekosistem produk seperti ini berkembang

• Tidak ada yang berhak mendapatkan VS Code secara gratis. Sebenarnya, tidak ada yang berhak mendapatkan apa pun secara gratis
  Alternatifnya adalah membayar untuk IDE komersial yang sudah membengkak
  VS Code itu cukup bagus, serbaguna, gratis, dan cukup terbuka untuk bisa di-fork
  Orang-orang lupa bahwa ini adalah hasil rekayasa yang luar biasa. Kalau melihat kodenya, itu bukan sesuatu yang muncul begitu saja secara gratis
  Baik Microsoft maupun perusahaan mana pun tidak berutang layanan gratis kepada siapa pun, dan rasa berhak seperti ini perlu dikendalikan

  • Benar, lebih baik pasang saja label harga. Orang-orang di sini juga mendapat cukup banyak manfaat dari VSCode, jadi mereka akan mau membayar
    Masalahnya adalah ketika penawaran gratis itu pada dasarnya dirancang untuk menjerumuskan pengguna ke dalam rawa tanggung jawab hukum dan kewajiban finansial tanpa batas atas
    Terutama untuk layanan seperti VSCode yang bukan pembelian sekali saja, melainkan membuat pengguna terus bergantung pada Microsoft melalui ekstensi dan pembaruan; dan memang dirancang seperti itu
    Alih-alih menyediakan opsi mudah untuk membayar sekali dengan jelas lalu selesai, mereka memilih mengekstrak jumlah uang yang kabur dalam jangka panjang, sesuai tingkat resistensi pengguna
  • Produk JetBrains bernilai, jadi saya membayarnya selama bertahun-tahun. Dibandingkan fitur Eclipse, produk itu jauh lebih maju, dan memang layak dibayar
    Saya juga selalu mengatakan hal yang sama soal open source: saya skeptis untuk mengadopsi framework yang tidak punya dana besar di belakangnya
    Berbahaya kalau bergantung pada tingkah seorang insinyur jenius acak di internet
    Microsoft akan menghasilkan uang dari VSCode. Hanya saja tidak se-langsung Google menghasilkan uang dari Chrome
  • Apakah benar-benar luar biasa secara rekayasa? Membuat IDE yang nyaris berfungsi dengan teknologi browser yang bengkak dan bahasa yang seperti dirancang di atas serbet, menurut saya sama “mengesankannya” dengan membangun jembatan pejalan kaki sepanjang 1 mil dari stik es krim dan permen karet

• Menurut saya OSS itu bagus, tapi bukan itu alasan saya memakai VS Code
  Saya memakainya karena ia memecahkan masalah kebutuhan akan editor yang layak, bukan monster seperti Eclipse
  Di area ini ada pilihan lain seperti Sublime, tetapi VS Code selalu terasa paling tidak mengganggu
  Sebelumnya ada Adobe Brackets yang mirip, tetapi entah kenapa sangat lambat dan banyak bug
  Jika Anda penggemar OSS, poin-poin dalam tulisan itu valid. Namun pada akhirnya kode sumbernya ada, dan kalau mau, Anda juga bisa menjalankan marketplace sendiri
  Memang butuh waktu dan uang, tetapi jika percaya pada ide itu, Anda harus berinvestasi tanpa bergantung pada perusahaan raksasa
  Kalau ada ekstensi proprietary yang tidak bisa dimiliki, itu memang disayangkan, tetapi seseorang bisa saja membuat versi OSS-nya
  Secara keseluruhan saya setuju dengan tulisan itu, tetapi saya tidak punya ilusi bahwa Microsoft melakukan ini karena keyakinan pada open source, dan dalam skenario terburuk masih ada pilihan lain, jadi tidak masalah