Visual Studio Code is designed to fracture (2022)

Original Article ↗ Hacker News Discussion ↗

Microsoft’s Visual Studio Code is praised as a powerful, free editor, but many argue its ecosystem is structurally tilted toward Microsoft’s proprietary services and extensions. Commenters highlight how key components like Pylance, Remote SSH, and Dev Containers are closed, tightly licensed, and sometimes DRM‑encumbered, preventing fully compatible open forks and locking third‑party platforms out. This raises broader concerns about “open source” being used as branding while control remains proprietary, the sustainability of true FOSS alternatives, and what developers risk when they build skills or businesses atop vendor-controlled tools.

What “fracture” means in this context

  • “Fracture” is used to describe how Microsoft splits VS Code into:
    • An MIT-licensed “Code – OSS” core.
    • A proprietary Microsoft-branded build and key extensions.
  • This lets Microsoft benefit from the “open source” halo while keeping crucial functionality and distribution rights under tight control.
  • Result: forks (VSCodium, Theia, cloud IDEs) can’t fully replicate the “real” VS Code experience, especially for popular languages/features.

Licensing and extension lock‑in

  • Many core MS extensions (Pylance, cpptools, C# tooling, Remote SSH, Dev Containers, etc.) have runtime licenses that:
    • Prohibit use with non‑Microsoft builds.
    • Forbid redistribution of language server binaries.
  • Some repos present an MIT license at the top level but hide proprietary runtime licenses deeper, which some call misleading.
  • Pylance in particular is cited as:
    • Closed, DRM‑encumbered (obfuscation, integrity checks).
    • Actively hostile to being run in forks (VSCodium, code‑server, etc.).

Microsoft’s strategy and motives

  • One view: classic “embrace, extend, extinguish” pattern:
    • Embrace OSS core, extend with proprietary services/extensions, extinguish viable forks and alternatives.
    • Tie VS Code tightly to Azure, GitHub, Codespaces, Copilot, etc.
  • Opposing view:
    • VS Code is “open core” and already extremely generous.
    • MS is entitled to monetize proprietary extensions and protect its investment; competitors wanting “free IDE + free ecosystem” are being unrealistic.

Impact on competitors and forks

  • Cloud IDE vendors (Gitpod, etc.) and forks (VSCodium, Theia) are constrained:
    • Can’t legally ship or depend on key MS extensions.
    • Third‑party SDK vendors may target only “official” VS Code, further sidelining forks.
  • Some say this is normal (Linux has proprietary apps too).
  • Others argue: “If your competitors can’t legally resell your build, it isn’t really open source in practice.”

Alternatives and developer reactions

  • Some happily stick with VSCodium + OpenVSX and OSS extensions (clangd, Pyright, free-vscode-csharp, etc.) and report few issues except Dev Containers/Jupyter quirks.
  • Others move to JetBrains IDEs, Emacs/Vim (often with Doom/Neovim), Theia, or Zed, citing:
    • Desire for real freedom, less lock‑in, or better language support.
  • Many still favor VS Code for polish, performance, rich ecosystem, and integration with corporate Microsoft stacks.

Open source definitions, SSPL, and sustainability

  • Heated debate over OSI, “open source” vs “source‑available,” and licenses like SSPL/BUSL:
    • One side: OSI, funded by big tech, blocks “field‑of‑use” restrictions that would prevent hyperscaler exploitation; OSD is outdated and harms sustainability.
    • Other side: OSD must forbid field‑of‑use restrictions to keep software usable “for any purpose” and avoid exclusion/uncertainty; SSPL clearly violates this.
  • Broader thread on:
    • Free‑as‑in‑speech vs free‑as‑in‑beer.
    • Entitlement to free tools vs developers needing to get paid.
    • Open core vs “fake OSS” vs pure copyleft.

Security, telemetry, and trust

  • Some see telemetry in VS Code as a red herring; the real issue is licensing and IP.
  • Others are worried about:
    • Unsandboxed extensions, remote SSH/devcontainers, and AI integrations being high‑risk attack surfaces.
    • VS Code obscuring what machine/interpreter/environment is actually being used, complicating debugging and security.
  • A few argue browsers are the only class that sandbox extensions well; most editors/IDEs (Emacs, Vim, JetBrains) share similar plugin‑trust problems.