Yesterday I wrote about how Open Source infrastructure across many ecosystems is fragile and underfunded.

Drupal is no exception.

Like most Open Source projects, Drupal runs on infrastructure that millions of people depend on but very few people directly pay for.

Drupal's infrastructure costs roughly $3 million per year, including servers, bandwidth, CDNs, software, and staff.

Funding comes from a mix of donated infrastructure from AWS and the OSU Open Source Lab, corporate memberships through our Drupal Certified Partner program, in‑kind contribution from Tag1, and revenue from DrupalCon, donations, and sponsorship on Drupal.org.

Last year, Drupal Association board member Tiffany Farriss and CTO Tim Lehnen analyzed the project's infrastructure costs. Their estimate: infrastructure for Drupal 8+ sites costs about $10 per active website per year.

But the Drupal Association spends only about $7.50 per site per year. About $3 comes from DrupalCon and the Certified Partner program. The remaining $4.50 comes from in-kind support: donated hosting, Tag1's infrastructure partnership, and volunteer contributions. That is all we have to spend.

The missing $2.50 per site shows up as technical debt: certain upgrades get deferred, legacy systems persist longer than they should, and the community sometimes wonders why infrastructure progress feels slow.

Even the $7.50 per site we currently fund is fragile. DrupalCon revenue depends on event attendance. Advertising depends on traffic. Tag1's in-kind contribution depends on one company's continued generosity. Our donated infrastructure from AWS and OSU could disappear at any time. At that point, the funding gap grows, more infrastructure work gets deferred, and things could start breaking.

Before talking about new funding models, it is worth asking whether the Drupal Association could reduce its infrastructure costs. Ten dollars per site per year may sound like a lot. Should we operate all of this infrastructure ourselves, or rely more on hosted platforms like GitHub or GitLab? Are parts of our infrastructure more complex than they need to be?

These are the right questions to ask. I believe we need to work both sides of the ledger: take a hard look at what we spend and build a funding model that depends less on goodwill. In practice, infrastructure decisions rarely optimize for everything at once. They involve tradeoffs between cost, speed, flexibility, and control.

Corporate patronage is worth considering. A single well-resourced sponsor could fund Drupal's infrastructure in a way community fundraising cannot, and if the choice were between a patron and a crisis, a patron wins. It's fast, requires no technical changes, and doesn't touch the social contract with site owners.

But patronage trades one fragility for another. Instead of depending on event attendance or AWS cloud credits, you depend on one company's continued generosity and strategic alignment with the project. If their priorities shift, we're back where we started. A patron funding infrastructure at this scale would also expect meaningful benefits. That usually means greater visibility and some level of control over Drupal.org.

Most infrastructure systems connect usage to funding. Cloud platforms charge for compute. Roads are funded by taxes paid by the people who drive them. Drupal's infrastructure has neither mechanism: millions of sites depend on Drupal.org services, but the cost of operating those services is disconnected from the people who rely on them.

A funding model tied to usage avoids some of the issues with corporate patronage, but comes with its own trade-off. Open Source culture is built on anonymous access. You can download any package, no questions asked, no account required. Any usage-based model has to break that norm. The simplest version would probably require a Drupal.org API key to download packages or receive automatic update notifications.

Requiring an API key is standard practice for any commercial API, but in Open Source it feels different. Requiring site owners to identify themselves to Drupal.org is a cultural shift, even if the key itself is free forever. Any such mechanism requires changes to Drupal Core, which could take years to reach the installed base. If we go down this route, we can't wait for a funding crisis to begin this work. By the time a real crisis arrives, we would still be years away from a solution.

I don't have a specific mechanism to propose yet. But we should start this conversation now, while we have the time and stability to get it right. The alternative is making the same decisions later, under more pressure, with fewer options and less trust to spend.

Thanks to Tiffany Farriss, Tim Lehnen, Gábor Hojtsy and Lauri Timmanee for reviewing my draft.

10 Mar 2026 10:30pm GMT

DrupalCamp NJ 2026 will take place from 12 March 2026 to 14 March 2026 at Princeton University in Princeton, New Jersey, bringing together Drupal developers, site builders, and community members for three days of training, sessions, and collaboration. Among the scheduled presentations is "Governance You Can See: Embedding Content Rules Directly Into Drupal," a session by Nathan Wallace that explores how governance guidance-often stored in documents and policies-can be embedded directly within Drupal's publishing experience to help teams maintain content quality, accountability, and editorial clarity.

10 Mar 2026 3:00pm GMT

10 Mar 2026 1:33pm GMT

The Nightmare of Permissions and OAuth Scopes in Drupal

Drupal's role-based access control is one of its strengths. Permissions and roles are well-understood, and the system is mature. But the moment you step outside the standard cookie-based session - say, into OAuth with the authorization code flow - you hit a wall that the core permission model never anticipated.

Super-permissions and their hidden assumptions

Drupal treats administer nodes and bypass node access as super-permissions. If a user has either, NodeAccessControlHandler assumes they can perform any operation on any content type and skips the granular checks entirely. bypass node access is actually more powerful than administer nodes - a quirk of legacy cruft going back to early Drupal versions.

10 Mar 2026 1:00pm GMT

UUIDv5 with config name as input. Storage decorators that intercept every write path. A hashed-table edge case that almost caused data loss. Here is how the module works.

10 Mar 2026 10:55am GMT

10 Mar 2026 10:01am GMT

Can one open-source CRM manage all your donors and donations in one place? If you're working for a nonprofit, you must read this blog to find out how CiviCRM can manage contacts and fundraising efficiently for you.

10 Mar 2026 7:47am GMT

A fresh breeze of innovation is set to sweep through Chicago this spring. As March 23-26 draws near, the Windy City is gearing up to host DrupalCon 2026, the world's largest Drupal gathering.

10 Mar 2026 12:48am GMT

09 Mar 2026 8:11pm GMT

Open Source software is free to download. But the infrastructure that makes it usable is not.

When developers install or update dependencies through npm, Composer, pip, or Cargo, those tools rely on package registries that host and distribute millions of software packages. When maintainers collaborate, they depend on hosted services: Git repositories, CI pipelines, and other tools to build, test, and release software.

Most of this infrastructure is invisible to end users, and almost no one thinks about what it costs to run.

But it is not free. Someone has to operate the servers, pay for bandwidth, respond to support questions, patch security issues, and keep everything reliable.

Much of the modern software ecosystem depends on these services working reliably. And yet the organizations operating them are almost always scrambling to fund them.

A patchwork of fragile arrangements

Every large Open Source project has found some way to keep its infrastructure running. Usually that means a mix of donated services, sponsorships, fundraising, cross-subsidy, or patronage from a single company.

The table below highlights the primary funding mechanisms various Open Source projects depend on, even though most projects combine several.

The mix differs across ecosystems, and some rely on several mechanisms at once. But one thing stands out: none of these approaches tie funding directly to how much the infrastructure is used.

PyPI, the Python Package Index, illustrates the sponsorship model. It handles billions of downloads a day on infrastructure donated by Fastly, AWS, and Google Cloud. The Python Software Foundation described this arrangement's fragility in a post last October: if a single sponsor decides not to renew, it would cost them tens of thousands of dollars a month to replace the lost infrastructure.

Packagist, the main PHP package repository, follows a different approach. It is run by a private company that also sells a commercial product called Private Packagist. Revenue from the paid product subsidizes the free public registry. It's one of the more sustainable models out there, though it means a public good depends on one company's continued success.

npm tried to operate as an independent company, ran into serious financial trouble, and was eventually acquired by GitHub in 2020. The end result is that critical JavaScript infrastructure is now owned by Microsoft.

WordPress.org runs on a different version of the same dynamic: corporate patronage. Automattic, by far the ecosystem's largest commercial beneficiary, subsidizes most of the infrastructure. It works, but it also means that whoever funds the infrastructure controls it.

The FAIR project, a federated package manager backed by the Linux Foundation, was designed to give the WordPress ecosystem an independent alternative. The software works but its organizers recently stepped back after failing to secure long-term funding commitments.

RubyGems took the community fundraising route, launching a program last year asking businesses for $2,500 to $5,000 annually, with about 110 supporters needed to cover the registry's operations.

Drupal, the Open Source CMS I help lead, depends on the Drupal Association to run much of the infrastructure behind the project: Composer endpoints, GitLab repositories, CI pipelines, automatic update notifications, and more. Running all of this costs roughly $3 million a year. Funding comes from a mix of donated infrastructure, community funding, DrupalCon revenue, and sponsorship.

When the economics break, the consequences become visible. In February 2026, GNOME began redirecting Git traffic from its own GitLab to GitHub mirrors to reduce bandwidth costs. As a result, GitHub and its owner Microsoft now absorb some of GNOME's bandwidth cost.

Taken together, these examples point to the same underlying problem. Most Open Source infrastructure does not have a real business model. It survives through donations, corporate sponsorship, and community fundraising, rather than revenue tied to the value it delivers.

From steward to service provider

One direction that makes sense to me is a simple value exchange: keep core infrastructure free for individuals and small projects, while organizations using it at scale help pay for what they consume. Not as a donation, but as payment for the infrastructure their software depends on.

Some people will instinctively resist the idea of charging for the infrastructure behind an Open Source project. That reaction may feel familiar to anyone who remembers the early debates about paid contributors. At the time, many feared corporate money would drive volunteers away. In practice, the opposite happened. Projects grew, contributor bases expanded, and paid engineers became some of their most active contributors.

That does not mean every new funding idea is a good one. But instinctive discomfort alone is not a reason to reject it.

In Open Source, what looks like fairness often is not. Free for everyone sounds equitable, but the cost does not disappear. It is absorbed by those who can least afford it, while the organizations that benefit most often pay the least. When a Fortune 500 company consumes Open Source infrastructure for free, that is not a neutral outcome. It is a subsidy flowing in the wrong direction.

If the problem is that costs are disconnected from usage, the obvious place to start is linking them. Exactly how that would work in practice is a separate design question, and the answer will likely differ from one Open Source project to another. One possible approach is usage-based fees, tiered by download volume or API consumption. Questions about measurement, thresholds, and enforcement would need careful community discussion.

Governance is downstream of funding

If infrastructure funding models need to change, the obvious question is who decides. In Open Source, questions like this ultimately belong to the community.

But communities do not decide these things in a vacuum. In practice, governance tends to follow funding.

Discussions about Open Source infrastructure often focus on governance: who should control it and who gets to make the decisions. In reality, those questions are often settled by something simpler: who pays for it.

FAIR is a recent example. The project didn't fail because federation was the wrong idea. It failed because nobody built a business case compelling enough to fund it as an alternative.

When one organization pays for the infrastructure, it ultimately controls it. When a broader set of stakeholders funds it, governance broadens with it.

That is why Open Source infrastructure needs more than better fundraising. It needs a business model that connects the cost of operating shared infrastructure to the organizations that rely on it most.

Infrastructure that entire ecosystems depend on cannot rely indefinitely on goodwill alone. It deserves a business model.

Solving the funding problem is a prerequisite to solving the governance problem.

Thanks to Tiffany Farriss, Tim Lehnen, Gábor Hojtsy and Lauri Timmanee for reviewing my draft.

09 Mar 2026 6:36pm GMT

09 Mar 2026 6:00pm GMT

Across the Drupal ecosystem, much of the work that keeps the project moving forward happens through sustained community effort. Developers maintain modules and review patches, accessibility specialists improve inclusive design practices, documentation writers clarify complex workflows, and organisers run DrupalCamps, DrupalCons, and local meetups that bring contributors together.

Women across the Drupal community play visible roles in many of these areas. They lead accessibility initiatives, maintain projects, organise community events, and guide product and platform discussions that influence how Drupal evolves. In recent years, these contributions have shaped areas ranging from documentation and mentoring to platform initiatives such as Drupal CMS and accessibility-driven improvements across the ecosystem.

International Women's Day offers a moment to acknowledge that work without separating it from the technical core of the project. The stories in this week's issue highlight the broader ecosystem in motion-from new developer tools and experimental modules to DrupalCon Chicago announcements and community initiatives reported over the past week.

With that context, here are the major stories from last week.

EVENT

• Mike Herchel Previews DrupalCon Chicago Sessions on Theming, Contributions, and Drupal CMS
• Managing Multisite Configuration with Config Split at DrupalCon Chicago 2026
• Drupal Community Summit Scheduled at DrupalCon Chicago 2026
• Drupal 25th Anniversary Gala Set for 24 March in Chicago
• DrupalSouth 2026 Splash Awards Opens Submissions for Wellington Event
• Stanford WebCamp 2026 Opens Call for Session Proposals
• Decoupled Days 2026 Scheduled for 6-7 August in Montréal

ACCESSIBILITY

• AmyJune Hineline Releases Accessibility Microlearning for Open Source Contributors

DRUPAL COMMUNITY

• Fundraiser Launched to Support "Drupal in a Day" Workshop at DrupalCon Chicago

DISCOVER DRUPAL

• Ivan Zugec Builds Node Tool to Auto-Clip Drupal Live Streams Using Remotion and FFmpeg
• New AEO Module Targets AI Search Optimization in Drupal
• A Practical Workflow for Tracking Drupal Core Changes
• Shortlink Manager 1.1 Beta Adds Analytics, QR Codes, and Automated Health Checks
• Form Layout Module Introduced for Drupal Edit Form Organisation
• Mark Conroy Publishes Experimental WebMCP Module for Drupal User Forms

We acknowledge that there are more stories to share. However, due to selection constraints, we must pause further exploration for now. To get timely updates, follow us on LinkedIn, Twitter, Bluesky, and Facebook. You can also join us on Drupal Slack at #thedroptimes.

Thank you.

Kazima Abbas
Sub-editor
The DropTimes

09 Mar 2026 4:42pm GMT

Staging-server bottlenecks often slow releases, compress QA into the final days of a sprint, and leave stakeholders reviewing work too late to give meaningful feedback. In this DrupalCon North America 2026 session, Jasmyne Epps of Digital Services Georgia and James Sansbury of Tugboat explain how the State of Georgia redesigned QA and UAT for GovHub by moving testing and stakeholder review directly into pull requests. The result is a workflow that helps teams catch issues earlier, collaborate continuously, and scale delivery across more than 80 state agency websites.

09 Mar 2026 3:31pm GMT

Dreaming about Claude Code

I lost sleep last night, dreaming about Claude Code. The night before, I was working too late and too hard on a coding problem, and I ended up dreaming about it and circling the solution. I was ruminating on how Claude Code fits into my development workflow. In my dream, I kept circling back to the question of how to code Drupal using AI.

I want to emphasize that I had a dream, not a nightmare. The dream was triggered by spending an entire day clauding at Symfony, more generally using Claude Code to improve my understanding of Symfony and how it is used in Drupal.

Improving my understanding of Symfony within Drupal

First and foremost, I see AI as a powerful tool, not a replacement for developers. AI is a disruptor affecting both junior and senior developers, requiring them to learn to use AI to develop and maintain software applications. An AI tidal wave is underway, and we need to get ahead of it rather than ignore it.

My long-term goal is to bring AI into my Drupal development workflow, yet I like circling around big challenges and seeking a learning task that is somewhat Drupal-adjacent. There are two Symfony-related issues/tasks on Drupal.org that I want to understand and maybe help resolve.

The first one is really simple. The latest version of Drupal CMS and, in turn, the AI Agents module can't generate content types. i.e., "create an Event content type" because the AI agent throws a passing generic $value parameter triggers an error. This is a minor bug, but I honestly don't understand Drupal's integration with Symfony's validation component well enough to contribute a patch.

A much larger second discussion I have been following for several years is the addition of integration...Read More

09 Mar 2026 2:32pm GMT

The weekend of 28th February to the 1st March saw the second DrupalCamp England event with around 100 people attending the University of Salford, not far from Manchester, for the two day event.

I had submitted a talk and the camp organisers had accepted it and also decided to make me a featured speaker, which was an incredible honour. As such I was part of the communications being sent out in the weeks before the event.

Since this is more or less a local event for me I decided to travel in on both days rather than get a hotel or anything. The rain and wind of the previous week had abated and the Saturday morning saw some of the warmest (and driest) weather we had seen in the north west for a few months.

Saturday

The keynote on Saturday morning was The Augmented Future: Winning with AI with Dr. Phininder Balaghan, founder of Traversally. This was an look through the current state of AI, which Dr. Balaghan said changes every time he gives the talk.

Most companies these days have adopted an agile methodology, which has taken about 20 years to become widespread. Since the introduction of LLM AI systems a few years ago we have seen massive adoption across all industries.

Dr. Balaghan joked that we have reached the age of AI-gile, the new agile methodology.

At the moment we are using a collection of LLM agents that work together in a so-called "agentic" system to provide a coherent service. The next true advancement in AI systems will be thinking AI systems that are able to properly think about the input and respond. I think we are quite a long way from that yet and no amount of processing power or RAM is going to solve the problem that LLMs are just statistical word engines.

Read more

08 Mar 2026 6:57pm GMT

My experiment in bringing Drupal Module Upgrader back from the dead in less than 24 hours

Gábor Hojtsy Sat, 03/07/2026 - 09:13

07 Mar 2026 7:13am GMT