Spec Driven Development Feature Matrix

Table of Contents

This matrix compares the five spec-driven development tools profiled in this section, feature by feature.

The category splits on two axes: who owns the specs (your repo or a platform) and whether the ceremony sizes itself to the change, and the waterfall critique is the standing judge of the second axis, while the new column adds a third question, whether the steward survives their own controversy.

Legend: ✓ supported, ✗ not supported, ~ partial or conditional, ? not verified. Each column links to the full research note; every cell below traces to a source cited there or in the references.

The matrix
#

Feature	BMad Method	GitHub Spec Kit	GSD	OpenSpec	Tessl
Kind	method plus agent workflows, npm install	Python CLI plus slash-command templates	npm command-and-prompt framework, multi-runtime, ecosystem growing around the loop	spec toolkit CLI, npm install	hosted platform, thin CLI
Steward	BMad Code, LLC	GitHub	original archived at TÂCHES (gsd-build), active as Open GSD community	Fission AI	Tessl (Podjarny), $125M raised
License	✓ MIT	✓ MIT	✓ MIT	✓ MIT	✗ closed platform
Artifact model	briefs, specs, architecture carried forward	constitution, spec, plan, tasks files	milestone state persisted as STATE.md, CONTEXT.md, PLAN.md; heavy work in fresh-context subagents	delta proposals archived into a living ledger	specs live on the platform
Workflow entry	`bmad-build` with right-sized depth	`/speckit-constitution` then specify	`/gsd-new-project` or `/gsd-onboard`, then discuss-plan-execute-verify-ship per milestone	`/opsx:propose` then apply and archive	web workflow
Ceremony sizing	✓ right-sizes to the change	✗ fixed ceremony	~ same five-step loop each milestone, lighter quick-task mode	~ fixed but light	? not verified
Brownfield support	✓ establish-context path	~ not the primary case	✓ `/gsd-onboard` for existing repos	✓ explicit design goal	? not verified
Convergence checking	✓ verify and learn loop	✓ converge step	✓ verify phase walks the build before done	~ archive keeps ledger current	? not verified
Unattended execution	✓ BMad Loop module	✗	~ parallel executor waves, human verify step, gsd-loop works a GitHub queue	✗	? not verified
Adoption	about 53.7k stars	about 140k stars	original archived at 64.4k stars; successor 10.1k stars, 43k npm downloads a month	about 71k stars, 2M npm downloads a month	24-point raise thread, thin OSS surface
Pricing	free	free	free	free	free tier plus Team at $100 per month, Enterprise custom

Reading the matrix
#

The license and steward rows tell the ownership story: four repo-native MIT toolkits against one closed, funded platform, and the free tools set the price anchor at zero while Tessl spends $125M betting specs are rentable. The adoption row inverts the funding row, which is the tension to watch. GSD adds the stewardship question the category had not faced: the archived original out-stars every column except Spec Kit, and its 10.1k-star successor is rebuilding trust in public.

Ceremony sizing is the design axis the waterfall critique created: only BMad sends small changes straight to build, and the artifact-first tools pay for their simplicity with fixed ceremony (GSD at least ships a lighter quick-task mode). If your changes are mostly small, that row alone picks your column.

Brownfield is the sleeper row: OpenSpec is explicitly built for existing code, BMad has an establish-context path, GSD’s onboard command covers it, and spec-kit’s scaffolding still assumes a fresher repo than most of us have.

Choosing from the matrix
#

Existing codebase, want the spec ledger to stay current: OpenSpec.
Want a whole delivery process with roles and retrospectives: BMad Method.
Heterogeneous org, zero cost, constitution ceremony acceptable: Spec Kit.
Want a phase loop that quarantines heavy work in fresh-context subagents: GSD, accepting the young successor’s governance.
Want specs as a managed product and accept portability questions: Tessl.

Changes
#

2026-08-27 - Created as a single-column Spec Kit scaffold.
2026-08-27 - Rebuilt to four columns (BMad, OpenSpec, Spec Kit, Tessl) across the ownership and ceremony-sizing axes.
2026-09-16 - Refreshed the Spec Kit adoption cell to about 137k stars after the v1.0.7 release.
2026-09-16 - Extended from four to five columns with GSD (the archived get-shit-done lineage plus the active gsd-core successor), inserted alphabetically, every row gaining a cell, and the reading prose extended to the stewardship question.
2026-09-21 - Refreshed the GSD and OpenSpec adoption cells after their star and npm-download counts moved.
2026-09-24 - Removed the verification preamble line on owner request.
2026-09-25 - Refreshed the Spec Kit (about 139k stars) and GSD (successor 9.8k stars, 40.9k npm downloads) adoption cells.
2026-09-27 - Refreshed the GSD (successor 9.9k stars, 41.2k npm downloads) and OpenSpec (2M npm downloads) adoption cells.
2026-09-29 - Refreshed the BMad (about 54k stars), GSD (41.9k npm downloads), and OpenSpec (about 71k stars) adoption cells; all other cells re-verified unchanged.
2026-10-02 - Refreshed the BMad (about 53.7k stars) and GSD (successor 10.1k stars, 43k npm downloads a month) adoption cells; all other cells re-verified unchanged.