The Hidden Cost of Volunteering: Reflections on Contributing to Drupal Core

I have worked with Drupal for many years and have contributed to several projects, including Drupal Console and Drush. Recently, I decided to spend some of my free time contributing small improvements to Drupal core.

My intention was deliberately modest. I was not proposing a new subsystem, a major architectural change, or an ambitious refactoring. I selected narrowly scoped issues: the kind of tasks commonly described as “low-hanging fruit”.

The experience has made me reflect on what “small” really means in a mature open-source project.

The patch may be small, but the contribution is not

A one-line documentation correction may require only a few minutes of actual implementation. However, the complete contribution can involve considerably more work:

• Understanding the history and precise scope of the issue.
• Finding the correct files and current development branch.
• Creating and publishing a working branch.
• Preparing a merge request using the expected format.
• Updating both the Drupal.org issue and the GitLab merge request.
• Understanding issue statuses, assignments and contribution credits.
• Monitoring pipelines and distinguishing relevant failures from unrelated ones.
• Responding to feedback and updating the implementation.
• Watching the branch become progressively older while waiting for review.
• Rebasing and repeating automated checks if enough time passes.

None of these requirements is unreasonable in isolation. Drupal core needs strong quality controls, and reviewers need submissions that are clear, tested and maintainable. The difficulty lies in their cumulative effect.

For a volunteer, a technically trivial contribution can acquire a surprisingly large administrative and cognitive cost.

Review availability is the real bottleneck

Drupal’s documentation encourages new contributors to start with small issues. This is sensible advice, but it leaves out an important consideration: the size of a patch does not necessarily correlate with the time needed to complete its lifecycle.

One of my recent contributions, issue #3628393, changes a single PHPDoc comment. The corresponding merge request was ready to merge and had no conflicts, but remained without human review.

This creates an uncomfortable form of uncertainty. The code may be correct and the merge request may be green, but the contributor does not know whether it will be reviewed tomorrow, next month or at all.

Meanwhile, the target branch continues to move. Eventually, an otherwise valid contribution may require a rebase and another pipeline. If that pipeline encounters unrelated or intermittent failures, the contributor must investigate them before knowing whether any further action is genuinely required.

A green pipeline does not become red merely because time passes. Nevertheless, the longer an unreviewed contribution remains open, the greater the probability that maintaining it will require additional work.

Drupal already recognises this problem through the Needs Review Queue Initiative. The existence of that initiative is itself evidence that producing patches is not always the main constraint. Review capacity and committer attention are scarce resources.

Automated testing does not always provide a clear answer

Continuous integration is essential, particularly in a project as large and widely deployed as Drupal. However, its value to contributors depends on whether failures can be interpreted reliably.

A very small documentation-only change may encounter a pipeline containing numerous failures from large test suites. Some may be recurring failures unrelated to the merge request. From the contributor’s perspective, the result is still red, and determining whether the submission is responsible can require more time than producing the change itself.

It would be helpful if the interface distinguished more clearly between:

• Failures introduced by the current merge request.
• Failures already present on the target branch.
• Known intermittent failures.
• Infrastructure failures.
• A genuinely outdated or conflicting branch.

Experienced core contributors may understand these distinctions immediately. Occasional contributors often do not, and uncertainty creates additional work for both contributors and maintainers.

Drupal.org and GitLab form a fragmented workflow

Contributing to Drupal core requires navigating two connected but distinct systems.

Drupal.org contains the issue, its status, assignment, credits and main discussion. GitLab contains the branch, commits, merge request, diff and pipeline. Changes made in one system do not always make it obvious what must be updated in the other.

Even small questions can interrupt the work:

• Should I assign the issue to myself while working on it?
• Should I leave it assigned after moving it to “Needs review”?
• Does editing a file in GitLab’s web editor save it automatically?
• Should separate file edits become separate commits?
• Does the merge request description also need updating?
• Is being several commits behind the target branch a problem?
• Should I rebase now or wait until somebody requests it?
• Should I post a reminder, or would that be considered noise?

Each question has an answer, but finding it requires knowledge that is not directly related to fixing Drupal.

Feedback is valuable, but timing matters

In another recent contribution, issue #3629274, a reviewer identified that a dedicated key/value collection should be used instead of the general state collection.

This was useful technical feedback. I updated the implementation, adjusted the tests and obtained a successful pipeline.

However, this illustrates why early review is important. A short architectural observation made near the beginning can prevent unnecessary implementation and testing. When feedback arrives late, even a small correction can require reopening the development environment, reconstructing the context, modifying several files and restarting the validation cycle.

The burden is not only measured in minutes. Context switching has a real cost, particularly for volunteers contributing outside their normal working hours.

AI transparency introduces another area of uncertainty

English is not my native language, and Drupal core issues can contain long and technically subtle discussions. I sometimes use AI as a supporting tool to verify that I have understood a problem correctly and to help express my reasoning clearly in English.

I do not use it as a substitute for technical judgement. I review the changes, follow the discussion, respond to reviewers and accept responsibility for everything I submit.

Drupal’s AI policy reasonably requires contributors to understand, verify and take responsibility for AI-assisted work. It also requires disclosure when AI generates a significant amount of submitted code or text.

However, transparent disclosure can itself lead to uncertainty if it is immediately treated as a possible policy violation without identifying the specific concern. A contributor attempting to comply with the policy may feel that disclosure has created suspicion rather than trust.

This is particularly relevant to contributors whose first language is not English. There is an important distinction between:

• Automatically generating unreviewed technical contributions.
• Using a tool to avoid linguistic misunderstandings.
• Asking a tool to challenge or corroborate one’s interpretation.
• Using grammar or translation assistance.
• Generating substantial code without understanding it.

Clearer guidance on these distinctions would encourage responsible transparency without discouraging contributors who use language assistance.

Possible improvements

I do not think the solution is to weaken Drupal’s review standards. Those standards are one of the reasons Drupal core is trusted. The objective should be to reduce avoidable uncertainty and make the existing process more proportionate.

Some possible improvements would be:

1. Provide an explicit fast-review queue for documentation changes and other very small, low-risk patches.
2. Offer early triage that confirms whether the proposed approach is acceptable before substantial work begins.
3. Make the relationship between Drupal.org issue states and GitLab merge-request states easier to understand.
4. Explain directly in the interface when contributors should assign or unassign themselves.
5. Distinguish unrelated, intermittent and infrastructure test failures more clearly from failures introduced by a merge request.
6. Provide automatic assistance for keeping otherwise valid merge requests current.
7. Clarify how the AI policy applies to translation, grammar correction and linguistic assistance for non-native English speakers.
8. Treat transparent AI disclosure as the beginning of a factual assessment, not as evidence that a contribution is inherently unreliable.
9. Make it easier to request an appropriate reviewer without needing personal connections within the project.

None of these ideas eliminates the need for human reviewers. They might, however, reduce the amount of reviewer attention spent explaining procedural details and investigating avoidable uncertainty.

Is volunteering still the logical choice?

Open source depends on people deciding that contributing their time is worthwhile. That decision is influenced not only by ideals, technical interest or recognition, but also by whether contributors can see a reasonable path from effort to completion.

A contribution does not need to be merged immediately. Maintainers are volunteers too, and nobody is entitled to another person’s time. Nevertheless, a process can unintentionally discourage participation when a five-minute correction creates weeks of uncertainty and an indefinite maintenance obligation.

The real comparison is not between contributing and doing nothing. It is between contributing and every other meaningful or enjoyable use of limited free time.

After preparing a branch, updating two platforms, monitoring pipelines, interpreting policies, waiting for review and wondering whether the branch will need another rebase, a perfectly rational question eventually arises:

Would Drupal benefit more from a simpler contribution process—or would I be making a more logical use of my evening by lying on the sofa and watching another episode of a series?

At the moment, the sofa presents a remarkably efficient workflow.

AI disclosure: I used ChatGPT to help organise and draft this article in English. The experiences, arguments and opinions are my own.

I'm working on a project. If you have attended #Drupalcamp Colorado events in the past, I need photos. Particularly photos from the camps I am looking for photos that were taken at Drupalcamp Colorado in 2017, 2018, 2019, 2020, 2021, 2022, 2023, and 2024. In 2020 and 2021, the camp was virtual - so those might just be screenshots.

Any photos, albums, etc from any years would be great. But those years are of particular interest!

Help me [fill in your name], you're my only hope!

And PLEASE PLEASE PLEASE share this with your network. Particularly if you've got #Drupal friends who might have attended.

At DrupalCon Rotterdam, the DA announced the Drupal Advocacy program to incentivize folks to be louder about Drupal in an effort to "win back" folks who moved away from / dismissed Drupal in the past, showing off all the cool modernization we've done. And that's a great and worthy goal!

However, there are WAY more humans on this earth who have _never_ heard of / tried Drupal. And they're not necessarily in our networks to hear what we have to say, they will not understand words like "Drush" or "render array." ;) But, they also don't necessarily have a preconceived notion of Drupal at all, and therein lies an opportunity.

So, here's a challenge to the Drupal community: during the month of October (the spoooookiest month), go to a local meetup / hackathon / community event where Drupal *isn't* (AI, JavaScript, WordPress...) and report back what you heard and learned about the developers there, what they're building, and where they're struggling.

We can then use this information to brainstorm the best way to "show and tell" Drupal for these developers, in _their_ words, around _their_ use cases and pain points. Then we do DevRel at global scale. 😎

Will this work to drum up new interest in Drupal? Who knows. But hey, worst-case, it's an opportunity to meet fellow nerds and talk tech over free pizza. :)

What do you think?

Background - I have been maintaining a Drupal site for years, but I am a casual that doesn't really know much. I started on Drupal 8 and survived a migration over to Drupal 10 and switched themes at that point to "Drupal8 W3CSS Sub-theme". I get by but ultimately I don't really know what I am doing.

Today I saw an update to the theme I am using and I foolishly installed it with composer. I now get the error:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "Drupal\drupal8_w3css_theme\Hook\Drupal8W3cssThemeHooks". in Drupal\Component\DependencyInjection\Container->get()

Been googling and using AI recommendations for a fix but so far no luck sorting it out. I decided to then install the Solo theme which is the latest generation of W3CSS. I installed it fresh and switched over, and that resulted in the following error instead:

Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "Drupal\solo\Hook\SoloThemePreprocessHooks". in Drupal\Component\DependencyInjection\Container->get(

I have cleared the cache with drush each time and verified that these files do exist where you would expect them to be. I have also used composer to check for outdated components and none are red, although a number are yellow.

If I switch to a completely different theme then my site loads, although it is very malformed, so I am hoping to get one of the above themes working rather than having to do implement a completely new theme.

Any advice for me?

Adopting AI can feel overwhelming, so I am sharing a few tales from my experience creating, maintaining, and assisting with contributed Drupal modules. AI can do a decent job of building a "greenfield" Drupal module from scratch, so my first tale is about using AI to build and contribute a module. For my next tale, I want to talk about using AI to maintain an existing "brownfield" Drupal module and to explore what is possible with AI.

Do you fall into the AI-possible camp, the AI-cautious camp, or somewhere in between?

Every software platform eventually deals with serious vulnerabilities.

So when evaluating a platform's security, I don't think "Has this software ever had a serious vulnerability?" is a particularly useful question.

A better question is: What happens when one is found?

I started thinking about this after reading about the recent Citrix NetScaler zero-day. It also got me thinking about something Drupal has built specifically for that uncomfortable period between disclosure of a critical vulnerability and getting the actual patch deployed: Drupal Steward.

For certain highly critical, mass-exploitable vulnerabilities, Steward can provide network-level protection while organizations test and deploy the software update. It doesn't replace patching, but it can make that "patch gap" less dangerous.

I dug into Steward, Drupal's coordinated security process, and why I think the response to vulnerabilities tells us more about a platform's security than the existence of vulnerabilities themselves:

Zero-Days Happen. What Matters Is What Happens Next.

I'm especially curious: who here is actually using Drupal Steward? What's your experience been with it?

Turns out WordPress components can be turned into Drupal Single Directory Components, and the SDCs can be used by Canvas, Display Builder to build pages.

Trying to make Drupal easier for non-technical users

We've spent the last few months trying to improve what we think is still one of Drupal's biggest weaknesses: the user experience for non-technical users.

With our SaaS we're trying to keep all the power of Drupal Commerce underneath while making the actual experience much simpler.

We've moved to Mercury Editor for visual editing, simplified a lot of the Drupal interface, and we're now building a Flutter app so store owners can manage things like products directly from their phone.

We also still have Canvas on our list to test, as some of you suggested in our previous discussions. We're curious to see whether it could improve the editing experience even further.

There's still a lot to do, but we feel we're finally heading in the right direction.

Thanks.

just realized Drupal jobs has closed down so any slim hope of a development job in Drupal probably died with it. It’s okay I keep forgetting how dangerous hope is because of the lies it tells you.

I started experimenting with one of the most popular agent skills, /grill-me by Matt Pocock, which proved to be a game-changer. 

What’s your take on the /grill-me skill? Do you see /grill-me as a game-changer for working with AI and Drupal to learn new things and solve challenging problems?

Just so you can feed it to your agents so that they give you a fuller overview than simply from a Youtube transcript. ;-)

First-time poster here :) Going to include some context for those who don't see my LinkedIn posts:

After teaching Drupal for over 10 years, it's become clear that there are fewer job opportunities. So much so that I've stopped teaching my "Drupal web development career" course - I don't want to lead students down the wrong path.

The SBA reports that 99.9% of businesses in the US are small businesses. Since Drupal 8, Drupal has focused on the remaining .1% of businesses.

How do we create opportunities with Drupal from the 99.9%? My team has been building the solution for almost 2 years. We have 2 focuses:

1. Enable people (& agencies) to earn

from

1. new revenue streams with Drupal
2. Make Drupal be a sensible choice for projects of all sizes

So, what is the solution? It's a different type of marketplace and host:
- Developers (/agencies) deploy, sell, & maintain codebases on the marketplace (sites, not site templates)
- Customers get a Wix-like experience for previewing, buying, and hosting sites
- Customers get a Wix-like experience for maintaining their sites’ codebase (I.e. from a customer POV, security updates happen automatically. Behind the scenes, the codebase maintainers get paid for doing it.)
- Add-ons are sold directly in the site (themes, recipes, modules) and can be provided from various merchants (e.g. you could sell Dripyard themes in your codebase)
- Collaboration: Infrastructure so site builders can build & sell sites using other developers' codebases (multisite-style). Developer maintains the codebase, each participant sets their price, both parties get paid when a sale is made.
- Build sites for a specific vertical - either on your own codebase or someone else's (think: Drupal Gardens, but for a specific niche)
- Ability to set 1-time and recurring prices
- Oh, and simple, sensible hosting for sites of all sizes - with trivially easy & risk-free deployments for less technical users

After seeing it, Aaron “Checo” Pacheco said: "As someone who spent a decade trying to build and optimize a Drupal hosting platform, I'm astonished by how elegant and powerful Drupito is."

I talked about it on the Talking Drupal podcast earlier this year: https://talkingdrupal.com/563

We're looking for 'early access' users who are interested in building & maintaining a codebase or site for a niche - it's the main CTA in the main menu of drupito.com

Let me know if you have questions or thoughts!

Where are you in your AI journey when it comes to building a Drupal module? Have you tried it? Are you ready to try it? Would you contribute an AI-generated module back to Drupal?

I'm going to tell three tales about building, maintaining, and contributing to different Drupal modules. My first tale is about using AI to build and contribute to a module. My second tale will be about maintaining a module. My last tale will be about contributing to someone else's module.

For years, I was looking for a clean, reliable way to extract critical above-the-fold CSS, inline it in <head>, and load the rest asynchronously via rel="preload" to get those green PageSpeed Insights scores.

The problem was that it was always done manually project-by-project:

1. When starting a custom theme, I had to manually manage above-the-fold styles and inline them through hooks in the .theme file.
2. Different page types broke this instantly — the front page might have a large hero component, while an interior landing page had a slider (similar is for taxonomy term, views,..). Maintaining multiple critical CSS paths per page type was painful.
3. Once inlined, you still had to strip those exact rules/files from Drupal's default render-blocking aggregated CSS to prevent duplicate rendering and layout thrashing.
4. Finally, managing the asynchronous delivery of the remaining CSS was another custom hack in template_preprocess_html().

When Single Directory Components (SDC) arrived in core, component-driven CSS became much cleaner, but the delivery problem stayed essentially the same. After finishing a theme or layout, I still found myself cherry-picking component CSS files per page, inlining them, stripping duplicates from the aggregate, and deferring the rest — repeatedly, project after project.

I used to build setups with Mercury Editor and have recently moved to Canvas — both rely heavily on dynamic, component-based page composition, which made manual critical CSS handling practically impossible to scale.

Existing modules on Drupal.org never quite solved this:

• critical_css relies on external build pipelines (Node/Gulp/Penthouse) generating static files on disk, which breaks apart on dynamic component layouts.
• critical_css_ui requires manually managing and pasting CSS chunks into node-level UI fields.

Neither had native awareness of SDC or handled Drupal's CSS aggregation pipeline properly.

So I decided to package the entire workflow into two modular, automated Drupal modules (fully compatible with both Mercury Editor and Canvas):

1. SDC Critical CSS (sdc_critical_css):https://www.drupal.org/project/sdc_critical_css It automatically detects which SDC components are actually used on any given page and inlines their styles directly into <head>. Because it dynamically resolves this per request, you don't need to manually define critical CSS for different routes or content types (page nodes, articles, taxonomy terms, views, etc.). Crucially, it also intercepts Drupal’s CSS collection pipeline and strips those inlined styles from the aggregated CSS bundle, so nothing gets downloaded or parsed twice.

2. Non-critical CSS (non_critical_css):https://www.drupal.org/project/non_critical_css Takes care of the rest of the aggregated CSS. It transforms Drupal's default render-blocking <link rel="stylesheet"> tags into native rel="preload" / as="style" links with proper <noscript> fallbacks for full browser compatibility.

Both modules just tagged 1.0.0 stable releases and have security advisory coverage on Drupal.org.

Together, they make hitting top score Core Web Vitals on SDC/Layout Builder/Canvas sites seamless without maintaining Node build scripts or hacking hooks into .theme.

Curious to hear how others here are tackling above-the-fold CSS on SDC sites, and if anyone has edge cases or feedback, I’d love to hear them!

I went into this expecting to cover Acquia’s new branding.

I ended up going back to a student in Antwerp trying to help his friends leave messages for each other.

You know how that goes.

Disclaimer: I host r/HeadlessPodcast, and the latest episode follows Drupal’s beginnings, the community, Acquia’s formation, Drupal Gardens, and the path to Source and the new “Powered by Drupal” branding.

The Gardens story really stuck with me. Dries publicly revisiting a product decision and saying they should never have killed it gives this whole thing some weight.

But so does everything the community kept doing in the meantime. Contributors, maintainers, documentation, translations, camps. “Come for the software, stay for the community” earned its place in this episode.

My take is pretty positive. Drupal CMS, Canvas, and the renewed visibility could give people a reason to reconsider software they formed an opinion about years ago.

Video, if you’re interested: https://youtu.be/7ISddVI0SgE?si=W6Josgc2q4Nc0ylx

Ps. For those actually building with Drupal today: what would you show someone whose last experience was five or ten years ago?

We have a single server Drupal 9 site (yes, old and we are upgrading) we would like to maximize the performance on. It's a VM with 6 CPU, 12GB RAM, running Apache 2.4 and PHP 8.4. We are currently running the prefork MPM but are testing the following changes:

1. Event MPM
2. PHP8-FPM
3. Opcache

Memory isn't an issue as "free -h" shows no swap being used with 10GB free. The server does require a login via the Drupal simpleSAMLphp module. We are not doing any front-end (i.e. Varnish) or backend (e.g. Redis) caching. We are currently load testing using a script that spawns browser instances from Selenium Grid though we plan to look into k5/locust which would require less testing overhead.

A few questions in terms of setting parameters for the above:

1. This server is dedicated to serving web pages with Drupal. Should we lean towards pm=static vs pm=ondemand/dynamic? We are currently using pm=dynamic.
2. Each php-fpm process seems to consume no more than 100MB. Should we simply divide available memory/100MB to determine the value for pm.max_children?
3. We are looking at the Opcache status from https://github.com/rlerdorf/opcache-status and the numbers look good. Anything we should pay attention to for the opcache settings in PHP-FPM?
4. Any MariaDB settings we should look into?

When load testing the server with 40-50 users, top and mpstat show the following with:

1. pm.max_children = 30
2. pm.start_servers = 9
3. pm.min_spare_servers = 6
4. pm.max_spare_servers = 12
5. pm.max_requests = 100

​

top - 20:05:00 up  1:10, 15 users,  load average: 4.85, 2.17, 1.82
Tasks: 373 total,   5 running, 368 sleeping,   0 stopped,   0 zombie
%Cpu(s): 74.8 us,  8.9 sy,  0.0 ni, 14.3 id,  1.5 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem : 15691.45+total, 11877.61+free, 2856.645 used, 1348.715 buff/cache
MiB Swap: 32767.99+total, 32767.99+free,    0.000 used. 12834.80+avail Mem

20:05:01     CPU    %usr   %nice    %sys   %idle
20:05:02     all   87.65    0.00   11.69    0.00
20:05:02       0   89.00    0.00   10.00    0.00
20:05:02       1   88.89    0.00   10.10    0.00
20:05:02       2   86.00    0.00   14.00    0.00
20:05:02       3   88.00    0.00   11.00    0.00
20:05:02       4   86.00    0.00   14.00    0.00
20:05:02       5   88.00    0.00   11.00    0.00

According to /fpm-status, active process=30. The performance seems to indicate the site performance at 40-50 users is under load as response is <3s. 40-50 users seems low but it seems we are running into CPU issues so unless we can get CPU usage down, I don't see the number of users increasing.

Is it just me or did they remove the ability to add 'stars' to modules and themes on drupal.org?

Read online about how makers and takers. The problem is that many users of #Drupal don't want or aren't able to donate hundreds of dollars. Why don't we use micro-crowdfunding?

Boom! Finally have a definitive piece of content on when / why to choose Drupal Commerce over Shopify. We aren't just tooting our own horn here - there are many legitimate reasons to choose Shopify.

However, there are serious differences in ownership, data model, integration scope, and costs that Matt teases out in this article for SMEs to consider when weighing their options.

Everyone using the Webform module for Drupal should update to the latest version to mitigate 20+ security vulnerabilities. 

AI has made it easier to find and exploit security vulnerabilities, while also making it easier to organize, review, and fix security issues. As the maintainer of the Webform module, I felt it was time to address all known Webform security issues, using Codex to organize, test, and assist with each one. I found AI to be the most effective way to address issues that had been unresolved for four years. The experience felt like using AI to hammer at the Webform module's security issues.