 So, today I'm going to be talking about a topic that's very near and dear to my heart, which is productization and hardware that ships KDE Plasma by default, because I believe that is how we conquer the world with a K. You may have seen me give similar talks in the past. When I introduced the usability and productivity goal, I explicitly set this out as a goal of that effort, and then I gave a sort of mid-cycle update to that a couple of years ago at Academy. So we're going to do a retrospective and see where we are today. So the big question for all of us in free software and in KDE is how do we get our software into more people's hands? And we've heard a little bit before about how we do this from the app side, and I believe that's a very important effort. But I also believe another half of this is to get KDE software pre-installed on hardware by default, and that means KDE Plasma at the operating system layer, because we want people to have a full-stack free software experience, not just apps, which can be a great gateway to our software, but we want people to be using it down all the way to the base of the operating system. On the other hand, there's sort of the why-bother question, who cares? And I think one of the biggest reasons why people should care about this is because the landscape outside of our little bubble in proprietary software is really very bad today. It's not a good situation. When you look at free proprietary apps, most of them are ad machines or they're spyware machines. They're basically just designed to harvest your information and get you into a pipeline for something else. Those proprietary apps that are paid will involve software subscriptions, so your data has basically held hostage to them, and you have to continue paying on an ongoing basis. A lot of them are cloud-based, so you need an always-on-internet connection. Many of them are simply vehicles for ambitious founders to earn an enormous profit by selling their free product to a big company so you can't rely on them sticking around for the long term. You folks are all familiar with this sort of thing, and I think it's really easy to forget that we don't suffer from any of these problems in the free software world, but normal people do, and I think that's one of the reasons why we have to continue to try to bring our software to them because the world outside of our bubble is just not very fun, and we can make it fun again. I hear this over and over again from people who say, well, KDE is fun. Free software is fun, and that's something that I think you can't say about the proprietary software world where people are just not really empowered anymore, and perhaps the most important reason to do this is because all of us started as young hackers at some point, and the next generation needs those opportunities, too. They need to be introduced to free software so that their entire experience of computing isn't just, oh, I used mobile games and see ads for crypto all the time. This is not ideal, and so that's why we got to do that, because this dumpster fire over here is not good for everybody. So then the next question, of course, is why focus on hardware? Because there are other ways to get software into people's hands, and I think hardware is important because hardware is how normal people get their products. They go out into a store or they go online and they buy a thing, and that thing has software on it, and most people are not super adventurous, they don't change defaults, they may install a couple new apps that they're very familiar with, but for the most part, the software that they get on their product is what they have, and so the more of our software we can get on those products, the more reach we have for this group of people. Another major reason is that hardware makes money, and money is important because all of us need to live, and people who sell products for money have money to reinvest in KDE, and I think this is a really important part of helping KDE itself become more financially empowered to financially empower its members. Hardware vendors are also very close to their users, they keep a close eye on what people want on market trends, on market conditions. If the product doesn't do well, they know why it isn't doing well, and they want to fix that. So that's really valuable feedback that they can pass on to people like us who make their software. So the more we partner with hardware vendors, the better our feedback channels become regarding what the market is actually like, and a final point here is that hardware is just really cool. I mean, I think a lot of us sort of share the sentiment that products are interesting, and there are often a lot of really cool things that you can do with them when people are empowered to make whatever they want. There are all sorts of devices and form factors out there that are very exciting. Now with this effort, we've had some successes before. A couple of years ago, I presented on this, and we've had these great laptops that had KDE Plasma pre-installed on them. We've got the Pinebook Pro over there. We have the Slimbook, and we have the K-Focus laptop. And these are really great products. I know some of you are already using them. At least one of you has one in the audience right now, which is super awesome. And so this effort was already successful, but as you can see, it's fairly limited. And I think in the last couple of years, we've been very successful in branching out from just these kinds of devices into a whole different class of devices. We've got gaming consoles now. We've got phones. We've got voice assistants. And we have the traditional desktops and laptops, which all of us are using. And the mainstays of our productivity is never going to go away. So I would just like to talk about a few of these real fast. So we've got the Steam Deck. I think many of you are very familiar with the Steam Deck. This is a really super exciting product. It's something that has put KDE Plasma into the hands of hundreds of thousands of new users, possibly even millions. I don't know if there are numbers. I'm guessing probably by the year's end, there will be millions. And these are people who I think are a really great market for KDE. The response that we've gotten so far from users about the Steam Deck has been generally overwhelmingly positive. People use the Steam Deck and they say, wow, this is easy to use. This is just how I like it. It seems like gamers are a good match for the software that we make. And so the partnership that we've had with Valve through this has been very impactful in terms of driving fixes, driving improvements throughout the stack. Like I said earlier, hardware vendors are very close to users. And in this case, Valve knows what their users want. And so they communicated through various channels what they wanted. We did it, and KDE Plasma has really benefited a lot as a result of this. We have other things too. We've got the PinePhone and the PinePhone Pro. This is another new device class that we've moved into. These are really exciting mobile phones that have Plasma Mobile on them. They're currently running Manjaro with Plasma Mobile, but I know you can put other things on them. And Plasma Mobile is also another sort of emerging new frontier because it's an opportunity for us to make our software convergent. And Nicolo talked a little bit about sort of consolidation in terms of software. And I think one of the ways that we can accomplish this is by creating the next generation of mobile apps that also happen to be really great on the desktop through our convergent user interface framework Kirigami. That becomes a way to basically make this happen without any drama. Instead of having to say, well, here's the old thing that we're throwing it away and here's the new thing that we're making, we can just sort of quietly make the new thing, allow the new thing to encompass what the old thing did so that it's better. And then boom, all of a sudden we have one unified app, one unified code base. And this is an opportunity that we didn't have before and now do have because of this new device form factor. Another really cool device that's out there is the Mycroft AI smart speaker and home assistant. We had another new device class that we didn't have before. This is, it's like an Amazon Alexa Echo sort of clone, but it's open source. And it runs KDE Plasma, it's got an OS on it called Open Voice OS, which is Plasma. And its software stack uses Kirigami and QML and it's our stuff, basically. The user doesn't interact with it as a Plasma device, but it's a KDE device through and through. And I think it says something very positive about our software that it was chosen for this. And then next, even more exciting, this is what I'm really excited about. All Tuxedo computers now ship Plasma. Tuxedo is another vendor out there like Slimbook. They compete in the same space and they ship a customized Ubuntu based OS on their computers called Tuxedo OS. And Tuxedo OS now runs Plasma. So if you buy a Tuxedo computer, you get largely a stock KDE Plasma experience by default, and they have tons of hardware out there, and they ship a lot of things. So this is very exciting as well. And then finally, rounding out the list of new hardware, we have the Elite Mini, which is a sort of all in one PC that can be used for a lot of different things, and there's a partnership with Manjaro. They ship this with Manjaro Plasma Edition on it. And here's just another device in that space. So I think if you look at all of these things put together, you see that there's a very clear trend towards hardware vendors wanting to pre-install KDE Plasma on their hardware. And so then the question is, why would they want to do this? What's driving it? And I think what's driving it is a few really positive trends in the KDE community and in Plasma. If you look at some of the reasons that have been communicated to us, as well as some things that we can kind of intuit on their own, one of the big reasons is that Plasma is flexible. This has always been a historical strength of the KDE community in general, and Plasma embodies that strength. Because no matter what kind of device you want to ship, Plasma can basically be adapted to meet the needs of that form factor. You can scale it up, you can scale it down, you can write custom software really easily, you can turn some things on, you can turn some things off. It's just a very good platform for device integration because a lot of the custom integration work that might need to be done doesn't need to be done because of the built-in configurability in the system itself. And so that's been a big feature, especially in branching out to new device types. I think another big reason is that Plasma developers are really nice and they're easy to work with. So when you as a hardware vendor do have problems and you do need some custom integration, it's not very difficult to get that done. And you don't find that there's a ton of friction within the community. We've seen a lot of distro partners and hardware vendors reaching out to people in the KDE community and saying, hey, we really like your software, but we've got this problem with it, or we'd like this feature implemented, or there's this integration that could be better. And generally speaking, the response to this is, yes, that's a good idea. We would like to do that. And then the conversation can happen regarding how this gets done. But Plasma developers are really approachable. And so being easy to work with is important. And a final reason is simply that Plasma is very fast. It's a high performance environment. It's really good for all sorts of uses that require low latency and high performance like Valve has used it on the Steam Deck. And gaming is an extremely high performance intensive thing. So the fact that they chose us, I think speaks very well to the technical bona fides of the platform that we've established. And so for all these reasons, we've got this amazing amount of new hardware coming out. And I'm very excited about it for quite a number of reasons. But it's not all perfect. I think that there are still some things we can do better. There's always a way to improve things. In the last couple of years, we've gotten these many new products that have Plasma running on them. But it's only a few, right? It's not a thousand. It's not everything. We're not going to conquer the world with all this. So I think if we really want to get there, there are a couple more things that we need to work on. Some things that we've specifically heard from distro partners and from hardware vendor partners regarding what they want us to focus on. And one of them is the Plasma LTS version. For those of you who are not aware, Plasma is a product that has a very aggressive release schedule with three major releases per year. But we also have a long term support version. And every two years, we designate one version to receive ongoing maintenance and bug fixes. And this product has been adopted by a couple of distros. But it's sort of an incomplete product. Because even though Plasma itself is a long term support version, we don't have, I'm going to go from this list from the bottom here. Hope you guys don't mind. We don't have long term support versions of frameworks and apps. And Plasma is only a part of the system, right? So if you're a distro and you want to freeze on a particular Plasma LTS version, that version gets ongoing bug fixes. But Plasma sits on top of frameworks, and there are no frameworks bug fix releases. There are no LTS versions out. So you, as the integrator, need to choose a version and freeze on that. And hope it's really good. And if there are bugs in it, you've got to backport things yourself. Because we and KDE don't take care of that. The way we take care of doing that for Plasma. And another potential issue with this is that even though in principle in the Plasma LTS, we backport bug fixes, in practice, we only backport a certain number of them. We don't do everything, we don't do big ones. Part of the reason is because some bug fixes are built on top of refactorings that happened later, and it's very difficult to backport these things. This can be done, of course, but it adds risk. And so that leads me to the third point here, which is that most Plasma developers, I'm aware of, are not using the LTS product. And so there's sort of a lack of QA on this product. A lot of the internal QA that we have comes from people using it. And so when people aren't using it, it means that things can break. So I think the Plasma LTS was a really great idea, and we've gotten very positive feedback from a lot of our partners about it. But it's a little bit incomplete, and I think we can work on that. The next major challenge that I see is that there is a lot of reinventing the distro wheel. If you looked at the previous set of slides and notice the OS that was listed there, there were a lot of different operating systems there. We've got Steam OS, which is a custom OS that was made by Valve. It's arch-based, and they have their own things on top of it. We've got Open Voice OS, which is Ubuntu plus Plasma, but not Kubuntu. We have Tuxedo OS, which is also Ubuntu plus Plasma, but not Kubuntu. We have Kubuntu, which is shipped on the K-Focus hardware in a very heavily customized way. We have Manjaro Plasma, which is also rather customized and opinionated about certain things, certain defaults. And then of course we have our own, not a distro, half way. Not quite a distro, Katie Enion, which is shipped on Slimbook hardware right now. So there's a lot of diversity here. And in general, I feel like diversity is a major strength of KDE. But there's a certain point where diversity can become redundancy. And especially when you look at all of these different distros, that's a lot of different packaging labor that's required. And very little of that packaging labor is shared among those distros. So there's opportunities for collaboration on products that are sort of fundamentally similar by nature. And I think what we see in the distro space is that, especially the people who ship distros, who ship hardware are often not interested in that collaboration. Not because of any fault of their own, but simply because it's not their responsibility. In the same way that we have this Plasma LTS product, we make it our responsibility to backport bug fixes. And distributors like that, because it takes labor away from them, I think there's room in this space for more collaboration in the distro space, either consolidation or creation of a sort of reference KDE distro that can up the quality broadly. But either way, I think there's room for KDE to make progress here at a level above the distros to say, here's our vision, here's our product. You're welcome to use it or not in a way that meets all of your needs really well. Because clearly, the reason why we have so many distros here, and this isn't even a full list of course, this is just a list of distros that are currently being used to ship KDE Plasma to users. There are tons and tons more that all of us have on our personal computers here. But I think the fact that we see such diversity here shows that there's room for KDE to be a more active player there. And a final challenge for this effort is that there's an unclear locus of responsibility when bugs are found. We've had this experience of distributors and hardware vendors finding bugs in KDE software that they say that, well, we love your software, but there's this bug here that's affecting our users and it's losing us sales. What are we going to do about this? And so there's that question, who's responsible, right? Is the distributor responsible for hiring somebody to fix it, because it affects them? Are Plasma devs responsible for fixing it because it's our product? Should they hire a Plasma dev to do it? It's unclear. So I think what we need to do is clarify this a little bit. There are a couple potential options that we've got to work on this. We could have, for example, a KDE specific channel that allows pipeline for developers to be hired to work on this. We sort of have this right now with a list of, like the EV maintains a list of contractors that you can contract with, but it's sort of indirect. I think there's room for KDE to be more direct about this thing and say, hey, if you have a problem with KDE software and you're shipping it, here is your channel right here. And that could be not only a channel for dev work, but also just a communications channel too. Right now, when distros and hardware vendors want to communicate bugs to KDE, there isn't an official channel for that either. So it's sort of challenging to figure out where to go. In my experience, sometimes people go to chat rooms. Sometimes people send an email, but then you don't know which email to send it to. Sometimes they'll send it to a particular person who they know about and say, hey, can you direct my query somewhere else? And so I think we can do a better job of saying, hey, if you're integrating our software, here is your communications channel to us, right here. Let's make this super clear and obvious and put it right front and center so everybody sees it. And finally, because we have this diversity of distros, this means that a lot of times distros find different ways to solve the same problem, and oftentimes fixes for problems don't get upstreamed. Again, not because of any kind of malice, but because people are busy, right? You solve the problem, you solve it for yourself. Working upstream can be challenging. And so I think in KDE, we often need to nudge a little bit to make sure that people who are patching our software downstream are submitting those patches upstream. And if those patches are not acceptable for being upstreamed, we need to help communicate why that would be and maybe help them fix the issue from another perspective. I feel like we have sort of a recent success story I can point to, actually. We have Neil over here from Fedora. And Fedora was carrying a patch for Plasma to add an add to terminal menu item that had been sitting in their source tree for over a decade, right? He said it was like 14 years. And it broke recently, and Fedora users complained. And they complained to KDE. They said, you took out the open in terminal menu item, how dare you? And we said, well, we never had one. Where did you find it? And they said, well, I used Fedora. And we said, well, we don't know where this is. And so it turned out Fedora had added it and it had broken. And so we communicated with the Fedora people recently. And we looked at their patch and we said, hey, this is not that complicated. But you're also doing this in kind of an old way because it's 14 years old. That's why it broke. So we worked with them to upstream the patch. The patch is now upstream. The functionality is now in KDE Plasma. Anybody who wants an open terminal menu item can turn it on if they want. And Fedora now does turn it on. So this was really an example where it was sort of a win-win-win situation, right? Users get more reliable software. KDE gets more features. Distros don't have to have so many patches. And so I think there's a lot of low hanging fruit like this. Many of us have distro hopped quite a bit. And so we're familiar with the patches that go into the distros that we use. I think all of us can just kind of help to ensure that distros are communicating to other people. And maybe finding ways to upstream their work so that it becomes less work for them ultimately. But despite these challenges, I think what this shows is that Plasma is a really mature product. It's a really popular product. It's an excellent vehicle for people to put on their hardware. And those challenges that I've mentioned, they're sort of low hanging fruit. I think we can overcome these challenges without too much trouble. They strike me as very surmountable issues. And I think there's also lots of room for people to help out if they want. One relatively easy way for people to help out is to use the Plasma long term support version. One thing that I know is that a lot of very active Plasma developers are living on Gitmaster, right? We're developing all the time. But if you're not an active Plasma developer, or let's say maybe you're a former Plasma developer who would like to kind of come back in an easy way, use the long term support version. Because this is a hole in our QA. And by using it and finding bugs in it, you don't even have to do any back porting or anything. Just use it and find bugs in it. This is a hugely valuable thing that is a way for people to contribute to that product. And I think all of us can also do a good job of communicating more with our distro of choice. Everybody in this room uses one. And so many of us are a part of a distro. So let's just make sure that we've got that channel of communication now. We want to be talking to each other so that people aren't working in a vacuum and unnecessarily duplicating work. Everything becomes easier when we talk to each other. And if you are a developer, a Plasma developer, a frameworks developer, an apps developer, fix little bugs here and there. I have an initiative that I started earlier this year called the 15 minute bug initiative, which was all about the idea of when you first use Plasma. Let's say you're showing off your KDE software to a friend, right? And you run into tons of little paper cuts here and there. All sorts of tiny issues that you hit in the first 15 minutes. These are usually not major issues. They're just, they're polish issues, right? They're things that make you say, oops, I'm sorry, that's a bug. We're going to fix it. And you don't want to have to say that to your friend when you're showing it off. So when you find little paper cuts in the software like that, just see if you can work on those. It seems small, it seems minor, but these kinds of paper cut issues really add up and they make a difference. So that's the end. I wanted to just say thank you all for coming to my presentation and open it up for some questions now. All right, I see a question back there and another one back there. But just beforehand, maybe we can have a show of hands. Who is a distro person, like actual distro builders? So we got a lot. That's a bunch of distro builders right here in the room. Yeah, so let's all talk. Is there a distro buff? Maybe we should have one. I think I have a different conclusion to the LTS topic than you. A different conclusion to what? What was that? To the LTS topic. Okay. Because distros may like it if you freeze your Plasma version, but I don't think that users like it that much. Like users want new features, want the latest software probably. And your Windows, it doesn't freeze if you buy your left window update. Your Android on your phone will update or should update. But people complain that your Android doesn't update any more because the vendor is shit, right? So maybe we shouldn't have an LTS at all and focus on making the latest Plasma the best version with almost no regression. So that's definitely one option. I'd like to also open this up to some of the distro people in the room because I'm sure they have their own answers. Before we do that, one thing that I want to say first is this is where I think it's really important to be listening to our partners. I mentioned earlier that hardware vendors are close to users, so they're a good gauge of what users want. I think we often think we know what users want, but it's important to listen to the people who are closest. So I would be very interested in knowing the opinions of distro people here, whether that's true or not. Is that what users want or is that not what users want? So maybe we can pass the mic around a little bit. Here's a distro person. In Fedora, we also now maintain, for the last couple of years, we maintain KDE Plasma for enterprise Linux distributions, so REL, CentOS, Almanut Drop, whatever. We actually decided to stop using KDE Plasma LTS for many of the reasons that you had, but also for the additional reason was that every combination we ever got was always wrong. For the frameworks with Plasma, with the apps, it just was impossible to get it to stay working. And so we just changed it to being we, every spring, we will refresh to whatever the latest Plasma we ship for that Fedora release and sync it down to Apple for all enterprise Linux users. So we're effectively creating our own maintenance cycle for this because the one that KDE does is not useful. I understand that there are others that are still continuing the Plasma LTS, but our own users tell us that the Plasma that we provide when we were shipping the LTS version was just not a good experience. So to condense that, would you say that your reason for dropping it is because of deficiencies in implementation and not deficiencies in concept? Yeah, deficiencies in implementation, as you said, with the KDE Plasma LTS, it was only the core Plasma components that were actually life-cycled in that manner. The underlying frameworks and the overlay applications weren't, but also on top of that, the necessary combinations to keep those working. So if we uplifted the frameworks and the applications at different cadences, they broke Plasma in surprising ways. And because that's really the only way to get bug fixes in frameworks or applications, we eventually wound up with a combination that looked like it worked, maybe passed some of the tests, but then applications would have bizarre behaviors and things like that. And people were just unhappy. It sucked for us as distributors because we had to pull all these combinations and figure it out. And it sucked for the users because the applications looked like they worked. And then when you try to activate a pretty good function, like one I remembered was Dolphin from Plasma LTS with KIO, was just KIO for frameworks eventually broke on it because of these kinds of things. Weird side effects and consequences just made it an untenable position to keep doing it. Other guy. Are there other distro people? What I'm interested, I know it doesn't work very well. So I guess the question that I think is more interesting is would it make sense to put more effort into making it work well? Or would it make sense to scrap that effort and reuse the effort towards something else? And so I think this is just a great example of we're listening to distroses really important. If everybody says, well, we use it, but it's not great, you can get rid of it, then okay, that's great, let's get rid of it. But if people really want it, then let's make it work the way people want it to work. Clearly we're well in the, this is more of a comment than a question stage, but that's fine because you asked for a conversation. I did. Are there any other distro people who would like to weigh in? Here's another distro, it looks like Debian to me. The LTS is that they never line up with the distro cycles unless you're lucky. Right. But the concept of LTS in many cases makes sense because at least users of slow moving distros might not want the frequent updates, but it depends on your user. I want frequent updates on my personal systems, on the systems in my, I don't want to fiddle around with upgrades. I don't want them to be changing at all. No visual changes, I know where all the stuff are. And these parts of things just get in the way for that. While you're at home, at work, I need to get stuff done and cannot fiddle around with stuff jumping around. And in some businesses like targeting feed, features, tool systems, for example, where you're active to the segmentation, then stuff moving around in a multi-passion is a bit hard. Thank you for your perspective, that's helpful. I could, do you speak to this discussion? You offer it. No, I mean, I think I can expand upon this by making it all sound even worse. Oh, great. Because beyond the distro perspective, I can offer the end-user perspective. Because at Mercedes-Benz, we have around 5,500 developer laptops running a customized version of Ubuntu with VATLAB. And that's maybe what they customize for, along with adding a bunch of other stuff. And the reason it's even worse for the end-user is that we, of course, use Ubuntu LTS. And the main reason why we use Ubuntu LTS is because we have the capacity to modify it, just not the capacity to do it very regularly, meaning that not only do we use the LTS, but we also trail behind it by two years. And then within that LTS, which is at that point already the outdated LTS, we don't get plasma updates at all. So you arrive at being completely cut off from fixes of any sort. There are some curious exceptions, though. There are some bits in the software that can get updates from a repository that bypasses, for example, widgets. It's that you will find from the KDE store, there are some widgets where people have actually back-ported the widget from a newer plasma to make it available so that you can airlift it into an outdated system. Amazing. And I think we should actually kind of look for some opportunities to do stuff like that. We have a couple of things that are common sources of problems integrating different hardware. For example, like the algorithm that hashes where a display is to fix your multi-screen setup that we have to revisit every plasma release. Maybe there should be in a script that not that hard for the C++ code so we can actually OTA it while setting the entire system. Then there's a couple of things where we could look at actually doing what David suggests, just to take control of the update channel and not rely on the distro in a kind of very specific way with some of the sort of critical bits that can update independently of itself. That's a very interesting perspective. I'm feeling like we need a cross-distro buff to flesh these things out a bit more. There will be a cross-distro buff. I'm sure it's gonna happen. Oh, yeah. We can also talk about installers. Does anybody else have any other questions? There are questions from online. Okay, let's get to some of those. Mention those because the hybrid participants are first-class participants. Remember that. Of course. Antimista asks, what about the configuration management of KDE Plasma? Like coin config framework, libElectra, because apparently their company doesn't like it. Are there plans there? So I don't know about any concrete plans there. I have heard from other people that the way KDE does configuration management throughout our software stack is not ideal from an enterprise perspective. I think there's definitely room for improvement here. That said, I can't remember the last time anybody was specifically approached by an enterprisey person or a distro-y person saying that. So I think it would be very useful to codify exactly what the pain points are. So in case that's something we do wanna address in the future, we're making sure that we actually address it and don't just make something that isn't helpful. I would be interested in hearing more about that. And I think my fellow Plasma devs probably would be as well, but I'm not aware of pain points. That's something that pick up in the talks channel. Second question from online, and then we'll go back to, Neil seems very insistent there. Julius Enriquez asks, wouldn't there be concerns from the EVs endorsed contractors or endorsed consultants if it also provides a channel for direct paid work? I suppose so, in as much as any amount of competition is potentially puts pressure on the one being competed with. I personally don't think that competition is a problem. I think in general it makes people stronger and I believe it makes institutions stronger. I think if KDEV wanted to potentially get into the game of hiring people to do technical work in a way that would explicitly compete with KDE endorsed contractors, I don't actually think that would harm the KDE endorsed contractors as long as they were also doing quality work. And I say this as a person who is currently an employee of an endorsed KDE contractor. So when I say this, I am potentially saying, yes, people can compete for my job and I think there is no problem with this because when all of us have this kind of a fire lit under us, we do better work in general I think. As one of the other KDE endorsed contractors, I'm gonna say, help, help, KDEV, KDEV, KDEV, KDEV, KDEV. So if you ever wanna talk about that list of configuration foibles, I definitely have a long one from a distro site and someone who's tried to do enterprise integration because at my workplace, it doesn't matter in this particular context, but in my workplace, we spent several years trying to put together a mass management at its work station environment and like, oh boy, everything sucked about that. So I have a list for sure about those kinds of things. The other bit that was I think the Debian guy who said the LTS experiences that users might actually like having that, I think even for us when we're shipping KDE Plasma for enterprise Linux users, I think they would definitely prefer for us to ship LTS versions and I would love for the LTS versions to work and have bug fixes and be something I could put my stamp of approval on. So like, if it was actually qualified and validated and like we had LTS cycles for all of the layers, I would happily go back to shipping that for enterprise Linux users because boy, it's not easy shipping the latest Plasma to enterprise Linux. Yeah, that's what I meant when I said that it's sort of an incomplete product. It's a good idea, but it needs a little bit of work to flesh it out as a complete thing. 45 seconds for, sorry, this is the last question. All right. So we have hardware now shipping with KDE Plasma, but for world domination, I think it's not enough having the hardware, but also having the hardware in the store where normal person buys the hardware, right? Right, I think it's really important that people can buy this stuff. I think the other angle which has been discussed earlier is getting apps out there too because nobody uses Plasma for Plasma. Plasma is an environment to run apps and we want these apps to be KDE apps as much as possible so they complement each other, right? We want people to have hardware that's running our software at all levels of the stack. And I think, in general, we're all kind of having a variant of the same conversation about distribution, about how we get our software into people's hands. And I think as long as we're focused on that and pointing in that direction, we're going to succeed. We're going to succeed. Thank you, Nate. Absolutely. Thank you very much. Thank you for your time, everybody. We've got five minutes left.