Apache Superset at FOSDEM 2026
FOSDEM (Free and Open Source Software Developers' European Meeting) is the largest open source conference in Europe, drawing thousands of developers, maintainers, and enthusiasts to Brussels every February. It's entirely free, entirely volunteer-run, and operates on a model unlike any other conference: dozens of specialized "developer rooms" run in parallel across the Université Libre de Bruxelles campus, each organized by a different open source community. There are no corporate booths, no badge scanners, no sales pitches — just hallway conversations, packed rooms, and the kind of grassroots energy that reminds you why open source exists in the first place.
This was my second year attending, and I came with a few goals in mind. First, to raise awareness of Apache Superset™ to a growing global audience — FOSDEM draws attendees from all over the world, many of whom are discovering projects for the first time. Second, to share what we've learned as maintainers and pick up new ideas from other speakers and communities. And third — maybe most importantly — to network with other Apache Software Foundation projects, database vendors, and platforms that Superset can integrate or interoperate with. These conferences are the best opportunities to meet new users, new contributors, and potential collaborators in our ecosystem.
The Talk: Self-Maintaining Documentation
I presented in the Tool the Docs developer room on the topic of how we've re-engineered Apache Superset's documentation to build itself from the codebase. The central thesis: don't let AI write your docs — let it write tools that let your docs build themselves.
Here's the hot take I opened with: humans are great at foresight; machines are great at coding. When you point AI at a codebase and say "write the docs," you get a lot of pages and a lot of words, but the unimportant details come front and center while the nuanced things that actually matter to users get buried. The alternative is to let humans decide what matters and let machines do the heavy lifting of keeping it current.
The Problem
Before diving into solutions, I walked through the mess we were dealing with — and it's a mess most open source projects will recognize:
- You can't find anything. Documentation was scattered across the website, README files, the GitHub wiki, third-party blog posts, and Storybook running as a sidecar. New contributor onramp was painful. Search was limited. AI assistants couldn't point to a single comprehensive knowledge base.
- Duplication of effort. You had to write code and docs. You had to update and link docs in multiple places. You weren't done when your PR merged — you still had the docs to write, and nobody wanted to do that part.
- Maintenance nightmare. Content didn't match product versions. Screenshots were perpetually out of date. The codebase is a moving target, and hand-maintained docs can't keep up.
The new goal was threefold: get everything under one roof so it's easily cross-referenced, make the docs build themselves from codebase metadata, and optimize for both humans and AI consumers. The docs should be a result of the codebase, not a description of it.
Seven Projects That Proved the Model
I walked through seven real projects that demonstrated the approach, each one turning some form of codebase metadata into self-generating documentation.
1. Country Mapping Visualizations
Superset includes map visualizations that require GeoJSON data for every supported country. Previously, adding a country meant editing a Jupyter notebook, updating the visualization plugin code, and updating the docs — three separate steps that were easy to botch.
This was actually one of our earliest experiments — born out of laziness, honestly. I wired up the Jupyter notebook to drive everything: a contributor edits one file, and the plugin code and documentation update themselves. One input, three outputs, zero docs maintenance. It worked so well that it sparked the question: what other areas of our documentation can be built automatically?
2. Feature Flags
Feature flags had been documented in a hand-edited Markdown file that nobody maintained because nobody wanted to. Flags would change status or defaults, and the docs would silently drift out of date — leading to confused bug reports.
The fix: I added structured metadata comments directly to the config file — flag category, default status, lifecycle stage — and wrote a script to generate the documentation pages from those comments. The result is a comprehensive, organized reference page that's always accurate because it's generated directly from the source of truth. Contributors never have to touch a docs file for feature flags again.
3. API Documentation
Superset had the standard Swagger renderer for its API that most projects end up with — functional but not great. We replaced it with an interactive Docusaurus-powered playground featuring code samples, response objects, parameters, and a real testing interface. All auto-generated from the API spec.
4. Database Connection Docs
This was one of the most impactful changes. Superset connects to a large number of databases via DB engine specs that sit on top of SQLAlchemy dialects. The documentation for these connections was hand-edited, frequently wrong, and nobody could definitively answer the question: "How many databases does Superset support?"
I used AI to add rich metadata to every DB engine spec file in the codebase — supported features, time grains, custom error messages, connection details. A build script now generates a fully searchable, sortable index page that answers the "how many databases" question instantly, plus individual pages for each database with truthful, up-to-date connection information.
The side effects were significant: better SEO (people can now search "does Superset connect to database X?" and get a real answer), better partner optics (every supported database gets a logo and a link), and — most importantly — no one has to maintain database docs anymore.
5. React Storybook Integration
Like many React projects, Superset had a Storybook collecting dust. Nobody ran npm run storybook to explore components; they just dug through the code.
We integrated Storybook directly into the Docusaurus docs using a collection of plugins, with AI handling the refactoring of hundreds of story files. The result goes beyond standard Storybook — contributors and extension developers get a live code editor where they can type code and interact with components directly, see all props, import paths, and even link to edit the underlying story file.
6. The "In the Wild" Page
The community showcase page had been a Markdown file that nobody knew existed, so nobody updated it. I converted it from Markdown to YAML (with AI assistance) and built a Docusaurus page generator around it. Now Superset has a polished showcase page with company logos, GitHub contributor faces, and a scrolling logo wall on the homepage — all auto-generated from the YAML data file.
7. Automated Screenshots with Playwright
This project was still in progress at the time of the talk, but the approach is compelling. Superset already uses Playwright for testing. Playwright can take screenshots. So we're building scripts that navigate to the right part of the DOM, capture the UI in the right state, and copy the images into the Docusaurus site — meaning screenshots update automatically whenever the UI changes. Combined with versioning (each new docs version locks screenshots at the right point in time), this eliminates one of the most tedious maintenance tasks in documentation.
The Bigger Picture: Open Source and AI Training
I made a broader point that seemed to resonate with the audience: open source projects have a unique advantage when it comes to AI. Everything about a project — the code, the people, the design patterns, the history, even the arguments on GitHub — is public data that foundation models train on.
That means making your documentation as comprehensive and current as possible isn't just a user experience play. It's an AI training play. Better docs today means more accurate AI assistance for your project tomorrow. The AI chat on Superset's homepage is already fine-tuning on the doc site, and the more the docs improve, the more useful those AI helpers become.
What's Coming Next
Beyond the screenshot automation, I outlined two major upcoming areas: a theming documentation playground (Superset now supports full theming for embedded analytics and brand customization, and the docs for theme creation will be auto-generated from the underlying component libraries), and the extensions ecosystem — where each extension's JSON manifest will auto-generate its marketplace page, making the docs scale automatically as the community extensions registry grows from ten extensions to thousands.
The Takeaway
The Q&A surfaced a practical question: how long does this take? My honest answer: it varies. Some projects — like the "In the Wild" page — took a couple of hours. Others — like refactoring hundreds of Storybook files — involved a lot of iteration. But each project chips away at the maintenance burden permanently.
The feedback from contributors has been positive — not because the docs look better (though they do), but because they no longer dread the docs step of a pull request. When the documentation builds itself from the code you already wrote, the friction disappears.
So that's the message I came to Brussels to share: don't let AI write your docs. Let it build tools that let your docs build themselves.
Watch the Full Talk
Explore the results:
The Maintainer Unconference
The day after FOSDEM wrapped, I joined fellow open source maintainers at the GitHub Maintainer Unconference at Les Ateliers des Tanneurs in Brussels. If you're not familiar with the format, an "unconference" is a participant-driven event where the agenda is created on the spot — attendees propose topics, vote on what interests them, and then break into small groups for focused discussions. There's no stage, no slides, just conversations.
The gathering was focused on what project maintainers want to see happen with open source over the next decade and how we can make it happen. I led breakout sessions on maintaining community growth and contribution at scale, and on using AI tools and agentic workflows to reduce contributor burden — topics that extend naturally from the documentation work I'd presented the day before. Other discussions covered governance and licensing, funding models, and the growing pains that successful open source projects face. The prevailing sentiment was optimistic: this really is the moment when open source shifts from being the exception to being the default mode of software development worldwide.
Networking with the Data Community
Earlier in the week, I attended the Brussels Meetup: Open Lakehouse and AI hosted by the Open Source Analytics community. Altinity — one of our partners and co-organizers of OSA CON — brought together folks from across the database ecosystem to talk about real-time analytics, open table formats like Apache Iceberg, and the convergence of data lakes with analytical databases. It was a great chance to reconnect with friends at Altinity, meet new collaborators from Dremio and others, and talk shop with users and maintainers who live in the same data infrastructure world that Superset serves.
FOSDEM 2026 Gallery
Wrapping Up
FOSDEM is one of those rare conferences where the hallway track is just as valuable as the sessions. Between the talk, the unconference, and the meetups, I came home with new ideas, new connections, and a renewed appreciation for how much momentum open source has right now. If you're working on an open source project and haven't made the trip to Brussels, I highly recommend it.
Related Reading
- Apache Superset Community Update: January 2026 — The month the Developer Portal launched, with details on the shift toward self-maintaining documentation.
- Apache Superset Community Update: December 2025 — Covers the community extensions registry launch and the extensions system that drove the need for a Developer Portal.
- Dosu + Apache Superset: AI-Powered Maintenance — How Superset uses AI-powered tooling for project maintenance beyond documentation.
