In the DrupalCon Atlanta Driesnote and follow-up blog post, Dries laid out a bold vision:

Site Templates combine Drupal recipes, a theme, design elements, and default content to give users a fully functional website right from the start."

He also posed a big question to the community: Should we build a Marketplace for these templates—and if so, how?

In just the first couple weeks of conversation, hundreds of community members have weighed in across Slack, blog comments, and BoFs. From enthusiastic endorsements to thoughtful concerns, the input is rich, complex, and deeply-rooted in the spirit of Drupal.

This post captures what we’re hearing so far.

The Opportunity

Many in the community agree: the lack of easily accessible, visually appealing starting points is one of Drupal’s largest barriers to adoption. A Site Template Marketplace could:

• Lower the barrier to entry for site builders and small organizations
• Give developers a fast, “wow-worthy” way to spin up sites in hours, not weeks
• Highlight the full potential of Drupal CMS + Experience Builder
• Generate new opportunities for agencies, makers, and module maintainers
• Strengthen the Drupal Association’s sustainability with shared revenue

As one commenter put it:

Every sold theme means a new Drupal site, likely a happy user... and the community gets something back."

What Would Make the Marketplace Useful?

In our first weekly Slack Prompt (#1), we heard:

• Fast paths to beautiful results: Templates you can install, customize, and deploy in days—not weeks.
• Tiers of complexity: Lightweight starter kits, robust enterprise templates, and everything in between.
• Paths for free and commercial use: A mix of free, contributed templates and paid offerings with premium support or assets.
• Rewards for collaboration: Incentives that elevate templates built by multiple contributors or agencies working together.
• SaaS-style options: Templates bundled with hosting, updates, or paid support for non-technical audiences.

I wanna grab something from the marketplace, put it together in 2–3 days max, and blow people’s minds." —Community member

The Questions We're Hearing Most

Across Slack and the blog post, several themes of inquiry and caution have emerged:

1. Legal Clarity & Licensing

• What parts of a Site Template can be sold under Drupal’s GPL license?
• Will template buyers be able to redistribute what they purchase?
• Can we enable commercial distribution while staying true to open source values?

Dries has addressed this nuance, noting that:

Assets like images, fonts, and demo content are not code and are not derived from Drupal. These elements… can use other licenses, including commercial ones."

2. Quality, Curation, and Trust

• How might we prevent a flood of low-quality or AI-generated templates?
• What might the minimum standards be for a “Marketplace-worthy” template?
• Will there be community reviews, security checks, and update requirements?

Many worry about the “freemium wasteland” effect—where flashy templates lack depth, break easily, or are quickly abandoned.

3. Revenue, Incentives, and Equity

• How might we compensate module maintainers when their code is included in paid templates?
• Should the marketplace allow non-fiat options like contribution credits?
• How might we incentivize the initial wave of templates while avoiding a “race to the bottom” on pricing?

Seeing others earn money by building on that work without recognition can be disheartening... But when it happens on Drupal.org, we have an opportunity to do better." —Dries

4. Experience & Accessibility

• Templates must support non-technical users: installable from the CMS UI, not just Composer.
• The Marketplace should integrate with Project Browser and potentially with hosters.
• Examples, walkthroughs, and support channels are key for adoption.

5. Governance & Structure

• Where might the Marketplace live? Drupal.org? Drupal.com? A subdomain?
• What rules, vetting, and governance structures might protect quality and community trust?
• Should a rollout be phased—starting with free templates first?

Additional Ideas from the Community

• Use contribution credits or sweat equity as alternative currency
• Add a “Marketplace-ready” badge system for contributors
• Offer lead generation or support links for template maintainers
• Allow template variation/extension patterns for maintainability
• Define the relationship between templates, themes, and recipes
• Rethink terminology: “Site Templates” vs. “Experience Kits” or “Project Starters”

Drupal has always had functionality. What it’s lacked is themes—and that’s what makes users fall in love with a CMS."

What’s Next?

This is just the beginning. Over the next few months, the Marketplace Working Group will continue to:

• Collect input via weekly Slack prompts, community surveys, and live feedback sessions
• Map feedback to the F-V-U-D-E model (Feasibility, Viability, Usability, Desirability, Ethics)
• Explore different models for governance, monetization, and sustainability
• Share out summaries like this one every few weeks to keep the community involved

We’re on track to make a go/no-go decision in Q3 2025, and your participation is essential in shaping that outcome.

How Can You Get Involved?

There are many ways to plug in and volunteer—whether you have 5 minutes or a few hours a week:

• Share your thoughts - Reply to the weekly Slack prompts in #drupal-cms-marketplace
  1. What would make the Drupal Marketplace useful to you?
  2. What might prevent you from using or contributing to the Marketplace?

1. Take a survey - Survey #1: Shaping the Drupal Marketplace: Contributor Perspectives targeted at Agencies, Drupal Contributors and Drupal Certified Partners

• Join a real-time session - Help shape decisions in live 50-min community calls
• Become a volunteer - this work is open to all community members—no special technical background required. Many roles are great fits for folks who enjoy facilitation, organizing, writing, or user-centered thinking.
• Spread the word - Invite others to share feedback or join a session

Over the past few weeks, the Marketplace Working Group and volunteers have been busy laying the foundations for the months ahead. As a reminder, our goal is to determine whether a Drupal Site Template Marketplace can be designed in a way that is trusted, inclusive, sustainable, and viable—and to reach a go/no-go recommendation before DrupalCon Vienna.

From Idea to Critical Assumptions

Over the past few weeks, the Marketplace Working Group has been focused on a key early step: identifying the assumptions that must be true for a Drupal Site Template Marketplace to succeed.

Rather than moving directly into planning and building, we are working transparently with the community to surface and stress-test our most critical assumptions before making any final decisions.

In this update, we’ll share where we are now—and where we still need your help to validate what matters most.

Why Focus on Critical Assumptions?

The Marketplace is an exciting idea, but it brings with it real risks. Some assumptions, if wrong, could seriously harm Drupal’s ecosystem, community trust, or financial health. We’ve identified the early critical assumptions—those with:

• High impact if we’re wrong, and
• High uncertainty based on what we know today.

Rather than ignoring or minimizing these risks, we are bringing them forward, openly and early, so the community can engage with them directly.

Critical Assumptions Emerging So Far

From the emerging community feedback (Survey #1: Shaping the Drupal Marketplace: Contributor Perspectives, slack prompts, and deep discussion in this thread), several high-risk assumptions have emerged:

1. There will be enough demand for site templates to sustain a marketplace.

If we build it, will they come? And will they pay?”
Without real demand, the Marketplace won’t achieve its goals—and may strain community resources without impact.

How we’ll validate: Ongoing surveys to Drupal users and agencies; testing via Drupal CMS starter templates; scenario-based surveys during Real-Time Collaboration (RTC) sessions.

2. High-quality templates will be created and maintained.

We need to avoid a freemium wasteland of abandoned templates.”
Success depends on attracting contributors with design and UX skills—and ensuring long-term maintenance.

How we’ll validate: Contributor surveys about incentives, motivations, and barriers; prototype pilot tests; deeper exploration in RTC sessions.

3. The operational complexity of running a marketplace is manageable.

The DA can’t afford to build and maintain a marketplace that requires millions to operate."
The Marketplace must be financially and operationally sustainable from day one.

How we’ll validate: Modeling operational costs; evaluating automation options; benchmarking against other marketplaces.

4. A commercial element can be introduced without undermining open source values.

Commercialization must not erode what makes Drupal different.”
If done poorly, a commercial marketplace could fragment the ecosystem, damage trust, and alienate contributors.

How we’ll validate: Community consultation on licensing models; exploring models for attribution, revenue sharing, and code stewardship.

5. Governance structures can maintain trust and quality at scale.

If trust fails, the marketplace fails.”
The Marketplace must earn and maintain user and contributor trust through clear standards, quality controls, and transparent processes.

How we’ll validate: Testing community expectations through surveys; prototyping governance models; pilot feedback loops.

Important Tensions Emerging

Through open discussion, several important tensions have also surfaced:

• Open Source vs. Monetization:
  Balancing the spirit of FOSS with the need for financial sustainability.
• Support Expectations:
  Clarifying who provides support for templates—and setting fair boundaries.
• Future Risks:
  Avoiding the slippery slope toward undermining Drupal collaborative ecosystem model or a poor signal-to-noise ratio from low quality or unsupported templates.

We recognize that these are not easily solved with a single conversation. They will require ongoing community engagement, transparency, and iteration.

Where We Are Now

Here’s what’s been accomplished so far:

• Roadmap finalized for how we'll reach a go/no-go decision.
• Volunteer team onboarded, and we're beginning weekly coordination around community engagement.
• Community framing completed, based on early signals from surveys, Slack prompts, and discussions.
• Critical assumptions identified through our Week 2 Assumption Slam.

What’s Next

Over the coming weeks, we’re moving systematically through key questions:

• Contribution Value: What would make it worthwhile for someone to contribute a template?
• Governance & Trust: What signals would make users feel confident using a marketplace template?
• Ecosystem Fit: How can the marketplace align with, not compete against, existing agency and contributor models?
• Contributor Experience: What support is needed to help contributors succeed?

Each week, we’ll continue to validate assumptions, evolve our thinking, and ensure that what we’re building—if we build it—is something the community truly wants and can stand behind.

Thank you to everyone who has already shared feedback, challenged assumptions, and raised important questions. Your voices are helping shape this work.

Stay tuned—and stay involved.

How You Can Get Involved

1. Respond to weekly Slack prompts.
   This week: What would make it worthwhile for you to contribute a template?
2. Join our upcoming Real-Time Collaboration (RTC) session
   First session: 1 May 2025 at 15:30  UTC about Co-creating Value and Incentives
3. Share your perspective on the surveys when they open.
   How could a Drupal Site Template Marketplace Help You? for Agencies and potential End Users of templates.
4. Bring forward your own assumptions and risks we may have missed.

Interested in learning how to build, implement and analyse a Content Security Policy? Michael shares some critical insights and lessons learned from a large government website built on Drupal.

In the presentation, “Hashes and Nonces and Violations, Oh My! Everything you need to know about Content Security Policy (CSP)”, you’ll discover that while enhancing web security on an existing site can be challenging, enabling it as early and strictly as possible eases those challenges.

Michael begins with the essentials for getting started, then moves into the more complex directives that you’ll need to know. And while a hard-coded policy isn’t dynamic enough for Drupal’s needs, particularly with Google Tag Manager—don’t panic! Michael will also present some strategies that can alleviate that.

By the end of the video, you’ll understand how to start building your policy, as well as the tools needed to analyse its effectiveness before deployment to production.

Watch the video

With Experience Builder in development and set to change how editors work in Drupal, Lee provides an overview of this ambitious initiative.

“I believe we're on the cusp of Drupal's Inverse Mullet* phase

 

*Inverse mullet - business out back, party up top”

In this video, Lee explains that Drupal 8+ is now a decade old, with a rock-solid backend and plenty of decoupled experience to draw on for building editing experiences. This allows us to enter a new period of front end innovation.

The presentation goes on to fully explore the Experience Builder goals and discuss how the work is going, as well as explaining the technology and ways to get involved.

Links:

• Drupal Starshot Initiative - Experience Builder

• Experience Builder project

Watch the video

Maestro and ECA Integration

When Maestro first hit the Drupal scene, it was 2011, Drupal 7 was the main release and the Rules module was the primary mechanism you'd use to react to events happening in your Drupal system. Maestro integrated easily with Rules to allow site builders to fire off Maestro workflows when events happened in Drupal.  Fast forward to 2025, and the ECA module is rapidly gaining traction.  Just like with Rules, Maestro can integrate with ECA.

Today we are talking about The Contact Form Initiative, What it is, and how it helped Drupal with guest J. Hogue. We’ll also cover Local Tasks More as our module of the week.

For show notes visit: https://www.talkingDrupal.com/499

• What is the Contact Form initiative
• What makes up the contact form recipe
• Why did you want to run this initiative
• What are the responsibilities of an initiative lead
• Were there any unexpected speed bumps
• Who was involved
• As a non-backend developer, any hesitation to lead this effort
• What was onboarding like
• What was the timeline
• Any tips for others thinking of leading an initiative

J. Hogue - oomphinc.com artinruins

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Kathy Beck - kbeck303

Jacob Rockowitz - jrockowitz.com jrockowitz

• Brief description:
  • Nodes can have too many local tasks. Only the first few, like View, Edit, Layout, Revisions, and Translate, are used daily. Would you like to hide or reorder less commonly used local tasks, which include Usage, Clone, Devel, and Convert. There is a module for that
• Local Tasks More (local_tasks_more)
• Brief history
  • How old: created on November 6th, 2024
  • Versions available: 1.0.0-beta2 r
• Maintainership
  • Actively maintained
  • No security coverage
  • Has test coverage
  • Does not require much documentation
  • No issues
• Usage stats:
  • 22 sites
• Maintainer(s):
  • jrockowitz (me)
  • Module features and usage
  • Enter the base routes that support the show more/less task link and alterations.
  • Enter the local task id and the altered title and weight. Set the local tasks to FALSE to remove it.
  • Enter the number of links to trigger show more/less tasks link/icon from primary and secondary tasks (aka tabs).

If you’ve been keeping an eye on Drupal community updates, you’ve probably seen the IXP Fellowship making some waves — and for good reason. It's the kind of program that feels long overdue: giving new Drupal developers, the ones who know their way around but haven't had their first real break yet, a way into the industry. Michael Anello, in his blog post, highlighted how the IXP is about recognising that real-world experience needs a starting point — and it’s refreshing to see that truth backed by genuine incentives. With early adopters like Seed EM and Digital Polygon already on board, the IXP Fellowship isn’t just an idea anymore; it’s producing real graduates and real results.

The real story here isn’t just that there’s a new pipeline — it’s that the Drupal community is finally getting serious about building for the future. On LinkedIn, Carlos Ospina praised the program's impact on both developers and companies, noting its potential to reshape the way new talent enters the field. Too often, companies talk about wanting fresh talent without providing meaningful opportunities to beginners. IXP changes that put mentorship at the centre and reward companies for stepping up. In his blog, 'A Drupal Couple,' he emphasised the value of bringing in new faces who now have a clear way to gain professional experience without hitting the usual barriers. That's not just good news for the Fellows; it's a necessary move for Drupal’s long-term growth.

If the community embraces this the way it should, the IXP Fellowship could quietly shift how Drupal brings in and develops new talent. It's not about overnight transformation; it’s about making sure newcomers aren’t left out simply because they’re new. Giving people a real start, with mentorship built in from the beginning, could mean stronger teams and a more sustainable community over time. It’s a small step that, if done right, could make a real difference where it matters.

Now, let's dive into the most important stories from last week.

DISCOVER DRUPAL

• Drupal in Government: Top Indian States That Run Official Websites on Drupal
• IXP Fellowship Graduates from Initiative to Functional Drupal Program
• Metadrop Releases Updated Entity Mesh Module for Drupal Content Visualization

DRUPAL COMMUNITY 

• Blocked from Contributing, Helped by a Veteran: How a Small Drupal Module Exposed a Bigger Problem
• Executive Voices Wanted: Take the Drupal Executives Network Community Survey

EVENTS

• Inside Edmonton’s Drupal Meetup Revival: Organizers Share Goals, Challenges, and What’s Next
• DrupalCamp Burkina Faso 2025: Igniting Africa’s Digital Future Through Community and Code
• International Splash Awards 2025 Now Accepting Submissions Ahead of DrupalCon Vienna
• Become a Volunteer at DrupalCon Nara 2025
• Drupal Open University Initiative Expands with "Drupal in a Day" Workshop at Drupaljam 2025
• April 2025 Drupal for Nonprofits Chat Open to All Users and Developers
• DrupalCon Vienna 2025 Seeks Proposals for Community & Health Track
• Drupal Café Lutsk #27 Held in Person and Online with Technical and Community Sessions
• Drupal Mascots Get AI-Generated Starter Packs Ahead of DrupalCon Vienna 2025

ORGANISATION NEWS

• Inside Releem: How AI Is Reshaping MySQL Performance—Insights from Roman Agabekov
• Teun Van Veggel Announces New Mapsemble Module for Drupal

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now.

To get timely updates, follow us on LinkedIn, Twitter and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you, 
Sincerely 
Kazima Abbas 
Sub-editor, The DropTimes.

Last week I attended the Drupal Dev Days in Leuven and many of the sessions and also conversations in the hallway and the contribution room were about Drupal CMS and AI.

The foundational engine behind Drupal CMS is the recipe system, which allows a bunch of configuration changes to be bundled and applied to your site. This is really cool, but it may do things you are not completely aware of. Unfortunately there is no way to “undo” a recipe. The same problem occurs if one is letting AI change configuration.

DDEV snapshots and git commits

The proper solution of course is to export the configuration and version it in git before starting to play with recipes, as well as periodically in between applying recipes to have more save points to go back to. Since recipes can also add default content and some configuration can not be deleted when there is content for it, it means that sometimes a previous git checkout of the configuration can not be imported. Therefore, the best solution is to create database backups and roll them back when needed. DDEV makes this very easy to do, and so that would be the first recommendation to address the problem and it will always work.

However, the ddev snapshots do not really give one a lot of information of what changed. The configuration in git is a lot better, but it requires an extra manual step to create the export and commit it to git. That may not be instinctive to most drupal users, especially not the target audience of Drupal CMS.

What if Drupal could help us with that?

It turns out that Drupal core introduced the concept of configuration checkpoints when recipes were added. The idea is that before a recipe is applied a checkpoint is set, then when the recipe application fails the configuration is rolled back to the checkpoint.

There is an issue for adding a command to revert to checkpoints but no work has even started.

I had the idea already at Drupalcon Barcelona 2024, but after discussions in Leuven I decided to implement a UI for the configuration checkpoints.

How does Config Checkpoint UI work?

So far the first version is very simple: It exposed some of the basic API to the UI. One can create new checkpoints, delete checkpoints and revert the site configuration to an older checkpoint. The reverting is done essentially the same way as the core command does: importing from the checkpoint storage. This is very similar to what Config Split does and the reason for which I thought it was a good idea to try.

Future and Limitations

There are a few bugs in other projects to watch out for: Project browser does not set a checkpoint, and core has a bug when deleting checkpoints. Of course there may be lots of bugs in the new module itself. In particular one of the things I have ran into is that the uninstall validation is a bit broken, so some of the recipes can not be rolled back when they add fields that depend on a module added at the same time. I will have to check where exactly this bug is hiding. More advanced things could also be explored, for example merging checkpoints or deleting checkpoints without deleting everything that came before.