Tech Over Tea - The Era Of KDE Plasma 6 Is Here | Nate Graham

Episode Date: May 3, 2024

Today we have Nate Graham back on the show again, this time to talk about of course KDE Plasma 6, my experience with it and everything else surrounding the launch of the desktop. ==========Support The Channel========== ► Patreon: https://www.patreon.com/brodierobertson ► Paypal: https://www.paypal.me/BrodieRobertsonVideo ► Amazon USA: https://amzn.to/3d5gykF ► Other Methods: https://cointr.ee/brodierobertson ==========Guest Links========== KDE Website: https://kde.org/ KDE Fundraiser: https://kde.org/fundraisers/ Blog: https://pointieststick.com/ KDE Twitter: https://twitter.com/kdecommunity/ ==========Support The Show========== ► Patreon: https://www.patreon.com/brodierobertson ► Paypal: https://www.paypal.me/BrodieRobertsonVideo ► Amazon USA: https://amzn.to/3d5gykF ► Other Methods: https://cointr.ee/brodierobertson =========Video Platforms========== 🎥 YouTube: https://www.youtube.com/channel/UCBq5p-xOla8xhnrbhu8AIAg =========Audio Release========= 🎵 RSS: https://anchor.fm/s/149fd51c/podcast/rss 🎵 Apple Podcast:https://podcasts.apple.com/us/podcast/tech-over-tea/id1501727953 🎵 Spotify: https://open.spotify.com/show/3IfFpfzlLo7OPsEnl4gbdM 🎵 Google Podcast: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy8xNDlmZDUxYy9wb2RjYXN0L3Jzcw== 🎵 Anchor: https://anchor.fm/tech-over-tea ==========Social Media========== 🎤 Discord:https://discord.gg/PkMRVn9 🐦 Twitter: https://twitter.com/TechOverTeaShow 📷 Instagram: https://www.instagram.com/techovertea/ 🌐 Mastodon:https://mastodon.social/web/accounts/1093345 ==========Credits========== 🎨 Channel Art: All my art has was created by Supercozman https://twitter.com/Supercozman https://www.instagram.com/supercozman_draws/ DISCLOSURE: Wherever possible I use referral links, which means if you click one of the links in this video or description and make a purchase we may receive a small commission or other compensation.

One. Good morning, good day, and good evening. I'm as always your host, Brody Robertson. And today we have a returning guest. You may not have seen his face before. I don't know. You've probably seen the blog that he runs. Welcome to the show, Nate Graham.

How's it going? Hi, nice to see you again. Great to be here. Thanks for inviting me. Absolute pleasure. Just for anyone who isn't aware of who you are, just give a brief introduction. My name is Nate Graham. I work on a whole bunch of KDE things. I am a volunteer developer and QA person. I'm on the board of directors of the KDE EV Foundation, which sees to administrative

things regarding KDE. I work for Blue Systems, which is a consultancy in KDE's orbit, where I am fortunate enough to be paid to work on KDE stuff full time, which is pretty cool. And as a result, KDE is a very significant fraction of my life. And so I appear in many places as a result. And of course, you have the blog as well, which is also important for a lot of people. Yeah. So I do this weekly blog, which started out as a sort of weekly progress report for the usability and productivity initiative, which I championed several years ago. And then after that initiative finished,

it seemed pretty popular. And so I just kind of kept going with it. Yeah, it is a, I don't know how to link open for a really old post. I had the one from like May last year. I check in every so often just to see what's going on in KDE land. Like even when I wasn't using the project myself, it's always nice to see like, oh, hey, HDR is being worked on or modifier only shortcuts or all of these like little neat things, which obviously all of this stuff is publicly available in the project. And you can see it if you're like digging through the hundred different repos that are involved in the project. in the project, but easily putting that together, I think has like a lot of value for people,

because it's hard to see from the outside, like what's actually happening in the project, obviously, like the really big changes, like the explicit sync stuff being worked on, I don't know, like Plasma 6 self-launching, all of that stuff, you know, makes its way out, and there'll be people that talk about it regardless. But a lot of the little things where it's like, we made a slight change to the label for opening up the widget edit menu, things like that, most people just are not going to see until maybe they come across it. But especially when it comes to the more underlying things like bug fixes, like performance improvements, that sort of stuff is hard to really notice without someone really just directly pointing out to you. Yeah.

And I see that kind of as the role of the blog, because as you pointed out, there's a lot of stuff going on. KDE is quite vast in scope and even people who are involved in the project are often not subscribed to more than a small fraction of what's going on. And so the role of this blog is kind of internal as much as it is external, right? Because people who maybe don't follow Plasma so closely can get a sense of what's going on with the project by reading. As time, the blog has kind of become a little bit more Plasma-centric. I do still talk about apps, but by far the vast majority of things that I report on right now are either directly about Plasma or about frameworks

in a way that kind of connects to Plasma in some way. So yeah, but I think it has value because Plasma is a big project and people want to know what's going on and so I try to make it easy and accessible so people can find that information. Yeah, it's... Big project is certainly one way to describe it. I think if anyone looks at like Bugzilla for example, and I do want to talk about the Bugzilla a bit later, but if anyone just looks at the Bugzilla and then looks at all the different categories, it is very clear the project is very, very big. Now, there's some improvements that could be done to the Bugzilla to maybe make it easier to search. I know there have been improvements over the years, but listing out each individual thing, it becomes very clear that there's a lot of things that go into this machine. Yeah. This is one of the topics that comes up a lot is how difficult it is to find anything on Bozilla. And people often say you should switch to GitLab issues

instead. But the problem with GitLab issues is that it is exactly no better in this way because GitLab issues ties issues to project repos on a one-to-one basis. And we have, you know, 500 project repos. So if you have trouble finding something on a giant flat list in Bugzilla that you can at least control F to search on the page, you're going to have an even bigger problem finding things among 500 Git repos that are namespaced across various different things. But talking about how KDE is big is kind of an important topic, I think, because KDE is so big that it kind of gives us big project problems, right?

Like when you have a small project, a lot of things are easy or at least doable. And once you have a big project, you start to run into these issues of internal coordination, how to find anything, preserving institutional memory, making sure people know who's doing what, making sure small projects within the umbrella project don't get forgotten or abandoned. It's really pretty, pretty huge. And one of the things that I think you can see in this is how KDE software is becoming used more widely across the industry. There's the

obvious thing that we can all think of, which is the Steam Deck, of course, which is a phenomenal success. But there are other things too, like the German company Tuxedo Computers, which is a whole company. And I've visited their headquarters. They have a whole floor and an office building. They have lots of people. Their whole company sells devices that run plasma. So, you know, we're important to them too. And there's a whole bunch of other people who are using KDE software in institutional

contexts for making money, for doing real work. And so as big as KDE is, it's equally important in world affairs. If KDE vanished tomorrow, there are a lot of people out there who would be scrambling for what to replace that software with. And I think it's a good problem to have, but it is a problem in some ways because KDE is still very much a volunteer directed project, even though there are a lot of people who are sponsored to work on it. It's still mostly volunteers. And so we're kind of in a transitional phase right now where the project started as a fairly loose-knit thing that was made by individual people. And now our work is being consumed by hundreds of thousands, millions of people out there who maybe don't have that much familiarity with open source,

right? And who come at the project with a product mindset where they say, well, this isn't working. What's wrong with you? Why didn't that work properly? And on one hand, we they say, well, this isn't working. What's wrong with you? Why didn't that work properly? And on one hand, we can say, well, just look at the warranty, right? You know, every file in the Git repo says there's no warranty implied or otherwise. Provided as is. Well, whatever. Provided as is, right?

And technically and legally, that is true. But it's also not what people are expecting. And I think we do sort of a bad job of setting expectations there, right? When you go to a Linux distro's website and you download it, it's going to give you the fancy glossy marketing copy. And it's going to tell you about how great the distro is and this and that. You're not going to see a giant red disclaimer that says, by the way, there's no warranty. You know, if you're not paying for this, there's no expectation of what you should receive in return. And so be prepared for things to break terribly.

People like you and I, we know that. We know that implicitly. And when our friends and relatives tell us, I'm really tired of Windows or Mac OS, I think I want to move to Linux. We're going to give them that little speech. Right. Yeah. But a lot of regular people out there are not having this information communicated to them. And so so then the problem becomes, do we want to communicate this information to them so that we're setting expectations? Or do we want to try to make it irrelevant

so that they don't get frustrated by issues in the first place, right? A little bit of both, you know, you want to set expectations, but you also don't want to pull a bait and switch where you're saying, oh, this project is so great, you should use it, it's so much better than the competition. Then when people run into problems, you say, well, not my problem, you know, whatever, it's all volunteers. Yeah, I was speaking to Christian Scheller, I think that's what his name is, from Red Hat. And he was saying the other day that

he doesn't like that a lot of the time when we have issues on the Linux desktop, the solution is either... I don't think he said this, but he said... He did definitely bring up, usually, it's try a different desktop, or use a different project, a lot of the, a lot of other times, it's, well, you can commit code upstream, you can fix the problem yourself, and both these are great if we're talking purely the developer mindset, the developer community. And in the very early days of Linux, when that was the people using Linux, and that was the people using open source, that made a lot of

sense. When we're talking back in like 1999, for example, nobody is using Debian unless they're a developer or have a developer adjacent position like you weren't having regular normal people who were just like working a nine to five they're a plumber running debian back then but right now it's a very different position especially with people who are you know in still they're replacing the windows 7 on their parents computer with something that's actually supported yep it's a very tough problem and obviously the really big projects like kd like gnome like uh i don't know this actually is not that i mean the linux cam um there's really few projects that fit this camp that can afford to really do some sort of like proper product like support but when you start doing that then you

you possibly start setting expectations for things outside of just the desktop and that's that's where it gets really difficult right because you can set expectations for what is going to come from plasma but if somebody installs a application as a flat pack, for example, and it's just some random application, one dude maintains it, you can't have that same level of expectation, but especially in the case of a product, like you're buying a computer, if maybe something

is pre-installed, that's going to have that same sort of expectation placed on it as well, and I don't know how you address this problem. It's very challenging for sure. I think the only way that you can actually address this is with vertical integration, which is very much beyond our capacity to do right now. But you're absolutely right that it's a problem because a normal person is accustomed to

a product being self-contained right and computers violate this expectation a little bit because when you get a computer you get it from your local retailer and you would power it up let's say it's a windows computer right uh you know that the company that made the computer is probably not microsoft although maybe it is but it has the company's name and logo on it and then you boot it up and it's got windows and you know that Windows comes from Microsoft. And then it comes with a whole bunch of other random software on it. And people like you and I often forget, but in the Windows world, a lot of random software is prominently branded with the company name on it so that people know who it came from, because otherwise this is not very obvious. But even then

people have trouble, right? People have trouble distinguishing third-party apps versus first-party apps. And even in the Windows world, right, there are people who are going to not understand the difference between an Asus and a Microsoft. The fact that even then that this is a product that is composed of components from multiple vendors is a little challenging. In the Mac world, that's not the case, right? Because Apple makes the hardware and Apple makes the software and Apple doesn't bundle any third-party software on their machines, I think. So it's a clearer, simpler story there. And I think as a result, there's sort of an easier user experience. And that's the thing that we have to shoot for if you ask me i think it's a good example right now uh and maybe at some

point in the future we will be but i think this is why you see kde has a distro kde neon and much hay has been made of kde neon and uh you, after the release of Plasma 6, there were some problems and we've been discussing internally how to fix those. But I think it's a good thing that we have our own distribution channel somehow. And whether we can improve that over time is something that we're going to be looking at. But it's good because it means that we can't pass the buck as much, right? When you have a problem with the packaging on, let's say, Ubuntu or Fedora, we can say, well, it's an upstream issue. Talk to them.

Right, right. But if you have a packaging problem on Neon, we can say, oops, we messed up. We can fix it. And that is a more satisfying response to hear if you are in the role of a customer and you feel like you're having a problem and you're seeking a solution i think a good example of people being confused about like what in the stack is like owned by who um i don't know if people say this around where you are but i often hear people compare samsung versus iphone like they don't even know that android exists

it's just samsung or i don't know if that's still like the big brand right they don't even know that Android exists. It's just Samsung or... I don't know if that's still, like, the big brand right now. I don't care about, like, smartphones. But, like, a couple of years back, that's the way people describe it. Because this whole concept of there being a separate operating system and there being these separate applications, it's just not the

way that most... Like, maybe they'll think of something like, I don't know, some game they installed as, like, a separate thing that's from a different company but the idea that samsung doesn't make the thing that runs their phone like that's just not even something that goes into their heads yeah and this makes sense too right because who are you buying your phone from you're buying it from samsung and let's say you buy your phone from sam and you have a problem with it. And that problem happens to be in a layer of the stack provided by Google in the form of Android. And you go to Samsung for support. You're expecting Samsung to support you. If somebody in Samsung

says, well, we just ship Google software. So you'll have to talk to Google. Like that's not going to fly. Right? And this is the expectation that we do have in our community. You file a bug report on KDE, if it happens to be an issue in a third-party library, we're going to pawn you off on that library. We're not going to take responsibility for it. And that's because we can't. But if you're an integrator, if you're a distro or you're a hardware vendor, you can take responsibility for it. And so I think in a lot of ways, in an ideal scenario, most of the bug reports that come to KDE would not actually be filed by users. They would be filed by distro maintainers.

They would be filed by QA people working for hardware vendors because they would be the people who get the issues reported to them first. Because as the integrators, as the ones who sell the products, they're the ones who are ultimately in the best position to figure out what exactly the issue it is and what can be done about it. Because after all, money has changed hands, right? Let's say you buy a computer from tuxedo right i brought them up earlier um you spend your you know thousand euros on a nice computer and you find that it doesn't work in a particular way well if you contact the tuxedo people then they're going to have like a warranty system they're going to have a customer service department who can talk to you they're going to have people who can figure it They're going to have a customer service department who

can talk to you. They're going to have people who can figure it out, who are at least ostensibly being paid by the money that's changed hands. Whereas if you buy a laptop from, let's say, Lenovo, and then you wipe windows and you put KDE, let's say, I don't know, Fedora 39 KDE on it. Well, no money has changed hands there, right? So when you go and you talk to KDE, implicitly, everything that you're asking for is free support. And even among the Fedora people who are happy that you're using their distro, if you ask for support from them, it's going again, be free support, right? None of this is paid support. And so whatever you get from that is kind of on a best effort basis. So I think when people come at

issues that they're experiencing from the perspective of a customer, it really needs to be that they're talking to somebody who they've given money to, because then there is an explicit expectation of support for money, right? The model wouldn't work nowadays, I don't think, but imagine that Ubuntu never happened and Ubuntu never just demolished the whole concept of a regular user commercial distro. Because if you go back to the early 2000s,

just before Ubuntu, that's what you go back to the early 2000s, just before Ubuntu, that's what existed. There were a couple of them, and that was just a normal thing. You would buy a CD, and that's how you would get it. There were obviously things like Debian, yeah, sure, and there was Slackware, but there were also these forming commercial distros as well. Assuming that model was possible today, do you think that would potentially solve some of

the issue or do you think it's sort of... Yes, I do. I do. I do absolutely think that it would solve some of the issues because with the revenue stream that these companies could achieve by selling their work, they could pay people to offer support. They could pay people to do QA. They could pay people to do bug triage. They could pay people to talk to upstream. And then the bug reports that we got in KDE would all be 100% good actionable bug reports because they would be submitted by technical engineers who knew what they were talking about, right? You know, in other words, there would be a filter right between users and us. I know I'm sounding a little bit down on bug reports right now, because I've been beating this drum for many years of please report bugs, tell us what the problems are. And I think, if anything, we've

maybe been a victim of our own success here, because we get a lot of bug reports. And some of these are really good. And they tell us when there are problems. But we have an absolutely enormous number of bug reports that frankly are not very good. KDE crashed. How do I fix it? Exactly. Yeah. And then you have to, that takes so much time to sort out whose fault, if any, you know, is involved there. We get tons and tons of those. And it takes a lot of time to sort through. And all of this time, these are resources being spent. Everybody who works on this is not somebody who's working on actually fixing those bugs or writing new features or any activities like that, because resources are extremely limited in not only this world, but in all worlds relating to open source.

I think it's very tempting for people to imagine that there's like a big company behind a project, that there are vast unlimited resources. But the truth is, even in a large open source community like KDE, if you look at any individual product that KDE makes, big ones that you've heard of like Plasma or Credo or Ocular or Console, right? There's going to be maybe five people max doing 80% of the work in these projects. Like all of them, I guarantee it's something like that.

And some fewer than five, might be two or even three people. So the resources available are extremely limited. And what people manage to get done with these resources is, in my opinion, nothing short of miraculous. It's not sustainable. As I think we saw with the XZ hack recently, is that relying on volunteers who are always a week away from burnout to provide amazing service to the world for free this is amazing but it is not a sustainable model right and it turns out it may not even be a safe model this whole thing is like not everything is well supported this isn't just a kde thing as a

good example um in the gnome project the gnome calendar is maintained by one person yeah like a very important part of gnome that people expect that would you know be well supported but pretty much it's only developed by george's devra because they'll be like passing commits from other people yeah most projects will have a couple of commits here and there from random people and it will look like oh this is actually one of the things i don't like about how github does i don't know if gitlab does gitlab show the number of contributors yes gitlab has a really great contributor graph the graph is useful yes but i mean just like a raw number uh i don't know if it has a raw number because on github contributors by number of contributions right so it's very obvious if the repo is 99% maintained by one person.

But on GitHub, there is like, until you go to the graph, there is just the number and then the list of people. So it can look like most projects it'll look like, oh, there's like 20 contributors. But if you look at the actual graph itself, it's like, okay, there's a thousand commits from one person five commits from the next person and then go down from there basically very common extremely common and you see this pattern everywhere i think if you dig into almost any project it's going to be something like that and it's just not sustainable frankly in some cases that one person is going to be somebody who's who's paid and that's a little

bit more sustainable but in a lot of cases it's not and even when there is one person who's paid there's some fragility there an example i can think of is lib input which is maintained by the indomitable peter hutterer who's been around forever and he is paid by red hat to single-handedly develop and maintain lib input. And for years, he has been asking for people to help him out. And who's going to do that if there's no money, right? So it's just him. What happens when he retires? What happens when he gets reassigned to another team within Red Hat? What happens when there's a reorg? You know, what happens when he decides, okay, I've worked on lib input enough of my life. I want to move on. I mean, we're all screwed because that's

the proverbial one library in Minnesota, one person in Minnesota who maintains the library, right? So I think we all kind of need to be thinking about this problem of key components that are maintained paid or not by an extremely small number of people we've all gotten used to getting everything for free but the downside of free is free is unstable frankly yeah there is this issue that people have already heard before but this is a great example of it the the uh bus factor or the whatever term you want to use for it, where if this one person dies or they retire or whatever, however bad you want it

to sound, if this one person leaves, they take a lot of this legacy knowledge, a lot of core knowledge of how the codebase works. For a small project, that's not that big of a deal. If a code how the code base works and for a small project that's not that big of a deal like if a code base is a thousand two thousand lines long you can get

your head around it pretty quickly but when you're talking about like ten thousand twenty thousand thirty thousand even more lines of code you can get back up to speed but that project is going to take a long long time to do so, and finding someone who wants to spend, I don't know, a month, maybe even more, trying to understand a code base before they can even make a single meaningful commit, that's like, that's a massive, massive endeavour. Like, a good example of this is the Yuzu emulator. After they got taken down by Nintendo, there have been like all these splits off into these other projects to try and take it over,

but it's a massive code base and emulation is a difficult problem, so trying to find people who can not only understand the code but meaningfully change the code? That's gonna take a long time if ever possible. Oh, your audio's gone. Whoops, I had myself muted and I wanted to unmute. I'm always doing this. I'm not very bright. Anyway, I was going to say you're absolutely right, and when you look at a very large project like Plasma or Krita, these are projects that have millions of lines of code. And there's a tremendous amount of institutional knowledge

in people. And this maybe is a good segue to the KDE goal that I'm championing right now, which is called automation and systematization. And the goal of this goal... Do you have a link I can go to? If you go to kde.org slash goals, you will see it there.

This is a goal that was chosen by the community in the last round of voting. And the idea here basically was to externalize people's knowledge and put it into the Git repo, into the documentation system, so that the project would become more resilient to any individual person leaving.

Because it does happen, right? If you look at Plasma in particular, we have lost a number of senior engineers over the last couple of years, and they've been replaced by other junior engineers, some of whom have later graduated to become new senior engineers. But that process inevitably involves the loss of knowledge. It happens every time somebody leaves. And so the goal here is to get that knowledge into the form of automated tests, into the form of readme's and tutorials and internally facing developer documentation so that it's not so hard for people to get up to speed again so that those things that everybody knows how to do are actually

documented properly and I think that'll that'll really help when it comes to things like actually getting people to join the project as well because it's not just for the people that are in it right now when people say things like oh just

submit a patch for it like that's that's not an easy the people that are in it right now. When people say things like, oh, just submit a patch for it. Like that's not an easy thing to do. Like, yeah, if someone's demanding work, it's a fun way to tell them to basically piss off. But I mean, there's a bit of privilege involved in that, right? When you say patches, patches welcome. What you're basically saying is you can't contribute unless you're at a sufficiently high technical level that you know more about computers and this project than 99.999% of all humanity.

And maybe you do. Maybe that matches you. But if that doesn't, or more importantly, if you don't feel like that describes you, you're going to feel like that's an exclusionary statement, even if it wasn't intended as such. Right. No, I get that. Yeah, no, that definitely makes sense. And so there's this kind of this meta challenge here, which is that people want to help.

People want to help in open source, but being able to meaningfully help in open source, let's call a spade a spade. It does often require that you are a highly competent programmer. And if you're not a highly competent programmer, there are more limited ways that you can help. But that's not to say that those ways don't exist. The most obvious one is donating with your money

because then you can essentially, in the aggregate, pay other people to help. There's another drum that I like to beat, which is bug triage. Yeah, I was going to mention that. Yeah. I feel like bug triage is the perfect entry point for somebody who is passionate about a project and has a certain amount of technical knowledge, but not necessarily programming knowledge.

Because all you have to do to triage bugs is be reasonably familiar with the system whose bugs you're triaging. Because then somebody will submit a report and you will already in your head have some knowledge about, oh, I thought I saw that issue last Sunday, or wait a minute, that issue that this person is talking about doesn't seem like it's actually possible to happen.

Let me see what's going on. Or, oh, that issue this person is talking about is clearly affecting a different project because they're confused and they don't understand the structure of this community the way I do. So I feel like bug triage is a super empowering way for people to get started.

If you just look at something like the bugs opened in the last 24 hours, there is a ton of, it's just, it's showing 50 bugs. I don't know if that's like the the bugs opened in the last 24 hours there is a ton of it's just it's showing 50 bugs i don't know if that's like the limit it shows in the past 24 hours or how this system works that's about accurate okay okay um yeah and that's every day obviously it's more when there's you know around the launch obviously uh or i don't know if you guys ship a giant regression or something like that but that takes a lot of time to get through and tell me about it yeah it sure does yeah and it's also it's not necessary necessarily that all of them are new things they might be existing bugs

that maybe this is a new condition it happens in, or maybe it's someone... This is a big problem that I don't know how bug reporting systems can deal with. How you properly link together duplicates. Because the way that Bugzilla does it, from my understanding, is when you type in a title, it'll show you similar sounding

titles, but there's a lot of people who just don't know how to write titles. So, you might have written a good title, So you might have written a good title or they might've written a good title and yours is terrible. And it's just not showing up in that list. So you think it's a completely unique bug. And I know a lot of projects will say like search for bugs before you report. And yeah, that makes sense. You're not going to do that. Nobody does that.

On a small project. It's easy, right? Like if it's like a single repo and there's easy, right? Like, if it's, like, a single repo, and there's, like, one set of issues, maybe there's, like, 30 issues. Like, you can easily go through that. It's going to take a bit of time, but you can go through that. But when we're talking KDE, and there are bugs that get reported on the wrong list,

or they get... Maybe they are... There's some... Issues, for example, where maybe it's something where it could affect multiple pieces down the stack, where it might be a Plasma issue, or it might be one of the officially supported add-ons, or it might be an application.

It's like, you're not really sure where it is, so you might have all of these different reports across these different things with very, very different sounding descriptions, or they might be, be again they might be bugs where the conditions that's occurring in are different but it's the same underlying problem like uh for example the wire plumber issue i had when i reported that one to you guys and to that one to why yeah i did see the reply on that um because i yeah i didn't know where the where it was breaking because

it said k win wrapper or whatever in the the pipe wire logs like could it be your portal it was only happening when the kd portal was open so maybe turns out it was actually wire plumber doing something they haven't actually fixed it yet but there was another bug with a completely different set of situations for it to occur but it's the same underlying problem when they saw the stack trace of it, and I had no idea that bug existed. I had no way of knowing that because it didn't even sound like the same bug.

But, yeah, it's a very tough problem. Someone's going to suggest AI or something to fix this problem, but I don't know how you feel. So I'm not the biggest fan of AI, but it's something that I have thought about a lot myself is that we could, I think, actually benefit

from a basic automatic bug triaging AI because an AI is never going to be able to actually troubleshoot issues and identify root causes but what an ai can do is it can help make really bad unactionable bugs actionable or else filtered out so developers don't see them so when somebody does submit a bug report like what you said earlier where it says kde crashes fix it you know a human shouldn't need to look at that. An AI or even a less smart, just a bot of some sort, some kind of pattern matching keyword bot could say, hello, it looks like this bug report is crap. Could you please do a better job, but with more gentle language, of course.

Sure. And that's something that is on my long-term wish list for Bugzilla is that the bug reports that are not very good get hidden from developers whose time is more valuable than to look at those. But I am a defender of Bugzilla in many cases. I'm going to acknowledge that it's not perfect, but I think it's pretty pretty good when it comes to searching for duplicates this is a place where i will not defend it because it is not amazing here i think the the way that that searching works is very unintuitive precisely because closed bugs are filtered out by default so if there's an issue like the classic situation is you're using an old version of Debian and you encounter a bug and you want to do your part and look for duplicates. Well, you're not going to find it because the report for this is already closed because it was fixed months or years ago.

So you're going to file a new one and then somebody, me or Nicolas Fela or somebody else will need to go manually market as a duplicate of that one and and that's that's a pain in the butt definitely a pain in the butt i am going to pre-warn you about this because i i when i talked to david he didn't know this was happening um kubuntu 24.04 is going to be shipping 5.27. So there's going to be users who are reporting 5.27 bugs as Plasma 6 bugs, and they won't know the difference. So I had some discussions with the Kubuntu people about

this, and I told them this. I said, you are going to be shipping a version of your distro that has software that's already out of maintenance. And then it's 3-year OTS, I believe the flavors do. Yeah.

Yeah. And, you know, if you're using the KDE version, maybe you're more of an enthusiast and you might want to upgrade, but still, it's going to be years. There's going to be frustration. The thing is, this is nothing new as well. We deal with this every cycle with Debian because Debian has a roughly two, sometimes two plus year release cycle.

So by the end of that cycle, we are regularly receiving bug reports that were fixed two years ago. Right. By Debian users. And it's gotten to the point where I have a little snippet of text in my canned answers git repo that I use for bug triaging where I just copy and paste in there and I say, hello, you're a Debian user, please submit bug reports to Debian first because they are responsible for providing support for out of support versions and this isn't because i'm

trying to be mean to debian debian's own guidelines recommend this they recommend to their own users that users submit bug reports to debian first and not upstream so you know my butt's covered there i'm i'm not upsetting anybody yeah it goes back to the problem where it's just difficult to find where this information is and like people will hear i have to report bugs right but they won't know all of this context around it like should i report to upstream should i report to downstream depending on what i'm on well if i'm a neon user yeah i should definitely report upstream because they're the only people that are going to deal with that problem but if you're on something like Arch

should I report to the distro? should I go upstream? if you're using Kabutin 2 or actually, let's go Fedora 40 because they're going to be on Plasma 6 if you're on Fedora 40 should you report your bug to Fedora or should you report it to Plasma?

it's really hard to work this problem out and I've discussed like general guidelines but there's no clear-cut answer. It's really hard for sure and I think there are different audiences for this message too that you have to tailor your communication to because the kinds of people who actually do go to bugs.kde.org and fill in a bug report are almost by definition fairly technical people. Right. So I think it's at least in theory feasible to disseminate the message among them that you should try to put a little bit of effort into figuring out where the bug might be.

Is this an upstream issue? Is this actually a KDE issue? Is this a distro packaging issue? For regular users, there's no hope and we need to do a better job for them. Um, I, over the course of about a year and a half, I was responsible for helping to refine a particular error message in Discover that illustrates this principle. Because in general, nerds, they like to use their package manager on the command line to update, but regular people use Discover.

Sometimes nerds do too. And when regular people use Discover, every once in a while, it spits out an error because the distro has messed up their packaging somehow. It depends on the distro. Some are better than others. But we had this classic problem where people would see this error message and they would take a screenshot of it

or they would copy and paste it and they would put it into a bug report in bugs.kd.org. And the message even says something somewhat technical that indicates that it's not our fault. The message would be like, oops, overlapping files between these two packages. Contact your distributor for assistance. Yeah, that's a weird one. Things like that. And so we refined this, the presentation in Discover. And where we've ended up with is a place where the error message first says, oops, there was an issue performing the update.

error message first says, oops, there was an issue performing the update. Please try again later. Because most update issues are resolved when mirrors sync or the repos sync with each other or the network connection gets better, right? So that weeds out a ton of things. Then there's a button on the bottom that says, click here to see nerdy technical details. And then nerdy technical details is in a box. And it says, here is the message from your distributor's package manager. And it doesn't say your distributor, it says the name of the distributor. So it'll say, here's the message from Ubuntu,

right here in this little box. And then there's a button under it that says, report this bug to Ubuntu. And then you click on that button and it takes you straight to Ubuntu's bug tracker. Oh, okay. Yeah, because we know what that URL is. It's in the release data.

That is a standard cross-distribute thing. So basically what we tried to do here was make it as easy as possible to report a bug in the right place and more difficult to report a bug in the wrong place. And as a result, most people don't file bugs on this and discover anymore. I would say once a quarter, we get a bug report where somebody has literally taken a screenshot of the error message that says, please report this to Ubuntu.

My favorite is when they take a picture of their screen with a phone. Yeah. I like those. That's that's great. But you know, the message will explicitly say what they should do instead. In that case, we can close it. But we went down to, I would say, at least one bug report per week with this kind of issue to no more than three or four per year. So it is possible. It is possible to direct people to the right place, but it takes a lot of effort. It really does. And this was a

clear-cut case where the error message is unequivocally coming from the distro. And it took us a while to figure out a user interface that guided people in the right direction. So it's that times a thousand that is needed to help people to get their reports into the right place. I think one of the things Katie does that does help out with the bug reporting as well is is needed to help people to get their reports into the right place. I think one of the things KD does that does help out with the bug reporting as well is having the reporting a bug in a lot of KD applications where you can just like go to like a help menu or something and they'll just be report bug there that I think it doesn't solve every problem because obviously not everything has it and sometimes something might be breaking outside of the app and it looks like it because you've got the app open it looks

like the app itself is breaking so it's not going to solve every problem but what sort of effect actually how long has kd been doing that and as that's been introduced um what sort of effect has that had so kd has been doing that for at least 10 or 15 years. That menu item has been present in the menu structure of every single Qt Widgets-based KDE application for a very long time. We don't get those automatically in QML-based apps, but for most apps we do add it in there manually because it seems useful. I don't know if I can quantify the exact effect that has. Sure, if it's been that long, then it's hard to say, yeah. Yeah, that's the thing. And the thing is that this also contributes to the bad bug

report effect too. Because let's say... Right, makes it too easy. It makes it too easy, right? Let's say you're using an NVIDIA GPU and you experience some kind of weird tearing or graphical glitching on your app and you're like oh the app is broken i'm gonna report this well the app is broken but it's not the app's fault right and it maybe it's not even the compositor's fault maybe it's your gpu driver's fault so this is this is a very challenging thing to uh to figure out how to how to present you got a you got a noise going on on your side?

It should be gone now. Yeah, it's the perils of working from home, right? Yeah, if only the connection was working in the other room, we'd be fine. I know, I got to get that sorted out. Do you know what could be the issue there, or is it just like... I'm so bad at network things.

Yeah, I know the feeling. We were trying to record in my office earlier, but the connection kept dropping every couple of minutes. And I mean, it's a super janky setup right now where I actually have my computer plugged into an external Wi-Fi receiver so that it picks up the Wi-Fi signal from my router, which is in the house.

And this generally works. Yeah, I guess it's a little bit janky, so I need to try some other things. Ultimately, I'll probably just end up trenching from the house to the office and laying an Ethernet cable and that'll fix it. That's the easiest way to do it. I'm just lazy. I'm so lazy.

So that's why I haven't done it yet. Yeah. Instead I've just dicked around with fancy cool tech to try to get the wireless thing working, which obviously was not the right approach to take. Yeah. I tried to do wifi in my house. Um, then I gave up and now I've got an ethernet cable, uh, like hooked along the wall and just, it goes all the way to the the modem and it it works you know and then i've got a switch under my bed and that plugs into everything in here perfect imagine that imagine if you just wire everything up it just works perfectly well the wi-fi works fine within the house but it seems like going from one one building to another one is kind of the problem

imagine that it's strange so this is going to be a weird tangent, but I'm going to mention this here because probably a lot of people don't know it because I didn't know this. One source of the problem is that the window in my office contains a low E coating on the glass that blocks Wi-Fi signals, but not all low E windows have the same chemical composition of the coating. And so the coating on the window in my house does not block Wi-Fi signals, but the coating on the window in my office does block Wi-Fi signals. So right now, the antenna that I have

is literally pointed directly at a solid wall because the signal propagation is better through the wall than through the window. It's extremely strange. I didn't know. So all of this, I think, is definitely leading to the conclusion that it's just time to go Ethernet. I had no idea that was a thing.

Yeah, me neither. Yeah. It's not one of those things you would ever look into unless you suddenly have an issue with it. You're like, why? What is going on here? Yep. So, what was the launch of Plasma 6 like? How was that experience?

It was a really cool experience. It was my first major Plasma release because I was not around for the beginning of Plasma 5. To a certain extent, the launch of Plasma 6 went very similarly to the launch of any minor release where in the beginning, there's a big splash and everybody gets excited. And for about one week, you think, oh man, this is going great. We did such a good job. And then after the first week, you start to get the really weird bug reports coming in where people with very strange custom systems are having things get broken. strange custom systems are having things get broken. So given how much was changed under the hood for Plasma 6, I think we did a pretty good job. There were a number of regressions that frankly we should have caught. And there's an open discussion about how to do that better. And this gets into the issue of size and complexity, which we talked about before,

because the bigger a project is, the more difficult it is to get adequate coverage for every individual thing it can do. And this is what counterbalances the desire to add options everywhere, right? And the GNOME people are super extreme about this. They have a culture of like, no options anywhere, which in some ways is easy because that's just, that's the party line. It becomes defensible in KDE. We don't have that party line. And so we need to draw a line somewhere and it becomes very challenging to determine where it's appropriate to add an option, where it's not. One of the most obvious examples is just X11 versus Wayland session, right? When the Wayland session got made the default, by that point, most devs were already using Wayland and some of the remaining

holdouts started using Wayland to do more testing on it. And very few people were actually testing on X11 inside the KDE developer community. And we have beta testers, right? We decided for this release, we were going to do three months of beta testing instead of one, like we were really going to pull out all the stops and we got tons of bug reports. Our beta testers were amazing, but most of our beta testers didn't change the default. So they were testing on Wayland 2. testers didn't change the default. So they were testing on Wayland 2. And so once the release came out,

there were all these little X11 specific glitches that just nobody had noticed because nobody was using it anymore. And most of those got fixed pretty quickly. But it was something that shouldn't have happened. We should have had people testing it, but it's also understandable why it happened too. And I'll just say that's the peril of options and choice, right? This was why one of the things I really wanted to do in Plasma 6 was

get rid of stupid options. Not like options that people use, but like stupid options that nobody should use or that we have evidence that are only misused. My biggest example is the multiple ways to scale the system. If you wanted to make everything on your system bigger or smaller because you have a high DPI monitor or not even a high DPI monitor, maybe a moderate DPI monitor, and your hardware vendor chose a stupid DPI that makes everything slightly too big or too small. There used to be like four ways to do this. Like we had the, so we have the way that we want everybody to use, which is the standard scale slider in the display and monitor KCM, that page.

That's what we want everybody to do. But in addition to that, in the fonts page, we had a font DPI control that also did some things. Then on the icons page, we also had an icon size chooser. And that allowed you to make all the icons bigger or smaller. icons bigger or smaller. Then also back on the fonts page, we have the font size chooser and lots of elements in the user interface scaled with the font size. So there were so many different ways to make your system things on your system bigger or smaller. And we would get all these weird bug reports from people saying, oh, this is miss size. This is too big. This is too small. And then we would dig into it and we would find that they were using like three of these

settings in strange interlocking ways that couldn't possibly work. And so for Plasma 6, we got rid of several of those. We got rid of the semi-global font size chooser and we got rid of the font DPI spin box, at least on Wayland. So now on Wayland, the only supported accepted way to scale your system is using the scale slider. And once this started happening, we got bug reports from people who said, hey, the scaling system doesn't work all that well. You guys really messed up and you should fix it. But this is good because now we're getting people filing bug reports on things that

are actually bugs instead of filing bug reports on their own workarounds and saying, will you please add an option to better support my workaround? And when we're getting bug reports on the bugs, we can fix the bugs. And the scaling system has gotten a lot better as a result of it. So this is the path forward is to try to unify the experience that people have on one thing that works well instead of three things that don't work well. And this is not saying that we're going to get rid of all the options, but we want to get rid of the stupid options that are primarily being used as workarounds for our own bugs. Because we do have a standing policy of we do not support working around our own bugs. So if you file a bug report and you're like, hey,

your software doesn't work well when I use this environment variable and force these things in a strange position, we're like, sorry, don't do that. And then they'll say, well, I have to do that because there's this other bug that I'm working around. And then we'll say, file that bug report so that we can actually fix that i think this wasn't where you were going with that but i think there is something important to be said in there and this is very true with the the beta testing was done the people that were doing the beta testing those were not regular linux users they were not regular kde users even they were very hardcore kde people that have a deep understanding of the system and this is why i wanted to use plasma myself because i don't have

experience with it and a lot of people didn't like some of the things i said and that's understandable but i think a big problem with when you're a developer on a project for, I don't know, five years, ten years, or you've been using Plasma since KDE 3, when it was still called KDE. You build a lot of these, they might not necessarily be workarounds per set, like workarounds for bugs, but you've got a workflow. per set like workarounds for bugs but you've got a workflow like you have a system that you understand how plasma works and it inherently makes sense to you so any like weird ux things about it just it's invisible yeah they people were very angry when i said like when i got confused about opening up the um the widget edit or the the bar edit for example, because there was like a distinction between edit mode on the desktop and edit mode on the panel.

And people were like, no, this is really obvious. Like, no, it's actually not. If you've been using- No, that one was totally legit. And that one was kind of like a five minute fix for Marco, who's already made it much easier. Well, minus any, it had been discussed before in the past as well.

It's just no one had implemented it. Yeah, a lot of things are like that. That was totally a legit one. I think deliberately not installing a ton of critical packages just to see what breaks was a little bit more of a enough rope to hang yourself in the foot situation. The reason why I do that is, I, I, look, I'm actually, I am going to blame part of this on KDE itself. I think you're just a masochist. No, I am. Yes, true. But I don't like... So with the KDE packaging guidelines,

I don't like the fact that there are this minimal subset of packages that distros should install, but a lot of things still expect other things to be installed, even though they are optional. That's my main thing. And I've talked to a couple of people about this that well and that's that's a bug on our side but there's like a what is optional right like let's take case green for example which i recall you had issues i don't know why that's the step i know now why it's a separate package i it'd be there's a whole like legacy reasons Dave was like yeah there was like competing things it's not just legacy reasons either because let's say

you're installing plasma on a system where there's always guaranteed to be only one screen sure and you want it to be as minimal as possible like I don't know an embedded system with a raspberry pi or something like that

or a car a car that is not the Mercedes EQS that has three screens. If there's only ever going to be one screen and you want your package that gets delivered to users to be as small as possible so that OTA updates are really fast, you don't want K-Screen in there, right? So it's not a mirror to not have K-Screen. I will disagree with you you specifically because things like game controller configuration are part of just just part of plasma yeah it's valid um that's

totally valid if all of these settings are different modules understandable but like random things are not modules like case screens one of those ones or like about this system like that's in a separate module like i don't like i get it from that perspective sure in like a situation where you want something super minimal and like it the user is never going to get to the system settings anyway like that's understandable but i think being in like this weird middle state makes it confusing it's totally valid um that we do have some things that could be totally irrelevant that are bundled inside workspace or desktop. And that's another conversation because there, as you've seen, there are multiple schools of thought within KDE. One is separate everything as much as possible and do tiny little packages so you can have only what you need. And then there are other schools of thought in KDE that say,

make it easy for people to get like a good usable system without having to know the details. And KDE is a big org. There isn't necessarily a consensus on this yet. You'll see, for example, with KDE frameworks, which are like 80 packages. Back in the KDE 4 days, that was one package. It was called KDE Libs. And it was huge. And it was like 500 megabytes. And people complained. They said,

oh, KDE is so bloated. I tried to install Dolphin. And it wants to pull in this KDE Libs nonsense. That's half a gig. What's wrong with KDE? So we took that to heart. And we split everything up for Plasma 5, for the version 5. And we split it into KDE frameworks. Now, when people go and they do, you know, sudo apt-get dolphin, they say, oh, wow, it wants to pull in 40 new packages. KDE is so bloated. So you kind of can't win no matter which way you go with this. And to a certain extent, there's no getting around the fact that it's just big. Like KDE stuff is big. Plasma is big. The workspace is big. There's a lot of stuff going on here.

And so we rely on distros. We rely on distros to do a good job of packaging this. And that gets back to an earlier topic I discussed, which was vertical integration. And it's why I think it's so important for us to have a distro, not because we want it to be the only distro that people use, but because we want to showcase what we think a well-packaged KDE distro looks like. Again, not to say that everybody else is wrong, but we want to show what we think is right. Again, not to say that everybody else is wrong, but we want to show what we think is right. Because sometimes it's an understandable thing. Like another example, a thing that happened right after the launch of Plasma 6 was we heavily advertised that the desktop cube was going to be back.

And people on Arch started using the desktop cube and it didn't work. And it didn't work because of an Arch packaging decision to make a key dependency optional rather than mandatory. When I talked to David about this, he was saying it's because KDE add-ons is a... It shouldn't be one thing. It really shouldn't be. There are so many different things. I discussed this with a prominent art packager and his opinion wasn't invalid because it is a giant, stupid grab bag repo with a lot of random stuff in it. And because of that, it does pull in a lot of dependencies. But on the other hand, it doesn't really make sense, in in my opinion to make any of those dependencies

optional because that's something that's just broken and you won't know why. So it's a situation where nobody is really right or wrong. It needs to be redone. Like what we need to do is split up that repo, but let's say we did, right? Let's say we split up KDE Plasma add-ons, which has something like 15 widgets in it. Should we make 15 new packages? If we did that, wouldn't that make life harder for people like you who are trying to install things package by package and wondering why things are missing? I think that would... So there's a lot of things I don't care about in Plasma-ons like most of it actually pretty much all of it there's like one little thing um i don't recall uh there was yeah i don't remember there was one thing i wanted from it regardless um i so i think if you have some prominent ones are like the

weather widget which is in plasma add-on yeah sure let's say there's also the large icons task switcher which is very popular and people like that. Right, right, right. There's the timer widget that's also in there. So, you know, if each one of these was a separate package, then wouldn't that just be more error prone for people wanting a complete system? Or maybe what we should do is put those in core

and have those in like Plasma desktop and everything else should just be distributed via store.kde.org or something there are a lot of things we could do here um because frankly the approach of having a giant meta repo that has everything stuck in it is pretty lazy and it also doesn't scale because the more things we put in it the more it you're eventually going to get into a 500 megabyte package this is way too big yeah so so you know yeah there's there's something that's that's definitely going to need to be going to need to be done there at some point and and that's that's going to be a discussion because it will reignite

this debate over should we split everything up into tiny pieces or should we make it easier for people to get a complete system and I don't think there is a right or wrong answer there. And so that's why I think when you do decide to kind of build your system from pieces, you have to expect that there's going to be a little bit of friction there because it's like getting DIY furniture, right? When you get DIY furniture, you got to put it together. And it comes with instructions, but let's say you don't read those instructions. Well, if you don't read the instructions, you're going to have a hard time putting the furniture together and whose fault is that? It's yours. And the equivalent of the instructions that we provide are that distro packaging recommendations page. Those are effectively the instructions for how to get a good complete plasma

setup over there. So I think you got to read the instructions or you got to get an out-of-the-box pre-built product or else you're in for an adventure. That's my new favorite word to describe the experience of using one of these DIY or less stable systems. I don't know how you feel about this, but I feel like in these cases where... Let's say with the cube, for example. I don't know if this is something you would say is worth fixing or if it's something that's just on the distros to make sure it doesn't happen but I didn't like that it silently

errors out so if you don't have a quick whatever it's called the dependency the 3D one if you try to open up the cube it just doesn't work it doesn't tell you anything there's no error from Plasma it's not like missing library up the cube, it just doesn't work. Yeah, it doesn't tell you anything. There's no error from Plasma.

It's not like missing library or anything like that. It just does nothing. I don't know whether that, and there are a couple of places where that happens across Plasma that you could argue are entirely the fault of me or entirely the fault of Arch for the way they package. And maybe you could argue that the whole idea

of there being a Plasma desktop package that can be installed by itself shouldn't be possible. And maybe distros shouldn't even allow that. There should be these things that are hard dependencies. Like the basic package list, like the meta package, should be the only thing that exists. Maybe that's fair. I don't know what your thought on this is, but just give me your general thoughts. So it's a complicated situation.

I don't think there is necessarily a right or a wrong answer because it depends on your perspective here. Like you could very easily make the point that, oh, distros have mispackaged our software and it's up to them to get it right. We shouldn't have to show error messages for their problems. And I think that's a valid perspective. But then there's also the perspective that says, one moment. So good, so good. Busy house.

So there's also the perspective that says, well, the fact that it's possible for distros to miss package this means that it's up to us to provide some sort of blame shifting so that the user at least Forgetting forgetting about whose fault it is the user knows what they can do Um, I tend to be in this camp personally because I think that you can't rely on people To understand all of that stuff themselves all of that stuff themselves.

Sorry. As you can tell, my life is very busy. But that's okay, because better busy than not busy enough. So I tend to fall on the side of when there's an error of some sort, we need to show it to the user so that they at least can know what to troubleshoot. And better yet, we need to tell the user whose fault it is so that they know who to file a bug report on. This gets back to what I was saying with Discover, where we worked very hard to make it clear whose problem it was and who they could go to for help. And in fact, for the cube effect, I believe we did just that.

So we now have a visible error message that appears on the screen when the cube couldn't be loaded. So if you're missing that cute, quick 3D dependency that we've been talking about for the last 15 minutes, it will say, blah, here's an ugly QML error, missing dependency, blah, blah, blah. And it's written in technical gibberish, but at least you can Google it, right? If you're typically knowledgeable enough, you'll say, oh, I'm missing that package. I'm going to go install it. Oh, why didn't my distro pre-install it? I'm going to go tell them to pre-install it and so on. So I think, personally, if there are cases where it is possible for something to be mispackaged,

we should make it easy for people to see that error without having to crack open the journal log of course that's more work it's a lot more work and error effort is finite and there are limited resources so it's it's all about increasing those resources so that more of this stuff that we all want to happen can happen so when it comes to distros like Arch, I think the much simpler problem is the way... I'll get back to the packaging guidelines. There's one line in the guidelines where it says recommended packages to pre-install.

For anyone... I don't know if you know the exact line. They probably don't know the packaging guidelines off the top of your head. I actually wrote that. Unless you do. You know it fairly well. Okay.

For anyone who doesn't know it, it says these are packages that we recommend you pre-install by default or install when the user installs your KDE Plasma Desktop meta package. This implies that the existence of a Plasma Desktop that is not a meta package is like a valid way for it to be installed.

Like a valid package to exist i think i think if i i think that if the idea of not wanting to support the idea of a solo plasma desktop by itself that should probably change to something like these are packages that we require be pre-installed um because this is why arch does, very strictly to the letter, most of the time, there's a couple of cases where they don't, but very strictly follows what Upstream says. So if Upstream says you can have a meta package and then you can also not have a meta package,

that's going to exist. And whether that's something that Plasma wants to support, that's understandable. They don't want to support it. But I think the simplest solution is changing the guidelines. It's not up to us to require a meta package we can't really do that because we don't offer the packaging sure sure um we can we can tell packagers please offer a meta package and i think to my knowledge all of them do in these distros but we can't require that people use it, right? And I think not using... No, you couldn't have the desktop

not build without the dependencies installed. You could hard do it in the code base. Which dependencies? Well, the basic guidelines for the meta package outlines as what Plasma needs to contain. That's what I would say. Not the entire framework but you know the the list where it's like breeze gtk that's not even possible either

because uh plasma desktop is indeed just plasma desktop as distinct from plasma mobile and plasma big screen right so we do have to have these separated out um and i i think in KDE we try to be nice. And so the experience of not installing the meta package and building it from pieces is valid. I don't think there's anything wrong with this. But I think when you do this, you kind of have to realize that you're on your own. Sure. That you're assembling IKEA furniture without an instruction manual. And maybe we could make that clearer on the wiki page as well, because we want to make sure that people know what

they're getting into, right? Because there are a lot of packages here. And installing a meta package is easy, but we also can't put specific distro recommendations on here because every distro packages things differently. I know in Fedora, for example, they do basically what you say, where they make lots and lots of things, hard dependencies on Plasma Desktop, and they don't

even let you remove any packages that will cause Plasma Desktop to be removed, which I think was done after the Linus thing where he blew up his system by trying to install Steam or something like that. So they make it like a hard dependency there. And that makes sense because Fedora is kind of more of a, you know, everything included distro, but Arch is by definition a DIY distro. And when you choose to use a DIY distro, I think you have to enjoy the DIY process, right?

You have to be the kind of person who encounters an issue and sees it as a fun challenge that you can overcome um and if you're the kind of person who sees those challenges and gets annoyed at them maybe it's a sign that it's not quite the right distro for you no that's that this is the general you french no that's that's understandable i i get what you're saying here yeah yeah no that's fair um That's the only reason that I talk about this, because of the way the guidelines are written. If the guidelines weren't written like this,

then I wouldn't install Plasma like this. I would have all of these different things installed. But I like to push... I do like to push the bounds, right? If this is going to be a supported way... Maybe not supported by Upstreet, like explicitly, but if this is not going to be something disallowed or i know like as you said it's hard to do that but i think even if it's not making hard dependencies i think updating the guidelines to make it explicitly clear what is and is not supported by the upstream project, I think is going to go a

long way to making it clear what should be done. It's an interesting point. You know, right after this recording, I can go think about that and update it. It's a wiki that's nice and easy. But I think it's not really about what's supported and what's not because we we support using the system in any way that makes it work it's kind of about what you're expecting right like if you're expecting for thumbnails to work out of the box um then you've gotta install the meta package or you've gotta know what that package is and know that you have to go install it or use a distro that does all this stuff for you. And if you aren't doing any of those things, then you're not going to get thumbnails out of the box.

And maybe the problem here is that we're not making it clear enough what you risk losing if you don't use a meta package. And perhaps that's the avenue of improvement we can investigate. Yeah, no, I think that's definitely fair because it's, again, this goes back to the thing where like K-Screen is like a separate module. It's not entirely clear like what is and is not separate. That, yeah, I think it's a tough problem because there's going to be a lot of different things

that would need to be mentioned then because there is a lot of different packages and it's obviously easier than rewriting a bunch of code. Yeah, for sure. Like updating a wiki is a lot of different packages and it's obviously easier than rewriting a bunch of code. Yeah, for sure. Like updating a wiki is a lot easier, but that's not to say it's like a trivial thing to do. And I do get that like.

Oh, that stuff's easy. Text is easy. I went to a liberal arts school. I know how to write English text. The only thing I know how to do, I can pretend to code sometimes, but I can write a decent English sentence. But yeah, the reason why I bring this up is because I watched your stream and it didn't seem to me like you were having any fun. To be fair, when I'm streaming, I'm drinking and also I'm, it's intentionally being extravagant. Sure, I get it.

That's the YouTube. It was also my biggest story. I had 500 people in my chat. People are constantly talking at me. And it's hard to shift focus and, you know, yeah. I'm sure you've done talks in public before.

Having people ask, try to get your attention with different things, it's difficult. Well, mostly when I'm doing a talk in public the audience is nice and respectful and they're not interrupting me yeah that's fair so i can see how streaming would be a little bit more nerve-wracking there they're just but then you get the top questions people are yelling questions at you constantly and people telling you how you're doing something wrong because they've been using plasma for 10 years and know exactly how to do it

and then the people who pretend like they've been using it for 10 years who are completely wrong and are just sending you down the complete wrong path. That's always great. Yeah, yeah. I get it. I get it. That does sound stressful. At least when you're public speaking,

usually people save the criticism for the very end where they'll ask a question where they'll say, well, thank you very much for that talk, but don't you think that everything that you said is totally wrong and what I'm about to say is actually right? Right. Also, it's not necessarily people that are wrong. There are people also, as you're saying, options that were removed in Plasma 6. Like, they tell me about an option to fix something, like some issue I was having, but it exists in 5.27, but it doesn't exist now. So it's, yeah.

Yeah, exactly. Yeah. So anyway, you were saying about the stream, didn't look like I was having fun. Yeah, and I was feeling sad because, you know, the process of discovery and learning something new, I think can be fun. I figured there was a little bit of extravagance

and flamboyance for the audience there. But yeah, my general hope is that people who are putting together a Lego set without the instructions would be enjoying the process. Otherwise, they would be using the instructions. I think the main... I take your meaning that maybe the instructions themselves were not as clear as they could be. So totally going to change that right after this most of that stuff like i i off the stream i was like checking reddit posts and stuff like oh here's a dependency i'm missing install that why why can't i configure my monitors okay screen needs to be needs to be installed i needed to report a bug i was like it said go to about

this system i was like why is about this system missing? Oh, it's a missing module. All of this stuff is fine. The main issues I had, and I did talk to David about this, were my stuttering issues. And there were stuttering issues that got addressed in 5.27. And this might be a different issue or something. Or it might be an AMD driver issue i i don't know what it is but um yeah there's just like anim sometimes animations lock up i i have no idea what the

problem could be and i'm not an nvidia user that's which is the big problem i'll try not to turn this into a live bug triaging session but uh is it fixed now or are you still experiencing it? Let's find out. No. To me it sounds like it probably is a graphics driver issue. Yeah. Well, this goes back to the wire plumber thing, right? Like it could just-

It's a thing, how do you know, right? For graphics drivers issues in particular, there's almost no way to avoid first filing a bug on KWin and then Xaver or Vlad shows up and they say, oh, it's this exact bug on the Mesa issue tracker. That's kind of what David was saying, where it was like, there's animation, you need to like request a number of like a delay from the GPU or something. I don't remember. It was like, go technical GPU stuff.

I didn't really know. These guys are way smarter than me. I can't pretend to know what they're saying most of the time, but I always just. Basically GPU hard. That's pretty much where we got. It's very hard. It's very hard.

Very hard indeed. But the reason why it might sound like I'm so critical about Plasma is because most of it is good. Like, most of it... Like, I don't need to talk about the way that, um, like, window snapping works or the way... Like, basic things like resizing windows, window closing, the way shortcuts work.

Like, all of this stuff's great. Like, this is why... Like, it might seem like I'm more critical than I should be, but it's because there are these very few issues that I have that, like, that... Why is OVS

lagging? Oh, no, maybe the whole browser was lagging. I don't know. Whatever. Chromium. We'll fix it. I don't know what it was. I will check in the recording afterwards. But there are so few issues

I have in Plasma. Like, the way tiling works is one and it's not a bug with tiling. It's just... Have you tried Polonium? I'm waiting for them to get 1.0 out. And I think they're waiting on Plasma to fix a bug. So I think the bug's going to be fixed in... I think the bug has been and I think they're waiting on Plasma to fix a bug so I think the bug's going to be fixed in I think the bug has been fixed but they're waiting on.04 is that the next version

or is.03 whatever the next version is to come out..04 is the next one yeah but yeah when when you look at the tiling system the tiling system was not designed to be like a full window manager alternative it doesn't offer auto tiling The idea was to offer enough API hooks for third-party scripts like Polonium to add that content themselves. And so I don't use this stuff myself, but I think they've largely done that. So if that's your preferred workflow, I would definitely recommend using one of those tools above and beyond what's built in. There are things even in the context of the way it currently works that i do think could be improved like um the quick tiling interacting with your tiling layout that would be a massive improvement

sure that's that's an open target yeah i wish listed in there like currently working on that okay for six point yeah okay okay that's awesome it was something that got flagged during the development of this feature as like an awkward interaction but we didn't have time to sort it out because it's kind of a conceptual problem because we're we're we're adding a new system that does the same thing as the old system but more and better yeah but the old system has been refined to perfection over 15 years. And so we don't want to make the new system worse than the old system in a million tiny little ways. Because then that's a way that we frustrate the heck out of people. But on the other hand, if you do what we did, which is add a new system on top of the old system, then you have code duplication. And then you have multiple paths to achieve the same thing.

And people get confused. And you have code duplication and then you have multiple paths to achieve the same thing and people get confused and you have a maintenance burden. So it's just one of those software development is hard things, especially software development in the context of keeping an existing user base happy is hard. I also, I haven't reported the problem yet. I need to do that. But I also noticed a weird issue where under some like very odd conditions, if you resize a floating tile,

you can get it to start overlapping with other tiles. It's a very weird one. I think it showed up. I thought we fixed that one. Oh, okay. Maybe it. Let me try that. Yeah, we fixed that.

That's fixed in 6.1 already. Oh, okay. Awesome. Yeah. I remember that. That's fixed in 6.1 already. Oh, okay. Awesome. Yeah. I remember that one. That was a 15-minute bug. Because I... So I...

I electrocuted somebody into fixing it. Because I was messing around with the floating tiles, and I had... I think I had, like, two floating tiles sitting there, and I resized one of them, and it suddenly turned back into, like, a regular tile, and it suddenly... And it was, was like because it was

it was overlapping so the buttons were behind another tile so i had to like delete a tile to get to it obviously it was a bug um yeah definitely a bug got fixed already yeah maybe even 604 it's at least fixed and fixed in 6.1 okay so i'm trying it out right now and it's it's not happening again because i know exactly what bug you're talking about yeah yeah it's it's one of those bugs where you have to like really be trying to do something stupid to get it to happen um i mean frankly you know the awkward truth is a lot of bugs are like that um my wife has been using kitty plasma for years now, she experiences no bugs. Because, I mean, not to be insulting to anybody, but she uses the system like a normal person. And when she does have a bug, it's like a very obvious bug that like everybody will hit. And it's the kind of thing that gets fixed quickly. But if you look

at the kind of bugs that get reported on the bug tracker, overwhelmingly, they're bugs that are caused by like technical nerds doing very interesting, creative things. And that's great. I love, I love the fact that people use our stuff in really creative ways. But the more creative you are, the more you're likely to experience paper cuts sometimes, right? It's just the nature of it. Like a common you're likely to experience paper cuts sometimes, right? It's just the nature of it. A common one these days is people who are saying, well, I have three panels on the top of my screen, one on the left, one on the right, and one on the middle. And now they don't interact quite right. It's like, that's true.

That's a bug. We know that's a bug. But also, like, do you really need to do that? Like, it's's supported and we will fix the bug but like still yeah nobody's forcing you to do that like let's let's face it let's face it this is not a showstopper when you decide to do that yeah i think but again it's a bug and we will fix it right but that's just the downside of offering a very flexible system right is that people people will use it flexibly

and they'll stress test the heck out of it and they'll find all these issues and then they will report all those issues. And then we will get disappointed and depressed because we don't have the resources to fix all of them, all the resources that we wish we had, which gets me back to how, you know, every project is like five people

doing 80 or 90% of the work. And this is probably the point at which I'm going to launch into a mini fundraising spiel, because this is something that I believe very strongly is needed throughout the open source world to make this work sustainable. And I think it's in everybody's interest that maintainers of open source projects be paid a living wage, a decent salary, right? Like you shouldn't have to make a sacrifice. You shouldn't have to sacrifice your nights and weekends. You shouldn't have to live like a pauper and be poor compared to your peers

if you want to do this amazing work that benefits humanity. And I'm already so happy and gratified that there are companies out there who sponsor work on this companies like my employer, Blue Systems, companies like Red Hat, companies like Valve, companies like Tuxedo, all the other companies that you've heard of. But it's never enough, because there's an infinite variety of bugs out there. And it's also never enough because these companies are quite understandably sponsoring work that they care about.

So one of these companies says, we're going to pay you to work on this feature that's important to our clients or this feature that's important to our users or this bug that's affecting our users. They are absolutely not going to have a free floating engineer put on general random bug fixes. They're not going to have a full-time QA person stress testing the system and writing tests and triaging bugs. And frankly, nobody else is going to do that stuff on a volunteer basis because it isn't any fun. I've spent like the last seven years trying to interest people in bug triage. Every time I do any kind of public speaking or public communication, I tell people

bug triage, bug triage, please help with bug triage. It's the easiest way to get involved. You can make a big difference. And I've had this experience now multiple times where a person shows up and they volunteer to start doing bug triage. And some of them will even say, hey, please mentor me personally. Help me. Help me get up to speed and let's do this together. And those people will do a great job for about four months. Then they disappear because it isn't any fun. Because to actually do a good job on bug triage, you have to treat it like a job. and it doesn't feel like a hobby anymore. And so to a certain extent, we rely on either professional bug triagers who are doing it as a part of their regular KDE job or volunteers rotating through the system. So my dream is to

have KDE EV, the nonprofit behind KDE, hire a small QA team to do bug triage and to do random bug fixes of miscellaneous problems that they find and small miscellaneous system hardening. We already have one person in KDE, Evie's employee who does do this, Nicholas Fellow, who is KDE's software platform engineer. He does an unbelievably amazing job, but he's one person. And we need seven of him. You know, we need six of them. And then we need one person who's like a manager who can direct the team, maybe him.

And then we need them to be able to report to the developers and to have a working relationship with them. And in order for that relationship to work, we need for there to be able to report to the developers and have a working relationship with them. And in order for that relationship to work, we need for there to be an org within KDEV of developers working on stuff with their own manager who can talk. And now we're looking at like 10 full time people. on a full-time basis in a way that's competitive in the marketplace, salary plus benefits plus taxes and cost to hire them, you're looking at $100,000 a year, 80, 90,000 euros to be competitive. And that is not an insignificant amount of money. The number that I like to throw out is that up until very recently, KDE EV's entire yearly budget was like 284,000 euros a year. It's like nothing. Right. And that was used to cover server hosting, development sprints, the annual academy conference of taxes, because we do pay taxes. People don't realize that even though we're a nonprofit,

we have to pay taxes. There's all these expenses. And so what KDE is able to do with the limited resources it has, either volunteers or sponsored developers or the very small number of people who KDE EV is able to pay is astonishing. It's miraculous, frankly. And I want that to be increased tenfold. I think it is very important that KDE EV have enough money to pay its own internal developers a living wage, a market competitive wage to work on this product so can its independence can be assured so that it doesn't need to be so dependent on fickle volunteer labor or on corporate contributions that could disappear at any time you know we're all beneficiaries of this but i think if we're honest with ourselves there's a serious fragility here and i would like to get ahead of that and help KDE EV support KDE even more in a technical sense.

And that requires a lot more money. So if it's something you want to see, KDE.org slash donations is the best way to make it happen. We just did a fundraiser for Plasma 6. And when we started this fundraiser we had 52 supporting members once a supporting member is somebody who says that they're going to pledge 100 euros a year so that's 5200 euros a year there's nothing right uh pizza sorry oh sorry i was confused that's right so 100 euros a year for 50 people. Yeah, okay, no, I might...

It's like Starbucks. No, my brain was falling apart there. I thought the numbers weren't making sense. No worries. That makes sense. 100 euros per person. It's just as likely that I got it wrong. No, no, it's fine.

I never do math on a stream, so I'm doing something risky here, no matter what. No, no, I think i just heard you wrong it's all good anyway so yeah we had 52 supporting members who were collectively providing 5200 euros a year which is peanuts it's nothing it doesn't amount to anything busy house i see that very busy house um anyway yeah so my son is telling me that he wants to make his own dinner, which is nice. Nice to see kids being independent. Anyway, so we had, you know, 5,200 euros a year that these folks are providing, which is wonderful, but it's not enough to move the

needle on anything. And we did this fundraising campaign campaign and as a result of this fundraising campaign we now have 1 000 support supporting members who are enough to bring in 100 000 euros so 100 000 euros that is enough right that is enough to hire a full-time developer two part-time developers uh all sorts of stuff like that so that moves the needle. And this is what we accomplished in six months. And I fully believe there's a lot more mileage that we can gain out of that. I think there are so many more people out there who love KDE, who are willing to give back somehow, who maybe don't know how to program, they don't have time for bug triage, but they do have some money to give. And 100 euros a year is not that much money in many parts of the world. And so I think if we can keep going on that, there is an enormous amount we can do to make KDE more

internally independent and financially sustainable. It's something I would like to see from our other companies too. If you go to kde.org, you'll see at the bottom in the footer, there's a list of companies that support KDE financially. And it's a cool list. There are a bunch of companies you've heard of there. There's Google, there's Canonical,

there's Tuxedo who I mentioned earlier, there's Blue Systems, my employer. And then there are even smaller companies who you might not have heard of, like G10 Code, which is a new supporter. And they support KDE's cryptography software, which is used throughout NATO, by the way. It's a big deal. And I would like to see that number go up. I would like to see many more companies represented there. I think there's a lot more room to grow here. And so this is going to become something that we increasingly focus on, is trying to make... Did I break? Oh, good.

Did my connection drop for a moment there? Yeah, I think so. My apologies. This has certainly been a dramatic stream, hasn't it? Yeah, you know, it's fine. Anyway, yeah, I was pretty much done. I was just saying, so I think there's a lot of mileage that we can get out of this. And there's so much more we can do

to make KDE financially sustainable. I think a very important thing you touched on in there was the idea of competitive rates. Because you can absolutely hire a bunch of engineers at, you know, 50,000, for example. But why would someone who has the knowledge they have obviously if they really really love what they do for sure yeah they'll do it but a lot of people they live in you know places like la you shouldn't live in la it's too expensive there. Or New York or other places like that where the cost of living is just ridiculously high. And they could work on KDE or they could go get a job

on Netflix or Google or Amazon. Obviously, you may not be able to compete with the top of the top, but competing with your... At least competing with the run like the run of the mill dev studio, like that, that's something that needs to be done. And otherwise, why would they come work for you unless they really, really love what they do? And to a certain extent, that is what we want, right? We want people who are super passionate, but there's another angle here, which is I think less commonly appreciated, which is you cannot have an organization made entirely out of superstars. And that's what most FOSS projects are. They are purely made out of superstars. Like everybody who's volunteering their time, top 5% of the industry. But the problem with only hiring superstars is that superstars are really ambitious. They may not necessarily want to stay with you long-term.

They may want to increase their salary and be making $300,000 a year working somewhere else, you know? And ambitious people are also, like superstars are used to getting their way. And when you have a whole bunch of superstars, often they have difficulty coming to consensus on something. When I look at something like bug triage, right? Bug triage does not require a superstar. Bug triage requires somebody who is detail-oriented, somebody who is personable, somebody who has empathy for others, somebody who has technical skills. So like normal levels of these things, right? Like this is somebody who probably could be paid 50 or 60 or 65 or $70,000.

They don't need to be paid $100,000 a year and they would be happy. And then they would stay and do it for 10 years and gain institutional knowledge. And I think the same thing is true for developers. Not everybody needs to be a superstar. Some people can just be slinging code, taking direction from others, not being dramatic.

If you look at most organizations, that's what they're like. You know, you're not going to have all of your colleagues being superstars. You're going to have a range of people whose interests and motivation range from, I love the company and I love the product, all the way through, I want to make a living and feed my kids and be able to afford my health insurance. Right. And that's perfectly valid. And when we require everybody to be superstars, we're excluding those people who, frankly, have something to offer as well. They're also usually a lot cheaper than superstars. So I think there's that element of it as well. But, yeah, we do, regardless of that,

need to pay market competitive rates. Something I hear a lot is people say, well, you don't actually really need to pay competitive rates because you can just hire somebody from India and they only need a third the amount of money, right? Well, anybody in India who's going to be doing that is also looking for other remote work jobs where they will be making three times as much money so you do actually have to compete on that sort of salary right like if this person from India is is looking at your job they're also looking at jobs from you know from Siemens from Google from Facebook and they're not going to say oh well you know it's okay that I'm in India I'm going to accept less money they're going to want more money. Of course they will. Who wouldn't?

If they have basically native level English skills, they're a very competent developer. Like, yeah, they're not going to, you're not talking about like, just like some random person on Fiverr where you're getting like some, something thrown together. It's like, they're working for basically nothing. nothing like that's not what we're talking about we're talking about people who if like if they wanted to they could like the only reason they live in india is because they were born in india like they could go anywhere else and they would be just fine yeah like that's exactly it when when you're hiring people for remote work these are people who could be mobile.

Yeah. And so they're going to demand global level competitive wages, not local level competitive wages. Yeah. This is a tough issue. I'm glad that there is a lot more funding coming in. Do you have any ideas for like possible future fundraising i i know that i back when it happened i talked to um the guys who set up the thunderbird

fundraising campaign that was done where they have massively massively increased their funding i don't know if you'd want to go like do some sort of pop-up like they did and like what sort of like it worked really well but i don't i don't know really what the yes i'm actually writing one i have a little project that i've been writing that does that once a year around christmas it shows a little tiny notification in the corner and it says hey if you love it please share the love once a year and if you are enraged by the mere thought of this, you can click the shut up and go away and never bother me again button. And then that's it. But I think this has the potential to be super important.

Because our experience with fundraising so far has been when you ask, people give. Not everybody. But when you ask, people give. Not everybody, but when you ask, people give. And we've been so timid about asking for so long. We've been afraid of money. We've been afraid of fundraising. We've been afraid of growth. We've been afraid of hiring and looking corporate. And we're at a point where KDE is important to the world, and we need to acknowledge that maintaining that has grown beyond the ability of random volunteers to contribute. And I'm not disparaging our random volunteers. They are universally in the top 5% of their careers. They are amazing.

But there's not enough of them. And we can't rely on it because people's level of time and motivation changes, right? You may be a passionate volunteer in your 20s, or when you're a college student, and then you get a job and you get married and you have kids, and suddenly, where'd all the volunteer time go? That's not because you suddenly lost interest in KDE. It's because you gained many other things that are competing for your time. And so I think especially when you're talking about engineers between the ages of like 28 and 50, we have to pay or else we're just not going to get these people.

And that's why I think you see such a gulf. Like you see so many students, you see passionate students, and then you see like retired people or early retired people. And everybody between those age groups are like either sponsored to work on KDE or are like unemployed, taking a pause from their work, or they have like a really easy job that lets them sit in front of a computer all day you know if you want those kinds of professionals you got to pay right there's just no way around it yeah but that's expensive that's very expensive i guess not what people want to hear because we all love the freeness of it you know we love the ability to download an iso and get all this stuff for free and that's amazing um but it's it's one of those trite things where you

have to say freedom isn't free right yeah you're and the meme here is that okay well if you're not paying with your time you're paying or if you're not paying with your money you're paying with your time in the form of bug triage and troubleshooting but you can pay with your money, you're paying, or if you're not paying with your money, you're paying with your time in the form of bug triage and troubleshooting. But you can pay with your money as well if you want to make the project better in a way that will make you not required to be paying with your time. Yeah, a lot of- It's kind of, kind of our choice as users. We, we can go back to the whole like definition of free software.

It's free as in freedom not free as in beer and i i know that's like a kind of like a funny meme thing to say but no it is very very true like that is the way this works it is like yes the entire time that we're doing stuff it has also been free as in beer like you haven't paid for the software. There have been exceptions where you might pay for support, for example, but the software itself you're not paying for. So I think a lot of people have gotten into their heads, and I've definitely had these people in my comments where they're like, well, no, it's free and open source software.

Like, why would I need to pay for it? And obviously this isn't most people, right? But it's still that most people don't, even if it's like a dollar, right? Like most people are not funding any of the projects they use. And they don't have to give their entire salary to it. And if they can't afford it,

obviously that's totally understandable. it and if they can't afford it obviously that's totally understandable but if you can afford to give a little bit here and there like a dollar here five dollars here like yeah it might not seem like that much for one person but if 10 000 people do that if 100 000 people do that that suddenly makes a massive difference if 100 000,000 people gave $5 to KDE, that would be massive. Big deal. Yeah, it's the law of large numbers. And that's what you were talking about with Thunderbird before too. I think the average donation amount was something like $22,

like not a huge amount of money. And they managed to raise like $ and a half million dollars off of this so they just got you know several hundred thousand people to donate the price of two pizzas and boom suddenly they have all these resources that they can use to drive the project forward in a sustainable manner and offer careers to people working on it and it's not just a this is one thing i did talk about when i had the thunderbird guys on it's not just a matter of we have funding now we can hire someone for a year it's a matter of doing it in a sustainable way because you don't want to you don't want to just hire contract workers and nothing but contract workers you have the exact same problem you have

with volunteers then where you have someone who comes in, they do a lot of great work, and then now they're gone. All of the knowledge they have is gone. Grants and grant money is that you apply for a grant, the grant gives you $300,000, and then you use that to pay people to do a particular project, and then that's it. The money runs out and they're gone.

And it's nice to be able to have project based fundraising that way when you do actually have a specific project that you could benefit from. But so much of the time, what we're looking for is just operating expenses so that we can hire people long term and let people make careers out of it so that we can benefit from their institutional knowledge staying in KDE. so that we can benefit from their institutional knowledge staying in KDE. Right. Because when you think about it, if you hire somebody for a year or two and they complete their project and the funding runs out and then they leave, they're taking with them all that knowledge that they gained while working on the project. And hopefully the project itself stands alone on its own and it continues to be useful. But if they're gone and they took their knowledge with them

and nobody else stepped up to maintain the project, it's a tough situation to be in. You know, it's, it's much better to have operating funds that you can use to employ people on a steady basis and not be jumping from grant to grant to grant. And I know this is sometimes the way it is, right. And there, there are people who make a career um on being funded by one grant and then doing another one and doing another one but honestly that's like half of half of your job in that case is applying for grants yeah yeah it this this podcast went in a very different direction than i expected it to i didn't think we were talking about like the operational structure of KDE as a project, but... In many ways, it's the most important thing because the operational structure is what

underpins all of this work that people love. We were talking about how you can download an ISO for free and get all of this amazing software on it. Well, all of that didn't come from nothing. It came from people doing the work. And a lot of those people were volunteers, but a lot of those people were paid. And a lot of those people were paid. Some of those people were paid by KDE. And so I think we need to stop being timid about talking about this, about talking about money, talking about financial sustainability, talking about where the software really comes from. And I think the XZ hack exposes that

because thankfully KDE is not a one person project, but it was a wake up call to all of us to investigate where exactly the software that we're getting comes from. You know, we're very accustomed to complaining about corporate behemoths who say, oh, you can't trust Apple, can't trust Google, can't trust Microsoft. They're big evil companies and they don't have your best interests at heart. And that's true. But are you sure you can trust that tiny one person library that's maintained by a person two weeks from burning out. Like, I'm not saying that's worse, but maybe that isn't better either. And maybe we need to do better. You know, maybe if we want for our critique of the big corporations to be a sharper critique, we need to have our own house in order and make sure that we have the ability to pay our own people to do the work that's really important.

It is kind of wild to me that it's taken this long to really have like a big kick in this direction. Because it's not like the whole idea of one person burning out and deleting a project, like LeftPad, for example example or one person running a project and then going rogue, this is not like a new thing, but it happens quite a bit in the web space, and people are like, oh that's a web problem, NPM, terrible ecosystem

there's nothing different, it's the exact same, the only difference is that NPM doesn't have a distribution that is managing what's going on there. That's the only difference. Everything else is exactly the same. In fact, I would argue it's worse than the distro case because you have all of these different distros

that aren't communicating with each other about the problems they might be seeing. And there are certain cases, there are certain cases like when it's like really big with the open source security mailing list, but a lot of smaller things, they get discovered across different distros because there isn't that single point of communication for it and i'm happy that it's finally been it's finally been understood that you if something's going to be that important like on on arch for example xz is part of the base package like it's not a small package that nothing uses this isn't like it's not ssh for example it's not like that that important but it is very very important for a lot of projects.

And there needs to be a better way to handle these cases and handle these libraries where they are important. And a lot of people are using them, but most people don't even know they exist, let alone the libraries. The libraries the libraries i think are a very difficult case because if you're looking at something like the kernel the kernel is already commercially supported and if you're looking at something like kde kde is user visible and so it's easy for us to do kdenlive or gimp or anything like that yeah but libraries like xz they're not user visible and their consumers are other developers. And I think it becomes very challenging for them to come up with a fundraising model that works for them.

And in a lot of these stories that I've read online of maintainers who are having difficulty getting funded, most of the worst of these stories are people who maintain developer libraries, right? Not people who maintain apps, not people who work on the kernel. It's people who say, I maintain this library and it has 500,000 downloads a month on GitHub. And I make $3.50 a month in donations, you know, where the usage compared to the income they receive is a pittance. And here I've been complaining earlier about KDEEV, which is a foundation only getting like 300,000 euros a year. And it's more now, thankfully. These are libraries that would be overjoyed to get 3000 euros a year. So I don't have the answers there,

but I think it's very clear that as an industry, we need to be thinking long and hard about how we can fix that. And also how deep our dependency chains should be. You know, if there are cases where we can do something in-house that's really small, maybe we should do it in-house instead of using a library that comes from who knows

where that may not necessarily be sustainable. Leftpad is my favorite example of that. For anyone who doesn't know leftpad situation, it's an ancient story now and people probably most know about it, but leftpad is a npm package to pad the left side of a string now you might be thinking why don't you use the javascript function for that it didn't exist yet um there was no function in the javascript library to pad the left side of a string so there was this package that most people didn't install it. The problem is transitive dependencies where you have dependencies of dependencies so... Yep, those are the hard ones. Yeah it was

like ten things down the tree and you're like why what's going on here and this person they were fed up with it they deleted the package and yeah it just broke the entire ecosystem because most of npm had some transit dependency on left pad and this is particularly a problem on the web where you have super deep dependency stacks and nobody actually understands how anything works and there's a new flavor of the week web framework that comes out all the time and i think that's that's something that i'm not involved with and i i think my lucky stars, I don't have to be because it seems like a very scary world to me. But we certainly have a variant

of this issue in locally running desktop and mobile software, where it's still important to audit our dependencies and make sure that we're not doing more than we need to. And maybe for things that are really important, once we've got our own financial house in order maybe we should be contributing to our own upstream dependencies a little bit in cases where they need some assistance you know maybe all of us should be thinking about this i think this is one of the places where if managed well the idea of commercial distros could have had an effect here where if you know if if ubuntu for example you paid a dollar for example per download then some of that could be used to if you're packaged on ubuntu you get x amount of funding based on downloads people might there might be a better system that is

just the first thing that comes to mind but even just that like at a at the scale of something like ubuntu if random library gets i don't know a hundred thousand downloads and then it gets like i don't know a dollar per thousand downloads or something i don't know what the number would be but i think it's very tempting i think it's very tempting for companies to put one of their engineers on the project temporarily and say, that's enough. They'll say, okay, well, we'll use this project. And when we have an issue that we're encountering or we want a new feature, we'll have our engineer submit a patch.

And that's great, definitely. But I don't think that's a substitute for contributing to the project itself. But I don't think that's a substitute for contributing to the project itself. Because when you have your engineer submit a patch, you're increasing the dependency on the project of the project on yourself. You're not making the project itself stronger so that it can stand on its own two feet. And then you won't need to be supporting it so much. So I think those with deep enough pockets to be sponsoring work upstream, it would be amazing if in addition to putting engineers on work, they could also make financial contributions

to the developers of the foundations behind them. I think a two-pronged approach is important. And frankly, it's never that much money either, right? Like in the case of KDEV, we're so, so cheap. You know, we ask for like 5,000 euros a year, 10,000 euros a year if you're a big company. Like this is pocket change for most big companies, even medium-sized companies. And that's to say nothing of a small library. Like imagine if the XZ maintainer had some corporation say,

you're doing a great job. Here's 5,000 euros. I bet that would help with the burnout issue, wouldn't it? That's nothing. Yeah. I don't remember what the library was. There was a dude a couple of years ago. His library is used by every

major website like Netflix Amazon Facebook all of them use his web library not a single one of them acknowledges the he's he's like sent them like I think some of them maybe like a random engineer has reported the bug and he sent the company's like support contracts and it, you know, just, it goes to spam. Like, I don't know how much is on the, like, maybe this is the wrong way to look at it. I don't know how much is on the, um, the developers of these projects to reach out as well. There's an aspect of that. There's an aspect of that.

Yeah. As I said before, I think it's so easy for us to be timid about asking about money or talking about money. And I think it's especially true in the open source world where there's kind of that legacy of, you know, cool socialism. We're giving everything away for free. It's amazing. But the reality is we live in a world where everything is more than money. And if we ignore this, we're going to be poor and we're not going to have the resources necessary to eat. You know, I think this, the story you just mentioned, I remember reading a blog post about that. I recall the developer was saying,

reading a blog post about that i recall the developer was saying uh i barely had enough money to eat because i was trying to do my project i lost my job i moved to russia to save money yeah because i ran afoul of the russian legal system and got sent to a gulag like it was this super tragic story and i remember reading this and thinking like, this is awful. It's terrible. This should never happen to anybody, but this is, this is what you make yourself vulnerable to when you don't care about money enough. Like it's, it shouldn't be a point of pride for you to say, oh, I don't care about money. Money doesn't matter to me. Like, of course money matters to you. Do you want to eat today? Do you want to be able to pay your rent? Like, do you want to be able to pay your car insurance so that your license doesn't get revoked? Do you want to be able to visit your mother when she's sick

because she's somewhere else so you can afford a plane ticket or a train ticket? Like, let's not kid ourselves here. We live in a world that runs on money. And we have to ensure that we have enough both personally and institutionally to make sure that the things that we need to get done are capable of being getting done. It's important. Like I would love for all of us to live in a Star Trek world, right? We've got replicators, we've moved past money, we don't need this anymore, right? We live in a cornucopia society, but we don't live in that society yet. And until we do, we need to care about money, because that's what makes the world go round. Like you can have a philosophical objection to it, fine, that's fine. But like, I'm willing to bet your philosophical objection for money doesn't go deep enough that you walk into the supermarket and steal all the food on the shelves. Like, I bet you pay for it. And if you're paying for the food that you're eating, you have to earn an income to get that. And that requires asking for money in some respect, right?

asking for money in some respect, right? You go to a job interview and you do a salary negotiation. You don't start at zero. You don't say, well, I could work for free, I guess, but it would be really nice if you paid me. Like, come on, you know, this money stuff is important. It's stupid and boring and we don't like it. And we would all prefer to be programming i get that i'm i'm there with you but we have to care about it anyway because it's it's important for our ability to do what it is that we want to do if we don't pay attention to it enough bad things happen it's just the world we live in absolutely um well on that note I guess we can end it off there. Sounds good. Yeah. Start a 401k, everybody. So let me know where they can support KDE, where they can find your stuff,

whatever you want to send people to. Yeah. So the URL is kde.org slash donations. And that is a great place to start help make kde more financially sustainable and then we can expand the scope of who we employ what we're sponsoring how the project is managed internally and then the project can be more internally autonomous because if you want to see kde thrive the best way for that to happen is to centralize the resources available to KDE in KDE so that KDE itself can have the biggest stake in the direction that everything goes in. Okay.

Is that what you want to mention or is that anything else? That's good. Let's leave people with one last thing. Okay, easy. As for me, my main channel is Abroady Robertson. I do Linux videos there six days a week. There's some Plasma videos there if you want to see them. Go check those out. I want to do one where I'm talking about the things I really like about Plasma, so that will probably be out by then. Because I really like widgets, for example,

and when I had David when i had david on he was like why like he was he was confused about like how much i care about widgets i think widgets are super neat i like the idea of me yeah it's this running joke that like none of the developers actually use widgets on the desktop or anything i think they're cool in common i don't like desktop icons that's i don't have those on my desktop but widgets well you're in good company there lots of people share that opinion um yeah so that'll probably be out by then along with the rest of my plasma videos which uh have been critiqued by many people if they have issues with my thoughts uh my gaming channel is brodyames. I stream there twice a week.

I don't have any clue what'll be going on when I'm there. Maybe I started playing Elden Ring. I don't know. Check it out. And if you're listening to the audio version of this, you can find the video version on YouTube at TechOverT. If you are watching the video, you can find the audio version on basically any podcast platform. There is an RSS feed.

Put it in your favorite app and you'll be good to go. How do you want to end off the show? What do you want to say? Nice. Thank you so much for having me. It was wonderful to be here again, as usual. Thank you for all the viewers

who are watching. It was lovely to be able to reach you and don't make sure to, make sure to like and subscribe and click that bell icon so that you never miss an episode sure you know what bye everybody i love you all