Dries Buytaert

The Sovereignty Prerequisite

Wed, 01 Apr 2026 05:06:03 -0400

Procurement frameworks aren't the most exciting topic. But the European Commission is about to propose the Cloud and AI Development Act (CADA), and how it treats Open Source will affect every Open Source project and Open Source business operating in Europe. This is one of those moments where the details matter.

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.

Screenshot of how the European Commission computes its composite sovereignty score. Technology Sovereignty (SOV-6), which covers open licensing, accounts for 15% of the total. Source: Cloud Sovereignty Framework, version 1.2.1, October 2025.

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:

SEAL level	Framework definition	Proposed licensing gate	What it means in practice
SEAL-3 or above	Digital Resilience / Full Digital Sovereignty	Grade A, B, or C (Open Source)	Software can be forked and maintained independently. Sovereignty survives acquisition.
SEAL-2	Data Sovereignty	Grade D or above (including European proprietary software)	European jurisdiction, but structurally vulnerable to acquisition or relicensing.
SEAL-1	Jurisdictional Sovereignty	No licensing gate	Minimal sovereignty assurance.

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 12 switches to Argon2id

Mon, 30 Mar 2026 05:15:35 -0400

Drupal 12 will hash passwords with Argon2id by default. It moves every Drupal site to what is now best practice for password storage, recommended by OWASP and aligned with NIST guidance.

Drupal is often used for security-sensitive and large-scale sites, so these kinds of changes matter.

Early versions of Drupal stored passwords as simple MD5 hashes, which is extremely weak by today's standards. Drupal 7 introduced a modified version of the phpass library using SHA-512 with multiple iterations and a salt, and Drupal 10 switched to bcrypt. Each jump was a response to attackers getting faster hardware, and this change continues that pattern.

When I first looked at this change, I wanted to understand what Argon2id actually does differently from bcrypt.

Its key advantage is that it is "memory hard". Each Argon2id hash requires far more memory to compute than a bcrypt hash, and the amount is configurable.

Modern GPUs can run many bcrypt computations in parallel because each one uses very little RAM. GPUs have a lot of total memory, but it is shared across thousands of parallel computations. As a result, Argon2id limits how many hash computations can run in parallel, making it harder and more expensive to scale attacks.

The best security upgrades are the ones nobody has to think about. Once a site upgrades to Drupal 12, existing passwords will automatically be rehashed to Argon2id the next time each user logs in. And in the unlikely event that Argon2id is not available in a particular PHP installation, Drupal will fall back to bcrypt for compatibility.

Many site owners never think about password hashing, so Drupal's defaults become their security policy. The people who benefit most from this change may never know it happened. It's why being "secure by default" matters so much.

Thanks to everyone who helped make this happen.

State of Drupal presentation (March 2026)

Thu, 26 Mar 2026 19:06:55 -0400

This year, Drupal turned 25. DrupalCon Chicago felt like the right place to mark that milestone. My keynote was part celebration and part wake-up call. I talked about Drupal's foundations, how AI is putting pressure on them, and why I believe we can rebuild them stronger than before.

If you missed the keynote, you can watch the video below or download my slides (32.6 MB).

It will be interesting to rewatch this keynote in 10 years, when AI is fully mainstream and has reshaped how we work, including our agencies, our craft, and how we collaborate in Open Source. It feels like a snapshot of an industry in transition.

Site templates and the marketplace

About a year ago at DrupalCon Atlanta, I introduced the idea of site templates and a marketplace to go with them. By DrupalCon Vienna, we had one site template, but no marketplace.

In Chicago, I showed eleven site templates available in a basic marketplace at marketplace.drupal.org. All eleven can be installed directly from the Drupal CMS installer.

AI for site building

For more than 20 years, Drupal's ecosystem has rested on a stable triangle: the platform itself, digital agencies who bring Drupal into the real world, and the community that builds and maintains it. That triangle has proven remarkably resilient through many waves of new technologies.

But what happens when AI disrupts all three sides at the same time? In my keynote, I showed how Drupal is responding.

I started by showing a demo of a workflow I believe will become common for Drupal agencies. You quickly prototype a website with AI, then turn it into a Drupal site with the help of AI and a skilled developer, all within hours.

AI gets you to a prototype fast. Drupal gives it the foundations that last.

I believe Drupal has a unique advantage in this new world. Organizations will always need real workflows, permissions, security, scalability, integrations, compliance, and governance. Drupal is very well suited for AI-driven workflows.

The demo worked because Drupal CMS ships with Drupal Canvas, which includes both CLI tools and AI skills. But the real strength comes from Drupal's foundations: its APIs, reusable building blocks, and mature architecture, refined over 25 years. This is the accidental AI advantage I have written about before. This is what makes Drupal one of the best platforms for AI-driven development.

AI for content management

At DrupalCon Vienna, I introduced the Context Control Center as a rough prototype. Since then, we have added many features. It is now nearly production-ready.

The idea is straightforward: AI agents need good context to help manage tasks in Drupal. With the Context Control Center, teams define their brand voice, target audiences, key messages, product details, and editorial guidelines in one place. Then every AI agent on the site draws from this single source of truth. The result is that you create knowledge once, and scale it to all the pages and content on your website.

In my keynote, I showed two demos of the Context Control Center in action. First, Drupal's AI agents turn a simple marketing brief into a complete, on-brand page using Drupal Canvas, consulting the Context Control Center along the way. It followed brand rules, asked clarifying questions, generated structured data for search, and added cross-links.

Second, I showed a proof of concept for dynamic contexts, where the Context Control Center pulls in real-time data from Google Analytics to help improve content performance after publication.

Saying no to AI slop

AI is lowering the barrier to contribute to Open Source projects like Drupal. On paper, that sounds great. More contributors, more patches, more momentum.

But it can also be a real challenge. The volume of contributions is going up while the quality is going down. More patches are landing on a small group of maintainers, and reviewing low-quality code wastes their time. This creates asymmetric pressure on Open Source.

If you're using AI to contribute, you are responsible for what you submit: don't submit code you don't understand. Our quality standards matter, and we will uphold them.

Our craft always evolves

In my keynote, I also told the stories of two community members who embraced AI in a meaningful way.

Aidan Foster, who has been running Foster Interactive for 17 years, chose to go all in on the Drupal AI Initiative instead of staying on the sidelines. Together with his team, he is rebuilding the foundations of his agency to leverage AI and prepare for what is next.

And Jürgen Haas, a longtime contributor and creator of the ECA module, used AI to move at the speed of a team and make Drupal's ECA module much easier to use. In both cases, AI amplifies expertise. It does not replace it.

The world is being flooded with AI-generated average. Average is cheap now, but expertise remains hard-earned and valuable. This community has spent 25 years building it, and that is not something AI can replicate.

AI is the storm, and AI is the way through the storm. I said that first in Vienna. Six months later, I believe it more than ever. Not as a slogan, but as something I have watched happen. We need more people like Aidan and Jürgen. If you want to get involved, join us on Drupal Slack or attend DrupalCon Rotterdam this fall.

I want to extend my gratitude to everyone who contributed to making my presentation and demos a success. A special thank you to Adam G-H, Aidan Foster, ASH Sullivan, Christoph Breidert, Cristina Chumillas, Emma Horrell, Gábor Hojtsy, Gurwinder Antal, James Abrahams, Jurgen Haas, Kristen Pol, Lauri Timmanee, Marcus Johansson, Martin Anderson-Clutz, Pamela Barone, Scott Falconer, Tim Lehnen. Many others contributed indirectly to make this possible. If I've inadvertently omitted anyone, please reach out.

Elo 1800

Fri, 20 Mar 2026 16:47:59 -0400

I finally crossed 1800 on Chess.com. It took 17 months to gain 100 points. It felt endless.

A few times, I was one game away from reaching 1800. Each time, I collapsed into a losing streak and dropped back to the low 1700s. Few things I do for fun frustrate me as much as chess.

Growth never happens in a straight line. Improvement often looks like regression. Even when I'm going backward, I'm still improving. That lesson carries into work and life.

When working out on the Peloton, I often watch 2000-rated players on YouTube. They're only 200 Elo points higher, but the gap feels massive. Skill doesn't scale linearly.

My game has certainly improved. I see weaknesses faster now, which helps me form better middle game plans. For better or worse, I still rely on a few familiar openings, but they usually get me to a playable position.

Still, 17 months for 100 points feels slow. Should I aim for 2000? Part of me wants the challenge. Another part questions the tradeoff, or whether I'll get there at all. I've not decided yet. For now, I am proud of reaching 1800.

Never submit code you don't understand

Mon, 16 Mar 2026 11:37:45 -0400

Years ago, in the early Drupal days, you would see a mantra everywhere: "Don't hack core".

It showed up in issue queues, conference talks, support channels, stickers, and even on T-shirts. It was short and memorable, and it solved a real problem: too many people were modifying Drupal Core instead of extending it properly.

Over time the mantra worked. The ecosystem matured. Not just the software itself, but also the habits and expectations around it. Today you rarely hear people say "Don't hack core".

With AI changing how code gets written, we may need a new mantra.

In Open Source, all code needs to be understood and reviewed before it can be merged. That responsibility belongs to both contributors and maintainers. AI is changing how code gets written, but it does not change that responsibility. In fact, it may make it easier to forget.

Code you don't understand becomes someone else's problem. In Open Source, that someone is often the maintainer reviewing your patch.

Offloading bad code onto maintainers wastes people's time, which is inconsiderate, and slows down reviews for everyone. You also miss the chance to learn from the code and grow as a developer.

It shouldn't matter what tools you use. But if you submit code, you should be able to explain what it does, why it works, and how it interacts with the rest of the code.

Everyone starts somewhere. Even today's top contributors submitted imperfect patches early on. You are welcome here, with or without AI tools. Perfection isn't required, but understanding your code is. Own your code and respect people's time.

Maybe it's time for some new stickers and T-shirts.

Never submit code you don't understand.

Thanks to Natalie Cainaru, Jeremy Andrews and Gábor Hojtsy for reviewing my draft.

What it costs to run Drupal's infrastructure

Tue, 10 Mar 2026 18:30:34 -0400

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, 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.

Open Source infrastructure deserves a business model

Mon, 09 Mar 2026 14:36:23 -0400

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.

	Donated infrastructure	Multi-company sponsorship	Community funding	Single-company patronage
PyPI	☑	☐	☐	☐
Packagist	☐	☐	☐	☑
npm	☐	☐	☐	☑
WordPress	☐	☐	☐	☑
RubyGems	☐	☑	☑	☐
Drupal	☑	☑	☑	☐

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.

Markdown, llms.txt and AI crawlers

Thu, 05 Mar 2026 10:18:15 -0500

In January, I made every page on my site available as Markdown. Immediately AI crawlers quickly found the Markdown versions. I was excited, but excitement isn't data. Now that the dust has settled, I pulled a month of Cloudflare logs and analyzed them.

I compared how much AI bots crawl my site to how often AI answer engines link back. For every citation they sent, their crawlers had fetched 1,241 pages. That is a lot of reading for very little traffic in return. It is the deal AI is offering creators right now, and it is not a good one.

People also asked whether serving Markdown reduced my bot traffic since the files are smaller. It does not. Bots fetch both versions, and my crawler traffic increased by about 7%. Offering a lighter format does not replace the heavier one. It simply gives bots more to crawl.

As the table below shows, several AI companies crawl my site. Some fetch thousands of pages each month, but very few request the Markdown versions.

Bot	Vendor	Total	HTML files	.md files	% .md
Amazonbot	Amazon	16,872	15,032	1,840	10.9%
ChatGPT-User	OpenAI	13,864	13,856	8	0.1%
Meta AI	Meta	9,011	8,526	485	5.4%
ClaudeBot	Anthropic	7,144	6,995	149	2.1%
OAI-SearchBot	OpenAI	5,722	4,422	1,300	22.7%
GPTBot	OpenAI	3,385	2,208	1,177	34.8%
Bytespider	ByteDance	1,190	1,190	0	0.0%
CCBot	CommonCrawl	530	530	0	0.0%
PerplexityBot	Perplexity	467	466	1	0.2%
Claude-User	Anthropic	94	87	7	7.4%

Interestingly, OpenAI runs three bots with different roles. OAI-SearchBot indexes content for search, GPTBot crawls for training data, and ChatGPT-User fetches pages in real time during live ChatGPT sessions.

When I added Markdown support to my site, I exposed it in two ways. The first is through dedicated Markdown URLs: append .md to any page and you get the Markdown version. The second is through content negotiation, where the original URL returns Markdown instead of HTML when the request includes an Accept: text/markdown header.

No AI crawler uses content negotiation. Not one. They only discover the Markdown pages through the dedicated URLs, and only via the auto-discovery link. To be fair, the auto-discovery link points to the .md version.

Bot	robots.txt	sitemap.xml	llms.txt	.md files
Amazonbot	182	-	-	1,840
ChatGPT-User	-	-	-	8
Meta AI	-	75	-	485
ClaudeBot	496	115	-	149
OAI-SearchBot	653	-	-	1,300
GPTBot	-	4	-	1,177
Bytespider	259	-	-	-
CCBot	8	-	-	-
PerplexityBot	142	-	-	1
Claude-User	87	-	-	7

And then my favorite: llms.txt, a proposed standard where sites describe their content for AI systems. My site received 52 requests for it last month. Every one came from SEO audit tools. Not a single request came from an AI answer engine or crawler. (I don't use or pay for SEO tools but apparently that doesn't stop them from auditing my site.)

For fun, we also looked across Acquia's entire hosting fleet and found about 5,000 llms.txt requests out of 400 million total (0.001%), nearly all from SEO tools. llms.txt is a solution looking for a problem. The bots it was designed for don't look for it.

So should you add Markdown support to your site? Probably not. There is no clear benefit today. It does not reduce crawl traffic, and I can't demonstrate that it improves how AI systems use your content.

We do know that AI systems love Markdown, and they fetch it when it is available. At best, it may become more useful over time.

If it is easy to add and you enjoy experimenting, go ahead. If it takes real effort, spend that effort on your content instead. What still works is what has always worked: clear writing, authoritative content, and timely publishing.

Drupal 25th Anniversary Gala at DrupalCon Chicago

Tue, 03 Mar 2026 10:55:07 -0500

There is a big party happening at DrupalCon Chicago, and I can't wait.

On March 24th, we're celebrating Drupal's 25th Anniversary with a gala from 7–10 pm CT. It's a separate ticketed event, not included in your DrupalCon registration.

Some of Drupal's earliest contributors are coming back for this, including a few who haven't attended DrupalCon in years. That alone makes it special.

If you've been part of Drupal's story, whether for decades or just a few months, I'd love for you to be there. It's shaping up to become a memorable night.

The dress code is "Drupal Fancy". That means anything from gowns and black tie, to your favorite Drupal t-shirt. If you've ever wanted an excuse to dress up for a Drupal event, this is it!

Tickets are $125, with a limited number of $25 tickets underwritten by sponsors so cost isn't a barrier. All tickets must be purchased in advance. They won't be available at the door. Registration closes March 18th, so grab your tickets soon.

Organizations can reserve a table for their team. Even better, invite a few contributors to join you. It's a great way to give back to the people who helped build what your business runs on.

For questions or sponsorship opportunities, please reach out to Tiffany Farriss, who is serving as Gala Chair and part of the team coordinating the celebration.

Know someone who should be there? Share this with them.

What matters most is that you're there. I can't wait to celebrate together in Chicago.

Skiing in Saint-Gervais, France

Tue, 24 Feb 2026 05:10:23 -0500

Last week, we went on a ski trip in Saint-Gervais, France. For the first time, Axl wasn't with us. He's off at university now, and his school breaks no longer line up with Stan's. So Stan and I had a lot of father-son time on the slopes.

Our friends Alexis and Héloïse were also on the trip with us, and Alexis captured this short video one of the days. I love it. Thank you, Alexis!