 So, this was one of the major goals of the usability and productivity initiative, which I proposed and worked on a couple of years ago, and I want to ask, do we think we succeeded? And I think we generally did. So the next step is to move on to the next thing. And I think what that next thing is, is to create an official KDE OS. So you might ask, why would we want to do this? Well, the simplest reason is we have to if we want a direct relationship with hardware vendors, because that's what they need. They need an OS. And that means working with distro partners, or it means having our own OS. And we love our distro partners. I do too, but having our own OS allows us to have our own relationship with them. And thankfully, we already have one. That OS is Neon. Unfortunately, Neon is a bit of a halfway product. It's mostly designed to showcase KDE software. Non-KDE software can be very outdated and is not necessarily guaranteed to work. It has a very small development team. And most puzzlingly, we don't admit that KDE Neon is an OS in our own messaging. So on the other hand, KDE Neon is indeed enough of an OS that the Slimbook people ship it on their hardware. And lots and lots of people use it as their daily driver on their own computers, including my wife. She loves it. It's really great. So I think it's time for us to finally admit that Neon is a real OS and treat it as such, we can say that it's what we believe, the reference implementation of KDE software ought to look like. And promote it accordingly. Just clean up our messaging a little bit. And so what would a new, bigger, more official Neon look like? Well, first of all, it would have the latest kernels in it for hardware enablement purposes. It would probably have a method to have newer kernels in it than even its parent OS Ubuntu does. It would have more up-to-date third-party apps. If not from the repos, then maybe from Flatpacker Snap or one of these generally new generation app deployment mechanisms that we support. It would have a lot more development resources too. And this is sort of a call to action here. I think if you want to make this happen, please go ahead and help out. There's also the possibility that in case Neon's Ubuntu base ever proves unsuitable for some reason, it could be rebased on another OS. I think we can be fairly agnostic about that. And generally, our new Neon-based KDE OS would just be more awesome in every way. That's what I think is the most important thing about it. Now, here's the obvious question that I know a lot of you are asking. Is this the worst idea anybody has ever come up with? Because clearly, making an official KDE OS would destroy the ecosystem and it would alienate our distro partners who we rely on, use, and love, and even get financial support from. I don't believe so. I personally think that there is room in the ecosystem for everybody, as evidenced by the fact that we essentially already did this. We created our own KDE OS, even though we didn't call it as such, and it did not destroy the ecosystem. It worked. I think in general, when people like us define their own reference implementation of something, it has a tendency to improve the ecosystem rather than destroy it. Microsoft did this, for example, when they started selling their own PC hardware. They didn't kill Dell and Lenovo. They pushed them to make their own offerings better. And in general, I think this has happened and will continue to happen as we promote Neon even more. And I don't even believe that we should want to kill other distros or destroy them. I personally use OpenSUSE at Tumbleweed myself. I'm very happy with it. I like it a lot. I'm not trying to kill it. I probably would continue to use it after this. So I think there's more room in the world for just one. And that's sort of what I want to communicate about that. I think the end result of this would be pretty beneficial for us because we would be able to work directly with hardware vendors in a better way. Having Neon has already allowed us to do this. And I think it's important that we continue to improve that offering so that we can improve our ability to work with hardware vendors. And I think there's also a very good chance, as I mentioned earlier, that making Neon our own official reference implementation of KDE software would encourage other KDE distros to up their game, do a better job. Not to say that they do a bad job. Obviously, I use a non-Neon distro. And I think they do a great job. But there's always room for improvement everywhere. And I think this is an example where competition potential to help everybody. So once we've got our KDE OS, so to speak, what we need to do is to create a hardware certification program. This is important for a couple of reasons. The biggest one is because hardware vendors will be able to use this to have an official channel for working with us on whatever changes they need. Furthermore, having an official hardware certification process brings confidence to users. They will be able to know that if they install this on their own hardware that happens to be certified that everything will work. There's no more fear or guesswork. And institutions that want to use Linux or other free operating systems rely on these kinds of programs because they mitigate risk. These institutions tend to be very risk-averse. And they want to make sure that things will work properly and not be an IT burden. So they are very sensitive to the presence or absence of some kind of official certification from the data program from. Part of it will be the official QA on the KDE side with vendor-provided hardware. This is what happened with the KDE, for example. There is an event where it could be crowdsourced. There are lots of KDE people out there. And they could submit their own data much in the manner that the ArchWiki has informal ways of showing compatibility with different hardware. And we could basically do the same thing. So the end result of all of this would be that we learn what hardware vendors want from us and what they need in our software projects, which allows us to make them better. And we start adjusting our software so that it becomes more attractive for pre-installation on hardware. And I think that's really the ultimate end goal if we want to get our hardware into more users' hands. So next, once we actually have all of this stuff, we need to partner with those hardware vendors so that they can actually create products with our software on it. We would want to get it added as a pre-installed option for the various people who already sell Linux-friendly hardware, like Tuxedo, Slimbook, Pines, Star Labs, others. But they're bigger fish to fry. We want Dell and Lenovo as well. They already sell hardware with Ubuntu on it and Fedora. So we need to make sure that they have KDE by default stuff on there and not just Nome stuff. So we've already started doing this, which is really great. We have Slimbook. They have Neon on their Slimbook laptops which are really, truly fantastic. They offer it as an option on other machines. And I think we should continue moving in that direction overall. So when we do this, what we're going to all see is more hardware on it that runs Plasma. And most game-changingly, it'll be sold at retail where regular people can gain access to it. And I think this is so powerful. Moreover, if we're used to working with hardware vendors and we have a steady stream of them, this makes it easy for KDE to get into new hardware markets. We're already working on Plasma Mobile so that constitutes phones, there's tablets, voice assistants with Minecraft, smart TVs, with a Plasma big screen, and then there's even cars because of the pre-existing overlap with the cute ecosystem and automotive. And we would also benefit from contributions from our hardware vendor partners' software teams. And in addition, their QA efforts. So I think it has the potential overall to be a virtuous cycle for everybody. Now, we've had some successes so far. There's the Ryzen-powered KDE Slimbook. It's been very well-received. It's a really great piece of hardware. There's the Kubuntu Focus laptop, which runs Kubuntu. The Pine Book Pro is sold with Manjaro and there are various other companies that sell Plasma-based distros on them. So we're doing it. It's happening and it's generally working. We just need to double down and keep doing it, I think. Now, here's the big thing that will make all of this possible is we need to start paying for development work within KDE. Here's a big one. There are a couple of reasons why I think we need to do this. The first one is because there are so many important things within KDE that just don't have enough resources that we all desperately need to improve things like sysadmin as one. Web is another. Carl is single-handedly doing all of this himself on web, but that's not sustainable. We need more sustainable means to do this stuff. And when we talk about sustainability, that can be a problem with employed professionals outside of the KDE sphere because they generally are busy with their jobs and their families and their children and they lack the time for intensive contribution that they are technically capable of doing. While on the other hand, students who have lots of time need guidance by experienced professionals who don't have the time to give it to them. Another one is that the KDE EV has lots of money right now in particular and has a legal obligation to spend it and sometimes has difficulty spending it because of almost the elephant in the room here. The EV often spends money on everything but development and I think if it becomes critical to get that cash reserve down, spending money on development is probably the easiest and fastest way to do it. And finally, most long-term KDE contributors are actually paid anyway. They're just not generally paid by KDE itself because there's a whole vibrant ecosystem surrounding KDE. So in the end, what we can see is that this is basically the only route to sustainable development. KDE is largely not built by unpaid volunteers but rather by paid professionals who are either paid to work on KDE stuff or paid to work within the KDE realm by affiliated companies like KDAB and Enioka. And if you look at KDE's most successful and largest and well-known projects, they are themselves generally led by paid professionals already. Looking at like Krita, which has paid developers from the Krita Foundation. There's Plasma whose developers are paid by Blue Systems Enioka, Suza and others. And there's Neon which is funded by Blue Systems. These are generally professional affairs, not 100% volunteer. And I think it's really notable just how impactful that can be. So when we're talking about paying for development work, there are a lot of different ways it can go, but I think a good way to start would be to have the decisions be made democratically. The EV could decide which projects could be financially supported. This could be done by voting so people's feelings would not be hurt so much. The EV itself would perform the hiring and oversee the work as they currently do for the contractors. So we know that that skill set exists. In general, we would want to hire from within the community as much as possible as we already do. And we could also ask EV members to contribute a little bit more financially. And I think this would be an easier pill if we all knew that the more money we put into the EV, the more paid developers, some of which could be ourselves, would be able to be hired. My own personal recommendation would be to be stress admin and then we move into maintenance and R&D of core software like frameworks, plasma and some of our basic apps like Dolphin and Gwynvue and Ocular. And yes, I'm the only speaker who gives a talk from my bed. I think the end result of this would be that we have a career path for young KDE contributors, which is so important for reasons that lots of other people have brought up to. It means less brain drain. People who are in the community get to stay in the community. They get to move from being new to experienced to senior engineers to actually mentoring others. And this ensures that KDE remains a really healthy and vibrant community. It would obviously mean faster development. Our software would be more stable. I think we would become a more professional organization as a whole. And as a result, hardware vendors would gain confidence that they can entrust their hardware with our software. And finally, the KDE EV states out of legal trouble because they don't have a giant cash reserve that nobody knows how to spend. So here's the next question that is on everybody's mind. Obviously, is this another worst idea ever? Would it SAP developers motivations, pick winners, alienate everyone else and go against the spirit of free software? Now, I personally don't think it would because in a lot of ways, this is where we already are. Lots of KDE developers are already paid to work on KDE just not by KDE. It's by third parties. And the EV already pays for non-technical work. So we know the EV can do this. So we can see that unpaid volunteers are already used to working with paid contributors. It isn't really a problem. It doesn't embitter them. It doesn't make us feel like we have been passed over and that therefore our motivation has been sapped. Basically, it already works because it's already working. And there's nothing about free software that requires unpaid volunteerism. People have bills, especially as they age. We buy houses and cars. We have children who need to be fed and so on and so forth. Financial needs are a thing. And we can always trust if it works. We can be a little bit agile. And if it works, we can expand it. If it doesn't work, we can cancel it. But I think we don't have anything to lose just by trying. And so I wanna talk a little bit about how impactful this can be because it's in fact already happening. I have just been reading in the chat that apparently my numbers for the CRETA Foundation are wrong and there are in fact more full-time contributors than I have listed on this slide, which is a great example of how well it works. The last numbers that I have for the Blender Development Fund were that they were getting 100,000 euros a month and we're hiring 20 full-time developers. Linux Mint has three full-time developers for 10 to 15,000, 12 to 15,000 a month. And so on and so forth. So this is a model that works. And I just want you to all to imagine what KDE could do with that many paid developers coordinated internally. I think we could really move mountains if we had that. So I'm gonna wrap it up a little bit early because I wanna leave lots of time for questions. I think what we have to do is we need to make it a real official KDEOS. We admit is a KDEOS. We need to create a hardware certification program so that users and institutions gain confidence using it. We need to partner with even more hardware vendors to ship it on their hardware and we need to start hiring community members to make all of this more easily possible and increase the speed of our progress. And then we win, victory! So does anybody have any questions? Yes, thank you so much. There are a bunch of questions. I'm gonna start reading them out for you. The first question people had was, what changed since the inception of KDE NEON which was deliberately not named a KDEOS? Is it just the hardware partnerships? So this is a question that I maybe am not the best person to answer. We should probably direct it at the NEON team themselves. My sense is that our desire was to not call it an OS to avoid upsetting our existing distro partners. Personally, don't think this was a satisfying solution. Indeed, that was the reason because regardless of what we call it, it's definitely an actual OS out there that users can install that in fact, a hardware vendor does pre-install. So I think calling it what it is doesn't, not calling it what it is doesn't soften the blow. The blow is already there. Apparently the blow has not killed anybody. So maybe we can call it what it really is in the future. But again, this would be a question more for the NEON team than me. Yeah. The second question is very related and someone is answering it. Let's move to the third question. I don't think KDE NEON is the reference implementation. There is no special care currently of the developers for KDE NEON. Apparently you think else. Could you elaborate? So the point that I wanna make about NEON is not so much that I think it's the perfect OS right now. In fact, I don't even use it. It's more that I think KDE as an organization needs to put in the effort to actually create something that we do believe is a suitable reference implementation. That thing could be NEON. That thing could be something else. It could be, I don't know, Fedora Silverblue with Plasma on it. It could be OpenSUSA via a much tighter partnership with them and more overlap. But I think what's important is that we have something that we consider to be the reference implementation that we largely own and control that will allow us to have a direct relationship with hardware partners. I gather from the question that you don't like NEON. That's perfectly fine. You don't have to. I think it can always be made better and other things can. But what I'm just trying to communicate here is that I think we need to start somewhere. Often things that we start with are imperfect. And I think the goal is what matters less so where we're starting. Thank you. The next question. Given that NEON already exists, what should be changed or improved? Let me see. I think I had a slide about this. Maybe I can find it. I'm probably not gonna be able to find it. But in a nutshell, I think what NEON needs from a hardware vendor perspective, now whatever, let's go back to the end. It needs newer kernels. I think it needs for non-KDE apps to be up to date and to be more reliable. I think those are probably the biggest things from my end. There are all sorts of underlying technical things regarding what distro it's based on. I'm pretty agnostic about distro and packaging tools, but to me, those are the big things. And of course, if you have your own opinions, you're welcome to express them in a NEON context so that we can all work on them and make it all better. Then the next question is what hardware categories are you actually talking about specifically? Depending on type of hardware, the main thing slash difficulty is to be able to install it and update it. But for example, on laptops and desktop, that is not so much an issue. Yeah, I think the sky's the limit when it comes to hardware. Laptops and desktops are a pretty obvious one. Mobile is another one. We already have a couple emerging partnerships there with the Pine people and various other things. So I think we really shouldn't limit ourselves and our imagination here because our software is so good and so flexible that we really should consider that it's capable of running on almost everything. I mean, consider that I'm running Plasma on my computer, you can have Plasma on your TV, you can now have KDE software on a smart home voice assistant. I mean, our stuff is everywhere. This is amazing stuff. We just need to make sure that it's easy for people to buy it because it's sold with it. So that's a good question by default. Cool. Then the next question we have is, instead of becoming a professional distributor to be able to cooperate with hardware vendors, might it be more sensible to contribute with existing distros instead to achieve the same goal? So that's a good question. I think this is something that we generally already do and have been doing for 25 years. This is the old model where we make the software and somebody else packages and distributes it and then we loosely or closely work with them to make sure it's what everybody wants. I'm not saying this is a bad model. I'm not trying to destroy this model, but I think there's room in this model for us to be a distributor as well. As evidenced by the fact that we are already doing it. Again, I want to emphasize that this is not a hypothetical thing. We are already distributors. We have Neon, we allow people to download it and put it on their OS. There is now a hardware vendor, SlimBook, that sells our OS. So I think you can make the case that we're a bad distributor, but you can't say that we're not doing it. So what I think I said earlier was the more we double down on this, the more it actually encourages other distributors to improve their own offerings. And I really do believe that. I'm not trying to say we should kill OpenSUSA and Fedora and Ubuntu. Nothing could be further from the truth. I love them and have used all of their OSs. I just think that if we take control of our own distro, it adds vibrancy to that ecosystem and shows people what we think our software could be and has the potential to encourage those distros to learn from us in the same way that we can and have learned from them. Yeah, cool. Then we have one feature slash downside of Neon is that it's rolling. And I'm reluctant to give that to many people who won't want new updates every day. Do you think that's suitable for non-nerds? Well, Neon is an odd beast because it's both rolling and non-rolling, right? So the KDE software aspect is rolling, but the Ubuntu LTS base is non-rolling. Personally, I think this often doesn't satisfy anybody because people who want the latest software want all of their software to be up to date and people who want a longer period of QA and maturity want all of the software to be like that. So I think this is something I've always personally wanted in an OS is some kind of a user-facing switch that allows you to determine this for yourself. So you could say, I want everything to be rolling and then you get it all new. Or alternatively, you would say, I want to only get releases after they've been out for, I don't know, three months, six months, eight months, so you can rely on the community to do more QA in that respect. I've never actually seen an OS that has something like this. I know Linux Mint in the past has had a variant of it, but not exactly this. So I think that could be pretty cool. I'd like that. Let's see if we can get one more in. Hardware vendors like Purism built their own distro, which for example uses GNOME as default. Why not talking to them so they use KDE in their own distros? So I have reached out to them. I have not gotten a response unfortunately, but I have heard from their own sort of internal rumors that there are people inside that they are open to it. I think this kind of thing is a case where having a personal relationship or a person who can introduce you makes a big impact. I personally don't have that connection. So if you or anybody else does, please reach out to me or anybody else who's interested because I am very interested in talking to hardware vendors and pitching our stuff to them, super interested. Cool. And then one last one, and then we'll wrap it up. Do you have any idea on how to start the process of payment for development? What do you think in starting this process using a per feature or bug solving basis? That is more of the bounty approach. I personally don't think that works so well. I think what we would wanna do is hire a person to work on a project rather than on specific features. And the discussion for which features within that project to support could be made internally. The EV membership could have a stake. We can discuss that. But I think that, for example, if we hired somebody to work on core software, what I would wanna see is that we hire somebody to work on frameworks in general. And we could have prioritization systems so that we could say, hey, here are the really frameworks bugs that need to be fixed before the next release. And maybe a project coordinator could work with people on that. But I think it's better to have people paid as a more of a salary basis than hired to work on specific microfeatures.