Extreme-BDD
A straight comparison

The Extreme-BDD board next to every project tool you’ve used.

Most planning tools treat the ticket database as the source of truth. Extreme-BDD treats the BDD scenario as the source of truth, then shows it on a board and mirrors it into Radicle issues. The matrix below shows what that swap really changes.

“GitHub Projects + Cucumber feature files + decentralized issue tracking + Radicle patch discovery + a seed-safe board viewer.”

Feature-by-feature matrix

Green ✓ = built-in. Amber · = partial or needs an add-on. Red × = not built on purpose. DIFF = there, but built in a different shape. The Extreme-BDD column is highlighted because this is its home turf.

Feature Extreme‑BDD Hermes Kanban GitHub Projects + Issues Jira / Linear Trello / Asana / Notion Plane / OpenProject / Taiga Gitea / Forgejo / sourcehut git‑bug / Fossil Generic Radicle UIs ngit / gitworkshop (NIP‑34)
Card body is the BDD Given/When/Then × × × × × × × × ×
Canonical backlog is repo files, not a hosted database DIFF × × × × × · ×
Board shows uncommitted work (reads the working tree) × × × × × × · × ×
Acceptance criteria travel with the code × × × × × × × ×
No hosted forge / SaaS in the trust path × × × · ·
Self-hostable end to end × × ×
Distributed issue tracking (no central server) × × × × × ×
Kanban / drag-drop board × × ×
Ghost cards for non-canonical branches / patches × × × × × × × × ·
Patch / branch discovery in the board × · × · × ·
Evidence-driven lifecycle (Done requires PMCI/local test status) × × × × × × × × ×
Read-only seed-hosted viewer (no private keys exposed) × × × × × × × ·
Velocity / burndown / Done-week rollups · · · × × ×
Gantt / timeline view × · × × × ×
Custom-fields editor / enterprise workflow admin × · · · · × × ×
Real-time multi-user editing × · × × ·
Zap / payment signal on patches and contributors × × × × × × × × ×
Requires Git/Radicle/BDD literacy DIFF DIFF × × × × DIFF DIFF DIFF DIFF

“Requires Git/Radicle/BDD literacy” is an honest trade-off, not a win. If your team won’t write Given/When/Then, the spec-as-backlog idea can’t work. The rest of the matrix is what you get in exchange.

How each alternative differs

Hermes Kanban

Harness-native task board for named agent profiles, durable SQLite rows, dispatcher-spawned workers, CLI/slash/dashboard control, and kanban_* lifecycle tools.

Hermes Kanban is a real board, but it is a different primitive: the canonical task state lives in Hermes’s Kanban database, not in repo-tracked BDD files. Its strength is agent orchestration — tasks, tenants, workspaces, worker lanes, retries, comments, blocking, completion, and audit trail. Extreme-BDD is stricter about product truth: a card is a BDD scenario in the repository, and Done is projected from current test evidence.

GitHub Projects + Issues

Issues, boards, custom fields, automation, PR linkage.

With GitHub, the issue database is usually the source of truth. Extreme-BDD keeps the backlog in tracked .feature files and mirrors metadata into Radicle issues.

GitLab Issue Boards

Issue cards move through workflow lists, similar to Kanban/Scrum boards.

GitLab is a server-based forge. Extreme-BDD runs on your laptop and uses Radicle. It reads your files, Radicle issues, your DID, who you follow, and updates from gossip.

Jira / Linear

Prioritized work, assignees, workflow states, roadmaps, issue discussions.

These are general project management tools. Extreme-BDD puts the spec first. Cards are BDD scenarios with Given/When/Then acceptance tests built in.

Plane / OpenProject / Taiga

Open-source or self-hostable project management with boards, cycles, roadmaps, and docs.

These tools track work in their own databases. Extreme-BDD keeps the plan next to the code and uses Radicle to share it.

Gitea / Forgejo / sourcehut

Self-hosted forge features: repos, issues, pull/merge requests, projects, CI.

These swap GitHub or GitLab for another forge. Extreme-BDD doesn’t host Git. It’s a workflow layer on top of Radicle repos, issues, patches, and seed viewers.

Generic Radicle clients / web UIs

Radicle repos, issues, patches, identities, and seed visibility.

Generic Radicle UIs show raw forge objects. Extreme-BDD turns those objects into BDD backlog cards, board columns, ghost cards, drift warnings, feedback queues, and “Continue work” commands.

ngit / gitworkshop.dev (NIP‑34)

Decentralized git collaboration over Nostr. Patches, issues, repo state, and clone URLs travel as Nostr events through commodity relays.

ngit is the Nostr-side peer to Radicle. The protocol is NIP‑34: patches are kind‑1617 events, issues are kind‑1621, repo state is kind‑30617/30618. Discovery is real-time over relays you already use for chat and zaps. No kanban, no ghost cards, no Given/When/Then — same patch-discovery shape, different surface. Extreme-BDD adds the board, the BDD lifecycle, and the adoption pill on top, and the ngit / NIP‑34 compatibility epic lets the board accept Nostr-published patches as ghost cards alongside Radicle namespaces. Zaps come along for free as an economic signal next to the technical adoption count.

⨯ on Radicle Read the epic the way the project lives — out of a Radicle clone, not a hosted forge.
rad clone rad:zdUFqQEWVNeMmdzeHpDyHrDpimWm
$EDITOR radicle-priorities/docs/EPIC__NGIT_NIP34_COMPATIBILITY.md
$EDITOR radicle-priorities/bdd/features/ngit_nip34_compatibility.feature

No rad yet? See Getting started for the one-line install. The whole site eats its own dog food — this is how every contributor reads our source.

git-bug / Fossil SCM

Distributed/offline issue tracking tied to version control.

These make decentralized tickets first-class. Extreme-BDD uses Radicle’s issue and patch model. It also keeps .feature scenarios as the backlog and spec.

Trello / Asana / Notion projects

Visual task boards, cards, lists, timelines, lightweight planning.

These tools are detached from the code. Extreme-BDD builds the board straight from repo files, Radicle issue state, test results, and sync state.

radicle-seed-kit complementary

Seed provisioning, private mirroring, restricted tunnels, seed sync, privacy guardrails, Tor/multi-seed resilience, and Circle Source governance.

Seed Kit makes the work available. Extreme-BDD plans the work. It reads BDD scenarios, issues, patches, CI/CD test results, seed status, and gossip state. The two tools ship together.

When this is a good fit

It’s a better fit when your team wants:

It’s a worse fit when your team mainly wants:

Bottom line Most planning tools treat the ticket database as the source of truth. Extreme-BDD treats the BDD scenario as the source of truth, then shows it on a board and mirrors it into Radicle issues. Everything else in the matrix follows from that one swap.