Category: Inside KDE

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!