diff --git a/docs/src/content/docs/guides/comparison.md b/docs/src/content/docs/guides/comparison.md
index 0840477..ed4a6ac 100644
--- a/docs/src/content/docs/guides/comparison.md
+++ b/docs/src/content/docs/guides/comparison.md
@@ -41,7 +41,7 @@ What each library gives you beyond extending directly from `HTMLElement`, the bo
 | Works with zero build tooling    | ✅ import from CDN, no compiler                                    | ✅ (buildless possible, decorators need tooling)         | ✅                                      | ⚠️ practical with tooling                        |
 | Editor/IDE tooling               | ✅ typed props + [CEM analyzer plugin](/cem-plugin/)               | ✅ extensive (analyzer, TS decorators, IDE plugins)      | ✅ CEM-focused                          | ✅ TS-first                                      |
 | Lifecycle hooks                  | `onInit`, `afterViewInit`, `onChanges`, `onDestroy`                | full reactive update lifecycle                           | `willUpdate`, `firstUpdated`, `updated` | full lifecycle + behaviors                       |
-| Backing / ecosystem              | solo maintainer, small surface                                     | Google, large ecosystem                                   | new (2026), solo-authored         | Microsoft, powers Fluent UI                      |
+| Backing / ecosystem              | solo maintainer, small surface                                     | OpenJS Foundation (donated by Google 2025), large ecosystem | new (2026), solo-authored         | Microsoft, powers Fluent UI                      |
 
 :::note[Why 11ty WebC isn't here]
 WebC is a compile-time tool: it resolves components during an Eleventy build and ships plain HTML with no client runtime. Every row above is about what a library does _in the browser at runtime_, so a side-by-side comparison would be measuring two different things. If your components are static at build time, WebC solves a different problem.
diff --git a/docs/src/content/docs/guides/why.md b/docs/src/content/docs/guides/why.md
index f96436c..dec0e3b 100644
--- a/docs/src/content/docs/guides/why.md
+++ b/docs/src/content/docs/guides/why.md
@@ -20,6 +20,6 @@ Pick honestly:
 - **Reorderable lists of stateful items**: patching is positional, not keyed; preserved focus/animation follows the position, not the item. Lit's `repeat` or FAST handle this correctly.
 - **High-frequency updates on large trees**: WCB re-renders synchronously per prop write and diffs the whole vnode tree; Lit/FAST update only the affected bindings on a batched schedule.
 - **SSR with client hydration**: WCB renders on the client after `connectedCallback`, so there's no hydration step. If you need server-rendered markup that hydrates in place, use Lit (`@lit-labs/ssr`).
-- **Big-team, long-horizon design systems**: WCB is a solo-maintained library with a deliberately small surface. For large-org backing and ecosystem, choose Lit (Google) or FAST (Microsoft, powers Fluent UI).
+- **Big-team, long-horizon design systems**: WCB is a solo-maintained library with a deliberately small surface. For large-org backing and ecosystem, choose Lit (OpenJS Foundation) or FAST (Microsoft, powers Fluent UI).
 
 For the measured numbers and the capability-by-capability breakdown behind these claims, see [WCB & similar libraries](/comparison/).