Bekers van mijn vijf oudste Nepenthes.

Trompetten van enkele Sarracenia.

10 Jul 2026 11:57pm GMT

En plots was er de drang om iets te schrijven. Het is niet nagelezen, het is gewoon mijn gedachtenstroom vandaag, op mijn blog. Klinkt het niet, dan botst het, en dat is ook oké!



fertiliteit

Ik kwam daarnet deze video tegen van de Financial Times:
https://www.youtube.com/watch?v=6lFXmDk-tps

Het gaat over de correlatie tussen smartphonegebruik en het aantal kinderen dat geboren wordt. Hun theorie is dat het aantal vrouwen dat kinderen krijgt daalt, omdat ze meer in de smartphone-influencer wereld leven dan dat ze mensen in levende lijve ontmoeten. Ze maken ook direct de stap naar meer zelfmoordgedachten bij hevig smartphonegebruik.

De paper zelf is van april dit jaar en kan je hier vinden (wel 63 bladzijden):
https://homepages.uc.edu/~moscoshn/Personal_webpage/papers/Smartphone_web.pdf

Ik ga ervan uit dat de cijfers kloppen, dat er inderdaad een correlatie is tussen het invoeren van de smartphone in een land, en de problematiek om een partner te vinden om kinderen mee op de wereld te zetten. En het klopt uiteraard dat iemand die verslaafd is aan Instagram/Tiktok/... een ander beeld heeft van 'de gewone mens' dan iemand die nooit naar deze media kijkt. Maar er is meer aan de hand.



veiligheid

Er is veel angst vandaag, meer dan in de jaren 80 toen de criminaliteit veel hoger lag. (Noot: Er zijn nu meer aangiftes van misbruik, maar het gebeurde vroeger wel vaker denk ik.) De media, zowel de klassieke als de sociale media, lijken mensen uitsluitend in emoties te duwen: bang, bedroefd, boos en soms een keer blij. Wees bang voor mannen, voor terrorisme, voor hoge prijzen. Bedroefd voor ongevallen met kindjes. Boos op Poetin en China, en Israel. Cijfers en statistieken tellen niet meer, de anekdotes vol emotie krijgen alle aandacht. Waar in de jaren 80 de krant nog schreef: "Er zijn 700 bedrijven failliet gegaan deze maand, en 900 nieuwe opgericht!" wordt alles na de komma vandaag niet vermeld. Mensen bang maken levert immers meer 'clicks' en 'views' op.

Zie bijvoorbeeld vandaag op VRTNWS over 'Marie' en 'Katrien', ik durf het geeneens te lezen na 'Valerie' enkele dagen geleden. Ik was kapot na dat Valerie-verhaal, zucht. Die journalist had dat wel verdomd goed geschreven, de beste horror kan er niet tegenop!! Dat soort gruwel verhalen voor vrouwen, veroorzaakt door mannen, is de laatste twintig jaar schering en inslag. Alsof het in mannen-genetica zit.

Lezen op eigen risico:
https://www.vrt.be/vrtnws/nl/2026/06/22/getuigenis-stiekem-genomen-naaktbeelden-fora-en-justitie/

Het deed me denken aan het huidige onveiligheidsgevoel dat (vooral jonge?) mensen hebben. Ja er was ook criminilateit en wreedheden en misbruik in de jaren 80, maar we zagen dat maar eenmaal per dag op TV, tijdens het nieuws om 19u30. Als dat al in het nieuws kwam. Vandaag de dag is er minder criminaliteit in België(*), maar al wie vaak op een smartphone kijkt (incluis de vrtnws app), wordt er wel veel meer mee geconfronteerd. De TV had natuurlijk ook dat effect, maar dat was toch veel langzamer, veel gradueler en jarenlang enkel 's avonds in familiale kring. De smartphone is er als je wakker wordt, als je op de WC zit, als je op de bus wacht, als je niet kan slapen, kortom altijd, en zeker al die tijd die je *alleen* doorbrengt.


(*) Ik vind geen goeie cijfers over de evolutie van het aantal misdrijven per jaar sinds de jaren 50-60-70-80 tot nu.
https://www.vrt.be/vrtnws/nl/2023/06/21/studie-nicc-criminaliteit-in-belgie-daalt/



vertrouwen

Toen ik pas mijn rijbewijs had (1989), heb ik honderden lifters meegenomen. Zo goed als altijd tieners, de helft of meer waren meisjes. Zeker in mijn unief periode dat ik vanuit Leuven vrienden afzette in Zoersel, en dus vrijdagavond laat via Sint-Antonius, Westmalle, Oostmalle naar Wechelderzande reed. Ik heb die rit zelden alleen moeten doen, en vaak waren dat leuke gesprekken. Ik had zelf ook jaren gelift, honderden keren meegereden met vreemden, nooit was er enige spanning. Ik heb in vreemde auto's gezeten terwijl de eigenaar een winkel binnen ging, sleutels erop of zelfs met draaiende motor. Dat vertrouwen hadden de volwassenen toen in een onbekende zestienjarige. Logisch dus dat ik een 'pay it forward' mentaliteit had toen ik zelf een rijbewijs had. Gisteren was een vriendin hier heel de dag klimaatvluchteling, die rijdt nog rond met haar auto. Ze zei dat het al twintig jaar geleden was dat ze nog een lifter had meegenomen. Er zijn ook gewoon geen lifters meer.



cancelcultuur

Er zijn uiteraard veel alternatieven zoals Uber/deelwagens/deel-whatever, maar toch. Dat soort vertrouwen in elkaar is weg. Maar dat heeft evenveel te maken met mobiliteit als met de smartphone. Toen wij vroeger 'uit' gingen was dat vaak naar fuiven van 'Union Servet' in Pulderbos/Westmalle/Sint-Antonius. Daar was je dan, op een fuif met een paar honderd mensen, maar ook met je vrienden, je buren, je klasgenoten, de mensen van de harmonie, ... m.a.w. je was in een super veilige omgeving. Je kon als vrouw het 'risico' nemen om met een stoere/stoute man te dansen want je wist dat als die iets te ver ging, dat zowel jouw vrienden als zijn vrienden tussenbeide zouden komen. Je hield elkaar in 't oog, wie gaat met wie buiten, je kende van vele mensen de ouders en wist waar ze woonden. (En die ouders kenden ook uw punten van uw laatste test Frans of wiskunde!)

Dat is op twee zaken een groot contrast met vandaag: Ten eerste ben je op een Tinder/Bumble/Breeze-date vaak alleen, in een vreemde omgeving, wat niet goed is voor je veiligheidsgevoel. Ten tweede is er de cancelcultuur en kan elke misstap leiden tot een eeuwige verbanning. Als op de Servet-fuiven vroeger iemand het uithing, dan kwamen zijn vrienden er wel tussen, en waren die slecht gezind op hem, of toch ene, omdat die hem naar huis moest brengen en dus vroeger weg was van de fuif. Maar... die gast kwam de week nadien wel terug, en kon daarbij aantonen dat die zich wel kon gedragen en nen toffe zijn en een lief vinden.



smartphone

Ligt dat aan de smartphone? De smartphone kan handig en nuttig zijn, zonder schadelijk te zijn. Je kan er je busabbonement op zetten, allerhande betalingen mee doen, mooie foto's nemen, je agenda erin zetten, je moeder mee bellen, de weg naar elkaar vinden in de stad, een taal studeren, boodschappenlijst in spreken, en nog een dozijn andere leuke, toffe, boeiende, leerzame, nuttige dingen.

Maar dat wordt, in uren per app gerekend, nauwelijks gedaan. Of dat is toch wat ik zie als ik eens in de bus of in den tram zit, of in een wachtzaal. Ik zie mensen scrollen, scrollen, scrollen, door een eindeloze scroll van video's, drie a vijf seconden per video en hup devolgende, video's die absoluut niks te maken hebben met hun familie, hun vrienden, of uberhaupt enige link hebben met echte mensen. Gooi er nog een hoop reklame tussen (mooi in beeld gebracht hier: https://youtu.be/e9dZQelULDk?t=141 ). En ja, dan leef je niet langer in een wereld van gewone mensen, dan leef je in een fantasie.



doemscenario

Is dat erg? Is de wereld naar de knoppen? Nee dat denk ik niet. Al wat hierboven staat, verraadt gewoon mijn leeftijd. Het is van alle tijden dat ouderen zeggen dat de wereld naar de knoppen is, dat kinderen niet meer luisteren naar hun ouders, dat regels niet meer gevolgd worden.

Nee, onderschat de jeugd niet, die overleven dat wel. Het is een nieuwe wereld, eentje die angst inboezemt, maar het komt wel goed. Dingen veranderen nu eenmaal, en dat geldt ook voor die overweldigende verslaving aan sociale media op de smartphone: op een dag is dat gedaan. Vandaag niet, morgen waarschijnlijk ook niet, maar op een dag is dat geschiedenis en gaan mensen weer bij elkaar zitten.

Het ging even heel snel en dan heb ik het niet over de nieuwe technologie, maar over de nieuwe verslaving aan sociale media. Deze verslaving heeft iedereen op snelheid gepakt, en de impact is enorm, zowel op wereldvlak als in persoonlijke interacties met mensen. Ik geloof dat het omgekeerde ook kan. Ik geloof dat mensen in staat zijn, op een dag, om die smartphone te gebruiken voor de nuttige en leuke dingen, en niet meer om oneindig te scrollen in een fake wereld.

10 Jul 2026 11:57pm GMT

We watch websites for a living at Oh Dear , which puts us in a unique position: we have data on a lot of different outages.

10 Jul 2026 11:57pm GMT

I've been moving our CI off GitHub-hosted runners onto our own arm64 hardware. The plan was straightforward: a pool of ephemeral runners on a dedicated CI box, and each test shard spins up its own MySQL, Redis, and ClickHouse as service containers, all under rootless Docker.

10 Jul 2026 11:57pm GMT

Un petit mot de nos sponsors…

Comme pour les stades ou les équipes cyclistes, il est important de nommer les vagues de chaleur et les canicules selon les sponsors qui ont rendu cela possible. C'est après tout la moindre des choses.

Ne dites plus « la vague de chaleur de mai 2026 » ou « la canicule de juin 2026 » mais « la canicule Bolloré 26 » et « la canicule TotalEnergies 26 ».

Avouez que « TotalEnergies 26 a déjà fait 115 morts » en gras dans la presse, ça fournit une belle visibilité médiatique au sponsor !

Du coup, Patlabar s'est improvisé public-reléchionne pour les sponsors et a fait de chouettes stickers à imprimer et à coller là où le rappel est le plus utile. J'espère qu'il va leur envoyer sa facture.

La canicule de juin 2026 vous a été offerte par TotalEnergies.

Il a également fait les stickers pour celle de mai :

La canicule de mai 2026 vous a été offerte par Bolloré.

Et il prévoit déjà celle de juillet :

La canicule de juillet 2026 vous a été offerte par Lafarge.

En 2026, TotalEnergies a clairement écrasé Bolloré. Lafarge pourra-t-elle tenir le niveau ? Rien n'est moins sûr, les supporters lancent déjà les paris.

Pour les prochains stickers, vous pouvez suivre Patlabar sur Mastodon:

• @patlabar sur Mastodon

PS: À propos de sponsor, l'équipe cycliste Israël-Startup Nation avait, en 2025, subit les foudres du public sur la Vuelta, entraînant son retrait de l'épreuve et le changement de sponsor pour 2026. Je me demande si on verra un jour des protestations similaires pour des équipes comme TotalEnergie ou Uno-X, qui sponsorisent le vélo en vendant de l'essence.

10 Jul 2026 11:57pm GMT

This is the seventh installment of a series of posts about taking back control of my web presence. In Part 1 I tackle hosting, in Part 2 I do things with DNS. In Part 3 I rediscover Proxmox, in Part 4 I move Mastodon around. In Part 5 I Tunnel All The Things with Pangolin and in Part 6 I sort out where to store code.

As I detailed in my previous posts, I used Let's Encrypt. But, as the astute reader can see, I've been wanting to reduce my dependency on non-European companies.

Let's Encrypt was not high on the list of things to replace - it's free, it works and it is a force for good. It being under US jurisdiction felt mildly annoying.

I recently came across Actalis, a company based in Italy that offers a free plan where you can get unlimited SSL certificates for domain validation via ACME.

Switching my stack over was as simple as registering an account and adding this to my Caddy configuration:

email my-email-address@domain.tld
acme_ca https://acme-api.actalis.com/acme/directory
acme_eab {
  key_id XxxxxxArihquYoJxxxxxx
  mac_key yyyyyyyyKPXMgkkxxxxxxLQaIuGhHQbbbbbb
}

(You'll find both values in the Actalis console.)

After reloading Caddy, I got an error: "Obtain: base64-decoding MAC key: illegal base64 data at input byte 43". A quick search taught me that I had to remove the padding (=) from mac_key.

I also had to update my Certificate Authority Authorization (CAA) DNS records to include issue "actalis.it".

A caddy reload later, my sites were serving Actalis certificates.

10 Jul 2026 11:57pm GMT

MariaDB 13.1 is a rolling release preview, and, as usual, this is the right moment to test what is coming, give feedback, and help us polish the next MariaDB Server release. But this time, there is something really interesting. And by "interesting", I mean: wow! MariaDB 13.1 Preview includes 32 MDEVs with new features and […]

10 Jul 2026 11:57pm GMT

During the last MariaDB Foundation Board Meeting (24 June 2026), Barry shared how it can be difficult to deploy an upgrade immediately and that they sometimes have to wait for one that fixes security bugs. Wait for the validation, wait for the fix, and the release. Even if the MariaDB engineers are doing incredible work, […]

10 Jul 2026 11:57pm GMT

MariaDB 13.1 Preview is full of nice things. Some are immediately visible to developers, like the new JSON operators. Some are very useful to DBAs, such as configuration validation. And some are about making security and access control easier to manage. Today, let's look at one of those: DENY, also known as negative grants. Yes, […]

10 Jul 2026 11:57pm GMT

MariaDB Server has long supported a flexible plugin architecture. Plugins allow developers to extend server functionality in areas such as data types, auditing, storage engines, information schema tables, and more. Today, MariaDB Server plugins are typically developed in C or C++, like the server's codebase. At least for a while Even with the current plugin-writing […]

10 Jul 2026 11:57pm GMT

Back in 2019, I wrote that Open Source is not a meritocracy. Meritocracy says talent is the only thing that counts, but that is not true. To contribute, you also need time, a steady income, and a flexible schedule. Plenty of people lack one or more of these.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10 Jul 2026 11:57pm GMT

Open Source won the technical argument a long time ago. But it still hasn't solved the funding and sustainability problem, one I've spent much of my career chipping away at.

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

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

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

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

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

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

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

Listen to the episode.

10 Jul 2026 11:57pm GMT

Near the end of most Open Source licenses, usually in capital letters, sits a clause that disclaims almost everything: no warranty, no liability, use at your own risk.

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.

10 Jul 2026 11:57pm GMT

Earlier this week, in "Drupal's role in agentic workflows", I argued that Drupal's AI future has two parts: helping people with AI inside Drupal, and helping agents use Drupal from the outside.

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.

10 Jul 2026 11:57pm 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.

10 Jul 2026 11:57pm GMT

The most common question founders ask me is "What's your opinion on rug-pulls and license changes?" My answer is that community backlash and controversy are often exaggerated, that license changes are not automatically bad, and that they should be used for the occasional harmonious re-calibration.

So let's look at relicensing, why it makes sense, when it goes wrong, and how to do it gracefully. I will include some lessons learned from our relicensing projects at Grafana Labs, though this blog post represents only my own opinion and not those of my past employer, Grafana Labs.

What is relicensing?

Note that we are talking about enterprise software (B2B) only here. B2C is different, and I have little experience with it.

Let's dig into this, but first we need to address some misconceptions and friction points:

• License changes are always "going forward": any code released under some license can't be taken back. A more practical way to think about relicensing is as a fork:
  • the company stops maintaining the code base. It's practically abandoned. Because it was unsustainable.
  • a company sees a path to save the community and project (though under a different license), so they step up and fork the project to continue it. It just so happens that this company is the same as the previous one, so they can keep the name, the established commercial support system (though sometimes under a new pricing structure), the existing repo, build systems, issue tracker, etc. Which makes the fork more seamless.
• Any person or company is free to reduce or terminate their efforts in any open source project. By law, they only have to honor their commercial agreements.
• The only reason they can fork the project and apply a new license, is because it is their full legal right. Usually they've had that right for years, and have full discretion about when they apply it. If you are a consumer of open source and this comes as a sudden, shocking surprise, it should make you reflect on how well you understand the products and services you have chosen to depend on, above all.

Perhaps this makes it sound more palatable. In case it doesn't, let's consider some events that probably have happened to you:

• A commercial service/product you depend on becomes decommissioned, bankrupt, too expensive, or is no longer the best solution.
• An open source project you depend on becomes unmaintained, too expensive, or is no longer the best solution.

Anyone who's been in technology for a while, will encounter these scenarios routinely. It's the reality of using commercial products that live in an economic market or non-commercial projects that depend on the spare time and goodwill of individuals. Mature engineers or tech executives will deal with them without much fuss. Migrations can be annoying or painful, but usually don't cause an outrage. They are considered part of the job. You will migrate to an alternative solution; supported by an existing vendor, a new vendor, a different community, your team, or a combination. Smart engineers and executives will build a tech stack specifically designed to handle these scenarios elegantly, with abstractions in place, to keep the door open for eventual migrations. Any mature team will thoroughly consider exactly these ramifications when building upon a technology that locks them in.

A relicensing event is like any of the above, but with some positive differences:

• renewed trust that your vendor will remain in business (unless they do something incredibly stupid)
• instead of being forced to find and implement an alternative, you are offered an additional solution, one which doesn't require a migration, doesn't impact your tech stack, your team's planning and has minimal impact to your existing commercial and customer support relationship with your vendor.

When relicensing goes wrong (the "rug-pull")

So, how is it that relicensing events cause controversies, when in fact they are easier to deal with than the more disruptive events which we somehow tolerate better?

I think there are multiple contributing factors, that become deadly when combined:

1) The community feels misled and betrayed

This is usually when they were asked to sign a CLA in which they had to hand over ownership or distribution rights of their contributions, especially so when they were led to believe "it's fine because the license is permissive and we won't change that". Signing such a CLA is your clue that a license change will happen. Not a matter of "if", but "when". Note, I'm not unequivocally saying CLA's are bad. I think empowering a vendor can be a good thing. As a contributor, you simply need to not be naive about the future. As a community, you need to be aware you can always fork. Whether before or after the CLA requirement, or before or after a relicensing event. But forking only works when you can put together a community of skilled engineers and can truly produce a better package. Those are the rules of the open source game.

2) The event comes with pricing increases or features moved from previously free/open to paid/closed.

Speaks for itself.

3) The new license is - or appears - too aggressive.

Different communities and individuals will tolerate different things dependent on what they're used to. The OSI has a long legacy in maintaining and defending the most formal and widely accepted definition of "open source". While it's been disputed by myself and by many others, it is the most widely accepted one. Nowadays, using the words "open source" around a non-OSI approved license stirs up religious wars without clear winners. Businesses may avoid or proceed doing this depending on their appetite for media controversies.

Regardless:

• Many users swear by OSI-approved licenses (even if it's only as an open core, wrapped by closed proprietary code). Part of the reason, I think, why our relicensing from apache to AGPL at Grafana was successful and generally pretty well received, is that we stuck with an OSI-approved license, even though we retained the open core model. Sometimes you just need to give people what they want.

• Personally I think there are a lot of interesting Source-Available options such as Fair Source which strike a better balance between the rights of both the vendor and its community than open core with an OSI-approved license in the center only. It seems some communities are slowly warming up to these solutions, though education around it is critical, and the progress is slow. But ultimately your community of users and customers is the final judge.

4) Intentionally vague or incorrect announcements

Some vendors actively try to mislead their users and customers. Throwing buzzwords like "open" around in a confusing soup of words is not good for your users, and therefore for your business.

5) The change feels all "take" and no "give".

For example, Grafana Labs didn't just fork the Apache licensed Cortex database into AGPL licensed Mimir, we also made sure to open up previously-proprietary functionality into the new open source project. As part of this relicensing we raised the bar for what we considered "enterprise only" and opened up everything that no longer met this new bar. I believe this shows respect to your community and is required for successful business long term. Relicensing should be more about "how can we improve the interests of both parties". A company thinking of a relicensing as a one-way street undermines its own business.

Cynical observers may note that perhaps the trick is to always "juice up" a fat shell of proprietary features when using a permissive open core, just to have something to give to offset a relicensing, but I think it speaks to always seeking the right balance: if you use a permissive license, you need more proprietary features; when you make the license more protective, you can and should include some of those features.

6) Just the fact that there is a change.

I have also learned that sometimes it's just the fact that something is changing, not the actual thing, that causes some uproar. When we started Grafana Labs in 2015, our first metrics database - Metrictank - was AGPL licensed from the start, which never caused an issue. Years later, when we forked the 2nd metrics database we worked on - Cortex - into Mimir and switched from Apache to AGPL for it, we forgot to mention that as part of this transition we were deprecating Metrictank, and merging its best already-AGPL features into (the easier to deploy) Mimir. That could have reduced the (already small) commotion a bit.

Relicensing is inevitable. But market forces dictate the only way to do it, is to do it right.

As a vendor who controls open source software projects, you don't play in a vacuum. You are beholden to a lot of external forces. There's constant changes in market conditions, sentiments and best practices, financing opportunities, competitors gaining or losing strength, cloud vendors giving you more credibility or threatening your business, shifts in available technology, M&A opportunities, talent, export controls etc.

Inevitably, you need to periodically re-assess and adjust every process in your business. E.g. your ICP (Ideal Customer Profile), GTM (Go-To-Market), your offering, support, team structure, partnerships, vendors, etc. The only constant is change. The more a change is externally facing / customer-impacting, the more deliberate and careful you should be - to minimize disruptions - but beyond that, relicensing is in principle not all that different from other inevitable changes you need to make.

Ultimately, everything you do, your reputation, the quality and pricing of your offering, the quality of your communication, the appeal of the open source project, etc boils down to an overall "score":

• Are you too aggressive or expensive? Somebody will fork and/or lure your customers away with an alternative.
• Are you not aggressive or expensive enough? You won't be able to defend your business, and will be overtaken by someone who can build something better (possibly a fork)

For vendors, this means you will only do well if you hit the sweet spot. You should always aim to provide a balanced offering and treat customers right. A relicensing event is not an opportunity to become more aggressive. The laws of business don't change, you need to retain a compelling offering.

For customers, it means whichever vendor gives you the best overall experience will serve you. Hopefully, it remains the same vendor. That's easiest for everyone. But if you are "mistreated" by a rug-pull (or by other moves the vendors make that you don't like), there will be short term and medium term turbulences (e.g. due to lock-in, painful migrations, compliance constraints, procurement/legal friction, etc), but eventually, the market rebalances. There are strong market forces nudging vendors to treat customers right; if they don't, another one will.

It also means that the only reason to do a relicensing is to make customers more happy on the long term. The happier you can make your customer, the better your business will be. If you upset your customers, the worse your business will be. Any badly received relicensing event is from vendors who think it's OK to upset this balance because they have the lock-in or the market sentiment. Short term they may be right, but long term, they are wrong. Even if short term they are able to grow profits and re-invest into their projects and offerings, the burned trust is never worth it.

Relicensing can be good: from permissive to protective.

The playbook seen among many commercial open source vendors is to start with a permissive license (apache2/BSD/MIT) and later relicense to something more protective. It is often said that this is "bad" or a de-facto rug-pull. I think this is faulty thinking. Grafana - and a few other companies - show that it's possible to relicense gracefully, though it's a tricky maneuver. There are more examples of relicensing gone wrong, but those often also involved bad communication and overly aggressive changes such as non-OSI-approved licenses.

I would go further and say this can be a good model worth designing for.

Early on, you want to boost adoption and remove restrictions. This grows community, adoption, and helps with testing and validating a market. This is good for users, the vendor, and early customers. Later on, the code is relicensed (assuming CLA's are in place, although now with AI things are changing). This allows the vendor to protect its business. Community members are often quick to complain about the "rights lost", but here the bigger picture still matters. If the vendor can protect its business better, it can invest and grow the open source project better. We saw above how limited their ability is to abuse any "rights gained" over the long term. In many cases, users and community end up better off: either the original vendor serves them better, or they are better served by a fork or competitor.

How to relicense?

Relicensing can be done in a way that isn't seen as a "rug-pull", but instead as a "cleaning house". A transformative make-over that leaves everybody happier.

Here are my tips:

• Try to avoid it by choosing a balanced license from the start, but better change something down the road than have analysis paralysis. Especially when getting started.
• Treat your community and customers with respect. Trust takes years to build, seconds to break, and forever to repair
• Never make promises you can't keep. Don't claim you will never relicense.
• Talk with your community. Figure out their licensing preferences. See how they react to license changes in neighboring projects.
• Communicate clearly. Whether it's about CLA's or new licenses, especially if they are novel or not OSI compliant. If going for Source-Available type licenses, truthfully educate your community about your real intentions and goals, and the implications of the chosen license. Anything less will backfire.
• If not using OSI-approved licenses, either steer clear of "open source" definition debates altogether, or leverage the inevitable debates between those who follow the OSD and those who don't. Pick your poison here :-)
• Consider the "giving" part as much as the "taking" part. Happy customer == Good business.

Finally, and this is actually how I usually start my consulting engagements: ask yourself if you really want to be an open source company and why. Open Source businesses are about "growing the pie" (creating more value, growing a community around a sustainable project), and consuming a small or tiny portion of that pie (capturing some of the value). Restricting previously free features is not a long-term smart move. It undermines or reverses the growth of the pie, and you then need to consume ever-growing chunks of it. This is not an OSS business based on growth. It's a proprietary business. Which by itself is not "wrong" (though I believe COSS leads to more successful businesses), but it is a very tough pivot and one worth avoiding. Especially as it relates to "cloud vendors eating our lunch". You enabled them to legally do it, it's literally how you built your business. Deal with it, gracefully, or someone else will.

10 Jul 2026 11:57pm GMT