14.1 The Adoption Decision

Who adopts, how fast, and which path fits your team

Before you score it on four axes, you need to know which version of adoption you are considering. Open Design is not a SaaS you roll out by provisioning seats. It is infrastructure you choose how to deploy, and the right choice depends on team size, technical capacity, and your compliance posture.

The product has three install paths, each targeting a different adoption context. A small design team evaluating on their own terms reaches for the desktop app. An engineering team that wants to fork or extend skills and plugins installs from source. A platform team deploying for a department chooses Docker Compose. These are not tiers --- they are different operating contracts.

As of June 2026, the desktop app covers the most common entry point: zero-config, auto-detects coding-agent CLIs on your PATH at startup, and stores everything in ~/.od/. Most leaders should start here. It eliminates the native-build failures that trip up first-time from-source installs (covered in Section 2.1).

The most common adoption mistake is jumping straight to the Docker Compose path to "do it properly" before the team understands the tool. I've seen it done --- the platform team builds a shared server before anyone has generated a single artifact, and the rollout stalls on infra debates. Start with the desktop app for the first two weeks. Get the four-beat loop (Section 3.1) running across two or three people before you centralize anything.

14.2 Governance

Where artifacts live, who controls the keys, and what the sandbox is designed to guard

Governance for Open Design breaks into four questions: where do files go, where do keys live, what prevents generated code from running loose, and how do you review automated refactors before they merge? Each has a concrete answer in the architecture.

Where artifacts live

By default, all project data lives under ~/.od/: generated artifacts in ~/.od/projects/<id>/, the project database in ~/.od/app.sqlite, and the generation history log at ~/.od/artifacts/history.jsonl (append-only, suitable for audit trails). The OD_DATA_DIR environment variable relocates all storage, which lets you point it at a team NAS, a mounted volume in Docker, or any compliance-controlled path.

Artifacts are plain files --- HTML, JSON, PDF, and PPTX --- not a proprietary binary format. That makes them git-friendly. You can commit the .od/artifacts/ tree to version control to get artifact history for free, with no additional tooling.

Where keys live

Open Design uses a BYOK (bring your own key) proxy. According to Open Design's architecture documentation (v0.9.0, June 2026), credentials are stored on the user's machine by design, not uploaded to a vendor. The proxy is designed to bind to localhost:7456 by default and is not exposed to the network unless you explicitly set OD_BIND_HOST. Routes exist for Anthropic, OpenAI, Azure, Google, Ollama, and SenseAudio providers at /api/proxy/<provider>/stream. Open Design's README documents that the proxy is designed to include SSRF (Server-Side Request Forgery) protection at the edge. This is documented design intent as stated in the project README; verify the specific mechanism against the daemon source before making security decisions that depend on it.

For LAN or Docker deployments, anyone who can reach OD_BIND_HOST can call the proxy. Set OD_ALLOWED_ORIGINS to restrict cross-origin access. This is standard CORS hygiene, not a substitute for network-level controls.

The sandbox

Every generated artifact is designed to render inside a sandboxed srcdoc iframe. Open Design's architecture documentation describes the sandbox as designed so that model-generated code cannot access the DOM outside the iframe, reach the filesystem, or make network calls. The Electron desktop shell adds a second sandboxed renderer layer with sidecar IPC. Together, the documented design intent is that Open Design can run arbitrary model-generated HTML safely on your machine, which is the stated security case for local-first generation. Treat this as documented architecture, not an audited security guarantee; verify against the source before relying on it for high-assurance environments.

The sandbox is not optional in the standard build. Do not disable it, and treat any fork or hosted variant that removes it as a red flag. Generated code is untrusted code by definition. The one inconvenience is preview-vs-export divergence on external assets --- covered fully in Section 8.6.

Reviewing automated refactors

The code-refresh-to-brand scenario plugin reads a git repository and a DESIGN.md and produces a diff refactoring components to match the brand spec. The diff is not auto-applied; it is staged for human review in git. Before any org-wide adoption of this plugin, establish a review policy: the diff must pass CI and get a human approval before merge. The plugin can touch large portions of a codebase.

14.3 Cost

Infrastructure and model spend versus per-seat licensing

The cost model for Open Design is structurally different from hosted alternatives. There is no seat license --- Apache-2.0 means commercial use is permitted with no per-user fee. The cost is the model API spend from the agent CLI you choose, plus the infrastructure to run it.

Hosted design AI products and collaborative design platforms typically charge per seat per month, with higher tiers for organization-level features. The meaningful comparison is not tool-vs-tool pricing, but the cost structure: Open Design's costs scale with usage, not headcount.

For a team of ten designers, a hosted per-seat tool might cost a flat monthly fee regardless of whether any design work happens that month. Open Design costs only the model tokens consumed by actual generations. A slow month costs less. A heavy sprint costs more. That variability is a feature for some organizations and a planning problem for others.

The agent model cost depends entirely on which CLI you wire. Claude Code (Anthropic) and Cursor charge their own rates. OpenCode (MIT) is open-source and free to run; its model cost is determined by your BYOK key. As of June 2026, the cost structure of individual agents is covered in Chapter 11; use that analysis to project model spend before committing to a CLI pairing.

The infrastructure cost advantage is strongest for small teams on the desktop path: they spend nothing on tool hosting and pay only for the model tokens they consume. It erodes for teams that run Docker Compose on a shared server and need an engineer to maintain it. That hidden engineering cost is real, and teams routinely undercount it in evaluations.

There is also a cost for vendor resilience. Running two agents via MCP --- one proprietary, one open-source --- costs marginally more in key management overhead but significantly reduces the exposure to any single vendor's pricing change or sunset. Google announced Gemini CLI will sunset on June 18, 2026 (as of this writing). Teams that had routed even a portion of their workflow through an open alternative did not stop work when a single vendor's product was discontinued.

14.4 Vendor Independence

Why agent-agnostic matters and how MCP delivers it

The agent CLI market has experienced significant churn: Google announced Gemini CLI will sunset on June 18, 2026, OpenCode was rebranded from a previous product in January 2026, and new entrants ship monthly. Wiring your design workflow to a single proprietary agent is a rollout risk with a documented recent history.

Open Design uses MCP (Model Context Protocol) as the interface between the design system and any agent CLI. MCP is an open standard, and as of June 2026, Open Design documents support for 21+ coding-agent CLIs via MCP, including Claude Code, Cursor, GitHub Copilot, OpenCode, Codex CLI, Gemini CLI, Cline, Trae, Kimi CLI, Aider, and others. The full list is in Chapter 11.

The MCP interface means you can swap agents without migrating artifacts, brand systems, or skills. Your DESIGN.md, your project history, and every generated artifact stay in place. What changes is only the CLI invoking the generation. I run two agents simultaneously --- one proprietary, one open-source --- because a vendor sunset never strands me. That is the vendor independence argument in a single sentence.

The artifacts themselves compound the independence: generated HTML, PDF, and PPTX are not proprietary binary formats. You can read, open, version-control, and process them without Open Design installed. This is different from design tools that lock your work in a file format only they can open.

As of June 2026, Open Design's GitHub repository reports 63k+ stars and 7k+ forks. Broad community adoption matters for vendor independence at the ecosystem level: a widely-adopted open-source tool with active contributors is harder to abandon or shut down than a single-vendor hosted product. The Open Design Fellow program was announced in June 2026 and signals long-term open-source investment; verify current terms at the project repository. None of this is a guarantee --- open-source projects do go dormant --- but it is evidence to weigh.

14.5 Open-Source Licensing Posture

Apache-2.0, bundled-template obligations, and the trademark notice

Open Design's licensing posture is straightforward for most use cases and has one area that needs legal attention before commercial distribution: the bundled templates retain their own upstream licenses, and the named brand systems carry a trademark notice. Nothing in this section is legal advice; confirm your obligations with qualified counsel.

The Open Design core is Apache-2.0. This is a permissive license: commercial use is permitted, modification is permitted, distribution is permitted, patent use is permitted, and private use is permitted. Apache-2.0 generally requires including the license notice in any distribution and is not a copyleft or share-alike license. For an organization adopting Open Design as an internal tool, Apache-2.0 creates no license cost. Have counsel confirm your specific obligations before any commercial distribution or redistribution.

Two bundled presentation templates are not Apache-2.0. Guizang-PPT is MIT-licensed (attributed to @op7418); HTML-PPT is MIT-licensed (attributed to @lewislulu). MIT and Apache-2.0 are both permissive open-source licenses, and many practitioners treat them as compatible for internal use, but compatibility for your specific distribution scenario is a legal determination --- have counsel confirm the obligation chain before redistributing Open Design as part of a product or service. MIT's attribution requirement means the upstream author names must appear in any distribution that includes these templates. Verify attribution details against the bundled LICENSE files in the release you ship; upstream maintainers control their license terms.

The named brand systems --- Linear, Stripe, Apple, Tesla, Notion, Figma, Vercel, and others --- are bundled in Open Design as reference implementations for learning the DESIGN.md schema structure. All trademarks remain the property of their respective owners; Open Design and this book are not affiliated with, sponsored by, or endorsed by those trademark holders. Use the bundled systems to understand the schema, then author your own house DESIGN.md. Generating output in a famous brand's visual style and shipping that output to customers raises trademark and potentially other legal concerns --- this is not a fair-use or otherwise cleared use; confirm with counsel before any such use.

14.6 The Adoption Scorecard

Score it on four axes before you commit

Score it on four axes: adoption fit, governance control, total cost, and vendor independence. Each axis has a clear signal and a red flag. If you hit a red flag, that does not necessarily rule out adoption --- it identifies where you need more work before committing.

The mental model for this evaluation is simple: score it on four axes and look for the distribution. If two or more axes have red flags, the timing is wrong and the rollout will fail. One red flag is a design constraint to resolve before launch, not a reason to cancel. Zero red flags means you are ready to proceed to a pilot.

The scorecard is most useful as a forcing function for conversations that adoption evaluations tend to skip. The governance axis forces a storage policy discussion before there are compliance incidents to drive it. The vendor independence axis forces the "what do we do if this agent sunsets" conversation before announcements like the Gemini CLI sunset happen again. Having these conversations during evaluation is much cheaper than having them after rollout.

A structured pilot produces better scorecard data than a theoretical evaluation. Choose one team, one real project, and run the four-beat loop (Section 3.1) for two weeks. At the end, score the four axes with real evidence. That evidence will be more useful than any vendor comparison document.