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 Open Source 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 is simple: no one is required to contribute. The code was shared freely, without a promise of care or an expectation of return.

For stewarded Open Source, the answer is not so simple. The license may still say the software is provided as-is, used at your own risk. Legally, no one has to contribute back. But there is also an entire layer of stewardship on top of the code: security, release management, infrastructure, governance, marketing, long-term maintenance, and more. People and organizations take on responsibilities well beyond what the license requires so the software can be safer to adopt, easier to upgrade, and dependable in production.

For projects like Drupal, that layer costs millions of dollars a year, and someone pays for every piece of it. I explored this more concretely in Open Source infrastructure deserves a business model and what it costs to run Drupal's infrastructure.

When we call everything simply "Open Source", we hide the difference between code that was simply shared and infrastructure that is being cared for and de-risked. Better language will not solve the funding problem by itself, but it makes the responsibility visible. More honest conversations start there.

Some people can give their nights and weekends to learning a codebase, clearing the issue queue, or reviewing patches. Some are paid to do it on the clock. A lot of people can't do either. Their hours go to a second job, caring for family, or simply making it through the week.

That doesn't make these people less talented. It means they have less opportunity.

AI changes the math. A contributor might have the skill to fix a bug, but not the time to learn an unfamiliar codebase. AI can help them understand the codebase faster.

On paper, that should be great news for Open Source. In practice, AI will only help if access and skill become shared, not private advantages.

AI access is not equal. The most capable models and coding agents cost real money, and using them well takes real skill. I pay hundreds of dollars a month for these tools and have spent countless hours learning when to trust them, when to doubt them, and how to turn their output into useful work. Many contributors do not have that money or that time.

We learned once that "anyone can contribute" is not the same as "everyone has the same opportunity to contribute". AI can repeat that mistake in a new form.

Powerful technologies rarely share their benefits evenly at first. Electricity did not create equal opportunity the moment it was invented. It only changed lives broadly when people built the infrastructure to make it widely available. The internet followed a similar path: it started with privileged access, then became useful to millions more people as access became cheaper and easier.

AI is no different. If we want AI to reduce privilege in Open Source instead of reinforcing it, Open Source projects can do their part by helping close two gaps.

The first is cost. Contributors should be able to do meaningful work without paying for the most expensive AI tools. As lower-cost models, including open-weight models, improve, Open Source projects should make them practical for contribution work.

The second is skill. Knowing how to use AI well should become shared knowledge within Open Source projects so more people can learn faster and make better contributions.

Contributing with AI should come down to talent, not to who can afford the best tools or who has the time to learn them.

Open Source already moves many things from private advantage to shared infrastructure: code, documentation, best practices, and more. We make all of these public so more people can participate and build on each other's work. The ability to use AI well for contribution should move in the same direction.

Publicly sharing AI best practices is an important start, but not enough. If we want AI to reduce the privilege of free time, those practices need to be embedded in the project and the contributor experience, not live on the side. If potential contributors have to hunt down the tools, prompts, skill files, and know-how themselves, the people short on time are the first to give up, even though they stand to benefit the most.

But more contribution is not automatically progress. As I wrote in AI creates asymmetric pressure on Open Source, AI can make it cheaper to contribute without making it cheaper to review.

The test is whether AI helps more people move from issue to tested patch while making the result easier for maintainers to trust and merge.

If we do this well, AI can make contribution less dependent on free time. If we do it poorly, it will widen the gap for contributors and increase the burden on maintainers. If we ignore AI or discourage its use, it will still show up in contributions, just without shared norms or shared accountability.

In 2019, I argued that Open Source communities should create opportunity by paying contributors. I still believe that. Paying contributors gives people time. But AI gives us another way to reduce the privilege of free time: it helps people do more with the time they have.

I want Drupal to help explore this in practice: not because we have all the answers, but because this is the kind of problem Open Source should help solve.

Now governments around the world are pushing for digital sovereignty: control over critical technology they depend on.

Open Source began as a volunteer movement, and commercialization helped it scale. Now digital sovereignty could accelerate Open Source's third and final chapter: governments helping to fund the Open Source software they depend on, just as they fund roads, schools, and defense.

It could be a rare win-win: Open Source becomes more sustainable, while governments and society get the resilience and independence they are looking for.

That is what makes this moment feel so important, and why I've been writing about digital sovereignty so much lately.

I got into all of this on the latest episode of EU Scream, hosted by James Kanter, who covered the EU for the International Herald Tribune and The New York Times for twelve years.

James also pushed the conversation further, into the broader public debate about technology, the risks ahead, and why I believe Open Source can help keep some of the more dystopian scenarios at bay.

Much of what we talked about builds on arguments I've made before, in The Software Sovereignty Scale and The Sovereignty Prerequisite. But if long blog posts aren't your thing, this conversation covers the same ideas and adds a few new ones.

Listen to the episode.

Earlier this year, the Commission ran a public consultation, and I contributed two articles to it: the Software Sovereignty Scale and a follow-up, The Sovereignty Prerequisite.

So when the package was published today, I skimmed it right away. I was pleasantly surprised to find one of my articles cited in a footnote on page 18!

I won't pretend to have fully digested it yet, but one part immediately caught my attention: a new Open Source Strategy for Europe (Section 4 of the PDF, starting on page 16).

The highlights are significant:

• Around €2 billion over seven years to fund and maintain critical Open Source projects.
• "Public money, public code", so publicly funded software is released openly.
• Support for European foundations that can steward key Open Source projects.
• Open Source encouraged across research funding.
• An "Open Source"-first principle for public procurement.

One of the best parts of the strategy is that it treats Open Source as infrastructure that needs sustained investment, not as free software that magically maintains itself. I'll admit, that made me happy.

It is an argument Open Source advocates have made for years, and one I made in Funding Open Source like public infrastructure. The Commission now seems to agree, pointing to the lack of sustained funding, uncertain maintenance, and procurement barriers that hold Open Source back.

Just as important, the strategy reframes why Open Source matters. The old argument for Open Source was mostly about saving money. Here, Open Source is treated as a path to Europe's technological independence: software that Europe can inspect, maintain, and control. In other words, software that gives Europe "freedom of action".

None of this came out of nowhere. The story starts with the 2024 Draghi report, the Commission's landmark diagnosis of why Europe fell behind the United States and China. The Commission spent the next year turning that diagnosis into policy, and today's strategy is one of the results.

You can see how far the thinking has moved just by counting. In Draghi's 412 pages, "Open Source" appears twice. In the new plan, it appears nearly 300 times, in roughly a tenth of the space. It really shows that Open Source has moved from the margins of Europe's competitiveness debate into the center of its sovereignty strategy.

Still, it is worth being clear about what kind of document this is. This is not a law. It does not require companies to use Open Source or rewrite procurement rules across Europe. But it still matters. It moves Open Source from principle to policy: part of Europe's sovereignty agenda, backed by real funding, and a step toward stronger procurement rules.

The strategy notes that "the EU currently spends EUR 264 billion a year mostly on US proprietary IT products and services". That is not the Commission's budget; it is what the broader European economy spends each year on American software.

Set against that number, €2 billion over seven years for Open Source is a start, but a very small one. Seven years of Europe's Open Source budget is roughly three days of its annual American software bill. Europe has started to treat Open Source as sovereignty infrastructure, but it is not yet funding it like sovereignty infrastructure.

The strategy also stops one word short. In procurement, it tells public bodies to choose Open Source "first", not that they must. But "first" is only a preference. It is the kind of thing you talk yourself out of when the demo is shiny and the deadline is close.

For the systems a society cannot afford to lose, Open Source should not be preferred. It should be required. Europe is not there yet, but this is an excellent step in that direction.

Companies compete through their own products and services, but they all depend on the same commons: the software, the community, the project's reputation, and the shared work that helps people trust and adopt it.

That shared foundation creates a different kind of responsibility: sharing a commons means sharing the work of keeping it strong.

The Open Source companies I admire most show up in two ways. They compete on the merits of their own products: features, support, and price. And they help sustain the commons: through code, documentation, security, marketing, events, education, sponsorships, and more.

Judge companies by what they do

Over the past year, Pantheon, one of Acquia's competitors in the Drupal market, has focused much of its messaging on attacking Acquia, including making our private equity ownership part of its story.

I have no quarrel with Pantheon's products or the people who build them. Competition is healthy. My concern is with marketing that attacks another Drupal company, often with misleading or unwarranted messaging.

I've spent nearly twenty years building Acquia through different stages and ownership models. Acquia has grown from a startup into a company backed first by venture capital and later by private equity. Every ownership model creates different pressures, but ownership determines far from everything.

Customers don't choose a platform because of an ownership model. They choose it because it works, because they can get help, and because they trust the platform will keep getting better. In Open Source, that trust depends on the health of the commons behind it.

Customers, partners, community members, and end users are not helped by vendor attacks. They are helped when companies build better products, contribute to Drupal, and help more people adopt it.

License permits, stewardship grows

For an Open Source company, the test is not only what they build for themselves. It is what they help build for everyone.

An Open Source license defines what companies are allowed to do. It sets the floor. Contribution is not required.

Above that floor is a social contract. No one enforces it, but every healthy Open Source ecosystem depends on it.

Stewardship is what companies choose to do beyond the license: contribute code, fund security work, support maintainers, improve documentation, sponsor events, promote adoption, and more.

Drupal thrives because people and organizations honor the social contract and choose to do more than the license requires.

Contribution is one measure of stewardship

Drupal.org credit is one public signal of that commitment. Acquia is the largest single corporate contributor to Drupal, but the wider community contributes far more than any one company.

In the past year, Acquia engineers earned 26,331 weighted issue credits, plus 164 from the Drupal Security Team.

These contributions are good for Acquia, for Drupal, and for every organization that builds on Drupal, including our competitors.

In the same period, Pantheon earned 243 weighted issue credits, plus 2 security credits. Credits don't capture every form of contribution, and Pantheon contributes in other ways too. Even so, the gap is substantial.

What we let pass becomes the social contract

I don't usually write publicly about competitors. It's not how I want to spend my voice.

Before writing this, I asked myself a simple question: if a major company contributing to Drupal were under sustained attack from another major Drupal company, would I feel a responsibility as Drupal's founder and project lead to speak up?

I would.

The fact that Acquia is the company being attacked made me slower to respond, but it doesn't change the answer.

When companies built on Drupal spend their energy attacking each other instead of growing the project, it bothers me. It's not good for Drupal.

I'm not writing this believing it will change anyone's marketing and sales tactics. I'm writing it because what we let pass now will shape what is acceptable in Drupal years from now.

Communities like ours evolve their social contract through moments like this, when we say in public what we expect of each other. If this post contributes to a healthier social contract taking hold, I'm happy.

Compete on merit, but grow the commons

Every company that builds on Drupal depends on the same commons. Every company has a choice about whether to help sustain it, and how much. Drupal gets stronger when more of us invest in it.

My invitation to every company that builds on Drupal is simple: let's compete on the merits of our products and services, not by attacking each other. Let's serve customers well, contribute where we can, and put our energy into helping more organizations choose Drupal in the first place.

That is the social contract I'd like all of us to live by. I want Acquia to be judged by that same standard: what we ship, how well we serve customers, how much we contribute, and whether Drupal is stronger because of our work.

Not by who owns us. Not by claims made about us. By whether we keep building, contributing, and helping the ecosystem grow.

I have said what I wanted to say, and I won't turn this into an ongoing debate or respond to social media comments on this. My focus is on building and contributing.

When an Acquia partner closes a deal, 2% of that deal flows directly to the Drupal Association, credited in the partner's name, to fund Drupal's infrastructure and long-term growth. This is in addition to the millions of dollars Acquia already invests in Drupal each year.

Imagine an Acquia partner closes a $100,000 Drupal deal with Acquia. $2,000 goes to the Drupal Association, attributed to that partner. The 2% comes from Acquia, not from partner margins, so the partner keeps their full revenue and incentives.

The donation is publicly attributed in the Acquia Partner Portal and counts toward the partner's standing in the Drupal Association's Certified Partner Program. It is recognized as financial support for the Drupal Association, separate from non-financial contributions like code, case studies, or community participation.

Most of all, I like that this program is structural. It is not a one-time gift or sponsorship campaign. It is built into the economics of Acquia's partner program, so Drupal's funding grows automatically as Acquia and its partners grow.

Too often, funding for Open Source projects depends on periodic fundraising or individual goodwill. That can work, but it rarely scales in a predictable way.

Open Source sustainability works best when incentives align. With the Fair Trade Initiative, the Drupal Association receives more predictable funding, partners receive recognition through the Drupal Association's Certified Partner Program, and Acquia invests in the long-term health of the Drupal ecosystem its business depends on. And yes, this also creates more incentive for partners to work with Acquia on Drupal projects. Drupal wins, Acquia's partners win, and Acquia wins too. That is what incentive alignment looks like.

I set a reminder for myself to report back in a year, maybe sooner. I'm curious to see what this model can become.

Last month, I proposed a Software Sovereignty Scale that grades software from A to E based on how easily your rights can be taken away. My core argument: if you want sovereignty that lasts, Open Source matters more than buying European proprietary software.

I submitted the Software Sovereignty Scale as feedback to the European Commission, recommending that Open Source carry more weight in the Cloud Sovereignty Framework, the tool EU institutions like the Commission and Parliament use to evaluate cloud providers when purchasing cloud services for their own operations.

The Cloud Sovereignty Framework only applies to how EU institutions buy their own cloud services. The Cloud and AI Development Act, which is expected to build on its approach, would set rules for the entire EU cloud market, across all 27 member states. The difference in scale is enormous, and the time to get this right is now.

My original recommendation was to give Open Source more weight in the Cloud Sovereignty Framework's scoring. I've since realized that isn't enough. Licensing shouldn't be in the sovereignty score at all. It should be a prerequisite.

Open Source is not a rounding error

The Cloud Sovereignty Framework evaluates providers across eight sovereignty objectives, each weighted into a composite score, as shown in the screenshot below. Contracting authorities use that score to rank and compare providers when selecting software and cloud services.

Technology Sovereignty (SOV-6), the objective that covers Open Source, accounts for 15% of the total. Within it, open licensing is one of four contributing factors. That means software being Open Source can contribute roughly 4% to a provider's final sovereignty score.

Does that feel right to you? The one thing that guarantees sovereignty long-term is worth ~4%.

A framework designed to measure sovereignty treats the one factor that makes sovereignty permanent as a rounding error. I could argue the percentage should be higher, or that Open Source supports other objectives, but even at 40%, licensing would still be in the wrong place.

Licensing is fundamentally different from every other objective in the framework. Skype checked every sovereignty box until eBay acquired it in 2005. Every credential was valid before the acquisition and meaningless after.

Had Skype been Open Source, no one could have taken the code away. You would still retain the right to use, modify, and fork it regardless of who acquired the company. That right is permanent, but a European headquarters is not.

That makes licensing a prerequisite, not something to average into a score. Scores compare trade-offs. Prerequisites define what is non-negotiable.

The gate already exists

Beyond the composite score, the framework defines Sovereign Effectiveness Assurance Levels, or SEAL levels. These range from SEAL-0 (no sovereignty at all) to SEAL-4 (full EU control with no critical non-EU dependencies).

For each of the eight sovereignty objectives, the contracting authority sets a minimum SEAL level. Any provider that falls below the minimum is rejected outright. These minimums work as pass/fail gates.

My proposal: licensing belongs in the gate, not in the score. Make Open Source a minimum requirement for the highest SEAL levels.

The Software Sovereignty Scale could map onto SEAL levels like this:

Under this proposal, mission-critical software with high switching costs would require a minimum of SEAL-3, making Open Source a requirement. For lower-risk procurement where the software is easy to replace, SEAL-2 would allow proprietary providers to compete.

Won't this exclude many proprietary providers? Yes, it would. But we have to be honest: proprietary software doesn't give you sovereignty that lasts.

I support the push to buy homegrown technology ("Buy European"). It keeps investment in Europe. But it doesn't solve the underlying problem.

Which government is sovereign?

Consider two scenarios. In the first, a government runs proprietary software on a sovereign European cloud. The provider gets acquired by a non-EU company, and the government can't migrate without replacing the software entirely. It has jurisdiction but ultimately no control. It's not very sovereign.

In the second, a government runs Open Source software on Amazon Web Services (AWS), a US-owned cloud provider with data centers in Europe. If AWS becomes a problem because of the CLOUD Act, policy changes, or geopolitics, the government can move the same software to a European cloud provider. Switching cloud providers can be hard, but switching software is much harder.

It may seem counterintuitive, but the second government is in a stronger position. Open Source on a non-European cloud gives you more sovereignty than proprietary software on a European one, because you can always change the infrastructure. You can't fix the licensing.

This doesn't make the second scenario risk-free. The ideal solution would be Open Source on a sovereign European cloud.

People overestimate jurisdiction and underestimate licensing. Licensing is not one sovereignty factor among many. It's the sovereignty prerequisite.

Special thanks to Tiffany Farriss and Sachiko Muto for their review of this blog post.

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, 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 has only about $7.50 per site per year to work with. 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, volunteer contributions and more.

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.

Plus, 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. If any of that support disappears, 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.com? Are parts of our infrastructure more complex than they need to be? Could we customize less to reduce costs and move faster?

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 could mean greater visibility, access to lead flow, 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 no such mechanism: hundreds of thousands 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 could still be years away from a solution.

I don't have a specific mechanism to propose yet. My goal here is to lay out the problem, explore potential solutions, and start the conversation. But we should start that conversation now, while we have the time and stability to get it right. Otherwise we may end up having this conversation later, under more pressure and with fewer options.

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

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.

I look at Drupal as a concrete example of this in a follow-up post: what it costs to run Drupal's infrastructure.

In practice, this could mean the backend infrastructure around Open Source projects operating more like a SaaS service: the software remains open, but the infrastructure that powers updates and security becomes a paid service for large organizations.

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 organizers didn't step back because federation was the wrong idea. They stepped back because no host would commit funding.

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.

The curl story

Daniel Stenberg, who maintains curl, just ended the curl project's bug bounty program. The program had worked well for years. But in 2025, fewer than one in twenty submissions turned out to be real bugs.

In a post called "Death by a thousand slops", Stenberg described the toll on curl's seven-person security team: each report engaged three to four people, sometimes for hours, only to find nothing real. He wrote about the "emotional toll" of "mind-numbing stupidities".

Stenberg's response was pragmatic. He didn't ban AI. He ended the bug bounty. That alone removed most of the incentive to flood the project with low-quality reports.

Drupal doesn't have a bug bounty, but it still has incentives: contribution credit, reputation, and visibility all matter. Those incentives can attract low-quality contributions too, and the cost of sorting them out often lands on maintainers.

Caught between two truths

We've seen some AI slop in Drupal, though not at the scale curl experienced. But our maintainers are stretched thin, and they see what is happening to other projects.

That tension shows up in conversations about AI in Drupal Core and can lead to indecision. For example, people hesitate around AGENTS.md files and adaptable modules because they worry about inviting more contributions without adding more capacity to evaluate them.

This is AI-driven asymmetric pressure in our community. I understand the hesitation. When we get this wrong, maintainers pay the price. They've earned the right to be skeptical.

Many also have concerns about AI itself: its environmental cost, its impact on their craft, and the unresolved legal and ethical questions around how it was trained. Others worry about security vulnerabilities slipping through. And for some, it's simply demoralizing to watch something they built with care become a target for high-volume, low-quality contributions. These concerns are legitimate and deserve to be heard.

As a result, I feel caught between two truths.

On one side, maintainers hold everything together. If they burn out or leave, Drupal is in serious trouble. We can't ask them to absorb more work without first creating relief.

On the other side, the people who depend on Drupal are watching other platforms accelerate. If we move too slowly, they'll look elsewhere.

Both are true. Protecting maintainers and accelerating innovation shouldn't be opposites, but right now they feel that way. As Drupal's project lead, my job is to help us find a path that honors both.

I should be honest about where I stand. I've been writing software with AI tools for over a year now. I've had real successes. I've also seen some of our most experienced contributors become dramatically more productive, doing things they simply couldn't do before. That view comes from experience, not hype.

But having a perspective is not the same as having all the answers. And leadership doesn't mean dragging people where they don't want to go. It means pointing a direction with care, staying open to different viewpoints, and not abandoning the people who hold the project together.

We've sort of been here before

New technology has a way of lowering barriers, and lower barriers always come with tradeoffs. I saw this early in my career. I was writing low-level C for embedded systems by day, and after work I'd come home and work on websites with Drupal and PHP. It was thrilling, and a stark contrast to my day job. You could build in an evening what took days in C.

I remember that excitement. The early web coming alive. I hadn't felt the same excitement in 25 years, until AI.

PHP brought in hobbyists and self-taught developers, people learning as they went. Many of them built careers here. But it also meant that a lot of early PHP code had serious security problems. The language got blamed, and many experts dismissed it entirely. Some still do.

The answer wasn't rejecting PHP for enabling low-quality code. The answer was frameworks, better security practices, and shared standards.

AI is a different technology, but I see the same patterns. It lowers barriers and will bring in new contributors who aren't experts yet. And like scripting languages, AI is here to stay. The question isn't whether AI is coming to Open Source. It's how we make it work.

AI in the right hands

The curl story doesn't end there. In October 2025, a researcher named Joshua Rogers used AI-powered code analysis tools to submit hundreds of potential issues. Stenberg was "amazed by the quality and insights". He and a fellow maintainer merged about 50 fixes from the initial batch alone.

Earlier this week, a security startup called AISLE announced they had used AI to find 12 zero-days in the latest OpenSSL security release. OpenSSL is one of the most scrutinized codebases on the planet. It encrypts most of the internet. Some of the bugs AISLE found had been hiding for over 25 years. They also reported over 30 valid security issues to curl.

The difference between this and the slop flooding Stenberg's inbox wasn't the use of AI. It was expertise and intent. Rogers and AISLE used AI to amplify deep knowledge. The low-quality reports used AI to replace expertise that wasn't there, chasing volume instead of insight.

AI created new burden for maintainers. But used well, it may also be part of the relief.

Earn trust through results

I reached out to Daniel Stenberg this week to compare notes. He's navigating the same tensions inside the curl project, with maintainers who are skeptical, if not outright negative, toward AI.

His approach is simple. Rather than pushing tools on his team, he tests them on himself. He uses AI review tools on his own pull requests to understand their strengths and limits, and to show where they actually help. The goal is to find useful applications without forcing anyone else to adopt them.

The curl team does use AI-powered analyzers today because, as Stenberg puts it, "they have proven to find things no other analyzers do". The tools earned their place.

That is a model I'd like us to try in Drupal. Experiments should stay with willing contributors, and the burden of proof should remain with the experimenters. Nothing should become a new expectation for maintainers until it has demonstrated real, repeatable value.

That does not mean we should wait. If we want evidence instead of opinions, we have to create it. Contributors should experiment on their own work first. When something helps, show it. When something doesn't, share that too. We need honest results, not just positive ones. Maintainers don't have to adopt anything, but when someone shows up with real results, it's worth a look.

Not all low-quality contributions come from bad faith. Many contributors are learning, experimenting, and trying to help. They want what is best for Drupal. A welcoming environment means building the guidelines and culture to help them succeed, with or without AI, not making them afraid to try.

I believe AI tools are part of how we create relief. I also know that is a hard sell to someone already stretched thin, or dealing with AI slop, or wrestling with what AI means for their craft. The people we most want to help are often the most skeptical, and they have good reason to be.

I'm going to do my part. I'll seek out contributors who are experimenting with AI tools and share what they're learning, what works, what doesn't, and what surprises them. I'll try some of these tools myself before asking anyone else to. And I'll keep writing about what I find, including the failures.

If you're experimenting with AI tools, I'd love to hear about it. I've opened an issue on Drupal.org to collect real-world experiences from contributors. Share what you're learning in the issue, or write about it on your own blog and link it there. I'll report back on what we learn on my blog or at DrupalCon.

Protect your maintainers

This isn't just Drupal's challenge. Every large Open Source project is navigating the same tension between enthusiasm for AI and real concern about its impact.

But wherever this goes, one principle should guide us: protect your maintainers. They're a rare asset, hard to replace and easy to lose. Any path forward that burns them out isn't a path forward at all.

I believe Drupal will be stronger with AI tools, not weaker. I believe we can reduce maintainer burden rather than add to it. But getting there will take experimentation, honest results, and collaboration. That is the direction I want to point us in. Let's keep an open mind and let evidence and adoption speak for themselves.

Thanks to phenaproxima, Tim Lehnen, Gábor Hojtsy, Scott Falconer, Théodore Biadala, Jürgen Haas and Alex Bronstein for reviewing my draft.