Andreas Gohr: Linkblog [splitbrain.org]

Bearming theme for Bear blog

Mon, 25 May 2026 05:36:39 +0000

The maintainer's dilemma

Fri, 22 May 2026 15:43:35 +0000

When a maintainer reviews a contributor’s PR, there’s an unspoken contract. [...] the human stays accountable regardless; the tool doesn’t absorb the responsibility. [...] it assumes someone is actually there to take responsibility. For most projects, nobody is. The social contract isn’t being broken by AI — it’s already being broken by silence.

A protected branch requires a second person to review a change before code ships. The rule exists because humans make mistakes, and a second pair of eyes catches what the first one missed. But what happens when one of those reviewers is a robot? What if both are?

Currently I can ask an AI to open a pull request on my repository and then merge it myself. Or I can write the code and ask an AI to review it. In both cases, the branch is technically “protected.” But what does that even mean now?

Those are questions worth asking. But they tend to get all the attention while a more immediate problem goes unaddressed. Right now, across my repositories, there are open pull requests from people who took time to understand the codebase, write tests, and submit clean patches. I haven’t reviewed them. Sadly, the ironic part is I haven’t reviewed them because I deeply care. I know how big of a deal it is to take the time to open a pull request on a project, and even more so on a popular one. I know that each one deserves an honest review and that that takes time I don’t have for projects I maintain as a volunteer. For every open source project with a funded maintainer, there are millions with an unpaid human staring at a growing backlog, wondering whether the right thing to do is spend their weekend triaging issues or just close the laptop and go outside.

AI tools can now do credible code reviews, write patches, and triage issues. The question is no longer whether they’re good enough to be useful. The real questions are where “useful” becomes “liability,” and whether leaning on them breaks something we can’t easily rebuild — the trust between maintainers and contributors, the judgment that comes from experience, and the community that forms around that exchange.

118 Open Pull Requests

I checked my GitHub notifications last week and closed the tab. Cobra has 243 open issues and 118 open pull requests. Afero has 114 issues and 55 PRs. I created both projects. I haven’t meaningfully reviewed a PR on either in months.

In spite of my inaction as a reviewer, these are actively maintained projects. Cobra powers kubectl, GitHub CLI, Hugo, and hundreds of thousands of other tools. When you type kubectl get pods or gh pr list, Cobra parses your command. Afero sits inside Hugo, inside Cobra itself, inside hundreds of thousands of other projects. A careless merge on Cobra could break Kubernetes tooling. A bad review on Afero could open a filesystem vulnerability that quietly propagates through everything downstream.

I created Cobra because I needed a specific CLI UX for Hugo and no existing library could support it. I split it out as its own project, thinking others might find it useful. I never imagined I’d still be maintaining it a decade later, or that both projects would become critical infrastructure for so many others. I just wanted to build something useful for me and maybe a few friends. But does open sourcing code mean I’m obligated to maintain it indefinitely? With each new project I release, there’s less time for the existing ones. Some of those PRs have been waiting for years. There’s a reported security vulnerability in Afero’s BasePathFs that’s been sitting open since June 2025 — which, until I wrote this post, I didn’t realize was there, because the backlog is that overwhelming.

The math of maintenance doesn’t work. It’s a well-known problem across open source (relevant XKCD). The number of contributions grows faster than the number of maintainers, and the time required to review each one grows with a project’s complexity and impact. Some projects attract volunteer co-maintainers, but that brings its own problem: no one is clearly responsible, so everyone picks what matters to them and the rest just sits. Cobra is intentionally slow to change — too many projects depend on it to casually merge anything — so each change requires more thorough review, not less. Many of my other projects fall into the gray area between maintained and abandoned. I’d describe it as optimized maintenance around the most critical paths, but that distinction matters a lot more to me than it does to the person who submitted a fix eight months ago and never heard back.

This isn’t just my problem. GitHub hosts over 420 million repositories. I was very fortunate to be a part of the inaugural cohort of the Secure Open Source Fund — a real investment that made a real difference. But even after expanding to several cohorts, it covers about 200 projects. OpenSSF scans a million critical projects weekly. Tidelift pays maintainers. Add it all up and you’re covering thousands of projects. It’s meaningful work. It’s also a rounding error against the actual surface area.

Ninety-six percent of codebases contain open source components, and the foundations they build on are maintained by people staring at a backlog they’ll never clear, wondering if this is the weekend they finally burn out or just stop checking. And that’s before you get to maintainer guilt — the knowledge that people are counting on your work, that you have the capacity to help, but that you can’t keep up.

Enter the Robots

I’ve been experimenting with AI tools across a couple of repositories — Jules on fileflow and pathologize, which have fewer dependencies and more room to try things. I’ve also been running GitHub Copilot on Afero, which has more dependencies, but its modular architecture lets me extend new backends without touching the critical paths other projects depend on.

I turned Jules loose and watched email after email arrive with new PRs. Looked promising. Then I went on a cruise. While I was at sea, Jules kept going, opening more pull requests each day because I hadn’t merged the first ones yet. By the time I got home, I had over 120 PRs across the two projects. I set aside a morning to review them all, only to find they represented roughly five distinct change sets, each submitted daily over several weeks. The PRs themselves weren’t wrong, Jules had found real issues. But none were quite right either; each needed course correction before I could merge. With guidance Jules made the adjustments, and the overall direction showed promise. But the experiment so far has created more maintenance work, not less: I had to verify each of those 120 PRs was actually a duplicate before closing it. The tool meant to reduce my backlog had added to it.

Jules also created these PRs as me, not as Jules — which raises its own questions about attribution and accountability. From the repository’s perspective, I authored those changes. But I didn’t write a line of them. If one of those patches introduced a bug or a vulnerability, the commit history points to me. Most contributor policies weren’t written with this scenario in mind, and the standard CLA doesn’t distinguish between code a human wrote and code a human directed an AI to write on their behalf.

Currently, it appears that Jules has no memory of its own previous work and doesn’t have the ability to check open PRs. It scans the repository, finds an issue, opens a PR, and stops. If you don’t merge it, Jules finds the same issue next time and opens another PR. It has no way to know you’re aware of the problem and haven’t merged it for your own reasons: maybe you disagree with the fix, maybe it’s lower priority, maybe you’re on a boat and won’t get to it for a couple weeks. That context is invisible to the tool. Jules found a real vulnerability — TOCTOU bugs in file operations are a genuine class of security problem — and it was right to flag it… once.

For the mechanical work — flagging issues, updating dependencies, drafting boilerplate responses — the tools are genuinely useful. But Jules and Copilot couldn’t tell me whether one of those 55 Afero PRs belongs in the project at all. That judgment requires knowing the codebase’s past and future, not just its present state.

These tools work only from what’s visible: the code, the open issues, the PR history. Maintainers work from the visible and the invisible: the context that never made it into comments, the constraints nobody wrote down, the internal debates that shaped the API. The gap between those two things is where human judgment is most irreplaceable, and where AI is most blind.

Russ Cox, who I worked with on the Go team, put this well in a recent discussion about AI contributions: “People brag about codebases of hundreds of thousands of lines that have never been viewed by people, churned out in record time. On closer inspection, these codebases invariably turn out to be more like dancing elephants than useful engineering artifacts.”

He’s right about novel code. But I keep coming back to the distinction between writing new software and maintaining existing software. Dependency updates aren’t dancing elephants. Triaging a stale issue isn’t a creative act. Telling a contributor “thanks, we’re not accepting changes to this API” is just keeping the lights on. And right now, for millions of projects, the lights are off.

That isn’t the biggest challenge, though. What most people don’t realize is that evaluating and merging changes is far harder than writing new code. Understanding how a change fits into the existing codebase, its history, and its plans requires knowledge that’s partly invisible — not in the code, not in the comments, not in the issues. It’s in the maintainer’s head. And some of it is deeply creative work, requiring the kind of judgment no model can replicate.

What “Protected” Actually Protects

The Go project is genuinely beautiful to me — meticulous reviews, design discussions that ran for months before anything shipped, a review culture refined over 15 years. That’s the ideal. But Go is exceptional in ways most projects can’t replicate: full-time contributors funded by Google, a mandate to build a language meant to last 50 years, rare external deadline pressure.

The Go team had a long thread recently about whether to accept AI-authored contributions — the same discussion where Russ Cox’s quote above originated. These are people I worked with for years — same reviews, same proposals, same arguments at the same whiteboards. Reading the thread, I could hear their voices. And I could see how every one of them was right, and why that was the problem.

Rob Pike went first and didn’t equivocate: “This is a very slippery slope. Be careful on your first step. I recommend simply saying, no.” That’s Rob. Direct, principled, and usually right. Then Alan Donovan pointed out the uncomfortable reality: “I suspect a significant fraction of CLs we receive today already include fragments of LLM-generated code, whether the authors admit it or not.” The horse, in other words, has already left the barn.

Russ Cox wrote the most thoughtful response I’ve seen anyone write about this. His core point: “The most important thing we can do is to maintain our usual processes around code review and code quality… That same bar must still apply when some or all of the code was written with the help of AI-based tools.” And: “Your responsibilities are not lessened when you use AI tools for your work.”

Every one of these positions is reasonable. And every one of them shares an assumption that exposes the core of the dilemma: they assume there are humans available to review.

Go can afford to say “maintain the same bar” because it has full-time contributors funded by Google. It has reviewers. It has a review culture that’s been refined for over a decade. Rob can say “just say no” because Go has enough people to say “yes” to the important things.

Afero doesn’t. Most open source projects don’t. When Rob Pike says no, the Go project keeps functioning. When I say no, the PR just sits there. Those are different kinds of “no.”

There’s a spectrum, and where you land on it depends on what you’re actually choosing between. In practice, maintainers face five options:

Human writes, human reviews.
AI writes, human reviews.
Human writes, AI reviews.
AI writes, AI reviews, human clicks merge.
AI writes, AI reviews, AI clicks merge.

Each step down that list typically trades rigor for velocity, and trust for throughput. But for most projects — certainly for many of mine — there’s a sixth option that doesn’t appear on that list: human or AI writes, nobody reviews.

What We’re Really Protecting

When a maintainer reviews a contributor’s PR, there’s an unspoken contract. The contributor invested hours understanding the codebase, writing tests, and submitting something clean. The reviewer invests hours evaluating it, pushing back, and suggesting improvements. Both people learn. The reviewer understands a new corner of the project. The contributor gets better at the codebase’s idioms. A relationship forms. That exchange is a big part of what makes open source a community instead of just a supply chain.

Bryan Cantrill at Oxide described this contract precisely in their internal policy on LLM use: ordinarily, “it is presumed that of the reader and the writer, it is the writer that has undertaken the greater intellectual exertion.” When the writing is AI-generated, “this social contract becomes ripped up.” The same holds for code review — we expect the reviewer to invest effort because the author invested effort. If neither did, what’s the review even for? Oxide’s answer is that the human stays accountable regardless; the tool doesn’t absorb the responsibility. That’s the right instinct. But it assumes someone is actually there to take responsibility.

For most projects, nobody is. The social contract isn’t being broken by AI — it’s already being broken by silence. The contributor who submitted a clean, well-tested patch six months ago and never heard back isn’t experiencing a degraded version of the ideal. They’re experiencing nothing.

Is a perfect social contract that never happens better than an imperfect one that does?

A response from an AI in a day might be more respectful than silence from a human forever.

The Experiment Ahead

I’ve decided to find out. I’ve been staring at 55 open PRs on Afero long enough to know that deliberation has become its own form of neglect.

Will AI tools make me more engaged, freeing me to focus on decisions that actually need me? Or will it feel less connected — the human element reduced by one more degree? I don’t know how it feels to have an AI review a PR instead of a human, or whether accountability holds when the effort on both sides is diminished. That’s the experiment.

Russ said something else in that thread I keep returning to: “The most important thing is to keep thinking. The tools make it very easy to turn off your brain, but if you are careful to avoid that trap, you can produce good work.” That’s the line I’m trying to walk. Let AI handle the volume. Stay responsible for the judgment.

There’s no universal policy that works for both Go and Afero. There shouldn’t be.

The protected branch is still protected. I’m just not sure what that even means anymore.

Have you run into this? I’d especially like to hear from maintainers who’ve tried AI review — what held, and what broke.

CSS & vertical rhythm for text, images, and tables

Tue, 12 May 2026 06:29:38 +0000

Vincent Bernat April 22, 2026

Vertical rhythm aligns lines to a consistent spacing cadence down the page. It creates a predictable flow for the eye to follow. Thanks to the rlh CSS unit, vertical rhythm is now easier to implement for text.¹ But illustrations and tables can disrupt the layout. The amateur typographer in me wants to follow Bringhurst’s wisdom:

Headings, subheads, block quotations, footnotes, illustrations, captions and other intrusions into the text create syncopations and variations against the base rhythm of regularly leaded lines. These variations can and should add life to the page, but the main text should also return after each variation precisely on beat and in phase.

― Robert Bringhurst, The Elements of Typographic Style

Text#

Three factors govern vertical rhythm: font size, line height and margin or padding. Let’s set our baseline with an 18-pixel font and a 1.5 line height:

html {
  font-size: 112.5%;
  line-height: 1.5;
}
h1, h2, h3, h4 {
  font-size: 100%;
}
html, body,
h1, h2, h3, h4,
p, blockquote,
dl, dt, dd, ol, ul, li {
  margin: 0;
  padding: 0;
}

CSS Values and Units Module Level 4 defines the rlh unit, equal to the computed line height of the root element. All browsers support it since 2023.² Use it to insert vertical spaces or to fix the line height when altering font size:³

h1, h2, h3, h4 {
  margin-top: 2rlh;
  margin-bottom: 1rlh;
}
h1 {
  font-size: 2.4rem;
  line-height: 2rlh;
}
h2 {
  font-size: 1.5rem;
  line-height: 1rlh;
}
h3 {
  font-size: 1.2rem;
  line-height: 1rlh;
}
p, blockquote, pre {
  margin-top: 1rlh;
}
aside {
  font-size: 0.875rem;
  line-height: 1rlh;
}

We can check the result by overlaying a grid⁴ on the content:

Using CSS rlh unit to set vertical space works well for text. You can display the grid using Ctrl+Shift+G.

If a child element uses a font with taller intrinsic metrics, it may stretch the line’s box beyond the configured line height.⁵ A workaround is to reduce the line height to 1. The glyphs overflow but don’t push the line taller.

code, kbd {
  line-height: 1;
}

Responsive images#

Responsive images are difficult to align on the grid because we don’t know their height. CSS Rhythmic Sizing Module Level 1 introduces the block-step property to adjust the height of an element to a multiple of a step unit. But most browsers don’t support it yet.

With JavaScript, we can add padding around the image so it does not disturb the vertical rhythm:

const targets = document.querySelectorAll(".lf-media-outer");
const adjust = (el, height) => {
  const rlh = parseFloat(getComputedStyle(document.documentElement).lineHeight);
  const padding = Math.ceil(height / rlh) * rlh - height;
  el.style.padding = `${padding / 2}px 0`;
};

targets.forEach((el) => adjust(el, el.clientHeight));

The image is snapped to the grid thanks to the additional padding computed with JavaScript. 216 is divisible by 27, our line height in this example.

As the image is responsive, its height can change. We need to wrap a resize observer around the adjust() function:

const ro = new ResizeObserver((entries) => {
  for (const entry of entries) {
    const height = entry.contentBoxSize[0].blockSize;
    adjust(entry.target, height);
  }
});
for (const target of targets) {
  ro.observe(target);
}

Tables#

Table cells could set 1rlh as their height but they would feel constricted. Using 2rlh wastes too much space. Instead, we use incremental leading: we align one in every five lines.

table {
  border-spacing: 2px 0;
  border-collapse: separate;
  th {
    padding: 0.4rlh 1em;
  }
  td {
    padding: 0.2rlh 0.5em;
  }
}

To align the elements after the table, we need to add some padding. We can either reuse the JavaScript code from images or use a few lines of CSS that count the regular rows and compute the missing vertical padding:

table:has(tbody tr:nth-child(5n):last-child)   { padding-bottom: 0.2rlh; }
table:has(tbody tr:nth-child(5n+1):last-child) { padding-bottom: 0.8rlh; }
table:has(tbody tr:nth-child(5n+2):last-child) { padding-bottom: 0.4rlh; }
table:has(tbody tr:nth-child(5n+3):last-child) { padding-bottom: 0 }
table:has(tbody tr:nth-child(5n+4):last-child) { padding-bottom: 0.6rlh; }

A header cell has twice the padding of a regular cell. With two regular rows, the total padding is 2×2×0.2+2×0.4=1.6. We need to add 0.4rlh to reach 2rlh of extra vertical padding across the table.

One line out of five is aligned to the grid. Additional padding is added after the table to not break the vertical rhythm. 405 is divisible by 27, our line height in this example.

None of this is necessary. But once you start looking, you can’t unsee it. Until browsers implement CSS Rhythmic Sizing, a bit of CSS wizardry and a touch of JavaScript is enough to pull it off. The main text now returns after each intrusion “precisely on beat and in phase.” 🎼

Task Paralysis & AI | g5t.de

Sun, 10 May 2026 17:06:29 +0000

About Task Paralysis

Straight away: I am not diagnosed yet. So I'm hesitant to say "I have ADHD", because the truth is: I don't know it. There are signs: My siblings have been diagnosed as kids, and I'm personally struggling with tasks that others deem to be "easy". I have a tremendous need for novelty, and I can hardly picture myself doing the same job for the next 30 years.

I'm not kidding: At the moment, I change roles every 2-3 years. This isn't really sustainable. Due to circumstances out of my control, I wasn't able to tackle that earlier.

Also, it doesn't really help if you want to build a career: I can navigate myself around a lot of technical fields, but I have no special knowledge.

Often, I struggle with the execution of a strategy that I successfully laid out. I will simply refuse to do the first step, because everything now feels overwhelming.

So... there are signs. Yes. But that might be another article.

I'm aware that there is something called Analysis Paralysis. But that's different, at least for me and to my understanding. Let me put it this way: When Analysis Paralysis kicks in, my brain will run in circles. When Task Paralysis kicks in, my brain won't run at all. That sucks.

About AI

I won't go as far and say that I HATE AI per se. I just shelled out almost 100 € in tokens (Max-plan for Claude) to code a game. And an iOS App. Because I need the latter and want the former. But I see all the negative effects that come with AI: People are loosing their jobs, sometimes loosing themselves. Art gets stolen, and suddenly, piracy isn't piracy any longer once large companies are doing the deed. That feels unfair, to say the least, and strange at best.

(I 👴 grew up in the 2000s, so I have some knowledge about piracy from back in the days, and how copyright holders went after people.)

I refrain to use AI for anything artistic since a couple of months. I either buy it, or try to do it myself "the old way". I can fail, I can succeed - but I did it on my own. That's important. The effect AI has on artists feels just too destructive.

What is it good for?

For me, personally? It helps me overcome my task paralysis. As mentioned earlier: I have a plan. A strategy. An idea. I just need someone (or something), who has fun in churning through the implementation. I have the ideas. But boy is coding exhausting. As I learned quite late in my life, it is indeed not normal to fight with your motivation to create code every time you tackle a new user story, but succeed once you started.

The Catch

Claude Code in this case is the something that just helps me getting started. And, lo' and behold, I see myself struggling to not get addicted to that.

What do I mean by that? While overcoming the task paralysis on one hand, it quickly produces really good results. Last time I tried AI was in fall of 2025. It's an understatement to say that a lot has changed. There are worlds between what is possible today and what was possible back then.

That means that the dopamine really kicks fast, because the cycle between "I have an idea" and "This is the result!" is so tremendously short. But Claude has token limits. You can only spend a limited amount of tokens per 5 hours or 7 days. But you can buy additional API tokens. And now you set yourself in a position where you throw endless money at your source of dopamine, like a junkie running to their dealer, begging for the next shot. Or a poor player waiting for the golden ticket.

And, to be brutally honest: I know because I fell for it. After getting the Pro-plan, I added another 20 € for API credits. After that, I realized I should go for Max for this month, and also leverage some tricks like /modus opusplan to reduce the amount of tokens that are used.

But the dopamine feels so freaking good.

Disclaimer: No AI was used to create this article.

Die dänische Entscheidung, konsequent für Wohlbefinden zu sorgen

Sat, 25 Apr 2026 14:46:44 +0000

"Morgen fahren wir nicht nur 800 Kilometer nach Hause. Wir reisen 30 Jahre in der Zeit zurück."

Prolog | Am Abend vor unserer Abreise sagte ich zum Reiseleiter: „Morgen fahren wir nicht nur 800 Kilometer nach Hause. Wir reisen 30 Jahre in der Zeit zurück.“

Damit meinte ich nicht die Digitalisierung in Dänemark. Vielmehr meine ich damit die Art, wie Dänen und insbesondere die Kopenhagener Zusammenleben gestalten.

Das Design | Wenn man Dänemarks und Kopenhagens Idee von Stadtplanung verstehen will, kommt man nicht an Jan Gehl vorbei. Foto aus dem Danish Architecture Center:

Als der 79-Jährige seinerzeit Architektur studierte, zeigten ihm seine Professoren Fotos mit Gebäuden. Um die Fotos zu machen, sind sie um 5 Uhr aufgestanden, damit keine Menschen auf den Bildern zu sehen waren. Gehl sagt, er habe im Studium gelernt, Skulpturen zu erschaffen, keine Gebäude für Menschen. Dann heiratete er eine Psychologin, „a big crossing point in my life“. Seither, sagt er, studiere er Architektur neu, seit 40 Jahren.

Das erzählt er in seiner Standardvorlesung, die zum Beispiel als Annual Lecture 2018 Mistra Urban Futures zu sehen ist, Video ab Minute 8:30. Oder im Podcast The Developer.

Gehl begann, Menschen zu beobachten. Er fuhr nach Italien und führte in den Altstädten akkurat Buch darüber, was in den Straßen, Gassen und auf den Plätzen geschah. Er schrieb auf, wie sich Menschen verhalten. Er bereiste andere Länder, andere Städte. Ihm wurde klar, dass die Architektur bislang einem Irrtum unterlegen war: Sie maß, wie viele Menschen wo gehen und fahren – um dann Straßen und Häuser zu gestalten. Dabei sei nicht wichtig, wo sie sich bewegen, sondern wo sie stehenbleiben, in Kontakt kommen, miteinander sprechen. So entstand Gehls Verständnis von Stadtplanung.

A good city is like a good party — people stay longer than really necessary because they are enjoying themselves.

Er beschäftigte sich mit menschlichen Dimensionen, mit Augenhöhen, Sichtachsen, wie weit wir gucken und laufen können, bei welchen Geschwindigkeiten wir noch was wahrnehmen können, welche Strecken wir wählen, warum wir lieber am Rand sitzen als in der Mitte, bis zu welcher Entfernung wir Mimik lesen können und vieles mehr.

Gehl kam zu dem Schluss, das der Mensch alles tut, um Energie zu sparen. Wenn wir uns entscheiden, wie wir eine Strecke zurücklegen, dann ist es immer eine Effizienzentscheidung. Also, sagte er sich, müssen Städte so gestaltet sein, dass sie effizient und bequem sind – nicht für ein Auto, sondern für den Menschen, für den menschlichen Körper und den menschlichen Geist.

Das Ergebnis ist eine Stadtplanung, die Plätze und Räume priorisiert, auf denen Menschen zusammenkommen und sich sicher fühlen, eine Planung, die am menschlichen Körper ausgerichtet ist, die Aktivität fördert und Gesundheit erhält. Er entwickelte eine demokratische Stadtplanung, die wiederum Demokratie fördert.

It emphasizes that we shall walk more, we shall meet each other more. That’s good for health, that’s good for safety, that’s good for social inclusion, that’s good for democracy. Don’t sit in your private little house and look out of little little windows. Come out in our wonderful outdoor spaces and enjoy the spaces with your wonderful fellow citizens.

Filmempfehlung: The Human Scale, verfügbar auf youtube. Leseempfehlung: Städte für Menschen. Außerdem ein Interview beim Deutschlandfunk.

Wege und Plätze | Der Reiseleiter und ich sind in den vergangenen Jahren mehr als tausend Kilometer mit dem Fahrrad durch Dänemark gefahren. Diese Mobilitätsform hat zwar den Nachteil, dass einem immer irgendwas weh tut und man sich fortwährend mit Keksen befüllen muss. Sie hat jedoch einen entscheidenden Vorteil: Man erkennt hervorragend Muster und Zusammenhänge, Verbindungen zwischen Menschen und Geographie, zwischen Städten und Stadtteilen, sich wiederholende Strukturen und die Prioritäten, die sich durchs Land ziehen. Diese Prioritäten finden in Kopenhagen ihren kummulierten Höhepunkt: Allerorten geht es darum, Gemeinschaft zu stärken. Der öffentliche Raum gehört dem Menschen, nicht Autos, nicht der Wertschöpfung, sondern dem Wohlbefinden der Däninnen und Dänen. Der Mensch wird willkommen geheißen: mit Bänken und Blumen, Schatten spendenden Bäumen, Spielgeräten, Wasser, Schaukeln und Rutschen – auch für Erwachsene -, mit Ruheliegen, Picknickmöglichkeiten, öffentlichen Toiletten, breiten Wegen und Beleuchtung.

Sollten Sie einmal in Kopenhagen sein, organisieren Sie sich ein Fahrrad und fahren Sie durch die Stadt. Sie werden erkennen, wie alles auf magische Weise verbunden ist, wie Wege sich öffnen und fügen, wie es fließt und wie verschiedene Orte und unterschiedliche Stadtteile sich zu einem verwobenen Ganzen zusammenfügen, das ohne Motor, nur mit menschlicher Körperkraft erfahrbar ist. Es existieren viele Plätze, die im Einzelnen unscheinbar wirken, die in ihrer Fülle und in ihrer Verbindung jedoch ein Netz bilden, das nicht nur für den funktionalen Teil des Erwachsenendaseins, sondern fürs Zusammenleben aller Altersgruppen sicher und praktikabel ist.

Kopenhagen hat weniger Spielplätze als deutsche Städte mit vergleichbarer Fläche. Es braucht auch nicht so viele, weil die Stadt selbst kinderfreundlich ist, weil sie Plätze hat, die zum Spielen, Rennen und Verstecken einladen. Eingezäunte Spielplätze helfen nicht, wenn die Stadt außerhalb des Zauns feindlich ist.

Dass Kinder Teil der Stadt sind, zeigt sich auch am Israels Plads, einem großen Platz, der umringt ist von Schulen (Foto des Reiseleiters aus dem vergangenen Juni):

Der Platz ist der Pausenplatz aller Schulen und gleichzeitig ein öffentlicher Ort. Kinder mischen sich mit Menschen, die einkaufen, mit Senioren, die sich ausruhen, mit Mittagspäuslern, die Smørrebrød essen. Keine Haftungsfrage, keine Angst: ein Schulhof, nicht eingezäunt? Der Platz ist übrigens auch Teil der städtischen Klimaanpassung. Er ist ein Regenrückhaltebecken, das tiefer liegt als die Umgebung: Regnet es zu viel, läuft er voll.

Gebäude für alle | Wir radelten zu den Nørrebrohallen. Ein Treffpunkt, eine Bibliothek, Sporthallen – alles öffentlich, alles steht für alle zur Verfügug.

Es gibt mehrere ähnliche Orte in Kopenhagen. Über die Seite bookbyen.dk („Buch die Stadt“) kann jeder sich einen Platz, einen Raum buchen. Ein Badmintonkort kostet beispielsweise 98 Kronen pro Stunde, das sind etwa 13 Euro. Als wir dort waren, war massig los: Die Leute kamen aus den Sporthallen, gingen hinein, trafen sich im Café, saßen einfach nur auf Bänken, besuchten die öffentliche Toilette, den Bücherschrank oder waren alleine oder mit Kind in der Bücherei. In der Eingangshalle standen locker 25 Kinderwagen. Es gibt einen Kochclub und andere Interessenskreise, außerdem Snakkeklubber für diverse Sprachen, in denen man seine Sprachkenntnisse vertiefen und sprechen üben kann – auch in Dänisch für alle Zugewanderten.

Wir hielten uns dort eineinhalb Stunden auf, lasen, aßen etwas. Ich nahm ein Buch aus dem Bücherschrank mit, einen Krimi, mein erstes Buch, das ich auf Dänisch lese. Mit etwas Anstrengung verstehe ich gut; mein Vokabelschatz erweitert sich um Wörter wie „Tatort“, „Ertrinkungstod“, „Zeugenaussage“ – mein Dänischlehrer wird irritiert sein. Das Schöne an dem Ort: Wir fühlten uns willkommen, obwohl wir nur Gäste waren. Ein Ort der unkomplizierten Freundlichkeit.

Die Bibliothek in den Nørrebrohallen war ein warmer, wuseliger, kreativer Ort. Den Sorte Diamant, Der Schwarze Diamant, die Dänische Nationalbibliothek, ist deutlich minimalistischer und vor allem dem Studium gewidmet.

Eine tolle Architektur.

Im Museum für Architektur und Design gab es übrigens eine Rutsche vom obersten Stockwerk ins Erdgeschoss – ausdrücklich auch für Erwachsene (mehr dazu, mit Bild). Ein wilder Ritt. Ich sah mein Leben an mir vorbeiziehen.

Rutschen-Architekt Carsten Höller:

Why are slides not used in architecture to complement stairs, elevators and escalators? They are fast, safe and energy-savvy – and they produce a sensation in the user that has been described as a kind of voluptuous panic upon an otherwise lucid mind, somewhere between delight and madness.

Das kann ich so bestätigen.

Epilog | „Aber in Deutschland ist doch nicht alles schlecht! – „30 Jahren hintendran – so kannst du das doch nicht sagen!“

In unserem Land sind Städte und Orte so gestaltet, dass sie funktionieren; dass sie effizient und vorschriftsgemäß sind. Dummerweise verhält sich der Mensch nicht normgerecht, sondern folgt seiner Intuition. In Dänemark passt sich die Stadt dem Menschen an, schafft Zugehörigkeit. In Deutschland muss sich der Mensch an die Stadt anpassen, steht der Individualismus über dem Gemeinsinn. Dieser Unterschied wirkt so fundamental, dass wir in Deutschland, selbst wenn alle Kommunen plötzlich Geld im Überfluss hätten, nur mehr von dem bekämen, was wir bereits haben: normtreu gestaltete Orte.

Bis wir diesen gedanklichen Sprung gemacht haben, werden Jahrzehnte vergehen.

Die Etappen | Auf der nächsten Etappe erzähle ich noch vom Radfahren in Kopenhagen:

#1 – Die Fahrt, der Wind, die Einöde, Schnee und ein Bällebad
#2 – Eine Erzählung über Museen und Friedhöfe
#3 – Brücken, Tunnel und Fähren – ein Beitrag für den Freundeskreis Ingenieurskunst
#5 – Test eines Mythos: Radfahren in Kopenhagen