KDE sets its goals through 2026

Almost a decade ago KDE e.V., the non-profit organization that supports KDE, started a process for selecting goals to help the community unite behind a common vision for where the project should go in the near future. KDE recently wrapped up its 2022-2024 cycle and announced the goals for 2024-2026 at Akademy on September 7, in Würzburg, Germany. This time around, KDE will be looking to streamline its application-development experience, improve support for input devices, and bring in new contributors.

Evolving KDE

The goal-setting practice got its start in 2015 when Lydia Pintscher, then president of KDE e.V., blogged about a plan for a yearly process of gathering community input, defining goals, planning ways to achieve them, and measuring success. She said that setting goals for the project was important to help KDE "get a better understanding of where we are, where we want to go and how we want to get there".

In 2017, Pintscher announced a formal process for setting goals and providing sponsorship from KDE e.V. in the form of support for sprints, presentation slots at Akademy, and more. Goals could be about "anything you consider important – it doesn't have to be about writing code".

Setting goals

Contributors have about a month from the announcement of a cycle to come up with proposals. The proposals are then posted on KDE's Phabricator instance. (The Phabricator project was a code-collaboration project that was open-sourced by Facebook that is now defunct. KDE is phasing it out in favor of GitLab.) The format is somewhat free-form, but it follows a rough template. It includes a detailed description of the goal (or a problem that the goal will solve), a high-level plan, what's needed to accomplish the goal, the champion or champions for the goal (if any), and a list of contributors willing to work toward the goal. All of that information is important for the next step, the discussion cycle.

During that phase, proposals are batted about and refined based on community input. The community is encouraged to submit proposals even if the proposal does not have a champion yet, with the idea that champions may be found during the discussion period.

The list is then winnowed down to the proposals that are eligible for voting. A proposal might not be deemed eligible for voting if it lacks a champion, is too narrowly focused to be a goal, or provides too little information to be considered. For the current cycle, more than 40 proposals were submitted, with only ten declared ready for voting.

Voting on the proposals is open to KDE contributors with more than 10 "actions" on Invent, KDE's GitLab instance. This year, voting took place from August 15 through August 31. Finally, the top three are announced at Akademy (and via KDE's mailing list and blog). Then the work begins.

For the 2018-2020 cycle, the project chose streamlining onboarding of new contributors, improving user privacy, and improving the usability and productivity of KDE. The 2020-2022 cycle focused on consistency, applications, and finalizing the transition to Wayland. The goal set for the most recently completed cycle, 2022-2024, focused on accessibility, sustainable software, and automating and systematizing KDE processes to improve the project's institutional memory.

We are the champions

In prior cycles, each goal had an individual champion who was responsible for the goal from proposal to completion. This time around, Pintscher wrote, goals will be driven by a team of champions instead of an individual champion. She suggested that one person should focus on the goal's vision, another person would work on steering the technical implementation, and a third person would work on promotion. That team structure was merely a suggestion; the team could delegate responsibility in whatever way made sense, so long as there was a team. The plan was to put less pressure on the champions doing the work themselves and more emphasis on them "driving the goal forward through others". It makes sense to expand the number of people responsible for championing major initiatives, rather than putting all the responsibility on one person. As with most community open-source projects, KDE is not overburdened with contributors, and it's important to help them avoid burnout. KDE e.V. would work with champions to help with fundraising for projects to support the goals.

The winning goals were unveiled at a session at Akademy by Pintscher (video here), and later sent to the kde-community mailing list by Farid Abdelnour. The first winner is "strealined application development experience", championed by Graham and Nicolas Fella. The second is "we care about your input", championed by Gernot Schiller, Jakob Petsovits, and Joshua Goins. Finally, the third winning goal is "KDE needs you!", which has three champions; Aniqa Khokhar, Johnny Jazeix, and Paul Brown.

Streamlined application-development experience

The streamlining proposal is a good example of how goals are refined over the discussion period. The original text for the goal sparked a lengthy discussion, with Julius Enriquez pointing out that some of its suggestions overlapped with a KDE apps initiative by Carl Schwan. Fella suggested rewriting the proposal around making sure "our application development story is as good as possible", whether they are first-party applications from the KDE project itself or third-party applications targeting KDE.

Ultimately, Fella's rewritten version of the goal was adopted, leading him and Graham to sign on as champions. The final proposal says that previous goals have helped to improve application delivery and design, and to improve the consistency of the Plasma desktop—but KDE has fallen short of improving the application-development story:

There are many cases where our application design is inconsistent, either because no unified idea has been established or older applications have not been updated to new design ideas. The introduction of convergent design as a goal introduced new complexity to this. We tried many ideas and approaches, but often didn't converge (pun intended) on a common design.

To that end, the plan is to improve KDE's human interface guidelines (HIG) and design documentation for applications. Some of that work had begun before the goal was proposed: Graham announced a rewrite of the guidelines in June 2024. The goal goes much farther than that, though; it sets its sights on improving developer documentation, establishing "a culture of continuous review and improvement", and making it possible to build KDE applications with languages other than C++, such as Rust or Python.

We care about your input

KDE has decent support for basic input devices, such as mice, touchpads, and (of course) keyboards. However, users need support for a much wider array of devices or input types, including drawing tablets, touchscreens, speech-to-text input, and more. Those devices are often under-supported on Linux since the manufacturers usually do not do the work of providing software for platforms other than Windows and sometimes macOS. Users tend not to care about where the fault lies, however, only that their devices work as expected with all the bells and whistles. In addition, the proposal acknowledges that KDE still needs to close the gap between Wayland and X11 support.

The plan is to start by gathering information about missing features, bugs, wishlist items, and GitLab issues to compile a wiki page that tracks work to be done. The Wayland showstopper page that was used for the Wayland goal in the 2020-2022 cycle is given as an example of this. The next steps will be to perform research on input topics and blog about the findings "to educate users and developers, spur discussions, and inspire contributions from the wider community". The team also plans to reach out to users with "special hardware" who can help test patches, and to coordinate developers interested in working on improving input-device support in KDE.

Some of the ideas that are already on the table include disabling a touchpad when a mouse is plugged in, allowing customization of three-finger and four-finger touchpad gestures, and making it easy to re-bind keyboard keys globally. For example, letting users remap the Copilot key that is included on PCs shipping with Windows 11 to something useful.

Even more ambitious, the plan includes an number of ideas around input-method editor (IME) support in KDE. Generally, IME is the use of software to allow users to input text through methods other than a traditional keyboard. This covers input methods such as speech-to-text, language translation, and handwriting digitization when writing with a stylus on a touchscreen laptop.

Plasma is included as the default desktop of SteamOS, a Linux distribution that is designed for portable gaming PCs such as the Steam Deck. SteamOS can be used on other devices, however, and KDE may not have support for third-party game controllers that users choose for those devices. The proposal notes that navigating the desktop and applications on SteamOS without the Steam Deck's trackpads "is not currently a pleasant experience". Therefore, the team has set a target of making game controllers a primary input device for KDE. This would entail making it possible to navigate the desktop using only "arrow keys, a Back button, an A (enter/select) button and a menu button".

And, of course, an input goal would not be complete without addressing accessibility. The proposal notes that some of the input focus areas "are directly relevant to accessibility concerns". It notes Matt Campbell's work on the Newton accessibility architecture for Wayland as work that "KDE needs to stay on top of" to ensure that screen readers work well with KDE software "regardless of whether users access it via mouse, keyboard, touchscreen, tablet or game controller".

What does success look like for this goal? The proposal says that success is when "we're happy enough with the input stack to move on to other undertakings instead". Some of the specific indicators of success include: at least one new IME input method, a virtual keyboard that can fully replace a physical keyboard for users with a touchscreen or mouse input only, and new reports of "missing or unintuitive functionality become exceedingly rare" for mice and keyboards.

KDE needs you

Finally, the "KDE needs you!" goal focuses on formalizing and improving KDE's processes for recruiting active contributors, with an emphasis on "active". The proposal explains that many of KDE's projects are maintained by only one or two people, leaving aside "flyby contributions (which cannot be relied upon for continuous and stable development)". Even a core project like Plasma, it says, only has between eight and ten contributors; attracting new contributors is a matter of survival for KDE.

KDE already has a mentorship team that is meant to help new contributors learn how to productively contribute to KDE. The proposal recommends expanding that team's charter, increasing its resources, and turning it into a recruitment team, "since the main purpose of the mentorship programmes is recruitment anyway". The proposal aims to recruit more aggressively over social media, through direct contacts, and more. It also recommends adding a paid contractor to manage the recruitment team if necessary and resources allow.

The proposal identifies academic institutions and companies as potential sources for new contributors. It suggests trying to persuade educational institutions to direct students to do internships or final projects with KDE. Companies might want to be involved, it says, to help train their employees on working with open source.

In addition to the recruitment team mentoring new contributors, the proposal suggests that KDE's "harried developers" should "slow down development and spend time making it easier to bring new contributors into the fold":

It's often argued that developers don't have the time to mentor and train new contributors, but why not? There are no quarterly targets to meet, no board of directors demanding more and more output. Development could slow down by 1/4 for, say, two years and KDE would not be affected in any significant way. So instead of 100 changes listed in the changelog, there are now 75, so what? This is not a big deal folks.

The slowdown would be temporary, according to the proposal, as more contributors are trained and become productive. Success will be easy to identify by counting heads. The target for the goal is to increase the number of regular contributors to some of KDE's core projects by 50% in the next two years.

Cumulative culture

One might wonder about the results of the program so far, and whether the effort of goal-setting has panned out for the project. Looking at prior cycles, the practice does seem to be working for the KDE community. The onboarding project, for example, delivered a number of improvements to KDE's Bugzilla during the cycle to help new contributors file better bugs, and helped fill out KDE's developer documentation.

The Wayland goal didn't quite succeed in hitting its target of letting KDE use Wayland by default by the end of the cycle: but it laid the groundwork for KDE to make the switch in 2023, ahead of the KDE Plasma 6 release in 2024. That is in keeping with KDE's philosophy of cumulative culture: every cycle "represents a new layer of accumulated wisdom, i.e. new features and more stability". As long as the process continues to improve KDE in the long run, goals don't have to hit 100 percent (though that would be nice), they just have to drive KDE forward.