Economists often classify goods along two dimensions. The first is excludability: how easy it is to keep someone from using something. The second is rivalry: whether one person's use leaves less for everyone else.

Combining those dimensions produces four kinds of goods.

A private good is both excludable and rival. A sandwich is a simple example: the shop can choose whether to sell it to me (excludable), but once I eat it, nobody else can (rival).

A public good is hard to exclude people from and is not used up through use. A weather forecast is a good example: once published, it is hard to prevent people from using it (non-excludable), and one person's use does not make the forecast less available to anyone else (non-rival).

A common-pool resource is also hard to exclude people from, but it is rival. Fish in the ocean are the standard example. It's hard to prevent people from fishing the ocean (non-excludable), but one person's catch leaves fewer fish for everyone else (rival).

A toll good is excludable but largely non-rival until it reaches capacity. A toll road can keep drivers out (excludable), but one more car does not reduce anyone else's access until traffic builds up (non-rival until congestion). James Buchanan also called these club goods.

The four goods in an Open Source project

People often describe Open Source as both a public good and a commons, but the terms answer different questions. A public good describes a resource's economic characteristics; a commons describes how shared resources are governed.

An ecosystem can be governed as a commons even when its parts have different economic characteristics. That is why it's useful to classify things like code, infrastructure, maintainer time, or collective reputation separately.

Open Source code itself behaves much like a public good. Making another copy does not reduce what others can use. And because Open Source licenses allow recipients to redistribute the code, restricting access becomes difficult after release.

Steven Weber goes further in The Success of Open Source, describing Open Source as anti-rival (not a dimension shown in the table). Under the right conditions, its value can grow as adoption and participation grow. More users can bring more testing, bug reports, features, documentation, promotion, and other contributions.

But the code is only one part of an Open Source project.

Many large projects are Stewarded Open Source. A foundation, company, or community operates its package registries and build systems, responds to security issues, coordinates releases, and more. Each of those activities has its own economics and can be mapped to the four types of economic goods.

A project-operated package registry or the data service behind in-product update and security notifications can behave like a toll good. The project could rate-limit access, require accounts, or reserve additional capacity and features for paying customers.

Support and consulting are private goods. A contract determines who receives the service, and an hour spent helping one customer cannot also be spent helping another.

Maintainer attention can also behave like a private good. Access to dedicated review time can be restricted (excludable), and time spent reviewing one patch cannot also be spent on another (rival).

However, that private input can produce a public good. A funder can pay a maintainer to fix a bug or review a patch, but once the improvement is released under the project's Open Source license, anyone can use and redistribute it. Economists call this the private provision of a public good.

The commercial opportunities an Open Source project generates are a common-pool resource. Customers arrive looking for help because the project has a reputation, and any provider can pursue them (non-excludable). But an engagement won by one provider is gone for the others (rival). The pool of potential customers is the ocean; a signed contract is a fish that has been caught.

What keeps that pool stocked is the project's collective reputation. It is built by many contributors, and every provider draws on it, whether they contributed or not. A provider can win engagements from the pool without helping maintain the project that produces them. Poor-quality work or unhealthy competition can weaken the reputation, and a weaker reputation means fewer customers arrive for everyone.

This is why I have argued that Open Source communities should help customers distinguish between Makers and Takers. Making contribution visible steers commercial demand toward providers that help sustain the project and the reputation that keeps customers coming.

A project-operated marketplace that lists service providers is one way to do this. Access to it can behave like a toll good: the project controls which providers it lists (excludable), while listing one more provider usually does not prevent others from participating (non-rival). Open Source gives providers rights to the code, not a right to promotion by the project. A project can therefore require providers to contribute as a condition of marketplace participation.

A funding rule for stewardship

For an Open Source project, this framework leads to two practical questions: what can it charge for, and what does it need to budget for?

Excludability shows where an Open Source project can control access and therefore where direct pricing is possible. For example, a project could charge for access to its package registry, security notification service, or provider listings in its marketplace. In each case, the project controls something separate from the released code, which remains available to everyone.

Rivalry shows what use can deplete and therefore where capacity must be budgeted. Copies of code do not run out. Bandwidth, server capacity, staff time, and maintainer attention do. A project may still choose to provide them for free, but someone always has to absorb their cost.

Together, the two dimensions suggest a simple funding model: revenue from excludable goods can pay for rival resources, while Open Source code remains a public good.

That does not mean every excludable service should be put behind a paywall. Charging everyone to use a package registry could slow adoption by making the software harder to try. It's why I previously proposed a tiered model for Open Source infrastructure: keep core services free for individuals and small projects, while asking organizations that use them at scale to help pay for what they consume.

Across the four categories, projects can look to private and toll goods for funding, protect common-pool resources from depletion, and use that funding to pay for the work that produces public goods.

Projects that do not make those arrangements explicit will continue to depend on invisible subsidies for infrastructure and maintainer work.

Keeping software relevant and dependable requires people to write code, review contributions, prepare releases, investigate security reports, operate infrastructure, write documentation, answer questions, and support upgrades and migrations. Someone always bears those costs.

A proprietary vendor can tie access to payment: every license or subscription sold helps fund developers, security work, infrastructure, and releases.

Open Source breaks the link between access and payment. Anyone can redistribute the software at any price, including zero. Payment is therefore not a condition of using or redistributing it, and those rights do not themselves provide a durable mechanism for funding production and maintenance.

But separating payment from access does not make the costs disappear. Costs are distributed across maintainers, employers, foundations, sponsors, and users. A maintainer may volunteer their time. An employer may pay a developer to contribute. A foundation may operate infrastructure.

Because these costs are distributed rather than collected through a single transaction, they are harder to see and harder to fund.

Technical choices often shape where those costs fall. That allocation is not always deliberate; it can emerge slowly from decisions that were individually reasonable and become visible only years later.

Drupal's update service recently gave me a good example. Drupal sites periodically contact updates.drupal.org to ask whether new versions of Drupal or any installed add-ons are available. Drupal calls these add-ons "contributed projects", such as modules and themes maintained by members of the community.

The current design sends one request for Drupal itself and one for every contributed project installed on the site. A site with 100 contributed projects therefore makes 101 requests each time it checks for updates, by default, once a day.

There were good reasons for that design. Each project's release history could be stored as a static file and served repeatedly without rebuilding it for every request. The design was straightforward, and it worked.

But Drupal grew. Today, updates.drupal.org serves nearly a billion requests a month. The file containing Drupal Core's release history is roughly half a megabyte by itself. Based on the number of requests for that file, I estimate that Drupal Core update checks alone may account for roughly 50 to 75 TB of data transfer each month. Traffic for contributed projects comes on top of that.

No one chose to make updates.drupal.org transfer tens of terabytes of release data each month. That scale emerged gradually as Drupal grew, from a design that had been reasonable when the ecosystem was smaller.

Part of the challenge is that, in Open Source, the people who benefit, the people who decide, and the people who bear the costs are often different and may have no formal obligations to one another.

Site owners benefit from reliable update notifications, usually without paying the Drupal Association for them. Drupal Association staff operate the update service, while the Association bears its traffic and infrastructure costs. But the code that determines how sites make those requests lives in Drupal Core, where changes require the involvement of Core committers. The Core committers do not report to the Drupal Association, so the Association cannot change that behavior on its own.

In practice, Drupal Association staff and Core committers collaborate closely. That collaboration is important because decision-making authority and cost-bearing sit with different groups.

The people bearing material costs need a way to make those costs visible and influence the decision, even if they do not control it.

This example shows why every Open Source architecture is also a cost-allocation system. Good governance considers that allocation up front, monitors its effects over time, and revisits it when it becomes unsustainable.

Understanding an Open Source system therefore requires more than understanding its code or license. We also need to understand who benefits, who decides, and who bears the costs as the system grows. Once those relationships are visible, a community can decide whether the allocation is sustainable or whether the architecture should change.

I looked at how other content management systems identify related posts: most use shared tags, backlinks, manual curation, or embeddings. I chose embeddings, which compare the meaning of each post, because they can uncover connections without shared tags, existing links, or manual curation.

Embeddings turn meaning into numbers

An embedding model reads text and returns a vector: a long list of numbers. The model I use, bge-base-en-v1.5 from the Beijing Academy of Artificial Intelligence (BAAI), returns 768 numbers for each post.

For one of my posts, the first handful of those coordinates looks something like this:

[ 0.021, -0.045, 0.038, -0.012, 0.007, ..., 0.019 ]

You can think of those 768 numbers as coordinates in a high-dimensional meaning space, where each dimension captures some pattern the model learned from text.

Conceptually, it is a bit like tagging each blog post with hundreds of auto-generated tags, except that these tags are unnamed (they are just numbers) and distributed (meaning is spread across all of them). Together, the 768 numbers place the post near other posts with similar meaning.

This is what lets two posts match even when they use different words. During training, the model learns that certain words and phrases appear in similar contexts or play similar roles, so it places them near each other in the space. It does not need "car" and "automobile" to share any letters to learn that they are used in related ways.

Raw cosine similarity makes everything look related

Once every post has an embedding vector, the next question is how to compare them. This is where I had to dust off a little math. Fortunately, it turned out to be mostly high-school math: averages, angles, and multiplication.

The standard way to compare two vectors is cosine similarity. Imagine each vector as an arrow pointing away from the origin. Cosine similarity measures the angle between two of these arrows and then takes the cosine of that angle, which is where the name comes from.

Two arrows pointing in nearly the same direction form a small angle, and the cosine of a small angle is close to 1, meaning the posts are related. As the arrows spread apart, the cosine falls: at a right angle it is 0, and for arrows pointing in opposite directions it drops to -1, so unrelated posts score closer to 0 or even negative.

In practice, these raw cosine values can be misleading, because embedding models rarely spread their vectors evenly in every direction. They tend to pack most vectors into a narrow cone, a property called anisotropy. It means that the cosine similarities tend to cluster in a narrow band.

On my blog, the raw cosine similarity between two randomly chosen posts is almost always between 0.5 and 0.75, with a median of 0.64. The practical effect is that almost any two posts look somewhat similar even if they are not.

Mean-centering reveals what makes each post distinct

Anisotropy has several known fixes. The easiest is mean-centering, which is what I use and what the rest of this section explains.

Other solutions include All-but-the-top, which removes the average and the next few strongest directions. Whitening stretches the space so every direction carries equal weight (the name comes from white noise).

With mean-centering you simply compute the average vector across all posts and subtract it from every post's vector. Subtracting the average vector from each post removes what all posts have in common; what remains is what makes each post distinct.

A modern model like bge-base-en-v1.5 already suffers less from anisotropy than older or simpler encoders: it is trained with contrastive learning, which pushes unrelated texts apart, and version 1.5 was tuned specifically to spread out its similarity scores. That said, centering still made the scores much more useful on my corpus.

An example might help. Imagine three posts with only two numbers each instead of 768:

A = (0.90, 0.10)
B = (0.85, 0.80)
C = (0.80, 0.75)

At first glance, all three posts might look somewhat similar. In every post the first number is high and close to the others (0.90, 0.85 and 0.80). A number that barely changes from post to post tells you little about how they differ, so that first number is not very useful.

The average (mean) of the three vectors is:

mean = (0.85, 0.55)

Now subtract that average from each post:

A = ( 0.05, -0.45)
B = ( 0.00,  0.25)
C = (-0.05,  0.20)

Now the picture is already clearer. B and C both have a positive second number, so they point in roughly the same direction; A's second number is negative, so it points somewhere else.

Before centering, everything looked similar. After centering, the comparison focuses on what is different from the average.

Normalization reduces comparison to a dot product

After centering, each vector has a length as well as a direction. Length says how far a post sits from the average, and direction says in what way it differs.

I want to rank posts by what they are about, not by how unusual they are, so only the direction matters. Hence, we normalize each vector by dividing it by its own length, which scales it to length 1 and moves it onto the unit circle (or, in 768 dimensions, the unit sphere), leaving only its direction.

It also makes the comparison cheaper. Cosine similarity is normally the dot product divided by the product of the two vectors' lengths. If both vectors have length 1, that denominator is 1 × 1 = 1, so the expression reduces to the dot product alone: multiply the two lists number by number, then add the results.

Using the same example, the centered vectors for B and C are:

B = ( 0.00, 0.25)
C = (-0.05, 0.20)

First, normalize each vector to length 1. A vector's length is the square root of the sum of its squared numbers (good old Pythagoras, only with more numbers). B has length √(0.00² + 0.25²) = 0.25, while C has length √((-0.05)² + 0.20²) ≈ 0.206, so dividing each vector by its own length gives:

B ≈ ( 0.00, 1.00)
C ≈ (-0.24, 0.97)

Then take the dot product:

(0.00 × -0.24) + (1.00 × 0.97) = 0.97

That is a strong match: the closer the score is to 1, the more the two posts point in the same direction. B and C are nearly aligned.

A, after normalization, points mostly downward. Next to B:

A ≈ ( 0.11, -0.99)
B ≈ ( 0.00,  1.00)

Multiplying them the same way:

(0.11 × 0.00) + (-0.99 × 1.00) = -0.99

That is not a match at all.

The PHP code is shorter than the explanation

The production code does the same arithmetic, just with 768 numbers per post instead of two:

public static function center(array $raw): array {
  if ($raw === []) {
    return [];
  }
  $mean = array_fill(0, count(reset($raw)), 0.0);
  foreach ($raw as $vector) {
    foreach ($vector as $i => $value) {
      $mean[$i] += $value;
    }
  }
  $count = count($raw);
  foreach ($mean as $i => $sum) {
    $mean[$i] = $sum / $count;
  }
  $centered = [];
  foreach ($raw as $nid => $vector) {
    $norm = 0.0;
    foreach ($vector as $i => $value) {
      $vector[$i] = $value - $mean[$i];
      $norm += $vector[$i] * $vector[$i];
    }
    // A vector sitting exactly on the mean centers to zero; fall back to 1.0
    // so the division below never hits a zero norm.
    $norm = sqrt($norm) ?: 1.0;
    foreach ($vector as $i => $value) {
      $vector[$i] = $value / $norm;
    }
    $centered[$nid] = $vector;
  }
  return $centered;
}

public static function topMatches(array $source, array $pool, int $self): array {
  $scores = [];
  foreach ($pool as $nid => $vector) {
    if ($nid === $self) {
      continue;
    }
    $similarity = 0.0;
    foreach ($source as $i => $value) {
      $similarity += $value * $vector[$i];
    }
    $scores[$nid] = $similarity;
  }
  arsort($scores);
  return array_keys(array_slice($scores, 0, 3, TRUE));
}

While my explanation was long, both PHP methods are relatively short. In center(), each vector has the corpus mean subtracted, then is divided by its own length. In topMatches(), I calculate the cosine similarity between one post and every other post, then keep the three highest.

You might expect a vector database to replace all of this. It would replace some of it: storing a vector and asking for the closest three would remove topMatches(), but it would not remove center(). Centering is optional, but it meaningfully improved my results.

A vector database likely makes centering harder. Today I store raw vectors and subtract the average when I compare them, so a new post does not change anything I have stored. A vector database would search what I stored, so the subtraction would have to happen before storing. I'd have to update all stored vectors for every new post or every edit, which feels more complex. Maybe vector databases have a good answer for that; I have not looked.

One-time embeddings, occasional ranking

You might wonder how expensive it is to generate these embeddings and compare all these vectors. It turns out to be fast and cheap.

There are two kinds of work, and they happen at different times. Generating an embedding calls an AI model, but happens only once after a post is created or edited. Ranking uses ordinary PHP arithmetic and happens occasionally, when Drupal rebuilds a page's cached related-post list.

I run the model on Cloudflare Workers AI. To generate an embedding, my server makes an HTTPS call that passes the post's text to Cloudflare, which runs the model and returns the 768-number vector. That round trip takes about 250ms. It happens on the first view after a post is created or edited, and the vector is then cached. The model is deterministic, so the same text always produces the same 768 numbers.

Cloudflare bills Workers AI usage in units it calls Neurons and includes 10,000 free each day. Embedding my full archive of roughly 1,500 posts used roughly 4,000 Neurons, and a new post costs about three. Embedding my blog is basically free.

Calculating the related posts never calls the AI model. It all happens in Drupal, my website's content management system. When Drupal needs to build one of the related posts lists, it loads all the stored vectors, centers them, and scores the current post against all the others: roughly 1,500 dot products, each over 768 numbers. This takes around 250ms on my site. After a list has been built, it is cached.

In other words, my website never loads model weights; it just stores the 768 numbers that come back. The machine-learning compute lives at Cloudflare's edge, and my server stays a plain PHP application. None of this needs a vector database or a machine-learning framework: one HTTP call generates the embedding, a key-value store caches it, and a few dozen lines of arithmetic choose the related posts.

Tags are too blunt, backlinks only capture the links I remembered to make, and manual curation does not scale. All three need me to notice the connection first. Using embeddings might sound a bit scary, but they turned out to be easy to implement, fully automated, and able to surface posts I would never have thought to link.

I have lived with a version of that question longer than most.

I released Drupal for free more than twenty-five years ago, and later co-founded Acquia, which has grown into a large enterprise software company built around Drupal.

Granted, Drupal is free in a different way than AI-generated applications are free, but I'm not sure that changes the basic question of how to build a successful business around either one.

Open Source made code abundant by giving people broad rights to use, modify, and redistribute it. AI is lowering the cost of producing code. One lets you copy the software; the other makes it cheaper to recreate software.

Free code changes what customers pay for

Because anyone could use Drupal for free, Acquia could never build a durable business around access to the code. From the start, we had to make money another way.

We built that business around helping enterprises build, run, and manage Drupal applications throughout their lifecycle. That includes hosting, but goes well beyond it: the tools and services needed to develop, deploy, secure, scale, monitor, and improve applications in production.

Proprietary SaaS typically bundles access to the application with the hosting and operations required to run it. With Open Source, organizations can run the software themselves or choose who hosts and operates it.

As AI makes applications cheaper to recreate, the traditional SaaS bundle of software and operations comes under pressure. Customers may become less willing to pay for access to application functionality without becoming any less willing to pay to run and manage applications in production. For Open Source businesses those economics are not new.

Dependability becomes the product

Software can be free, or nearly free, without becoming cheap to depend on. The more people and organizations depend on a system, the more of its value comes from operating it securely, reliably, and at scale.

Once people depend on an application, the cost of its failure has little to do with how much it cost to build. An application that costs $1,000 to build can still cause a $10 million failure.

As AI makes enterprise applications easier to create, adapt, and integrate, they still have to be deployed, secured, scaled, monitored, and run reliably over time. As software cost comes down, dependability becomes a differentiator.

Linux is abundant; dependable cloud infrastructure is a service worth paying for. Drupal is abundant; dependable digital experience infrastructure is a service worth paying for.

Acquia has lived with those economics for nearly 20 years. Drupal made the code abundant, so we built our business around helping organizations build, run, and improve what they created with it. As AI makes code cheaper to generate, that business model may start to look a lot less unusual.

Either way, more software companies will have to answer the same question: if code and capabilities are abundant, what are customers really paying you for?

So far, no agent has found my search on its own. The API Catalog has been a published IETF standard for over a year but I found no evidence that either OpenAI or Anthropic checks for it. ARD is newer, still a v0.9 draft, and I found no evidence that OpenAI or Anthropic supports it either.

In the meantime, what does work is a custom Agent Skill that points my AI assistants to the API Catalog, which leads them to my OpenAPI description and from there to the search itself. If and when agents adopt one or more of these discovery standards, I might be able to drop the skill and have it all work automagically.

Until last week, I had decided Model Context Protocol (MCP) was not worth implementing for my search API endpoint. It required an initialization handshake and could involve protocol-level sessions. My search doesn't need either: every query is stateless and anonymous. MCP felt like overkill for my simple use case.

The 2026-07-28 revision changed my mind because both the protocol-level session and the initialization handshake are gone. Every request can now be self-contained, which means that, for a service like mine, an MCP server is basically a POST route that returns JSON.

So I went ahead and implemented MCP support for my search endpoint. The whole thing came to one route and three small RPC methods: fewer than 150 lines of code, excluding tests.

You can call it from any terminal

In my testing, adding my site as a custom MCP connector to Claude Desktop, Claude Code, or ChatGPT still fails. These clients don't support the new protocol yet, which is understandable because it is only a week old. Once they catch up, anyone will be able to add dri.es as a connector, not just me.

Until then, an easy way to talk to my site with an MCP client is Simon Willison's mcp-explorer. You can run it with uvx, which comes with uv:

uvx mcp-explorer list https://dri.es/mcp
uvx mcp-explorer call https://dri.es/mcp search -a q "open source"

The first command prints the tool's name, description, and arguments. The second runs a search across my posts and returns up to twenty results.

Alternatively, you can use the raw protocol by running this curl command from a terminal:

curl -s https://dri.es/mcp \
  -H "Content-Type: application/json" \
  -H "MCP-Protocol-Version: 2026-07-28" \
  -H "Mcp-Method: tools/call" \
  -H "Mcp-Name: search" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search","arguments":{"q":"open source"},"_meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28"}}}' \
  | jq .result.structuredContent

Discovery and invocation are separate layers

Having implemented support for three new standards, the useful thing I learned is that they are not alternatives.

ARD handles discovery: it gives registries a standard way to index and search for services like mine. OpenAPI and MCP handle invocation by defining how agents can call and use those services.

So the choice is not ARD or MCP. It is ARD plus OpenAPI, or ARD plus MCP.

For an anonymous, read-only API like mine, I prefer OpenAPI. It was easier to implement and anything that can make an HTTP request can use it.

MCP becomes more attractive when you have services that involve multi-step interactions, authentication, or explicit application state.

Ultimately, agent and crawler adoption will decide. Time will tell, but my money is on ARD and MCP right now.

Those choices determine whether harm is possible at all. So when harm occurs, responsibility should fall on those who controlled the relevant choices. That responsibility may be shared: model developers control training and release, product builders control permissions and deployment, and users control deliberate misuse.

Responsibility should follow meaningful control

That principle is missing from much of the debate over open-weight AI models, which often treats the decision to release a model as the only one that counts.

Axios recently reported that United States officials had considered measures that could restrict American companies from using Chinese open-weight models. Open-weight models make their trained parameters available for others to download, modify, and run on their own infrastructure, without going through the company that built them.

More than 230 companies and organizations have since signed an industry letter defending open weights. After critics accused Anthropic of supporting a ban on open-weight models, Anthropic CEO Dario Amodei published a statement denying that position. He described open-weight models that do not have dangerous capabilities as a public good and supported mandatory safety testing for sufficiently capable models, open or closed.

The disagreement is less about whether open weights can create risk than about when those risks justify restricting a release, and whether restrictions would improve safety or mainly concentrate power in the largest AI labs.

I am firmly in the open-weights camp. I have run and compared open-weight models, argued that digital sovereignty depends on who controls software, not where it comes from, and believe organizations should control their infrastructure and data instead of depending on a handful of providers.

I also believe consequential algorithms need oversight. More than a decade ago, I argued that we would eventually need something like an FDA for software. The harder question is where responsibility for that oversight should lie.

Open-weight models unbundle control

With hosted, closed-weight models from providers such as Anthropic and OpenAI, the provider typically keeps the weights private, controls how customers access the model, and decides when to update the hosted service.

Open weights can separate those roles. One organization creates and releases the model. A repository such as Hugging Face hosts and distributes the weights. Another team might fine-tune them. A product builder incorporates the model into a product and connects it to data, tools, and users.

Each team controls something different. Because open weights unbundle control, it becomes harder to say who is responsible when harm occurs.

A model developer controls the training process, capability testing, documentation, and release decisions. A repository controls what information it displays about a model's origin, which security checks it performs on uploaded files, and which access restrictions it provides or enforces. A product builder controls what data and tools the resulting system can reach, which actions require human approval, and what gets logged.

Control is not the only thing that matters, but it shows who could still have changed the outcome. When harm involves AI, several actors may bear responsibility for the same incident because each controlled a different opportunity to prevent it.

Open Source shows how responsibility follows control

Like open-weight models, Drupal's Open Source code can be copied and changed without asking anyone's permission. A site owner could use it to spread misinformation or operate a fraudulent website. The site owner controls the content and operation of the site and is responsible for those choices. The Drupal project is not responsible merely because someone used its code.

But the Drupal project controls other decisions. When someone privately reports a security vulnerability, the Drupal Security Team follows a coordinated disclosure policy. It keeps the issue private while a fix is prepared. Once a security release is available, the team publishes an advisory and tells site owners to upgrade. The timing of that disclosure can give site owners a fair chance to protect themselves.

The same distinction applies to AI. Responsibility should follow the decisions each actor controls.

Products turn capability into authority

A model generates outputs. An agent is a software system that uses a model to work toward a goal, often by calling tools and taking actions. The people who build and configure the agent decide what it can access, which actions it can take, and when it needs a person's approval.

In a coding agent such as Claude Code, a model can generate a database command. Whether that command can run depends on the tools and permissions the agent provides, as well as the access allowed by the computer, network, and database.

A content management agent can propose deleting an article. The content management system (CMS) determines whether the agent has permission to delete it, whether the deletion is reversible, and whether the action is recorded.

Permissions, isolation, audit logs, rate limits, human approval, and rollback are not merely engineering details. They determine who has control at the point where harm can still be prevented. That is why AI governance is becoming an essential part of product architecture.

Regulate AI at each point of control

Deciding who should answer after harm is easier, even when the answer is not obvious. The harder question is what government should require before any harm has happened.

If control and responsibility are distributed across several actors, government rules should be distributed across them too. This is not a new idea. We already regulate many technologies this way.

More than a decade ago, when I argued for something like an FDA for software, I had drug approval in mind. I no longer think that is the right model. The FDA approves a drug for one or more intended uses, while a general-purpose model may be used for many different purposes.

Cars are a better comparison. The government sets safety standards, and manufacturers certify that their vehicles meet them. Separately, drivers must pass a test defined by the government before they are licensed to drive.

The layers extend beyond cars and drivers. States set legal blood-alcohol limits for drivers and require bars to have licenses they can lose. In many states, a bar can also be held liable for serving a visibly intoxicated person who later causes harm.

Each rule targets the actor who controls a particular decision. Together, they reduce risk for everyone. I would take the same layered approach to AI.

Blocking a model's release is a much stronger step, and one that should rarely be used. For an open-weight model, that means preventing the developer from publishing the weights. For a closed model, it could mean preventing the provider from offering access.

I would support that only when safeguards in products and rules governing their use could not prevent a serious danger in time. The two-part test below applies only to this exceptional step, not to AI regulation in general.

Require extraordinary evidence to block a release

The strongest argument for restricting an open-weight release is that it is effectively irreversible. Once the weights are public, the developer cannot withdraw every copy, monitor how the model is used, or ensure that its safeguards remain in place.

If a model made catastrophic harm much easier, its release could be the last moment anyone had meaningful control. By catastrophic, I mean mass-casualty or comparably systemic harm, not ordinary product failure, fraud, or abuse.

As of July 2026, I have not seen public evidence that an open-weight model has crossed this threshold. That said, I believe it is just a matter of time, which is why I still think meaningful regulation is coming.

Before blocking a model's release, a government should have clear evidence that the answer to both questions is yes:

1. Would releasing this model make catastrophic harm much easier? Compare it with closed models and other tools people can already access.

2. Would blocking its release meaningfully reduce that danger? A restriction should not merely shift access to another country or distribution channel.

Default to openness with distributed responsibility

So where do I land today? I would default to allowing publication and place obligations where control already exists: on model creators for testing and release decisions, on distributors for provenance and file integrity, on product builders for permissions and deployment, and on users for deliberate misuse.

This approach also protects competition. A regulatory regime that only the largest labs can satisfy could protect them from competition without necessarily making anyone safer. It could also push organizations toward depending on a handful of providers for infrastructure they cannot inspect.

Open weights do not eliminate control. They distribute it, making it harder to say who is responsible when harm occurs. Regulation should follow that structure: place obligations on each actor at the point where harm can still be prevented, and block publication only when release would make catastrophic harm substantially easier and a restriction would materially reduce the danger.

Last week, I joined the Drupal AI Learners Club to discuss several experiments I had already published. Angie Byron started the club and runs it with co-organizer Amber Himes Matz. It gives people in the Drupal community a place to show how they are using AI and talk honestly about what works and what does not.

I spent an hour walking through some of my AI experiments, starting with Drupal Digests, a tool that uses AI to summarize key developments across Drupal Core, Drupal CMS, Drupal Canvas, and the Drupal AI initiative.

Drupal Digests led to another experiment: AI-generated Rector rules. When a Drupal Core change deprecates an API, Drupal Digests analyzes the issue and code changes and generates a rule that can automate the corresponding upgrade in other Drupal projects.

I also showed my API Catalog that helps AI agents discover my website's search API.

These are only some of my AI experiments. Most begin as tools I build for myself, and many never go any further. When one seems useful beyond my own work, I publish it so others can benefit from it.

Once a tool is public, we can see whether people use it and want to help improve it. If they do, it may eventually become a proper community project. If not, that is useful to know too.

The recording goes into more detail, with demonstrations of the tools and questions from the group. You can watch it below.

What ARD adds to yesterday's API catalog is discovery. If an agent has never heard of you, it does not know to look for your API catalog. Ask an agent what people have written about the future of Drupal, for example, and it will probably search Google. It may not think to check dri.es or drupal.org directly.

The web solved discovery decades ago. Search engines find the right site, so you do not have to know where the answer lives.

ARD brings search-engine-style discovery to AI agents. ARD registries crawl the web for catalogs published by sites and add their resources to a searchable index. An agent can then ask a registry a plain-language question, such as "Who can answer questions about the future of Drupal?". The registry returns a ranked list of relevant resources, perhaps pointing the agent to my site's search API.

You opt in by publishing a manifest at /.well-known/ai-catalog.json. Here is what my mine currently returns:

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Dries Buytaert"
  },
  "entries": [
    {
      "identifier": "urn:air:dri.es:search",
      "displayName": "Site search",
      "type": "application/openapi+json",
      "url": "https://dri.es/openapi.json",
      "description": "Full-text search across the site's content, ranked by relevance.",
      "representativeQueries": [
        "Find posts about the future of Drupal",
        "What has been written about open source sustainability?",
        "Find writing about digital sovereignty",
        "How is AI changing how we build websites?",
        "Search Dries Buytaert's blog and notes"
      ]
    }
  ]
}

Each entry describes a resource an agent can use. ARD deliberately defines "resource" broadly: it can be an API, an MCP server, another agent, a skill, or even a nested catalog containing more resources.

My site offers just one resource: a simple search API. The whole thing took less than an hour to implement because the ARD entry simply points to the existing OpenAPI document, https://dri.es/openapi.json, that I wrote about yesterday. In other words, it makes the same API description available through a second discovery mechanism.

The representativeQueries field is the interesting part. It lists example questions registries use to match an agent's intent. Mine are first guesses that I will revise once I can see how they get used.

Of the eleven companies listed as contributors, Hugging Face is the only one whose AI catalog I could find on its primary domain. It also runs an early registry. So I queried Hugging Face's registry. It responded correctly using the protocol defined by the specification, but for my queries, it returned only skills hosted by Hugging Face.

Broad adoption will depend on whether major agents begin searching ARD registries. Microsoft, Google, and GitHub are members of the working group, but OpenAI and Anthropic are not. Google has said its Agent Platform will connect to ARD registries in the coming months, but it remains to be seen how widely the specification will be adopted.

Does my blog need this? Probably not. Other sites have more to gain. An online store could announce its product search and checkout APIs, a restaurant its reservation system, and a city its appointment system for renewing a permit.

Many of these sites run on a content management system. A CMS that made its capabilities discoverable through ARD by default could therefore be interesting. Experiments like this help me understand whether Drupal should be that CMS.

At the same time, the web is gaining a new audience. In addition to people visiting pages, AI agents increasingly access a site's knowledge and tools directly.

That combination led me to add support for /.well-known/api-catalog to my site. A request to https://dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://dri.es/search/json",
      "service-desc": [
        {
          "href": "https://dri.es/openapi.json",
          "type": "application/openapi+json"
        }
      ]
    }
  ]
}

RFC 9727, an IETF Proposed Standard, defines /.well-known/api-catalog as a predictable location for discovering a site's public APIs.

The catalog is a small JSON document written in the Linkset format. It advertises my search endpoint and, in turn, links to an OpenAPI document that tells software how to use it.

The JSON endpoint at /search/json predates the catalog and powers my site's search. However, it was not documented or easy for software to discover. The catalog now makes it explicit.

The OpenAPI document at https://dri.es/openapi.json tells AI agents exactly how to call the endpoint and interpret the results. It removes the guesswork, reducing the time and tokens agents would otherwise spend figuring out how the API works.

In short, the API catalog announces that my search API exists, while the OpenAPI document explains how to use it. An agent can start with just my domain, check /.well-known/api-catalog, follow the link to the OpenAPI document, and learn how to search dri.es directly.

The feature has been live for a few months, but I am only now writing about it. In the meantime, I have logged every request to /.well-known/api-catalog and /openapi.json. The result so far: zero AI agents have used it.

I found the same problem when I analyzed llms.txt usage: the AI crawlers it was meant for never use it, so I never bothered implementing it.

Unlike llms.txt, the API catalog solves a problem I have, and I do not need to wait for industry adoption. I recently created an Agent Skill, a SKILL.md file that directs my agents to check the catalog and use my site's search API whenever they need information from dri.es.

My agents now search dri.es directly and find posts that Google misses. And if any AI agent adopts API catalog discovery, my site is ready.

Some of these sites will move to Acquia Cloud, our Drupal PaaS, while others will move to Acquia Source, our Drupal SaaS. Drupal CMS played an important role in these decisions by making Drupal more approachable to marketers and site builders.

Why are different organizations making the same choice? One key reason is the cost of CMS fragmentation.

A few months ago, a CMO told me that her team had purchased a new digital asset management system (DAM). The estimate to connect it to the organization's websites came back at nearly $100,000 and three months of work.

Why so much? The organization ran three CMS platforms: Drupal, WordPress, and Contentful. The DAM had to be integrated with all three. That meant not only three integrations, but also three sets of expertise, three rollout plans, and three ongoing maintenance responsibilities. One new capability had become three separate projects.

Organizations are under pressure to move faster and reduce costs. CMS fragmentation creates a recurring tax through duplicated integrations, security practices, governance policies, infrastructure, technical expertise, and more. It also fragments attention and makes it harder to share improvements across teams and websites.

Organizations pay that tax every day through higher operating costs and slower execution, not only when they introduce new capabilities. When it consistently slows their ability to improve digital experiences, it can become a competitive disadvantage.

Some of this duplication can be reduced by standardizing hosting and portfolio governance across multiple CMS platforms. That is valuable, but it addresses only one layer of the problem. Each CMS still has its own extension model, editorial experience, security considerations, and required expertise.

This fragmentation usually happens for understandable reasons. Teams often make technology decisions independently, and different sites can have genuinely different requirements.

A marketing team may need to launch a campaign site in days without involving developers, making SaaS solutions attractive. A team responsible for a high-traffic enterprise application with custom integrations may need the flexibility and control of an Open Source solution running in a PaaS environment.

Each decision can make sense for the individual project while creating significant duplication across the organization.

More than 15 years ago, I argued in a post about Acquia's product strategy that organizations should standardize on a common CMS while choosing the right operating model for each site.

Today, the case is even stronger. Websites depend on more integrations, digital experiences are more complex, and AI is becoming another shared capability that organizations need to deploy across their portfolios. With multiple CMS platforms, every new capability becomes harder and more expensive to deploy safely.

Standardizing on a single CMS lets teams reuse more of their design systems, security practices, integrations, and expertise across sites. Marketers get a more consistent way to create and manage content, while developers spend less time implementing the same capabilities on unrelated platforms.

But standardizing on Drupal does not mean forcing every site into the same architecture or operating model. Organizations can share a common CMS foundation while choosing a different balance of convenience and control for each site.

That is where Acquia Source and Acquia Cloud fit together.

Acquia Source provides the SaaS operating model. It is designed for teams that value speed and simplicity. Acquia manages the underlying platform, while marketers and site builders customize experiences through the user interface, reusable components, and supported integrations. Developers can extend sites through custom components, APIs, webhooks, and other supported tools without managing the Drupal codebase or installing arbitrary modules.

Acquia Cloud provides the PaaS operating model. It is designed for sites that need deeper customization and more developer control. Teams can build custom Drupal modules, use contributed modules, manage code through Git, run CI/CD pipelines, and integrate Drupal more deeply with other systems.

Both are built on Drupal. This gives organizations a shared foundation for skills, content practices, design systems, security, and integrations, while allowing each site to choose the right balance of speed, simplicity, flexibility, and control.

A site can begin on Acquia Source when speed and simplicity matter most. If its requirements later grow to include custom modules, deeper integrations, or more developer control, the organization can export its source code, database, and files and move to Acquia Cloud or another Drupal environment without adopting a different CMS.

I have been calling this "Open SaaS": the convenience of SaaS combined with the ownership and portability of Open Source. Organizations can choose a different operating model without leaving Drupal or surrendering control of their sites.

When organizations standardize this way, the economics change dramatically. We have helped some customers save millions of dollars each year by reusing shared capabilities instead of rebuilding them for different platforms.

The goal is not to operate every website in the same way. A campaign site and a mission-critical application require different levels of speed, flexibility, and control, but they do not need unrelated CMS platforms.

The goal is to create operating leverage across an organization's digital portfolio. Each site can use the operating model that fits its needs, while teams reuse investments in content, design, integrations, security, and expertise.

Then, when the organization adds a DAM, a personalization engine, an analytics platform, or an AI capability, teams can build on shared work rather than start over for each CMS. The result is faster execution, greater returns on digital investments, lower costs, and less risk.

One CMS foundation with multiple operating models makes that possible.