Freedom is Not Free: A Model for Open Source Sustainability demet Tue, 06/23/2026 - 11:49

How to align public policy and procurement to support the costs of our shared digital infrastructure

The modern world runs on open source software-trillions in economic value, and growing more essential to digital sovereignty by the day. Yet, beneath this foundation, the projects producing it are starved of capital. Open source simply does not have the structural resources it needs to be sustainable. The code is free, but the human and technical infrastructure required to maintain it is not.

A project like Drupal is no longer just a code repository; it is a full-scale utility provider. We deliver supply chain security, product management, and continuous integration pipelines. Our licenses waive all warranties and responsibilities-and yet enterprise scale demands we provide these services anyway, because no one else will. The core failure of our current model is that open-source funding is completely disconnected from these operational cost centers.

Because we lack a built-in mechanism to capture the value open source creates, we have accidentally engineered an extractive system. The Takers who consume open source without paying their fair share of its operational footprint are not acting out of malice; they are simply doing exactly what the market currently incentivizes them to do.

It is not inevitable that open source must be extractive. That is an architectural choice. To change the outcome, we must change the incentives. Using regenerative system design, we must re-engineer open-source models to capture enough resources from our outputs to continuously sustain our inputs. We must ensure that supporting open source the right way becomes both the easy way and the expected way.

Right now, supporting open source the right way is almost impossible for our largest users. Public procurement systems are designed to buy structured services from single vendors. They cannot write open-ended checks to decentralized communities. To bypass this "charity trap," we must transition to an operational cost framework and move the operating costs of open source off the donation sheet and directly into core operating budgets as a predictable, line-item consumption expense.

To make the easy way possible, open source foundations must clearly quantify and communicate our true technical and human costs. In Drupal, we know part of it. We provide $10 per site per year in consumable technical infrastructure, but our revenues only fund $7.50. The remaining $2.50 is pushed off as technical debt to the future. That gap says nothing about the release managers and security teams whose essential work is still mostly donated-that burden sits entirely outside this number. We must turn these technical and human maintenance costs into a transparent, billable utility, giving institutions a clear, legally compliant way to pay for what they consume.

But once we make it easy to pay for this utility, how do we make it the expected way?

That requires establishing two clear standards.

For the vendor ecosystem, we need a sustainable participation standard. In Drupal, we have a contribution credit system to visibly recognize our Makers, those who invest real capital, code, and labor into the project. This system also helps us to identify the Fakers, organizations that use sponsorship and marketing to signal commitment while funding and doing little-to-none of the actual work.

For public institutions and enterprise users, we need a sustainable use standard defined by three practices:

• One, select vendors who sustainably participate in the projects they use.
• Two, include an explicit open source maintenance line item in every contract-a cost-recovery expense that shifts the burden off pro-bono maintainers.
• Three, require timely upstream release of all non-sensitive bug fixes and features.

With these standards in place, Open Source Program Offices can work with procurement officers to differentiate the true Makers from the Takers and Fakers at the point of purchase. And, the market-making power of public purchasing operationalizes "Public Money, Public Code" into the norm.

Open source cannot thrive on the margins of volunteerism, but it doesn't have to. Once public policy acknowledges open source maintenance as an operational cost rather than a charitable act, everything else follows. That's regenerative system design in practice: change the incentives, and the system begins to fund itself.

Adapted from a June 23, 2026 presentation by Tiffany Farriss at the Sovereign Tech Agency's Breakfast Reception during United Nations Open Source Week. Photo by Mike Gifford, licensed under CC BY-SA 4.0.

23 Jun 2026 4:49pm GMT

When we started working on the Drupal AI initiative in June 2025, I assumed most AI features would live inside Drupal.

By my DrupalCon Chicago keynote in March 2026, my thinking had changed. I framed the shift as "inside-out" versus "outside-in" and concluded that not every AI capability belongs inside Drupal. Some work is better done outside the CMS, where AI tools can move faster and connect back to Drupal when needed.

Last week, I explored these ideas in more detail in "AI and the great CMS unbundling". That post argued AI is making the CMS less central as a creation tool, but more important as a control layer: the place where content is structured, governed, reused, and published with trust.

This post picks up from there. If Drupal's role as the control layer is becoming more important, it needs to support AI-driven workflows that run inside Drupal, start outside Drupal, and move across both: external workflows that call into Drupal, and Drupal-native workflows that outside systems can safely rely on.

Drupal joins workflows beyond the CMS

First, Drupal needs to work well with tools outside the CMS: coding agents like Claude Code and Cursor, and orchestration platforms like Salesforce Agentforce, n8n, and Activepieces.

I actually showed what this could look like in my DrupalCon Vienna keynote in October 2025. Here is a short clip of that:

It was a proof of concept demo, and we had some fun with it. But the pattern behind the demo mattered more than the demo itself: an external tool drove the work and handed tasks to Drupal, while Drupal returned structured content and state.

Watch the demo, and it will be easy to imagine the same pattern in a real marketing use case. Campaigns usually begin with a marketing brief and span many tools and channels: email, website landing pages, social media, paid media, and more.

An external agentic platform could generate campaign copy and ask Drupal to build a landing page. Drupal could map the copy to the right structured content type, place it into approved components with Drupal Canvas, save a draft, and flag any fields, metadata, or translations still missing before it can publish.

If Drupal reports a missing hero image, the agentic platform could search the digital asset management system (DAM), find an approved campaign image, and hand it back. Drupal could then attach it through its media model, supply or verify the required alt-text, confirm the page meets its requirements, and advance the draft through the editorial workflow.

This is a pattern that Drupal will need to support well. External platforms can coordinate work across the broader digital stack, but Drupal should remain the system that assembles, validates, governs, and publishes the content.

External workflows call Drupal-native workflows

While the larger campaign workflow may live outside Drupal, there is an equally important case for Drupal-native workflows.

External agents are good at coordinating work across systems. But once a workflow needs to act on Drupal content or data, it should use Drupal's native content model, permissions, validation rules, moderation states, revisions, and publishing workflows rather than recreate them outside of Drupal.

That is where projects like ECA, FlowDrop, and Maestro become more important. They let Drupal turn site-specific processes into repeatable, multi-step workflows that outside systems can call.

For example, any of these three systems could power a single Drupal workflow that validates a draft, coordinates translations in five languages, assigns reviewers, and publishes the content only after all required approvals are complete.

Depending on the task, these internal Drupal workflows can be deterministic, AI-assisted, or fully agentic. Drupal can support that today.

An external agent should not have to manipulate Drupal from the outside, field by field or function by function. It should be able to ask Drupal to execute a Drupal-native workflow through a single external API call.

That is the other half of what I showed in the demo video above. Drupal was not just exposing content to an external agent. It was exposing custom Drupal-native ECA workflows that an external automation tool called.

That was powerful last fall at DrupalCon Vienna, but as agentic workflows become more common, this pattern will only grow in importance.

The best end-to-end experience will win

There is a natural tendency to debate what should live where. Should AI happen inside Drupal, or outside of it? Should workflows be Drupal-native, or managed by external platforms?

Those are useful questions, but the answer is not universal. AI and workflows should live where they create the best end-to-end experience. Sometimes that will be inside Drupal, sometimes outside Drupal, and often across both.

What "best" means depends on the use case, the user, and the requirements for speed, reliability, security, governance, cost, and human review. There will be best practices, but no single approach fits every case.

Who is doing the work shapes what "best" looks like:

• A developer may prefer an external coding agent like Claude Code.
• A marketer may prefer a Drupal-native experience that keeps them close to previews, translations, moderation, and publishing.
• A campaign manager may need an external workflow that coordinates email, social media, analytics, DAM, and CMS.

Work will move across systems and people. The best end-to-end experience will come from doing each step where it can be done best, while making the handoffs feel invisible.

A head start is not a plan to win

Understanding Drupal's role in these future workflows gives us clarity about where Drupal needs to go. Drupal needs to get better at supporting external orchestration, Drupal-native workflows, and the real-world hybrids that combine both.

What makes Drupal interesting is that it already has so much of the hard, unglamorous infrastructure these workflows need: structured content, granular permissions, revisions, rollback, JSON:API, and plenty more. These are exactly the capabilities agents need, and they're genuinely difficult to build well from scratch or retrofit.

Conceptual clarity and a strong foundation are wonderful things, but they are not enough to win.

When I asked whether AI coding agents would recommend Drupal, the issue was not Drupal's capability. It was whether agents could get from prompt to a working Drupal site quickly and easily enough. As I wrote in "Friction, abstraction and verification", agents tend to choose the path that gets them to a real, verified result with the least friction.

For experienced Drupal teams, the challenge is different. They have already chosen Drupal. They do not need an agent to recommend it. They need agents that help them build, validate, and ship quality work faster.

To turn Drupal's advantage into adoption, we need to improve both paths: helping agents choose Drupal for new builds, and helping existing Drupal teams ship better work faster. Both depend on making it easier for agents to work with Drupal from start to finish.

That means Drupal needs to expose the best practices, site context, tool definitions, constraints, and precise validation agents need to take the right actions and verify the result.

A lot of this is already underway across Recipes, Site Templates, Drupal AI, Drupal Canvas, ECA, FlowDrop, Maestro, MCP, and CLI improvements, to name a few.

But the goal is bigger than any one project. Drupal needs these efforts to add up to a clear, coordinated path for agents: from setup to connection, context, governed action, validation, recovery, and launch.

Special thanks to James Abrahams, Jürgen Haas, Randy Kolenko, Scott Falconer, and Shibin Das for their review and contributions to this blog post.

23 Jun 2026 1:47pm GMT

In this blog post we celebrate International Women in Engineering Day by interviewing Carine Bournez, W3C Principal and Team Contact who specializes in WebRTC, Web Performance, SVG and Data Shapes.

23 Jun 2026 12:32pm GMT

I Keep Evaluating Alternatives to Drupal. I Keep Choosing Drupal. Here Is the Actual Reasoning.

Why I Bother Looking at All

There is a failure mode among experienced developers where they defend their stack because switching would invalidate years of accumulated expertise. The sunk cost is real and the bias is real. The antidote is to take the alternatives seriously when the opportunity comes, build something real with them, and see whether they have caught up.

So when a project's requirements actually push me toward another tool, or when I am curious enough about a new one to spend real time on it, I do exactly that. I read the docs properly. I build a non-trivial prototype. I model a real content structure, not a blog with three fields. I look at what production would actually require. Then I compare honestly.

This post is the result of those evaluations. It is not a Drupal sales pitch. It is the reasoning of someone who has genuinely used the alternatives and keeps finding that, for the work I do, the decision still holds.

Where the Alternatives Are Genuinely Better

Let me start here, because a post that only praises Drupal is not credible.

The modern headless stacks are genuinely better at greenfield speed. If I am starting a small-to-medium project with a clean content model and a React frontend, Sanity or Payload will get me to a working state faster than Drupal will. The developer experience is smoother. The frontend integration is more natural. The mental overhead is lower. For a certain class of project, they are simply the better choice, and I have recommended them when that was the case.

Custom Next.js builds give you total control. No framework opinions to fight. No contrib modules to maintain. For a team with strong frontend engineers and a genuinely unusual set of requirements, building from scratch can be the right call.

These are real advantages. I am not going to pretend otherwise. If your project is greenfield, your content model is simple, and your team is React-native, the alternatives deserve serious consideration and might win.

Where They Keep Falling Short

Here is the pattern I keep hitting. The alternatives are excellent at greenfield and start to strain the moment the content model gets genuinely complex.

A blog with posts and authors is easy in any of these tools. A content structure with deeply nested relationships, polymorphic references, conditional fields, revision workflows across content types, and the kind of editorial complexity that real enterprise content demands is where the headless tools start showing their age, and where Drupal's entity and field system pulls ahead.

This is the single most consistent finding across every round of re-evaluation I have done. The tools that win the demo lose the complex content model. Drupal that loses the demo wins the complex content model. And in the kind of work I do, the content model is almost always complex.

The Four Reasons I Keep Choosing Drupal

When I strip away the noise, four things keep Drupal as my default for the work I actually do.

1. The content modeling is genuinely better

Drupal's entity and field system is the best content modeling foundation I have worked with, and I have worked with most of them. The ability to define content types with arbitrary fields, reference entities polymorphically, attach fields to anything, build view modes for different rendering contexts, and have all of it integrate cleanly with revisions, translations, and access control is not matched by the headless alternatives.

The headless tools model content as documents with schemas. That works beautifully until your content is not really document-shaped. Drupal models content as entities in a relational graph, which is harder to learn and more powerful when the structure gets complex. For the content I work with, that power is the difference between a clean implementation and a pile of workarounds.

2. Long-term maintenance and stability

I have Drupal sites I built years ago that still run, still update, still get security patches, and still make sense to a developer opening the codebase for the first time. The upgrade path from Drupal 8 forward has been genuinely good, and the project takes backward compatibility and security seriously in a way that matters when you are responsible for a site over years rather than months.

The headless ecosystem moves faster, which is exciting and also exhausting. Tools get acquired, change pricing, deprecate APIs, or simply lose momentum. Betting a long-lived enterprise site on a venture-funded SaaS CMS means betting on that company's roadmap and survival. Drupal is not going to get acquired and pivot. That stability has real value when the site needs to live for a decade.

3. Ecosystem and community depth

Twenty years of contrib modules, documentation, Stack Exchange answers, and accumulated community knowledge is a moat that is easy to undervalue until you need it. When I hit an unusual problem in Drupal, someone has almost certainly hit it before and written about it. The depth of the ecosystem means most problems are solved problems.

The newer tools have enthusiastic communities, but they do not have twenty years of accumulated edge-case solutions. When you hit the unusual problem in a younger ecosystem, you are often the first one there, which means you are solving it from scratch.

4. Migration and enterprise-scale capability

Drupal's Migrate API and its broader enterprise tooling (multilingual, workflow, content moderation, granular permissions, multisite) are built for the scale and complexity that enterprise content operations actually have. I have migrated large, messy, legacy content estates into Drupal, and the tooling for that work is mature in a way the alternatives have not matched.

When a project involves moving hundreds of thousands of pieces of content from a legacy system, with all the data-cleaning and field-mapping and URL-preservation that entails, Drupal has the tools and the patterns. Most of the alternatives assume you are starting fresh, because greenfield is where they shine.

What This Means in Practice

The honest synthesis is this. Drupal is not the right answer for every project, and I do not pretend it is. For greenfield projects with simple content models and React-native teams, the alternatives are often better and I will say so.

But for the work I actually do, which involves complex content models, enterprise requirements, long-lived sites, and frequently the migration of large legacy content estates, Drupal keeps winning the evaluation. Not because I am attached to it. Because every time I take the alternatives seriously and build something real with them, I hit the same wall: they are excellent until the content model gets hard, and then Drupal pulls ahead.

The decision is not "Drupal is best." The decision is "Drupal is best for this kind of work," and the kind of work I do keeps being that kind.

Closing Thought

The reason I stay aware of the alternatives is that the day one of them closes the gap on complex content modeling, long-term stability, and enterprise migration, I want to know about it before my competitors do. So far that day has not come. The headless tools keep getting better at the things they were already good at, and keep not solving the things Drupal is good at.

Maybe that changes. Maybe Payload or whatever comes next builds a content modeling system that matches Drupal's entity API while keeping the modern developer experience. If it does, I will notice, because I pay attention. Until then, the choice keeps making itself.

If you have moved from Drupal to one of the alternatives and it held up on a genuinely complex content model, I would be curious to hear about it. That is the case I keep expecting to find and keep not finding, and I would rather learn it from you than from losing a project.

23 Jun 2026 7:03am GMT

At the Brussels seminar on Human Rights and ICT Standardization, W3C contributed to the discussion on how human-rights principles can enter technical work while design choices are still open. The post connects Ethical Web Principles, accessibility, horizontal review, threat and harm modeling, and the practical cost of participation: making assumptions, impacts, and responsibilities visible before they become infrastructure.

22 Jun 2026 3:16pm GMT

On 14 May 2026 W3C held its Japan Member Meeting with presentations reflected the latest developments and offered valuable insights into future W3C activities. Following that, it hosted the "W3C in Japan 30th Anniversary Reception" with W3C members and also many alumni who have established shape W3C in Japan over the years.

25 May 2026 12:42pm GMT

On January 14, 2006, John Resig introduced a JavaScript library called jQuery at BarCamp in New York City. Now, 20 years later, the jQuery team is happy to announce the final release of jQuery 4.0.0. After a long development cycle and several pre-releases, jQuery 4.0.0 brings many improvements and modernizations. It is the first major … Continue reading →

18 Jan 2026 12:29am GMT

It's here! Almost. jQuery 4.0.0-rc.1 is now available. It's our way of saying, "we think this is ready; now poke it with many sticks". If nothing is found that requires a second release candidate, jQuery 4.0.0 final will follow. Please try out this release and let us know if you encounter any issues. A 4.0 … Continue reading →

11 Aug 2025 5:35pm GMT

Last February, we released the first beta of jQuery 4.0.0. We're now ready to release a second, and we expect a release candidate to come soon™. This release comes with a major rewrite to jQuery's testing infrastructure, which removed all deprecated or under-supported dependencies. But the main change that warranted a second beta was a … Continue reading →

17 Jul 2024 2:03pm GMT

When it comes to crafting an article, the headline is crucial for grabbing the reader's attention and enticing them to read further. In this post, I'll explore the 7 types of article headlines and provide examples for each using the subjects of product management, user experience design, and search engine optimization. 1. The Know-it-All The […]

The post 7 Types of Article Headlines: Craft the Perfect Title Every Time first appeared on Smiley Cat.

29 May 2023 10:20pm GMT

Product management is one of the most exciting and rewarding careers in the tech world. But it's also one of the most misunderstood and misrepresented. There are many myths and misconceptions that cloud the reality of what product managers do, how they do it, and what skills they need to succeed. In this blog post, […]

The post 5 Product Management Myths You Need to Stop Believing first appeared on Smiley Cat.

09 Apr 2023 5:28pm GMT

The role of a product manager is crucial to the success of any product. They are responsible for managing the entire product life cycle, from conceptualization to launch and beyond. A product manager must possess a unique blend of skills and qualities to be effective in their role. Strong strategic thinking A product manager must […]

The post The Key Strengths of the Best Product Managers first appeared on Smiley Cat.

11 Dec 2022 4:43pm GMT

Last week I helped the folks at ezSystems debug some APC problems they were having. The problems ended up being a 64bit architecture problem (they have uber-fast Opterons) and the bug is now fixed in 2.0.3.

Today I received Python & XML from them (off my Amazon wishlist). Thanks guys!

On a side note, my wishlist seems borked. The list I get when I search on my email address or name is not the same one I can edit when I log into the site.

01 Apr 2004 6:53pm GMT

1st of April 2004 get's to it's end and I guess it's time, to summarize the recent April fools a bit. Not that I think anyone in the world believes in them, but some were quite funny:

1. Changes to case sensitivity in PHP.
Alan Knowles announced that PHP will change to the studlyCase API and therefor will get everything broken by changing established functions.

2. IBM takes over Zend.
Myself hacked a little article about IBM taking over Zend to make PHP a compete of Java.

3. The first PHP virus has been seen.
Wasn't there one last year, too?

4. PHP has been overtaken by Micro$oft.
Mhhh... a little bit unreliable, if they had been taken over by IBM this morning... Maybe one should first look, what others wrote...

5. And finally, PHP4 and 5 showed their real faces...
Take a look at a phpinfo() output!

I guess I missed some, so feel free to comment on this entry, if you found another!

01 Apr 2004 5:49pm GMT

Symantec have a report of the virus here. I've yet to see any of the PHP news sites picking up on it but, using a virtual host account, managed to deliberately expose some PHP scripts to it. From examining the infected scripts, what's disturbing is once infected, every tim...

01 Apr 2004 12:19pm GMT