Linus Torvalds does not write often anymore, at least not with the old ferocity. So when he does, people notice. Last week, on a thread about linking Patchwork with an AI-assisted maintenance tool called Sashiko, someone raised a familiar worry: that the drift toward caution around AI contributions was quietly becoming a drift toward rejection. Torvalds answered the way only a founder with three decades of unquestioned authority can. Linux is not an anti-AI project, he said, and if that troubles you, fork it, or walk away. AI is a tool. Whether it is useful is no longer a question worth asking. The only real question is whether we make it help the people who maintain the project, or let it become one more source of pain.
It is tempting to read this as a Kernel story and move on. I think it is worth sitting with a little longer.
Not long ago we had a message that echoed Torvalds’ framing, though with none of his certainty. He was not complaining about any one person. He was naming something quieter and more troubling: that nobody in the core was particularly excited about AI, that the caution had good reasons, and that the shared instinct that this, too, shall pass might be exactly what costs the project its future relevance. A REST API sturdy enough to enable MCP integration is not a moonshot. The technical foundations- DataHandler, reactions, webhooks, existing headless extensions- are already there. What is missing is not capability. It is a decision.
Here the difference between a kernel and a CMS association is instructive rather than incidental. Torvalds can simply decide, because Linux has one maintainer at the top and always has. The TYPO3 Association is a different kind of body, a registered nonprofit with an elected board, built so that no single voice declares a technical direction by fiat, however well-intentioned. That is not a weakness. It is the shape of the thing we chose to build, and it comes with its own obligation. We cannot decide the way Torvalds decides, but we still have to decide, only through the mechanisms we actually have.
Which is why I think this thread should end with an RFC, not more back-and-forth on Slack. Not because the debate needs to be silenced by decree, but because a community that keeps having the same unresolved conversation is spending its energy on the wrong kind of friction.
An RFC gives the question a place to live, a named owner, a timeline, and an actual decision at the end. What we take from Torvalds should not be the tone. It should be the discipline of treating usefulness as settled and channeling the real energy into how the tool is integrated so it helps the people doing the work, rather than adding to their load.
So where does this RFC start?
; thanks for helping out with the GitHub access rights). This policy defines how decisions are documented (as RST files in the repo), who owns certain documents and what kinds of changes require which kind of approval processes (for example, a “simple” Board majority decision or a General Assembly vote).
).