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.