← all posts

2026-10-02

The Drupal flywheel: talking louder is not enough

Dries says talk louder. I agree. But I think we need to make it more systematic.

At DrupalCon Rotterdam, Dries Buytaert made a point that stuck with me: Drupal is light-years ahead of its reputation. The platform has moved fast. The community has built remarkable things. But almost nobody outside the community knows about them. His call to action was simple: talk louder.

I agree. But I think talking louder is a behaviour, and behaviours are fragile. What we actually need is a system.

The original Drupal flywheel (2024)

Diagram of the original Drupal AI flywheel (2024): More Makers leads to More budget in Drupal AI, then More Features, then Building More Cases (highlighted in red), then More demand from customers, back to More Makers

I first presented this flywheel at the Drupal Dev Days in Leuven, at the conception of the Drupal AI initiative. It was a re-do of a keynote I had given in Burgas. The idea: more makers attract more budget, more budget delivers more features, more features generate more cases, and more cases drive more demand. A self-reinforcing loop around the Drupal AI ecosystem.

The weakest link was always the cases step. It depends on someone deciding to build and tell the story. That decision rarely happens automatically.

Since then, the Drupal community has moved fast. There are now many AI features in the platform, and the first real success cases are starting to appear. The flywheel has started turning. The question is how to make it spin faster.

Six months ago: a second flywheel

Diagram of a newer Drupal flywheel (2026): New users (easy to migrate to Drupal) leads to Keep them (easy editor experience), then Easy to tell more stories, then Reach more people (more eyes on us), back to New users

Six months ago I drew a second flywheel, focused on user growth: easy migration brings new users in, a good editor experience keeps them, happy users tell stories, and those stories reach more people. Same principle, different angle.

The bottleneck is the same in both flywheels: storytelling. Someone has to decide to do it.

Dries also understands it: Talk Louder

Dries sees the same problem. In the Driesnote he called it out directly: the product is good, the stories are not getting out. His answer is to talk louder, and the community is picking it up. The Drupal Advocacy program is one concrete example of people moving this forward.

That is good. But it depends on people. And anything that depends on people is only as consistent as the people doing it. Coding standards work not because developers remember to care about them, but because tools help users or enforce them automatically. The moment you rely on individual motivation to keep a system running, you have introduced a bottleneck.

People move on. Priorities shift. Energy runs out. A process that requires human initiative every single time will always be slower than one that just runs.

Making it automatic

This is where I think the community can go further. Two ideas:

Option 1: crawl and propose. An external service crawls the web, identifies sites built on Drupal, and generates a draft case study: the organisation, the scale, the visible features. It then sends a simple message to the site owner: we noticed your site runs on Drupal. We drafted a case study. Do you want to submit it? The barrier is low, the draft is done, and they get visibility for free.

Option 2: opt in at build time (my favourite). When creating or managing a Drupal site, you enter your Drupal.org ID. After a few months, the site drafts a case study of itself, attributes the credits to you and your agency, and proposes submission. AI can prep the draft. You just review and approve.

Option 3: a "Drupal Case" module in core. This is where it gets interesting. A native Drupal module that pings a remote case-making API. After six months on a site, it shows the admin a simple prompt:

The AI option is the one I find most compelling. It removes every barrier: no writing, no decisions about what to include, no navigating an external tool. The site owner gets the draft back in their admin interface. They can edit it, or just submit it as-is.

Both approaches share the same logic: remove the moment where someone has to decide to start. That decision is where most cases die.

I am not sure what the exact answer looks like. But I am convinced this is the direction. If we want to scale Drupal's reach without making people the bottleneck, we have to make it frictionless to turn a site or project into a case.

Dries is right that we need to talk louder. But loud voices come and go. A system keeps going.

Written with assistance from Dobbie, Frederik's AI assistant.

Frederik Wouters Frederik Wouters · frederikwouters.be
Published: 2026-10-02 18:44