Hear dinosaurs ramble! The panelists will tell the story of how they joined up and got sucked into the amazing community that is KDE. Afterwards we'll discuss what the best way to join is and what to avoid.
Ever wondered what happens to all the bug reports that get submitted? Wanted to help out with bug triage but didn't know how to get started? Want to know how bug reports help developers take action? Come find out!
... Or How the Sovereign Tech Fund Invested in KDE
In 2026, the Sovereign Tech Fund commissioned work to bring KDE software closer to readiness for large enterprises and public institutions. Members of KDE e.V., enioka Haute Couture, and Techpaladin Software joined forces to prepare the proposal which led to this investment.
Join us to get a peek behind the curtain of such an endeavor. We'll explain how we got there and our (not so) secret recipe for success.
In this talk, we'll cover the scope of the project and explain how the conversation with the Sovereign Tech Agency unfolded. This will also include insights on how we structured and estimated such a large project.
Can we expect further momentum for KDE products' adoption in the enterprise and public institutions? Is this the next step in KDE's quest for world domination with freedom and choice? You be the judge.
With its 30 years of publicly available commit history, KDE is an exceptional project. More than 5,000 people have contributed more than 8 million lines of code in almost 900,000 commits in the core modules alone. This presentation will show some graphical insights into KDE's code base and its history. We will touch the shape of its modules, its release history, peek into the work of some exceptional contributors and get a feeling for how the activity moved around over the years. And we will explore the stories behind some of its most significant events.
Spoiler alert. KDE is more alive than ever. The last two years saw more people contributing than any year before. And that built on all the work from the decades before. In this session we will see how.
This talk shows you what sorts of problems you might encounter while attempting to contribute to KDE and how to address them: whether they are a normal part of the onboarding experience, unexpected issues, or indicative of flaws in our onboarding that need fixing.
"United we stand, divided we fall." "There is strength in numbers." "Sticks in a bundle are unbreakable." There exist several cliches about the importance of working together, and no one knows the value of collaboration more than FOSS contributors. But perhaps sometimes overlooked is the importance of cross-community collaboration. In this talk I will take a deeper look at the collaborations which were part of KDE Eco's "Opt Green" project, in particular the "End Of 10" campaign. The focus will be on how building alliances with groups outside of KDE opened doors to new audiences and new opportunities. There are two main types of collaborations which I will explore, namely (i) those with other FOSS communities and (ii) those with adjacent communities such as Repair Cafes and environmental groups. What approaches were taken? What were the advantages? And disadvantages? What other opportunities for collaboration are there looking forward?
In this talk we will discuss some best practices that you should apply when creating software to ensure that you can sustain high quality development. This includes things such as the spanish inquisition, static analysis, and licensing.
The desktop interface has remained fundamentally unchanged for over two decades, relying on legacy paradigms that haven't scaled to meet new modern needs.
Industry leaders like Apple and Microsoft are too deeply entrenched in their established ecosystems to risk radical shifts. While the Linux community has shown some appetite for experimentation, much of it has nibbled at the edges such as focusing on tweaking window management.
This talk reflects my lifetime experience as a UX designer at Apple and Google and how the deepest innovations happen at the most mundane level: richer input, better data flows, and breaking out of our 2d windowing prisons. Ironically, the open source nature of Linux and specifically KDE provides a unique opportunity to break free from these legacy constraints.
The Qt framework is one of the foundational building blocks on which most of KDE's applications are build upon.
Conveniently, the expected final release of Qt 6.12 overlaps with Akademy. So let's take a tour through what Qt 6.12 brings to the table, and also check what will come next.
The talk will look at shiny technical additions (liek hardware accelerated imperative painting and improved QML tooling, HarmonyOS as a new platform), and revisits modules moving out of TP. Moreover, there is also the topic of regulation, like the Cyber Resilience Act (CRA). There will be an overview of what Qt (both the company and the framework) have done in that area, and how this might be relevant even for FOSS projects like KDE.
What happened in Plasma since last Akademy? Many of us here alwayas use the latest and greatest from the master branch, so we see changes gradually. Seeing the main things that changed since last year puts in perspective how much work we do as a community to make the user experience better and better. We'll see also what it expects us for the year to come, for future planned featuresand exciting new possibilities that the wayland-only session will give us
KDE has a lot of code. All that code we want to ensure keeps working. We have lots of different bits and pieces in place to ensure that our code keeps working.
In this talk we are going to look at various aspects of how technical quality assurance is done in KDE. This includes CI, unit/integration tests, sanitizers, static analysis.
We are going to see what we use, what the strengths and limitations of those are, and what we might to better in the future
During this talk, I would like to present progress for Ocean Design at Plasma. We have a list of advances to show:
I'll talk about everything related to Vulkan in KWin: What it even is, what it's replacing, why we need it, what's already implemented and what I'm hoping to achieve with it in the future.
If you change a blueprint or add a new one then you should test it before you push it to the master branch to avoid breaking the Craft builds for you and others.
In this talk I will briefly demonstrate how to do this on KDE's CI/CD system.
In this presentation I would like to discuss the work we have done over the last few years towards getting closer to our users and how it culminated in my work embracing BuildStream as a solution for our builds.
We will cover why it is a good idea, why it's an area that is important to put a lot of care on and how we will do to make sure that it remains a good idea and, most importantly, which possibilities BuildStream enables once everything is in place.
With improving Continuous Delivery (CD) infrastructure it has become easier than ever to use bleeding edge builds of our applications. This is reducing the threshold for users to become contributors.
KDE software is tremendously useful for teaching. It greatly helps from teaching elementary school pupils to university level students. I believe that acceptance for using free and open source software in teaching environments has recently risen given increased attention on digital sovereignty.
Given these circumstances, I was allowed to participate in two projects bringing KDE to local pupils and students last year. I would like to share some takeaways from these projects to hopefully motivate others to run similar projects. The perceived open mindedness to using KDE software in schools is certainly a great incentive.
One of the projects took place in a local elementary school. It started with a 1000 Euro grant which was used to organize hardware to set up a popup computer lab. We were able to furnish seven individual computer workstations, each powered by a Raspberry Pi 7.
Given these computers, we ran multiple sessions splitting a class' students in two groups so two students could collaborate per workplace. All of the RPs run KDE as sole desktop environment. We started with multiple sessions using Gcompris and eventually moved forward to smaller programming exercises and even assignments involving electronic components.
The other project involves the evolution of two lecture rooms at a local
vocational school. One of them is a pure Linux lab and the other is a dual
boot lecture room. Both use KDE as main desktop environment. The key here
is probably how we slowly increased acceptance from other teachers and how
we are planning to spread KDE software further.
The great acceptance of the above projects clearly shows that KDE offers great features for teaching. From pupils touching a keyboard for the very first time to students of post-secondary computer science programs.
In 2006, I prepared my first Kdenlive release. Twenty years and 151 releases later, where are we ?
Is Kdenlive still relevant ? Will it finally get GPU support ? How is the community doing ? And more importantly, are we still having fun ?
I will try to answer these questions, and give you a better overview of our plans.
This talk will provide a brief overview of what has been going on in KEcoLab over the past year, which includes full OS migration, tooling improvements, and contributions from SoK26 student Hrishikesh Gohain. Two issues we will discuss in some detail are: (i) porting usage scenario scripts from xdotool to ydotool+kdotool; and (ii) setting up a lab machine dedicated to measuring KDE Plasma itself, which presents interesting new scripting and measurement setup challenges.
Whenever a KDE Goals cycle comes to an end, it launches us into an upward spiral toward the next. In this panel, we’ll look back at the achievements of the 2024–2026 Goals cycle:
And finally, announcing new goals & champions
In September 2025, a few of us Open Source nerds heard that the Bavarian government wanted to "sneakily" "invest" another billion Euro in Microsoft Cloud, Teams and 365 – without a tender, and before the year ends (Base contract)
I talked to friends, and we created an open letter. Soon we were like ten initiators. We found support among many Bavarian Open Source companies and NGOs, only weeks later > 160 companies and institutions had been signing the letter.
When larger German NGOs like the Gesellschaft für Informatik (Society for Informatics) and the Bund der Steuerzahler (Tax Payers' Association joined, the Bavarian Government could not stay silent any more. Leading up of today, two secretaries and the minister president have engaged in a public blame game. At first they were angry about the unwanted, additional publicity - and publicly said so.
The goal of sneakily accomplishing the deal until end of 2025 failed and it is still not finalized. But now - four weeks before an election, secretaries of state for digital and finance are fighting publicly, accusing each other of "fake news" and are saying silly things.
On camera - and in parliament.
"OSS is too expensive" or "We needed something federated, decentralized and secure, thus we had to go for MS 365" and similar. It's fun.
What we can learn from this? PR for OSS works, timing is helpful, topics are important and claims like "ONE BILLION!!" are valuable. No one knew Trump, Greenland and Davos would come to help us, but they did and made it hard for the conservative Bavarian government to keep doing what they had always been. And we were a bunch of people that stuck it out.
And it's so important that we the OSS community learn how to play against the lobbys. We need to apply the "divide and conquer" strategy against the real enemies, not internally.
In 2026, the Sovereign Tech Fund commissioned work to bring KDE software closer to readiness for large enterprises and public institutions. As part of this work, KDE PIM infrastructure had to be improved.
In this talk, we will cover the bug fixing and improvements we did around Akonadi resources and their protocol libraries. This will help all the applications using Akonadi to be at the forefront in term of protocol updates.
To get there, we also setup an end-to-end tests suite using Python. We will thus do a detour on how we structured those tests for better test data management and reduced flakiness. It will also show the bugs you can catch this way but not with unit tests.
If your life is stored in an IMAP and a DAV server, if you'd like things to be easier to configure, or if you'd like a better Flatpak experience for KDE PIM applications, then join us and rejoice! We'll tell you what you can expect to see in the next release.
KDE Linux is two years old. Building an operating system turns out to be hard! Along the way, we've learned a lot about what users love. We'd like to share it with other OS builders as we've learned from them, and lay out what's next.
A talk in three parts, building towards a vision for a sovereign desktop in 2026 (and a look back).
Loved. In 2003, together with Eva Brucherseifer, Jan's company relevantive ran the first large-scale usability study of the Linux desktop on behalf of decision-makers considering migration. KDE 3.1 on SuSE was tested by 60 office workers with no prior Linux experience; 87% enjoyed working with it, 80% estimated they could reach professional competence within a week. The Linux desktop wasn't a usability disaster — but realising its potential required deliberate configuration, honest naming, and treating migration as a human-resources problem, not a technical one. The findings shaped a decade of OpenUsability work inside KDE. They are, awkwardly, almost entirely still applicable. We'll look at what stuck, what didn't, and why "lovable" — not merely "usable" — is the bar today, and why getting it right cuts the cost and risk of every migration discussion that follows.
AI-native. A desktop that loves you back has to know you. Personal AI has crossed the threshold where the desktop itself can be compiled per user, per device, per moment, from a small portable model of the user — what we are sketching as Kadai: an encrypted, vendor-agnostic personal kernel from which Plasma assembles each Activity. Plasma is uniquely well-fit for this — Activities, Plasmoids, the existing scripting surface — but a handful of upstream changes (declarative reconciliation, per-widget capabilities, richer Activity metadata) would turn KDE into the first shell that treats AI as infrastructure rather than as a chat box bolted to the side.
Sovereign. Once a user owns their model and their tools, the same question returns at institutional scale. EU institutions, member countries, and a long tail of organisations are openly asking what a credible, non-colonialising desktop stack looks like. No project carries this alone — a sovereign desktop is an ecosystem question. KDE is uniquely positioned as the shell, the integration layer, the experience; but filesharing belongs with Nextcloud, the browser with Firefox, the office suite with .... The last third of the talk is about what KDE's partnership surface could look like — outward, to industry and public administration, and sideways, to the allied open-source projects that already do the rest of the work better than anyone could redo it. Who owns that surface, where it lives, what KDE e.V. would need, what not to build. Sovereignty, from this angle, is just lovability and AI-ownership scaled up to the organisation: the user not owned by a vendor, the institution not owned by a foreign supplier — and the stack not owned by anyone, because the right partners hold the right pieces.
This talk is an invitation — from peple with a long arc inside this community — to take a serious swing at the question the 2003 study posed and never quite resolved: what would it take for KDE to be the desktop people actively choose, not just the one some of us settle for? Attendees will leave with: a concrete proposal (KaDAi) to react to or tear apart, a clear set of asks the project could direct at Plasma maintainers, and the framing for a sovereignty conversation that KDE is uniquely positioned to lead.
Format: 30 minutes of content with an open structure that invites interruption; 10 minutes of Q&A.
This paper argues that KDE's most significant and durable contribution to the technology landscape is not its desktop environment, its application suite, or its adherence to open standards - though these are substantial. Its most radical technology is its governance model: a self-organizing, volunteer-driven community structure that has resisted capture, sustained creative output across three decades, and preserved user autonomy as both a practice and a value. We examine the historical conditions that produced this model, analyze its structural features, identify the pressures it faces in an era of platform consolidation and corporate open-source capture, and propose a framework for understanding community governance as a form of infrastructure. The paper concludes that KDE's next decade depends less on technical roadmaps than on deliberate investment in the social architecture that makes the technical work possible.
StyleKit (formerly known under the working title "Unified Style") is a new QML module shipped with Qt 6.11 under the "Qt.labs.StyleKit" namespace.
StyleKit is a declarative styling system for Qt Quick Controls and Widgets, built on top of Qt Quick Templates. It lets you define a complete visual style for all your controls from a single Style document, including support for themes, state-based styling, and transitions. StyleKit handles the underlying template implementation automatically, letting you focus purely on visual aspects such as colors, dimensions, borders, and shadows.
A key strength of StyleKit is its hierarchical property system: set a property once on a base type like abstractButton, and it automatically applies to all button-like controls. Override it where needed for specific controls or states. Changes to your style are instantly reflected across all controls, ensuring consistency while still allowing fine-grained customization.
This talk will introduce the module, demonstrate how it works, and outline future plans.
In this session the board will report on the activities of KDE e.V. over the past year.
By examining its past, its present restoration, and its potential future, this presentation contextualizes Oxygen, the flagship theme of the KDE 4 era, within the broader questions it raises for KDE as a project.
We argue two things about Oxygen: that it carries genuine historical and artistic value, and that KDE's continued stewardship of the theme reflects something important and positive about our community. Namely that KDE Plasma is a user's desktop, one that is willing to prioritize user choice over narrow cost-benefit development logic.
In recognition of both Oxygen’s value and in line with the values of KDE, Oxygen has been undergoing an active restoration effort. We present the state of that work: what has been accomplished, what obstacles were encountered, and what dilemmas arise when preserving a theme of this kind. Here we also take the very positive user feedback received as a signal that there is clear demand for designs rooted in the very principles Oxygen is rooted in.
The future certainly does not involve redesigning the Oxygen that was, but it does carry the potential of its evolution into the Oxygen that will be, new modern Oxygen's, built on the same principles, of pushing the boundaries of what we do in the design space in OSS. This work also opens a larger question about what KDE wants to offer in terms of theming infrastructure and available themes. Our position is that preserving the original Oxygen is worthwhile in its own right, and that working on its evolution can be beneficial for bettering the new theming infrastructure, as fostering the next generation of OSS designers.
The Linux printing ecosystem is currently undergoing one of its biggest architectural transitions in decades. Since the CUPS 2.2.x series, printing has increasingly moved toward IPP-native and driverless workflows, allowing applications to print directly to discovered IPP print destinations without requiring manually created print queues, PPD files, or vendor-specific driver filters.
With the upcoming transition to CUPS 3.x, legacy printer drivers and classic PPD-based queue creation will be removed entirely from CUPS itself. Non-driverless printers will instead require Printer Applications that expose printers through modern IPP interfaces. These changes significantly affect desktop printing infrastructure and require desktop environments to adapt to more dynamic, asynchronous, and network-oriented workflows.
This talk explores the ongoing modernization work in KDE Print Manager to prepare for these changes. It covers the migration away from older synchronous request handling, improvements to UI responsiveness and request lifecycle management, and the architectural challenges involved in modernizing mature desktop infrastructure software while maintaining compatibility with existing workflows.
The session will also provide an overview of how KDE Print Manager interacts with CUPS and the broader Linux printing stack, discuss the implications of the CUPS 3.x transition for KDE and Linux desktops, and highlight future directions for modern desktop printing infrastructure.
Whether you are interested in KDE internals, Linux desktop architecture, or the future of printing on Linux systems, this talk offers insight into the engineering challenges and design decisions involved in preparing KDE Print Manager for the next generation of Linux printing.
Tarun Srivastava has started the work voluntarily in the end of 2024, continued it as Google Summer of Code 2025 project for OpenPrinting (his final report) and is currently working on its completion in the Google Summer of Code 2026. His main mentor is Mike Noe, responsible for the printing support in KDE, and additional mentors are Till Kamppeter, co-founder and lead of OpenPrinting, and Nico Fella.
More about OpenPrinting:
- OpenPrinting News - 25 years of OpenPrinting
- OpenPrinting in Google Summer of Code 2026
- Destination Linux #351 - Till Kamppeter and Michael Sweet
- Tech over Tea #299 - Till Kamppeter (highlight clips)
- FOSDEM 2024 - OpenPrinting - We make printing just work!
In this session the working groups of KDE e.V. will present their work of the past year.
Trees need regular maintenance to stay healthy and productive.
In this talk we are looking at how to take care of a tree, and what it can teach us about software and community.
Find out why it's important to license all your files from the get-go.
Present how dolphin is made accross its libraries usage and plugins, its wide usage, its community involvement, and future work ahead.
Activities are a very powerful, yet heavily under-appreciated (and under-explained) feature of Plasma.
In this lightning talk I would like to convince you why they are cool and to join us in the Activities BoF to discuss how both Activities themselves and KDE’s messaging/documentation/onboarding about them could be improved.
The quick talk will do an overview on the implementation of a new mouse and touchscreen feedback kwin effect that involves a very basic fluid simulation shader that produces pretty and realistic looking water ripples around the mouse cursor or the touch points
Eike's adventure using KDE/Qt/HMI software in the field on an archeological mission for a robotic system!
Akademy Awards (10-20 mins)
Closing Announcements - GET TO THE PARTY (5-10 mins)