Visual Studio Code is designed to fracture (2022)

Original Article ↗ Hacker News Discussion ↗

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.