 Brilliant. Right. Yeah. So, welcome to my presentation. First, a little short introduction. I'm Dan Laney at Heathrow Jensen, and I have been a member of the KD community for a number of years at this point. And I have had many guys over the years, but usually looking either like that or like that, but also as a way of introducing myself in a more relevant fashion to what's going on here. A short introduction to my digital life. Don't worry, I'm not going to go through all of this. That's not really the point here. But it ties into the title of this talk. So, back when I was eight, I got a Commodore C64 and had my first play around with basic, and then you'll notice there is some time until anything else happens, because my first sort of experience with that was that I played with it for a while, and then the power supply broke in that, in that, or rather the diffuse blue. And I didn't tell anyone for a year, so I didn't play with it. And apparently I decided that that wasn't important, so no one knew. But it did then, after a while, turn into the case where we ended up buying a computer for the family, which a 386SX25 with an astonishing 512K of RAM, that was quite a thing, came on, you know, a slot in card, and it came with Windows 3.1 with the hot dot theme enabled by default, which was a whole entire thing. And then I got into batch scripting back then, which was fun. But then time moved on. I got a PC, and I got Visual Basic, and played around with that for a bunch. I should actually start it slightly earlier than what it says there with VB3, and then via VB4, and all the way to VB5, and then one thing that it doesn't mention there, part of the reason why I upgraded to VB5 and started actually being able to release stuff in 96, was that Christmas of 95, our house burnt down, and yeah, that was a whole thing on its own. But one result of that was that all of us kids got some money to spend on things that had, you know, burnt in the house. So I spent a fair chunk of that money to buy bits for a new computer. And then everything kind of, you know, took the standard turn from there, I guess. I went to high school, and ran into some people who played around with this crazy thing that was called Linux that I'd not really done much in, much with before then. And I installed Red Hat 4.2, and then started playing around with that a bunch, and you know, the cute little startup sound, the test sound that was Linux Torval pronouncing Linux, Linux and all of that. But that was not a part of my software distribution work. That, as it says there, started really in 96 where I released Randomizer 3, which was a wallpaper randomization tool. So that was my first public release. It was at a computer club, so it was the first public, but you know, distributed on a floppy disk between friends sort of thing. But that was my first public release of a piece of software that I had written. But then through the Linux playing around, I eventually, you know, started working on what eventually would become a content management system that actually happened a lot later when it became travel-sized. It was called other things over the years and had different concepts over time, but also that was a content management system for websites that I also ended up releasing eventually, which, as it says on the next bit, the first sort of version of that was called Site Ripple. It was basically a pre-processing tool that took bits of HTML with some keywords in it and turned it into HTML pages that was static. And it, you know, it kind of worked. It was very, very early sort of just string replacement stuff, but it worked pretty decently. And I did my first couple of websites with that and eventually also released that on that website and I glanied at DK. Kind of still exists. Incidentally, travel-sized does not, because it was PHP3. So if you go to my personal website, that has not been updated since then, and travel-sized no longer works, because PHP3 and security was fun. So that's been disabled since then. But it was part of my first sort of software release journey and a couple of other things also got released during that time. There was a another couple of little tools written in Visual Basic and eventually when I joined higher education after a small trip through security job work, which security guard work, which that was a strange experience. Talk to me later if you want to hear anything about that, because it's not really relevant to software distribution here. But then in 2006, I started my direct interaction and my direct involvement with the KD community by making the standard, again, error of reporting eight bugs in a single bug report and getting told that that is not how one reports bugs. Because you're going to start somewhere and I hadn't noticed. So I wrote a bunch of them down and standard sort of thing. And then, yeah, I got better. But so apart from that, my sort of direct involvement with actually trying to work out a better way of getting software to people, that wasn't just picking it on your personal website and hoping that people would notice. The first sort of thing where I started getting involved with that was the GLUAN project. At the Gran Canary Desktop Summit in 2009, we had Dr. IDK who presented us and a bunch of others with a couple of nifty little tools and libraries, which were based around the idea that you should be easily able to build games primarily for the KD desktop. And so we, that is, I and a couple of others, noticed that this was a thing that could be, with a bit of finagling, be turned into something that could be more than just building some very simple games and then hoping, again, that someone else would distribute them. Basically, what came out of that was the gaming freedom project, which was a kind of hybrid thing where basically we looked at the current landscape of game distribution and it was not great. Weirdly, what we saw then is basically what has happened where all of these things are kind of a closed garden. The digital distribution landscape of gaming is a problem. If you look up the various discussions that exist at the moment about digital archiving efforts for games, that the digital distribution revolution comes up a lot in that. And our sort of intentions were that we should be able to do better than what, well, at the time the likes of Steam were doing, which were locking people into effectively an ecosystem that they couldn't really get out of easily. There is a bit more to that story. Obviously, it's not just Steam is not just Valve and so on. But yeah, that was a part of our intentions back then. But also, the distribution part of it was based on this idea that you have two things when it comes to the making and playing of games, which was then the topic of my first talk at an academy in 2010, which was the social game distribution talk, which basically discussed how players of games and makers of games are not two separate entities. There is obviously the ones who make games who don't play them, which some who know me closer will be aware that I'm actually in that part. Yeah, I don't really play games, but I do tend to be a part of the playing of games. I don't just don't tend to actively do it myself, but never mind. The idea being that most people who make games also play them, so there's a large overlap there. And so there was this idea that we should be able to support this enthusiastically. And so we came up with the idea of social distribution where the idea was that someone would have an idea and then there would be tooling to support that idea being created, which at the time was glue on creator, which was a tool built on top of the engine system that we built. And then we would have a way of putting that stuff, the resulting game somewhere, which was the social desktop, which is basically what became open desktop.org. And then there was a kind of connection point, and then there would be a way for people to download and play that stuff on whatever platform they happened to do. A lot of interesting icons in that one, because of course back then Mego and those two what technically still existed. So that was a weird point in history. And then the idea was that eventually it would be a two-way thing. The idea being, of course, that you should be able to give feedback directly and that it would be a bi-directional social support system for both makers and players of games, which again with things like Steam and so on has kind of turned into a thing. It's a lot more tightly controlled on there, but that is effectively the kind of thing that we were thinking of at the time. And so in 2011, after I finished uni, I got hired to work on a project which had a similar kind of thing going on, but was focused more directly on general software distribution. And so the idea was obviously the problem with Gluon. It wasn't great for things that weren't directly based on Gluon Engine. Technically you could distribute stuff through it that weren't Gluon Engine, but it wasn't really great for it. And so the idea was that we had a lot of things that existed, which was also basically what the gaming freedom project noticed. So we had ways of getting things, which was Open Desktop.org or the KD store as it's called now. We have ways of making those things. We had Qt Creator. We have a bunch of other ideas, but Qt Creator was the sort of, yeah, it was about Qt, so why not? And we had a way of constructing binaries for a whole bunch of different systems, which was the Open Build system, the one originally built by Open Sousa for making their distributions, but then turned into something much, much, much bigger. And so the idea there was that we would basically connect the dots between those, which then resulted in the Project Breton kind of plug-in for Qt Creator. And part of the reason I say kind of plug-in is that it is technically a plug-in, but because of how Qt Creator worked in 2011, you couldn't build plug-ins for Qt Creator without building Qt Creator. So it was effectively a fork of Qt Creator, which not great, but as a proof of concept, it worked and it really did. You could build a project in Qt Creator and then you load up this thing, you would connect it to OpenDeskTop.org, and you'd connect it to the Open Build system services, and then it would, you'd fill out a little form with some information, which is the one that's a picture of just there. You'd fill out that form with the basic information of versions and descriptions and so on. And then it would create a rough set of packages for you. You could then edit those and make them better. But as a basic thing, you would have packages, it would build rpms and devs for the various things that it supported on OBS at the time. It was the very early days of the Windows build stuff on there and Mac OS wasn't supported at all. And so we didn't really focus on that. We only had half a year to build this thing. So it got put together and it worked. So the idea was you would do that and then once OBS was done, you would then be able to check. It wasn't polling, you'd have to ask, but you'd also, as a person building on there, you could subscribe to emails and it would send you an email where it eventually got done building the packages. And then through that same plug-in, you would click make me a listing on OpenDesktop.org and it would do that for you. It would also then cache the knowledge so that it wouldn't be creating a bunch of new listings every time it would update an existing one and so on. And so that was the directional thing. It didn't have the commenting stuff. It didn't have the social distribution stuff that gaming freedoms kind of focused was, but it was a way of going from ID to consumer of applications in 2011, which is something that we basically have most of this now. But yeah, we'll get back to that. So a decade after that's happened, we've got Linux distributions, which are doing great. They are doing excellent work. They've got some really polished experiences, but of course there is only so much they can do. We're going to end up with outdated apps. The common one that comes up, I didn't list it before, but I was also involved in the creature project a fair bit. So I've been involved with getting creatures to the masses through Steam and so on over the years. And one of the things that comes up for creature on Linux is that it is always outdated because creatures development cycles are fairly fast. So it's always outdated and people will come to the creature devs and go, oh, I've got a bug and that's great. And it's already fixed. It was done three months ago. You haven't got an update because your distribution hasn't packaged the most recent release. And that's fine. Like it is the distributions work at a different pace to everything else. And so that's fine. Hence the asterisk. It's just a reality of what happens with that. And that's fine. So we also have Windows, Android and macOS. And on there, again, we're kind of okay. We've got, in particular in KDE, we have the binary factory which spits out packages for those three now with some caveats. But it is mostly there. The bit where it says everybody's rolling their own, which is less true for KDE, but we do still have that situation kind of happening. We then have bundles which are kind of the thing that happens on Windows, Android and macOS where you create bundles of the application versus the developers of the application create the builds and they end up in the hands of consumers directly. And that's pretty great. You know, you go around and you talk to everybody and pretty much everybody agrees that bundles are pretty awesome. But also, yeah, there are a couple of versions of it. So we have flat pack and we have snap craft, which I call them pseudo distributions, which I don't think is entirely unfair. They have both a version of a runtime where they bundle effectively a set of the libraries that make up a sort of coherent lump of supporting libraries. And then those get updated more regularly. You might end up with a couple of different versions of some runtime because some package demands an older version of the runtime and can't be updated to a new one. But as a rule, you don't have a lot of duplication there. And then you have app images which are, right there, a more pure bundle because it is based on the idea of effectively bundling everything that is not in a conceptual, very minimal desktop system. Then, you know, I also mentioned the not quite app image type things, which are things like Discord and Telegram and there's a bunch of others as well. But those which are the ones where the idea is you go on to the developers website, you download it. Oh, incidentally, we should totally play that later. Super ToxCart is distributed roughly like that, where the idea is you download it from the website. You decompress it somewhere and it then just runs. And you, yeah, but it's the same basic concept as an app image minus the sort of that makes a thing an app image. There's a bunch of little tick boxes basically that you have to run through to make your thing an app image. The closest of these two that would be Telegram, which has literally a binary that you launch. And there's nothing else. It's just the one binary, Discord and Super ToxCart. Different, they've got lumps of stuff mixed in with them. So, but conceptually, they're very similar in that you just download a thing from the website, decompress it if for some reason they've compressed it and then run it. And that's it. Some of them will have auto updates. Some of them don't. Flatpak and Snapcraft have that built into their on client service and app images have the ability to be auto updated, but it is not a guarantee. And then, oh yeah, and of course, if you think app image came out of nowhere just for that, you can go back and find out that it was kind of born out of what was originally called click, not to be confused with click, which became Snapcraft, which is spelled differently. But yeah, so as I was saying, we have, it was a little bit hyperbolic. The absolute state is basically we're good. We're well underway to making something shiny here. We have the open build system. We have KDE's craft, which is this gigantic meta build system thing that you fire off a, effectively you fire off one command and it will build and package anything that KDE has that craft has a, what's that called, a recipe for. And then we have KDE's binary factory, which these days is in part based on craft. And that's really neat. I like that kind of things fitting together really nicely. In particular, when I say binary factory, what I mean is that it is based on that for the Windows builds and for app images they are built using that. I think also Mac OS, not entirely sure, I forgot to look. The Snap and Flatpak packages that the binary factory produce are not based on that, but exactly how that's done also, don't know. And then we have the KDE store, which is getting a lot of work done to it at the moment. And some of you will have noticed this a little bit slow, but that is a part of that work. It's undergoing some massive rewrites on the underlying system, which are having a bit of an effect. But it's there and it's, yeah, it has all of the stuff that we always had on the store. Amongst others, we have binaries on there still. And then we have to discover very own App Store or App Store clients, so to speak, which sort of is a kind of aggregation point for all of these things. And perhaps the most important of all of these is that the bus factors for all of these is improving. The open build system was always pretty good, because it was a commercial effort effectively by OpenSUSA that it was available to the outside world is more of almost a side effect. But also Kraft used to be effectively a one person thing. It is now, there's more people on it now. The same thing with Discover used to basically be one person. There's now a small team there. It's pretty cool. And so, yeah, basically, there are more people getting actively interested in this, which is neat. And so, what I'm suggesting now is that we might just be able to actually pull this off. Of course, back then, I called it social game distribution these days. It would be a federated social software distribution system because of what the bits are. And we now have a better language for it. So, my suggestion is that we have Discover already. We have the KD Store. Specifically, we have the Open Collaboration Services, which what ties us to the store and many other places. Yeah, I know what I said there. And then there is this tiny little thing called the XD Bundle App Installer, which is a little thing that I put together, which has the idea that you can stick stuff on the KD Store in whatever bundle format it happens to be, and the XDG Bundle App Installer can handle that for you. It's just a small tool so that you don't need to really know what format your bundle is. It'll just kind of work. That's the intention. The reality is it's early days. But I thought I would mention it because the promise is of all of this, that we will end up in this situation, that the social game distribution concept of gaming freedom originally intended, which feels pretty neat. Yeah, that was basically what I should have said there. So, in 2021, I'm hoping that we will have that and that it would basically look a bit like this. If you recall the old graphic from 2011, this is basically that, but with modern bits. So, Qt Creator is KDevelop because, yeah, it doesn't make sense to put it basically anywhere else. And KDevelop has a really solid plugin infrastructure. And we don't necessarily need the plugins either because we can kind of just do the thing in KDevelop, but also, yeah, that would be neat. And then integrate that with open desktop. And incidentally, through this thing, if you install it, then Discover already does this. So, yeah, that would be my hope. Just, I thought I'd throw that one in at the end. But the, basically, the states that we are in, in software development feels pretty solid, which is a neat place to be. There is obviously always more work to be done. But, yeah, I'm pretty solid. I'm pretty happy about all this. So, yeah, any questions? Thank you very much, Dan, for this presentation. We do have still some times, and we do have already some questions coming in. I didn't actually notice the time. That's fine. That's fine. That's all right. That's all I might do. Okay, so Pro Bono asks, are you aware of any truly distributed app stores with any, without any central servers, all done in peer to peer, including a way of peer producing trust? That's something you can be interested in. I am not, but that is a really good idea. If we can pull that off, that would be super neat. Possibly a little bit of a big discussion for right now, also, we'd probably need to actually be talking about it. But also, oh, no, these are the outdated slides. There is a pop, which you should totally come and have a chat. It's on, I want to say Thursday, I think. Have I got it here? Just a moment. I do not have a two hand. Yeah, there is a buff. And yeah, oh well. What's the name of the buff, the title? People will find it. Oh, I don't remember the title. It's after, it is after Alice's hosted one about, it's a part of the, all about the app's goal. So it's immediately after his one. Yeah, it seems like that would be a definitely, yeah, let's definitely take, bring that up there. That would be neat. Yeah. Okay, so we'll continue that discussion at the buff then. And I do not see any other questions coming in. So thank you very much, Dan, for presenting and enjoy the rest of the event. Thank you very much.