# Plugin registry or marketplace

- **Pattern:** `ab-002099` (`plugin-extension-architecture.discovery-docs.marketplace`)
- **Severity:** info
- **Lifecycle:** active
- **Last modified:** 2026-04-18
- **Canonical URL:** https://auditbuffet.com/patterns/ab-002099
- **License:** CC-BY-4.0 — attribute to AuditBuffet Pattern Catalog (https://auditbuffet.com/patterns/ab-002099)

## Why it matters

Without a discovery mechanism, third-party plugins die in obscurity regardless of quality. Users resort to searching GitHub for unvetted repos, which fragments the ecosystem, delays adoption, and increases supply-chain risk because developers install whatever first result appears. A registry, naming convention like `eslint-plugin-*`, or curated list concentrates discovery into a trusted surface, which drives plugin author motivation, accelerates user-experience wins, and gives the core project a lever to flag abandoned or malicious extensions.

## Severity rationale

Info because discovery is a growth and usability concern, not a security or correctness defect blocking release.

## Remediation

Ship the cheapest discovery surface first: adopt a package-manager naming convention (for example `my-app-plugin-*` on npm) and publish a curated list of known plugins in `docs/plugins.md` or a JSON registry at `src/plugins/registry.json`. A minimal seed:

```json
{ "plugins": [{ "name": "my-app-plugin-analytics", "description": "Analytics integration", "npm": "my-app-plugin-analytics" }] }
```

Link it from the README and the plugin-authoring guide so new authors know where to register.

## Detection

- **ID:** `marketplace`
- **Severity:** `info`
- **What to look for:** Check whether there is a way for users to discover and install third-party plugins. Look for:
  1. A public plugin registry, marketplace, or catalog (web page or API)
  2. A search mechanism — users can browse or search for plugins by functionality
  3. An install mechanism — a CLI command or UI to install plugins from the registry
  4. Alternatively, a convention for finding plugins on npm (e.g., `eslint-plugin-*`, `gatsby-plugin-*`, `babel-plugin-*`)
  5. A curated list in documentation (e.g., "Awesome Plugins" page)
  Real-world examples:
  - VS Code: marketplace.visualstudio.com
  - npm: keyword conventions (`eslint-plugin-*`, `webpack-plugin-*`)
  - WordPress: wordpress.org/plugins
  - Obsidian: community plugin browser built into the app
- **Pass criteria:** Count all marketplace/registry integration points. At least one discovery mechanism exists: a dedicated registry/marketplace, a documented naming convention for finding plugins on npm/PyPI, a curated list in docs, or a built-in plugin browser.
- **Fail criteria:** No discovery mechanism. Users can only find plugins by word of mouth or searching GitHub. No naming conventions, no registry, no curated list.
- **Skip (N/A) when:** The plugin system is internal-only or the project has fewer than 5 published plugins. Discovery mechanisms are premature for very small ecosystems.
- **Detail on fail:** `"No plugin discovery mechanism exists. There is no marketplace, no naming convention for npm packages, no curated list in documentation, and no built-in plugin browser. Users can only find plugins by searching GitHub or asking in community channels."`
- **Remediation:** Start with a naming convention and curated list in `docs/plugins.md` or `src/plugins/registry.json`:

  ```json
  { "plugins": [{ "name": "my-app-plugin-analytics", "description": "Analytics integration", "npm": "my-app-plugin-analytics" }] }
  ```

---

Taxons: user-experience

HTML version: https://auditbuffet.com/patterns/ab-002099