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!

9 thoughts on “Inside KDE: leadership and long-term planning

  1. Hey Nate, i wanted to thank you for all your hard work in giving KDE a voice. This is something it has sorely missed over the last years and as an on and off user of Plasma & Co work for at least 15 years (on for the last 3), i gotta say i really appreciate the effort you make to keep us in the loop.

    You offered to poke others about some posts and i’d love to have regular posts (i’m thinking about one per week from a different team/project, for example) about various topics of the whole community and process and i’m sure i’m not the only one. Technical posts, design challenges and ideas, community development and selected statistics are things that spring to mind that would interest me greatly. It would also give a better glimpse into the projects which in turn would make them more approachable for new volunteers. Just a thought, no expectations.

    Liked by 1 person

    1. Thank you very much!

      If you’re not aware of it, you might check out KDE blog posts are syndicated there. A lot of people already blog about this kind of stuff, it’s just good to encourage more. 🙂


    2. I was aware of it, but i also forgot it for a while and remembered it again when i wrote the comment. It’s pretty active still, which is awesome and more is always welcome. I’ll definitely follow it again.

      Liked by 2 people

  2. Thanks to Nate Graham for this follow up post to his ‘KDE is Anarchy’ blog.
    I think this was probably needed and it was good to see some detail on the various types of organisation within the KDE cadre.
    The term ‘Anarchy’ scares some people who conflate it with a more modern misconception of ‘chaos’. It is not.
    Anarchy itself simply means ‘no rulers’. It does not mean no rules. Nor does it deny leadership, organisation and structure.
    But wait, Nate wrote there is the “benevolent dictator for life” model! It is not anarchy then, you may say! Well, not really. This is the world of Open Source. If you do not like the direction of a project you can always reject it or fork it. A real/political dictator would deny you the right to disassociate let alone fork or compete.
    Being a “dictator” and controlling your own project is completely different to controlling others without their consent.
    This is the key factor. In anarchist systems all things are voluntary as there is no ruler (or rulers) to command and control otherwise.
    It also means there is no restriction on how people can organise.
    Some may claim that anarchy also means there can be no hierarchy, but not even this is true. Any structure that does not involve involuntary control is compatible with anarchy. It could be spontaneous order, ‘the invisible hand’, a collectivist structure, or hierarchy – as long as it is by voluntary association. Only rulers can deny people on how they choose to interact.
    Anarchy as Jeffrey Tucker explains is actually all around us!

    “Anarchy is all around us. Without it, our world would fall apart. All progress is due to it. All order extends from it. All blessed things that rise above the state of nature are owned to it. The human race thrives only because of the lack of control, not because of it. I’m saying that we need ever more absence of control to make the world a more beautiful place. It is a paradox that we must forever explain.”

    Liked by 2 people

    1. one type of order that is exclusive to a state of non-coercion (Anarchy) is ‘Spontaneous Order;.

      *Spontaneous order, also named self-organization is the spontaneous emergence of order out of seeming chaos. “spontaneous order” is typically used to describe the emergence of various kinds of social orders from a combination of self-interested individuals who are not intentionally trying to create order through planning. The evolution of life on Earth, language, crystal structure, the Internet and a free market economy have all been proposed as examples of systems which evolved through spontaneous order.[1]

      Spontaneous orders are to be distinguished from organizations. Spontaneous orders are distinguished by being scale-free networks, while organizations are hierarchical networks. Further, organizations can be and often are a part of spontaneous social orders, but the reverse is not true. Further, while organizations are created and controlled by humans, spontaneous orders are created, controlled, and controllable by no one.[citation needed] In economics and the social sciences, spontaneous order is defined as “the result of human actions, not of human design”*

      This is howI personally read Nate’s meant originally when he said KDE is “an anarchic society” That is, KDE is a Spontaneous Order.

      He also clarifies in this post that there is leadership and planning.
      “organizations can be and often are a part of spontaneous social orders” I think this actually fits the description of KDE. It is a minimal organisation utilising the power of spontaneous order. This is beautiful!

      KDE is 22 years old and has grown. I attribute this to strong decentralisation and the wonderful phenomenon of anarchic Spontaneous Order!
      Long may KDE embrace this successful attribute!


  3. “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.”

    Yes, I find the foundational stuff fascinating and also reassuring about the evolution of KDE.


Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s