Plasma 6: “Better defaults”

The 2023 Plasma sprint is now finished! KDE Patron Tuxedo Computers were kind enough to open their offices to us for a full week to do the sprint. We had some great conversations with Tuxedo employees, who were very friendly and excited to work with us, and made us thoroughly aware of just how much more complicated modern keyboard backlighting is than we had imagined! I’d like to thank KDE’s Software Platform Engineer Nicolas Fella for organizing this sprint, and Tuxedo Computers for providing the space and free pizza for lunch yesterday. πŸ™‚

Happy KDE Developers in Tuxedo's offices for the 2023 Plasma sprint
This actually isn’t all of us, because we foolishly forgot to take a picture earlier when everyone was present!

This won’t be a retrospective of the entire sprint, because I don’t want to steal anyone else’s thunder! People will be blogging and making videos about their own personal work and experience, so this one will be about mine.

The first thing was to get a Plasma 6 session working for daily driving. My colleagues have been working unbelievably hard on this, and I’m happy to report that I was able to live on Plasma 6 for the entire sprint without major showstoppers (from the perspective of a technical developer, of course). Almost everyone else there was as well, and I expect this to lead to extremely rapid stabilization despite the heavy code refactoring underway. I plan to continue living on Plasma 6 until its eventual release, and I encourage any adventurous developers to do so as well. If you try it out and submit any bug reports, make sure to add the “qt6” keyword to it.

I also did a bunch of technical work of my own, but I largely found myself in the role of facilitator, hosting discussions and meetings with different groups of people to bridge gaps.

KDE developers discuss topics, with one joining via video call

New Default settings

As a result, we advanced a number of topics that had been stuck for a while. A major area of my focus in this respect became “Better default settings”. The 5 -> 6 transition is the perfect time to make significant changes to the default settings in a way that improve the UX out of the box. Among these are:

Double-click by default

Link to task

Wait, did I just bury the lede!? I did indeed. This is because the work hasn’t actually been done yet… but it has in fact been approved! That’s right, Plasma 6 will default to opening files and folders with a double-click, not a single-click. Even though almost everyone in the room for the discussion actually uses and prefers opening with single-click, we had to admit that it’s probably not the ideal default setting for people who are migrating from other platforms, which is most of them. They can still learn the benefits of single-click later. πŸ™‚

Wayland by default

Link to task

We’re going to make a very strong push for Wayland to be the default session type for Plasma 6. The X11 session will still be there of course, and distros will be free to override this and continue defaulting to X11 if they feel like it suits them better. But we want Wayland to be our official recommendation.

To get there, we went over our “Wayland showstoppers” wiki page with a fine-toothed comb to refine what we really consider a showstopper. We decided that a lot of them are really more like annoyances rather than showstoppers, because X11 has plenty of annoyances of a similar severity too! The true showstoppers are down to five, plus a couple of NVIDIA issues that need further investigation. Many of these issues are in progress with a clear path towards resolution, so I do expect us to be able to achieve the goal!

Floating Panel by default

Link to task

This feature has been optional since its introduction a year ago. In that time it’s become quite popular, but its visual fanciness alone wasn’t enough to tip this proposal over the finish line. Rather, it’s the fact that Microsoft has blatantly copied us in Windows 11, and as a result, people are starting to see Plasma as a cheap clone of Windows again. We see this all the time in the VDG room when some rando comes by and starts telling us why our design isn’t as good as what Windows 11 has; they’ve implicitly made the comparison and found us wanting. It’s the wrong mindset!

Making the panel float by default provides an immediate visual differentiation from Windows 11 and we hope this will help jolt users’ brains out of “ew, it’s slightly different from Windows 11” mode and into “wow, this is new and cool and I wonder what’s in it” mode. There’s probably more that needs to be done for that, but I think this is a good start.

Plasma desktop showing floating panel and Audio Volume popup over a desert canyon landscale with scrubby juniper trees
And let’s face it, it’s also just sexy af

Accent-color-tinted header area by default

Link to task

In the middle of the Plasma 5 lifecycle, we switched to the Breeze Light color scheme by default, and we changed its appearance to use a medium gray header area, sort of mimicking the visually pleasing CSD headerbar look without actually using CSD headerbars. This appearance change has generally been well-received by users, but it faced a persistent criticism: diminished ability to distinguish the active window at a glance.

It’s a legitimate problem, and we decided to fix it by lightly tinting the header area with your current accent color (or the current color scheme’s selection color, if you’re not using Accent colors). This will distinguish the active window with a small amount of color, making it pop more without being visually overwhelming. Something like this:

Note: this is a mockup and the appearance is not final! So don’t go posting this all over social media declaring that it’s going to be the way everything looks forever πŸ™‚

New default Task Switcher

Link to task

For a while, we’ve had a goal of switching our current default “Breeze” Task Switcher to something that doesn’t vertically scroll with even a relatively small number of windows, which feedback had indicated was bad for usability. We also wanted to make our default task switcher better for people who navigate primarily by looking at app icons rather than thumbnails or text. With those design goals in mind, we decided to use the “Thumbnail Grid” Task Switcher by default and make some UI changes. Here’s what it looks like at this point in time:

As a part of this work, we also deleted a bunch of infrequently-used Task Switchers in the kdeplasma-addons Git repo that were simply worse versions of other ones. And finally, we made our Breeze Global Themes no longer have an opinion about what they want the Task Switcher to be, so if you use a non-default one, you can safely switch Global Themes without having it reset your Task Switcher all the time! That makes it less annoying to use the Dark and Light buttons on System Settings’ Quick Settings page to switch the system’s appearance between those two states.

This work is already merged and was done by me.

No more scrolling on desktop to switch virtual desktops by default

Link to task

We got feedback over the years that scrolling on the desktop to switch virtual desktops was disorienting, especially because you could switch to a desktop that you couldn’t switch out of in the same way because the desktop was covered up. So we decided to turn this feature off by default. If you really like it, you’re still welcome to turn it back on, of course!

This work is already merged and was done by me.

Clicking in scrollbar track jumps scrollbar to that location

Link to task

This change makes it easy to scroll straight to a specific location without having to drag the scrollbar, which is worse from the perspective of avoiding repetitive motion injuries. The old style is still available as an option to can switch back to.

This work is already merged and was done by me.

Other discussions and decisions

Many other discussions were also had besides just default settings. Here are a few:

City of Treuchtlingen’s use of KDE software

We found out that the nearby German city of Treuchtlingen has been using KDE software for over 20 years for their government IT purposes. Two representatives came out to the Tuxedo HQ to give us a presentation and we all talked about how to continue this going forward not only for us, but potentially for a lot of other German governments. The possibilities here are quite exciting.

A slower-paced release schedule

Link to task

In the beginning of Plasma 5, the release schedule was very fast–four releases a year. As it stabilized, we went down to three, which we kept for the whole lifecycle of Plasma 5.

Over time we’ve gotten a lot of feedback from distros in particular who have told us that this represents a hardship. It’s also been my personal observation that we often don’t have enough time to polish a new Plasma version before it’s released.

Now, a fast release cycle makes sense for a product under heavy development that breaks a lot of things and needs to fix them quickly. However, at this point Plasma is mature and feature complete after 8 years of hard work. It can always be improved, of course, but it pretty much does everything a general user needs at this point in time. So a fast release schedule isn’t as useful as it once was.

For Plasma 6, we’re going to try a slower release schedule of two per year once we feel like it’s stabilized enough after its initial release. And we’re going to be reaching out to distros with twice-yearly release schedules themselves to see if we can find release dates that will allow all of them to ship the latest version of Plasma soon after it’s released rather than skipping it in favor of something older. Making use of these lengthened release periods, we’re also going to lengthen our Beta releases and update them on a weekly basis, so there’s more time to find and fix bugs. We’re hoping this should result in Plasma 6 having a high level of stability and reliability throughout its lifecycle.

A wallpaper page in System Settings

Link to task

We agreed that the status quo isn’t ideal because people expect to find wallpaper settings in System Settings. So we started sketching out a wallpaper KCM that will let people change their wallpapers in a central location, including the ability to apply them to the lock and login screens. You’ll still be able to access the wallpaper changing UI from the current method in addition to the new KCM.

Consolidate Desktop plugins

Link to task

Currently we have two default desktop plugin types: “Folder” (the default) and “Desktop”. “Desktop” is just “Folder” without support for desktop icons. This is a bit silly, and internally they’re 99% the same because its prior developer also thought it was a bit silly and implemented them with the same backend code. So for Plasma 6, we’re going to collapse the distinction in the UI and instead expose a “Show desktop icons” checkbox somewhere. This will make it even easier for people who don’t like desktop icons to hide them, avoid putting implementation details in front of the user, and de-clutter the wallpaper choosing view.

Keyboard backlighting is hard

Taking advantage of the fact that we were in Tuxedo’s offices, we took the opportunity to ask many Tuxedo employees about their and their customers’ biggest pain points with KDE software. Happily, there were actually few complaints. But something that came up a few times was how we handle keyboard backlighting. Currently our code assumes there will be one keyboard backlight that affects all keys, so it only affects the first one it finds. But many modern laptops have more than one backlight, with some even giving each key its own! Needless to say, the result of adjusting a single backlight on such a keyboard looks somewhat hilarious. So we plan to put some effort into improving this.

That’s not all

This blog post contains only a small sampling of what was done and talked about during the sprint. There are many, many other plans and in-progress projects for Plasma 6, but I’ll let others talk about their own projects elsewhere, so look for them on! I’d say that Plasma 6 promises to be a very large and exciting release.

Help make it possible again

Thanks again to Tuxedo Computers for graciously opening their offices to us, and for Nicolas Fella for organizing the sprint!

In addition, funding for the sprint was covered by KDE e.V., the nonprofit backing KDE. As you can probably imagine, transporting and lodging 20 people for a week is expensive, and most e.V. funding comes from individual donations. So if you’d like to see more of this kind of thing, please consider making a donation today! Every little bit helps!

Planning the future of Plasma

This week my fellow developers and I are in Germany for an in-person Plasma sprint–our first since 2019! For this reason, there will be no normal weekly blog post today, and instead next week there will be a combined “what happened over the last two weeks” and “what happened during the sprint” blog post, since otherwise there would be significant of overlap. There’s a lot to do, and here are some of the topics we’re covering:

  • Stabilizing Plasma 6 so we can all start living on it full-time
  • Discussing significant UX changes we want to make in Plasma 6
  • API changes for Frameworks 6 that are relevant for Plasma
  • Design vision for Kirigami and various Kirigami-related topics
  • Improving our test infrastructure

…And a lot more! I’ll be able to share additional details next week. Wish us luck!

The 15-Minute Bug Initiative

In my 2022 roadmap, I mentioned something called the “15-Minute Bug Initiative.” Today I’d like to flesh it out and request participation! This blog post is not only informational, but I really hope any developers reading along will get excited and decide to participate. πŸ™‚

KDE software has historically been accused of being resource-intensive, ugly, and buggy. Over the years we’ve largely resolved the first two, but the issue of bugginess persists.

Have you ever had that experience where you’re introducing someone to a KDE Plasma system and to your horror, they run into multiple bugs within moments? These are the issues we need to fix first: those that can be easily encountered within 15 minutes of basic usage. They leave a bad taste in people’s mouths and provide the impression that the system is a house of cards. It’s time to remedy this final strategic weakness of KDE, starting with Plasma itself. So I’d like to present our initial list of bugs:

If you have any software development skills, working on these bugs is a super impactful way to make a difference with code!! Every fixed bug is a huge deal, and brings Plasma meaningfully closer to a position of true stability.

Likely-to-be-frequently-asked questions

1. What are the criteria for being a 15-minute bug?

It’s an inherently squishy thing, but I look for the following:

  1. Affects the default setup
  2. 100% reproducible
  3. Something basic doesn’t work (e.g. a button doesn’t do anything when clicked)
  4. Something basic looks visually broken
  5. Causes Plasma or the full session to crash
  6. Requires a reboot or terminal commands to fix
  7. The bug report has more than 5 duplicates

The more of those conditions apply, the more likely that any Plasma user will run into it quickly during normal usage, and the more I feel like it qualifies.

2. Who determines what gets to be a 15-minute bug?

KDE developers and bug triagers make the call.

3. I’m a developer or bug triager; how do I add a bug to this list?

Change its Priority to HI. If you don’t have permission to do this, ask sysadmins for “editbugs” permission over here:

4. I’m not a developer or a bug triager; how can I help?

You can go through the list and try to reproduce or confim the bugs, and do investigation into root causes and triggering factors for the ones where this isn’t already known. Those are important because a skilled developer can usually quickly fix a bug they can reproduce. But if they can’t, then they may never be able to. So if you can help developers reproduce bugs, that’s extremely valuable.

5. I’m experiencing this annoying issue that’s not on the list! Can you add it?

Maybe. Mention the 15-minute bug initiative in the bug report for it, and KDE’s bug triagers will see if it makes the cut.

6. Why are you only doing Plasma bugs right now?

Lack of resources. The list currently has almost 100 bugs, and I don’t anticipate that we’ll get it down to zero in a year. A lot of the issues there are quite challenging to fix. But if I’m wrong and we blaze through everything, then I’ll absolutely broaden the initiative to include first frameworks, and then apps! Stabilize all the things!

So that’s the 15-Minute Bug Initiative. Let’s get cracking and make Plasma rock solid in 2022!

KDE roadmap for 2022

Another year, another roadmap! Last year’s was a smashing success, as we delivered on everything. So here’s what I think we can expect in 2022. As always, this is not an official planning document or a promise; it’s just me giving you a sneak peak of some things that are in progress or about to start, and that I think will be feasible to complete before the year’s end!

Merged “Formats and Languages” KCM

The Languages and Formats pages in System Settings have long been problematic because their scopes overlapped. Not for long! Han Young is working on merging them together into one new page that handles both, making it clear what applies when and making it harder or impossible to mess up your system by choosing incompatible settings. This is in progress and I expect it to be completed sometime in the first half of 2022.

Overhauled Breeze icons

KDE designer Ken Vermette is working on improving and modernizing Breeze icons! Colorful icons will be softened and rounded a bit, and visually updated to remove old ugly elements like the long shadows. Monochrome icons will eventually get attention too. All of them are expected to become more responsive to your system color scheme, and look better when doing so. Initial work for Places icons has already been submitted and is being reviewed. This work will soon start landing piece by piece, and you can read more about it on Ken’s blog.

Multi-monitor stuff finally works properly

We plan to focus quite a bit on resolving multimonitor issues this year, and some of that effort has already borne a bit of fruit so far. But there will be a much heavier focus in 2022!

Inertial touchpad scrolling in QtQuick software

A big improvement went in recently that will make this possible to do soon! It seems quite likely that we’ll finally have this sometime in 2022.

The Wayland session can completely replace the X11 session

This is a bit of a moonshot but I think it’s possible. The list of issues on our “Wayland Showstoppers” wiki page is quite low, and when new ones are added, they’re notably lower in severity than the ones that have already been fixed. And now that NVIDIA has added GBM support to their driver and KWin already supports it, I think life should really start to get better for NVIDIA users, who represent a large chunk of dissatisfied Plasma users and those still unable to use the Wayland session at all. Let’s call this a stretch goal, but I think it’s not impossible!

“15 minute bug” initiative

This year I’d like to start something I call the “15 minute bug” initiative–an effort to fix as many of the bugs as possible that are trivially encountered within a quarter hour of basic usage. These are the kinds of issues that form permanent negative opinions in people’s minds, and reinforce the perception that KDE software is buggy and unreliable.

So far I’m limiting it to Plasma and Plasma-aligned software (e.g. KWin, System Settings, Discover) to avoid getting overwhelmed by scope creep. But if it’s wildly popular and successful, I’d love to extend it to apps and frameworks as well! Check out the current list here. I’ll be writing about this in more detail soon!

So that’s the list! What do you think? Is there anything else you think we should focus on in 2022?

2021 roadmap mid-year update

It’s time to check where we are on the items I mentioned for my 2021 roadmap:

Polkit-in-KIO: ON TRACK

This work is proceeding and is currently in the final stages of QA. I expect it to finally be merged sometime this year!

Power/session actions in the lock screen: AT RISK

No new work done. May not happen this year.

Production-ready Plasma Wayland session: ON TRACK

In part due to it being an official KDE goal, a truly enormous, herculean amount of work has gone into making the Plasma Wayland session usable, to the point where the Fedora KDE spin has decided to enable it by default in Fedora 34, which ships Plasma 5.21. This is quite a vote of confidence! I fully expect that by Plasma 5.23, it will be broadly usable for day-to-day use. I find that it’s almost there for me.

Fingerprint support throughout the stack: AT RISK

No new work done. May not happen this year. We are kind of blocked by the necessary SDDM pieces not being done yet. Assistance needed.

Finish up Breeze Evolution: ON TRACK

Work is proceeding and the new widget style will land in Plasma 5.23. After that, most of the remaining work requires changes to apps themselves, particularly to make them less framey. Adopting KHamburgerMenu in more of our apps will help too, and it’s already been done for Dolphin and Gwenview, with more on the way.

Kickoff replacement: DONE

We landed the new Kickoff in Plasma 5.21, to mostly positive feedback. A few of you loved the old Kickoff and have decided to keep using it, which is fine. But overall, the new one has been a hit!

Reflowing text in Konsole: DONE

This work was completed early in the year to universal acclaim. A much needed improvement!

Overall we’re in a good state. If you’d like to see this work happen faster, please help out! Review merge requests, file bug reports, submit code–the sky’s the limit.

KDE roadmap for 2021

Just like last year, here are the things I expect will get done in 2021:

Leftovers from last year

We’ll finally finish up polkit-in-kio, which got closer in 2020 but didn’t quite make it. 2021 will be the year! We will probably also get power/session actions in the lock screen as this feature is necessary for Plasma Mobile, and making it work in the Plasma Desktop session as well will be fairly simple. Per-screen scaling on X11 seems unlikely given our renewed focus on Wayland, and on that subject…

Production-ready Plasma Wayland session

I’ll be honest: before 2020 the Plasma Wayland session felt like a mess to me. Nothing worked properly. But all of this changed in 2020: suddenly things started working properly. I expect the trend of serious, concentrated Wayland work to continue in 2021, and finally make Plasma Wayland session usable for an increasing number of people’s production workflows.

Fingerprint support throughout the stack

This is already in progress! It’s a lot of work because support needs to be added in SDDM, the lock screen, KAuth, Polkit… There are a lot of moving pieces to put together. I think 2021 will be the year that it finally happens!

Finish up Breeze Evolution

This work is in progress and about half of it has already been merged, to be released in Plasma 5.21. I expect the rest will land in Plasma 5.22 and possible 5.23 later in the year. At that point, the project will be complete and our apps will look super modern and awesome!

Kickoff replacement

A super-fantastic replacement for the venerable Kickoff application launcher has been in heavy development throughout 2020, according to the spec that VDG wrote in 2019. It’s almost done, and I expect it to be merged soon and be released in Plasma 5.21.

Reflowing text in Konsole

This is already in progress and very close to being done! 2021 will be the year that Konsole’s window finally re-flows the text when you resize it.

I feel like we’re getting really really close to the goal of having a mainstream-hardware-ready software stack. In some ways we’re already there, especially when you compare our stuff to some of the weaker offerings in the market. We need to keep plugging away, and start thinking about the next steps: more hardware partnerships, closer coordination with distros, and more engineering effort for our own Neon distro. 2021 is going to be a great year for KDE and KDE users! So what are you waiting for? Get involved! πŸ™‚

How KDE can transcend the cycle of Geeks, Mops, and Sociopaths

A few years ago I read a fascinating article about the cycle of how subcultures grow, mature, and die. The whole thing is worth a read (as well as the whole site), but here’s the abridged version:

  1. Creators invent something new and cool, attracting fanatics who validate them and help spread it around. These people are the “Geeks.” I would guess that most current users of KDE software are in or near this group.
  2. The coolness attracts “Mops”–normal people who want to enjoy the cool thing with minimal effort or investment. They dilute the coolness by demanding that it be simplified, sanitized, and mainstreamed for them. In KDE terms, these people would be our non-technical friends and relatives.
  3. At this point, the Geeks may start to quit because the coolness has been destroyed by the Mops. However sometimes the Geeks realize that Mops are key to expanding the cool thing even further.
  4. At this point Sociopaths will appear–people who participate in a system for the money or power games. They figure out how to monetize the Mops, allowing some Geeks to go pro and create the cool thing full time.
  5. Sociopaths increasingly exploit both the Geeks and the Mops, because they’re in it for the money and social power.
  6. The Geeks increasingly burn out because they’re spending their time unpleasantly interacting with exploitative Sociopaths and compromising their original vision to placate demanding Mops who provide their income.

I’m old enough that I’ve started to notice this cycle play out in various hobbies, subcultures, and even commercial companies I’ve been involved with: they start out small and cool, but along the way, mainstreaming and commercialization seem to corrupt everything.

I’ve also noticed that many FOSS projects seem to avoid this cycle and the dark fate at the end. Not all do, but some seem to. Why? How?

How FOSS helps

In the FOSS world, Mops are not easily monetized. The product is given away for free, after all! Only mildly Geeky Mops will be attracted, and the more entitled mainstream Mops can be told to pound sand when they start to demand more. They didn’t pay anything, so they’re not entitled to anything.

As a result, many FOSS projects are able to preserve their stable niche status because they explicitly reject a strong Mop appeal, limiting the attractiveness for Sociopaths. To tie this fairly theoretical discussion back to the software world a bit, Arch Linux is a good example: not having an installer acts as a gate to keep out low-investment Mops, ensuring that the project remains safely in the hands of the Geeks.

However this kind of gatekeeping–intentional or not–has a drawback: if the gate is too strong, the project may shrink over time as the original Geeks get bored or driven away by internal politics. Because the pool of Geeks is fairly limited, Geek-only growth largely involves poaching from other Geek projects; it’s a zero sum game.

What to do? Is it really a matter of keeping out the Mops and staying small, or letting them in and burning out after growing huge? And how am I able to reconcile knowledge of this cycle with my stated goal to get KDE Plasma onto every computing device on planet Earth? Earthlings are mostly Mops, after all.

How KDE can do it

Well first of all, I acknowledge that my goal is more aspirational than realistic. πŸ™‚ Better to shoot for the moon and fall short, I think. I’d be pretty happy if we get Plasma to 15% global market share. That’s enough to be a major player with a direct and ongoing positive impact on human civilization.

Anyway, here’s how I think KDE can avoid the cycle, and grow powerful without being corrupted:

Attract all the Geeks

You may notice how many sysadmins, software devs, and general nerds have Apple computers outside of the FOSS world. In the early 2000s, Apple attracted a huge number of Geeks by pairing support for power-user workflows with an attractive user interface and high reliability. This was the “It Just Works” factor, for people who were doing work. It allowed Apple’s ecosystem to maintain a favorable Geek-to-Mop ratio, at least until the iPhone took off. KDE can realistically follow this path as well. I myself am a former Apple nerd. We can convert them. And the more Geeks KDE has, the more engineering talent it will accumulate, and the more Mops it can safely support.

Minimize the project’s reliance on Mop money

This avoids creating a financial incentive to dilute the product, and it reduces the project’s appeal to Sociopaths (at least, the ones who are attracted to money). KDE already has this pretty well covered, because we don’t sell products directly to consumers for money–with the exception of Krita on the Windows store (to my knowledge), and even then there are simple ways to get Krita for free if you want. The existence of a free version is a pressure valve.

Preserve the KDE community’s gravitational center for development

Today KDE benefits from outside companies paying people to work on KDE who are benevolent: Blue Systems (my employer), Enioka Haute Couture, KDAB, SUSE, the city of Munich, and various others. But it won’t always be this way as KDE rises in importance.

Large companies with little exposure to the FOSS world, but who use or sell products with KDE software, will want to hire their own engineers to contribute to KDE so they don’t feel like they’re shut out of the development of a product that significantly affects them. If enough of this happens outside of KDE itself, we run the risk of the project being taken over by sheer weight of outside contributions by large companies.

This is why I feel so strongly that the KDE e.V. should start hiring community members for technical roles. With the KDE community itself clearly in charge of the gravitational center of paid engineering, these outside companies would find it more convenient to simply pay money to the e.V. to strengthen those development efforts, join a sort of technical advisory board, or pay for priority access to engineering resources to fix bugs affecting them (not features, only bugs). These could give those companies the the “seat at the table” that they’re looking for while keeping technical decision-making firmly in the hands of the community. The project would be able to remain independent more easily.

It’s not a problem we urgently need to solve right now, but it will be in the future if we’re as successful as I want us to be. I think it behooves us to do it now rather than later.

Hire Geeks, not Mops

Whenever someone is paid to work on KDE stuff–either by the KDE e.V. or anyone else–always prioritize hiring KDE community members over outsiders. There’s always the risk that the outsider is a Mop who just wants a paycheck rather that someone who truly believes in KDE. Those with the privilege of being paid to work on KDE stuff should be people who go above and beyond because they love it.

Foster a culture of resistance to Sociopathy

KDE will probably never be an institution where you can get rich quick, and I see this as a good thing. But not all Sociopaths are in it for the money; some crave power. An important project like KDE will still hold appeal for the type of Sociopath who wants to push everyone around as the king of a little digital fiefdom. We need to keep these people out.

Unfortunately, while Geeks are generally good at noticing when Sociopaths show up, they are generally terrible at kicking them out. Geeks can be conflict-averse, or believe that the Sociopaths can be reasoned with, reformed, or safely tolerated because they do some good work. They cannot be.

KDE needs to maintain and expand a culture of resistance to Sociopathy by teaching its members to harden themselves against Sociopaths and and use some of their own tactics against them when they show up. Nobody should be the king of KDE. KDE should not have a king! Central leadership is a risk factor, as I blogged about earlier.

What it all looks like

KDE will attract as many Geeks as possible through our continued commitment to technical excellence and supporting power user workflows in our software. We minimize the risk of demanding Mops burning everyone out by not selling anything to them directly and maintaining a favorable Geek:Mop ratio through our attraction of lots of Geeks. We start paying for engineering talent, but we hire insider Geeks, not outsider Mops. And we do it within KDE itself. Then we remain vigilant for Sociopaths craving power, and we kick them out so that KDE can remain a safe place for the Geeks.

So who’s ready to take over the world with love and positivity and user-empowering high quality software?

Inside KDE: leadership and long-term planning

Based on my post about KDE’s anarchic organization and the micro-not-macro nature of my This Week in KDE series, you would be forgiven for having the impression that KDE is directionless and has no leadership or long-term planning capabilities. In fact the opposite is true, and I’d like to talk a bit about that today, since this information may not be obvious to users and the wider community.

Now, since KDE is so vast, I can only provide my personal perspective based on the projects I’m most heavily involved in: the VDG, Plasma, and a few apps.

Overall direction

First of all, you might be surprised to hear that the KDE e.V. board of directors does not act as a technical or strategic leadership body. This is in fact by design; their role is to support the individual project teams (which provide their own leadership) with infrastructural, financial, and legal support. Instead, there are two sources of cross-project planning and leadership in KDE:

  • We democratize long-term planning by allowing the community itself to vote every two years on three goals to prioritize. Members of the kde-community and various developer mailing lists are eligible to vote, so sign up for the kde-community mailing list if you’re not already a subscriber! The current set of long-term goals are Consistency, Wayland, and Apps, following the last set which were Onboarding, Usability & Productivity, and Privacy. These are cross-project goals. There’s no formal mandate to follow them, but project leaders are expected to take them into account. The idea is basically to understand which things are most important to the KDE community as a whole. We’ve done two rounds of this now and I think it’s been quite successful.
  • Additional coordination and strategic planning is provided by members of the KDE Gardening Team, which is essentially our version of upper and middle management. Anyone who cares about the global state of all KDE software and KDE as a community is welcome to join or participate.

On a personal level, I’m a member of the Gardening Team, and my overarching goal is to help KDE get our software shipped by default on hardware all over the world. I have given two Akademy presentations on the subject–one in 2018 and one in 2020–detailing the process I think we can follow to get there. Everything I work on is designed to further this strategic goal.

Small or narrowly scoped projects

Some individual KDE projects use the maintainer model (sometimes known as the “benevolent dictator for life” model). Leadership and planning are easy: the maintainer does it all. This generally works fine for small or focused projects like apps. Many of KDE’s apps follow this model with great success–such as Krita, Kdenlive, Dolphin, Konsole, and so on. A wise maintainer listens to the input of others and changes his or her mind when presented with reasonable alternative perspectives, but ultimately that person makes the call. If you don’t like the call, tough. It’s their project, not yours.

Broadly scoped projects

Projects that touch everything, either from the top (UI side) or the bottom (technical infrastructure side) tend to have a lot of interested parties and stakeholders because of how their activity affects others. Some examples within KDE would be Frameworks, Plasma, KWin, and the VDG.

The maintainer model is often not used for these projects. Instead, an alternative model commonly arises, which I’ll call the “council of elders”: 3-5 of the most active and respected contributors who have strong viewpoints or leadership tendencies will organically emerge to govern the project.

A project’s council of elders is collectively responsible for its long-term priorities and technical direction. Decisions are made on the consensus model, with agreement required from all elders before any kind of potentially controversial action is taken. Sometimes this can take a long time! Discussions are generally public and take the form of status and sync-up meetings, ongoing discussions in the relevant chat channels, Phabricator tasks, and mailing lists. However some of these discussions do take place behind closed doors. For example, when my employer Blue Systems is sponsoring some bit of work and the people working on it are a part of some project’s council of elders, the initial planning for it often takes place inside Blue Systems-specific venues. However it typically moves upstream as soon as practical, once the work is suitable for initial public consumption. And I think the best development and planning happen in the open.

Maintainer vs council of elders

An advantage of the maintainer model is that one person is clearly in charge and has the final say, avoiding endless debate and allowing high speed of decision-making. However even if a project has a humble maintainer with good collaboration skills (such a person is worth their weight in gold), they’re still only one person. People can lose interest, burn out, or die–the notorious “bus factor” of a project. Or the maintainer can simply take the software in a direction that you don’t like. Relying on software steered by a single individual requires trust that none of these things will happen.

The council of elders model solves these problems with its power sharing arrangement. In so doing, it gains the ability to survive the loss of any given elder and provides stability and continuity for 3rd parties who would rely on it. The project does gives up a measure of speed and decisiveness in decision-making as a consequence. However there’s no reason why a council of elders has to fall prey to squabbling. In my experience it only happens if any of the elders in the council disagree with the others but take a “my way or the highway” approach rather than reaching for compromise or admitting that they may simply be wrong.

It’s natural for people–including any of the elders themselves!–to sometimes feel frustrated with the council’s lower speed of decision-making compared to a sole maintainer. But everyone appreciates the immortality that the council provides to the project and its resistance to the problems of a tyrannical or negligent maintainer. For these reasons, there’s but slow but natural drift from the maintainer model to the council of elders model as projects mature over time, especially for software used as a base for other software.

Does it work?

KDE doesn’t lack for strategic long-term goals and direction, so I think that part can be pretty solidly marked as a success. As for tactical leadership and direction within and between individual projects, I also think things are pretty rosy overall. KDE’s maintainer-led projects generally have excellent maintainers. The variety of KDE apps using this model model is a testament to how successful it can be with a high-quality maintainer–especially our professional-class apps like Krita. And in my opinion, KDE’s council of elders projects also have very good leadership today. I think you can see this in the successful roll-out or ongoing progress of various multi-year initiatives:

I could go on; there are tons of long-term projects being worked on behind the scenes. My blog posts may actually be hiding this, because I tend to blog only about the user-visible elements once they’re finally merged. In reality, large projects are often started months or years before the final UI piece of the puzzle is fitted into place. If people are interested, I can try to blog more about the foundational stuff too–or at least encourage others to do so, as this is not my area of expertise. πŸ™‚

Now, has everything been perfectly smooth? No. Are there problems? Yes. Have some things moved too slowly? Certainly. Such is life! And I’ll talk about those things in a future post, because I do think that we can improve upon the way we do things in various ways. But overall, I think KDE’s long-term planning abilities are pretty impressive, especially for a mostly volunteer community!

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!