Category: Inside KDE

About Plasma’s X11 session

X11 is in the news again, so I thought it would make sense to be clear about the Plasma team’s plans for X11 support going forward.

Current status: Plasma’s X11 session continues to be maintained.

Specifically, that means:

  • We’ll make sure Plasma continues to compile and deploy on X11.
  • Bug reports about the Plasma X11 session being horribly broken (for example, you can’t log in) will be fixed.
  • Very bad X11-specific regressions will probably be fixed eventually.
  • Less-bad X11-specific bugs will probably not be fixed unless someone pays for it.
  • X11-specific features will definitely not be implemented unless someone pays for it.

This is actually not too bad; there are relatively few open and fixable X11-specific bugs (0.76% of all open bug reports as of the time of writing), and when I went looking today, there were only two Bugzilla tickets requesting new X11-specific features that needed closing. Most bugs and features are platform-agnostic, so X11 users will benefit from all of these that get fixed and implemented.

Eventually it’s lights out for X11 though, right? When will that happen?

Yes, the writing is on the wall. X11’s upstream development has dropped off significantly in recent years, and X11 isn’t able to perform up to the standards of what people expect today with respect to HDR, 10 bits-per-color monitors, other fancy monitor features, multi-monitor setups (especially with mixed DPIs or refresh rates), multi-GPU setups, screen tearing, security, crash robustness, input handling, and more.

As for when Plasma will drop support for X11? There’s currently no firm timeline for this, and I certainly don’t expect it to happen in the next year, or even the next two years. But that’s just a guess; it depends on how quickly we implement everything on https://community.kde.org/Plasma/Wayland_Known_Significant_Issues. Our plan is to handle everything on that page such that even the most hardcore X11 user doesn’t notice anything missing when they move to Wayland.

Why are you guys doing this? Why don’t you like X11 anymore?

The Plasma team isn’t emotional about display servers; it’s just obvious that X11 is in the process of outliving its usefulness. Someday Wayland will be in this boat too; such is the eventual fate of all technologies.

In addition to the fact that Wayland is better for modern hardware, maintaining code to interact with two display servers and session types is exactly as unpleasant as it sounds. Our resources are always limited, so we’re looking forward to the day when we can once again focus on programming for a single display server paradigm. It will mean that everything else can improve just a little bit faster.

Regardless of when you pull the trigger, isn’t it premature?

Most major distros have already moved their Plasma sessions to Wayland by default, including Arch, Fedora, KDE neon, Kubuntu, and generally their downstream forks. Several others whose roadmaps I’m familiar with plan to do so in the near future.

At this point in time, our telemetry says that a majority of Plasma users are already using the Wayland session. Currently 73% of Plasma 6 users who have turned on telemetry are using the Wayland session, and a little over 60% of all telemetry-activating users (including Plasma 5 users) are on Wayland.

Interestingly, the percentage of Plasma 6 users on Wayland was 82% a month ago, and now it’s down to 73%. What changed? SteamOS 3.7 was released with Plasma 6 and the X11 session still used by default! Interestingly, since then the Wayland trendline has continued to tick up; a month ago the percentage of Wayland users dropped from 82% to 70%, and now today it’s up to 73%.

So you can see that to a large extent, this is up to distros, not us. It wouldn’t make sense for us to get rid of Plasma’s X11 support while there are still major distros shipping it by default, and likewise, it won’t make sense for us to keep it around long after those distros have moved away from it.

Regardless, Wayland’s numbers are increasing steadily, and I expect upward bumps when the next Debian and Kubuntu LTS releases come out, as both are currently planned to be Wayland by default.

Now, is Plasma’s Wayland session perfect? No. (what is?)

Is it better than the X11 session in literally every way? Also no.

Is it better in most ways that matter to most people? The numbers say yes!

Well I’m not a most people! I’m me, I’m an individual! I’m not a number, I’m a free man!

That’s fine, and you’re the reason why we’re still maintaining the X11 session! We’re going to try very hard not to to get rid of it until you’re happy too.

Ultimately that’s the goal here: make everyone happy! This includes people who have mixed-DPI/refresh rate multi-monitor setups or laptop touchpads, as well as people using AutoKey or graphics tablets with dials on them. Long transitions like this are tough, but ultimately worth it so that we all get something better in the end.

Akademy 2024: broadening, professionalizing, and being awesome

Akademy 2024 is a wrap, and others have already begun to write about the conference in beautiful Würzburg, Germany, with some posts already visible on https://planet.kde.org. This year’s Akademy was fantastic, probably the best one I’ve ever attended. Other than the A/V situation (which we’ll be addressing next year, pinkie-promise), it was well-organized and smoothly run.

But more substantively, the talks and sessions were incredible, and really wove together a coherent narrative: KDE has mature and effective leaders who are pushing forward strategic projects that combine to become more than the sum of their parts. Among them:

Design

Andy Betts introduced us to the concept of the design system and how he and other VDG designers are building one to help unify layout and style across KDE software. …then Arjen Hiemstra introduced us to Union, a new styling system intended to be a single tool to style everything, and it can be informed by the design system’s semantics as well.

Apps

Nicolas Fella explained how our app development platform is lacking, inhibiting the growth of a more vibrant KDE-centric app ecosystem. This is also the topic of one of KDE’s newest high-level goals (full disclosure: I’m a co-champion of this goal along with Nicolas as primary champion). Carl Schwan laid out his “App Initiative” which is directly related, and David Edmundson talked about how we can improve the ability of our software to work in sandboxed environments.

Distribution

Harald Sitter introduced us to “KDE Linux” (tentative name), a new technologically advanced OS that will offer a radically high level of stability, security, and polish for those wishing to get KDE software directly from the source. David Edmundson’s talk about sandboxing is also heavily related here as well.

Recruitment

But how are we going to do all of this? Paul Brown, Aniqa Khokhar, and Johnny Jazeix introduced us to the “KDE Needs You 🫵” goal, aiming to reach more people to broaden the pool of potential contributors so KDE is sustainable for years to come.

Eco

And finally, some perspective on a different sustainability issue: this was the hottest year on record, breaking records set just a few years prior. Our planet’s capacity to sustain human life in certain regions is starting to be impacted, and we need to consider both how our work exacerbates it, and how we can do our part to help make it better. Accordingly, we heard from Joanna Murzyn, Cornelius Schumacher, and Joseph P. De Veaugh-Geiss about KDE’s efforts to prolong the lifespan of old hardware so it doesn’t become e-waste. And Nicole Teale gave us some concrete hope by informing us about a program to introduce German schoolkids to the idea of upcycling old computers by installing Kubuntu on them, very similar to a similar program here in the USA that I was tangentially involved with!

Hopefully the themes and synergies here are clear. KDE is becoming more professional, more comprehensive in scope, will take more initiative for the distribution of its own software, will evolve that software’s design in a way that’s supported by modern design tools and professional designers, and contributes to solving the world’s biggest problems. I find this to be super exciting, and I hope you do too!

My personal role in Akademy was a bit more behind-the-scenes this year. I did take part in two presentations: the former goal wrap-up and the KDE e.V. Board of Directors report.

In these, I described the successes and challenges of my now-concluded Automation & Systematization goal, and helped to inform the community about KDE e.V.’s activities since last Akademy.

I also participated in Many birds-of-a-feather (BoF) sessions about various topics, including:

  • A tech discussion about KDE Linux — install it today and help make it great!
  • Plasma planning and roadmap — Plasma is in a great state, and we’re going to resume Monday meetings, this time in video form. I’ve got five specific features, UI changes, or bug-fixes I want to add to 6.3, and others have even more ideas.
  • Design team decision-making process — super useful; we came up with one to enable us to make important decisions again.

Beyond the BoFs, I found myself constantly talking to people between sessions, during lunch, and in what seemed like every spare moment! Including:

  • Björn Balazs about his work to create https://privact.org, a foundation building a next-generation method to gather metrics from users with zero risk to their privacy.
  • Jos van den Oever about KDE developers applying for sponsorship from https://nlnet.nl to work on important KDE and KDE-relevent projects. Seriously, go do it!
  • Eike Hein about KDE’s history and the 100% drama-free Trinity Desktop Environment.
  • Neal Gompa about the challenges involved in shipping an immutable-base-system OS outside of single-purpose appliances (i.e. as a desktop OS for regular people, enthusiasts, and developers).
  • Xaver Hugl live-debugged an issue on my laptop that he was able to speedily conclude was a Libinput bug.
  • …and many more I didn’t have the remaining brain capacity to remember!

All of this was completely exhausting, and I had to excuse myself from a few group events and dinners to rest and process the day’s events. But Würzburg being a ridiculously beautiful city certainly helped!

Döner kebab count: 3

This has been my favorite Akademy so far, and thank you so much to everyone who helped to make it possible — David Redondo, Kieryn Darkwater, Victoria Fierce, Lydia Pintscher, and the rest of the Akademy team! Job’s a good ‘un, and I’ll see you around the internet!

How YOU Help With Quality

In today’s other blog post, I mentioned how we’ve been getting a huge number of bug reports since the Mega-Release. If you’re not in software engineering, this probably seems like a bad thing. “Oh no, why so many bugs? Didn’t you test your software properly!?”

Since most people are not involved in software engineering, this perspective is common and understandable. So I’d like to shed a light on the assumptions behind it, and talk about the challenges involved in improving software quality, which is a passion of mine.

Don’t kill the messenger

See, bug reports are a “don’t kill the messenger” type of thing. Bugs are there whether they get reported or not, and getting them reported is important so you have a more accurate picture of how your software is actually being used by real people in the real world.

In our KDE world, the alternative to “lots of bug reports” isn’t “few bug reports because there are few bugs” but rather “few bug reports because the software isn’t actually being used much so no one is finding the bugs.” What matters more is the severity of the actionable bug reports.

What bug-free software looks like

That sounds so defeatist! Surely it must actually be possible to have bug-free software, right?

Yes. But to achieve it, you have to test literally every possible thing the software can do to make sure it performs correctly in the environment in which it’s doing it. If the software can do infinite things in infinite environments, then testing also becomes infinite and therefore impossible, so combinations get missed and bugs sneak through. Bug-free software must aggressively limit the scope and variety of those environments to just the ones that can be tested. What does that look like in practice?

  • Limit what the software can do in the first place. Remove as many features, options, and settings as possible without compromising the product’s necessary core functionality.
  • Limit how the user can modify and extend the software after release. No user-created themes, widgets, scripts–nothing! Every modification to what the software can do or how it looks must go through a the same QA team that QAd the software in its original state. 1st-party modifications only.
  • Limit the versions of upstream 3rd-party libraries, dependencies, and kernels that the software is allowed to use. Lock those versions and test everything the software can do on those specific versions.
  • Limit how downstream 3rd-party user-facing software (i.e. apps) can interface with the system. Lock it down in a sandbox as much as you can so any misbehavior can’t affect the rest of the system.
  • Limit the hardware that the software stack is allowed to run on. Test everything the software can do only on that hardware.

Does this sound very much like how KDE software is developed, distributed, and used? I’d say it’s more like how Apple builds products (and note that Apple products still have bugs, but I digress)! By contrast: KDE develops lots of features and options; we’re liberal with supported library, dependency, and kernel versions; and we don’t prevent you from installing our software on any random device you can get your hands on.

You can see the challenge right away! The foundation of quality is a set of restrictions that we don’t want to impose on ourselves and our users. You folks reading this probably don’t want us to impose them on you, either.

Quality from chaos

So is it just impossible to ensure quality in a permissive environment? No, but it’s harder. That’s right: we in the KDE free software world set for ourselves a fundamentally more difficult task than the big corporations with their billions of dollars of resources. Given this, I think we’ve done a pretty darn impressive job with the Mega-Release. And judging by initial impressions out there, it seems like many others agree too!

So how did we do it?

We lengthened our beta period to 3 months and relied on bug reports from people using the software in their own personal environments.

Yes you, loyal reader! We wanted to hear how our software was working on your 12-year-old Netbook. We wanted to hear how it worked when plugged into two TVs and a rotated monitor, all through a KVM switch. We wanted to hear how it coped with the most bizarre-looking 3rd-party themes. By using our flexible and non-limited software in your diverse ways on your diverse hardware, you’re testing it and finding all the bugs that we lack the resources to find ourselves.

Does this sort of QA work sound like something you don’t want to do? That’s 100% fine. But then you need for someone else to be the QA team for you. There are two options:

  • Buy a computer with KDE software pre-installed; there are a lot of them now! Then it’s the vendor’s responsibility to have done adequate QA on their own products. Is it buggy anyway? Complain to them or find a better vendor!
  • If you’re going to install it yourself, limit yourself to common hardware, default software settings, and operating systems that are relatively conservative in their update schedules. Then the QA has been provided by others who who already used your exact setup and reported all the bugs affecting it.

Become a superhero

But what if you do want to help out with making the software better for others, but you’re not a programmer? Congratulations, you’re a real-life superhero.

We’ve already talked about reporting bugs. It’s also important to do a good job with your bug reports so they’re actionable! I’ll encourage folks to read through our documentation about this. Low-quality bug reports don’t just waste our time, they waste yours as well!

But where do all those 150-200 bug reports per day that I mentioned actually go? There’s a flip side which is that someone needs to do something with every single one of them. The more bug reports we get (which, again, is good!) the more we need people to help triaging them.

Because the truth is, most bug reports don’t begin life being actionable for developers. They may be missing key information; they may be mistaking a feature for a bug; they may be describing an issue in someone else’s software; they may be about an issue that was already fixed in a version of the software that the reporter doesn’t have; they may be describing a real issue but in an unclear and confusing way; and so on.

The job of bug triagers is to make each of these bug reports actionable. Ask for missing information! Move them to the right products! Set the version and severity appropriately! Mark already reported bugs as duplicates of the existing report! Mark obvious upstream or downstream issues accordingly and direct people to the places where they can report the bugs to the responsible developers! Try to reproduce the issue yourself and mark it as confirmed if you can! And so on. It isn’t terribly glamorous work, so there aren’t very many people lining up to be volunteer bug triagers, unlike developers. But it’s very important. And so every person who helps out adds resources to what’s currently a very small team, making a massive difference in the process.

If you’ve been looking for a way to help out KDE in a way that doesn’t require programming or a consistent time commitment, this is it. Triage a few bugs here, a few bugs there. Chip in when you can. If 30 people each triaged three bugs a day (this would take under 10 minutes, on average), we’d be in an amazing position.

So get started today! I’m available to help in the #kde-bugs Matrix room.

Still don’t wanna? Donate to KDE e.V. so we can eventually hire our own professional bug triage and QA team!

Where bugfixes and new features come from

A few conversations I’ve had recently at Akademy 2023 have inspired me to write about a topic I’ve been wanting to share for a long time. So today I’d like to shine a bit of light on how the process of getting bugs fixed and features implemented works in KDE. This article’s target audience is general users more so than experienced technical contributors who will already have an understanding of this. But feel free to read anyway if you consider yourself a member of that group!

To begin with, I sometimes encounter the impression that there’s this pool of developers who either roam around looking for bugs to fix and features to implement, or are told or motivated to do so by some higher authority. This isn’t necessarily a misconception, but it needs to be qualified a bit. Well, a lot!

First we have the volunteers who are so often talked about! In general, volunteers work on things that feel rewarding to work on. As a result, most will only work on things relevant to their personal use cases, that are easy or fun, or that they feel a sense of personal obligation to continue working on. There are exceptions, but they tend to be rare and temporary, as the people in question often get hired by someone and lose most of their KDE time.

On that subject, some developers are sponsored to work on KDE software by KDE e.V., by a contracting firm in KDE’s orbit, or by a direct institutional or individual user of KDE software. In general these folks are paid to work on specific features and bug fixes relevant to the use cases of their employers or clients–which can be quite exotic, involving things like hundreds of users with networked home directories, specialized stacks of cryptography software and hardware, multi-screen multi-GPU setups, expensive business printers, and so on. These are the kinds of use cases that an average user never encounters.

There’s often some overlap here. Some paid KDE contributors work for a company that pays them to work on specific projects but gives them some personal time to work on KDE projects of their choice for a few hours a week. Some are contractors who reserve a bit of their own time to volunteer for KDE. And some are fortunate enough to receive open-ended invitations to “Make it better for us” as applied to a broad slice of the system.

This leads to some obvious conclusions regarding the kinds of bugs and features that are likely to get fixed and implemented. Here’s a chart that summarizes it:

Everyone likes the green box. A surprising number of bugs and feature requests fall into it. Even hard bugs can get fixed quickly if their impact is significant and widespread (which means many eyeballs on them) and they are trivially reproduced (which means fixes are easy to test).

Next we have bugs or features in the red box. These are mostly irrelevant to an average user. If you’re a non-average person or institution with a specialized use case, the course of action is clear: pay someone to fix or implement it for you. KDE e.V. maintains a list of contractors who offer such services. Otherwise it probably won’t get done. Expect to pay Real Money™ for this kind of service; targeted contracted software development is rarely cheap. Pizza money donations and average bug bounties ain’t gonna cut it!

Finally, we have bugs or features in either of the yellow boxes. Sometimes these kinds of things get done by volunteers, but it’s hit-and-miss with an uncertain timeline because the work is just not that important–as evidenced by the fact that institutional or individual users rarely if ever pay for them to be fixed. But of course, people who are affected don’t like being told that their small pain points are unimportant, so in my experience, these issues represent a big source of frustration for users in general. Fixing them anyway is a big part of the 15 minute bug initiative. …Which you may notice has stalled at around 50-60 bugs. These remaining bugs are all quite solidly in those yellow boxes where it’s hard to find anyone willing to either do the work or pay for it to be done.

But all is not lost! If you’re annoyed by a yellow-box issue, and you’re unable or unwilling to pay to have it fixed, there is another way to help: try to move the bug or feature closer to the green box somehow! Here are some ideas:

  • If the issue is truly major, help call attention to it. Perhaps it simply got missed among the endless flood of other bug reports. For this to work, the issue really does need to be major; I mean more like “causes data loss” and not “System Tray icons for my autostarted 3rd-party apps sometimes don’t show up.”
  • Identify the easiest possible way to reproduce the bug with 100% success on common and generic hardware, then mention it in the bug report and set its status to CONFIRMED.
  • Identify any volunteer developers in the bug report who take an interest in the issue but mention they lack the hardware to reproduce it, and offer to buy or loan them such hardware.
  • Start fixing or implementing it yourself, even if you know you can’t do it. Your draft work may be enough to motivate someone else to finish it up, or provoke the kind of normally unhelpful nerd-rage nitpicking that drives someone to show you how it’s done by doing it themselves!
  • Wait for the use case to become more widespread, and hence more important. High DPI, multi-screen, multi-GPU, and high refresh rate hardware setups have all become more common over time, and accordingly, the number of people willing to put effort into making them better (or pay for this to happen) has increased.

None of these suggestions guarantee success. But pushing a yellow bug towards being a green one does make it more likely to be worked on and eventually fixed. And anyway, hopefully this helps to illuminate how development work in KDE happens, and why some bugs reports or feature requests linger for a long time.

Presentation at University of Macedonia: Making a Difference

Today I had the honor of delivering a virtual presentation with fellow KDE contributor Neofytos Kolokotronis at the University of Macedonia, the site of KDE’s 2023 Akademy conference. The subject was “Making a Difference: How to contribute and jump start your career in Free Software with the KDE Community”, making it especially relevant for those who have been looking to get started contributing to KDE and don’t yet know how. But even if you’re a seasoned KDE contributor, I bet you’ll learn a thing or two about KDE’s storied history or ambitious plans!

Check it out:

On hiring, and fundraising to make it more biggerer

This year at Akademy, I took the plunge and decided to run for a seat on the KDE e.V.’s board of directors.

What is the KDE e.V.? It’s the nonprofit organization that represents the KDE community in legal and financial matters. It has several paid employees who work on KDE stuff, most notably promotion & marketing, project management, and event planning. You can see more at https://ev.kde.org/corporate/staffcontractors.

By the way, in case you were wondering (as I did at one point), “e.V.” is short for “eingetragener Verein” which is German for “registered association”–basically a type of nonprofit entity.

For several years, I’ve believed and publicly suggested that the KDE e.V. needs to have more technical positions. We need to directly hire KDE community members so they don’t have to seek employment with a 3rd-party company, or even drift away from the community when they have less free time and age into positions of greater financial need. In fact the KDE e.V. has already been moving in this direction, but slowly, because the available budget is pretty small compared to the vastness of the KDE community and the scope of more ambitious hiring. You can get an idea by looking at the report of the Financial Working Group in the 2021 annual report.

So I ran on a platform of hugely increasing both fundraising and technical hiring. And I’m honored to report that I won the election and am now a member of the board!

i got board

To those of you who voted for me, thank you so much for your support. For those of you who didn’t, I hope I can represent you well anyway, and if you get ticked off with anything I’m doing… please tell me! I welcome feedback. This position is all about being a good representative, and that’s what I want to be.

So what does this mean?

It means that a majority of the KDE e.V. membership approves of these goals, so when it gets more money, the KDE e.V. has a mandate to do more hiring–especially for impactful technical positions. It means we will eventually be able to have the big names in KDE paid by KDE, so they can stay in KDE over the long haul! And it also means we need a lot more money to make this happen.

There are a lot of steps to this, including figuring out the legal technicalities of full-time hiring, and increasing the budget so we can make sure we’re always offering market wages. We’ll be investigating potential ways to boost fundraising: hiring a professional fundraising director; applying for a lot more grants; having more explicit fundraising campaigns; gamifying fundraising; sending out nudgey newsletters to people who have donated in the past; making it easier to donate on a recurring basis; and more.

But for now, if you want to see us do more hiring, the best way is to make a donation to the KDE e.V. at https://kde.org/community/donations. It helps. It really does! This money is going to transform KDE into a professional powerhouse with its own internally-employed cadre of world-class superstars. We’re going to take on the Big Tech dogs and win, and we’re going to let our heavy-hitters make a living within KDE while doing it. But it can’t happen without your help, so please consider making a donation today!

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!