OpenVSX, which VSCode forks rely on for extensions, down for 24 hours

Original Article ↗ Hacker News Discussion ↗

OpenVSX Outage and Impact

  • OpenVSX (the Eclipse Foundation–run VS Code–compatible extension registry) was down ~24h, returning 503s and breaking extension search/installs for VSCodium, Cursor, Windsurf, code-server, GitLab Web IDE, and other VSCode forks.
  • Linked status/incident threads attribute it to a major storage failure at Eclipse affecting multiple services; restoring data is slow.
  • People highlight the fragility of relying on a single volunteer‑run service for a global ecosystem, especially when multi‑million‑dollar products depend on it.
  • OpenVSX is open source and self‑hostable; some note that serious users/firms should mirror it or run private registries instead of freeloading on the public instance.

VS Code, Licensing, and “Open Core” Fracture

  • Several commenters argue VS Code is “open core”: the editor core is MIT, but many flagship extensions (C/C++, C#, Python, Remote Development, AI) and the official marketplace are proprietary and legally restricted to Microsoft’s own builds.
  • Forks technically can point at Microsoft’s marketplace, but that violates the ToS; legality and enforceability of such terms are debated.
  • One camp says it’s reasonable Microsoft doesn’t subsidize competitors like Cursor/Windsurf and that others should build their own LSPs/marketplaces.
  • Another camp argues this is classic “embrace, extend, extinguish”: VS Code was initially more open, then key capabilities moved behind closed, licensed blobs, making pure-FOSS use significantly worse and locking users into Microsoft’s ecosystem.
  • VS Code is compared to Android vs AOSP + Google Play Services: a nominally open base with critical proprietary layers.

Alternatives and De‑Risking from VS Code

  • Theia is promoted as a more future‑proof VS Code–like platform: not a fork, built on Monaco, high (though not perfect) VS Code API compatibility, fully open, and intended as a shippable platform.
    • Pros: no Microsoft telemetry, more extension freedom, less risk of a “rug pull.”
    • Cons: rough edges (finicky builds, weak docs, bugs in extension handling), still uses OpenVSX, and seems oriented toward vendor tooling rather than end‑user polish.
  • Others advocate Emacs, Vim/Neovim, Helix, Kakoune, Lapce, Zed, or JetBrains IDEs as ways to escape VS Code’s centralization and licensing constraints.
  • Neovim/Emacs users emphasize decentralized, resilient package ecosystems (ELPA/MELPA, git-based installs) and simpler remote workflows (SSH, TRAMP) vs VS Code’s Remote SSH lock‑in.

Centralization, Mirrors, and Infrastructure

  • Some lament the shift from mirrored FTP/HTTP archives to single corporate‑hosted services (GitHub, extension marketplaces), arguing it increases fragility and corporate leverage.
  • Suggested mitigations: multiple OpenVSX mirrors, OCI-based distribution, IPFS, or GitLab‑hosted registries so organizations can cache .vsix files and ride out outages.