Locara

VS Code Marketplace

What it is: Microsoft-run marketplace for VS Code extensions. ~50k+ extensions, dominant editor in software dev, marketplace is the closest analog to a “developer-tool extension store” Locara could study. Status: Mature, dominant for code editor extensions. Operated by Microsoft on Azure DevOps infrastructure. Most relevant to Locara: Manifest-based, free-to-publish, automated review of low-risk + human review of verified publishers, no monetization layer (sponsorship-only). A model that bootstrapped a thriving free ecosystem.

Background

VS Code launched in 2015 with an extension model from day one — a key strategic choice that turned a small editor into the dominant IDE. Extensions are Node.js modules (or webextensions) that consume a published API surface from VS Code itself. The marketplace is run on Azure DevOps; publishers create an Azure org, generate a Personal Access Token, and publish via the vsce CLI.

The extension API itself has been Microsoft’s actual moat — it’s huge, well-documented, and continuously expanded with first-class support for activities like debugging, language servers, source control, terminal integration, and now AI chat participants and language model providers.

Key design decisions

  • package.json + manifest fields as the extension spec — extensions are npm packages with VS Code-specific metadata. Familiar to JS devs.
  • vsce CLI for packaging and publishing — produces a .vsix (zip with metadata).
  • Free to publish, no monetization layer — sponsorship link only. Extensions are uniformly free.
  • Verified publisher badge via DNS TXT record verification (5 business days).
  • Manual review only for verified publishers; baseline submissions go through automated checks.
  • API-defined capability surface — extensions can only do what the VS Code API exposes. No arbitrary host access.
  • Activation events — extensions activate on demand (when a specific file type opens, command runs) instead of being always-loaded. Reduces startup cost.
  • Telemetry guidance — Microsoft publishes patterns, doesn’t enforce.
  • Pre-release channel — extensions can ship early versions to opt-in users.
  • Platform-specific builds for native dependencies.

What worked

  • The API surface, not the marketplace, was the win. A great API made extensions valuable; the marketplace was distribution.
  • package.json reuse lowered the bar for any JS dev. Migration from “tinkering with VS Code” to “publishing an extension” was hours.
  • Free-to-publish + free-for-users + sponsorship built a healthy ecosystem without the monetization wars Apple/Google have.
  • Activation events = perf-by-design. Extensions don’t slow the editor unless used.
  • Microsoft consistently expanded the API — devs trust they can build long-term against it.
  • AI integration (chat participants, language model providers) added in 2023+ is well-designed and ecosystem-friendly.

What failed / criticisms

  • Extensions can do too much within the API surface. Some extensions phone home, install bundled binaries, etc. — the API doesn’t strictly capability-gate.
  • Cursor and forks (Cursor, Codium, etc.) cannot legally use the official Marketplace per Microsoft TOS — they ship Open VSX or alternatives. Distribution is locked to Microsoft’s editor, despite the API being open.
  • Microsoft proprietary extensions (Pylance, Live Share, etc.) use private APIs not available to others, creating an uneven playing field.
  • No first-party monetization story has been controversial — many high-value extensions live as parallel commercial products (DataGrip-style) rather than in the marketplace.
  • Search/discovery is mediocre — relies heavily on install counts, which calcify rankings.
  • Telemetry inconsistencies — extensions phone home in many ways with little oversight.

Specific learnings for Locara

  1. The framework’s API is more important than the marketplace. VS Code’s success is 90% great extension API. Locara’s SDK and component primitives need to be excellent; the registry follows.
  2. Familiar package format wins. VS Code reused package.json. Locara should reuse familiar patterns too — package.json-style manifest with Locara-specific fields, not a brand-new format.
  3. Free-to-publish + sponsorship-link is a viable model. It worked for VS Code. Locara can default here and add commerce only if needed.
  4. API-defined capability surface is the right boundary. Extensions can only do what the API allows. Locara apps can only do what their declared capabilities allow. Same principle.
  5. Activation events as performance pattern. Locara apps shouldn’t run by default; they activate when launched. (Obvious for app stores, but worth stating.)
  6. Pre-release channel is a low-cost feature with high dev value. Bake into the registry from start.
  7. Cautionary tale on locking the marketplace to one client. Microsoft’s Marketplace TOS effectively bans Cursor etc. from using it. Locara should not lock the registry to Locara-runtime-only — let other tools/runtimes consume the registry too. The signed manifests + open spec mean this is achievable.
  8. Bootstrap the ecosystem with first-party extensions. Microsoft seeded the marketplace with many official extensions before opening up. Locara should similarly ship 5–10 first-party reference apps.
  9. Plan for AI-extension capabilities. VS Code added chat-participant and language-model-provider concepts as the ecosystem evolved; Locara was born for this and should make it native.

References