Near the end of most Open Source licenses, usually in capital letters, sits a clause that disclaims almost everything: no warranty, no liability, use at your own risk.
For an organization that depends on that code, the clause is harsh. If the code fails and takes your data or revenue with it, the license owes you nothing. No fix, no refund, and no one to explain what went wrong.
That is the license doing its job. It makes the code available and protects the people who share it. Without that protection, sharing code could become a gift that backfires: a generous act turned into unlimited legal risk.
But the license can only answer the legal questions: who may use the code, on what terms, and what risk the authors are willing to accept. It cannot tell you what kind of Open Source project you are working with.
Some Open Source is "License-only Open Source": code released under an Open Source license, without active stewardship or any promise of ongoing care. There is no guarantee of updates, fixes, security response, or long-term support.
Other Open Source is "Stewarded Open Source": code cared for as shared infrastructure. Maintainers review contributions, fix bugs, respond to security issues, manage releases, provide long-term support, and much more. Organizations fund maintainers, support core development, donate infrastructure, and absorb costs end users never see.
Both types of projects are Open Source, but they are not the same. A weekend hobby project and business-critical software can ship under the exact same license. Legally, they look identical. Practically, they are worlds apart.
The difference is stewardship. The license makes code available; stewardship makes it dependable. And the more people or organizations depend on a project, the more stewardship it often requires.
Responsibility is the tax on relevance.
Distinguishing license-only from stewarded Open Source gives us the vocabulary to describe two very different realities that the words "Open Source" alone do not capture.
For example, the distinction becomes useful when we talk about contribution. If a company depends on Open Source, should it give back?
For license-only Open Source, the answer can be simple: no one is required to contribute, and that is the point. The code was shared freely, without a promise of care or an expectation of return.
Stewarded Open Source is different. The license may still require nothing, but the work does not happen for free. Someone is paying to keep your code usable, secure, and available. When you depend on that work, the question is not only what the license allows, but who helps carry the responsibilities beyond what the license requires.
The license says use at your own risk. Stewardship is what happens when people decide you should not have to.
read moreThis is the fifth post in our GitLab issue migration series. So far we’ve covered the immediate changes, the new workflow for migrated projects, how to use it, and what the migration looks like from a contributor’s perspective. This post is about which projects we’re migrating next, and why.
We are now migrating projects maintained by Ripple Makers, the individual members of the Drupal Association. If you’re a Ripple Maker who maintains one or more contrib projects, this is our thank you for your membership.
Migrating issues to GitLab, and running GitLab itself, has a real cost. There is engineering time for the migration tooling, upgrades for git.drupalcode.org, and ongoing work on the integrations that keep contribution credit, issue forks, and the rest of the Drupal.org glue working smoothly.
That cost is covered by the people and organizations who fund the Drupal Association: Ripple Makers and Drupal Certified Partners. As we schedule migration batches, we are prioritizing projects maintained by members and projects supported by Drupal Certified Partners.
To be clear: every project will eventually be migrated. Membership doesn’t change whether your project moves; it changes when. Prioritizing members is a small way to say thank you to the people whose contributions make the infrastructure itself possible.
If you’d like your projects prioritized, and, more importantly, if you’d like to support the infrastructure that the whole Drupal ecosystem runs on, this is a good moment:
Membership funds don’t just pay for GitLab. They keep Drupal.org, project packaging, GitLab CI, automatic updates infrastructure, and more running for everyone, members and non-members alike.
Found a bug in the migration itself or in the integration between Drupal.org and GitLab? Please file it in the Drupal.org customizations issue queue.
Have a question, or want to share feedback on the new workflow? Join the #gitlab-issues-feedback channel on the Drupal community Slack.
We’re continuing to iterate on this transition based on what we hear from maintainers and contributors in migrated projects. Your feedback now shapes the experience for the rest of contrib later.
Related blog posts in this series:
Related issues
This is the fifth post in our GitLab issue migration series. So far we’ve covered the immediate changes, the new workflow for migrated projects, how to use it, and what the migration looks like from a contributor’s perspective. This post is about which projects we’re migrating next, and why.
We are now migrating projects maintained by Ripple Makers, the individual members of the Drupal Association. If you’re a Ripple Maker who maintains one or more contrib projects, this is our thank you for your membership.
Migrating issues to GitLab, and running GitLab itself, has a real cost. There is engineering time for the migration tooling, upgrades for git.drupalcode.org, and ongoing work on the integrations that keep contribution credit, issue forks, and the rest of the Drupal.org glue working smoothly.
That cost is covered by the people and organizations who fund the Drupal Association: Ripple Makers and Drupal Certified Partners. As we schedule migration batches, we are prioritizing projects maintained by members and projects supported by Drupal Certified Partners.
To be clear: every project will eventually be migrated. Membership doesn’t change whether your project moves; it changes when. Prioritizing members is a small way to say thank you to the people whose contributions make the infrastructure itself possible.
If you’d like your projects prioritized, and, more importantly, if you’d like to support the infrastructure that the whole Drupal ecosystem runs on, this is a good moment:
Membership funds don’t just pay for GitLab. They keep Drupal.org, project packaging, GitLab CI, automatic updates infrastructure, and more running for everyone, members and non-members alike.
Found a bug in the migration itself or in the integration between Drupal.org and GitLab? Please file it in the Drupal.org customizations issue queue.
Have a question, or want to share feedback on the new workflow? Join the #gitlab-issues-feedback channel on the Drupal community Slack.
We’re continuing to iterate on this transition based on what we hear from maintainers and contributors in migrated projects. Your feedback now shapes the experience for the rest of contrib later.
Related blog posts in this series:
Related issues
By the Drupal AI Initiative
Following our announcement last week introducing Inside AI and Outside AI, we are excited to share how we are scaling our leadership and organizational structure to support these two parallel workstreams.
What started as an ambitious vision originally founded by Jamie Abrahams from FreelyGive quickly gained community-wide momentum. In June 2025, our founding partners – 1xINTERNET, Acquia, Dropsolid, FreelyGive, and Salsa Digital – came together to establish the official Drupal AI Initiative, providing a cohesive strategy, baseline funding, and dedicated staff. Since then, the initiative has grown rapidly to encompass over 30 partner organizations, with many of their team members stepping directly into key leadership and execution roles.
To support our rapid growth and ensure effective daily coordination, we are evolving our structure into a more robust, three-tier governance model comprising a Drupal AI Board, a Drupal AI Leadership Team, and our existing community of AI Partners.
The purpose of the Drupal AI Leadership Team is to coordinate day-to-day project execution, align technical and cross-functional work streams, and ensure all initiative activities successfully deliver on our strategic goals.
At the center of this governance evolution, this team formalizes leadership roles that have organically emerged and evolved over the past year. Rather than introducing a brand-new operational layer, this structure officially empowers the individual contributors who have already been actively driving the initiative's day-to-day work.
By having dedicated, individual leads taking ownership of specific subject-matter areas, we ensure that every key aspect of the initiative has focused guidance. This structure also provides a natural avenue for our partner organizations to showcase their technical talent and gain visibility within the ecosystem, while placing experienced contributors in charge of critical technical and horizontal areas.
The Leadership Team's execution is divided into two distinct, cooperative disciplines:
This division ensures that technical teams can focus on delivering robust functionality, while cross-functional leads act as an internal agency to validate, test, document, and promote those features before they reach users.
In an upcoming post, we will share more details about the leadership team structure, introduce our current domain leads, and outline vacant positions.
Our founding partners, who previously made up the initiative's core steering group, are transitioning to become the members of the Drupal AI Board.
The Board serves as the strategic and supporting foundation for the Leadership Team, establishing a strong, predictable operational environment. Rather than individual developers having to balance ecosystem coordination, funding allocations, and administrative hurdles alongside daily coding, the Board takes on these responsibilities.
Composed of our founding partner companies, the Board is responsible for setting the high-level strategy, defining the general initiative direction, and prioritizing our long-term roadmap. In addition to guiding this overarching strategy, the Board provides baseline initiative funding and staff, manages overall ecosystem alignment, and secures ongoing partner resource commitments. This structural backing ensures a stable operational runway, allowing the Board to focus on defining leadership functions, appointing execution leads, and securing the necessary resource allocations so developers can focus strictly on build and delivery.
For the developers, builders, and content creators actively contributing to the initiative, the day-to-day experience will feel familiar, but with clearer support structures.
Our established sprinting procedures remain completely unchanged. The community and partner teams will continue to collaborate on their scheduled sprints.
However, we are introducing two key improvements:
This structural evolution ensures that everything built by both Inside AI and Outside AI integrates seamlessly with the broader Drupal AI roadmap and aligns directly with our collective short term and long-term goals.
As we step into this new phase of growth, we are looking for dedicated partners and brilliant minds to help execute our goals.
The Drupal AI Initiative is made possible by the generous funding, resources, and technical contributions of our partner network. We are incredibly grateful to these companies for driving the future of open-source AI:
You can view the full list and status of our contributing sponsors on the official Drupal AI Partners directory.
By the Drupal AI Initiative
Following our announcement last week introducing Inside AI and Outside AI, we are excited to share how we are scaling our leadership and organizational structure to support these two parallel workstreams.
What started as an ambitious vision originally founded by Jamie Abrahams from FreelyGive quickly gained community-wide momentum. In June 2025, our founding partners – 1xINTERNET, Acquia, Dropsolid, FreelyGive, and Salsa Digital – came together to establish the official Drupal AI Initiative, providing a cohesive strategy, baseline funding, and dedicated staff. Since then, the initiative has grown rapidly to encompass over 30 partner organizations, with many of their team members stepping directly into key leadership and execution roles.
To support our rapid growth and ensure effective daily coordination, we are evolving our structure into a more robust, three-tier governance model comprising a Drupal AI Board, a Drupal AI Leadership Team, and our existing community of AI Partners.
The purpose of the Drupal AI Leadership Team is to coordinate day-to-day project execution, align technical and cross-functional work streams, and ensure all initiative activities successfully deliver on our strategic goals.
At the center of this governance evolution, this team formalizes leadership roles that have organically emerged and evolved over the past year. Rather than introducing a brand-new operational layer, this structure officially empowers the individual contributors who have already been actively driving the initiative's day-to-day work.
By having dedicated, individual leads taking ownership of specific subject-matter areas, we ensure that every key aspect of the initiative has focused guidance. This structure also provides a natural avenue for our partner organizations to showcase their technical talent and gain visibility within the ecosystem, while placing experienced contributors in charge of critical technical and horizontal areas.
The Leadership Team's execution is divided into two distinct, cooperative disciplines:
This division ensures that technical teams can focus on delivering robust functionality, while cross-functional leads act as an internal agency to validate, test, document, and promote those features before they reach users.
In an upcoming post, we will share more details about the leadership team structure, introduce our current domain leads, and outline vacant positions.
Our founding partners, who previously made up the initiative's core steering group, are transitioning to become the members of the Drupal AI Board.
The Board serves as the strategic and supporting foundation for the Leadership Team, establishing a strong, predictable operational environment. Rather than individual developers having to balance ecosystem coordination, funding allocations, and administrative hurdles alongside daily coding, the Board takes on these responsibilities.
Composed of our founding partner companies, the Board is responsible for setting the high-level strategy, defining the general initiative direction, and prioritizing our long-term roadmap. In addition to guiding this overarching strategy, the Board provides baseline initiative funding and staff, manages overall ecosystem alignment, and secures ongoing partner resource commitments. This structural backing ensures a stable operational runway, allowing the Board to focus on defining leadership functions, appointing execution leads, and securing the necessary resource allocations so developers can focus strictly on build and delivery.
For the developers, builders, and content creators actively contributing to the initiative, the day-to-day experience will feel familiar, but with clearer support structures.
Our established sprinting procedures remain completely unchanged. The community and partner teams will continue to collaborate on their scheduled sprints.
However, we are introducing two key improvements:
This structural evolution ensures that everything built by both Inside AI and Outside AI integrates seamlessly with the broader Drupal AI roadmap and aligns directly with our collective short term and long-term goals.
As we step into this new phase of growth, we are looking for dedicated partners and brilliant minds to help execute our goals.
The Drupal AI Initiative is made possible by the generous funding, resources, and technical contributions of our partner network. We are incredibly grateful to these companies for driving the future of open-source AI:
You can view the full list and status of our contributing sponsors on the official Drupal AI Partners directory.
Join Martin, Andy and Mike as they discuss what Drupal site templates are and how they differ from Drupal's traditionally bare-bones starting point, aiming to reduce setup effort and total cost of ownership while making Drupal competitive again for small nonprofits and smaller sites. They compare building templates versus client sites, covering the evolution from early Layout Builder/Recipes work to today's simpler packaging via a Drush site:export workflow, plus tooling like DripYard Recipe Builder for extracting reusable "recipe" parts.
For show notes visit: https://www.talkingDrupal.com/cafe018
Topics Martin Anderson-ClutzBased in London, Ontario, Martin transitioned from graphic design to web development, ultimately specializing in Drupal in 2005. Currently working as a Product Marketing Manager at Acquia, he is Triple Certified in Drupal and UX-certified by the world-renowned Nielsen Norman Group. His key contributions include: As a speaker & writer, presenting at Drupalcamps and Drupalcons, and a published blogger across multiple platforms, including the Acquia Dev Portal and opensource.com; as a podcast host, participating in the Talking Drupal podcast, including as the "Module of the Week" correspondent; and as an open source maintainer, developing and maintaining popular Drupal contrib modules and recipes, including Smart Date and Fullcalendar.
Andy GilesAndy is a Drupal back-end developer. In 2012, he founded Blue Oak Interactive, a development and consulting agency focused on complex Drupal site builds, particularly in e-commerce. In 2025, he partnered with Mike Herchel to launch Dripyard, a premium Drupal theme designed to reduce the cost of ownership and enhance the developer experience for modern Drupal projects.
Mike HerchelMike is a founder & developer at Dripyard, and is a longtime contributor to Drupal. He has played a key role in modernizing Drupal's frontend architecture, performance, and accessibility, and is known for helping bring Drupal's component-driven development into mainstream use. Mike has delivered projects for organizations including IBM, the U.S. Small Business Administration, and the U.S. court system. He is a frequent speaker on performance, accessibility, and modern frontend practices.
Martin Anderson-Clutz - mandclu.com mandclu
Andy Giles - andyg5000 Dripyard
Mike Herchel - mherchel Dripyard
read moreContent moderation is a data processing problem. For large sites with many content contributors, moderators can get bogged down catching obvious content policy violations without having time to do real editorial work.
Meanwhile, AI is great at fast, consistent classification of text, which is exactly the kind of work that can clog an editorial queue. It’s not a replacement for human judgment: it makes mistakes, it can be gamed, and it lacks context. But as a first-pass filter, AI can meaningfully shrink the noise that reaches a human reviewer.
This post walks through adding that type of AI content filter to an existing Drupal workflow using contrib modules and no custom code.
The full solution uses zero custom code. Here are the key contrib modules:
drupal/aiThe assumption is that a site already has a working Content Moderation workflow. The AI gate slots in between author submission and the editor queue:
[Before] Draft → Needs Review → Published [After] Draft → Needs Review → [AI gate] → AI Review Passed → Published ↘ Rejected
To support this, the workflow needs two new states (AI Review Passed, Rejected) and two new transitions (AI Approve, AI Reject). Those transitions should not be granted to any UI role as they’re triggered only by ECA.
The five modules listed above need to be installed, an AI provider configured with a securely stored API key, and the updated workflow applied to the relevant content type.
This is the core of the implementation.
Create a new ECA model at Admin → Configuration → ECA. The model has five nodes:
1. Event — Workflow: state transition Fires when an article transitions to needs_review.
2. Action — Token: set value Stores [entity:body:value] into a token named moderation_input. This uses ECA’s token replacement, which resolves field values correctly at runtime. (A note on this: the more obvious Get field value action returns null for body fields in practice — token replacement is the right approach here.)
3. Action — Moderation (from AI Integration for ECA) Calls the AI provider’s moderation operation. Set model to openai / omni-moderation-latest, token input to moderation_input, and token result to ai_result. The result token exposes [ai_result:flagged] (1 or 0) and [ai_result:information] (per-category scores).
4. Action — Workflow: transition (condition: [ai_result:flagged] = 1) Transitions to rejected. Revision log: AI moderation: content flagged.
5. Action — Workflow: transition (condition: [ai_result:flagged] = 1, negated) Transitions to ai_review_passed. Revision log: AI moderation: content passed initial screening.
The conditions use ECA’s built-in Compare two scalar values plugin. Steps 4 and 5 share the same condition — one negated, one not.
Submitting a benign article routes it to ai_review_passed with the pass log entry. Submitting content that violates the violence policy routes it to rejected with the flagged log entry. Both transitions appear in the node’s revision history with the AI-stamped message.
The OpenAI Moderation API uses fixed categories. If your policy doesn’t map to them cleanly — community guidelines, brand safety rules, domain-specific restrictions — you can replace the Moderation action with a Chat action and a configurable system prompt. The rest of the ECA model stays the same.
With a Chat action returning structured JSON (response_format: json_object), you define exactly what the AI evaluates and how it reports back. The downstream ECA conditions check the response token the same way. This makes the screening logic editable in the UI without a code change or redeploy.
A bare rejection with no context isn’t great author experience. ECA can handle the follow-on steps too. On the rejection branch, you can chain additional actions before or after the transition: send the author an email using [ai_result:information] to surface which categories were flagged, set a message on the form, or move the node to a Needs Revision state rather than a hard Rejected — giving authors the ability to edit and resubmit rather than starting over.
You could also model a full revision loop: Rejected → Needs Revision → Needs Review (with the AI check firing again on resubmit). Whether that’s appropriate depends on your content volume and how much trust you extend to repeat offenders, but the workflow and ECA config support it without any custom code.
The drupal/ai_integration_eca module is what makes this approach work cleanly. Without it, inserting AI into an ECA model would require a custom action plugin. With it, the entire integration is UI-configurable and exportable as config.
A few things worth knowing before you build on this:
ai_eca submodule inside drupal/ai is deprecated as of 1.x. Use drupal/ai_integration_eca (a separate package) instead.drupal/ai_integration_eca is still at RC as of this writing — worth checking for a stable release before going to production.coder.ddev.com gives you a full DDEV environment in the cloud, no local Docker required. This is a quick look at using it for a TYPO3 project with the freeform template.
For general background on coder.ddev.com, including access requirements and the other available templates, see the announcement post.
ddev coder-setup + ddev starttrustedHostsPattern error with ddev restart after Composer brings in the rest of the code*.coder.ddev.com subdomainddev sharecoder CLI) and clone your TYPO3 project.ddev coder-setup once in the project directory, then ddev start. If the project has a post-start Composer install hook, like rfay/typo3demo, it'll finish setting itself up automatically.ddev launch shows a trusted-host error, it's because Composer brought in the rest of the code after the first ddev start already generated additional.php. Run ddev restart to regenerate it, then reload.The workspace can be shared with other coder.ddev.com users directly, without any extra setup.
It can also be shared with ddev share, since rfay/typo3demo uses a relative base (/camino) instead of a hardcoded URL. Projects that do hardcode a full URL in base need the pre-share/post-share hook fix described in Sharing Your TYPO3 Project with ddev share.
If you have questions, reach out in any of the support channels.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
read more
In the enterprise world, Drupal is often chosen for its unparalleled flexibility and power. Organizations, including large-scale research institutions like CERN, have historically relied on Drupal to manage thousands of complex, interconnected websites. Yet, we are witnessing a trend where massive Drupal ecosystems are migrated to alternative platforms.
This migration is rarely about the CMS engine itself. It is a symptom of The Drupal Paradox: the same flexibility that makes Drupal the ideal choice for an enterprise also creates the conditions for its eventual mismanagement.
When an organization manages hundreds of websites, Drupal’s modular nature can become a double-edged sword. Mismanagement typically creeps in through three specific avenues:
Many organizations view migration as a clean slate. They assume that moving to a new platform will solve the underlying technical and process issues. This is a mistake.
If an organization lacks the governance to manage a Drupal ecosystem, they will inevitably reproduce the same technical debt on any other platform they choose. Migration is not a cure for poor architectural discipline, it is simply a very expensive way to reset the clock on systemic failure.
To ensure the longevity of an enterprise CMS, organizations must shift from a "content-editing" mindset to an "engineering-discipline" mindset:
Drupal is not failing, enterprise governance is. If you find your organization trapped in a "paradox" where your CMS feels like a burden, stop looking at migration as your only option. Start looking at the structural integrity of your team’s processes.
We don't believe in "quick fixes." We believe in building systems that respect your investment. If you are struggling with a paradox of your own, we approach enterprise architecture differently.
People have increasingly been discovering git worktree for use in working on multiple features or bugs at the same time, or for having AI agents work in parallel. A DDEV contributor training covered this, and a Drupal Florida presentation.
TYPO3 projects sometimes provide a special challenge for git worktree if they have the full URL specified in config/sites/*/config.yaml's base, like base: https://typo3.ddev.site/. When you add a second git worktree checkout, DDEV names that project after its directory, giving it a different *.ddev.site hostname—but TYPO3's base is still trying to route the first worktree's hostname, so the new one fails with a 404 "not found".
This is the same underlying problem covered in Sharing Your TYPO3 Project with ddev share, but it can be fixed with a different post-start hook fix. (If your base is already a relative path like /camino, as in the DDEV TYPO3 quickstart, there's nothing to fix—every worktree works out of the box.)
name from project .ddev/config.yamlddev config global --omit-project-name-by-defaultgit worktree checkout of a TYPO3 projectbase URL mismatch breaking the second worktreepost-start hook which checks out the original TYPO3 config.yamlBy default, DDEV names a project after the directory it lives in. Remove the name: key from .ddev/config.yaml (or set this globally with ddev config global --omit-project-name-by-default) and every git worktree checkout gets its own project name and *.ddev.site hostname automatically, matching its directory.
That's what you want for running several branches side by side, as covered in Contributor Training: git worktree for Multiple DDEV Projects—but it means a TYPO3 project with a hardcoded base containing a URL will only route correctly in whichever single worktree happens to match that hostname.
post-start and post-stop HooksUnlike ddev share, where the tunnel URL is temporary and the pre-share/post-share hooks restore the original base afterward, a worktree's hostname is permanent for the life of that checkout. So instead of a temporary swap, use a post-start hook that sets base to match whatever hostname the current worktree actually has, every time it starts, and optionally git restore on ddev stop:
# .ddev/config.yaml
hooks:
post-start:
- exec: |
for f in config/sites/*/config.yaml; do
cp "$f" "$f.post-start-backup"
newbase=$(yq '.base' "$f" | sed -E 's#^https?://[^/]+##')
[ -z "$newbase" ] && newbase="/"
yq -i ".base = \"$newbase\"" "$f"
done
typo3 cache:flush
post-stop:
- exec-host: |
git restore config/sites/*/config.yaml
The simplest answer is not to use the absolute base at all, just make it relative in the first place—base: / (or /your-path/ for a subpath)—which is hostname-independent and needs no hook. That works for git worktree, ddev share, and any other hostname change alike, as described in New ddev share Provider System.
DDEV already automatically adds a trustedHostsPattern to additional.php for any hostname running under DDEV, so PHP's own host validation isn't a concern here—only TYPO3's base setting is.
return [
# ...
'SYS' => [
'trustedHostsPattern' => '.*.*',
'devIPmask' => '*',
'displayErrors' => 1,
],
];
Each worktree is a separate DDEV project, so it needs its own database and files. See Setting Up the Database and Files in the git worktree training post for exporting from one checkout and importing into another.
rfay/typo3demoA pre-built example project based on the TYPO3 docs and DDEV quickstart is at rfay/typo3demo, with the post-start hook described here already in place.
For background on git worktree with DDEV in general, see Contributor Training: git worktree for Multiple DDEV Projects. For more on TYPO3's base URL and the ddev share version of this problem, see Sharing Your TYPO3 Project with ddev share and the docs on ddev share.
For another way to manage TYPO3 system routing check out the b13/host_variants extension, a more sophisticated way to manage what routes the TYPO3 router will accept and work with.
If you have questions, reach out in any of the support channels.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
read moreBatch and queue are fine until they aren't. Once you've hit their limits and if your site is large enough, and you will, Temporal is the answer. Crashes, retries, scaling across machines: handled, transparently, without touching your business logic. Here, Károly Négyesi, Edge Case Engineer walks through how Temporal integrates with Drupal and why it's the next step for sites that have outgrown what Drupal ships with.
Beyond serving pages, a lot of websites have background processes they need to run. Importing third party data, indexing changes, generating reports and so on. Once a site becomes so large it is no longer feasible for a single PHP process to do this for every entity it cares about, things become more difficult.
Drupal provides two APIs for long-running processes: batch and queue. A batch runs an operation, saves state and then runs it again until the operation says "stop". However, if an operation fails then the entire batch aborts. Queue lines up operations and runs them independently of each other so the error handling is somewhat better. If an operation fails then the rest of the operations can run but there is very little control over retries. These two are good for the basics, they are good enough to be included in Drupal core, but when you are dealing with larger sites they are woefully inadequate. I should know: I wrote the queue API originally.
What if we had an ability to run these processes without having to worry about crashes, retries, or scaling across machines with extensive reporting about what has happened? That system is Temporal, and this post will walk through how it integrates with Drupal.
In Temporal, your Drupal code is an activity. Activities are a single unit of work. It doesn't matter whether it takes a short or long time, for example transcoding media might take a long time, but it's still a single unit. A workflow tells Temporal which activities to run and how to retry them. It has a rich selection of retry strategies. It also controls various timeouts. One of the more interesting timeouts is the heartbeat for long-running activities: if the activity doesn't send a heartbeat within the specified time, it will be cancelled. Heartbeats can also carry progress information.
The workflow is a long-running process and if it stops for any reason, Temporal makes it resume where it stopped. When I first read this I thought "huh, maybe it somehow saves the memory state but that'd be very fugly" and no, that's not what it does. Instead, this magic is achieved by saving the inputs and outputs of every activity call in its own durable event log. There is a UI to see the log which also includes workflow events besides these activity events.
Thanks to this event log, when a workflow is restarted the activities do not need to be rerun, the workflow fast-forwards to the point where it stopped based on the event log replay. I can't emphasize enough how important this is: no matter what crashes and when, the system completely transparently handles it. The activity calls a third party service that is temporarily down and so it needs to return with an error? PHP crashed with an out of memory error because Drupal leaks memory like a sieve? No need to worry about any of this, no need to write elaborate retry strategies for the remote call, no need to try to patch up the leaking sieve. Temporal will retry the activity, the workflow will continue and neither needs to care about errors and crashes.
For this to work well, workflows need to be deterministic: given the same series of events, a workflow must always make the same decisions. For this reason, workflows should not consult databases, file systems, clocks, random numbers, and the like. That's a job for activities. Most workflows will even avoid logging to prevent any side effects, especially since Temporal already records all activity inputs and outputs.
And activities are recommended to be idempotent: running them multiple times should have the same result as running them once. This is important because they can be re-tried if they fail. A classic example of an idempotent operation is the stop button on a media player: no matter how many times you tap it the music will not play. The play/pause button, on the other hand, is the classic example for a non-idempotent operation. Within PHP, writing to a stream opened with fopen('filename', 'w') is idempotent: the contents of the file become the data written. On the other hand, if a stream is opened with fopen('filename', 'a') then the writes are not idempotent: the data is appended over and over again.
To further highlight the difference between the two, consider a database MERGE: the operation will want to report back whether the row was inserted or updated, so it is not deterministic, but it is idempotent because the database row ends up with the same data either way.
Enough of the theoretical talk, let's talk code!
A workflow is a PHP class. To make it easy for Drupal to discover them, they are in the Drupal\mymodule\Temporal\Workflow namespace and the class has the Temporal\Workflow\WorkflowInterface attribute. This pattern should be familiar from writing plugins. This attribute is enough for Temporal to recognize this as a workflow class. Temporal also requires the workflow method to have the Temporal\Workflow\WorkflowMethod attribute.
While a workflow looks like a Drupal plugin, it is not. As we discussed workflows need to be deterministic and due to the complexity of Drupal it is almost impossible to guarantee any call into Drupal to be deterministic so it's best if workflows do not talk to Drupal at all. The integration encourages this: workflow classes are instantiated by Temporal directly without passing any arguments to the constructor.
The most important thing a workflow does is calling an activity. The Temporal PHP SDK's mechanism for this is a bit unusual at first, but it's the same pattern as mocks/stubs in phpunit: activity classes get a stub in the phpunit sense and the methods defined in the activity class are called on this stub.
For example:
/** @var \Drupal\temporal\Temporal\GenericActivity $activity */
$activity = Workflow::newActivityStub($activityClass);
$ids = yield $activity->getIds();(Irrelevant arguments are cut from this example, see the GenericWorkflowBase class shipping with the module for the rest.)
Calling a method on the activity stub returns a promise (from the ReactPHP package) that encapsulates this method invocation. Then yield hands back control to the Temporal PHP SDK, which resolves this promise by sending the activity to the Temporal server as a gRPC request. (Yes, yield can have a value, see the documentation for the rarely used Generator::send() for more.) It is not necessary to yield after every call: see ParallelGenericWorkflow for an example on how to instruct Temporal to run multiple activities in parallel.
Once you are used to this calling convention this is much easier to read than a traditional request builder. Now you can see why the code uses the old /** @var */ convention instead of asserting the type directly: as far as the IDE and the developer is concerned, $activity can be treated as an instance of $activityClass. But in reality, it's an ActivityProxy class.
When the Temporal server gets the request to call an activity, it might just send the relevant answer immediately if it is replaying the event log. Otherwise, it logs the activity inputs and puts the request in a task queue. The task queues are processed by workers, we will get back to them after discussing activities. First let's mention the two example workflows shipped with the module. Both call an activity for a large list of IDs (by default 1000), then small chunks of these (by default 20) are sent back to the activity for processing. One workflow launches a chunk worth of activities in parallel, the other sends the chunk in a single call. The former is good for something like search indexing; the latter is good for anything that writes the database and wants to keep database load lower by keeping many writes in a single transaction. A lot of tasks can be accomplished by writing an activity for one of these two, so writing a workflow is not always necessary.
Writing activities is much easier: the code does not need to talk to Temporal, these are normal Drupal plugins containing ordinary Drupal code and writing Drupal code is very easy ;). As usual for plugins, they need to be within a specific namespace, Drupal\mymodule\Temporal\Activity with the Temporal\Activity\ActivityInterface attribute on the class which, again, is enough for Temporal as well to recognize it as an activity. Methods are marked with the ActivityMethod attribute for Temporal.
While the code doesn't need to contain calls to Temporal, there are some considerations knowing they will be used by Temporal:
ApplicationFailure, which, among others, can tell Temporal whether the failure can be retried at all.Activity::heartbeat($progress);
It really must be noted how easy it is to work with the Temporal PHP SDK. We have a complex server-client architecture but most of the complexity is not visible at all: activity calls are hidden behind a proxy class and a simple yield, progress reporting is a single static method call and simple error handling is completely automatic.An example activity is shipped with the module which re-saves every entity of an entity type.
Before we can get to trying it, there's one more thing we need to introduce: Workers. These are long-running processes that poll the Temporal task queues and run workflows and activities. To better support their long-running nature, Temporal uses the RoadRunner application server for them. The Drupal integration ships this worker as a Drush command and supplies a sample .rr.yaml RoadRunner configuration to run this command. Most of the time simply copying the configuration to the project root and running rr serve is all you need to do. Read the module README.md for more. Besides a Temporal server instance at least one worker is needed for Temporal to work. But you can run as many as the workload warrants.
To round it off, there's a Drush command to start workflows and another to send signals and queries to them.
To make local development easier, a DDEV add-on (chx/ddev-temporalio) has been developed as well, this spins up a Temporal server and a Temporal web UI. So in a ddev project, you can run
ddev get chx/ddev-temporalio
ddev restart
ddev composer require 'drupal/temporal:^2.1'
ddev drush en -y temporal
ddev drush temporal:workflow:start 'Drupal\temporal\Temporal\Workflow\GenericWorkflow' 'Drupal\temporal\Temporal\Activity\EntityResave' user
This will re-save every user entity. The first argument of the Drush temporal:workflow:start command is the name of the workflow. In turn, the first argument of this particular workflow is the activity class. This is not a Temporal convention or even a convention of the Drupal-temporal integration, it's simply convenient for such a generic workflow. The rest of the arguments are passed to the activity and the entity resave activity needs the entity type.
We started with talking about batch, let's finish with it, too: we actually integrated the Drupal batch system with temporal. In the next blog post we will talk about that. Teaser: you can start the batch and close the browser tab.
Running into the limits of Drupal's batch and queue? See how Tag1 scales Drupal.
read moreI’ve been part of the Drupal community for nearly twenty years, contributing as a former Drupal Association Board member, founder and Chair of Drupal Colorado, organizer of DrupalCamp Colorado, speaker, mentor, volunteer, and advocate. Professionally, I work at the intersection of technology, strategy, and community. Today I’m AI Ambassador at amazee.io, where I help organizations explore responsible open source AI and contribute to the Drupal AI Strategic Initiative. Before that, I spent nearly a decade at Pfizer leading enterprise digital platforms, global web strategy, and AI initiatives. Beyond my professional work, I’m a passionate advocate for neuroinclusion, accessibility, and universal design. As someone who is autistic, has ADHD, and dyslexia, I believe our strongest communities are the ones that welcome different perspectives and different ways of thinking. Whether I’m organizing an event, mentoring a new contributor, speaking at a conference, or serving on a nonprofit board, my goal is always the same: leave Drupal stronger than I found it and help create opportunities for the next generation of contributors. If you’d like to learn more about my background and contributions, you’ll find additional details on my Drupal.org profile.
For me, Drupal started as software, but it evolved into community.
If Drupal disappeared tomorrow, I’d still have some of my closest friends, mentors, and confidants because of the relationships this project has created. That’s how I know community is the most enduring thing we’ve built together.
Building community isn’t just about attracting new people. It’s about creating an environment where they feel welcome, where they can learn, contribute, grow into leadership, and eventually help the next generation do the same.
Over the past twenty years, I’ve tried to contribute to that in whatever way I could: organizing DrupalCamp Colorado, helping found the Event Organizers Working Group, serving on the Drupal Association Board, mentoring first-time speakers, advocating for neuroinclusion, contributing to the Drupal AI Initiative, and simply making time for people who are looking for a place to belong.
Strong communities don’t happen by accident. They require stewardship, empathy, and a willingness to invest in people for the long term. When we build systems that help people succeed, we don’t just strengthen the community, we strengthen Drupal itself.
Advocating for Drupal means helping people see not only what Drupal is today, but what it can become.
Sometimes that means introducing someone to Drupal for the first time. Sometimes it means helping an organization adopt Drupal or contribute back to the project. Increasingly, it means representing Drupal in conversations far beyond our own community.
Over the past year, I’ve had the opportunity to speak about Drupal and open source in places where Drupal hasn’t traditionally had a voice, including AI conferences, international open source events, and United Nations Open Source Week. Those conversations reinforced something I’ve believed for a long time: Drupal has an important story to tell, but we need to be telling it more often and to more audiences.
Advocacy also means being honest. It means celebrating what makes Drupal exceptional while also recognizing that we face real challenges. The technology landscape is changing rapidly. Open source is evolving. Communities have new expectations. If we want Drupal to thrive for the next twenty years, we need to be willing to innovate while remaining true to the values that have always defined us: openness, collaboration, inclusion, and community.
For me, advocating for Drupal means showing up, listening carefully, building bridges, and helping ensure that Drupal continues to be a project the world looks to as a leader in open source.
I’m running because I believe Drupal is at one of the most important moments in its history.
We’re navigating enormous opportunities through AI, changing expectations around open source, and an increasingly challenging economic environment. At the same time, many members of our community are asking an important question: “Is anyone listening?”
I believe they deserve to be heard.
The Drupal Association exists to serve the project and its community. That means more than delivering programs and organizing events. It means listening carefully, communicating transparently, and ensuring that contributors feel they have a meaningful voice in the future of Drupal.
Over the past year I’ve worked to help move Drupal forward through the Drupal AI Initiative, advocacy, training, mentoring, and community building. Those experiences have reinforced something I’ve believed for a long time: our greatest strength isn’t our technology alone. It’s the people who choose to invest their time, talent, and trust in this project.
If elected, I’ll work to strengthen that trust by helping build a Drupal Association that is financially resilient, forward-looking, and deeply connected to the community it serves. I want contributors to know that their voices matter, that their concerns are heard, and that together we’re building a stronger future for Drupal.
That’s why I’m running.
I bring a combination of experience that I believe is particularly valuable for the Drupal Association at this point in its history.
I’ve served on the Drupal Association Board before, chaired its Governance Committee, and helped shape governance changes that continue to guide the organization today. Beyond Drupal, I’ve spent nearly two decades serving on nonprofit boards and understand both the strategic responsibilities and fiduciary duties that effective governance requires.
I’m also deeply engaged in Drupal’s future. Through the Drupal AI Strategic Initiative, my work as AI Ambassador at amazee.io, community training, speaking, and mentoring, I’ve been helping contributors understand and adopt new technologies while staying true to Drupal’s values of openness, transparency, and collaboration.
At the same time, I remain connected to the grassroots community. I’ve helped lead DrupalCamp Colorado for nineteen years, continue to mentor new contributors and speakers, and believe some of the best ideas for Drupal begin in our local communities.
Finally, I bring experience from outside our ecosystem. After nearly a decade leading enterprise digital platforms and AI initiatives at Pfizer, I understand the challenges and expectations of the organizations that choose Drupal. That perspective helps bridge the needs of enterprise users with the values that make Drupal unique.
Experience and vision matter. But leadership is ultimately measured by showing up, especially when the work is hard. I’ve tried to do that consistently for nearly twenty years: listening, building, mentoring, organizing, and helping leave this community stronger than I found it. If you choose to place your trust in me again, that’s exactly how I’ll serve on the Drupal Association Board.
My favourite Drupal memory goes all the way back to DrupalCon Barcelona in 2007.
I had just joined a Drupal agency, and my connection to the community was still very small. I’d been to a few local meetups when one of the founders asked, “Do you have a passport? Would you like to go to Barcelona?” My answer was an immediate, “Yes!”
There were only about 430 people at that DrupalCon, and for the first time I found myself surrounded by the people whose names I’d been seeing in the issue queues and documentation. I met Dries Buytaert, Moshe Weitzman, Karoly “chx” Negyesi, Morten Birch Heide-Jørgensen (MortenDK), Gábor Hojtsy, Jeff Eaton, Merlin of Chaos, Angie “webchick” Byron, and so many others who were shaping Drupal’s future.
What struck me wasn’t that they were influential. It was that they were approachable. They welcomed questions, shared ideas freely, and treated a newcomer like I belonged there.
That experience changed the trajectory of my career. It showed me that Drupal wasn’t just exceptional software. It was an exceptional community. Looking back, I think that’s the moment I stopped being someone who used Drupal and started becoming someone who wanted to help build Drupal.
Today, one of my favourite parts of every DrupalCon is welcoming someone who’s attending for the first time. Twenty years ago, the community made room for me. Ever since, I’ve tried to do the same for others.
I’ve been part of the Drupal community for nearly twenty years, contributing as a former Drupal Association Board member, founder and Chair of Drupal Colorado, organizer of DrupalCamp Colorado, speaker, mentor, volunteer, and advocate. Professionally, I work at the intersection of technology, strategy, and community. Today I’m AI Ambassador at amazee.io, where I help organizations explore responsible open source AI and contribute to the Drupal AI Strategic Initiative. Before that, I spent nearly a decade at Pfizer leading enterprise digital platforms, global web strategy, and AI initiatives. Beyond my professional work, I’m a passionate advocate for neuroinclusion, accessibility, and universal design. As someone who is autistic, has ADHD, and dyslexia, I believe our strongest communities are the ones that welcome different perspectives and different ways of thinking. Whether I’m organizing an event, mentoring a new contributor, speaking at a conference, or serving on a nonprofit board, my goal is always the same: leave Drupal stronger than I found it and help create opportunities for the next generation of contributors. If you’d like to learn more about my background and contributions, you’ll find additional details on my Drupal.org profile.
For me, Drupal started as software, but it evolved into community.
If Drupal disappeared tomorrow, I’d still have some of my closest friends, mentors, and confidants because of the relationships this project has created. That’s how I know community is the most enduring thing we’ve built together.
Building community isn’t just about attracting new people. It’s about creating an environment where they feel welcome, where they can learn, contribute, grow into leadership, and eventually help the next generation do the same.
Over the past twenty years, I’ve tried to contribute to that in whatever way I could: organizing DrupalCamp Colorado, helping found the Event Organizers Working Group, serving on the Drupal Association Board, mentoring first-time speakers, advocating for neuroinclusion, contributing to the Drupal AI Initiative, and simply making time for people who are looking for a place to belong.
Strong communities don’t happen by accident. They require stewardship, empathy, and a willingness to invest in people for the long term. When we build systems that help people succeed, we don’t just strengthen the community, we strengthen Drupal itself.
Advocating for Drupal means helping people see not only what Drupal is today, but what it can become.
Sometimes that means introducing someone to Drupal for the first time. Sometimes it means helping an organization adopt Drupal or contribute back to the project. Increasingly, it means representing Drupal in conversations far beyond our own community.
Over the past year, I’ve had the opportunity to speak about Drupal and open source in places where Drupal hasn’t traditionally had a voice, including AI conferences, international open source events, and United Nations Open Source Week. Those conversations reinforced something I’ve believed for a long time: Drupal has an important story to tell, but we need to be telling it more often and to more audiences.
Advocacy also means being honest. It means celebrating what makes Drupal exceptional while also recognizing that we face real challenges. The technology landscape is changing rapidly. Open source is evolving. Communities have new expectations. If we want Drupal to thrive for the next twenty years, we need to be willing to innovate while remaining true to the values that have always defined us: openness, collaboration, inclusion, and community.
For me, advocating for Drupal means showing up, listening carefully, building bridges, and helping ensure that Drupal continues to be a project the world looks to as a leader in open source.
I’m running because I believe Drupal is at one of the most important moments in its history.
We’re navigating enormous opportunities through AI, changing expectations around open source, and an increasingly challenging economic environment. At the same time, many members of our community are asking an important question: “Is anyone listening?”
I believe they deserve to be heard.
The Drupal Association exists to serve the project and its community. That means more than delivering programs and organizing events. It means listening carefully, communicating transparently, and ensuring that contributors feel they have a meaningful voice in the future of Drupal.
Over the past year I’ve worked to help move Drupal forward through the Drupal AI Initiative, advocacy, training, mentoring, and community building. Those experiences have reinforced something I’ve believed for a long time: our greatest strength isn’t our technology alone. It’s the people who choose to invest their time, talent, and trust in this project.
If elected, I’ll work to strengthen that trust by helping build a Drupal Association that is financially resilient, forward-looking, and deeply connected to the community it serves. I want contributors to know that their voices matter, that their concerns are heard, and that together we’re building a stronger future for Drupal.
That’s why I’m running.
I bring a combination of experience that I believe is particularly valuable for the Drupal Association at this point in its history.
I’ve served on the Drupal Association Board before, chaired its Governance Committee, and helped shape governance changes that continue to guide the organization today. Beyond Drupal, I’ve spent nearly two decades serving on nonprofit boards and understand both the strategic responsibilities and fiduciary duties that effective governance requires.
I’m also deeply engaged in Drupal’s future. Through the Drupal AI Strategic Initiative, my work as AI Ambassador at amazee.io, community training, speaking, and mentoring, I’ve been helping contributors understand and adopt new technologies while staying true to Drupal’s values of openness, transparency, and collaboration.
At the same time, I remain connected to the grassroots community. I’ve helped lead DrupalCamp Colorado for nineteen years, continue to mentor new contributors and speakers, and believe some of the best ideas for Drupal begin in our local communities.
Finally, I bring experience from outside our ecosystem. After nearly a decade leading enterprise digital platforms and AI initiatives at Pfizer, I understand the challenges and expectations of the organizations that choose Drupal. That perspective helps bridge the needs of enterprise users with the values that make Drupal unique.
Experience and vision matter. But leadership is ultimately measured by showing up, especially when the work is hard. I’ve tried to do that consistently for nearly twenty years: listening, building, mentoring, organizing, and helping leave this community stronger than I found it. If you choose to place your trust in me again, that’s exactly how I’ll serve on the Drupal Association Board.
My favourite Drupal memory goes all the way back to DrupalCon Barcelona in 2007.
I had just joined a Drupal agency, and my connection to the community was still very small. I’d been to a few local meetups when one of the founders asked, “Do you have a passport? Would you like to go to Barcelona?” My answer was an immediate, “Yes!”
There were only about 430 people at that DrupalCon, and for the first time I found myself surrounded by the people whose names I’d been seeing in the issue queues and documentation. I met Dries Buytaert, Moshe Weitzman, Karoly “chx” Negyesi, Morten Birch Heide-Jørgensen (MortenDK), Gábor Hojtsy, Jeff Eaton, Merlin of Chaos, Angie “webchick” Byron, and so many others who were shaping Drupal’s future.
What struck me wasn’t that they were influential. It was that they were approachable. They welcomed questions, shared ideas freely, and treated a newcomer like I belonged there.
That experience changed the trajectory of my career. It showed me that Drupal wasn’t just exceptional software. It was an exceptional community. Looking back, I think that’s the moment I stopped being someone who used Drupal and started becoming someone who wanted to help build Drupal.
Today, one of my favourite parts of every DrupalCon is welcoming someone who’s attending for the first time. Twenty years ago, the community made room for me. Ever since, I’ve tried to do the same for others.
I'm Helge, 50 years old, originally from northern Norway and now based in Bergen, Norway, married with one child. I've worked with Drupal for over 20 years as a user, developer, and project manager, and hold a degree in philosophy that shapes how I approach problem-solving and community work.
Since 2017 I've organized the PHP Bergen / Drupal Bergen meetups, and since 2024 I've served on the board of Drupal Norway. Outside of Drupal, I enjoy cooking, 3D printing, and open source more broadly.
To me, building community means bringing people together around a shared goal and giving them a reason to keep showing up — including me.
Over the years I've learned that it's really about building real relationships, not just connections of convenience: staying curious about new people, and making sure new faces feel just as welcome as familiar ones. Above all, it's about sharing knowledge. Even though I might not be the best programmer, I've both learned a lot from others and seen others grow through the knowledge we've shared
To me, advocating for Drupal means standing up for open source as a model that benefits everyone, not just those who can afford proprietary alternatives. It means helping keep the internet open — built on shared, transparent code rather than closed platforms controlled by a few.
It also means taking security seriously, since trust in open source depends on the community's commitment to building and maintaining software responsibly. Advocating for Drupal isn't just about promoting a CMS; it's about promoting the values behind it — openness, collaboration, and shared responsibility for the tools we all depend on.
After more than 20 years working with Drupal — as a user, developer, and project manager — I want to take the next step and contribute more directly to the project's future, beyond what I've done locally through meetups and the Drupal Norway board.
I believe Drupal needs to invest more in marketing and clearly communicating its strengths, especially as the CMS landscape becomes more crowded and competitive. I also think the community needs a balanced, thoughtful approach to AI — embracing the opportunities it offers while being deliberate about how it's integrated into the project and its workflows.
Finally, I'm motivated by the need to bring in more junior developers and contributors; Drupal's long-term health depends on building a pipeline of new talent who can carry the project forward. Running for the board is my way of turning two decades of experience into a more active role in shaping where Drupal goes next.
I bring over 20 years of hands-on experience with Drupal, combined with a varied professional background spanning sales, marketing, development, and project management. That combination is exactly why I want to focus on two things I see as key drivers for Drupal's future: marketing Drupal more effectively toward large and public sector organizations, and making Drupal accessible to younger generations of developers and contributors.
Since my time as a student at university, I've been involved in volunteer projects, and I've carried that same commitment into organizing the Bergen meetups and serving on the Drupal Norway board — experience that's taught me how to bring people together around a shared goal. I want to put that experience to work for the Drupal Association, helping the project grow both its institutional reach and its next generation of contributors.
One of my favorite memories is from an early Drupal Bergen meetup, where a group of shop employees showed up completely bewildered — they'd actually meant to go to an escape room and ended up with us instead. Once they were there, they stuck around, and ended up thoroughly impressed by what Drupal can do, even though they were probably about as far from our target audience as you could get.
I'm Helge, 50 years old, originally from northern Norway and now based in Bergen, Norway, married with one child. I've worked with Drupal for over 20 years as a user, developer, and project manager, and hold a degree in philosophy that shapes how I approach problem-solving and community work. Since 2017 I've organized the PHP Bergen / Drupal Bergen meetups, and since 2024 I've served on the board of Drupal Norway. Outside of Drupal, I enjoy cooking, 3D printing, and open source more broadly.
To me, building community means bringing people together around a shared goal and giving them a reason to keep showing up — including me. Over the years I've learned that it's really about building real relationships, not just connections of convenience: staying curious about new people, and making sure new faces feel just as welcome as familiar ones. Above all, it's about sharing knowledge. Even though I might not be the best programmer, I've both learned a lot from others and seen others grow through the knowledge we've shared
To me, advocating for Drupal means standing up for open source as a model that benefits everyone, not just those who can afford proprietary alternatives. It means helping keep the internet open — built on shared, transparent code rather than closed platforms controlled by a few. It also means taking security seriously, since trust in open source depends on the community's commitment to building and maintaining software responsibly. Advocating for Drupal isn't just about promoting a CMS; it's about promoting the values behind it — openness, collaboration, and shared responsibility for the tools we all depend on.
After more than 20 years working with Drupal — as a user, developer, and project manager — I want to take the next step and contribute more directly to the project's future, beyond what I've done locally through meetups and the Drupal Norway board. I believe Drupal needs to invest more in marketing and clearly communicating its strengths, especially as the CMS landscape becomes more crowded and competitive. I also think the community needs a balanced, thoughtful approach to AI — embracing the opportunities it offers while being deliberate about how it's integrated into the project and its workflows. Finally, I'm motivated by the need to bring in more junior developers and contributors; Drupal's long-term health depends on building a pipeline of new talent who can carry the project forward. Running for the board is my way of turning two decades of experience into a more active role in shaping where Drupal goes next.
I bring over 20 years of hands-on experience with Drupal, combined with a varied professional background spanning sales, marketing, development, and project management. That combination is exactly why I want to focus on two things I see as key drivers for Drupal's future: marketing Drupal more effectively toward large and public sector organizations, and making Drupal accessible to younger generations of developers and contributors. Since my time as a student at university, I've been involved in volunteer projects, and I've carried that same commitment into organizing the Bergen meetups and serving on the Drupal Norway board — experience that's taught me how to bring people together around a shared goal. I want to put that experience to work for the Drupal Association, helping the project grow both its institutional reach and its next generation of contributors.
One of my favorite memories is from an early Drupal Bergen meetup, where a group of shop employees showed up completely bewildered — they'd actually meant to go to an escape room and ended up with us instead. Once they were there, they stuck around, and ended up thoroughly impressed by what Drupal can do, even though they were probably about as far from our target audience as you could get.
Hi, I'm Janna. I’m a software engineer based in Australia, and day-to-day I wear a lot of hats—from team lead and developer to accessibility tester on all kinds of projects. I care a lot about open source, which is why you’ll usually find me co-organising local WordPress meetups, running Drupal code sprints, or helping out with DrupalSouth. I'm also out there speaking at various tech events such as AI engineer and DDD conferences; a couple of my recent presentations were “Secure By Design” and “Engineering for the Agentic Web When 50% of Your Traffic is Robots.” I’m contributing to Drupal code, updating documentation, and working on community initiatives every single week. After running for the board back in 2024, I’m excited to step up again to support our global community.
Building community means putting down the microphone and actually doing the work to bring people together. With the disconnect we’re all feeling post-COVID and in the rush toward AI, I believe we desperately need the human factor back. For me, it’s about creating physical spaces where one human being sits down and listens to the concerns of another. Whether that's organising local meetups, running conferences, or setting up monthly sprints, I focus on the logistics that get people into the same room so anyone, regardless of their skill level, feels included, heard, and welcomed.
Advocating for Drupal means earning back popularity among newcomers (student, teachers) and rebuilding the credibility with technical users who have moved on to other systems. Drupal needs to be a practical, go-to tool for small site builders, independent businesses, and universities. Real advocacy also means protecting how Drupal is discovered. In a world driven by LLMs and AI search engines, we have to ensure our documentation is clean, versioned, and accurate so these tools index modern Drupal correctly, rather than providing not so relevant or confusing documentation or outdated examples.
I am running to help the Association to focus back to three critical areas that are vital for Drupal's long-term future:
You should vote for me if you feel that Drupal leadership is turning conservative. I'm hands-on and I don't live on the island. Every single week, I am on the ground contributing to Drupal code, running local meetups, and organising conferences like DrupalSouth. But I also step outside our bubble to actively promote Drupal at other major tech events. Vote for me if you want a progressive, non-conservative voice on the board - someone focused, competitive, and relevant to the wider dev community.
Nothing beats the spark when people discover Drupal for the first time. Whether I’m working with clients, mentoring students, collaborating with fellow presenters, or bouncing ideas off colleagues, I love that exact moment when the lightbulb goes off. Seeing someone realise the sheer potential of what they can build with Drupal is incredibly rewarding, and it’s what keeps me energised to do this work.
Hi, I'm Janna. I’m a software engineer based in Australia, and day-to-day I wear a lot of hats—from team lead and developer to accessibility tester on all kinds of projects. I care a lot about open source, which is why you’ll usually find me co-organising local WordPress meetups, running Drupal code sprints, or helping out with DrupalSouth. I'm also out there speaking at various tech events such as AI engineer and DDD conferences; a couple of my recent presentations were “Secure By Design” and “Engineering for the Agentic Web When 50% of Your Traffic is Robots.” I’m contributing to Drupal code, updating documentation, and working on community initiatives every single week. After running for the board back in 2024, I’m excited to step up again to support our global community.
Building community means putting down the microphone and actually doing the work to bring people together. With the disconnect we’re all feeling post-COVID and in the rush toward AI, I believe we desperately need the human factor back. For me, it’s about creating physical spaces where one human being sits down and listens to the concerns of another. Whether that's organising local meetups, running conferences, or setting up monthly sprints, I focus on the logistics that get people into the same room so anyone, regardless of their skill level, feels included, heard, and welcomed.
Advocating for Drupal means earning back popularity among newcomers (student, teachers) and rebuilding the credibility with technical users who have moved on to other systems. Drupal needs to be a practical, go-to tool for small site builders, independent businesses, and universities. Real advocacy also means protecting how Drupal is discovered. In a world driven by LLMs and AI search engines, we have to ensure our documentation is clean, versioned, and accurate so these tools index modern Drupal correctly, rather than providing not so relevant or confusing documentation or outdated examples.
I am running to help the Association to focus back to three critical areas that are vital for Drupal's long-term future:
You should vote for me if you feel that Drupal leadership is turning conservative. I'm hands-on and I don't live on the island. Every single week, I am on the ground contributing to Drupal code, running local meetups, and organising conferences like DrupalSouth. But I also step outside our bubble to actively promote Drupal at other major tech events. Vote for me if you want a progressive, non-conservative voice on the board - someone focused, competitive, and relevant to the wider dev community.
Nothing beats the spark when people discover Drupal for the first time. Whether I’m working with clients, mentoring students, collaborating with fellow presenters, or bouncing ideas off colleagues, I love that exact moment when the lightbulb goes off. Seeing someone realise the sheer potential of what they can build with Drupal is incredibly rewarding, and it’s what keeps me energised to do this work.
I am the volunteer project lead for Drupal Forge and a member of the community health team. I joined the Drupal community in 2005 and have been contributing ever since. Until 2026, I maintained the Drupal platform for Estée Lauder Companies as a senior software engineer at Cognizant. I live in Lakeland, Florida with my wife, three sons, and two cats.
Building community means two things:
We all own every Drupal project. We should continue to prioritize accessibility for people of all abilities in our products, tools, and events. We need to do a better job of responding to behavior that makes people feel unwelcome. We should not treat volunteers who maintain projects as if they were paid employees maintaining something we bought.
We need to improve our ability to work with people of different languages, skills, and availability. Many issues have been ignored for years because a contributor did not provide a requested test or change notice. We should establish a norm of assuming people have given their best; and, if more is needed, it’s up to the rest of us to move it forward.
To me, advocating for Drupal means spreading its value widely and making it easy to discover. Advocating for Drupal includes promoting the wider open source ecosystem and helping more vendors distribute ready made, fully customizable experiences to users. Everyone has a stake in Drupal; they just need to realize it.
I have a vision for making the value of Drupal easier to discover. In 2024 I moved to fulfill this vision by founding Drupal Forge as a community platform for zero-friction trial experiences. My vision includes developing ready-made kits for launching Drupal businesses. I want to ensure that Drupal experts like me always have work and that Drupal benefits projects that are too small for big agencies but introduce it to a wider audience.
I believe the Drupal Association is ready to lead us to this vision. After two years of leading from outside, it is time for me to try leading from within.
I have proved my effectiveness by leading the Drupal Forge project. I know the Drupal community from 20 years of contribution. I also know the challenges facing new members from volunteering as a mentor for Discover Drupal, the Open University Initiative, and Drupal events.
Like many of you, I lost a secure, well-paid job when the company I worked with switched to a different platform. I am committed to regaining the ground we have lost. I understand the value of Drupal. Drupal is not only more open but also ahead of other platforms in many ways. In many cases where Drupal is not the right solution, it is very close to being the right solution and just needs a push to get there.
My single favorite moment is the first time I installed Drupal and learned how many features I could enable without writing code.
Darren is the volunteer project lead for Drupal Forge. He joined the Drupal community in 2005 and has been an active contributor ever since. Until 2026, he maintained the Drupal platform for Estée Lauder Companies as a senior software engineer at Cognizant. Darren lives in Lakeland, Florida with his wife, three sons, and two cats.
Building community means two things:
We all own every Drupal project. We should continue to prioritize accessibility for people of all abilities in our products, tools, and events. We need to do a better job of responding to behavior that makes others feel unwelcome. We should not treat volunteers who maintain projects as if they were paid employees maintaining something we bought.
We need to improve our ability to work with people of different languages, skill levels, and time to contribute. Many issues have been ignored for years because a contributor did not provide a requested test or change notice. We need to establish a norm of assuming that whatever someone contributes is the best they can do; and, if more is needed, it’s up to the rest of us to move it forward.
To me, advocating for Drupal means spreading its value widely and making it easy to discover. Advocating for Drupal includes promoting the wider open source ecosystem and helping more vendors distribute ready made, fully customizable experiences to users. Everyone has a stake in Drupal; they just need to realize it.
I have a vision for making the value of Drupal easier to discover. In 2022 I took action to fulfill this vision by founding Drupal Forge as a community platform for zero-friction trial experiences. My vision includes developing ready-made kits for launching Drupal businesses. I want to ensure that Drupal experts like me always have work and that Drupal is used for projects that introduce it to a wider audience but are too small for big agencies.
I believe the Drupal Association is ready to lead us to this vision. After four years of leading from the outside, it is time for me to try leading from within.
I know the Drupal community from 20 years of contribution. I also know the challenges facing new members from volunteering as a mentor for Discover Drupal, the Open University Initiative, and Drupal events.
I understand the value of Drupal. Like many of you, I lost a secure, well-paid job when the large company I worked for decided to switch to a different platform. I am committed to regaining the ground we have lost. Drupal is not only more open but also ahead of other platforms in many ways. In many cases where Drupal is not the right solution, it is very close to being the right solution and just needs a push to get there.
I have proved my effectiveness by leading the Drupal Forge project.
If I have to choose a single favorite moment, it would be the first time I installed Drupal and learned how many features I could enable without writing code.
I'm a software developer located in Los Angeles. I've contributed some modules and even a little code for D11.
It means expanding the community by reaching out to developers and users of other CMSes.
It means explaining to various audiences what Drupal can do for them. That starts with having a system that can be used by a wide range of people, not just experts.
I have three goals (expanded on below):
I'm already trying to make Drupal more usable by a wider range of people. For instance, I'm trying to make the permissions page easier to understand. I'm also the author of a wrapper for composer. That lets users run composer commands without having to learn how to use the command line. Having to deal with composer, SSH, etc is one of the main reasons why many won't use Drupal. An insecure configuration where the web server can write to code directories is not the answer.
Although my contribution to D11 is small, it's one of my favorite memories of this project.
To expand on the above, if people want to put messages on their profile pages or on the pages for projects they administer, they should feel free to do so. However, Drupal itself shouldn't take a stance on political issues. Another aspect of this is opposing censorship, brigading, in-fighting, etc etc. Well over a million people have signed up for Drupal accounts but, as issues languishing for years shows, there aren't enough active developers already. Let's work towards increasing that number.
As for the second item, I personally wouldn't be doing the developer outreach but would help recruit ambassadors/evangelists to promote Drupal as an option on various forums and so on. Representing themselves as ambassadors, they could correct misconceptions; for instance, some years ago I saw several people on a forum who thought that Drupal was intertwined with Flash.
For the third item, the U.S. government and other large organizations make extensive use of Drupal and don't contribute as much as they take in many cases. Asking them to contribute money is problematic because it would favor some over others. The best thing is to ask them to contribute in the issues queues. Those ambassadors can reach out through various channels and urge such participation.
I'm a software developer located in Los Angeles. I've contributed some modules and even a little code for D11.
It means expanding the community by reaching out to developers and users of other CMSes.
It means explaining to various audiences what Drupal can do for them. That starts with having a system that can be used by a wide range of people, not just experts.
I have three goals:
I'm already trying to make Drupal more usable by a wider range of people. For instance, I'm trying to make the permissions page easier to understand (drupal.org/node/3495351). I'm also the author of a wrapper for composer: drupal.org/project/sheephole_helper That lets users run composer commands without having to learn how to use the command line. Having to deal with composer, SSH, etc is one of the main reasons why many won't use Drupal. An insecure configuration where the web server can write to code directories is not the answer.
Although my contribution to D11 is small, it's one of my favorite memories of this project.
I have been an active member of the Drupal community for more than 25 years. In the project's earliest days I registered the drupal.org domain and handed it over to Dries Buytaert, a small but formative moment in the history of what would become this community. Over the years I have tried to build durable infrastructure for that community rather than just participate in it. I founded and organized DrupalJam fifteen times, growing it into one of the most significant Drupal camps in the world. I co-founded Stichting Drupal Nederland and helped build it into one of the richest and most successful Drupal organizations in the Netherlands, later serving as its chairman for several years. I also founded the Splash Awards, ran them ten times, and grew the format into a genuinely global event, replicated across dozens of countries and culminating in an international edition. Earlier still, I served on the board of the Drupal Association when it operated as a Belgian non-profit, where I contributed to its foundational work. Professionally, my path has taken me deeper into open source as a business, rather than away from it. I work as Sales Director, leading sales and public-affairs efforts in commercial open source infrastructure, specifically enterprise Linux (SUSE Linux Enterprise Server) and Kubernetes management (the Rancher portfolio), including engagement at the level of the European Commission. This gives me a vantage point that is rare on most non-profit boards: I understand both the cultural and technical fabric of Drupal as a community, and the commercial and policy mechanics that determine whether open source projects survive and thrive at enterprise and governmental scale.
To me, building community means giving local colour the room to thrive, while making sure the Drupal Association functions as a strong umbrella above the many local foundations and user groups around the world. The Drupal ecosystem is not one audience, it is many: end users, large organizations running Drupal at scale, agencies delivering services on top of it, and the individual contributor who quietly keeps things running and is too often overlooked. A real community has to represent all of these roles, not just the loudest or most visible ones.
In practice, building community means activating people by setting examples and celebrating success. People rarely need to be convinced that contribution matters, they need to see it modelled, and they need their work recognized when it happens. That is the philosophy behind everything I have built in this space, from DrupalJam to Stichting Drupal Nederland to the Splash Awards: create the stage, show what good looks like, and then make sure credit reaches the people who earned it.
Advocacy is ultimately about making sure success gets seen, and celebrated, by the right audiences, through the right channels. That sounds simple, but it carries real depth: every act of advocacy is really an act of translation, taking what the community already does brilliantly and making it visible and meaningful to an audience that did not build it but needs to trust it.
For me, advocacy has to operate on multiple axes simultaneously. There is the axis we know well: developers as the audience, and earned media, conference talks, blog posts, word of mouth, as the medium. That path has served Drupal for two decades and it remains genuinely good. My instinct is not to abandon it but to make it stronger and more deliberate, more professional in its marketing, more consistent in celebrating wins rather than letting them pass quietly.
But that axis alone leaves real value untapped. The other axis that deserves far more deliberate attention is policy, reaching decision-makers, public administrations, and procurement officers who will never read a Drupal.org blog post but who decide whether an entire ministry standardizes on open source. And the other dimension that needs strengthening is the medium itself: moving beyond earned media into owned and, where it makes sense, paid media, genuine commercial-grade promotion of what this project and its ecosystem can do.
This matters financially as much as culturally. There is a long tail of potential sponsors who have never been properly approached, and a largely untapped landscape of subsidies and grants, government funding, but especially foundations, that fund digital public infrastructure and open source without yet knowing Drupal is a candidate. Advocacy done well is not just visibility for its own sake. It is the mechanism that turns recognition into resources, and resources into the next decade of the project.
I am running because I want to bring my network, my knowledge, and a fresh dose of energy to strengthening the Drupal Association, and because I want to do that on behalf of the whole world, not any single country, region, or continent.
My own roots are local. DrupalJam, Stichting Drupal Nederland, the Splash Awards, these were built from the Netherlands outward. But that experience taught me something that goes well beyond the Netherlands: every strong global community is, in fact, a federation of strong local ones. I believe deeply in couleur locale, in letting every region keep its own voice, its own language, its own way of celebrating its contributors. What I want is not to flatten that diversity, but to see every colour on the map grow stronger at the same time, with the Drupal Association acting as the umbrella that makes that possible everywhere, not just where the project has historically been strongest.
That is the energy and the network I want to bring to the board. Professionally, my work in commercial open source and enterprise Linux and Kubernetes has put me in conversation with organizations and policymakers well beyond the traditional Drupal heartlands, and I want to put those relationships to work for the entire ecosystem. A board seat is, for me, the opportunity to take 25 years of building locally and use it to help every local Drupal community in the world, wherever it is, become a little stronger.
Members should vote for me because I bring a rare combination of deep knowledge, a wide network, and a long, honourable track record of actually building things that lasted.
For 25 years I have put my name behind Drupal projects and delivered. DrupalJam ran fifteen times and grew into one of the most significant Drupal camps in the world. The Splash Awards ran ten times and became a genuinely global format, replicated across dozens of countries. Stichting Drupal Nederland became one of the richest and most successful Drupal organizations in the Netherlands under my chairmanship. None of these were one-off efforts. They were built, sustained, and grown year after year, which is the actual test of whether community work matters: not whether it launches, but whether it is still standing and still growing a decade later.
That same reliability defines how I work. I do not take on responsibilities lightly, and once I commit to something, I see it through with the people around me, openly and honestly. My professional life now adds another layer of knowledge and another network entirely, commercial open source, enterprise Linux, Kubernetes, and engagement at the policy level with the European Commission, which means I bring relationships and expertise to the board that extend well beyond the traditional Drupal world, while never having left it.
In short, I have a long record of taking on responsibility for this community and delivering measurable growth, with integrity, and I want to bring that same discipline and that same network to the Drupal Association at exactly the moment it needs to grow further.
My favorite memory is the second DrupalCon ever held, which I organized in Amsterdam in 2005. We deliberately rode the wave of the O'Reilly Open Source Convention happening next door, and used that proximity to pull some of the great minds of the open source world into the same room as us, people like David Axmark of MySQL and Rasmus Lerdorf, the creator of PHP.
What makes the memory so vivid is the scale, or rather the lack of it. We were a small group, just over thirty people, sitting together trying to figure out where this thing we were building was actually going. There was no sense yet that Drupal would become what it is today. And yet many of the people in that room went on to become legends of the open source world, each carving out their own significant path. It is a memory I come back to often, because it captures something essential about open source itself: the biggest futures are usually decided in the smallest rooms, by people who have no idea yet how far it will all go.
I have been an active member of the Drupal community for more than 25 years. In the project's earliest days I registered the drupal.org domain and handed it over to Dries Buytaert, a small but formative moment in the history of what would become this community. Over the years I have tried to build durable infrastructure for that community rather than just participate in it. I founded and organized DrupalJam fifteen times, growing it into one of the most significant Drupal camps in the world. I co-founded Stichting Drupal Nederland and helped build it into one of the richest and most successful Drupal organizations in the Netherlands, later serving as its chairman for several years. I also founded the Splash Awards, ran them ten times, and grew the format into a genuinely global event, replicated across dozens of countries and culminating in an international edition. Earlier still, I served on the board of the Drupal Association when it operated as a Belgian non-profit, where I contributed to its foundational work. Professionally, my path has taken me deeper into open source as a business, rather than away from it. I work as [your exact title], leading sales and public-affairs efforts in commercial open source infrastructure, specifically enterprise Linux (SUSE Linux Enterprise Server) and Kubernetes management (the Rancher portfolio), including engagement at the level of the European Commission. This gives me a vantage point that is rare on most non-profit boards: I understand both the cultural and technical fabric of Drupal as a community, and the commercial and policy mechanics that determine whether open source projects survive and thrive at enterprise and governmental scale.
To me, building community means giving local colour the room to thrive, while making sure the Drupal Association functions as a strong umbrella above the many local foundations and user groups around the world. The Drupal ecosystem is not one audience, it is many: end users, large organizations running Drupal at scale, agencies delivering services on top of it, and the individual contributor who quietly keeps things running and is too often overlooked. A real community has to represent all of these roles, not just the loudest or most visible ones.
In practice, building community means activating people by setting examples and celebrating success. People rarely need to be convinced that contribution matters, they need to see it modelled, and they need their work recognized when it happens. That is the philosophy behind everything I have built in this space, from DrupalJam to Stichting Drupal Nederland to the Splash Awards: create the stage, show what good looks like, and then make sure credit reaches the people who earned it.
Advocacy is ultimately about making sure success gets seen, and celebrated, by the right audiences, through the right channels. That sounds simple, but it carries real depth: every act of advocacy is really an act of translation, taking what the community already does brilliantly and making it visible and meaningful to an audience that did not build it but needs to trust it.
For me, advocacy has to operate on multiple axes simultaneously. There is the axis we know well: developers as the audience, and earned media, conference talks, blog posts, word of mouth, as the medium. That path has served Drupal for two decades and it remains genuinely good. My instinct is not to abandon it but to make it stronger and more deliberate, more professional in its marketing, more consistent in celebrating wins rather than letting them pass quietly.
But that axis alone leaves real value untapped. The other axis that deserves far more deliberate attention is policy, reaching decision-makers, public administrations, and procurement officers who will never read a Drupal.org blog post but who decide whether an entire ministry standardizes on open source. And the other dimension that needs strengthening is the medium itself: moving beyond earned media into owned and, where it makes sense, paid media, genuine commercial-grade promotion of what this project and its ecosystem can do.
This matters financially as much as culturally. There is a long tail of potential sponsors who have never been properly approached, and a largely untapped landscape of subsidies and grants, government funding, but especially foundations, that fund digital public infrastructure and open source without yet knowing Drupal is a candidate. Advocacy done well is not just visibility for its own sake. It is the mechanism that turns recognition into resources, and resources into the next decade of the project.
I am running because I want to bring my network, my knowledge, and a fresh dose of energy to strengthening the Drupal Association, and because I want to do that on behalf of the whole world, not any single country, region, or continent.
My own roots are local. DrupalJam, Stichting Drupal Nederland, the Splash Awards, these were built from the Netherlands outward. But that experience taught me something that goes well beyond the Netherlands: every strong global community is, in fact, a federation of strong local ones. I believe deeply in couleur locale, in letting every region keep its own voice, its own language, its own way of celebrating its contributors. What I want is not to flatten that diversity, but to see every colour on the map grow stronger at the same time, with the Drupal Association acting as the umbrella that makes that possible everywhere, not just where the project has historically been strongest.
That is the energy and the network I want to bring to the board. Professionally, my work in commercial open source and enterprise Linux and Kubernetes has put me in conversation with organizations and policymakers well beyond the traditional Drupal heartlands, and I want to put those relationships to work for the entire ecosystem. A board seat is, for me, the opportunity to take 25 years of building locally and use it to help every local Drupal community in the world, wherever it is, become a little stronger.
Members should vote for me because I bring a rare combination of deep knowledge, a wide network, and a long, honourable track record of actually building things that lasted.
For 25 years I have put my name behind Drupal projects and delivered. DrupalJam ran fifteen times and grew into one of the most significant Drupal camps in the world. The Splash Awards ran ten times and became a genuinely global format, replicated across dozens of countries. Stichting Drupal Nederland became one of the richest and most successful Drupal organizations in the Netherlands under my chairmanship. None of these were one-off efforts. They were built, sustained, and grown year after year, which is the actual test of whether community work matters: not whether it launches, but whether it is still standing and still growing a decade later.
That same reliability defines how I work. I do not take on responsibilities lightly, and once I commit to something, I see it through with the people around me, openly and honestly. My professional life now adds another layer of knowledge and another network entirely, commercial open source, enterprise Linux, Kubernetes, and engagement at the policy level with the European Commission, which means I bring relationships and expertise to the board that extend well beyond the traditional Drupal world, while never having left it.
In short, I have a long record of taking on responsibility for this community and delivering measurable growth, with integrity, and I want to bring that same discipline and that same network to the Drupal Association at exactly the moment it needs to grow further.
My favorite memory is the second DrupalCon ever held, which I organized in Amsterdam in 2005. We deliberately rode the wave of the O'Reilly Open Source Convention happening next door, and used that proximity to pull some of the great minds of the open source world into the same room as us, people like David Axmark of MySQL and Rasmus Lerdorf, the creator of PHP.
What makes the memory so vivid is the scale, or rather the lack of it. We were a small group, just over thirty people, sitting together trying to figure out where this thing we were building was actually going. There was no sense yet that Drupal would become what it is today. And yet many of the people in that room went on to become legends of the open source world, each carving out their own significant path. It is a memory I come back to often, because it captures something essential about open source itself: the biggest futures are usually decided in the smallest rooms, by people who have no idea yet how far it will all go.
A co-founder of FreelyGive Ltd. We are a company that has specialised in Native Drupal CRM but I've become obsessed with AI for the last few years. I've been heavily involved in spearheading the AI module and then the AI Initiative. We've built a team of people committed to radically pushing forwards both AI and Opensource AI. We believe strongly that Drupal is the best CMS for your agents to use and that a healthy truly opensource community around your AI applications is essential for freedom and sovereignty. I've been working outside the DA to do what I can to explore ways of the DA finding alternative and sustainable funding as I think it is essential to the long term success of Drupal not being owned by a single company like many open source software. Outside of Drupal I'm a somewhat recent father and avid video gamer.
Building community is about creating consensus amongst many different stakeholders so that everyone involves can feel that we are in win win win situations where our interests are aligned. I have spent a lot of time at events but also speaking to people and agencies on an individual basis to get to know the people, what they are passionate about and how they struggle in the Drupal community.
FreelyGive is in a unique situation given its size that we don't need to expand forever and grow wide. We want to grow tall and focus on the important issues we are best to solve and so we have found ourselves able to support, not compete with the Drupal ecosystem.
As a result building community and helping where we can is very ideologically important to us but also important for the bottom line.
We think building community means providing places for as many people as possible to achieve some kind of self actualisation, it needs to be fun to work together, rewarding but also financially sustainable.
I take this approach by creating maps of everyone, their goals and figuring out paths where working together is beneficial for everyone.
I've been involved in the Drupal community since 2011 and became radicalised around online communities and Opensource since a teenager.
I've loved the architecture of Drupal both the concept of the site builder (I'm not a programmer) but the unique truly opensource community of modules that you almost never see. Truly open, and interoperable with some level of security and maintenance guarantees compared to just throwing things on GitHub.
I love it! From the beginning with AI, we knew we could try and make FreelyGive single AI agency but felt that for Drupal to survive everyone will need to become an AI expert and every agency will need to have the expertise. So we set about focusing on leveling up all of Drupal.
I now spend as much time as possible getting out of the Drupal community and advocating for it. I've seen a real shift in the energy for Drupal and a renewed excitement across the community. I want to take that further!
I have been advocating for Drupal and specifically the Drupal Association for a while now. I've worked on creating a few new potential business models and helped with any lobbying and infrastructure or proof of concepts where I can. I have also been working on finding partners who can directly fund Drupal and the Drupal Association and some of those might be coming to fruition with real ongoing revenue for the DA. I think it is essential the DA is able to bring in funds sustainably to maintain what makes Drupal unique otherwise it may fall into the sea of projects across github. The Drupal AI Initiatives organisation has to some degree been a place to explore potential ideas that could scale into the Drupal Association.
I have been doing this already and whether or not I am on the board I can continue this mission with existing board members, staff in the DA and stakeholders across the community.
However I believe I may be able to help further by being part of the board itself.
AI isn't just about AI features itself. The world is fundamentally changing in many ways even if not directly touched by a specific LLM model. I want to help Drupal and the DA survive, reform where needed and thrive in this new world. I'll be here to help Drupal and the DA regardless and it's up to the community and board for whether or not people feel like I can help further by being directly part of it!
I bring a fresh perspective to the board as someone who is relatively new to the internal workings of Drupal and the Drupal association whilst still bringing a deep understanding of Drupal and it's community as I started my business half way through university spending a good 3 hours a day reading every critical issue for Drupal 7 and every new comment!
I run and own an agency and so have a good deal of autonomy and personal understanding for the issues many agencies will face whilst also having the autonomy to help where I need to without needing to answer to anyone specifically apart from my co-owners who are all very committed to Drupal.
I have spoken about Drupal and AI a great deal and I'm continuing to work on thought leadership, podcasts , hackathons etc.
I'm also out there in the community getting to know many of you!
I have a good deal of recent board experience via the AI Initiative but to some degree I am a rookie compared to others on the board and so I may be able to offer a fresh perspective and learn.
So why should members vote for me? Well I hope many members who have interacted with me in the community can answer that question and see how much I have been trying to help people where they are at and how much passion I have for this community to survive.
To some degree... Discovering Views! It changed everything! (and then more recently meeting earl miles! So many people in this community are heroes of mine from when I started as a teenager) Seeing the reaction at Drupalcon Barcelona to our Drupal CMS AI agents was pretty amazing too!
A co-founder of FreelyGive Ltd. We are a company that has specialised in Native Drupal CRM but I've become obsessed with AI for the last few years. I've been heavily involved in spearheading the AI module and then the AI Initiative. We've built a team of people committed to radically pushing forwards both AI and Opensource AI. We believe strongly that Drupal is the best CMS for your agents to use and that a healthy truly opensource community around your AI applications is essential for freedom and sovereignty. I've been working outside the DA to do what I can to explore ways of the DA finding alternative and sustainable funding as I think it is essential to the long term success of Drupal not being owned by a single company like many open source software. Outside of Drupal I'm a somewhat recent father and avid video gamer.
Building community is about creating consensus amongst many different stakeholders so that everyone involves can feel that we are in win win win situations where our interests are aligned. I have spent a lot of time at events but also speaking to people and agencies on an individual basis to get to know the people, what they are passionate about and how they struggle in the Drupal community.
FreelyGive is in a unique situation given its size that we don't need to expand forever and grow wide. We want to grow tall and focus on the important issues we are best to solve and so we have found ourselves able to support, not compete with the Drupal ecosystem.
As a result building community and helping where we can is very ideologically important to us but also important for the bottom line.
We think building community means providing places for as many people as possible to achieve some kind of self actualisation, it needs to be fun to work together, rewarding but also financially sustainable.
I take this approach by creating maps of everyone, their goals and figuring out paths where working together is beneficial for everyone.
I've been involved in the Drupal community since 2011 and became radicalised around online communities and Opensource since a teenager.
I've loved the architecture of Drupal both the concept of the site builder (I'm not a programmer) but the unique truly opensource community of modules that you almost never see. Truly open, and interoperable with some level of security and maintenance guarantees compared to just throwing things on GitHub.
I love it! From the beginning with AI, we knew we could try and make FreelyGive single AI agency but felt that for Drupal to survive everyone will need to become an AI expert and every agency will need to have the expertise. So we set about focusing on leveling up all of Drupal.
I now spend as much time as possible getting out of the Drupal community and advocating for it. I've seen a real shift in the energy for Drupal and a renewed excitement across the community. I want to take that further!
I have been advocating for Drupal and specifically the Drupal Association for a while now. I've worked on creating a few new potential business models and helped with any lobbying and infrastructure or proof of concepts where I can. I have also been working on finding partners who can directly fund Drupal and the Drupal Association and some of those might be coming to fruition with real ongoing revenue for the DA. I think it is essential the DA is able to bring in funds sustainably to maintain what makes Drupal unique otherwise it may fall into the sea of projects across github. The Drupal AI Initiatives organisation has to some degree been a place to explore potential ideas that could scale into the Drupal Association.
I have been doing this already and whether or not I am on the board I can continue this mission with existing board members, staff in the DA and stakeholders across the community.
However I believe I may be able to help further by being part of the board itself.
AI isn't just about AI features itself. The world is fundamentally changing in many ways even if not directly touched by a specific LLM model. I want to help Drupal and the DA survive, reform where needed and thrive in this new world. I'll be here to help Drupal and the DA regardless and it's up to the community and board for whether or not people feel like I can help further by being directly part of it!
I bring a fresh perspective to the board as someone who is relatively new to the internal workings of Drupal and the Drupal association whilst still bringing a deep understanding of Drupal and it's community as I started my business half way through university spending a good 3 hours a day reading every critical issue for Drupal 7 and every new comment!
I run and own an agency and so have a good deal of autonomy and personal understanding for the issues many agencies will face whilst also having the autonomy to help where I need to without needing to answer to anyone specifically apart from my co-owners who are all very committed to Drupal.
I have spoken about Drupal and AI a great deal and I'm continuing to work on thought leadership, podcasts , hackathons etc.
I'm also out there in the community getting to know many of you!
I have a good deal of recent board experience via the AI Initiative but to some degree I am a rookie compared to others on the board and so I may be able to offer a fresh perspective and learn.
So why should members vote for me? Well I hope many members who have interacted with me in the community can answer that question and see how much I have been trying to help people where they are at and how much passion I have for this community to survive.
To some degree... Discovering Views! It changed everything! (and then more recently meeting earl miles! So many people in this community are heroes of mine from when I started as a teenager) Seeing the reaction at Drupalcon Barcelona to our Drupal CMS AI agents was pretty amazing too!
I currently lead Drupal as an open-source product at Acquia, am on the Drupal AI Initiative team and have been a member of the Drupal community for 20+ years.
To me, Drupal is the community. Drupal is what it is because of two decades of community conversations, work, ideas, and collaboration pulling us towards well-though and proven capabilities based on real-world needs. Without the community none of what we do would be possible.
It's important that open, collaborative, community backed software is what the world chooses when they need a Content Management System. My goal is that when that need arises, Drupal is the #1 choice.
I value the Drupal community and the opportunities Drupal has given many of us over the years. As AI rapidly changes the nature of software and open-source itself it's important to me that Drupal retains it's identity, technical foundations, and community.
I've worked with Drupal for 20+ years, from small hobby sites to some of the largest digital properties in the world. As Technical Director of Acquia's Professional Services group, I worked alongside some of the top minds in the community. More recently, as product owner for Drupal as an open-source product at Acquia and a member of the Drupal AI Initiative leadership team, I've focused on ensuring Drupal is well positioned for the future.
When I started building with Drupal I had very little "real" programming knowledge, but the community was open, available, and willing to help. I owe much of my career trajectory and personal development to Drupal and the community.
I currently lead Drupal as an open-source product at Acquia, am on the Drupal AI Initiative team and have been a member of the Drupal community for 20+ years.
To me, Drupal is the community. Drupal is what it is because of two decades of community conversations, work, ideas, and collaboration pulling us towards well-though and proven capabilities based on real-world needs. Without the community none of what we do would be possible.
It's important that open, collaborative, community backed software is what the world chooses when they need a Content Management System. My goal is that when that need arises, Drupal is the #1 choice.
I value the Drupal community and the opportunities Drupal has given many of us over the years. As AI rapidly changes the nature of software and open-source itself it's important to me that Drupal retains it's identity, technical foundations, and community.
I've worked with Drupal for 20+ years, from small hobby sites to some of the largest digital properties in the world. As Technical Director of Acquia's Professional Services group, I worked alongside some of the top minds in the community. More recently, as product owner for Drupal as an open-source product at Acquia and a member of the Drupal AI Initiative leadership team, I've focused on ensuring Drupal is well positioned for the future.
When I started building with Drupal I had very little "real" programming knowledge, but the community was open, available, and willing to help. I owe much of my career trajectory and personal development to Drupal and the community.
ddev share lets you share your running local project with anybody in the world. It can be used for collaboration or demonstration to clients. All the details are in the DDEV docs.
TYPO3 projects sometimes provide a special challenge for ddev share if they have the full URL specified in the config/sites/*/config.yaml base, like base: https://typo3demo.ddev.site. When you ddev share and get an arbitrary URL from Cloudflared or ngrok, TYPO3 refuses to show the site because it's not the specified URL.
This isn't a problem at all if the base element doesn't include the URL. For example, with base: /camino on a project like the DDEV TYPO3 quickstart, everything works fine out of the box, there's nothing to do. The share URL with /camino will work fine.
But we can solve this problem with DDEV's pre-share hooks, see below
ddev share without URL in baseddev share with URLpre-share hookspre-share and post-share HooksDDEV exports the tunnel URL as $DDEV_SHARE_URL when you run ddev share. You can use pre-share and post-share hooks to temporarily disable the base: setting for the duration of the share session, and restore it afterward:
# .ddev/config.yaml
hooks:
pre-share:
- exec: |
for f in config/sites/*/config.yaml; do
cp "$f" "$f.pre-share-backup"
newbase=$(yq '.base' "$f" | sed -E 's#^https?://[^/]+##')
[ -z "$newbase" ] && newbase="/"
yq -i ".base = \"$newbase\"" "$f"
done
typo3 cache:flush
post-share:
- exec: |
for f in config/sites/*/config.yaml.pre-share-backup; do
mv "$f" "${f%.pre-share-backup}"
done
typo3 cache:flush
This strategy checks your config.yaml, temporarily updates the base to use only the required / or other URL, and then does a typo3 cache:flush.
At the end of the share, the original config.yaml is restored by the post-share hook.
Of course your project should be under Git source control in case anything should go wrong, or you never exit the share, etc.
DDEV already automatically adds the trustedHostsPattern to the additional.php which is used only running with DDEV. This allows the project to work on a shared URL.
return [
# ...
'SYS' => [
'trustedHostsPattern' => '.*.*',
'devIPmask' => '*',
'displayErrors' => 1,
],
];
rfay/typo3demoA pre-built example project based on the TYPO3 docs and DDEV quickstart is at rfay/typo3demo, and has post-start hooks for composer: install and pre-share hooks as described here.
For background on the ddev share provider system, including using either ngrok or the free Cloudflare Tunnel option and how $DDEV_SHARE_URL hooks work for other CMSs, see the announcement blog and the docs on ddev share.
If you have questions, reach out in any of the support channels.
Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.
This article was edited and refined with assistance from Claude Code.
read moreWe've published an updated product strategy for Drupal CMS. Version 2.0 replaces the original Drupal Starshot strategy from August 2024, and it reflects where we are after nearly two years of building.
The updated strategy largely documents what we're already doing, and why, and makes some important clarifications.
The initial strategy framed content creators and marketers as the primary target audience. That made sense as a signal about our ambitions: Drupal already has a reputation for being developer-friendly, so we wanted to emphasize the focus on end users.
In practice, though, it created some confusion. Marketers are the end users of the sites built with Drupal CMS, but they're not the ones installing it, configuring it, or (in most cases) choosing it. That decision usually belongs to agencies and professional developers.
So the updated strategy is clearer: Content creators and marketers remain the target person for the product as end users, and the primary audience for the builder experience is agencies and professional developers. We can only reach marketers if developers can succeed with Drupal.
Rather than representing a change in what we're focused on, this now more accurately captures it.
The strategic frame has shifted to "making agencies and developers successful faster." The end goal of delivering great experiences for content teams is still central to the strategy, but we are explicit about doing that through agencies and developers.
A few other notable updates:
AI is now framed as infrastructure, rather than a feature. The original strategy positioned AI as one of several ways to win. Version 2.0 is more direct: every workflow in Drupal CMS should be operable by an AI agent. The goal is to be able to ship new AI-enabled workflows in days, not months.
Integrated hosting providers are now explicitly part of the strategy. These platforms are becoming real distribution channels for Drupal CMS, and the strategy names them as a priority. Making Drupal CMS excellent to provision and host is a prerequisite for those partnerships.
Vibe coding platforms are now named as a positioning opportunity. We're not competing with tools like Lovable or Bolt for prototyping. But we are positioning Drupal CMS as where those projects land when they need real content governance, multi-contributor workflows, and long-term maintainability.
The timeline has changed. Version 1.0 set a target of June 2027. Version 2.0 extends that to June 2028, acknowledging that the scope has grown and the strategy is more comprehensive.
We're still aiming to expand in the mid-market, with projects with total budgets in the $30,000–$120,000 USD range, and we're still explicitly not competing with entry-level website builders. We are also calling out that we will continue to maintain our leadership in the enterprise market.
And, of course, the differentiators against proprietary CMS solutions are the same: open source, no vendor lock-in, digital sovereignty.
The updated strategy is published on Drupal.org.
If you have questions or feedback on the direction, find us in #drupal-cms-development on Drupal Slack.
