Over the last few weeks, the Marketplace Initiative has been mapping assumptions, surfacing motivations, and exploring real-world expectations for a Drupal Site Template Marketplace. The initial rounds of feedback were designed to surface motivations, beliefs, unknowns, and frame what success might mean. That work has helped ground the initiative in shared purpose and direction.

Now we’re starting the work of transforming those broad ambitions into working models of value, governance, trust, and experience. We're beginning to sketch what the Marketplace does, how it creates and protects value, and what contributors and users can expect from it.

Why a Drupal Site Template Marketplace?

Across survey feedback, community prompts, and RTC themes, several consistent value propositions have emerged — answering the question: Why build a Drupal site template Marketplace?

For Contributors

A trusted, visible channel to distribute, monetize, and showcase high-quality site templates that reflect your expertise — and generate leads, recognition, and revenue.

For Agencies & DCPs

An ecosystem catalyst that drives qualified leads, lowers implementation costs, and helps you deliver faster, better Drupal experiences to more clients.

For End Users (Builders, Subject Matter Experts, Evaluators)

A library of trustworthy, ready-to-launch Drupal sites — professionally built, continuously vetted, and provided by the Drupal community.

For the Drupal Project & Drupal Association

A sustainable marketplace that strengthens the ecosystem, generates new revenue, and reflects the values of open source through governance, quality, and inclusion.

What Makes Contribution Worthwhile?

In Slack, surveys and our real-time collaboration session we asked contributors directly: “What would make it worthwhile for you to contribute a template?” Key themes emerged from the discussion:

• Compensation matters. Contributors suggested price points between $300–$1,000 per site template, depending on complexity. Some see templates as a viable business; others view them as strategic loss leaders.
• Lead generation is an incentive. Access to user contact info or opportunities to offer services was cited as a powerful motivator—even more than direct revenue in some cases.
• Recognition and visibility also surfaced as important non-financial incentives, especially for those aiming to grow brand or project awareness.
• Licensing clarity and IP protection remain concerns—contributors want guardrails to discourage cloning and unauthorized redistribution.
• Marketplace features—such as demo previews, rich media listings, and clear tech specs—can enhance both contributor experience and buyer confidence.

We also heard loud and clear what gets in the way of contribution:

• High (Uncompensated) Support Expectations: Ongoing maintenance, support, and clarity of lifecycle.
• Lack of Clarity: Around what qualifies, what gets featured, and how disputes are handled.
• Governance Gaps: Without rules, the risk is chaos — too many low-quality or misaligned submissions.
• Misaligned Incentives: Contributors worry about monetization models that exclude or exploit.

What’s Coming Next

Here’s what we’ll be working on over the coming weeks:

• Governance Sketching: From submission flow to trust signals and appeals.
• Contributor Workflow Design: What the path from idea → listing → maintenance actually looks like.
• Quality & Review Criteria: What “good” looks like across code, content, accessibility, and UX.
• Revenue & Recognition Models: How value is created, shared, and sustained.

How You Can Contribute Now

We’re still in active input-gathering mode, and your voice matters.

• Survey #2 is still open – If you haven’t yet shared how a Drupal CMS Marketplace might help you or your business, take it now.
• Survey #3 just launched – This one explores expectations around fairness, openness, and revenue models. Take the survey here.
• Join the weekly Slack prompt in #drupal-cms-marketplace
  Up this week: What would make you trust a site template listing?
• Participate in our Drupal Certified Partner and Agency Ecosystem Roundtable 15 May 2025 UTC 15:30. Register here.

Join us for an extraordinary celebration of Talking Drupal's 500th episode! In this milestone episode, we dive into a treasure trove of memories, insights, and updates from an array of special guests. From innovative Drupal contributions to the future of open-source technology, this episode is packed with valuable discussions. Don't miss appearances from notable guests like Dries Buytaert, Tim Doyle, Tim Lehnen, Mike Anello, and many more. Celebrate with us as we look forward to 500 more episodes!

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

Guests include, in order of appearance:

• Jason Pamental
• Dries Buytaert
• Tim Doyle
• Tim Lehnen
• Carlos Ospina
• Mayela Jackson
• Mike Anello
• Jonus Cuyvers
• Jacob Rockowitz
• Antonio Estevez
• Norah Medlin
• Kevin Quillen
• Chris Wells
• Steven Jones
• Jürgen Haas
• Thomas Scola
• Chad Hester
• Matt Glaman
• James Abrahams
• Avi Schwab
• Josh Mitchell
• James Shield

Road to deprecating .module files

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Martin Anderson-Clutz - mandclu.com mandclu Stephen Cross - stephencross

Dear Readers,

The 2025 State of Open Source Report has dropped, and it’s raising eyebrows. Open Source adoption keeps climbing, with 96% of organizations either holding steady or increasing their usage. But behind that impressive number is a more complicated story. Many teams are pushing ahead without the skills or strategy to manage what they’ve adopted. The tools are powerful. The human side, including staffing, governance, and lifecycle planning, is struggling to keep pace.

Drupal users will recognize the tension. As one of the most mature and widely deployed open-source platforms, Drupal has long been part of the enterprise tech stack. But even here, the report's themes hit home. The risk of running outdated modules, the effort needed to stay current with security updates, and the rising demand for cloud-native workflows are all very real. It's not just about building with Open Source anymore. It's about managing it with clarity and consistency.

The key takeaway? Adoption alone isn’t success. Whether you're using Drupal, containerized services, or open-source data platforms, the same pressures apply. Unsupported code, compliance gaps, and missing talent can quietly undermine progress. The report is worth your time if you care about using Open Source in a sustainable, responsible way. Read the full 2025 report to get a grounded look at where the ecosystem stands and what needs attention next.
 

DISCOVER DRUPAL

• Drupal Site Template Marketplace Under Review as Working Group Tests Key Assumptions
• Chris McGrath Rebuilds Drupal-Based ATS/CRM with React and AI Tools
• Jürgen Haas Sparks Community Discussion on the Future of Drupal Marketplace
• 2025 State of Open Source Report Shows Surge in Adoption, Ongoing Security Concerns

LISTICLE

• Drupal in Government: Top Indian States That Run Official Websites on Drupal

EVENT

• DrupalCamp Ouagadougou 2025 Builds Momentum for Drupal Community in West Africa
• Behind the Scenes of DrupalCamp Ottawa 2025: How This Free Event Came Together
• DrupalCamp Spain 2025 Offers Free Tickets for Students in Web Development
• JetBrains to Host Free Virtual Event Celebrating 30 Years of PHP
• Drupal Events This Week: Meetups, Camps, and Community Sessions (May 5–11, 2025)

ORGANISATION NEWS

• What Happens When a Podcast Outlives a Decade? Talking Drupal Knows
• Annertech Advances LocalGov Drupal with New Features, Governance, and Media Improvements
• YMCA Website Services Distribution Upgrades to Later Versions of Drupal and PHP
   

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 
Alka Elizabeth 
Sub-editor, The DropTimes.

Open source projects thrive because of the people and institutions that nurture it behind the scenes empowering innovation, collaboration, and digital freedom. One impactful institution is the Oregon State University Open Source Lab (OSL). The Drupal community owes much of our success and growth to Open Source Lab when they supported the project in 2005 by hosting our servers.

Today, OSL needs our support.

About Open Source Lab

The Oregon State University Open Source Lab is a nonprofit organization with a powerful legacy in the open source ecosystem. For years, it has provided secure, reliable hosting services to some of the most widely used and mission-critical open source projects like Apache, CentOS, Debian, Django, Docker, Eclipse, Mozilla Firefox, GNOME, Go, KDE, Node.JS, OpenBSD, OpenSSL, postgreSQL, Rust, sqlite, The Tor Project, Yum, and yes, Drupal.

Open Source Lab helped shape Drupal’s journey

In 2005, when a surge of interest melted down the shared server that was being used by Dries to host Drupal.org, Sun Microsystems donated a server but there was nowhere to host it. Open Source Lab stepped forward providing managed data center services, offering not only hosting but also long-term support through its student mentorship model. This commitment shaped the careers of many open source leaders, including former Drupal Association Infrastructure Manager Rudy Grigar and current Infrastructure Manager and Tag1 CTO Narayan Newton, both Open Source Lab alums. 

While the Drupal Association has now moved to a hybrid cloud architecture, we still operate some critical infrastructure at the Open Source Lab, including pre-production environments, mail transport, and legacy systems that are still mid-migration, and will be repurposed for things like our testing infrastructure. It is our hope for Drupal to continue to be present at the Open Source Lab for years to come.

A Critical Moment for Open Source Lab

In recent years, the Open Source Lab has faced a steady decline in corporate donations, leading to an operational deficit. Today the Open Source Lab is under threat, placing Open Source Lab’s future in jeopardy.

Unless they secure $250,000 dollars in commitments by 14 May 2025 they will have to close their doors.

If Open Source Lab shuts down, we lose a backbone of the open source world and a value-driven infrastructure provider. It would ripple across dozens of projects and thousands of contributors, setting back years of progress and community building.

Together, we can keep Open Source Lab alive

This is an opportunity for all of us to come together to support an unsung pillar of open source.

Here’s how you can help:

• Your donations are vital to keep this precious resource for the public good open. Consider making a donation to support Open Source Lab’s future. Donate today.

• If you are able to make a major gift, you can also reach out to: donations@osuosl.org 

• Help raise awareness by sharing this post within your network and with anyone you think could help support Open Source Lab.

The Open Source Lab has played an important role in supporting the open source community, now it’s our turn to give back. By contributing today, you’re helping secure the future of open source innovation and sustaining essential digital infrastructure. It's time to come together to ensure the Open Source Lab’s legacy continues to thrive.

DDEV has really changed the game for developers by making it easier to set up local development environments in no time! When you team it up with the amazing automation features of Selenium, you get a powerful duo for doing thorough functional tests. In this article, your favorite Drupal development team looks at how this combination can boost your development efficiency and enhance the quality of your projects.

With all the advancements in CSS over the past few years, it's surprising to discover a technique that's been available all along. If you're well-versed in CSS, you might already know this little nugget: selector > * + * {...}. Let's dive into it.

Lobotomized Owls 🦉 🦉

The Lobotomized Owl (* + *), or Owl selector, is one of my favorite techniques for managing document flow and achieving consistent spacing in a highly manageable way. While the Owl selector can be used for various style settings, my preferred use is to add spacing between sibling elements.

How does the Owl selector work?

The Owl selector targets elements that are preceded by an immediate sibling. This means that if you apply the Owl selector to a group of HTML elements, the styles will apply to all elements except the first one, as the first one doesn't have a preceding sibling. We'll see some examples shortly.

The Lobotomized Owl isn't a new CSS concept; it's been around since the beginning of CSS and was first discussed back in 2014 when A List Apart wrote about it. Read that article for a more in-depth description of the Owl selector.

Understanding the Owl selector

Concept

The Owl selector allows you to manage the document flow by using the next sibling combinator (+), along with the universal selector (*).

Example

Consider the following HTML:

Scoping the Owl selector

Using the Owl selector in its original form (* + *), could result in unexpected updates due to its broad scope. Narrowing the scope is prefered.

Chaining the Owl selector with .parent >:

Nesting it within .parent along with other rules that may exist:

By narrow the scope as shown above, and using the child selector (>), a 2rem top margin is added to "direct" children of .parent, but only if they have a preceding sibling.

Visual example

A more visual representation of what the CSS is doing can be seen here:

FIG 1: Each white box represents a div while the purple boxes represent top margin.

Instead of writing styles, we’ve created a style axiom: an overarching principle for the layout of content flow. - Heydon Pickering.

Traditional approach for handling margin

In the past I would do something like this to handle margin on a group of elements.

That's not terribly bad, but the problem with this approach is that it increases the specificity of the rule, which could complicate overrides.

Before :not was a thing, I would also do something like this (please forgive me):

There's nothing wrong with this example except that it's more code and you're overriding rules. Ultimately, it works, so don't feel too bad if you've done this. Just don't do it again 😉. Instead, do this:

A more complex example

The examples above are pretty simple, but in many cases, our HTML may not be as clean or uniform as the examples we've seen. Here's a more realistic example where our markup is a combination of different HTML tags.

The HTML above is actually the code used on each of the blog posts on this site. Let's break it down in an illustration form for a better visual representation.

FIG 2. Illustration of the markup structure of a Blog post.

From the code and FIG 2 above, we notice the following:

1. The <article> tag is the top parent element with four direct child elements (Tag, Header, Share, and Article content).
2. The <header> tag is also a parent element itself with three direct child elements (Title, Subtitle, and Date).
3. There is a mix of HTML tags.

Let's start with the <article> parent selector:

The result of this CSS rule is a 2rem top margin on direct sibling children of the .blog-post selector, except the first/top one. I have highlighted in purple how this looks in FIG 3. below:

FIG 3. The purple boxes represent the space added by the CSS above.

Now let's apply the same treatment to the <header>:

To make it easier to diferentiate, this time I highlighted the margin in direct sibling children of the <header> tag, in blue. See FIG 4. below:

FIG 4. The blue boxes represent the space added by the CSS above.

With very little CSS code we have been able to achieve consistent spacing in direct sibling children of the <article> as well as nested ones inside the <header>. In the spirit of staying DRY, we could even combine both rules to reduce code repitition.

What if the HTML structure changes?

It's not uncommon for the HTML of a document to change. Some of my blog posts, for example, have subtitle text while others don't. The beauty of the Owl selector is that it doesn't depend on specific HTML tags or structure in your document. If new sibling elements are added or some are removed, the spacing previously defined with the Owl selector will continue to work as intended without breaking the document flow.

What about Gap?

Oh yes, enough about Owls 🦉, Gap is a beautiful thing and can even be used similarly to the Owl selector for adding space in between sibling child elements.

Pros of gap

• The CSS block above will behave exactly as the Owl technique, as in it will only add space between sibling child elements.
• Another advantage of using Gap for spacing, is that when it comes to responsive design, the gap rules you apply to elements for mobile, will remain in place as you transition to tablet or desktop. No need to change the gap settings if the direction of your layout has changed. See FIG 5. below.
• Gap is great for menu lists where you may want to add spacing in between each menu item except the ones at the end.

FIG 5. Visual of Gap on column and row mode.

Cons of gap

If you opt to use Gap for spacing, this means you either need to use display: flex or display: grid on the parent element. This is not a bad thing if you are already using flex or grid on that parent element, but if your only reason for using gap is for spacing purposes, then I would recommend using the Owl technique instead as it requires not additional properties on your parent selector.

In closing

I don't think there has ever been a more exciting time to work with CSS than now. The capabilities of CSS and browser support have never been better. Sometimes however, using some of the most basic techniques can make a great impact in our projects.

If you found this post useful, stay tuned for more like it.

Resources

• What is the 'Owl selector' (* + *)? — Brand new video
• My favourite 3 lines of CSS
• The Stack
• Axiomatic CSS and Lobotomized Owls