One of the shortest announcements at Open Source Summit Europe 2026 will affect a large part of the cloud native world: Docsy is moving to the Linux Foundation.
Docsy is the open source, documentation-focused theme for the Hugo static site generator. If you have read the Kubernetes, etcd, OpenTelemetry or gRPC docs, you have used it. The announcement came during the Wednesday morning keynote from Erin McKean of Google’s Open Source Programs Office, who works on making open source documentation better (and who founded the nonprofit dictionary project Wordnik).
The keynote opened with the best slide of the conference:
Marcin and I in the Congress Hall during the Docsy keynote.
Why the Linux Foundation is the right home
The “LF loves Docsy” slide explained why the move makes sense: the LF ecosystem already runs on it.
- At every size. Top-velocity CNCF graduated projects such as Kubernetes, etcd, OpenTelemetry and Flux use Docsy for multi-versioned, multi-lingual documentation at scale. kubernetes.io alone builds more than 5,600 pages across 15+ languages.
- At every stage. Projects across all CNCF maturity tiers use Docsy, including gRPC, Dapr, Kubeflow and Notary Project (incubating), and kpt, Fission, CloudWeGo and Layer5 Meshery (sandbox).
- Metadocumentation too. The CNCF Cloud Native Glossary (glossary.cncf.io) is built with Docsy.
When so much shared infrastructure depends on one theme, neutral governance is the sensible step. DevOps.com’s report on the move notes that Docsy was created by Google’s technical writers, and that the move came with expanded support for AI agents. On the engineering side, the Docsy 0.16.0 release made the theme available on npm as @docsy/theme, so upgrading no longer depends on Git submodules. It is the same argument the State of Open Source in Europe report made the same morning about critical dependencies.
Better docs, better open source
The keynote backed the case for documentation with data:
- In the 2023 Tidelift survey, 87% of maintainers said help improving documentation would be “extremely valuable” or “somewhat valuable”.
- 93% of respondents to the 2017 GitHub Open Source Survey called incomplete or outdated documentation a “pervasive problem”.
- Multiple Google Season of Docs projects between 2021 and 2024 found that better documentation reduced the number of basic questions from users and contributors, and with it maintainer toil.
That last point is the one maintainers should care about. Good docs are not marketing. They are a way to get your evenings back.
Docsy for AI: documentation as an interface for agents
The part I came for was the AI section. Docsy describes itself as made for tech docs and made for everyone. Now it is “made for AI” as well: features that help people who read docs directly or via an LLM or agent.
Three features were shown:
- In-page directives that point LLMs and agents to your
llms.txt. - HTML and Markdown side by side. You can publish Markdown versions of pages for tools that prefer that format, next to the normal HTML.
- AFDocs scores (coming soon). “Don’t guess! Measure how agent-friendly your docs are.”
I like the third one most. Today most projects have no idea how well an agent can use their docs. A score turns “make the docs AI-friendly” from an opinion into a metric you can improve in CI. I have written before about what happens when assistants work from stale or invented docs in the end of hallucinated documentation. Serving clean Markdown and an llms.txt file is the cheapest fix there is.
Google’s OSPO also pointed maintainers to google/opendocs: docs project archetypes (templates for everything from auditing a docset to building interactive widgets), a Docs Advisor with advice from people who work on documentation, and more than 200 Season of Docs case studies.
My Udienza conversation with Erin
As a media partner, I had arranged a ten-minute Udienza conversation with Erin at the Google Cloud booth on Thursday, scoped strictly to open source documentation and Docsy. The angle was documentation as an interface consumed by people and machines. These are the questions I prepared:
- What changes when documentation has an AI agent as a first-class reader?
- Which documentation habits help both humans and models, rather than optimising for one at the expense of the other?
- Should docs become more structured and machine-readable, or is high-quality prose still the core?
- What failure mode do AI agents expose in existing open source documentation?
- If a project has one week to improve its docs for agents, what should it fix first?
Udienza conversations are published as episodes on udienza.com, with chapters and transcripts.
What to do this week if you maintain docs
- Add an
llms.txtat the root of your docs site that lists the pages that matter. - Publish Markdown alongside HTML for reference pages. Agents parse it better and it costs you a build step.
- Version your docs the way Docsy and Hugo already support, so agents do not mix answers from three releases.
- Fix the top ten questions from your issue tracker in the docs. That is where both humans and agents fail first.
More from Prague: AI-speed exploits and the security keynotes and the Open Source Summit Europe 2026 recap.
