But can It Change People’s Minds?

Drupal has been called plenty of things over the years. Powerful. Flexible. Enterprise-ready.

Easy to use is usually not one of them.

That was my biggest takeaway from Dries Buytaert’s State of Drupal presentation at DrupalCon Rotterdam: Drupal is working hard to close the gap between what the platform can do today and what people remember about it. Dries openly acknowledged that reputation gap as Drupal’s biggest challenge.

The presentation covered visual page building, AI-assisted content management, and more flexibility for developers. There was plenty to like. But watching through both a developer’s and a marketer’s lens, I kept returning to one question:

Will a business owner or marketing director understand how this makes their work easier?

At BigTuna Interactive, we’ve spent more than 20 years helping businesses get more out of Drupal. As a Drupal development agency, we know its strengths, but we also know that an impressive feature needs a clear connection to the problems clients are trying to solve. Otherwise, it turns into a toy that gets abandoned when its novelty wears off.  

Feedback from one of our developers who is newer to Drupal reinforced that point. Some of the things longtime Drupal users take for granted were exactly what caught his attention.

An established strength deserves a fresh introduction

One of his first observations was about Drupal’s open-source ecosystem. He was accustomed to seeing premium plugins, themes, and add-ons, so discovering how much Drupal makes freely available stood out.  This is a core differentiator as you evaluate Wordpress vs Drupal.  

Drupal itself is free and open source, and community-contributed modules and themes hosted on Drupal.org are available under its open-source licensing terms. That gives teams considerable freedom to use, modify, and build on existing work.

That doesn’t mean everything associated with Drupal is free. Commercial offerings can exist, and businesses still need to budget for development, hosting, maintenance, support, and connected services such as AI providers.

Still, access to a substantial library of community-built functionality is a meaningful benefit.

His reaction was a reminder that Drupal’s story doesn’t have to revolve entirely around what’s new. Some of its established strengths deserve a better introduction to people discovering the platform today.

The university demo made AI feel useful

The fictional Northmoor University website was one of the strongest parts of the presentation.

It gave Drupal’s AI capabilities a recognizable setting: a website full of programs, people, policies, and information that needs to stay accurate. The demo showed AI reviewing website content against guidelines, flagging potential problems, and helping visitors find answers grounded in the site’s own content. Proposed updates could be held as drafts for human review.

That’s a story a customer can follow.

Anyone responsible for a substantial website knows the challenge. Someone’s title changes, but their old title lives on across several pages. A policy gets updated, while related content quietly falls behind.

Multiply that by hundreds of pages and you have a maintenance problem that rarely makes it to the top of the priority list.

Showing how AI might help find and address those issues makes the value tangible. I’d still want to test it against a real client’s content, including the exceptions and inconsistencies that make websites interesting. But the demonstration gave me a reason to explore further.

Drupal Canvas needs to pass the everyday editor test

Drupal Canvas brings visual page building into the conversation, and that makes sense.

A well-configured Drupal website can already give editors a manageable experience. However, creating a new layout or moving beyond the available templates has often meant asking someone with more technical knowledge for help.

Canvas offers a more visual way to assemble pages. The keynote also highlighted multilingual improvements, including translation support within Canvas.

The opportunity is significant: give marketers more control over their work while developers establish the components and structure underneath it.

My next step would be a simple test. Put a marketer in front of Canvas, give them a realistic campaign brief, and see where they get stuck.

Can they build the page? Can they adjust it confidently? Do they understand what will happen when they publish?

A polished demonstration gets attention. Watching someone successfully complete an everyday task builds confidence.

A more familiar starting point for JavaScript developers

Our developer was particularly interested in the separation between the editing experience and component development.

Editors work within Drupal, while front-end developers can build Canvas code components using React and familiar JavaScript tooling. The demonstrated workflow includes a local component development environment, previews, and tools for pushing those components to Drupal.

For someone coming from a JavaScript background, that creates a more familiar starting point. It also potentially opens Drupal projects to a wider pool of front-end developers.

There’s a practical detail here, though: the local React component workflow still involves setting up and maintaining development tooling alongside Drupal. Making the editor’s experience simpler doesn’t eliminate the technical work underneath it.

That’s a distinction worth explaining to clients. An experienced team builds the foundation so the marketing team can work more independently.

Headless needs a plain-English explanation

Developing React components for Canvas and running a separate headless website are related possibilities, but they are different implementation choices.

With Canvas Headless, Drupal manages content while a separate application controls the visitor-facing website. The approach preserves visual editing and previews, with framework options including Next.js, Astro, and Nuxt.

The business benefit is easier to explain:

Your marketing team can manage content in Drupal while your development team uses the front-end technology that fits the project.

That flexibility can be valuable. It also introduces implementation and maintenance decisions, so we’d evaluate it against a client’s actual needs.

The phrase “headless architecture” probably won’t excite many marketing directors. Being able to modernize their website while keeping a content system that works just might.

AI could change how people interact with Drupal

Another observation from our developer was that AI’s appeal extends beyond writing copy. It could give people a simpler way to ask the website to do something.

Consider an administrator who wants to update a title or create an editor account with an established role. Being able to describe the task could reduce the need to navigate multiple screens.

That’s an appealing direction, provided the requested action is supported and the person has the appropriate authority.

The keynote demonstrated this principle with an AI assistant acting on an editor’s request while Drupal continued to enforce permissions and publishing rules. Dries also discussed work to make more module capabilities accessible to AI assistants and other tools.

The important qualification is that installing AI doesn’t automatically make every Drupal feature available through a prompt. Each action needs the appropriate integration and controls. Changing a form’s notification recipient, for example, would depend on tooling that can safely expose that specific capability.

This is where expectations matter. A compelling demonstration shows what’s possible. A project plan needs to establish what’s supported, what needs development, and what requires approval.

AI still needs to earn its place

Our developer explored the AI demo and liked what he saw, but he didn’t immediately identify a need to implement it. I appreciate that perspective.

New functionality should solve a recognizable problem.

Before introducing it into a client’s workflow, we’d want to know:

• How accurate are the suggested changes?
• What happens when AI misunderstands an instruction?
• How easily can someone review and undo mistakes?
• How much time does human review take?
• Do the savings justify the setup and ongoing costs?

Governance and accuracy are different things. A change can follow the correct approval process and still contain the wrong information.

The goal is a workflow that helps people finish good work faster, with enough visibility and control to trust the result.

Drupal’s next audience needs a different conversation

A developer conference is naturally going to discuss APIs, React, MCP, and architecture. Those details belong there.

But when the same capabilities are introduced to business owners and marketing teams, the conversation needs to start with their work.

Can we launch a campaign faster? Can we update content without opening another ticket? Can our team manage multiple languages more easily? Can we make changes confidently?

The new Drupal Advocacy Program creates an opportunity to tell those stories through demonstrations, customer examples, and educational content, especially for audiences outside the existing community.

I’d love to see more comparisons built around the same task in an older Drupal implementation and a modern one.

Build a landing page. Update a multilingual section. Find outdated content. Show what the developer handles, what the editor handles, and how long each step takes.

Keep the comparison fair. Explain what was configured beforehand. Let viewers see where someone still needs help.

Drupal Canvas and AI were the biggest takeaways for our developer, and I can see why. Both offer ways to make Drupal feel more accessible to people with different skill sets.

Now we need to make that progress obvious to the person responsible for the website on an ordinary Tuesday.

Show them how to get their work done. That’s how Drupal starts changing minds.

‍