Aleix Pol Gonzalez (KDE president), Lydia Pintscher (KDE vice president), and myself are doing an AMA on Reddit right now for the next hour and a half. Check it out if you want to ask us anything!
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.
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:
- Partnership with Slimbook to sell multiple iterations of KDE-branded laptops
- Progress towards the Wayland session becoming increasingly usable and stable
- Engagement with folks from other desktops and compositors to move various Wayland protocols forward in a cross-desktop manner
- Inter-process isolation throughout Plasma so that a crash in one component doesn’t take down everything else, which is especially important on Wayland
- Systemd startup (optional of course) with cgroups and slices for app launching
- VDG’s Breeze Evolution work, which is in the process of being merged for Plasma 5.21
- System Settings UX overhaul, which makes configuration a little bit better in every Plasma release
- Ongoing replacement of Phabricator with GitLab
- And more that I’m sure I’ve forgotten
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!
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!