Video summary

KDE's Plasma Wants To Become The Linux Standard

Main summary

Key takeaways

Technology

KDE “Goals” + €1M Investment (Merged Discussion)

The video describes two parallel KDE effort streams:

  1. KDE Goals

    • Yearly, community-driven project priorities.
    • Contributors can champion a goal (not necessarily implement it).

  2. ~€1M funding for KDE software development

    • Broken into work tasks on GitLab.

At Akademy 2026, the community will announce the top 3 goals for the next year.

Current process details

  • There are currently 7 goals listed.
  • If there are more than 12, the list is reduced to 12 before voting.
  • Goal champions are expected to do leadership work, such as:
    • promotion
    • documentation
    • recruiting developers
    • (not only coding)

KDE Goals Highlighted

1) “Better documentation” (Nate Graham)

Goal: Make KDE documentation usable and accurate, comparable to fast-moving wiki-style documentation from other projects.

Critique

  • Outdated/misleading/duplicative docs are worse than none, because they push users toward:
    • forums, or
    • “LLM-generated” answers (with risks of hallucinations and added cost)

Proposed improvements

  • Emphasize tutorials (goal-driven “how to” content), not lecture-style docs.
  • Enforce single sources of truth (avoid multiple competing wikis for the same topic).
  • Retire redundant wikis, including reorganizing content logically.
  • Modernize documentation tooling using Hugo or Sphinx.
  • Improve the contribution workflow (make contributing easier).
  • Reduce confusing hierarchy; use index pages organized by use case, not “app”.
  • Build a contributor guide and replace fragmented materials (e.g., community.kde.org patchwork) with a handbook-style approach.

2) Ocean styling / design workflow improvements (Andy Betts)

Context: “Ocean” is positioned as the next styling direction after Breeze.

Problem addressed

  • KDE theming has become a patchwork of multiple approaches added over time, making it harder to maintain and evolve.

Focus

Rather than end-user theming, the effort emphasizes a designer → developer workflow:

  • reduce and clarify the barrier to entry for becoming a KDE designer
  • provide documentation and clear processes
  • ensure developers can implement designs that are practical (tight integration between designers and developers)

3) Accessibility / “Access Building KDE” (Edouard Filipas)

A proposed accessibility-related goal is mentioned, but the speaker criticizes the proposal mechanics:

  • the champion may not be listed correctly
  • accessibility work already has paid developer effort outside the goals process

Core point: KDE accessibility work will continue regardless, but the proposal structure is questioned.

4) KDE for Enterprise and Deployments (David Edmundson)

An enterprise/outreach goal aimed at institutional adoption.

Rationale

  • With EU government open-source momentum, KDE should be positioned as a viable option.

Example success metric

  • SUSE and RHEL ship Plasma out-of-the-box due to customer demand (described as ambitious but plausible)

Alignment

  • Tied to deployment work, and later linked to Sovereign Tech Fund items.

5) “Little loved but important apps”

(Referenced as coming from an “unnamed new KDE contributor” in subtitles.)

  • The aim is reasonable, but critiques include:
    • unclear adherence to the championing process
    • missing definition of which apps should be prioritized and why

6) Developer-friendly modernization & new technologies (Christoph “Gruninja”)

Critique

  • Again, an issue is raised regarding champion listing/qualification.

Technical intent

  • Adopt modern C++
  • Use modern CMake
  • Explore Rust integration possibilities
  • Use modern Qt tooling
  • Improve testing, including:
    • higher test coverage
    • smoke testing
    • leveraging GitLab CI capabilities

Some alignment with Sovereign Tech Fund work is noted.

7) “Pillars of KDE Linux” (Aleix Pol Gonzalez)

Presented as a successor/replacement direction for KDE Neon, targeting a reliable distro.

Main themes

  • improve KDE Linux quality assurance for consistent deployments
  • prepare for OEM readiness and wider device shipping
  • not to replace Fedora/Kubuntu/Arch-with-KDE/NixOS approaches, but to provide KDE Linux as a reference/beacon for packaging and support practices

Sovereign Tech Fund Work Items (7 items)

A) Improve KDE Plasma + KDE Linux QA infrastructure

Purpose: stronger automated testing for the desktop and distro.

Key points:

  • fix non-reproducible Appium-based automatic tests in Plasma repos
  • increase test coverage for Plasma Workspace and Plasma Desktop
  • build advanced QA for KDE Linux to catch issues pre-release
  • target QA for:
    • boot
    • login
    • upgrades
    • core functionality

B) Improve KDE Plasma recoverability mechanisms

Add and strengthen “safe mode”-style recovery:

  • safe mode disables third-party customizations to isolate what breaks Plasma
  • re-enable customizations one-by-one to identify the culprit component

Improve monitoring and control:

  • enhance System Monitor to identify misbehaving apps/processors
  • increase robustness of process termination and controls
  • ensure app quit UI remains functional during instability (including cases like OOM or graphical freeze)

C) Factory reset functionality for KDE Linux (OEM / lifecycle)

Enable baseline restoration without full reinstall, supporting device resale/reassignment.

Reset domains

  • full system reset (e.g., selling a device)
  • reset system configuration/state only (team/department changes)
  • reset user config/state for user reassignment within the same team

UI integration

  • add controls into Plasma System Settings

Design principle

  • ideally reusable by other distros (Fedora/Arch/NixOS, etc.), not locked solely to KDE Linux

D) Improved security infrastructure for organizational usage

Includes:

  • secure boot support
  • multi-factor authentication (optional; password + fingerprint)
  • face recognition authentication (Windows Hello-like)
  • non-password-based login support
  • disk/home re-encryption while screen is locked
  • improved authentication/locking UX

E) Data backup and restore systems

Introduce snapshot-based workflows and modernize backup tooling:

  • implement btrfs snapshots (local snapshotting service)
  • use a KIO worker to browse snapshots
  • add UI/context menu to restore older file versions

Improve KUp:

  • use btrfs snapshot sources
  • improve UX for network share backup targets
  • add restore UI during system setup

Emphasis: reliable versioning and recovery to reduce data-loss risk.

F) Improve network shares experience (enterprise pain point)

Motivation: network share behavior is unclear outside KDE apps; long-standing community complaints exist.

Planned work:

  • mount remote shares at persistent locations using KioFuse
  • integrate mounts into Dolphin Places and Open/Save dialogs

  • improve metadata correctness/integrity during copy/move via KIO/KioFuse (timestamps, xattrs, etc.)

  • improve network performance to better match traditional mounts (reduce overhead)

  • investigate io_uring to improve traditional mounts and port critical KDE software away from blocking filesystem calls

G) Strengthen configuration management as core desktop infrastructure

Enterprise/fleet deployment focus:

  • adapt KDE’s configuration system for centralized policy management
  • integrate with admin tools and remote management
  • research organizational needs/use cases and integrate with tools like:
    • Ansible
    • Puppet
    • Chef
    • Salt
  • modernize/extend KDE’s kiosk system based on research
  • provide extensive documentation for system administrators (connecting back to “better documentation”)

Reviews / Tutorial / Guide Emphasis

The video frames documentation as a product:

  • prioritize tutorials and a “single source of truth”
  • improve contributor workflows and documentation tooling (Hugo/Sphinx)

It does not provide formal product reviews of existing hardware/software. Instead, it’s a strategic analysis of:

  • what KDE goals/work items should accomplish
  • how success could be measured

Main Speakers / Sources

  • Nate Graham — documentation goal author; known for KDE work
  • Andy Betts — design/theming; Ocean styling goal
  • Edouard Filipas — accessibility-related proposal
  • David Edmundson — KDE for Enterprise & Deployments
  • Christoph “Gruninja” — developer modernization/testing goal
  • Aleix Pol Gonzalez — KDE Linux / OEM readiness goal
  • Unnamed video narrator/summarizer — primary narrator for the community proposals discussed

Original video