Wiki provider landscape

@@ -2,501 +2,239 @@
schema: foundry-doc-v1
title: "Wiki provider landscape"
slug: wiki-provider-landscape
short_description: "An audit of 25 wiki platforms across four groups documenting why no competitor has closed Wikipedia's encyclopedic gap, and what closing it would require."
short_description: "A structural audit of the wiki-shaped knowledge-surface market by archetype, documenting why no category of provider has closed Wikipedia's encyclopedic gap, and what closing it would require."
status: active
category: reference
type: topic
content_type: topic
quality: complete
last_edited: 2026-05-14
editor: pointsav-engineering
audience: vendor-public
bcsc_class: no-disclosure-implication
last_edited: 2026-07-30
editor: pointsav-engineering
paired_with: wiki-provider-landscape.es.md
cites:
 - ni-51-102
 - osc-sn-51-721
---

The PointSav documentation wiki at `documentation.pointsav.com` is one
entrant in a field where twenty-five distinguishable providers ship some
variation of "wiki-shaped knowledge surface" in 2026. Most of them are
not encyclopedic-knowledge platforms; they are private-team productivity
tools, developer-documentation site generators, or personal-knowledge
networked-thought systems. None of them has replaced Wikipedia for
general-knowledge encyclopedic depth. This article documents the field,
names the structural reasons no provider has closed the gap, and
identifies the genuine advantages each provider has over Wikipedia —
features worth preserving as the [[app-mediakit-knowledge|substrate]] iterates.

The audit is structural, not promotional. Each provider is described
factually with its strongest published positioning and the structural
limitation that prevents it from filling the encyclopedic-knowledge
gap. The conclusion is not "PointSav wins"; it is "the gap is structural
and is not closing under the current commercial-incentive structure of
the wiki market."

## 1. The four groups

Twenty-five providers in four groups by their target use case.

- **Group A — Collaborative knowledge bases**: Notion, Confluence,
 Coda, ClickUp Docs. Built for private organisational knowledge
 management. Sell seat licenses to enterprise IT.
- **Group B — Public-facing wiki engines**: Wiki.js, BookStack,
 Outline, MediaWiki (what Wikipedia runs on), Fandom, Wikidot,
 DokuWiki, TiddlyWiki. The closest in shape to a Wikipedia-class
 platform; widest variance in editorial governance.
- **Group C — Developer documentation site generators**: Docusaurus,
 MkDocs Material, VitePress, Nextra, Fumadocs, Astro Starlight,
 GitBook, Read the Docs. Generate docs sites for software projects;
 static-site-first; collaborative-editing-second or none.
- **Group D — Personal/networked-thought tools**: Obsidian Publish,
 Roam Research, Logseq, Capacities, Quartz v4. Single-author
 personal-knowledge-management primarily; some publish surfaces.

## 2. Per-provider one-pagers

### Notion (notion.com)

In 2026 Notion repositions itself as "The AI workspace that works for
you" — an enterprise productivity suite with Custom Agents, autonomous
Q&A routing, and integration across Gmail, Slack, GitHub, and HubSpot.
The article shell is a free-form block canvas: headings, callouts,
toggles, inline databases — no fixed structure and no enforced schema.
The encyclopedic-depth gap is categorical: Notion has no concept of a
canonical article namespace, no red-link discovery, no Talk-page
editorial debate, no Neutral Point of View policy, no notability gate,
and no footnote-citation infrastructure where references are
load-bearing rather than decorative. A Notion knowledge base degrades
to informal, inconsistent prose at scale because there is no editorial
constitution enforcing it.

### Confluence (atlassian.com/software/confluence)

Confluence in 2026 is "An AI-powered workspace — One place for all
your ideas, docs, knowledge, and teammates," backed by Atlassian's
Gartner Magic Quadrant Leader designation. The article shell is a
Confluence page in nested spaces with structured templates. Reviewer
consensus: native search returns broad, poorly-ranked results; without
governance, pages sprawl and go stale; simultaneous-edit conflicts
corrupt content; permission model is complex enough to drive new-user
abandonment. At encyclopedic scale Confluence has no equivalent of
Wikipedia's category graph, "What links here," or Manual of Style — the
knowledge graph is a flat filing cabinet rather than a navigable
semantic network.

### Coda (coda.io)

Coda is "Your all-in-one collaborative workspace" combining docs,
databases, and applications. The article shell blends document and
spreadsheet — packs of tables, buttons, formulas, and automations
co-exist on a page. The encyclopedic-depth gap: Coda's structural power
is relational (cross-doc formulas, synced tables) — useful for project
tracking, but creates no stable article-topology. There is no article
schema discipline, no citation surface, no Talk-layer, and no discovery
mechanism beyond search.

### ClickUp Docs (clickup.com/features/docs)

ClickUp positions Docs as "Beautiful, collaborative docs right where
you work" — explicitly contextual knowledge management embedded in task
and project management. The article shell is a nested-pages rich text
editor with task-embedding. The encyclopedic gap is structural by
design: docs live inside projects and inherit project context; there is
no concept of a standalone encyclopedic article. Real-time
collaboration degrades above five concurrent editors.

### Wiki.js (js.wiki)

Wiki.js is "The most powerful and extensible open source Wiki software"
— self-hosted Node.js, Markdown / visual / HTML editors, with storage
backends including Git, AWS, Azure, and 50+ authentication
integrations. Current stable v2.5.312. Encyclopedic gap: Wiki.js has
the right bones (version history, multi-language, wikilinks) but ships
no editorial governance layer — no NPOV policy, no notability criteria,
no Manual of Style enforcement, no Talk-page infrastructure in the
Wikipedia sense, and no red-link system. A powerful authoring engine
that requires an editorial culture to be built entirely from scratch on
top.

### BookStack (bookstackapp.com)

BookStack is "Simple & Free Wiki Software" — self-hosted PHP/Laravel,
MIT licensed, content organised in Books → Chapters → Pages. The
article shell is a WYSIWYG page in a rigid three-tier hierarchy. The
hierarchical model is the central limitation at encyclopedic scale:
Wikipedia's article graph is a flat namespace with a category overlay,
not a tree. Knowledge does not respect a single hierarchy. BookStack
works well for documentation with clear ownership but collapses under
cross-cutting topics that belong to multiple conceptual parents
simultaneously.

### Outline (getoutline.com)

Outline is "Your team's knowledge base" — team-oriented with real-time
multiplayer editing, AI-powered search, Slack integration, cloud or
self-hosted. The article shell is a Notion-like block editor with
Markdown and slash commands. The encyclopedic gap mirrors Notion's:
Outline is a private-team tool with no public-epistemics layer. No
citation surface, no Talk-page equivalent, no category graph, no
red-link system.

### MediaWiki (mediawiki.org)

MediaWiki is the reference implementation — Wikipedia's engine.
Structural primitives: flat article namespace; `[[wikilink]]` with
red-link signalling; category graph; Talk: namespace per article;
Special:Random; Special:WhatLinksHere; Special:RecentChanges; full
revision history; Wikidata integration; citation template system where
references are structurally load-bearing. The platform runs "tens of
thousands of websites." The 2026 gap is the opposite of competitors:
it has the structural depth, but a 2000s-era UX that new contributors
find hostile. The visual editor exists; the learning curve for template
syntax, Lua modules, and citation formatting remains steep.

### Fandom (fandom.com)

Fandom is a MediaWiki-based platform hosting fan wikis for games,
film, TV, and entertainment properties. New CEO Jay Sullivan (appointed
February 2026) brings a background from Mozilla, Twitter, and Facebook.
The article shell is MediaWiki with Fandom-specific extensions:
interactive maps, Table Progress Tracking, Game Companion tools.
Encyclopedic gap: Fandom inherits MediaWiki's structural depth but
deploys it inside an ad-supported commercial context, driving the
ongoing migration of communities to independent wikis. Audience and
scope are fanbase-specific rather than general; the commercial ad
overlay creates trust and UX friction.

### Wikidot (wikidot.com)

Wikidot is a cloud-hosted wiki-site builder with 106 million pages,
10.3 million registered users, and 24,653 daily edits, on a freemium
model. Encyclopedic gap: stagnation. No significant platform updates
in years; non-standard syntax; community ecosystem fragmented. Notable
deployments maintain their own editorial cultures independent of
platform tooling. A maintenance-mode product rather than an advancing
platform.

### DokuWiki (dokuwiki.org)

DokuWiki is a flat-file PHP-based wiki platform that stores content
in plain text files rather than a database — easy to back up,
version-control externally, and migrate. Preferred for intranet
technical documentation among sysadmin communities. Encyclopedic gap:
flat-file storage without structured metadata or semantic graph means
cross-article discovery is search-only. No category graph, no red
links, no Talk pages in the MediaWiki sense.

### TiddlyWiki (tiddlywiki.com)

TiddlyWiki v5.4.0 is "a non-linear personal web notebook" —
self-contained, single-HTML-file knowledge system. The fundamental
primitive is the tiddler (an atomic note); structure is entirely
graph-based via linking. The UX is maximally personal and maximally
unfamiliar to new readers. No concept of a public-facing article
optimised for readers who are not the author.

### Docusaurus (docusaurus.io)

Docusaurus is Meta's React/MDX-based static site generator: "Build
optimized websites quickly, focus on your content." Target: open-source
projects and technical documentation teams. The article shell is an MDX
page rendered to static HTML with sidebar navigation, versioning, and
Algolia search. Encyclopedic gap: Docusaurus generates a docs site,
not a wiki. No inter-article linking discovery, no red links, no Talk
pages, no category graph, no collaborative in-browser editing. Every
Docusaurus site looks structurally identical because it ships a single
enforced layout.

### MkDocs Material (squidfunk.github.io/mkdocs-material)

MkDocs Material is "Documentation that simply works" — Python-based
static site generator with 50,000+ users, instant browser-side search,
responsive layout, extensive theming. **Entered maintenance mode
November 2025** — bug fixes and security patches continue, no new
features. Same encyclopedic gap as Docusaurus: docs site, not wiki.
Navigation primitive is a fixed sidebar tree which cannot represent a
multi-parent category graph.

### VitePress (vitepress.dev)

VitePress is "Markdown to beautiful docs in minutes" — Vue/Vite-powered
with hot-reload. The article shell is a Markdown file with Vue-powered
layout, sidebar, theme. Powers Vue's own documentation. Encyclopedic
gap: same category as Docusaurus. "Beautiful docs in minutes" is
precisely the wrong metric for encyclopedic reference — it optimises
for designer-smooth surfaces rather than structural rigour.

### Nextra (nextra.site)

Nextra is "Simple, powerful and flexible site generation framework"
built on Next.js and MDX — the Next.js-ecosystem equivalent of
Docusaurus. Server Components and ISR support give it rendering
flexibility beyond typical static generators. Encyclopedic gap:
developer documentation tool with no wiki primitives.

### Fumadocs (fumadocs.dev)

Fumadocs is "Build excellent documentations, your style" — React.js
documentation framework for component libraries and developer tools,
with minimal aesthetics, headless customisation, React Server
Components. Endorsed by Vercel engineers and shadcn/ui's creator.
Encyclopedic gap: explicitly positioned at component-library
documentation; no public-wiki primitives, no editorial governance
surface, no reader-navigation affordances beyond sidebar and search.

### Astro Starlight (starlight.astro.build)

Starlight is "Make your docs shine" — Astro's documentation site
builder with built-in i18n, search, dark mode, sidebar, accessibility
focus. Framework-agnostic via Astro's island architecture. Encyclopedic
gap: same category as Docusaurus and VitePress. The accessibility
emphasis is a floor requirement, not a differentiator for encyclopedic
depth.

### GitBook (gitbook.com)

GitBook in 2026 is "Turn documentation into your product's knowledge
system" — a commercial SaaS documentation platform with AI Agent
monitoring, Git Sync, embedded AI assistants, SOC2/ISO27001 compliance.
The 2026 pivot to "AI-ready docs" and "knowledge system" language
positions it against internal company knowledge tools rather than
public encyclopedias. Encyclopedic gap: closed-source, commercially
oriented, migrated away from open-source roots. No Talk-page model, no
red-link mechanism, no NPOV policy surface, no category graph.

### Read the Docs (about.readthedocs.com)

Read the Docs is "Docs as Code for everyone" — documentation hosting
and build-automation supporting Sphinx, MkDocs, Docusaurus, Jupyter
Book, others. Provides build pipeline, versioning, PR previews, hosted
search. Encyclopedic gap: an infrastructure platform, not a
knowledge-graph engine. Solves the CI/CD problem for documentation but
adds nothing to article-structure, editorial-governance, or
navigation-primitive dimensions.

### Obsidian Publish (obsidian.md/publish)

Obsidian Publish is "$8/month per site — The easiest way to publish
your wiki, knowledge base, documentation, or digital garden." Converts
local Obsidian vaults into public-facing sites with hover previews,
stacked pages, backlinks, graph view. The article shell is a Markdown
note with `[[wikilinks]]` and frontmatter — structurally the closest
of any Group D tool to Wikipedia's article model. Encyclopedic gap:
single-author publication tool, not a multi-author collaborative wiki.
No collaborative in-browser editing, no Talk-page discussion layer, no
NPOV enforcement, no notability gate, no community moderation
infrastructure.

### Roam Research (roamresearch.com)

Roam Research is "A note taking tool for networked thought" — the
originator of the modern bidirectional-link paradigm at $15/month,
significantly more expensive than alternatives while offering less
customisation. By 2026 Logseq has absorbed most of Roam's market. The
article shell is a page of nested bullets with `[[wikilinks]]` and
block references, optimised for the author's non-linear associative
workflow. Encyclopedic gap: a personal thought-capture tool. The
structural model is explicitly anti-encyclopedic — no article-length
atomic unit, no concept of a reader who is not the author.

### Logseq (logseq.com)

Logseq is "A privacy-first, open-source knowledge base" — local-first,
open-source, block-based, with bidirectional links, graph view,
Org-mode/Markdown support. In 2026 "the better choice" over Roam due
to free tier and open codebase. Encyclopedic gap: same as Roam. The
block-outline model is a personal-knowledge primitive, not an
encyclopedic-article primitive. Multi-author collaborative publishing
is not a supported workflow.

### Capacities (capacities.io)

Capacities is "A studio for your mind" — a personal knowledge
management system built on typed objects rather than files in folders.
Object-based relationship modelling surfaces connections automatically
via "Related Content." Funded by users rather than venture capital;
EU-hosted with full data export. The article shell is a typed object
with properties, linked to other typed objects — the most semantically
rich data model in Group D. Encyclopedic gap: explicitly
individual-focused; no collaborative editing, no public-epistemics
model, no article-level citation infrastructure, no community
governance layer.

### Quartz v4 (quartz.jzhao.xyz)

Quartz v4 is "a fast, batteries-included static-site generator that
transforms Markdown content into fully functional websites" — targeting
students, developers, and teachers publishing personal notes and
digital gardens. Native Obsidian compatibility, `[[wikilinks]]`, graph
visualisation, LaTeX, popover previews, full-text search. Encyclopedic
gap: a single-author static site generator. Ships graph view and
backlinks natively (more than most competitors) but no collaborative
editing, no Talk-page layer, no notability mechanism, no NPOV
infrastructure, no red-link system.
The PointSav documentation wiki at `documentation.pointsav.com` is one entrant in a
field where a large number of distinguishable providers ship some variation of
"wiki-shaped knowledge surface" today. Most of them are not encyclopedic-knowledge
platforms; they are private-team productivity tools, developer-documentation site
generators, or personal-knowledge networked-thought systems. None of them has replaced
Wikipedia for general-knowledge encyclopedic depth. This article documents the field by
structural archetype, names the structural reasons no archetype has closed the gap, and
identifies the genuine advantages each archetype has over Wikipedia — features worth
preserving as the [[app-mediakit-knowledge|substrate]] iterates.

The audit is structural, not promotional. Each archetype is described factually by its
strongest published positioning pattern and the structural limitation that prevents it
from filling the encyclopedic-knowledge gap. The conclusion is not "PointSav wins"; it
is "the gap is structural and is not closing under the current commercial-incentive
structure of the wiki market."

## 1. The four archetypes

Providers in this space cluster into four archetypes by target use case.

- **Archetype A — Collaborative knowledge bases.** Built for private organisational
  knowledge management. Sell seat licenses to enterprise IT. The article shell is
  typically a free-form block canvas — headings, callouts, toggles, inline databases —
  with no fixed structure and no enforced schema.
- **Archetype B — Public-facing wiki engines.** The closest in shape to a
  Wikipedia-class platform; widest variance in editorial governance across this
  archetype. Some ship real version history, multi-language support, and wikilinks;
  none ship a full editorial-governance layer out of the box.
- **Archetype C — Developer documentation site generators.** Generate documentation
  sites for software projects; static-site-first, collaborative-editing second or none.
  The article shell is typically a Markdown or MDX file rendered to static HTML with
  sidebar navigation and search.
- **Archetype D — Personal and networked-thought tools.** Single-author
  personal-knowledge management primarily, with some publish-to-web surfaces. The
  article shell is typically a block or bullet-outline page optimised for the author's
  own associative workflow, not a reader who is not the author.

## 2. What each archetype does and doesn't do

### Archetype A — Collaborative knowledge bases

The article shell blends free-form blocks, nested pages, and — in some products —
spreadsheet-like relational tables (cross-document formulas, synced data) alongside
prose. The encyclopedic-depth gap is categorical across this archetype: no concept of a
canonical article namespace, no red-link discovery, no Talk-page editorial debate, no
Neutral Point of View policy, no notability gate, and no footnote-citation
infrastructure where references are load-bearing rather than decorative. A knowledge
base in this archetype degrades to informal, inconsistent prose at scale because there
is no editorial constitution enforcing it. Reviewer consensus across the archetype:
native search returns broad, poorly-ranked results without governance; pages sprawl and
go stale; permission models are complex enough to drive new-user abandonment at scale.

### Archetype B — Public-facing wiki engines

This archetype has the right structural bones in the strongest cases — version history,
multi-language support, wikilinks, self-hosting, pluggable storage backends — but ships
no editorial-governance layer by default: no NPOV policy, no notability criteria, no
Manual-of-Style enforcement, no Talk-page infrastructure in the Wikipedia sense, and
(in the weaker cases) no red-link system at all. A powerful authoring engine still
requires an editorial culture built entirely from scratch on top of it. The reference
implementation in this archetype (the software Wikipedia itself runs on) is the
opposite case: it has the full structural depth, but a dated interface that new
contributors find hostile — the learning curve for markup, extension modules, and
citation formatting remains steep. Fan/community-hosted deployments in this archetype
add commercial ad layers that create trust and UX friction on top of an otherwise
capable engine. Some products in this archetype are in maintenance mode rather than
active development; a stagnant platform inherits this archetype's structural strengths
without gaining any of its possible fixes.

### Archetype C — Developer documentation site generators

The article shell is a Markdown or MDX file rendered to static HTML with sidebar
navigation, versioning, and search. Every site in this archetype tends to look
structurally identical, because most ship a single enforced layout — this is the
documentation aesthetic every engineering team recognises, and it is also what a
Wikipedia reader does *not* associate with encyclopedic authority. Encyclopedic gap
across the archetype: no inter-article linking discovery, no red links, no Talk pages,
no category graph, no collaborative in-browser editing. These are docs sites, not
wikis — solving the CI/CD and rendering problem for a documentation set, not the
knowledge-graph or editorial-governance problem an encyclopedia needs.

### Archetype D — Personal and networked-thought tools

The article shell is a page of blocks or nested bullets, often with bidirectional
linking and a graph view — genuinely the most semantically rich data model of the four
archetypes in the strongest cases. Encyclopedic gap: a personal thought-capture or
single-author publication tool. No collaborative in-browser editing, no Talk-page
discussion layer, no NPOV enforcement, no notability gate, no community-moderation
infrastructure. The structural model is explicitly anti-encyclopedic in the more
associative products — no article-length atomic unit, no concept of a reader who is
not the author.

## 3. Cross-cutting failure modes

The eight structural reasons no provider in this audit has replaced
Wikipedia for general encyclopedic knowledge:

**(i) Audience mismatch.** Notion, Confluence, Coda, ClickUp, Outline,
and BookStack were built for private organisational knowledge
management. Access-control model, pricing model, and UX assume a known
trusted team. Public-encyclopedic publishing requires the opposite —
anonymous editors, verifiable sourcing, reader-first navigation. These
products cannot pivot without dismantling their commercial model.

**(ii) No editorial constitution.** Wikipedia's NPOV, Notability,
Reliable Sources, No Original Research, and Manual of Style constitute
a multi-decade-refined editorial constitution. No provider in this
audit ships an equivalent. The absence is a missing governance
organisation, not a missing feature.

**(iii) Information density floor.** Docusaurus, MkDocs, VitePress,
GitBook, and Obsidian Publish optimise for prose elegance, developer
aesthetics, and clean typography. Wikipedia articles are deliberately
dense — infoboxes, hatnotes, references with 100+ footnotes, navboxes,
stub tags, disambiguation pages. No documentation site generator ships
this density model because target users actively want the opposite.

**(iv) Navigation primitive missing.** Wikipedia's navigation stack —
`[[wikilink]]` with red-link signalling, Special:Random,
Special:WhatLinksHere, category graph, disambiguation pages, navbox
templates, sister-project interlinking — exists complete in MediaWiki
and at most one or two members elsewhere. Most competitors do not even
ship the red-link mechanism, which is structural to Wikipedia's growth
model.

**(v) Citations are decorative, not load-bearing.** Wikipedia's
footnote system makes claims verifiable at the statement level. Across
Group A, C, and D providers, citations are absent entirely, implemented
as inline hyperlinks with no formal structure, or supported as
page-level frontmatter rather than claim-level.

**(vi) No Talk-page substrate.** Each Wikipedia article has a Talk:
page that is the public record of editorial dispute. Confluence and
Notion have inline comments — not archived public editorial debate.

**(vii) Structural brittleness.** Notion's block format, Coda's pack
structure, and ClickUp's embedded docs are proprietary serialisation
formats. Content created in 2020 is at vendor-lock-in risk by 2026.
Wikipedia's wikitext is plain text that can be exported, archived, and
mirrored.

**(viii) Template homogenisation.** Every Docusaurus, Starlight,
VitePress, and MkDocs site looks structurally identical. This is the
documentation aesthetic every engineering team knows. It is also what
a Wikipedia reader does *not* associate with encyclopedic authority.

## 4. What each provider does better than Wikipedia

The honesty floor of the audit. Each provider has a genuine advantage
over Wikipedia in some dimension. The leapfrog candidates worth
considering:

| Provider | Genuine advantage |
The eight structural reasons no archetype in this landscape has replaced Wikipedia for
general encyclopedic knowledge:

**(i) Audience mismatch.** Archetypes A and C were built for different publics —
private organisational knowledge management and software-project documentation,
respectively. Public-encyclopedic publishing requires the opposite: anonymous editors,
verifiable sourcing, reader-first navigation. Archetype A products in particular cannot
pivot without dismantling their commercial model.

**(ii) No editorial constitution.** Wikipedia's NPOV, Notability, Reliable Sources, No
Original Research, and Manual of Style constitute a multi-decade-refined editorial
constitution. No archetype in this audit ships an equivalent as a product feature. The
absence is a missing governance organisation, not a missing feature.

**(iii) Information density floor.** Archetype C tools optimise for prose elegance,
developer aesthetics, and clean typography. Wikipedia articles are deliberately dense —
infoboxes, hatnotes, references with 100+ footnotes, navboxes, stub tags,
disambiguation pages. No documentation site generator ships this density model because
its target users actively want the opposite.

**(iv) Navigation primitive missing.** Wikipedia's navigation stack — wikilinks with
red-link signalling, a random-article surface, "what links here," a category graph,
disambiguation pages, navbox templates, sister-project interlinking — exists complete
only in Archetype B's reference implementation, and at most partially elsewhere. Most
providers across all four archetypes do not even ship the red-link mechanism, which is
structural to Wikipedia's own growth model.

**(v) Citations are decorative, not load-bearing.** Wikipedia's footnote system makes
claims verifiable at the statement level. Across Archetypes A, C, and D, citations are
absent entirely, implemented as inline hyperlinks with no formal structure, or
supported as page-level frontmatter rather than claim-level.

**(vi) No Talk-page substrate.** Each Wikipedia article has a Talk page that is the
public record of editorial dispute. Archetype A tools have inline comments — not
archived public editorial debate.

**(vii) Structural brittleness.** Several Archetype A products use proprietary
block/table/document serialisation formats — content created today is at
vendor-lock-in risk years out. Wikipedia's wikitext is plain text that can be
exported, archived, and mirrored by anyone.

**(viii) Template homogenisation.** Archetype C sites tend to look structurally
identical to one another. This is a documentation aesthetic every engineering team
knows. It is also what a Wikipedia reader does *not* associate with encyclopedic
authority.

## 4. What each archetype does better than Wikipedia

The honesty floor of the audit. Every archetype has genuine advantages over Wikipedia
in some dimension. The leapfrog candidates worth considering, by archetype:

| Archetype | Genuine advantages worth preserving |
|---|---|
| Notion | Inline @-mentions linking people, tasks, dates inside prose; database-as-page model embedding live structured data |
| Confluence | Macro ecosystem for dynamic content embedding (Jira ticket status, roadmaps); enterprise SSO and granular permissions |
| Coda | Cross-document formula language: relational knowledge made visible without a separate database |
| ClickUp Docs | Contextual attachment: docs live adjacent to the tasks they describe |
| Wiki.js | Git-backed storage: every article version is a git commit, fully portable and diffable with standard tooling |
| BookStack | Operational simplicity: runs on a $2.50 VPS with a single PHP install — lowest cost-to-first-article of any self-hosted wiki engine |
| Outline | Real-time multiplayer editing with operational-transform conflict resolution; smoother concurrent editing than MediaWiki's section-locking |
| MediaWiki | Everything that is the benchmark — full navigation primitive stack, NPOV enforcement, category graph, Talk pages, Wikidata integration |
| Fandom | Interactive maps and progress-tracking tables embedded natively in wiki articles; best media-gallery integration |
| Wikidot | Community-site builder supporting custom CSS per wiki plus sub-wikis under a shared domain |
| DokuWiki | Zero-database flat-file storage — most portable, least infrastructure-dependent knowledge store |
| TiddlyWiki | Single-file portability — entire knowledge base is one HTML file; extreme durability |
| Docusaurus | MDX: React components embedded in Markdown enabling interactive documentation (live code playgrounds, API sandboxes) |
| MkDocs Material | Instant client-side search with offline support and zero external dependencies; fastest search-to-result |
| VitePress | Hot-module reload during authoring: sub-second preview updates as you write |
| Nextra | Server Components: docs pages can fetch live data at render time |
| Fumadocs | Headless architecture: complete design-system override without forking |
| Astro Starlight | Island architecture: zero JavaScript shipped by default; best Lighthouse scores |
| GitBook | Git bidirectional sync: write in IDE or visual editor; both stay synchronised |
| Read the Docs | PR preview builds with visual diffs |
| Obsidian Publish | Graph view with hover-preview; most visually legible representation of a personal knowledge graph |
| Roam Research | Block-level transclusion: any block embeddable by reference into any other document |
| Logseq | Free plus open-source plus local-first with bidirectional links — the combination Roam never offered |
| Capacities | Typed objects with automatic relationship discovery — closest to a semantic knowledge graph |
| Quartz v4 | Native Obsidian vault publishing with wikilinks, popover previews, graph view in a static site |

Three of these advantages are particularly worth integrating into a
Wikipedia-class chrome without breaking the muscle-memory contract:
MkDocs Material's instant client-side search; Capacities' typed-object
relationship surface rendered as navigable article metadata; and
Obsidian Publish's hover-preview popover on `[[wikilinks]]`.
| A — Collaborative knowledge bases | Inline mention-linking of people/tasks/dates inside prose; relational cross-document data made visible without a separate database; contextual attachment of documents to the work items they describe; enterprise SSO and granular permissions; macro-style embedding of dynamic content |
| B — Public-facing wiki engines | The full reference-implementation navigation stack (NPOV enforcement, category graph, Talk pages, structured cross-reference integration); git-backed storage in the stronger self-hosted products (every article version a portable, diffable commit); real-time multiplayer editing with better conflict resolution than section-locking in some products; lowest cost-to-first-article of any self-hosted engine in the simplest products; community-site building with custom styling and sub-sites |
| C — Developer documentation site generators | Interactive components embedded in Markdown (live code playgrounds, API sandboxes); instant client-side search with offline support; sub-second hot-reload preview during authoring; server-rendered pages that can fetch live data; headless design-system override without forking; zero-JavaScript-by-default rendering with strong accessibility scores; bidirectional Git sync between IDE and visual editor; PR-preview builds with visual diffs |
| D — Personal and networked-thought tools | Graph view with hover-preview, the most visually legible representation of a personal knowledge graph; block-level transclusion (any block embeddable by reference); typed-object relationship modelling approaching a semantic graph; native vault publishing with wikilinks and popover previews in a static site |

Three of these advantages are particularly worth integrating into a Wikipedia-class
chrome without breaking the muscle-memory contract: Archetype C's instant client-side
search; Archetype D's typed-object relationship surface rendered as navigable article
metadata; and Archetype D's hover-preview popover on wikilinks.

## 5. Why the gold-standard market gap exists in 2026

The gap is structural and has five reinforcing causes.

**Commercial incentive misalignment.** Notion, Confluence, GitBook,
Coda, and ClickUp make money by selling seat licenses to organisations
managing internal knowledge. Their roadmaps are driven by enterprise IT
buyers — investing in NPOV enforcement, Talk-page infrastructure, or
red-link discovery does not convert to enterprise seat revenue.

**The editorial-labour problem cannot be automated.** Wikipedia's
structural authority is twenty years of accumulated editorial labour.
Generated content cannot replicate the transparent editorial process,
source verification standards, or community governance that make
Wikipedia trusted. Replicating the credibility surface requires
replicating the governance — and no commercial entity has bootstrapped
that from a product launch.

**Open-source coordination cost.** MediaWiki's codebase is 25 years
old, carries enormous legacy compatibility surface, and requires
sustained foundation resources to maintain. No independent open-source
project has shipped a "MediaWiki v2 with modern UX" because the
coordination cost is prohibitive.

**Scope creep on one side, narrow scope on the other.** Group A
providers expanded into "everything platforms"; their knowledge-base
features compete with AI agents, project management, and enterprise
integrations. Group C providers are deliberately minimal static-site
generators — no collaborative editing model by design.

**The "Wikipedia muscle memory" gap.** No competitor has invested in
replicating the specific reader-navigation UX that billions of
Wikipedia users know by reflex. This is an information-architecture
commitment, not a CSS problem. Documentation sites ship sidebars
because their readers navigate a product's API. Encyclopedia readers
arrive from search, orient via the infobox, follow blue links
**Commercial incentive misalignment.** Archetype A and several Archetype C vendors
make money by selling seat licenses to organisations managing internal knowledge or
developer productivity. Their roadmaps are driven by enterprise IT buyers — investing
in NPOV enforcement, Talk-page infrastructure, or red-link discovery does not convert
to enterprise seat revenue.

**The editorial-labour problem cannot be automated.** Wikipedia's structural authority
is twenty years of accumulated editorial labour. Generated content cannot replicate the
transparent editorial process, source verification standards, or community governance
that make Wikipedia trusted. Replicating the credibility surface requires replicating
the governance — and no commercial entity has bootstrapped that from a product launch.

**Open-source coordination cost.** The reference public-wiki engine's codebase is 25
years old, carries enormous legacy compatibility surface, and requires sustained
foundation resources to maintain. No independent open-source project has shipped an
equivalent engine with a modern UX because the coordination cost is prohibitive.

**Scope creep on one side, narrow scope on the other.** Archetype A providers expanded
into "everything platforms"; their knowledge-base features compete with AI agents,
project management, and enterprise integrations. Archetype C providers are
deliberately minimal static-site generators — no collaborative editing model by
design.

**The "Wikipedia muscle memory" gap.** No competitor across any archetype has invested
in replicating the specific reader-navigation UX that billions of Wikipedia users know
by reflex. This is an information-architecture commitment, not a CSS problem.
Documentation sites ship sidebars because their readers navigate a product's API.
Encyclopedia readers arrive from search, orient via the infobox, follow blue links
sideways, and exit via categories.

## 6. What this means for documentation.pointsav.com

Closing the gap requires simultaneously building governance software, a
navigation primitive set, and an editorial culture. PointSav's
substrate-sovereignty design, three-tier compute routing under the
optional [[four-tier-slm-substrate|Intelligence Layer]], [[apprenticeship-substrate|apprenticeship-corpus capture]], and the
editorial pipeline are the three preconditions no commercial competitor
can simultaneously match.
Closing the gap requires simultaneously building governance software, a navigation
primitive set, and an editorial culture. PointSav's substrate-sovereignty design,
three-tier compute routing under the optional [[four-tier-slm-substrate|Intelligence
Layer]], [[apprenticeship-substrate|apprenticeship-corpus capture]], and the editorial
pipeline are the three preconditions no commercial competitor can simultaneously match.

The wiki engine [[app-mediakit-knowledge]] is intended to become the
customer-installable demonstration of that substrate. The structural
argument for the leapfrog claim is what this article documents: the gap
exists because of the five structural causes above; closing it requires
the three preconditions above; the substrate has those preconditions as
design intent. The award framings in knowledge-wiki-home-page-design
§5 and article-shell-leapfrog §5 are the planned downstream
consequences.
customer-installable demonstration of that substrate. The structural argument for the
leapfrog claim is what this article documents: the gap exists because of the five
structural causes above; closing it requires the three preconditions above; the
substrate has those preconditions as design intent. The award framings in
knowledge-wiki-home-page-design §5 and article-shell-leapfrog §5 are the planned
downstream consequences.

## 7. Open editorial item

This audit was conducted in April 2026 with primary research across
all 25 providers. Provider positioning shifts; an annual re-audit cadence
is planned to keep this article current. The next re-audit is intended
for approximately April 2027. If a provider in this list ships a
structural change between audits — for example, MediaWiki ships a
modern UX layer, or Wiki.js adds NPOV-style editorial discipline — this
article is amended in transit. Forward-looking framings carry stated
assumptions and cautionary language per NI 51-102 and OSC Staff Notice
51-721.
This audit was conducted in April 2026 with primary research across the market. Vendor
positioning shifts; an annual re-audit cadence is planned to keep this article current.
The next re-audit is intended for approximately April 2027. If a provider in any
archetype ships a structural change between audits — for example, an Archetype B
reference implementation ships a modern UX layer, or another Archetype B product adds
NPOV-style editorial discipline — this article is amended in transit. Forward-looking
framings carry stated assumptions and cautionary language per NI 51-102 and OSC Staff
Notice 51-721.

## See also