PARTY TIME!

I removed the Node.js component from my configuration management repository yesterday.

Not because of some grand redesign. I deleted a reusable GitHub Action, and then realized it was the only reason Node.js was still hanging around.

The repository is Ansible, YAML, shell scripts, and a bit of Python. No JavaScript. No TypeScript. Yet somehow I was still carrying a Node.js toolchain, npm dependencies, and CI jobs that no longer served a purpose.

So out they went.

As a bonus, I also retired an old ESLint workflow. No JavaScript means no need to lint JavaScript.

Simple.

I’ll admit I’ve never been a fan of dependency-heavy ecosystems. If I actually need the functionality, that’s fine. But if a dependency tree exists purely because of historical baggage, I’d rather remove it than maintain it.

The result?

• One less runtime
• One less workflow
• Fewer dependencies
• Less attack surface
• Less maintenance

The repository is now a little smaller, a little simpler, and a little more boring.
In infrastructure work, boring is usually a compliment.

Sometimes the best improvement isn’t adding something new.
It’s deleting something you no longer need.

So here’s to unnecessary dependencies:
May they rest in peace.

And to Node.js:

Thank you for your service. Please don’t let the door hit you on the way out.

Dependency updates are one of those areas where AI is often presented as an obvious win. But when you look closely, the value proposition can be surprisingly thin.

Every few months I find myself looking at a piece of automation I wrote and asking a dangerous question:

“If I deleted this today, would I miss it?”

Recently that question came up while looking at some code that uses AI to assist with commit messages for automatic dependency updates.

It’s undeniably cool. And if we’re being honest, “cool” has probably justified more engineering decisions than we’d like to admit. Somewhere, a developer is about to spend three days adding AI to a workflow that already takes five seconds, and nobody is stopping them.

When a bot updates a dependency, AI can inspect the diff, generate a polished commit message, summarize release notes, estimate risk, and even draft a pull request description. Give it another six months and it’ll probably offer unsolicited opinions about my coding style, too. Beep-boop-beep-beep.

But do I actually need any of that?
For dependency updates specifically, I’m not convinced.

The Diff Already Explains Everything

Most dependency update pull requests are boring.
That’s not a criticism. Boring is good. In fact, “boring” is one of my favorite qualities in infrastructure. Right up there with “predictable”, “consistent”, and “unlikely to trigger a sensory response.”

A typical update looks like this:

- Newtonsoft.Json 13.0.2
+ Newtonsoft.Json 13.0.3

Or:

- actions/checkout@v3
+ actions/checkout@v4

The dependency changed. The version changed. The automated tests passed.
What more needs to be said?

An AI-generated commit message such as:

Update Newtonsoft.Json from 13.0.2 to 13.0.3 to incorporate the latest improvements and fixes.

is objectively more polished than:

chore: update thing

and considerably less polished than the commit messages written by developers who own more than one ergonomic keyboard.

But it doesn’t add information.
It’s merely a longer version of the diff.

The Cost of Automating the Obvious

AI systems are not free.

Even when the direct cost is negligible, there is still operational complexity:

• Prompt engineering
• API keys
• Rate limiting
• Error handling
• Monitoring
• Dependency on external services
• Additional maintenance burden

For a feature whose main purpose is generating text that developers may never read, that’s a surprisingly long list.

The irony is hard to ignore.
I’m adding dependencies to manage dependency updates.

Most Dependency Updates Require Validation, Not Summarization

The real value in dependency management isn’t explaining what changed.
It’s determining whether the change is safe.

Questions such as:

• Did tests pass?
• Are there breaking changes?
• Did security vulnerabilities disappear?
• Has runtime behavior changed?
• Should this be rolled out gradually?

Those are useful questions.
An automatically generated paragraph of prose is not.

If I had to choose between:

• AI-generated release summaries
• Better test coverage

I’d take better tests every time.

Where AI Actually Helps

To be clear, I’m not arguing that AI is useless in dependency management.
There are situations where it genuinely provides value.

For example:

Large Version Jumps

Updating from:

React 17 -> React 19

is not the same as:

React 19.1.0 -> 19.1.1

That’s the difference between “let’s merge this before lunch” and “let’s spend the next three hours reading documentation for fun.”

The first update may involve deprecations, migration guides, and behavioral changes spread across hundreds of pages of documentation.
Having AI summarize those changes can save time.

Dependency Investigation

When a vulnerability appears in a transitive dependency, AI can help answer questions like:

• Why do I have this package?
• Which component pulls it in?
• What are my upgrade options?

That’s actual analysis.

Pull Request Triage

In environments processing hundreds of updates per week, AI can prioritize and categorize changes:

• Security-related
• Major version updates
• Low-risk patch releases
• Updates requiring manual review

Again, this is valuable because it’s helping people make decisions.

The “Because We Can” Trap

One of the easiest mistakes in engineering is automating something because it is technically possible. AI makes this temptation even stronger.

You add a model call.
The output looks impressive.
Everyone nods.
Nobody wants to ask whether the feature is genuinely useful. Which is ironic, because asking uncomfortable questions is usually how I ended up adding the feature in the first place.

Six months later nobody reads the generated text, nobody remembers why it exists, and the system is carrying around a feature whose primary function is making demos more interesting.

That’s usually the moment when the dangerous question returns:

“What would happen if I deleted this?”

If the answer is “nothing,” deletion should be a serious option.

Simplicity Is a Feature

The software industry currently has a tendency to ask:

“How can we add AI to this?”

A more useful question is:

“What problem exists that AI uniquely solves?”

For routine dependency updates, I’m not sure there is much of a problem to solve.

• A dependency bot opens a pull request.
• The diff shows the change.
• CI validates the result.
• Humans review anything important.

That’s already a remarkably effective system.

The AI-generated commit message may be neat. It may even spark a ten-minute discussion about style, consistency, and aesthetics that is somehow completely unrelated to dependency management. But aesthetically pleasing is not the same thing as necessity.

And sometimes the best engineering decision is not building something new.
Sometimes it’s deleting code and discovering that nothing got worse.

Maybe Open Source Instead of Delete?

Just because I’m questioning a feature’s place in my workflow doesn’t mean the code itself has no value.

What started as an experiment in AI-generated commit messages evolved into a working GitHub Action. It takes a diff, calls an LLM, and produces a commit message that is often more polished than what most developers would write themselves.

The question isn’t whether it works. The question is whether it solves a problem I still have. For routine dependency updates, I increasingly think the answer is “not really.”

For routine dependency updates, the diff already tells the story. The generated explanation rarely influences whether I merge a change. Most of my confidence still comes from test results, release notes, and experience with the dependency itself.

But that doesn’t mean the idea is universally useless.

Some teams maintain hundreds of repositories. Some want consistent commit messages. Some value automated summaries and release notes. Others simply enjoy experimenting with AI-assisted workflows.

So rather than keeping an optional AI component embedded in a critical workflow, I have extracted it into its own repository and made it public on GitHub:

https://github.com/amedee/ai-commit-message

That has a few benefits:

• My dependency update process stays simple.
• The action remains available for anyone who finds it useful.
• Future development can happen independently.
• The project can stand on its own merits. Or fail gloriously on its own merits. Open source is wonderfully impartial that way. Besides, releasing a side project to the public is significantly cheaper than buying another keyboard, graphics card, or suspiciously expensive cardigan.

In a way, open-sourcing it feels like a more honest outcome than quietly keeping it around forever. If the idea is genuinely useful, people will adopt it. If not, that’s valuable feedback too. I’ve spent enough time collecting niche interests to know that “a surprisingly specific audience of twelve people” can still be a community.

Sometimes publishing a project is the fastest way to discover whether you’ve built a product, a feature, or simply an interesting experiment.

Not because I’m convinced AI-generated commit messages are essential, but because software doesn’t have to be essential to be useful. Sometimes an experiment is worth sharing even after you’ve decided not to keep it in production.

Worst case, it becomes a small open-source artifact of a particular moment in the industry’s AI enthusiasm.

Best case, somebody finds a use for it that I never did.

A Note on How This Post Was Written

Some honest truth: was this blog post (co-)written by AI?

Yes.

I gave Copilot (don’t shoot me! I also use other Large Language Models) an abstract, a rough outline of the argument I wanted to make, and the source code of the GitHub Action discussed in this article. It generated an initial draft. Which, to be fair, is also how I approach many hobbies: start with an overwhelming amount of information and then spend hours reorganizing it until it feels right.

After that, though, the process looked a lot like editing any other piece of writing. I rewrote sections, changed wording, moved paragraphs around, added examples, removed points that didn’t fit, and generally shaped the article into something that reflects my own opinion. In other words, the AI produced a draft and I spent the rest of the time refining presentation details until they felt correct. If that process sounds familiar, no further questions.

I can’t escape the irony of using AI to help write a blog post that questions whether AI is needed for a particular problem.

That irony is intentional.
In fact, it reinforces the point I’m trying to make.

The problem was never “AI bad” versus “AI good”. The question is whether AI adds enough value to justify its complexity. For writing, brainstorming, editing, and turning rough ideas into a first draft, I often find that it does. For generating commit messages for routine dependency updates, I’m much less convinced.

AI helped me write this post faster.
I’m not sure it helped me review dependency updates any better.

And that distinction is precisely why this blog post exists.

Snapkin is live on iPhone and Android. 😄

For the past few months, I’ve been working on a calorie tracker. I originally built it just for me.

Ah ouais, quand même, on en est là !

À ce point immergé dans notre propre stupidité.

Durant la dernière vague de chaleur, je suis tombé sur un article dans la presse nationale belge vantant les mérites d’une application permettant de mieux survivre à la canicule. Il suffisait d’entrer sa position et quelques données techniques sur son habitation (volume, type d’isolant, exposition…) et l’application vous disait quand ouvrir et fermer vos fenêtres pour garder un maximum de fraîcheur.

Cet article m’a frappé. Ni le journaliste ni l’auteur de l’app ne se rendait compte à quel point le principe était complètement irrémédiablement débile. D’une connerie sans nom.

Car, pour conserver autant que possible la température de votre logement, il suffit de tout fermer quand l’air est plus chaud dehors et de tout ouvrir quand l’air est plus frais dehors. Si vous avez deux thermomètres, le tour est joué.

J’ai beau me creuser la tête, je n’arrive pas à trouver un seul cas de figure différent. Et si un cas très spécifique existe (baie vitrée par exemple), ce n’est pas une app qui va pouvoir vous aider.

Dans l’article, l’auteur de l’application reconnaissait n’avoir aucune formation de développeur et d’avoir « vibecodé » tout le bazar. Lui-même n’a donc aucune idée de comment fonctionne son app, même approximativement. Et le résultat est là : sans avoir testé l’app moi-même, je peux garantir que l’app ne fonctionne pas, qu’elle ne fait qu’afficher des recommandations purement aléatoires.

Et le journaliste ne s’est posé aucune question.

Ah ouais, quand même, on en est là !

Un outil pour les idiots

Si le créateur de l’app avait été un entrepreneur et avait engagé un développeur, il aurait été forcé de se confronter à des questions telles que « sur quelles bases scientifiques nous basons-nous pour le calcul ? ». Mais, grâce aux chatbots, plus besoin de cela. On peut désormais faire semblant de réaliser nos idées les plus stupides sans garde-fou. Je dis bien « faire semblant » car, comme le prouve l’exemple, au final cela ne marche pas.

Comme le dit Cory Doctorow: les patrons adorent les chatbots non parce qu’ils font le travail, mais parce qu’ils disent toujours oui et trouvent toutes vos idées géniales. C’est peut-être pour ça que je n’aime pas les chatbots: quand quelqu’un trouve toutes mes idées géniales, je me dis qu’il réfléchit encore moins que moi au sujet !

Un autre cas avait fait le buzz : une personne qui avait patiemment développé une app à travers ChatGPT, pendant des semaines. App qu’elle demandait à ChatGPT de faire tourner pour la déboguer à travers des captures d’écran générées par ChatGPT. Au final, quand cette personne avait voulu accéder au code source, ChatGPT avait fini par reconnaître qu’il n’y avait pas d’app, pas de code source, que tout était inventé en direct.

Cory Doctorow a mis le doigt sur un point crucial de cette bulle IA : si les chatbots devaient soudainement disparaître demain, rien ne changerait à part quelques collégiens qui devraient réapprendre à copier les uns sur les autres pour leurs devoirs. Les états s’empressent de vouloir développer une « IA souveraine », mais si demain Trump bloquait ChatGPT et Claude dans toute l’Europe, l’impact serait nul. Voire positifs argueront certains.

• Pluralistic: Why businesses lie about AI (01 Aug 2026) (pluralistic.net)

Comparez cela au chaos total si, soudainement, Trump bloquait Outlook, Whatsapp ou Gmail dans toute l’Europe.

Non, l’IA n’est pas la nouvelle bulle Internet

Comme le dit Cory, la bulle Internet s’est construite sur des employés qui voulaient utiliser Internet pour être plus efficaces alors que leurs patrons leur interdisaient. Des milliers de nouvelles entreprises apparaissaient chaque jour pour tenter de coloniser ce nouvel espace. La bulle IA, au contraire, est imposée par les patrons et j’ai déjà entendu de première main des témoignages de gens qui prétendent que le code qu’ils ont écrit manuellement a été généré, juste pour faire plaisir à leur boss. Certains des employés m’ont personnellement raconté faire tourner les chatbots sur des questions sans intérêt juste pour montrer à leur patron qu’ils ont utilisé des tokens.

Une personne a même reçu une réprimande pour n’avoir pas utilisé assez de tokens. Donc pour avoir fait son travail en utilisant moins d’argent que prévu.

Ah ouais, quand même, on en est là !

Et, malgré tout le ramdam, nous n’avons pas encore la moindre success-story d’une entreprise qui aurait fait fortune grâce à un produit au moins partiellement conçu par l’IA.

Si l’IA était une ruée vers l’or, des milliards seraient utilisés pour nous convaincre que les nouvelles pelles intelligentes sont la panacée, les blogs seraient remplis de témoignages comme quoi la pelle intelligente fait vraiment gagner du temps pour planter ses bégonias dans son jardin de banlieue, mais personne n’aurait encore trouvé la moindre pépite d’or. Toute la bulle tiendrait sur le fait que « Vu comme on creuse, on va forcément trouver de l’or et si un jour on trouve de l’or, mieux vaut être habitué à utiliser une Pelle Intelligente (TM) pour en profiter ».

Chose marrante, certains patrons qui poussent l’utilisation de l’IA commencent à se demander pourquoi leurs employés font de la merde.

• Shopify CEO Who Pushed Staff to Use AI Is Now Horrified by What He's Wrought (futurism.com)

Le culte de l’idée

Le problème majeur, je l’ai déjà expliqué, c’est que nous sommes biberonnés au concept de « La grande idée ». Il n’est pas un film d’action, d’aventures ou d’espionnage qui ne repose sur la découverte ou le vol d’un objet représentant « une grande idèe ». Hitchock appelle d’ailleurs ces objets des « McGuffin ».

• De la mystification de la Grande Idée (ploum.net)

Or, je me répète, l’idée seule ne vaut rien. Strictement rien ! Et une idée doit être confrontée, discutée, mise en balance pour s’affiner, se transformer et, après bien des efforts, exister.

Comme le soulignait très bien Marcello Vitali-Rosati dans « Éloge du bug », cette croyance imprègne la philosophie occidentale depuis Platon : il y a les penseurs-décideurs et les exécutants. Rien d’étonnant donc qu’un produit qui vous fait croire que vous êtes un décideur avec accès à une puissance d’exécution ait du succès. Marcello compare cette croyance au génie de la lampe d’Alladin qui, sous prétexte d’obéir à Alladin, le manipule en réalité à sa guise.

• Qu’est-ce que l’outil va faire de moi ? (ploum.net)

Décrire une idée dans ses moindres détails revient, en réalité, à la réaliser. Il est tellement compliqué de faire des spécifications exactes d’un logiciel qu’on a littéralement inventé des règles pour traduire ces spécifications en langage machine. Cela s’appelle « un langage de programmation ». Et si vous n’êtes pas capable de programmer, vous n’êtes tout simplement pas compétent pour demander à un chatbot de le faire à votre place.

Cela fait 60 ans que nous avons des langages de programmation, cela fait 60 ans que l’on tente de trouver un moyen de se passer des programmeurs (genre avec des schémas graphiques, avec des "langages de spécification"). Mais c’est impossible : les idées humaines sont par définition imprécises et floues, un ordinateur ne peut pas faire quelque chose de précis à partir d’idées floues.

Les chatbots sont un produit qui prétend réaliser votre idée sans la discuter, en acceptant tout. Les chatbots sont donc, essentiellement, une arnaque parfaite pour ce que Ed Zitron appelle les « business idiots » et que j’appelle les « Juliuses ».

• Mon collègue Julius (ploum.net)

Le résultat issu d’un chatbot est soit non-fonctionnel, ce qui est parfois marrant, soit fonctionnel, ce qui est terrifiant. Parce que cela signifie que des centaines voire des milliers de décisions n’ont pas été prises. Les choix que vous n’avez pas vus ont été aléatoirement faits par le génie d’Alladin, un algorithme opaque d’une grande entreprise américaine. Si cela ne vous terrifie pas, c’est que vous n’y avez pas réfléchi assez.

Des outils incompétents pour personnes compétentes

Nombre de projets Open Source que je fréquente sont désormais envahis de contributions générées par chatbots. J’ai été témoin d’un pseudocontributeur qui disait, en substance « voici un patch pour corriger le bug XXX. Je l’ai généré et n’étant pas codeur, je n’ai pas la compétence de savoir s’il fonctionne ».

Reconnaissons à cette personne d’être honnête et transparente. Mais si j’avais cette personne en face de moi, j’aurais envie de lui demander si elle avait réfléchi deux minutes à ce qu’elle fait. Quelle est la valeur qu’elle espère ajouter au projet ? Si résoudre le bug était juste une question de demander un patch à un chatbot, ne serait-ce pas fait depuis longtemps ?

Ah ouais, quand même, on en est là !

Il faut être honnête : j’ai été témoin de cas où je reconnais l’utilité des chatbots. Mais, sans exception, il s’agissait à chaque fois d’une personne compétente. D’une personne qui aurait pu réaliser le travail sans chatbot et a réussi à gagner un peu de temps. De l’ordre de quelques minutes à quelques jours selon ses dires. Sûrement moins, mais passons…

• AI Isn’t Breaking Work. It’s Already Broken. (calnewport.com)

Dans 100% des cas que j’ai entendus, il faut préciser qu’il s’agissait soit de prototypage très expérimental, soit de réaliser une tâche parfaitement absurde, mais administrativement nécessaire. J’ai moi-même codé, à la main, un générateur aléatoire de timesheets lorsque j’ai été soumis à ce régime.

Force est de constater que si vous vous posez la question de développer une app et que vous n’avez pas envie de concevoir un prototype, un petit test vibecodé pourrait éventuellement vous permettre de "tester".

Mais comme le démontre amplement l’exemple de l’application anti-canicule, même le prototypage nécessite un minimum de compréhension du problème, de compétence, bref, d’intelligence.

L’effet Tetris

Une intelligence qui nécessite de l’attention, de la concentration.

Vous vous souvenez de vos heures passées à jouer à Tetris ? Le soir, en vous endormant, est-ce que vous ne voyiez pas des pièces tomber devant vos yeux ? Moi j’ai eu ça très fort en jouant à démineur sur mon 386 et en écoutant en boucle un CD de 2unlimited (oui, je sais, mais il y a prescription). Lorsque j’entends 2unlimited aujourd’hui, 35 ans plus tard, je revois des carrés de démineur devant mes yeux.

Ce que nous apprend cette expérience c’est à quel point notre cerveau est déformé par ce à quoi nous donnons notre temps et notre attention. Ce qui peut être une bonne chose lorsque c’est intentionnel.

Mais la notification qui vient de vous interrompre est-elle intentionnelle ? La 7ème vidéo Youtube que vous regardez durant votre « pause » est-elle intentionnelle ? Et ce n’est pas parce que c’est libre que c’est mieux. Ce enième toot mastodon sur le réchauffement climatique est-il intentionnel ?

Non ? Pourtant, il déforme votre cerveau comme le faisait Tetris ou chez moi, démineur…

• Attention is all you have (alicegg.tech)

Du coup, je n’ose pas imaginer l’état du cerveau des gens qui chattent avec une IA toute la journée, ne s’interrompant que pour les notifications de leur smartphone. Surtout si ces personnes ont du pouvoir.

Ah ouais, peut‑être que ça explique pourquoi on en est là !

• Photo par Basile Morin

Fuir le numérique ou bien le reconquérir ?

Le numérique est-il intrinsèquement mauvais ?

Comme le souligne Sandra, le minimalisme numérique ne vient pas du fait que le numérique soit mauvais en soi, mais juste qu’on a réussi à le rendre le pire possible sur tous les niveaux. Au niveau physique : on fait tout sur un petit écran trop brillant sans aucune sensation tactile et qui nous force à plier la nuque, au niveau psychologique avec l’addiction et l’optimisation pour les pertes de temps ainsi qu’au niveau économique : votre smartphone ne vous appartient pas vraiment, vous n’avez aucun contrôle dessus et, pire, il sert à vous espionner. Et vous allez racheter exactement le même rectangle noir tous les ans ou tous les deux ans.

• Minimalism vs Digital Minimalism (idiomdrottning.org)

Car comme le dit très bien Solderpunk, le créateur du protocole Gemini, nous croulons sous les appareils électroniques de mauvaise qualité qui envoyés au rebut (ou dans un tiroir) parce que « plus supporté par la société qui les a produit ».

Le contrôle de nos appareils nous pousse à en racheter de nouveaux, mais modifie également nos pensées au point de considérer que s’il n’y a plus de mise à jour, l’appareil se transforme soudain en presse-papier. Nous sommes tellement formatés à obéir aux grandes entreprises que nous en perdons toute créativité et toute compétence réelle avec des appareils qui sont des miracles de technologie.

• Lateral Thinking with Withered Technology (solderpunk)

Des miracles de la technologie qui fonctionne contre nous et non pas pour nous.

CodeTiger achète un robot « intelligent » et décide de bloquer l’envoi de données vers le fabricant. Ce qui entraîne à chaque fois une panne après quelque jour. Fâché, iel décide d’investiguer les entrailles de l’appareil : le robot est en fait un ordinateur tournant sous Linux qui envoie toutes ses données au fabricant, y compris la configuration de la maison, les habitudes des occupants, les codes wifi. On s’y attendait un peu. Mais, en plus, il est piloté à distance !

Une fois qu’il cesse d’envoyer ses données, quelqu’un envoie une commande pour désactiver l’appareil volontairement !

• The Day My Smart Vacuum Turned Against Me (codetiger.in)

Note: l’immonde illustration générée n’existait pas lorsque j’ai bookmarké ce site.

La fuite ?

Ce n’est pas un hasard si de plus en plus d’experts du numérique se tournent vers le retrocomputing ou le technopunk.

• La complainte du technopunk ringard (ploum.net)
• Un manifeste Offpunk (ploum.net)

Par exemple, le vénérable et très minimaliste navigateur web Dillo, relancé en 2024, après une petite décennie d’abandon.

Mais à quoi peut servir un navigateur qui ne supporte pas le JavaScript ? Bobby Hiltz explique comment il s’est mis à l’utiliser de plus en plus pour faire des recherches, lire les blogs et même écouter de la musique sur Bandcamp !

• Dillo Web Browser (bobbyhiltz.com)

Et non, ça ne scale pas. Le technopunk s’en fout de la mise à l’échelle ou de convaincre les investisseurs, il veut juste que ça fonctionne pour lui et ses potes.

• Against scale (tante.cc)

Cette même population fuit également de plus en plus la nocivité intrinsèque des réseaux sociaux.

Car suivre nos proches sur les réseaux sociaux serait en fait une mauvaise idée. Si les réseaux peuvent rapprocher des inconnus aux intérêts similaires, ce qu’ils ont fait à leurs débuts, ils peuvent également éloigner des gens proches dont les intérêts spécifiques ou les opinions diffèrent. Ils emprisonnent des groupes d’humains pleins d’énergie et de motivation dans un carcan consumériste (dédicace aux groupes Facebook qui se disent "anticapitalistes").

• Du risque de transformer nos amitiés IRL en relations parasociales (lalunemauve.fr)

Alors, certes, quitter Whatsapp n’est pas évident. Mais c’est possible.

• Résolution de la rentrée : quitter WhatsApp (www.baudelot.eu)

C’est par contre plus facile de quitter X…

C’est marrant, car ça me fait penser à ma nouvelle humoristique « Le dernier espoir » dans laquelle je mets justement en scène un handicapé numérique qui tente de lutter contre l’espionnage de toutes ces plateformes alors que sa famille essaye de le convaincre de les rejoindre. La nouvelle est dans le recueil « Stagiaire au spatioport Omega 3000 et autres joyeusetés que nous réserve le futur », disponible dans toutes les bonnes librairies, sur le site de l’éditeur (sans DRM) ou dans les archives d’Anna la pirate.

• Stagiaire au spatioport Omega 3000 (pvh-editions.com)

Un problème politique et social

Le pire, c’est qu’on ne vous ment (presque) pas : tout est dans les conditions que vous avez acceptées.

Nicolas Vivant insiste sur ce point : en cliquant "J’accepte", nous marquons notre accord pour être espionnés, mais, également, nous prétendons avoir l’accord de nos amis pour qu’elleux soient espionnés.

C’est notamment le cas de Whatsapp qui envoie toutes les infos de votre carnet d’adresses à Meta.

• Nous ne lisons pas les conditions d’utilisation, et c’est problématique (grenoble.ninja)

Bien que n’ayant plus de compte Meta sous quelque forme que ce soit, il existe un profil avec mon numéro de téléphone, tous les noms sous lesquels je suis renseigné dans les carnets d’adresses, un graphe de contacts qui permet de me situer précisément dans le tissu social. Sans compter les infos que j’ai données lorsque j’étais jeune et naẗf.

• Le suicide de mon compte WhatsApp (ploum.net)

Le plus effrayant, c’est que le fait que j’aie supprimé tous mes comptes doit certainement me faire apparaître dans une liste particulière qui peut-être utilisée pour tenter de me cibler avec des pubs qui vont me convaincre, puis pour s’assurer de me pourrir subtilement la vie et, enfin, pour me mettre sur la liste de "potentiels terroristes" le jour où le gouvernement de mon pays se mettra à suivre cette mode mondiale du fascisme.

Si j’étais Meta, par exemple, et que j’avais des infos sur un "réfractaire" à Meta et Google, je demanderais à Google de faire en sorte que les messages qu’il envoie via SMS se perdent un peu plus souvent. Que ses appels sonnent un peu plus dans le vide.

Nicolas oublie de préciser qu’il avait été estimé que si nous devions lire les conditions d’utilisation de tous les logiciels que nous utilisons, et leur mise à jour, 24h par jour n’y suffirait pas. L’acceptation des conditions d’utilisation est donc une pure fiction.

Le problème n’est donc pas que nous ne lisons pas les conditions d’utilisation. Le problème est que cette fiction permet aux entreprises de faire n’importe quoi. « Bien sûr que nous allons enlever son premier né pour boire son sang ! L’utilisateur a accepté ! »

Et il suffit d’une seule personne dans vos cercles sociaux qui accepte ces conditions en votre nom pour vous faire espionner.

Autrement dit, ce n’est pas de la faute de l’individu, c’est un problème 100% politique.

La preuve, c’est l’impact qu’a eu le RGPD dans le monde. Alors, certes, il n’est pas idéal et, en réalité, ne fonctionne pas vraiment.

• GDPR is a failure (nikolak.com)

Mais, quand même, le fait que tout le monde déteste le GDPR est un signe que c’est un pas dans la bonne direction. Il ne fonctionne pas vraiment, mais il fait très très peur aux grandes entreprises.

• matduggan.com

Reconquérir notre indépendance

Il est temps de réactiver vos comptes "indépendants" que vous n’utilisez pas, car "moins facile", "moins de personnes", "moins de dopamine",… Votre site perso, votre compte sur le Fediverse, vos expérimentations sur Gopher ou Gemini…

• Eternal 2020 (or not) (midnight.pub)
• Creating a Blog in Gemini:// (brennan.day)

Et surtout, de le faire avec vos petites mains, votre petit cerveau et toutes vos maladresses humaines.

Car quand vous publiez un billet de blog ou un post sur les réseaux sociaux qui a été généré par un chatbot, vos lecteurs s’en rendent compte. Très vite. Et ils arrêtent de vous lire instantanément. Et ils arrêtent de vous lire pour toujours.

Croire que ça ne se voit pas, c’est comme un fumeur qui pense que parce qu’il a éteint sa clope avant de rentrer dans une pièce, il n’empeste pas. C’est juste que le monde autour de vous est juste trop poli pour vous le dire franchement.

Comme le dit Bryan Cantrill, si vous pensez que personne ne va le remarquer, c’est que soit vous n’avez pas lu vous-même ce que vous postez, soit vous êtes devenu tellement incompétent en termes de lecture (pas d’écriture, de lecture) que vous n’êtes plus capable de lire correctement.

• The revolt of the reader (bcantrill.dtrace.org)

Comme je le disais, si vous ne prenez pas le temps de l’écrire, pourquoi devrais-je prendre le temps de le lire ?

• Soyez humains, communiquez ! (ploum.net)

Et si il n’y que la « performance » qui compte pour vous, vous êtes en train de détruire votre réputation. Pareil avec les illustrations générées. Le moteur de recherche Kagi permet de signaler les contenus qui sont du « slop » de manière à les cacher. Petit à petit des réseaux vont se mettre en place pour exclure les contenus générés. Et la réputation que vous êtes en train de construire aujourd’hui aura un effet demain. Plus vite que vous ne le pensez…

J’utilise personnellement le filtre AI Blacklist pour uBlock Origin. Il m’a arrêté bien des fois lorsque je suivais un lien. Et vous savez quoi? Je ne l’ai jamais regretté jusqu’à présent !

• AI uBlock Origin Blacklist (github.com)

D’ailleurs, il est grand temps de mettre vos filtres uBlock à jour vu qu’OpenAI tente désormais d’espionner votre comportement en ligne, même si vous êtes déconnecté de votre compte ChatGPT. J’avoue être bien content de n’en avoir jamais créé, même « pour tester ».

• ChatGPT now knows what you do on other websites via ad collector (www.buchodi.com)

Évitez le slop, évitez d’en générer et tentez de créer et de communiquer le plus loin possible des grandes plateformes privatrices. Bref, cultivez votre indépendance !

Vous allez voir, on y prend vite goût !

• Illustration : La Liberté guidant le peuple, de Delacroix

Gabrielle Deman, de jonge naar avontuur en wetenschap hunkerende dochter van een Brusselse uitgever, trok in het begin van de 20ste eeuw als eerste blanke vrouw met haar man Commandant Sillye door de toenmalige Congo-Vrijstaat. Ze fotografeerde en verzamelde insecten en vogels voor het Afrikamuseum en documenteerde haar ervaringen in dagboeken en brieven die later ook in de collectie van het…

Source

Ahhhh … September! Geniet ervan, ook met “Tell me I never knew that” van caroline featuring Caroline Polachek! Watch this video on YouTube.

Source

41 years after bemoaning their friend Marcia Moretto who died from cancer in “Marcia Baila” (produced by Conny Plank) and 19 years after losing partner Fred Chichin to cancer, the other part of Les Rita Mitsouko Catherine Ringer died from cancer as well. Watch this video on YouTube.

Source

Today Acquia launched a new brand, and my favorite part is the updated logo. Right under the Acquia name, it now says "Powered by Drupal".

Drupal has always been at the core of Acquia, but for the past 5 years it was less visible in how we described ourselves. Now it's front and center again.

But that is not the main reason for the rebrand. The bigger reason for the rebrand is to help people see what Acquia has become. Our products have evolved faster than awareness of them.

The new brand leads with content instead of digital experiences, and the homepage calls Acquia an "agentic content platform" rather than a "digital experience platform".

Acquia Source is our new command center, bringing content management, digital asset management, and web governance into one workspace. Acquia AI coordinates agent work across those tools.

For agents to work safely across these tools, they need content they can trust and clear rules for using it. Somebody still has to decide what is approved, who can use it, and where it can go. I wrote about that in AI and the great CMS unbundling, and the new brand puts that idea at the center of our story.

Drupal is well suited for that job. Structured content, granular permissions, workflows, and revision history are the things agents need to work safely, and Drupal has refined them for years.

Customers can use Acquia Source CMS, our fully managed Drupal SaaS offering. For teams that want full control over their Drupal sites, we offer Acquia Cloud. Acquia Source brings sites on either platform into a shared workspace.

As you scroll the new homepage, it builds up our technology stack one layer at a time, starting from Drupal.

Acquia leaning into Drupal is also good news for Drupal itself. It helps close the gap between Drupal and its reputation. Drupal is still often seen as a CMS that requires a developer for everything, even as improvements in recent years have made it easier for marketers to build pages and manage content themselves.

So alongside the new brand, we'll be investing more in helping the Drupal community evangelize Drupal, reaching developers and marketing leaders who may not have looked at it in years. I want more people to see what Drupal has become.

Soyez humains, communiquez !

Pourquoi le moindre humain écrira toujours mieux que le chatbot le plus perfectionné.

Dans ma vie, j’ai écrit plusieurs millions de mots, sur des myriades de sujets et pour des dizaines ou des centaines d’audiences différentes. Rien que ce blog en fait 250.000. J’estime également en lire plusieurs millions chaque année.

Bref, j’ai une relation profonde et intime avec l’écriture et la lecture. C’est ma passion, mon métier et même une manière de vivre. Je suis capable, en me concentrant, de lire particulièrement vite. À une époque, je pouvais lire "photographiquement". De même, j’ai l’écriture très facile. Lancez-moi sur un sujet et je peux discourir pendant des pages et des pages sans effort.

À celleux qui me demandent comment écrire, je n’ai qu’un conseil : réduisez la friction entre votre cerveau et les mots en apprenant la dactylo (mes passages au Bépo puis à Ergol ont été des étapes incroyables dans mon processus d’écriture). Pour le reste, il suffit de prendre goût au fait d’écrire.

• Le bépo sur le bout des doigts (ploum.net)
• Ergo‑L (ergol.org)

Écrire c’est très facile si on accepte de se laisser aller, si on prend confiance en soi.

Essayez, vous verrez !

La concision fait la qualité de l’écriture

Bien écrire, c’est évidemment beaucoup plus difficile, en tout cas pour moi. Mais l’essence de « bien écrire » est très simple. Il faut que chaque mot ait une utilité.

Bien écrire, ce n’est pas écrire beaucoup. Au contraire ! Bien écrire, c’est couper, supprimer pour aller à l’essentiel. Chaque mot doit être une manière d’amener subtilement votre idée, votre émotion, votre raison d’écrire à se clarifier dans votre cerveau et dans celui du lecteur. L’écriture est une forme de télépathie. La qualité de l’écriture est la mise au point, la netteté.

C’est la raison pour laquelle les textes générés par chatbots/IA/pouetpouetGPT me sont insupportables. Ils sont creux, longs, verbeux.

Même les résumés automatiques sont une catastrophe. Ils trahissent le cheminement de l’auteur, ils se trompent régulièrement sur les points subtils, mais cruciaux et, comble de la bêtise, ils sont souvent plus longs que le texte original qu’ils sont censés résumer. Un résumé ou un surlignage est intrinsèquement personnel. Il doit vous permettre de vous rappeler votre expérience de lecture.

Et ce n’est pas une question de qualité du modèle. Non PouetPouetGPT 42.3 n’est pas révolutionnaire ! Il ne peut pas l’être.

Parce qu’il ne peut pas inventer l’information. Il ne fait que diluer le prompt que vous lui donnez, le mettre en forme selon ses standards, l’agglomérer à des milliards de statistiques. Mais il ne peut pas lire dans vos pensées et deviner ce que vous voulez me dire.

Le message utile sera toujours plus court que le prompt pour l’obtenir

Si vous demandez à PouetPouetGPT d’envoyer un mail à Ploum pour savoir comment il va, la seule information valable, la seule écriture qualitative est: 

Salut, Ploum, comment ça va ?

Tout le reste n’est que du bruit. De la mauvaise écriture (et je m’y connais en mauvaise écriture). C’est juste que la mise en page, l’orthographe, le respect de certains styles peuvent donner l’apparence que c’est « bien écrit ». Ça ne l’est pas. Ça ne le sera jamais parce que « bien écrire » c’est avant tout « bien communiquer ». Et rajouter du bruit ne permet pas de bien communiquer.

L’équation est simple : un message bien écrit sera toujours plus court que le prompt équivalent. Les agents d’aide à l’écriture exploitent le manque de confiance. « J’écris mal, je vais demander à l’IA ». L’apparence du résultat fera encore plus baisser l’estime de l’auteur qui, pour couronner le tout, pratiquera de moins en moins l’écriture et sera de moins en moins au clair avec ses propres idées.

• Ne rien avoir à penser (ploum.net)

Imaginez une conversation téléphonique. Le réseau est mauvais. On vous entend mal. Vous décidez alors de mettre de la musique à fond en arrière-plan parce que la musique est jolie. Avez-vous amélioré votre capacité à communiquer ?

Et, surtout, pensez-vous que c’est respectueux de votre interlocuteur ?

Lorsque l’écriture n’est plus le fruit d’un effort intellectuel

Jusqu’il y a peu, lorsque je tombais sur un billet de blog, lorsque je recevais un email, je partais du principe qu’un humain avait fait l’effort de l’écrire. Je faisais donc l’effort de le lire, au moins rapidement. J’abordais tout texte avec cette question en tête : « Qu’est-ce que l’auteur essaye de me dire ? »

Ce n’est aujourd’hui plus le cas. Je dois traiter chaque email, chaque site web inconnu comme étant potentiellement généré et n’ayant demandé aucun effort humain. Dans le doute, je vais désormais m’abstenir de lire et de répondre. Après tout, si vous n’avez pas pris le temps de l’écrire, je prends comme une insulte que vous pensiez que je puisse prendre le temps de lire.

• I Don’t Want to Interact With Stochastic Parrots (ploum.net)

Bien entendu, je n’ai pas de détecteur IA parfait. Je me fie à mon instinct. Mais, comme je l’ai dit en introduction, celui-ci est particulièrement développé pour l’écrit. Un message qui porte une énorme attention au style, à l’orthographe, qui est long, mais qui est particulièrement pauvre en information est soit généré, soit écrit par quelqu’un qui fait du remplissage et ne vaut guère mieux (typiquement, un marketeux).

Mon expérience de prof joue aussi peut-être : les textes générés ressemblent de manière frappante aux examens que je fais passer à des étudiants qui ont beaucoup de charisme, mais qui n’ont rien compris. Ils brodent, tournent autour du pot, tentent de camoufler leur ignorance avec une assurance déconcertante. Mais aucun prof ne s’y trompe : l’étudiant sera recalé ! Et encore plus sévèrement que l’étudiant qui avoue son ignorance de manière transparente.

Un humain qui écrit très peu et a du mal à structurer ses idées ne fera pas autant d’efforts pour faire "de belles phrases" bien creuses. Ça n’a aucun sens ! Au contraire, les personnes les moins à l’aise avec l’écriture ont tendance, malgré leurs maladresses de style bien excusables, à donner beaucoup d’informations, à avoir envie d’exprimer des choses.

Et, oui, vous pourriez certainement générer un message qui me tromperait. C’est peut-être déjà arrivé. Mais, pour être sûr de votre coup, générer le prompt vous demandera sans doute beaucoup plus de travail que d’écrire le message directement. Ce qui est fondamentalement stupide, non ? Quelle est la finalité de tout ça ? À un certain point, votre grossièreté devient de la malveillance.

De nos belles et humaines maladresses

La maladroite phrase d’une personne à peine lettrée aura toujours plus de valeur, sera toujours une meilleure manière de communiquer que l’apparence formelle d’un message généré. Et même le modèle PouetPouetGPT le plus parfait au monde ne pourra jamais rien y changer.

Si vous pensez que la version 42.3 s’est justement grandement améliorée, que je devrais tester, c’est juste que vous vous êtes habitué à l’outil, que vous cédez à la normalisation, que vous avez atteint votre propre seuil d’incompétence. Que vous n’avez pas compris à quoi servent l’écriture et la lecture. Que vous êtes en train de perdre votre confiance en vous et votre capacité à écrire.

Alors, par pitié, continuez de penser, d’écrire. Ne déléguez pas votre libre arbitre. Et si vous voulez communiquer avec moi, acceptez vos maladresses, vos fautes et votre humanité. Un simple correcteur orthographique peut aider à améliorer la lisibilité et votre confiance en vous. Mais ce n’est pas nécessaire lorsqu’on communique informellement entre humains.

Respectez votre correspondant : soyez humain !

• Détail d’une statue de scribe de la Vème dynastie égyptienne (photo par Rama)

Yesterday evening, a close friend of ours, together with her two daughters 9 and 3, walked 800m from Charleroi Central station to Charleroi West station. I had suggested her to take the bus through this "interesting" area instead. However, she wanted to quickly grab her kids something to eat. Until she walked out of Charleroi Central.

"Baigais ūķis", she described it, roughly translated: "shady shithole". She didn't like what she saw. Open consumption of heavy narcotics, and more. They ran quickly and caught the train to Leuven.

"Baigais ūķis", by a friend, very well-travelled and a survivor of the post-Soviet '90s absolute chaos.

If you're smarter and more motivated than me, feel free to see this as a call to action.

🚀 FOSDEM 2027: Showcase Your Open-Source Project to the World

FOSDEM 2027 is happening on January 30–31, 2027, at ULB Brussels—and your project could be part of it! As always, we’re offering free stands to open-source projects to connect with the community.

What you can do at your stand

✔️ Present your project and engage with attendees

✔️ Demo your project live

✔️ Sell merchandise or collect donations

✔️ Hand out goodies and grow your contributor base

What we provide

✅ 1 table (180x80 cm) with chairs and a power socket

✅ Fast wireless internet for demos and presentations

✅ A spot for one or both days (choose what suits you best)

✅ Shared stands encouraged! (Joint submissions will be prioritized)

📅 Key Dates

• Submission deadline: October 31, 2026 (23:59 UTC)
• Accepted stands announced: November 8, 2026

🔗 How to Apply

1. Submit your proposal.
2. Add all team members who will be at the stand.
3. Wait for confirmation—and get ready for FOSDEM! 🎉

❓ Questions?

Reach out to us at stands@fosdem.org.

Share your submission with #FOSDEM and #FOSDEM2027. Spread the word about your project!

I believe any Open Source project with a commercial or institutional funding ecosystem should publish an official contribution record: who contributes, how much and over what period, what kind of work they do, which parts of the project they work on, and, where disclosed, who paid for the work.

The test for a good record is simple. A buyer should be able to answer three questions in about a minute: does this vendor contribute at all, how much do they contribute compared to other vendors, and do they work on the parts of the project I care about?

A good record serves both sides. Buyers get answers they can check, and vendors who contribute get credit for work that often goes unseen.

Of course, contribution does not prove that a vendor can deliver. It is one procurement factor alongside delivery capability, expertise, and price.

Vendor claims are hard to verify and compare

Say you need a vendor for your Drupal site, your Kubernetes cluster, or whatever Open Source software you use, and two firms bid. Both say they're deeply involved in the project, and both might be telling the truth by their own definition of "involved".

Without a project record, verifying those claims often means reconstructing each vendor's contribution history yourself.

The code repository seems like the obvious place to start, but even counting commits by vendor is not simple. A project has to connect individual contributors to the organizations that employed or funded their work, and those relationships can change over time.

More importantly, Open Source contribution can include documentation, support, event organization, governance work, promotion, and more. Much of that work happens outside the code repository or isn't recorded in a form a buyer can easily interpret. The data may all be public, but public is not the same as usable. A contribution record exists to close that gap.

Projects are best placed to decide which contributions matter

Drupal has tracked contribution credits since 2015, following a method I proposed in 2014 and now governed by the Drupal Association. Its system records more than code and gives credit not only to individual contributors, but also to the organizations and customers that fund their work.

Not every contribution counts the same. A contribution to Drupal Core or a strategic initiative earns more credit than one to a module that few sites use, and work on contributed projects counts for more when more sites depend on them.

Raw contribution data does not tell buyers which work matters most to the project. The project has the context to decide what advances its priorities and how different contributions should be weighted. Its record should publish those rules, link to the underlying contributions, and explain how mistakes are corrected.

In Drupal, contribution credits feed into the Drupal.org marketplace where buyers can look up agencies and compare them. While we have a strong foundation, we still have work to do to make the record easier to find, understand, and compare.

The record is the project's job, not the vendor's

A fair objection is that this puts the burden on the wrong party: if a vendor claims to contribute, the vendor should prove it, and the project shouldn't spend scarce time tracking contributions.

Suppose the two firms from earlier both send proof. Each proves its own numbers, in the measure it looks best on, and it is still not clear who has the better record. Buyers meet this problem everywhere, which is why procurement leans on third parties: auditors, certifiers, industry analysts, references.

For vendor contribution, the project is often the natural third party. The work happens inside it, so it has the data and is uniquely placed to express an opinion on the value and strategic impact of a vendor's contribution.

A contribution record is a way for a project to recognize its Makers and to say who it would like to see win bids. It also settles the question once, for every buyer, instead of every buyer auditing every bid.

A project should take on the burden when publishing the record is in its interest. Making contribution visible steers commercial work toward the vendors that sustain the project, and that work is what pays for the contribution. So the project gets more contribution, and public credit is how the project gives back to the vendors that contribute.

Projects can start with a simple record

Not every project may want or need a system as elaborate as Drupal's. How much record a project needs depends on how services around it are bought and sold: a project with hundreds of firms competing for work needs more than one with a handful of known vendors, and a project with no commercial ecosystem may not need a record at all.

For a small project, a text file in the official repository listing its recognized organizational contributors and what they worked on can be enough for a first version.

More complex ecosystems may need to categorize vendors, support searches by location, or weight different kinds of contribution. Whatever form it takes, the record has to be easy to find and quick to use.

So if you maintain an Open Source project with a commercial or institutional funding ecosystem, start publishing a contribution record and improve it over time.

If you buy services built on Open Source, ask for the project's contribution record. Decide at the start how contribution should count in your purchasing decision, then check bidder claims against the record.

Finally, if you fund Open Source, use the record to find contributors working on the parts of the project you want to support.

Where buyers and funders can consider contribution, I expect projects with clear records to see more commercial opportunities go to their maintainers than projects that rely on appeals alone.

Special thanks to Henry Poole for his contributions to this blog post, and to Sachiko Muto, Tiffany Farriss, Tim Lehnen, and Amandine Le Pape for their review.

Die PISA resultaten voorstellen als een wedstrijd waar je als land/ regio toch maar zo goed mogelijk moet scoren is kortzichtig! In dat rapport staat er immers zo veel meer dat het belang van die schijncompetitie overstijgt, over zaken die niet enkel over onderwijs-kwaliteit, maar over onze maatschappij gaan. Lezen, leesvaardigheid, leesplezier is zo een héél belangrijk aspect.

Source

I Don’t Want to Interact With Stochastic Parrots

My AI policy is "I don’t want any kind of interaction with that thing." And this should be all you need to know.

I don’t care if you call it AI, LLM, chatbot, or whateverGPT. I simply don’t want to interact with it in any form. If you interact with me, make sure to never send me any output from those nor to use it as a "source" to justify one of your arguments.

I’m one of those people deeply interested in all the extraordinary stuff other humans have to say. Unfortunately, life is already too short to hear them all. I need to make a lot of choices. That’s why I will not tolerate any attempt to steal the little time I’ve on this planet by making me interact with stochastic algorithms trained to produce tons of "average," non-human content.

The direct consequence of my choice is that I will refuse to interact with humans who take pride in making themselves a meat interface between me and the algorithm they’ve chosen to replace their free will.

I will not read your website, I will ignore your emails and I will happily walk away from real-life conversations as soon as it is clear that I’m not talking to a fully sentient Homo sapiens sapiens but to an empty shell who has happily delegated their cognitive abilities to an external proprietary tool designed to be some sort of "random average garbage."

I will not read the text

The very essence of writing is what makes you think. When you write, even something as mundane as a short email, you transform a bunch of contradictory neural stimuli into an ordered thought.

If you don’t care to write it, there’s no reason I should waste one single second reading it. The effort should be on your side first.

I don’t mind mistakes, typos, or badly formed sentences. In fact, I subtly appreciate them when we interact because they are part of you, they tell a lot about yourself. I’m not a literary agent, I will not judge your way of writing: I’m there to exchange ideas, knowledge, and experiences.

If you find yourself typing a prompt to express your idea, then just send me that prompt. I’m not interested in what an algorithm would do with your prompt, I want to know what you asked in the first place. I care about you, the human.

You may find it hard to express yourself, to write what you think: remember that the less you practice, the worse it will be. Prompting might feel easier. It does not make it right.

If it is from an algorithm, it is not you. Only you can write what’s inside yourself.

I will not look at the pictures

Generated images. Seriously. They all look hideous.

When I spot one in a given context, I immediately have a feeling of cheapness, bad taste, and poor culture. Like this fancy restaurant of a luxury hotel I saw in a big European city. It had a huge AI generated picture on its main building: a kid eating malformed fries with his six-fingered hand and putting them in his skull through his cheek. Or this other restaurant which had a very nice menu, full of pictures of Italian cities. Until the kid’s menu which, was shockingly out of place and totally unnecessary. It also showed a kid awkwardly eating a pizza even though there was no pizza on the kid’s menu.

If you don’t have the resources to pay for an artist, you probably don’t need a picture at all. If you are making a poster, write what is important to know instead of burying it in a gloomy generated picture. If you write a blog post, I will not read if it is illustrated by generated pictures.

A website illustration, if any, conveys an emotion, a feeling. I sometimes spend more time finding a good illustration for a post than writing it. If I don’t find a satisfying picture, I don’t put any.

The first feeling conveyed to me by a generated picture is an uncanny unease, an obnoxious emotion that immediately makes me want to leave. It also tells me enough about the author not to want to know more. It might be a kind of overreaction. But as I said, there’s too much to read anyway so it’s a good first filter.

No, that picture is not pretty. No, it is not funny. It doesn’t share any human feeling, any artistic expression. You like it because you had fun generating it. But it is wasting my time.

I will not run the code

I don’t want to run generated code on my computer.

Good code is knowledge. Even in a purely productivity-oriented business, every line of code should reflect the choice of an employee knowing the business and choosing a way to solve a business problem.

Reality is, of course, different. I’ve worked with enough different codebases to know that proprietary software is simply badly coded. Each line is written assuming "I will not be there anymore to deal with it in a few years." But at least we know that each line, as bad as it can be, was added by a human for a reason. LLMs move the needle from "no need to care in a few years" to "no need to care right now." You cannot assume anything about generated code. Maybe it was simply hallucinated and, by chance, it compiled.

Which means that, as soon as generated code is added to a project, the whole project becomes unmaintainable by humans. You can’t understand the code because there’s nothing to understand in the first place!

It follows that the whole project now needs LLMs for any change which, will make it even worse from a human perspective. We end up adding more and more lines of code nobody understand where the problem has always been "There are too many lines of code and too few people understand them."

I’m convinced that accepting generated code will lead most projects to become broken beyond all hope of repair in only a few years. "Carefully reviewing" will soon not be enough. Unfathomable code will eventually slip in and gradually destroy the whole project. I predict that the projects too important to be left to rot and die will take decades to recover from those couple years of "assisted productivity."

We need to remember that what we call "code" is merely a specification of the software we want. Those specifications will be given to the compiler to make the real software. The role of a coder is to take vague, imprecise, and contradictory specifications from a manager or customer and then make sure to remove any ambiguity. This could be done by clarifying with the customer or by silently making choices. History and mathematics have demonstrated that humans cannot make unambiguous and non-contradictory specifications without using a formal language designed expressly for that purpose. Natural languages simply cannot remove ambiguities and this may be an evolutionary feature.

Removing the coder and replacing them with a tool designed to pretend to agree to anything said could never produce good, maintainable software. It may produce a small throwaway script. It may find security holes more efficiently than fuzzing. But it will never be able to build something useful and reliable for the long term.

Which is what I expect from software.

I want to be able to trust software enough to invest time in learning it. That has always been one of my main arguments for using open source: if a free software is good enough, I trust that there will always be people to maintain it or to fork it if needed. If I have a problem with a free software, I can always look at the code to understand what the humans who designed it wanted to do. I may also modify it. This is not theoretical: I’ve done that with countless pieces of software in the last 20 years. I rely on it!

For that reason, I will carefully avoid running any openly "vibecoded" tool, and I’m trying to focus my efforts on projects that actively try to distance themselves from the current bubble.

I will not listen to the discussion

"I’ve asked ChatGPT and…"

That’s it. No need to say more. All those years speaking about "fake news" and "checking your sources" just to blindly repeat a random series of letters assembled by a stochastic algorithm? Seriously?

I don’t care about your credentials, I don’t care about your experience. With a couple of words, you gladly announced that you are obliterating them and refusing all forms of free will. Goodbye!

That’s not very friendly, I know. I never pretended to be. And I didn’t start it.

I will not grade the student report

Across the last years, I’ve not managed to find one single student who astonished me with their use of a chatbot. In every single case I’ve met, the use of a chatbot made my student perform worse. Sometimes spectacularly like, this student who contributed to a project on Github but, when asked, could not even tell me what the project was about.

On the opposite, forcing the student not to use any AI makes them better every single time. No exception. It also vastly improved their self-confidence.

• Giving University Exams in the Age of Chatbots (ploum.net)

It is not a matter of "learning to use the tool". You cannot learn to use a proprietary stochastic tool which can be changed at any time. You don’t need to "learn to chat" (and if you do, not in my course). What the "tool" is really doing is making you lose the essential ability to learn, making you lose your self-confidence. As John Scalzi points out: playing Guitar Hero is fun. But even thousands of hours of playing Guitar Hero will not enable you to play "Happy Birthday" on a real guitar.

• Generative “AI”: The Guitar Hero of Creativity (whatever.scalzi.com)

I consider that my students are in my class to learn. Chatbots are actively preventing any kind of learning. That’s why, from now on, I make it a strict policy that anything my students are submitting should be entirely produced by them.

It can be short. It will be imperfect. It will be full of mistakes. It may even be wrong. The report will have fewer bullet points and emojis. But it will be yours, and that’s what I want to see.

I will not technologically "enforce" this rule. Cheating has always been part of university. If you are smart enough not to be caught, you probably deserve to pass. But it will probably require a lot more effort on your side than simply writing your own goddamn report with your bloody fingers on a keyboard.

I will not judge what you do in private

AI/chatbots/LLMs are known to have a terrible impact on your brain. They are bad for you, for the whole economy, for the political atmosphere, and for the environment. They consume huge resources, destroy the whole Internet and our ecosystem.

But they are addictive, I get it. They make you feel productive (which, studies have demonstrated, is largely a feeling). I consider them a kind of drug.

• AI Isn’t Breaking Work. It’s Already Broken. (calnewport.com)

They may also be useful when you are forced to accomplish a stupid one-time task you don’t want to do but is required. We all have to deal with our share of bullshit jobs, I get it.

Using AI is like a shameful drug addiction or a weird sex fetish. If you want to use it privately or between consenting adults, it’s up to you. As long as you don’t brag about it, I will not judge.

Just make sure that I don’t have to interact with it.

• Human made logo by Matt Kindt (commons.wikimedia.org)

I switched from Docker to Podman in my homelab back in 2023, and settled on using Quadlets. I’ve been using this system for about three years, but it’s a bit of a hassle to have to convert any and all Docker Compose files into separate Quadlet files.

If you’re starting out with Podman, you might want to go read the blog post linked above, as it does contain some things to help you get started.

Having grown tired of doing that, I decided to revisit Podman Compose - taking the Compose files created by the upstream projects, and running them through podman instead of Docker. My previous trials with Podman Compose weren’t that great, but somehow now things just worked.

While switching over my container stack I came across a few things that I had to change:

SELinux process labeling

For Traefik I had SecurityLabelType=traefik.process configured so that the process would be labeled with the correct SELinux context. To do this with Podman Compose I had to add

security_opt:
  - "label=type:traefik.process"

to the service definition.

User namespace mapping

Some of my containers use namespace mapping to make the original UID available to the container. I came across this blog post which details a lot of the Podman Compose extensions available.

Previously I had

PodmanArgs=--uidmap +1000:@1000:1 --gidmap +1000:@1000:1

which could be mapped to

x-podman.uidmaps:
  - "+1000:@1000:1"
x-podman.gidmaps:
  - "+1000:@1000:1"

in my compose.yml file.

Starting containers automatically at boot

When using Quadlets, systemd will make sure your containers are started at boot. When using Podman Compose, there’s a service you can activate called podman-restart.service to basically do the same thing.

To enable it, run (as your Podman user):

systemctl --user enable --now podman-restart.service

If you check out /usr/lib/systemd/system/podman-restart.service, you’ll see that the start command reads

ExecStart=/usr/bin/podman $LOGGING start --all --filter should-start-on-boot=true

The man page for podman-start tells us that the should-start-on-boot filter will instruct Podman to start containers with a restart policy of always or unless-stopped.

Automatic updating of containers

Quadlets also offer the feature of updating your containers automatically and restarting them when a new image is available.

In this blog post I found a nifty way to solve this problem:

I created the systemd timer ~/.config/systemd/user/podman-update@.timer:

[Unit]
Description=Podman update timer for %i

[Timer]
OnCalendar=daily
RandomizedDelaySec=900
Persistent=true

[Install]
WantedBy=timers.target

and the systemd service ~/.config/systemd/user/podman-update@.service:

[Unit]
Description=Podman auto-update service for %i
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
WorkingDirectory=%h/containers/%i
Environment="DOCKER_HOST=unix:%t/podman/podman.sock"
KillMode=process
RemainAfterExit=no

ExecStart=/bin/bash -c '\
  BEFORE=$$(/usr/bin/podman compose images -q | sort -u); \
  /usr/bin/podman compose pull; \
  AFTER=$$(/usr/bin/podman compose images -q | sort -u); \
  if [ "$$BEFORE" != "$$AFTER" ]; then \
    echo "New image downloaded for %i. Recreating containers..."; \
    /usr/bin/podman compose up -d --force-recreate; \
    /usr/bin/podman image prune -f; \
  else \
    echo "Images for %i are unchanged. Skipping restart."; \
  fi'

[Install]
WantedBy=default.target

and enabling the timer (per Podman Compose project directory)

systemctl --user enable --now podman-update@<directory>.timer

Don’t forget to update the WorkingDirectory in podman-update@.service to wherever you store your Podman Compose YAML files! I use ~/containers, with a subdirectory per project.

Now my containers get automatically updated and cleanly restarted too.

Proposals for developer rooms for FOSDEM 2027 can now be submitted!

Developer rooms are assigned to self-organizing groups to work together on open source and free software projects, to discuss topics relevant to a broader subset of the community, etc. Most content should take the form of presentations. Proposals involving collaboration across project or domain boundaries are strongly encouraged.

We want to continue to focus on promoting collaboration and community between different projects in niches which don’t normally have their own spaces, rather than large projects with significant corporate backing.

For inspiration, some example rooms along these lines from recent years: Modern Email, Package Management, and Music Production.

As usual, we unfortunately have a very hard limit on the number of devrooms we accept due to the realities of the physical space available to us. Every year we must make difficult decisions about which great proposals must be rejected (in the past we could have filled the entire conference with every devroom about a different programming language!). If you submitted a proposal for a devroom in the last few years and got rejected, don’t be disheartened and submit anyway!

Devroom coordinators must enter a complete schedule into our conference system by 7th December. It is particularly important to be available and to respond promptly to emails about the schedule for about a week either side of this date. We also require all proposals to be submitted directly by the speakers into our system.

• Saturday devroom schedules should contain between 7.5 and 8.5 hours of content, beginning at 10.30 and running until between 18.00 and 19.00.
• Sunday schedules should contain between 7 and 8 hours of content and start between 09.00 and 10.00 and run through until 17.00.
• No lunch breaks should be scheduled for devrooms.

If you don’t think you can fill a full day, please try to join up with another project and submit a joint devroom application or indicate on the submission form that you are requesting only half-a-day and would like FOSDEM to try to pair you up with another similar request for half-a-day.

Because our room capacity is limited, we will record and stream all devrooms live. The recordings will be published under the same licence as all FOSDEM content (CC-BY).

Devroom submissions will only be accepted with at least two named managers who are responsible for the room.

If you have questions or need help crafting a good submission, contact us at program@fosdem.org.

The deadline for submissions is 4th October.

Key dates:

• 04 October: deadline for developer room proposals
• 20 October: accepted developer rooms announced
• 27 October (or earlier): developer rooms issue Calls for Participation
• 07 December (or earlier): developer rooms publish complete schedules

Note that the submission form should only be used by organisers of devrooms. If you want to submit a talk to a main track or devroom, keep an eye on the website until their Call for participation opens around October 27.

David Van Reybroeck pleit (nav bv #klimaatproblemen, drugsgeweld, … en het tanende geloof in #democratie) voor de oprichting van #burgerpanels in België naar model van de Duitstalige gemeenschap. Zo een permanent geloot burgerpanel kan los van partijpolitieke en electorale belangen meedenken en adviezen formuleren en blijkt in de praktijk een grote meerwaarde te kunnen hebben. Meer info vind je…

Source

9000 RPM. That’s how fast a modern sports car engine can rev.

I know that number, but I can’t quite visualize it. The math is simple: 9000 revolutions per minute is 150 per second.

I Don’t Have a Smartphone…

• Tradução para português por Berlim

…or, at least, I wish I didn’t.

"I don’t have a smartphone," is what I tell people and professionals nowadays. This allows me to cut the crap about companies insisting that I install their app or restaurants wishing that I scan a QR code to access their menu on a small screen.

"I don’t have a smartphone" is, according to my experience, the easiest explanation, the shortest way to force people to get their shit together and take the required actions to allow me to live without being glued to a small screen dependent on a huge American megacorporation.

When I buy something, from a small kitchen appliance to a car, I’m now forced to get formal confirmation by the seller that I will be able to use it without installing one, two or three different apps. I kept the count: in the last year alone, I had to argue against the installation of 18 smartphone apps. Just in my toilet, I’m supposed to have an app for the seat, an app for the flush and one for the ventilation.

It is quite fascinating because if you assume using each app for only 3 minutes per day (which basically means opening, closing and does not include doing the upgrade every other day or debugging some problems), that’s nearly 1 hour of your day! 22 full days of your year (assuming 16 waking hours per day).

What installing your app means

When you ask someone to install your app or to scan your QR code, you make the following assumptions:

1. That person owns a smartphone (which is at least a couple hundred dollars).
2. That person has the smartphone on them right now.
3. The smartphone is in working condition.
4. It has enough battery to install your app, use it then finish the day.
5. It has enough storage left for your app.
6. It has enough network coverage.
7. That person has enough data left on their data plan.
8. They have a valid and connected Google account (or, an Apple one).
9. They are comfortable with taking out the phone and dedicating some time and attention to the screen right now while not paying attention to all those notifications that the phone surely gathered since its last use.
10. They are willing to accept all the conditions of your apps, including sending you personal data, registering an account, etc.

When you think about it, this is an awful lot of assumptions.

Just regarding point 8: your Google account could be terminated right now, without reason. It happens every day. It could happen to you. Or an American president could decide your country should not have that service anymore.

• Et si vos comptes disparaissaient demain ? (ploum.net)

If only one of those 10 assumptions is false, for whatever reason, the person will not be able to use your app. You will have to deal with it.

People always tell me I’m weird for not installing the app but, looking at this list, I find it weird that you even find people to install it in the first place!

But here we are… Those 10 assumptions have become the new commandments everyone should obey.

Why I will tell you I don’t have a smartphone

Ten assumptions that are a bit too long to explain to a vendor or a worker. So, instead of arguing about the time lost and my quest to be Google free, I took the stance of answering, "I don’t have a smartphone."

Reactions vary. Pure salesmen try to convince me that you can’t live without the app, that I need to do the mandatory "update" Why? If it’s connected, it can do its update alone. If it is offline and it works, it doesn’t need any update and updates have a higher probablility to worsen my situation than to be helpful. If it is offline and it doesn’t work well, why should I buy it in the first place?

On the other hand, real workers, those with dirty hands, often smile at me and tell me I’m right or that they wish they could not have a smartphone. On one occasion, a worker installing an appliance told me: "Oh, we will get along well!"

Which tells you something important: nobody wants the app. People install the app because they believe it is mandatory in some sort of way. Because they are afraid of missing out on something. Because they are told so by the salesman. But they just don’t want it. In fact, when pressed, most salesmen even have a hard time justifying why I should install the app.

Also, I was strongly addicted. My relationship with my phone was not healthy.

• How I fought my smartphone addiction (ploum.net)

So "I don’t have a smartphone."

But it is not true.

Mudita Kompakt, my not-so-dumb-phone

My main driver is a Mudita Kompakt, a small minimalist smartphone with an e-ink device. I’ve spoken at length about it in the following piece:

• Une vie sans notifications (ploum.net)

The main point is that, despite being an e-ink device and being totally Google-free, the Mudita is an Android smartphone. I can install apps and, yes, I love the smartphone concept for the tools I choose. I have Signal (well, I use Molly to connect to Signal). I also have the app of my bike GPS. I don’t use it often but when I’m lost far from everything and it starts raining, I launch the Komoot app, ask for the shortest way home and upload it to my bike computer.

That’s very useful innovation!

I also use Comaps, an online calendar and the local train schedule app.

So, seriously, I do really like the smartphone idea. It’s just that I don’t have any browser or "social" app on it. And I don’t want anything else than what I have.

I wish I could say it is all I have, that I’m a true minimalist.

But it is not true.

The secondary desk phone

Somewhere on my desk, I keep an old FairPhone 3 that I repaired after it took a deep plunge into the ocean. It runs the Google-free /e/OS operating system.

But why? The reason is simple: sometimes, you are forced to use an app. Those apps may even check if your phone truly uses Google. So /e/OS has a solution to fake it (microG). The main use case is banking apps.

I highly prefer to do banking on my computer. But, having been brainwashed enough by Google, banks think I cannot be trusted to do banking on a computer I own while doing it on a small piece of glass that I keep in my pocket is "safe." Logging in on banking websites requires me to authenticate on a smartphone that checks for Google services.

It is not only banking: this secondary phone is very useful to test apps without cluttering my main phone. I’ve learned, thanks to my teenagers, that Strava will not launch without Google services. But it will also refuse to login with the fake microG. The solution is thus to launch Strava with microG enabled, to disable microG while keeping Strava running, to log into the app then to re-enable microG. A similar problem happens when using filters on Snap. Living without Google is not always painless.

At least, I can say I’m Google-free.

But this is not true.

The third, real android phone

I still keep in a drawer an old OnePlus 5 I bought in 2017 with a pristine Android system. The screen is cracked, the USB connector is wobbling but it works. It is still connected to a Gmail account I created in 2001 (invitations were still required!) and that I didn’t even open for the last 10 years.

This phone is sometimes necessary. Like when a known bug in /e/OS prevented my banking app from working for several months. Anecdotally, this phone is also the thinnest, the lightest, the best screen I’ve ever seen. It also takes the best pictures (without any AI). It demonstrates that current smartphones are worst in every aspect compared with those of 10 years ago. The only exception being the CPU: that phone has a very hard time loading Anubis-protected webpages. Everything else is fine. It is hard to have this phone in your hand and not consider we are heavily scammed when we buy a modern phone.

In my country, businesses and governments are pushing hard to mandate the use of "Itsme", a proprietary authentication app developed by a commercial joint venture with the explicit intent to extract personal data and sell them commercially (yes, that was explicit in their conditions when they launched the service). I’ve always refused to register and use that service but it is becoming incredibly hard to find alternatives.

New EU regulations may also push more apps to check for the "Google Play Integrity" to ensure that they are running on a true Google owned Android.

I’m fighting hard but I foresee a moment when we will all be officially forced to have a Google account. If you have children, you are also forced to have a Meta account as everything school related now happens through Whatsapp.

So I’m living Meta-free because my wife volunteered to handle the Whatsapp groups. I’m living Google free because, deep in a drawer, there’s still a solution for the day when I could not work it out without Google.

Who could have predicted

I’m European. The whole continent is assumed to have a Google and a Meta account. To always have in their pocket a Google or Apple certified and remotely controlled piece of hardware. It is even sometimes assumed to have a Microsoft account (like that time when the platform to be reimbursed from a cancelled ticket assumed a Sharepoint login).

This is frightening. We are putting all our eggs in the same basket. And our milk, our water, our house, our furniture and our loved ones. In an electrical-auto-closing basket remotely controlled by a foreign entity that openly spies on us and wants to extract as much money as they can. For some reason, it is considered weird not to like the basket.

At least, some are trying to build alternatives

• Why there’s no European Google? (ploum.net)
• The Privacy Respecting European Phone (jolla.com)
• Delta Chat, decentralized secure messenger (delta.chat)

At the same time, European politicians are focusing on "not seeing" this elephant in the room while dedicating huge money and effort to promote "European AI" or "European Blockchain." Seriously. They are so blind to easy, innovative and existing solutions (Peertube, Mastodon, European mail hosting,…) that I’m starting to suspect that being dumb doesn’t explain it all, that they are truly corrupted.

In the meantime, I do my small part. I defend my small hill. I’m an Offpunk.

• Offpunk Manifesto (blog.ayom.media)

And when requested anything about an online service or a smartphone, I answer:

I don’t have a smartphone!

• Picture of a broken phone by Ashwin Kumar

An Open Source project contains several economic goods. Its code, infrastructure, services, maintainer time, and commercial ecosystem each behave differently. Treating all of them as a single commons hides who pays today, who controls access, and who needs to pay.

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

Combining those dimensions produces four kinds of goods.

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

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

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

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

The four goods in an Open Source project

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A funding rule for stewardship

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

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

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

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

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

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

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

A great bike commute yesterday evening, mostly flat with lots of tail-wind. That’s the way (a-ha a-ha) we like it! The digital overlords however were pretty confused; Wahoo (a Bolt v2) was high and reported over 500m elevation and Strava told me I must have mistaken my gravel bike for en e-bike because of my flat-out speed on a 4km long section, quod non B-)…

Source

FOSDEM 2027 will take place on Saturday 30 and Sunday 31 January 2027, at the ULB Solbosch campus in Brussels, Belgium.

As always, attendance is free and registration is not required. The call for participation, the schedule and travel information will follow here.

Open Source is usually described as a licensing model, a development model, or a production model. All three descriptions are useful, but they leave something out. Every Open Source ecosystem is also a cost-allocation system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10 jaar De Boekenjagers! In 2016 op een lome zondagmiddag gestart als tegenhanger van het Franstalige “Chasseurs de livres” met het idee om ook in dit deel van het land een paar honderd mensen op boeken in plaats van Pokemons te laten jagen. En nu? Meer dan 130.000 leden! Naar schatting 50.000 boeken verstopt/ gevonden! Een eigen boek uitgegeven! Ik ben dan ook heel trots op mijn vrouwken Veerle…

Source

Meeslepende en gevoelige roman over verboden jeugdliefde, trauma, verdringing, verder leven en dan toch nog de confrontatie met dat verleden. Geen lange, poëtische zinnen waar ik soms zo graag in verdwaal, maar Robben schrijft helder en toegankelijk zonder dat het kinderlijk of gekunsteld wordt en slaagt erin om al die emotie geloofwaardig over te brengen. Zeer de moeite!

Source

I added a new feature to my blog: a list of related posts at the bottom of each post. I implemented it using embeddings, and this note documents how.

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

Embeddings turn meaning into numbers

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

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

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

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

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

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

Raw cosine similarity makes everything look related

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

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

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

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

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

Mean-centering reveals what makes each post distinct

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

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

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

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

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

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

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

The average (mean) of the three vectors is:

mean = (0.85, 0.55)

Now subtract that average from each post:

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

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

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

Normalization reduces comparison to a dot product

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

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

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

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

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

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

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

Then take the dot product:

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

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

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

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

Multiplying them the same way:

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

That is not a match at all.

The PHP code is shorter than the explanation

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

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

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

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

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

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

One-time embeddings, occasional ranking

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

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

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

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

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

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

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

In my very first experiments with AI agents, I wanted to manipulate many rows in CSV files. I learned pretty quickly that rather than asking the agent to make the change, you’re better off asking it to write a script to do it, and then running the script. This has many advantages: it’s easier to inspect and validate the logic, make refinements (either with the agent or manually), iterate on the logic as needed, save it for reuse on other files, and ensure the exact same operation is applied across all rows. As a bonus, for non-trivial workloads it also tends to go faster and use far fewer tokens.

Turns out that however good LLMs are at reasoning tasks, for deterministic (and larger-scale) changes, traditional code works better. My first self-taught lesson with agents was: don’t use it for everything, certainly not to replace traditional code. Code and LLMs can be very complementary, and soon after, agents started automatically generating scripts and running them.

Introducing SWAMP

When you take this idea of moving the deterministic logic out of an agent and into scripts and develop it further into a refined, comprehensive system that can be used by individuals or by teams, what do you get? The authors of SWAMP may explain it differently, but I think of SWAMP as exactly that.

Swamp has extensive docs, but these are quite dense. Let me paraphrase, simplify, and explain what it really boils down to (IMHO).

Swamp first helps you build deterministic scripts (using your agent). You can run the scripts on a plain old CLI, but if you run them via an agent, the agent becomes “reasoning glue” around the scripts. Either way, Swamp tracks all input and output data into a robust repository, and the agent context only gets what it needs.

Specifically:

• Swamp deploys skills, so your agent helps you factor out pieces of work into reusable Swamp “models” which have methods, just like classes in OOP. These are glorified scripts, implemented in TypeScript. Swamp bundles various quality checks, which force the agent to improve the code until it’s good enough. One of them is an “adversarial review”: essentially a second persona that picks apart the code and makes your agent do a better job. See this code. You can manually intervene as well, but in my experience, you don’t really need to - certainly not for personal projects, where the agents have become incredibly good.
• Swamp lets you instantiate these models and call the methods. Like objects in OOP, you can just use them without needing to read the class’s code. If you have the agent do it for you, it does not need to load any code into its context, saving tokens.
• Traditionally, you call a script and its output goes to stdout or a file. Agents will typically use grep, sed, or similar tools to select the pieces of output they need, which is pretty token-efficient. But Swamp does something a bit different: the swamp CLI tool wraps the script and automatically collects and stores output data in a repository, neatly organized by model, method invocation, version, etc. You can query and inspect the data and reuse it in other invocations, or load some of the data into your agent context window if you want to. This is a bit more organized and allows for easier auditing and the like. It does mean Swamp needs to teach the agent how to select the data it needs by loading a skill into the context.
• You can feed output from one model into another and construct entire workflows. You don’t even need an AI agent; you can just run these workflows as a CLI command.
• Swamp has a public repository where people can contribute and share useful models. The most popular ones now are for system administration, S3, etc. But there’s also stuff for managing your music library, Flipper Zero management, workout tracking, and managing your baby’s diaper schedule.
• Swamp ships a bunch of skills that guide you and your agent through all of the functionality. This works incredibly well. It holds your hand from start to finish.
• It also has various features for enterprises, larger-scale uses, vaults, etc.

Use cases

The above was a bit theoretical. More people are writing about their use cases (and here’s an interesting CI one), but it’s certainly not limited to sysadmin and software development stuff.

I use Swamp models and workflows for:

• tracking a weight loss journey with a friend. One model extracts my weight data from body.build as CSV, while another extracts my friend’s data from my second brain, Logseq. Several calls to methods on the Grafana model then download, patch, and update a private Grafana Cloud dashboard where we can track our progress.
• extracting location clues out of various sources such as GPX coordinates in my Google Photos, constructing a location history, and making sure I comply with tax laws (which count the number of days spent in a country, etc.).
• managing a Raspberry Pi and querying Prometheus (Swamp helpfully made an extension for this) and managing a local Grafana dashboard (using this extension). I have a local monitoring setup and am troubleshooting an internet issue. Offloading the grunt work to code (Swamp models) and leaving reasoning to the agent works incredibly well. The two work hand in hand to help me build a detailed diagnostics report. Today I have Codex drive Ansible, but may switch that to Swamp as well for more graceful handling of config drift.

All of these seem kind of random, but I guess that’s the point: you can use Swamp for anything! I suspect I will probably start using it for more and more random things.

All of this was built on autopilot. I wouldn’t say vibe coding because it uses Swamp quality checks, adversarial reviews, etc., to ensure a decent level of quality (certainly higher than what I would have cobbled together for my hobby projects in the pre-AI days!).

The confusing bits

If you decide to check out Swamp, I just want to make you aware of some confusing bits:

• I don’t know why it’s called a “club”. There’s nothing exclusive about it. It’s a great open source devtool that anyone can download and use.
• It creates public user profiles (here’s mine - these look very “gamer”-y) and puts them on an undocumented leaderboard. None of this is relevant to using it. I think it’s hooked up to telemetry sent from the CLI tool, which I suppose is a way to gamify the experience and encourage more usage, but this can all be ignored. You can disable telemetry, but I haven’t bothered.
• There’s some very interesting content surrounding Swamp. I find the blog of Swamp team member Paul Stack particularly well-written and thought-provoking. But a lot of it is about “building the machine that builds the machine”: managed software factories that minimize human interaction and rely heavily on AI code generation, automated reviews, and automated quality testing. That’s how Swamp is built. And of course they use Swamp models and workflows in their “software factory”. But all of that is just one use case for Swamp; it’s not what Swamp is really about. Note that the tool feels very solid. I guess all their automated testing pays off :-)
• The “Lab” is their own bug tracker. Paul’s post about why pull requests are dead explains in fascinating detail why they are not using GitHub issues (nor pull requests), but instead built their own bug tracker as part of their software factory.

Conclusion

I found Swamp a very nifty tool to add rigor to my AI workflows, to reduce my inference costs, and to create standalone tools and workflows that I can also run completely outside of AI. So install it, find some basic repetitive or annoying task, ask your agent to help you, and enjoy the ride!

Programming language generations

When I was young, I learned about a model of classifying programming language: the system of programming language generations.

In this model, first generation programming languages are, basically, where you program the computer in the language that is defined by its architecture. On a Von Neumann machine, with its load-and-store architecture, you do that by inputting a string of numbers. The first programmer in human history -- her name was Ada Lovelace -- wrote in a first-generation language. 1GLs aren't so much invented as they are a byproduct of the computers for which they're created.

Second-generation languages are the assembler languages. Because humans are not computers, and because decoding long lines of numbers to understand what the computer is doing, when programming became a full-time job, the programmers that did it decided that doing all this assembling manually is too complicated, so they quickly wrote assemblers to automate the process for them. They still could understand the 1GL output of the 2GL assembler, but most of them quickly forgot how to write software in a first-generation language. Not that anyone cared, as the translation from a 2GL to a 1GL is lossless and you can just revert it.

Third-generation languages are higher-level languages. When the first 3GLs were invented (such as COBOL and, more famously, FORTRAN) in the late 1950s and early 1960s, it was believed by some that the work of programming a computer so accessible to non-programmers that the job of programmer would eventually cease to exist, and people would just ask the computer what they needed by entering COBOL instructions. This of course was ridiculous and incorrect, because converting algorithms to computer instructions, whether at the 2GL or 3GL level, is a specialized skill that some automation can perhaps make simpler but never completely take away the need for. At the time, some people also felt to some extent that using 3GL wasn't the same thing as actually programming 3GLs, but eventually the world moved on and embraced things. The invention of 3GL environments reduced, but did not completely take away, the need for people to understand 2GLs, as compiler and operating system authors still need to understand them, and some highly optimized code still continues to be written in 2GLs to this day.

Fourth-generation languages abstract away some or all of the process of programming. For instance, a database-related 4GL will hide away the complexities of storing data in particular locations, how to fetch that data, how to index it such that you can fetch it efficiently, how to loop over the data to get you a summary of that data, and instead allows you to express the required information in an abstract way, expecing the computer to fill in the blanks. When SQL, an early 4GL, was invented, some people believed that the language made accessing databases so simple that the requirement to implement database applications would eventually cease to exist and we would just hand SQL prompts to users who need to access data. This of course was ridiculous and incorrect, because understanding data schemas and using that understanding to query data from a database is a specialized skill that perhaps a higher abstraction can help you make simpler, but that in the longer run it can never completely take away the need for. The invention of 4GLs also reduced, but did not completely take away, the need for people to understand how to do the things that the 4GLs automate for you manually, as the people who do write those things still need to understand them, and there are also environments where these particular 4GLs are rather not appropriate or just very slow.

The first definition of programming language generations that I read about in the 1980s simply stated that fifth-generation languages did not yet exist, but that they would in the future, and that in those, you would "tell the computer what to do, and it would then do that". Now that we have a way of doing so, it could be said that by some definition, we now actually do have a number of 5GLs. The existence of these LLM systems has caused some, especially the people who build and exploit these systems, to exclaim that programming as we know it today is going to cease to exist, and everyone will just ask an LLM to generate a program, which will then do so. That is of course ridiculous and incorrect, as no automaton can generate software from nothing; input is still required for the model to be able to produce something that approaches usability, and being able to word that input in a correct and productive fashion will be a skill that future programmers can benefit from. I ran some experiments a while back, and from that concluded that, if we look only at the technical side, LLM use can, in some niches, increase productivity for a programmer. There are certainly things that you shouldn't use an LLM for, but equally there can be cases where use of an LLM to perform some task that traditionally would have been done by a programmer would be a net positive.

But LLMs, as they exist today, are highly problematic.

They require vast amounts of data to build the model. The companies that build these models are disrespectful of people who run web services, and as a result, everyone now has to implement various types of application firewalls just to not make systems fall over from the overwhelming requests for data. They are also disregarding the licenses that are attached to these vast amounts of data, which makes me, as a person who believes in the tenets of free software, sad.

They require vast amounts of energy, causing an already-critical global warming crisis to, well, not improve.

They require vast amounts of coolant to dissipate the energy concentrated in their data centers, causing further environmental effects.

In this, they are problematic and to be avoided. But these are side states of the current state of affairs; I do not believe that they are inherently implied to be able to build and operate an LLM -- any LLM.

I guess it's fair to say that my feelings towards LLM usage are complex and many-faceted. I haven't been involved in many debates about the subject, debates that to me seem to be mostly focused on "LLM good" vs "LLM bad" arguments that aren't as nuanced as the position that I would believe is more accurate. This is not because I don't care, but partially because I've been busy in my personal life recently and partially because the whole thing seems somewhat disheartening.

But then Debian popped up GR 2026-002, meaning, I now have to come up with an opinion about various candidate statements in the context of the above, which is... not easy. But I did it anyway.

There are 8 choices on the ballot, and they all have some truth and some falsehood to them. My position about LLMs can be summarized as:

• The current state of affairs wrt LLMs is disastrous and we should not encourage them
• However, there's no technical reason why this must remain true for all time
• And so any statement should keep in mind what might happen in the future and that the current disastrousness of the whole thing isn't guaranteed to continue to exist for all eternity.

With that, let's go over them.

GR vote options

Proposal A

Its summary, from the GR text:

This proposal aims to expressly forbid any contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools.

This falls squarely in the "LLM bad" camp, outlawing all generative-AI contributions, disregarding potential future ones where the problematic situations that exist today are not present.

It makes a change to the social contract, which is especially difficult to reverse (on purpose), and which therefore also will require a 3:1 supermajority, but if we want to ban LLM-assisted contributions, this is probably the best way to do it.

Proposal B

This one tries to allow AI-assisted contributions under certain conditions. It's mostly an "LLM good" proposal, with some caveats that can be discribed as "make sure you know what you're doing".

Proposal C

This proposal is both a weaker (in some places) and stronger (in other places) version of Proposal A. It makes changes to the code of conduct instead of to the social contract, and it also wants to, at least, suggest policy to parties beyond the Debian project. By not changing the social contract, however, it is more likely to reach its simple majority requirement than proposal A.

I don't think the language that it wants to add to the code of conduct is particularly well phrased, however.

Proposal D

This is a weaker form of proposal B. The language is more compact and there are a few requirements that are spelled out in proposal B that are not spelled out in proposal D, but if you read between the lines you'll see that the requirement is still there really and I don't understand why proposals B and D were not merged into one.

Proposal E

This proposal tries to hold a middle ground between "LLM good" and "LLM bad". It appreciates that things are quite muddled at the present time, and that perhaps the situation might might change in the future. It acknowledges that certain questions remain unanswered and that perhaps future considerations might therefore be different. But it essentially refuses to take a stance on whether LLMs should be accepted by the project or not.

Proposal F

Similar to proposal E, this proposal tries to discourage Debian contributors from using LLMs, while still allowing people to use it should they want to, but with some requests and requirements to mark LLM-assisted contributions to account for those people who don't want to interact with LLM-generated software. As such, it is a proposal similar to proposal E that leans closer to the "LLM bad" camp.

Proposal G

This proposal aims to ensure that contributions directly to Debian are created by humans, while at the same time avoiding restrictions on the tools those humans may choose to use when contributing

Another "LLM bad" proposal, it however restricts the "bad" bits to only the direct output of the LLM. If you use an LLM to do something and then clean-room re-implement the same thing yourself, that's apparently fine.

Proposal H

This proposal condemns the use of LLM for its environmental and moral problems, but explicitly not for its technical considerations. I feel that it is closest to my position as explained above.

Voting

Expressing a vote on a ballot so convoluted and complicated like this one takes time. I have to read and understand every ballot option, and formulate an order of them.

And I shouldn't just state which option has my preference; Debian's voting process allows a rich expression of opinion on ballot options.

Anyway, I eventually ended up voting in a way that I think is consistent with my opinion. But it wasn't easy.

I’ve found my ideal format for shipping apps for personal & family use: PWAs, with an offline-first focus, rendering (mostly) entirely client-side. JavaScript is powerful enough to do pretty much anything these days - especially if you don’t have to write the code yourself.

If AI can generate an application from a description, is software still worth anything?

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

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

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

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

Free code changes what customers pay for

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

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

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

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

Dependability becomes the product

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

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

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

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

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

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

L’onanisme des utilisateurs de chatbots

Quand bien même les chatbots ne seraient pas les produits de gigantesques entreprises centralisées qui cherchent à nous exploiter en pourrissant nos cerveaux et Internet tout en étant une catastrophe écologique et sociale, je ne les utiliserais pas.

Quand bien même l’outil serait éthique à tous les points de vue, je le détesterais !

Le guitariste et le joueur de Guitar Hero

John Scalzi explique enfin pourquoi je n’aime pas ça. Parce que ç’est littéralement une perte de temps, un jeu vidéo qui ne sert à rien.

• Generative “AI”: The Guitar Hero of Creativity (whatever.scalzi.com)

Il prend l’analogie de Guitar Hero : oui, c’est fun. Mais, fondamentalement, c’est inutile. Vous n’apprenez rien ! En demandant à un chatbot de répondre à une question, de produire un texte ou une image, vous n’avez littéralement rien appris. Les études le montrent : un étudiant qui répond à une question d’un prof en utilisant ChatGPT est incapable de répéter cette réponse quelques minutes plus tard. L’investissement intellectuel est nul. L’étudiant est comme une interface transparente entre le chatbot et le prof.

Je l’ai vécu lors d’un examen où j’avais autorisé l’usage de l’IA : un étudiant a été incapable de répondre à une question alors que la réponse était affichée sur son écran.

• Giving University Exams in the Age of Chatbots (ploum.net)

Mais, comme Guitar Hero, jouer avec un chatbot est amusant, voire addictif.

Je le comprends très bien. J’ai pris une demi-heure pour jouer avec la génération d’images de Lumo, le chatbot de Proton. Je lui ai demandé une couverture de Bikepunk et j’ai itéré en notant les défauts. J’avais plein de choses à dire sur l’output (notamment que, quoi qu’on fasse, une jeune femme à vélo doit obligatoirement porter un crop top). C’était très marrant de voir que quand j’ai précisé que je voulais que le personnage masculin ressemble à Thierry Crouzet, il a soudainement acquis une musculature impressionnante. Ce n’est pas que Thierry n’est pas musclé en vrai, mais, quand même, j’évite d’éternuer trop fort dans sa direction.

Et là, vous voyez le truc : c’était amusant. Ça me donnait envie de partager les différentes images.

Mais, en réalité, quand on n’est pas dans le délire, c’est juste nul. C’est comme regarder un pote jouer à Guitar Hero : il s’éclate, mais c’est un peu emmerdant pour le public. Voir c’est gênant. Un peu comme si vos amis vous racontaient à quel point leurs dernières séances masturbatoires étaient jouissives.

L’utilisation de l’IA est un plaisir solitaire. Je n’ai rien contre le fait que ça vous amuse, mais, par pitié, ne le partagez pas avec moi !

On ne gagne pas du temps en poussant sur un bouton

Les gens disent gagner du temps avec l’IA, mais ils n’améliorent pourtant pas leur productivité. Le paradoxe viendrait que le temps pris à utiliser l’IA lui-même ne serait, intuitivement, pas pris en compte.

• AI Isn’t Breaking Work. It’s Already Broken. (calnewport.com)

C’est un paradoxe bien connu des bons managers : le management prend du temps et de l’énergie. Souvent plus que faire les tâches soi-même. Si tu engages un jardinier pour tondre ta pelouse, tu dois trouver le jardinier, le contacter, convenir d’un rendez-vous, négocier un tarif puis, une fois qu’il est là, lui expliquer le travail, vérifier qu’il a bien compris et puis vérifier qu’il a fait tout correctement.

Outre l’argent que ça coûte, cela n’est clairement pas une tâche anodine. En fait, si c’est juste pour faire une seule fois un petit jardin, c’est beaucoup plus rentable de tondre ta pelouse toi-même. Le bénéfice ne se fait sentir que lorsque tu as confiance et que tu as un accord pour que le jardinier vienne une fois par mois tondre une grande pelouse, sans même avoir besoin de te prévenir.

Les jeunes parents connaissent tous cela : junior veut absolument aider au montage du meuble Ikea, mais, honnêtement, ça te prend cinq fois plus de temps que de le faire tout seul.

On en est là avec l’IA. Parfois on gagne un peu de temps (une vraiment grande pelouse à tondre), parfois on en perd (l’armoire Ikea), mais l’attrait de la nouveauté fait que c’est fun. Un peu comme le fait de regarder un jardinier travailler depuis son salon en lui donnant des ordres. Cela donne un sentiment de puissance. C’est littéralement masturbatoire.

Le problème c’est que la rentabilité à long terme de notre jardinier se base sur le fait de créer une confiance, un automatisme. Et là, on est face à une entreprise de jardinage qui a un monopole mondial, qui augmente ses tarifs arbitrairement et envoie, à chaque fois, un nouvel ouvrier qui ne connait pas votre jardin, mais fait semblant du contraire. En plus, il est sous ecstasy.

Vos outputs de chatbots sont de la pollution

Mon principal grief, c’est que les utilisateurs des chatbots sont persuadés d’avoir une compétence ou une valeur ajoutée quelconque. J’en ai été témoin de première main : les projets open source sont noyés de contributions générées. Souvent, les utilisateurs sont de bonne foi : ils ont réellement trouvé un bug et plutôt que de le rapporter, ils demandent à un LLM de générer un patch.

Parfois, ils poussent le vice jusqu’à faire écrire le rapport de bug par le LLM. Ils sont très fiers.

Fier de quoi ? D’avoir cliqué sur l’icône Claude ou ChatGPT ?

Et c’est une catastrophe : parce que le mainteneur doit désormais tenter de comprendre dans tout ce charabia et ce jargon quel est le problème de base. Au lieu d’avoir un utilisateur qui se plaint, parfois un peu maladroitement, nous sommes face à une machine qui réinterprète tout et il faut deviner ce que l’utilisateur avait en tête. En gros, il faut essayer de déduire le prompt.

Ce n’est déjà pas évident de se comprendre entre humains en communication directe alors si un chatbot sert d’intermédiaire…

Ou cette connaissance à qui je pose une question et qui m’envoie la réponse de ChatGPT. Comme si c’était d’une aide quelconque. Parce que si je demande quelque chose à quelqu’un, c’est vraisemblablement parce que je ne trouve pas de réponse facile et que je pense que cette personne a une expertise du domaine. Me renvoyer la réponse de ChatGPT est à la fois injurieux (tu n’en as rien à foutre de m’aider) et hautain (tu penses que je ne suis pas capable de faire une recherche Web).

Que ce soit clair : un output de chatbot n’est pas fait pour être partagé. Si vous souhaitez le faire, alors partagez juste le prompt, ce sera beaucoup plus efficace.

De plus en plus d’artistes professionnels se plaignent : plutôt que d’avoir des instructions claires, les clients leur envoient des « idées » générées par IA. Et les artistes doivent deviner ce que veulent leurs clients.

Le chatbot, c’est comme la masturbation : pratiquez-le seul ou dans un cercle restreint d’adultes consentants. Jamais en public. Jamais en présence de personnes non consentantes. Jamais dans un cadre professionnel.

Apprendre de ses expériences

Mais le principal problème, outre l’opacité de la communication, c’est ce que dit Scalzi avec Guitar Hero ou comme le montre l’analogie de la masturbation : vous n’apprenez rien.

Vous ne saurez pas jouer bon anniversaire à la guitare même après des centaines d’heures de Guitar Hero. Vous ne rencontrerez jamais un partenaire amoureux en vous masturbant. Ce n’est pas un jugement de valeur : c’est juste que ces activités n’ont pas le moindre rapport entre elles !

L’énorme majeure partie des patches que je reçois pour mes projets Open Source me prennent plus de temps à relire et à intégrer que si je le faisais moi-même. Pourtant, j’apprécie cela, car je sais que la personne a dû fournir un effort pour comprendre mon code. Elle a appris. Et, petit à petit, elle va être de plus en plus à l’aise pour faire des changements plus importants tandis que moi, j’aurais appris à lui faire confiance. Je peux également poser des questions sur les choix techniques qui ont été faits, en discuter, remettre en question mes propres perspectives, mes propres choix.

Accepter un patch n’est jamais un gain de temps, c’est un investissement sur le futur. C’est également une manière de faire grandir deux personnes.

Ce qui n’est pas le cas avec les patchs générés. C’est même exactement le contraire : accepter un patch généré va introduire dans le projet du code qui fonctionne peut‑être aujourd’hui, mais que personne ne comprend et, surtout, dont on ne peut même pas présupposer qu’il a une logique.

Si vous n’avez rien appris en utilisant un chatbot et si la personne qui reçoit l’output n’apprend rien, pourquoi le faire tout court ?

Un tas de débris aléatoire n’est pas une maison

Vous vous souvenez de l’expérience de pensée qui dit que si on assied assez de chimpanzés qui tapent aléatoirement sur des machines à écrire, on va finir par générer du Shakespeare ou du Proust ?

Et bien c’est exactement ce que font les chatbots avec le code : ils génèrent presque aléatoirement des morceaux de code jusqu’à ce que le code en question réponde superficiellement à la question. Ça fonctionne, parfois, ici et maintenant, mais, bien entendu, ça va craquer de partout dès qu’on bouge quelque chose.

Un peu comme si on construisait une maison en jetant aléatoirement des poutres et des briques jusqu’à ce que, ô miracle de la loi des grands nombres, l’édifice de matériau dégage un espace assez grand pour qu’on l’appelle "chambre" avec une ouverture appelée "porte". Ce serait cool.On prendrait des photos.

Mais pensez-vous sérieusement que cette "maison" tiendrait face à la première pluie, au premier souffle de vent ou à la première vibration d’un camion sur la route ?

De la même façon, communiquer par écrit est une compétence qui se travaille. C’est même plus important que cela : l’écrit permet de structurer ses propres pensées. Tant que vous n’avez pas écrit vos idées, elles ne sont pas réelles, pas claires.

Tant que vous n’avez pas fixé votre idée sur un support, elle ne vaut rien. Et si ce n’est pas vous qui la fixez, ce n’est pas votre idée.

• Votre idée ne vaut rien (ploum.net)

En déléguant l’écriture de vos emails et de vos rapports, non seulement vous perdez la compétence communicationnelle, mais, pire, vous perdez simplement vos idées.

Les singes bientôt remplacés ?

Dans le cliquetis des milliards de machines à écrire actionnées par les singes, une feuille tomba soudainement sur le sol. Un entrepreneur s’en saisit et lut : « Longtemps, je me suis couché de bonne heure… »

— Ça y est, hurla-t-il ! Nous avons réussi ! Ce singe écrit du Proust !

Le singe en question fut mis sur un piédestal, choyé, dorloté. Mais les entrepreneurs avaient beau faire, il n’écrivait plus que du charabia sans signification.

— Dommage, fit un entrepreneur. Peut-être n’est-ce pas la bonne approche.
— Et si nous remplacions les singes par des utilisateurs de ChatGPT ?
— Pas bête. Statistiquement, ça devrait fonctionner…
— Et puis, on ferait des économies de bananes !

L’arnaque du bilan carbone

Pourquoi nous nous sommes fait avoir dans notre soi-disant lutte contre le réchauffement climatique

Ne plus prendre l’avion, acheter des électroménagers de moindre consommation ou se déplacer en voiture électrique semblent être les mesures antiréchauffement climatique dont j’entends le plus parler. Ça et guillotiner les milliardaires qui voyagent en jet privé. D’ailleurs, les estimateurs de bilan carbone pullulent.

Mais je suis de plus en plus convaincu que c’est une grossière erreur. Nous sommes en train de compter nos grammes de CO₂ produits et cela a probablement autant d’impact que faire pipi sous la douche. Cela nous occupe pour nous donner l’impression de faire quelque chose tout en permettant aux politiciens de ne surtout rien changer.

Comprendre le réchauffement climatique.

Revenons à la base. Il existe sur la planète une quantité fixe de carbone qui est invariable (on peut oublier les très rares apports de météorites). De ce carbone, une grande quantité est prisonnière dans le centre de la terre dont elle s’échappe parfois lors des éruptions volcaniques. Mais simplifions et oublions cela.

Nous avons donc une quantité de carbone fixe pour la surface et l’atmosphère, que j’appelle « le système surface ».

Il y a des milliards d’années, il n’y avait pas d’oxygène dans l’atmosphère, mais énormément de gaz carbonique. L’abondance de CO₂ a permis une explosion de la vie, principalement le plancton, extrayant le carbone de l’atmosphère grâce à la photosynthèse. Mais la photosynthèse produit un déchet éminemment toxique pour beaucoup de formes de vies : l’oxygène !

Cette période porte le nome de « Grande Oxydation ».

• Grande Oxydation (fr.wikipedia.org)

Heureusement, ce processus ayant eu lieu sur des centaines de millions d’années, des formes aérobiques ont eu le temps d’évoluer, formes de vie qui survivaient grâce au processus inverse : consommer de l’oxygène et produire du CO₂ Nous faisons nous-mêmes partie de cette forme de vie. Nous devons donc ingérer du carbone, via l’alimentation, afin de le brûler avec de l’oxygène pour produire de l’énergie et expirer le déchet, le CO₂

Un point particulièrement important est que la somme du carbone de la surface et du carbone de l’atmosphère n’est jamais modifiée. S’il y a plus de plantes et de planctons, le carbone est fixé sur la surface et dans les océans. S’il y a plus d’humains et d’animaux, il y a un peu plus de carbone dans l’atmosphère. Mais la somme des deux reste constante.

Lorsqu’un être vivant meurt, quel qu’il soit, son carbone est soit rendu à l’atmosphère via la décomposition (qui est une forme de combustion), soit intégré à un autre être vivant via l’alimentation.

La fossilisation du carbone

Une troisième voie est cependant possible. Lorsqu’un « cadavre » s’enfonce dans le sol ou dans un fond marin, son carbone est comme capturé par la planète. Il ne peut plus rejoindre l’atmosphère ni être consommé. Avec le temps et les très hautes pressions, ce carbone se fossilise.

Les plantes fossilisées deviennent essentiellement du charbon tandis que les autres formes de vie, principalement les espèces de planctons, se transforment en hydrocarbures : pétrole et gaz fossile (aussi appelé « gaz naturel »).

Le point le plus important de cette fossilisation est qu’elle a retiré énormément de carbone de la surface. Au fil des milliards d’années, le taux de CO₂ de l’atmosphère a donc chuté de manière extrêmement importante, entraînant un refroidissement climatique. Le CO₂ a en effet la propriété de « capturer » la chaleur du soleil comme le ferait une serre. Cette particularité du CO₂ a été mainte fois observée et prouvée depuis la moitié du 19e siècle.

• Eunice Newton Foote (fr.wikipedia.org)

Avec moins de CO₂ dans l’atmosphère, la terre s’est lentement refroidie, au détriment de certaines espèces, mais au plus grand bonheur d’autres dont l’Homo Sapiens Sapiens. Le « lentement » est important. On parle de dizaines de millions d’années.

L’extraction du fossile

Le grand malheur de notre espèce est que, depuis la révolution industrielle, nous avons découvert que ce carbone fossile brûle très bien. C’est donc un formidable réservoir d’énergie, de joules, que chacun veut exploiter. En fait, on sait depuis longtemps qu’il brûle bien, mais les réserves étaient inaccessibles : il fallait plus de joules pour extraire du charbon que ce qu’il produisait en brûlant. L’invention du moteur à vapeur va changer la donne et permettre l’industrialisation des mines de charbon puis des puits de pétrole (relisez « À l’ombre des derricks »).

Comme me le disait Philippe Samyn, le Joule est l’unité qui fait tourner le monde. Et le carbone fossile en est une fameuse réserve.

• Qucocoma Philippe Samyn ? (ploum.net)

Mais, en brûlant ce fossile, nous remettons en circulation dans l’atmosphère du carbone qui était séquestré depuis des millions ou des milliards d’années.

Le changement climatique est bel et bien humain, la question ne devrait même pas se poser vu que chaque puits de pétrole, chaque mine de charbon et chaque gisement de gaz n’a, au fond, qu’une seule utilité : remettre dans l’atmosphère du carbone qui n’y était plus depuis des milliards d’années.

J’espère que cette explication cloue aussi définitivement le bec aux idées absurdes comme le fait que les cyclistes contribuent également au réchauffement climatique en respirant et en mangeant des côtelettes. Que vous mangiez un steak ou une salade de pois chiche, tout le carbone que vous consommez était encore dans l’atmosphère il y a quelques jours. Vous n’ajoutez aucun atome au système de la surface. Par contre, allumez la flamme d’un briquet et vous êtes littéralement en train d’envoyer dans l’atmosphère du carbone qui n’y était plus depuis des milliards d’années.

Ce billet est également la réponse à l’idée parfois entendue que cette recarbonisation serait « naturelle ». Il a fallu des milliards d’années pour capturer ce carbone que nous relâchons presque totalement en moins de 200 ans ! C’est 10 millions de fois plus vite ! Aucune adaptation du vivant ne peut se faire à cette vitesse !

Le renouvelable est-il la solution ?

Intuitivement, vous vous dites qu’il suffit de ne pas utiliser de briquet et de passer à une énergie dite « renouvelable », des joules propres produits sans carbone fossile. Qu’il faudrait consommer « intelligemment » pour savoir combien de grammes de CO₂ ont été produits pour tel ou tel objet.

Mais c’est à la fois très compliqué à calculer et complètement inutile.

Tout l’effort pour passer vers le renouvelable se base sur la théorie (essentiellement fausse dans le monde réel) de l’offre et la demande en se disant que « si le renouvelable devient moins cher, les gens n’achèteront plus de pétrole et les puits ne seront plus rentables et donc se fermeront ».

Cela permet aux néolibéraux de se déclarer écologistes, mais c’est évidemment complètement et dangereusement faux. À l’heure actuelle, la moitié du pétrole extrait sert à déplacer l’autre moitié jusqu’aux pompes ou aux centrales tout en restant l’un des produits les plus rentables du monde !

Tout le pétrole, charbon et gaz déjà extrait sera consommé, quoi que vous fassiez. Une fois extrait, le carbone fait littéralement partie du système de la surface. À moins d’arriver à convaincre 100% des humains de ne plus utiliser de pétrole ou de charbon et de laisser intactes les réserves mondiales, ce dont je doute fort, il sera brûlé. Même si le pétrole devenait soudain beaucoup trop cher, il serait revendu à perte (vu que déjà extrait). Et il restera toujours un atout stratégique essentiel des armées, ce qui lui confère une valeur intrinsèque importante (le jet supersonique, le missile balistique et le char d’assaut sont difficilement imaginables en version électrique).

La seule mesure réaliste et efficace pour lutter contre le réchauffement climatique est d’arrêter l’extraction de carbone fossile. Point à la ligne. Tout le reste n’est que poudre aux yeux malhonnête ou confondante naïveté.

Entendons-nous bien : toutes les mesures « écologiques » sont généralement positives et procurent bien des avantages (moins de particules fines, moins de pollution dans les océans ou les sols …). Je les encourage fortement. Mais, quand on parle du réchauffement climatique, elles nous distraient de l’essentiel.

Capturer le carbone

Planter des arbres, c’est pas mal. J’aime beaucoup les arbres. Cela permet de modifier l’équilibre sol/atmosphère, ce qui est toujours appréciable. Mais il faut en planter beaucoup et s’assurer qu’ils ne brûlent pas. Même avec beaucoup d’arbres, le carbone fait désormais partie de notre cycle de surface !

Prétendre que planter des arbres contrebalance l’extraction fossile est une escroquerie pure et simple, car, en pourrissant ou en brûlant, le carbone de l’arbre va bientôt revenir dans l’atmosphère. Et quand bien même c’est utile, le mécanisme économique des certificats de compensation carbone est une arnaque qui entraîne plus d’émissions !

• Les mécanismes de compensation carbone expliqués à mon hamster (ploum.net)

C’est également la raison pour laquelle les tentatives d’extraction industrielles du carbone de l’atmosphère sont vouées à l’échec. Il faudrait non seulement extraire plus de carbone qu’on en produit, mais aussi arriver à le fossiliser, à faire en sorte que celui-ci ne puisse plus jamais revenir dans l’atmosphère.

Certains imaginent capturer le carbone dans le béton de constructions, mais l’échelle est ridicule par rapport à la quantité de carbone fossile qui est extraite à chaque seconde. Et, au fond, mettre du carbone dans nos constructions, ça s’appelle des planches en bois. Mais comparez cela avec la quantité de barils de pétrole extrait à chaque instant.

De nouveau, on tente de se distraire, d’imaginer toutes les solutions les plus absurdes les unes que les autres. Toute sauf la seule réelle : arrêter l’extraction.

Parce que je ne vois pas d’autres solutions

Il suffira de quelques jours froids cet hiver pour faire oublier les canicules de 2026 et entendre les habituels poncifs sur le déni du réchauffement climatique. Et puis, quand bien même le sujet reviendrait dans l’actualité, les militants accuseront les jets privés et les politiques annonceront une prime pour l’installation de panneaux photovoltaïques. Les geeks se rassureront en achetant un smartphone « éthique » avec un chiffre arbitraire de grammes de CO₂ sur la boîte (qui est bien, car entouré en vert).

Il n’en reste pas moins que chaque litre de pétrole, chaque kilogramme de charbon extrait contribue au réchauffement climatique. Que les entreprises qui se livrent à cette activité sont criminelles, que leurs cadres devraient être traduits en justice pour tous les morts et toutes les catastrophes climatiques. Bref, pour crime contre l’humanité.

Les états devraient en prendre la mesure et interdire toute importation de produits issus de l’extraction du carbone fossile.

C’est la seule solution réelle si nous voulons efficacement ralentir puis stopper le réchauffement climatique. Il n’y a pas de demi-mesures possibles. Et, en plus, c’est techniquement assez simple. Il « suffirait » d’une résolution de l’ONU suivie d’un Nuremberg du climat.

Mais, franchement, vous y croyez vous ?

Vous connaissez un seul politicien qui pourrait être élu avec cette idée ?

Alors on va aller faire pipi sous la douche en tentant de se convaincre que la fameuse parabole du colibri n’est pas une pure intoxication néolibérale pour rejeter la culpabilité d’une catastrophe planétaire sur les choix de consommation de l’individu.

Je suis sans cesse tiraillé entre l’idée qu’il faut que je produise moins de CO₂ et la certitude que, de toute façon, cela ne sert à rien : tout carbone fossile extrait sera bientôt dans l’atmosphère, que ce soit demain ou dans dix ans.

Il n’y a pas de bilans carbone honnêtes. Il n’y a que le carbone de surface et le carbone fossile. Si nous ne condamnons pas rapidement et durement ceux qui extraient le carbone fossile, le trou qu’ils sont en train de creuser sera la tombe de l’humanité…

• Photo d’un puit de pétrole en feu au Koweit par Habib Hassan Kuwait

This is the third post in a series about making my site's search available to AI agents. First, I published an API Catalog, which helps agents that already know to check my site find its search API. Second, I added an Agentic Resource Discovery (ARD) entry so my search can be indexed by "AI registries" (think search engines for AI agents).

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

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

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

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

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

You can call it from any terminal

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

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

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

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

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

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

Discovery and invocation are separate layers

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

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

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

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

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

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

Un manifeste Offpunk

Ce texte est une traduction en français du Offpunk Manifesto rédigé par Arlon de Serra Grande et que j’ai co-signé

• An Offpunk Manifesto (English version)
• Versão em português
• Traduzione italiana

La révolution ne sera pas numérique

Alors que l’hyperconnexion apparait comme le symptôme d’un futur inéluctable, un timide mouvement semble prendre de l’ampleur : celui de la déconnexion volontaire et intentionnelle. L’adoption des « dumb phones » est en train de croître. Les appareils photo numériques font leur retour. Tout comme les cassettes audio et les machines à écrire… Il existe un mouvement pour se réabonner à la presse papier. Même le minidisc, vite oublié après le succès des lecteurs MP3, semble renaître de ses cendres.

Au début du siècle, Internet semblait être la dernière pièce pour mettre en place le fameux « village global » de Marshall McLuhan. Les ordinateurs, rares et chers (et donc parfois partagés) étaient des portails vers un autre monde. Les gouvernements consacraient beaucoup d’argent pour s’assurer que même les plus pauvres ne soient pas des exclus numériques.

Et nous y sommes arrivés ! Nous allons bientôt passer le cap de trois appareils connectés par humain, selon l’estimation du Cisco Visual Network 2020.

• Global_2020_Forecast_Highlights.pdf (www.cisco.com)

Le numérique est partout et considéré comme acquis. Que nous le voulions ou non, nous sommes tous connectés en permanence. Car nous ne nous connectons plus à Internet : nous y vivons sans plus jamais le quitter !

Comme si nous portions un uniforme, nous gardons toutes et tous notre téléphone dans notre poche pour travailler, pour vivre, pour aimer et sous l’oreiller pour dormir.

Le numérique a cessé d’être un outil pour devenir un environnement duquel on ne peut s’échapper. Autrement dit une prison.

« Préserver le non numérique n’est pas un retour vers le passé, c’est un devoir »
— Giulio Cavalli

Lorsque la connexion, même non nécessaire, devient obligatoire, la résistance ne consiste pas à détourner le système, mais bien à refuser tout simplement d’en faire partie.

Comme l’écrit l’auteur belge de science-fiction et développeur informatique Ploum, les punks de notre époque sont ceux qui osent vivre sans smartphone. Ce sont des « offpunks », comme je les appelle désormais.

• La complainte du technopunk ringard (ploum.net)

La connexion est une arme de guerre

La première conséquence de cette centralisation monopolistique de la technologie est que la fourniture d’un accès à Internet est devenue une arme de guerre. Lorsque les grandes puissances entrent dans un conflit, elles ne cherchent plus seulement à perturber l’approvisionnement en eau ou en énergie, mais également à couper l’accès à Internet ou à certains services en ligne. La Russie a utilisé plusieurs fois cette tactique contre l’Ukraine. Israël fait de même contre la Palestine.

Fin 2025, le juge français Nicolas Guillou de la Cour Pénale Internationale a perdu ses accès à plusieurs services en ligne américains, dont Airbnb, Amazon et Paypal. La justification de cette sanction prise par les États-Unis était que Nicolas Guillou avait signé un mandat d’arrêt contre le Premier ministre israélien Benjamin Netanyahu et son ministre de la défense Yoav Gallant, suite au caractère génocidaire des attaques israéliennes contre les territoires palestiniens. Les États-Unis sont pourtant l’un des seuls pays à soutenir les actions d’Israël au Proche-Orient.

La philosophie Offpunk est née de constatations simples, mais inconfortables : le monde numérique est fragile et notre vie sociale est intrinsèquement liée à notre environnement. Le corollaire évident est que nous ne devrions jamais dépendre entièrement de services propriétaires virtuels, car nous pouvons en être exclus sans préavis.

De nombreux exemples illustrent notre dépendance envers cette fragile infrastructure : le bug Microsoft qui a mis hors service des milliers de banques, de transports et de services critiques en 2024, le gouvernement brésilien qui a bloqué Twitter/X en 2024 ou la panne globale d’Amazon et Cloudfare qui a rendu une bonne partie des sites web injoignables fin 2025.

Lorsqu’un système est injoignable, que ce soit à cause d’une panne, d’une sanction politique ou d’une guerre, tout un univers virtuel disparaît purement et simplement. Vous n’avez aucun recours si le numérique connecté était votre seule option.

Après tout, une connexion permanente à haut débit n’est jamais garantie, spécialement dans les pays en voie de développement ou qui connaissent des troubles politiques. Même les pays riches et industrialisés ne sont pas à l’abri. À cause de sa politique de gestion de l’énergie, la ville de Sao Paulo, au Brésil, connait des coupures d’électricité fréquentes lorsqu’il pleut.

Dans ces pays, avoir un plan B « analogique » est une question de survie.

Le minimalisme numérique et l’Offpunk

Il ne faut pas confondre le mouvement « Offpunk » et le minimalisme numérique.

Le minimalisme numérique est une vision individuelle et autonome de la déconnexion, sans aucune remise en question des tendances sociétales et des structures de pouvoir.

Puisqu’une vie complètement déconnectée n’est plus possible, le minimalisme numérique tente de supprimer les aspects les plus addictifs et les plus envahissants de la connexion permanente.

Off, ma non troppo.

Mais ce dont nous avons réellement besoin c’est d’une possibilité de se déconnecter réellement, d’avoir le droit de vivre et de nous déplacer sans emporter avec soi un téléphone suffisamment récent, suffisamment chargé et avec un forfait suffisant pour être connecté 24h sur 24.

Dans "Digital Detox: The Politics of Disconnecting" (2020), Trine Syvertsen démontre comment la mouvance du minimalisme numérique contribue à un agenda néo-libéral qui fait endosser par les individus, comme l’utilisateur lambda d’un smartphone, la responsabilité de résoudre les problèmes structurels auparavant gérés par des institutions collectives. L’autrice identifie trois raisons principales qui motivent le minimalisme numérique, les 3 « P » : présence, productivité et vie privée. Les trois étant des motivations purement individuelles.

En d’autres termes, si vous avez l’impression de rater des moments importants de sociabilité, si vous n’êtes pas productifs dans votre travail ou vos projets à cause des notifications ou si vous n’aimez pas être espionné en permanence par les grands monopoles de la tech, c’est uniquement de votre faute, car vous n’avez pas assez d’autodiscipline. Ce n’est en rien lié à l’économie de l’attention, au capitalisme de surveillance et aux logiciels conçus pour être addictifs.

Ce déchargement de la responsabilité fait notamment partie de l’analyse de la société contemporaine par l’intellectuel germano-coréen Byung-CHul Han dans son livre « The Agony of Eros ». Il y dit notamment :

L’auto-exploitation est bien plus efficace que l’exploitation par d’autres, car elle donne une impression de liberté.

Un autre symptôme de ce déchargement des responsabilités sont les caisses automatiques et les distributeurs en libre-service dans les supermarchés, les banques voire les pharmacies. Le client doit désormais faire le travail des employés, le plus souvent sans aucune aide et pourtant sans payer moins cher. S’il y a une erreur dans le processus, c’est de toute façon le compte en banque du client qui sera débité, pas celui de l’entreprise.

Bien qu’initialement issue d’une tendance technophile, la mouvance Offpunk, au contraire du minimalisme numérique, promeut une déconnexion simple et sans prétention. Une déconnexion non excluante des activités sociales ou de l’exercice de ses droits de citoyen·ne·s.

Quand le minimalisme numérique voit la détox numérique comme un outil d’amélioration de la productivité, les offpunks envisagent la déconnexion comme une attitude anti-consumériste.

Définitions

Le mouvement Offpunk n’est pas un style de vie, c’est un positionnement par rapport à notre usage du numérique, une forme de quête de sevrage numérique collective qui explore les impacts sociaux et politiques de la déconnexion. Le mouvement tente de permettre aux individus de se réapproprier leurs loisirs, leur citoyenneté et leurs communications sans passer par un intermédiaire numérique incontournable. L’Offpunk ne s’oppose nullement à Internet ou à la technologie, il cherche juste à rendre possible une vie sans connexion permanente.

Dans son positionnement, Offpunk se rapproche plus des méthodes non dogmatiques comme la méditation ou les techniques de guérilla.

De plus, il est particulièrement remarquable que même les activités professionnelles traditionnellement analogiques, comme l’enseignement, soient de plus en plus envahies par le numérique. L’utilisation d’Internet est de plus en plus liée au travail et le terme même de « déconnexion » implique le loisir ou l’oisiveté.

En conséquence de quoi, la philosophie Offpunk défend le fait de vivre sa vie au sens large, au-delà de la séparation travail/vie privée.

Paradoxalement, toutes ces couches inutiles numériques dans notre vie quotidienne rendent l’interaction analogique et directe de plus en plus efficace ou confortable pour résoudre nos problèmes du quotidien (voir aussi la section « Instruments Offpunk »).

Offpunk embrasse autant l’adolescent qui achète un téléphone basique et rejoint un club luddite, un audiophile qui quitte Spotify pour se créer une collection de vinyles ou un lecteur MP3 hors-ligne, un expert qui utilise des systèmes de cybersécurité minimalistes. Le mouvement comprend également les militants qui luttent contre l’obsolescence programmée, qui installent Linux ou des ROMs dédiées sur des appareils normalement condamnés, un indépendant qui désactive Facebook et Instagram pour se concentrer sur ses clients directs voire une personne âgée qui refuse le smartphone pour effectuer ses démarches administratives.

Offpunk n’est pas de la nostalgie ! Ce n’est pas une technophobie naïve ou une idéalisation romantique d’un passé imaginaire. C’est, avant toute chose, la quête d’une indépendance et d’une souveraineté. Pour paraphraser Edouardo Fernandes :

La révolution technologique n’est pas révolutionnaire et se laisser dépasser n’est pas réactionnaire.

• Geriatria da tecnologia (textosobretela.com)

L’esthétique Offpunk

Offpunk n’a pas encore de visage, mais certains indices peuvent nous permettre de voir à quoi il va ressembler. La première vient d’une définition que donne Ploum de ses propres actions sur Internet : « Technopunk », un technophile antisystème.

• La complainte du technopunk ringard (ploum.net)

Comme mentionné plus haut, Offpunk est un positionnement envers la technologie contemporaine, pas une utopie/dystopie ou une esthétique visuelle culturelle, comme le sont les mouvements Solarpunk ou Cyberpunk.

Quelques exemples :

1) En informatique, le navigateur Offpunk, qui donne son nom à ce manifeste, et le protocole Gemini.

• Offpunk browser
• Project Gemini (geminiprotocol.net)

2) En design, le concept du « Forever Computer » ou le téléphone Mudita Kompakt.

• The computer built to last 50 years (ploum.net)
• Mudita Kompakt, a minimalist E Ink® phone. (mudita.com)

3) Dans la société, le New York Luddite Club

4) Dans la culture, le roman « Bikepunk » (2024) ou le film « One Battle After Another » (2025)

• Philosophie politique du bikepunk (distinguos.net)

Dans One Battle After Another, l’obsolescence, le « downgrade » est une stratégie pour conquérir sa liberté. Les personnages reviennent à des anciens appareils personnalisables pour créer un réseau de communication parallèle. Lorsque les nouvelles technologies apparaissent, comme le smartphone, elles ont pour objectif de mettre les personnages en danger, de les empêcher de réaliser leurs plans voire de les supprimer tout simplement.
— Edouardo Fernandes

Dans le film Germano-japonais « Perfect Days » (2023), on peut voir la routine idyllique de Hirayama, un nettoyeur de toilettes publiques à Tokyo, qui, dans son temps libre, prend des photographies, écoute des cassettes audio, se déplace à bicyclette et lit des livres avant de dormir. La particularité étant qu’il semble apprécier chaque moment de sa vie tout en étant totalement déconnecté.

Au Japon, un pays qui a toujours cherché l’équilibre entre la modernité et la tradition, on trouve encore partout des terminaux pour payer en espèce, des lignes téléphoniques fixes pour conduire la majorité des communications professionnelles et d’anciennes technologies encore utilisées par les plus grandes entreprises, comme le fax ou les disquettes.

En Inde, qui possède l’un des meilleurs réseaux téléphoniques du monde, un citoyen passe en moyenne 90 appels par jour !

Priorités du mouvement Offpunk

Offpunk s’inscrit dans les luttes sociétales plus larges telles que :

1) La lutte contre la surproduction

2) La lutte contre l’obsolescence programmée

3) La lutte contre « l’Internet of Things », qui veut que chaque objet, même le plus mondain, soit connecté, récolte des données envoyées à Big Data, nécessite des mises à jour et des applications externes.

4) La lutte contre l’économie de l’attention

5) La réduction des heures de travail qui sont de plus en plus virtuelles

6) Le droit au loisir, à la citoyenneté et au travail sans avoir besoin d’un appareil numérique connecté.

7) Le droit à l’inclusion des populations précarisées ou plus âgées qui dépendent non seulement d’un accès à un appareil numérique connecté, mais doivent également avoir les moyens de se former et de s’adapter pour le mettre à jour et continuer à l’utiliser en dépit des changements introduits.

L’éditorialiste italien Giulio Cavalli disait :

C’est vrai : la digitalisation simplifie, accélère et standardise les procédures. Mais seulement pour ceux qui ont les moyens d’en faire partie. Pour tous les autres, la porte du futur est en train de se fermer.

• Garantire il non-digitale è un diritto, non un ritorno al passato (www.lettera43.it)

Les outils Offunk

1) Le paiement en espèce. Pratique, ne nécessitant ni électricité ni Internet et garantissant que vos données personnelles ne sont pas stockées, agrégées, ni revendues.

2) Les médias analogues. Garantissant qu’une communication reste possible sans Internet et que les données vous appartiennent bel et bien. Disques, livres, journaux, radio…

3) Les médias numériques indépendants et décentralisés. Email, sites web « brutalistes » ou minimalistes, flux RSS, appareils photo numériques non connectés, lecteurs MP3, dumbphones…

4) Stockage et transfert physique des données. Disques durs, clés USB, cartes mémoires ou solutions en ligne indépendantes et contrôlées individuellement. Afin de garantir que nos données ne dépendent pas du bon vouloir d’un « cloud » propriétaire.

5) Des protocoles de communications décentralisés : messagerie via Bluetooth (Bitchat), protocole Gemini, emails chiffrés, Tor, XMPP…

Les challenges

1) La première difficulté est la commodité, la convénience des outils propriétaires : amusement, normes sociales, ubiquité.

2) L’accès aux espaces sociaux qui nécessitent de plus en plus un outil numérique : concerts, parking, cinémas, clubs de sport voire menus de restaurants.

3) Construire des réseaux de relations, y compris professionnelles, sans intermédiaire numérique.

Nous défendons le droit non négociable à un monde non numérique. Le droit de partager sans algorithmes, de nous organiser socialement sans plateformes centralisées. Le droit de ne pas être en permanence connecté ni espionné.

Tant qu’une poignée de sociétés maintiendra un monopole sur la technologie, tant qu’une surveillance de masse sera en place avec la complicité des États, sans la moindre transparence sur les moyens mis en œuvre ni l’utilisation de ces données, tant que l’économie de l’attention pourra monnayer nos temps libres contre de la publicité, tant que les infrastructures mettront à mal l’indépendance des pays du Sud, tant qu’il y aura une digitalisation forcée alors que les accès à Internet ne sont pas considérés comme un droit basique, alors la révolution ne sera pas numérique !

Ce texte a été initialement rédigé en Portugais par Arlon de Serra Grande et cosigné par Ploum (Lionel Dricot)

• Versão em português

An AI model does not decide what data it can access, which tools it can use, or whether it can act without approval. People make those decisions at different points. Upstream, a model developer trains and tests the model and decides whether and how to release it. Downstream, a developer builds the model into a system, connects that system to data and tools, and decides whether a person must review its proposed actions before they take effect.

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

Responsibility should follow meaningful control

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

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

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

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

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

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

Open-weight models unbundle control

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

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

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

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

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

Open Source shows how responsibility follows control

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

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

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

Products turn capability into authority

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

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

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

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

Regulate AI at each point of control

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

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

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

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

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

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

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

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

Require extraordinary evidence to block a release

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

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

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

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

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

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

Default to openness with distributed responsibility

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

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

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

In April 2025, I published Claude Code meets Drupal, my first public experiment with an AI coding agent. I have been experimenting with coding agents ever since, often by building tools to solve problems in my own work.

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.

A git worktree workflow eats a lot more disk than you’d expect. On the remote box I run my coding agents on , ten worktrees took a 28 GB volume down to 687 MB free in about a day. Here’s one way to limit that.

Yesterday I blogged about the API catalog that announces my site's search API to agents. In response, someone pointed me to the ARD specification, a draft announced last month by a working group that includes Google, Microsoft, GitHub, Hugging Face, Cisco, Nvidia, and Salesforce.

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

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

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

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

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

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

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

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

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

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

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

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

For the last few months my laptop has been the bottleneck in my own workflow. Not the CPU, not the RAM – the fact that it’s a laptop.

We are halfway 2026 already so it is time to think about what you will be doing next February.

Start with blocking your calendar for 1-3 February . As usual we’ll be meeting in Ghent for 3 days of Infrastructure Automation Geekery. It will be a fun mix of 2 days of conference with new and old communities, followed by a day of workshops hackathons and tutorials. You know you can’t mis this.

I’ve been busy doing some OpenSearch upgrades and migrations the past couple of months, and I was tired of running curl with different parameters to get the default health and other OpenSearch statuses. Apart from that my muscle memory failed to get the right variety of parameters once in a while so I figured I just write a wrapper around curl that would do a bunch of these things easier for me.

 Evolutie van twee bakken deze lente/zomer. Die kunnen goed tegen de hitte!

Some weeks ago Matt Rechenburg posted about MattX , A Modern openMosix Re-Implementation for Linux 6.x
he tagged me in the post and obviously I was triggered, having spent years in the openMosix community , first writing the Howto, then later being the release manager , testing and getting rid of the openMosixFS , I wanted to see how things would work again today.

My first attempts at getting things to work were a quick failure, Matt had been bitten by the Works on My machine bug … it worked on his Debian setup, but not on my Fedora testbed, and while there is nothing wrong with Debian, that’s kinda a really small scope, so obviously I reached out , we’ve been chatting on and off. And I`m happy to see that I have now seen the first processes migrate in my Lab setup on my AlmaLinux boxen :)

Alex West wrote Not Business Advice , a free series of 13 short books about building profitable personal projects, compiled from the daily blog posts he’s written since 2018. It’s the story of how he made over $1M from his own side projects, and I’m reading it right now. It’s really good: honest about the failure, luck, and burnout, not just the wins. Go read it, it’s free.

I’ve been pondering whether to move away from Fastmail - not because it’s a bad service, but because of where the servers are hosted. I’ve weighed a bunch, but for now I’m staying with Fastmail. The beauty of email is that it’s based on open standards, and you can just move whenever you feel like it.

Mail-hosting history

Over the years I’ve used GMX.net, Hotmail and Gmail - the latter still exists but is not actively used. In addition to Gmail, I also used Google Calendar and Google Contacts.

Unknown (2000 - 2005)

I bought my first domain in 2000, but I forgot where I had that hosted. It came with email, that I remember, which I accessed through Eudora and later KMail.

Lunarpages (2005 - 2008)

In 2005 I moved to Lunar Pages, and took my mail with me there. Your run-of-the-mill shared webhosting mail service. Used via KMail. If my memory serves me right they offered Squirrelmail and IMP as webmail interfaces.

Google Apps for My Domain (2008 - 2015)

In 2008 I moved my mail to Google Apps for My Domain, which had a free plan at the time. I also moved my calendar and contacts there, removing them from the free Google services that I had been using up to then.

With Google Apps for My Domain (now known as Google Workspace), you could use your own domain. The Google interfaces were amongst the best that I had come across; the service was free, and Google did not put ads in the Google Apps variants (since they were geared towards paying customers).

Fastmail (2016)

As I was feeling less and less good about my over-reliance on Google products, I moved in 2016 to Fastmail for a year. I really enjoyed it, but the integration options into Android (my mobile platform of choice) weren’t that fantastic. 3rd party apps only got me so far.

Google Apps for My Domain (2017.. ish?)

2017 saw me moving back to Google Apps - as a paying customer this time since they had stopped their free plans - but that didn’t last long. After using Fastmail, the Gmail interface felt slow and clunky - and I was facing serious synchronisation issues with calendars from Microsoft O365. Often they would not sync at all.

I raised a ticket with support, but that did not end on a happy note:

As discussed I can confirm you’re affected by the known issue where Google Calendar experiences issues parsing a published ICS. Our engineering team are aware of this issue and have been working towards interoperability with Microsoft engineers but as of yet there is no ETA for a fix for this issue.

Under usual circumstances I would suggest installing Google Sync for Microsoft Outlook as a workaround to sync in real-time but I understand you’re unable to install applications on your machine. Please note I have added your domain to the list of affected users and will provide additional feedback to our engineering team regarding this issue.

Needless to say, I never heard back from them. I’m not sure if that issue even ever got fixed.

Fastmail (2017 - now)

That same year I migrated back to Fastmail, where I’ve been ever since.

About Fastmail

Fastmail is a fantastic email provider. They do great work in the open source world and are actively working with several international communities to make email better for everyone.

The web interface - which is the primary way I interact with their service - is functional, fast, beautiful, and gets out of the way. Keyboard navigation is a thing, and it works great.

Their support is amazing. Back in 2016, I had an issue syncing calendars from Microsoft O365 (duplicate entries would show up if individual items in a recurring meeting got modified), and I raised it with them. After some back and forth, this was the outcome:

As you can see, the “RECURRENCE-ID” field has a zero time component, but the DTSTART was T110000, so the RECURRENCE-ID doesn’t match any actual recurrence of the event. There’s been a ton of discussion about this case on the standards calls for CalConnect, and the conclusion was that we should be including any “unknown” recurrence as a separate instance - so you wind up with two instances of the event in our system.

It’s clearly a Microsoft bug, that recurrence ID should say T110000. I’m not even sure what we can do about it :(

Having said that - the behaviour when RECURRENCE-ID doesn’t match an expanded recurrence is undefined by the spec. We’re working on fixing that as part of the TC-API group at CalConnect - there will be a new standard which doesn’t have this problem. sigh

So meanwhile we’ve fixed our product to check for this particular case - where there’s no time on the RECURRENCE-ID field, but the recurrence must be at the same time each day - and it will modify the recurrences to be at the same time as the DTSTART of the first event.

You will notice that this has fixed the duplicates on display in your calendar. It will also modify the caldav events on next sync for synchronised calendars.

Regards,

Bron.

And it was fixed. At that time I wasn’t even aware who Bron was - he’s the CEO of Fastmail.

So why consider moving?

My current subscription ends in October, so this is a good moment to weigh things up. I would prefer staying with Fastmail - it works, and it works well, but there’s one thing that keeps nagging at me:

I am not a lawyer. This is my own interpretation. Make of it what you will.

Fastmail is an Australian company which hosts its servers in the US. Data that is physically there falls under US jurisdiction regardless of where the company is incorporated. FISA Section 702 gives US intelligence agencies the ability to collect communications of non-US persons from US-based servers without a warrant, and the CLOUD Act allows them to compel access through standard legal process.

Fastmail addressed this concern back in 2013 in which they stated that as an Australian company with no US incorporation or staff, they are not directly bound by US court orders. The CLOUD Act which has been passed since mitigates this though.

The above concerns are not specifically tied to Fastmail, but more to do with how I feel about US jurisdiction. They’ve behaved less like a trusted partner and more like an abusive spouse.

I know that there are international intelligence sharing agreements, so even moving to a purely European hosting service would not mitigate this.

Requirements

• The provider must use open standards - SMTP, IMAP, CalDAV and CardDAV. JMAP is a nice-to-have. POP3 is not required.
• Multiple custom domains need to be supported.
• Email, contacts and calendars should all be part of the offering.
• Catchall addresses are a requirement.
• Since I mostly (always?) access my mail through webmail and I have not found a client that I like, their webmail should check the boxes listed in the previous blog post. And it really needs to be pleasant to use. Perhaps a strange requirement, but it is one for me.
• The provider or its parent company must not be incorporated in the US.
• The servers of the provider should not be solely located in the US. Not having them there at all is even better.
• Encryption at rest is non-negotiable, but I believe all reputable providers do that these days.
• End-to-end encryption is not a requirement for me. While it’s nice from a privacy point of view, it negates the possibility of using the aforementioned standards, and being realistic, 90% of the mail I send out probably ends up on either Gmail or Outlook.

Hosting providers

I had a look at a bunch of alternative hosting providers, in no particular order.

Proton & Tuta

Proton is hosted (for now) in Switzerland, Tuta in Germany.

These two providers are end-to-end encrypted and have (in my view) a lock-in problem: it’s not easy to get your data in or out. They both have a means for importing and exporting, but it’s a far cry from using an IMAP copy between mailboxes. The main reason I don’t want to use them.

For a long time neither of them had the option to share calendar links to 3rd parties outside of their ecosystem, which also negated them for me. This seems to be possible now.

Additionally, Proton has no support for dark-themed mail content, and while Tuta does have that, it’s half baked.

My threat model also does not require end-to-end encryption.

Eclipso

Hosted in Germany. The web interface is clean, but unfortunately no dark mode to be seen anywhere. It also had me searching how to change the language from German (default) to English… I understand some German but not enough to use it daily.

Runbox

Hosted in Norway. The interface is better than the older version, but often it switches back and forth between versions. No dark mode support, and also no way to share or subscribe to calendars.

Posteo

Hosted in Germany. Does not support custom domains, which is a dealbreaker.

Mailbox.org

Hosted in Germany, supports all the standards. Web interface is not great, but works. Unfortunately no support for dark-themed mails, and I had issues getting a rather large shared calendar to sync.

I contacted support about this. After a really long round-trip (nearly a week), the final conclusion was that I just have to sync it in my client of choice. Heh.

Infomaniak

Hosted in Switzerland. No dark-themed emails, and the interface is confusing. They have so many things that I don’t need or want in the K-Suite that it’s off-putting to use.

Migadu

Also hosted in Switzerland. Mail and very limited calendaring support (only through CalDAV).

Startmail

Hosted in The Netherlands. No calendar support, which I do require.

Mailfence

Hosted in Belgium. Supports mail, contacts, calendars. No dark-themed emails, unfortunately. The interface needs to be improved to be really something I’d love to use on a daily basis.

Soverin

Hosted in The Netherlands. While they have all the parts, the interface feels old and not pleasant to use. Dark mode is wishy-washy, both for mails and the UI.

Grommunio

This is actually an Exchange replacement. I asked for a demo account on Grommunio to test it (since they don’t sell it themselves, only through partners). Dark mode works well (mail and UI), but there is no way to subscribe to calendars from outside Grommunio without relying on scripts. Finding a reseller that will deal with a customer (vs a business) might also be a challenge.

Update 2026/07/17: Businesswire: Fastmail will be adding email hosting in Amsterdam.

Update 2026/08/03: Fastmail blog: Fastmail offers EU data region

In a first phase, the secondary copy of the data (for resiliency in case the EU servers go down) will still live in the US. The blog post does open up the possibility that in a future phase data won’t be sent to the US anymore.

Fastmail is an Australian company and as such it is bound by Australian law. This, combined with international data sharing agreements, means that data can be subpoenaed regardless of where it is hosted. For me personally it feels like a step in the right direction though. Bron answered some questions in this Reddit thread - we’ll need to wait and see what happens.

I’ve been searching for an email client. Well, more than an email client - a piece of software (or interconnected pieces) that can handle email, calendaring and contacts - often referred to as a Personal Information Manager (or PIM). Either natively on Linux, or as a web client.

The main reason for this search is that I’m considering moving away from my current mail hoster, Fastmail. Not because of the price (which is fair), not because of the service (which is stellar), not because of their webmail interface (which is one of the best PIM interfaces I’ve ever come across), but because their servers are hosted in the USA. Maybe a bit childish, but I’d prefer my stuff a bit farther away from that regime.

In my world email, calendaring and contacts go hand in hand. I send emails to contacts, I use multiple calendars to keep track of all I want to do, and I use email and contacts to share those calendar events. Having them separate doesn’t work.

Beyond having some form of integration, my list of ‘requirements’ isn’t that big:

• Supporting standards. For email we have SMTP, JMAP, IMAP and POP3, CalDAV for calendars and CardDAV for contacts. Since I use multiple platforms, it has to use these standards.
• Having full-text search. Attachment search is nice to have, but not a dealbreaker.
• Having a modern look, with support for dark mode - not only for the interface, but also for the content of emails.
• Supporting multiple identities easily.
• Having a notion of conversations, and properly visualising them.
• Supporting mail filtering rules. If it can interact with Sieve on the backend, even better.

There are some optional features that I’d like, but could do without:

• Showing contact images in the message list (or placeholders). Many modern clients do this these days.
• Snoozing of mails. Client side, not server side, I know, but it’s nice if it has it.

All these criteria make it really hard to find a client that I want to use on a daily basis.

Native clients

Kontact Suite

This is a part of KDE, my desktop environment of choice. It brings together KMail, KAddressBook and Korganizer.

While this suite of applications is technically very capable, the visual aspect of them is lacklustre. I originally started using KDE around 2000 (with KDE 2.0), and in many ways it feels like those applications haven’t had a UI refresh since. I stopped using KMail around 2009 and hadn’t looked at it since. I’m mindboggled by the fact that the HTML bar is still there in 2026.

Also, no support for dark mode mail content.

Thunderbird

Probably the most promising of them all. Has dark mode support for UI and mail, handles contacts and calendaring fairly well. Interface still looks extremely outdated. Doesn’t feel pleasant to use. Dark mode theme is “ok”, but conversation threading is unclear. Contact images can be added using an extension, but that same extension causes Thunderbird to become unbearably slow.

Mailspring

Beautiful client, handles mails well. Beta support for contacts (I managed to crash it a few times), no calendar support as of yet. Has AI bollocks, which fortunately you can ignore completely.

BlueMail

I read a lot of good things about it, but never managed to get it to work - neither with the RPM nor the flatpak image. I don’t do snaps. Also proprietary, and includes AI bollocks it seems.

Evolution

The PIM for the Gnome desktop environment. Doesn’t fit in well with KDE, is extremely opinionated (which is the Gnome way but not my way) and does not support dark mode mail content.

Web clients

MailFlow

I came across Mailflow in the weekly SelfH.st newsletter. It’s beautiful, has a good mix of features and it’s fast. Unfortunately, it has only barebones contact handling, and calendaring is still for the future. No support for dark mail content.

Definitely keeping an eye on it.

RoundCube

A venerable email webclient, which works well for mail. Calendar and contacts are handled through plugins, which need separate configuration - sometimes not even through the actual web interface but through editing config files. Contact handling is mediocre at best. No support for dark mode emails, unless through another plugin.

I tested version 1.7.2, which is the latest at the time of writing, but it felt so slow and old.

Bulwark

A mail webclient made for the JMAP standard, and (usually?) paired with Stalwart. I connected this to my current Fastmail account, and it is absolutely brilliant. Unfortunately, this would mean that I’d have to self-host Stalwart somewhere.

So far, no dice. If you have any other recommendations, I’d be glad to hear them.

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.

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.