The structure of KDE, or how anarchy sometimes works

KDE is a funny beast. In a lot of ways, it’s an anarchic society that actually works!

Engineers and designers work on KDE software and websites, but none of them are paid by KDE itself. Most are volunteers but some (myself included) are paid by 3rd-party companies. These people work on what they want or what they are sponsored by their company to work on, not what anyone in KDE tells them to work on.

KDE has a board of directors, but they are elected by KDE’s membership rather than stockholders (there is no stock lol), and they do not control KDE’s strategic direction as in a corporation. Rather, they mostly take care of financial and legal matters, sort out copyright claims, help to organize the yearly Akademy conference, and so on.

There is no formal “upper management” or even “middle management” layer. We have the “gardening team” whose members are in essence volunteer managers, but we mostly do things like triaging bugs, following up on stuck merge requests, performing QA on unreleased software, and so on. We support the people doing the work, rather than telling them what to do.


So how does anything get done around here?!

Well, just because KDE is an anarchy, does not mean that there is no organization and coordination! It’s just all done on a voluntary basis, with slightly unusual motivation techniques. Anarchy is not the absence of governance and decision-making, it’s just different from how it’s typically done.

In a corporation, managers motivate their employees by offering them them money, benefits, bonuses, promotions, and internal social perks. Bad work or bad behavior is punished by reprimands, demotion, or being fired.

But in KDE, most people are unpaid volunteers, so KDE has no financial leverage over them. Those who are paid are hired by 3rd-parties rather than KDE itself. Neither the carrot nor the stick will work!

Instead, motivation within KDE uses the currency of excitement. When a project is cool and its contributors publicly demonstrate its coolness and their enthusiasm for it, other people want to join in and help out! This turns out to be a very effective way to motivate free people to work on something: you make them feel like they want to be a part of something big and special, and you organize the discussion in a way that makes them feel like they can be included.

KDE’s design team (the VDG group) does a lot of this, constantly churning out astonishingly beautiful mockups and organizing discussions about important topics. People gravitate to the VDG’s proposals because they seem cool and there’s buzz and excitement surrounding it. The promo team works to generate that buzz and excitement. Other teams do similar things. You have to keep people excited and happy or else they will drift away.


This leads to an important point: you have to minimize negativity! For most people, conflict destroys energy and motivation. Internal arguments and politics need to be minimized and driven towards a consensus rather than simmering forever. Even if you have to bend a bit and give up some of what you want, that’s a better option than getting nothing because everyone is burned out by endless arguing. And new contributors in particular must be treated with kindness, given the benefit of the doubt, and made to feel welcome.

Similarly, if you’re a user who’s frustrated with the lack of progress on something you care about, insulting the developers or KDE itself in the bug report is the worst thing you could do: it will damage the motivation of the people in a position to do the work, reducing the chance that you will get what you want. Gently pinging people without negativity is the way to go–or even better, work on it yourself! Like all FOSS projects, KDE encourages self service. 🙂

In essence, KDE’s little anarchic digital utopia works because we all voluntarily agree to treat each other with respect and kindness and become stakeholders in the project, and this greases the wheels of all the work we do. Somehow, it all manages to work!

2020 KDE roadmap: mid-year update

Here’s a mid-year update on the 2020 roadmap I proposed six months ago:

FUSE mounts to better support accessing remote locations in non-KDE apps: DONE

kio-fuse was released in beta form early this year and is already packaged in many distros. It’s working great! The final release will happen later this year.


Privilege escalation in KIO and Dolphin: AT RISK

It turned out that there was more work remaining here than I had anticipated. Unfortunately nobody seems to have the critical combination of domain knowledge, interest in working on it, and time to do so. Assistance on https://phabricator.kde.org/D7563 would be appreciated to help make it happen this year.


Improved Samba share discovery in Dolphin: DONE

This was implemented for Dolphin 20.04. By all accounts, it’s working quite well!


Auto-rotation for tablets, convertibles, and other hardware with rotation sensors: DONE

This was implemented for Plasma 5.18 and works on Wayland (getting it working on X11 is a lost cause, apparently). If it isn’t working for you on Wayland, it’s likely that you don’t have the iio-sensor-proxy package installed, or your hardware isn’t supported by the kernel yet.


Implement more of the proposed visual design changes to the Breeze style and KDE apps: ON TRACK

Work is proceeding at a good pace. The new System Tray design was shipped with Plasma 5.19. We’re targeting 5.20 for the new application appearance and patches are landing. Things are on track.


Better wallpapers in the extra wallpapers repo: AT RISK

This is blocked on implementing a wallpaper cache. I took a stab at it for Plasma 5.18 but it turned out to be more complicated than I had anticipated and I kind of got demoralized and dropped it. Need to resume the work.


Per-screen scale factors on X11: UNLIKELY

Focus has shifted toward Wayland in a big way, and for the past few months, veteran KDE developers have been smashing Wayland problems left and right. They’ve gotten clipboard support working with Klipper and going between Wayland and XWayland windows; made Spectacle work properly; fixed a number of drag-and-drop issues, and are very close to finishing task manager thumbnails, screencasting, and more! Given the progress and momentum, there’s a strong desire to make Wayland finally usable rather than hack things into X11 that it was never designed to support and are unlikely to ever work properly.


Inertial scrolling throughout Plasma and QML apps: UNLIKELY

No work has happened here. A lot of the issue are in Qt itself and are very challenging to resolve, especially on X11. There may be more hope for getting it done on Wayland.


Power/session controls on the lock screen: AT RISK

I started implementing this and got it kinda-sorta working but then lost motivation and forgot about it. Sorry about that. I need to get back into it.


Well there you have it! Of course this is just a tiny fraction of the stuff actually going on, it’s just what’s relevant to the proposed roadmap I outlined earlier.

As always, if you want to see these things happen faster, please feel free to help out! The code is public and the people are friendly. 🙂 What do you have to lose!? Nothing, that’s what!