Drupal CMS (Starshot) and the Modern CMS Race

Archive note: this is a backdated post, written years later while rebuilding this site. It’s dated to the moment it covers, but the hindsight is real.

A confession this blog has underserved: roughly half my professional life is Drupal. The Laravel posts get the annual-release glamour, but client-side, enterprise content work has kept me deep in Drupal for years — so the Starshot initiative, announced at DrupalCon this year and now taking shape as Drupal CMS (targeting a 1.0 around January), deserves the same coverage.

The problem Starshot admits out loud

Drupal’s open secret: it won the capability war and lost the first-hour war. Out of the box, core Drupal is a magnificent box of parts — and a new evaluator stares at it like a flat-pack wardrobe with no manual. The real product has always been “Drupal plus the fifty contrib modules every expert installs by reflex” — and that recipe lives in agency muscle memory, not in the download. Meanwhile WordPress owns “publish in an afternoon,” and the headless upstarts own the JS-framework mindshare. Evaluators bounce in the gap; market share erodes from the bottom while the high end stays loyal.

Drupal CMS is the recipe, shipped. A product built on core: sensible defaults, the essential contrib pre-assembled, recipes for common site types, browser-based trial, and — the part that has my attention — AI agents for site building, scaffolding content types and configuration from natural-language intent. Dries has framed the ambition plainly: make the ambitious site builder’s first day delightful, not archaeological.

Why I think this is the right bet

1. It’s productization, not capitulation. The framework-vs-product tension kills platforms that pick wrong. Drupal’s answer — keep core as the framework, ship an opinionated product beside it — is the same maturity move as Laravel slimming its skeleton while keeping its power: meet newcomers where they are without amputating what experts came for.
2. The structured-content thesis is aging well. The decade bet on “content as wild HTML in a box” (WordPress’s instinct) versus “content as structured, queryable entities” (Drupal’s religion) just found its decider: AI systems consuming and generating content need structure. Clean entity models, typed fields, real relationships — the unfashionable rigor is suddenly the machine-readable foundation everyone wants. Drupal accidentally spent fifteen years preparing for this.
3. The AI site-building angle is honest about who builds sites now. Most sites are assembled, not engineered. Agents doing the assembly on top of a structured platform is a far saner proposition than agents extruding novel code — the rails constrain the hallucinations. It’s the scoped-agent pattern with a CMS as the sandbox.

The honest risks

Naming them, because advocacy without skepticism is marketing: distribution-style efforts have disappointed in Drupal’s past (veterans remember); an opinionated layer can fork community attention from core; and the launch window puts a 1.0 against incumbents with a decade of onboarding polish. The differentiator has to be that first hour, sustained — a great trial that hands off to the old archaeology solves nothing.

But for the first time in years, the project is competing for the evaluator rather than lecturing them about node types. For those of us with a foot in each ecosystem, the convergence is satisfying: every mature platform is reaching the same conclusion from different directions — power earns its keep only when the first day is kind. January will show whether Drupal’s version lands. My client work, and a long-overdue “Drupal vs Laravel: when to pick which” post, are both watching.