 I am going to walk away from this mic if I do it so that you can't hear me. Everybody should make a loud noise that indicates that I suddenly become silent. That would be very helpful. Welcome to the State of Fedora Talk for 2019. Welcome to Flock. Thank you all for coming here. Here's what I'm going to talk about today. We had a council meeting in December, November last year and had some strategic work we did there, which I want to talk about here. How many people read the blog post that we made after that? Okay. That's like a quarter of the room, which is pretty good. Hopefully, this will be a refresher for you and hopefully, it will not be shocking to everybody else, but that's what I'm talking about. Then I'm going to do my traditional charts. I'm going to talk a little bit about some things that are going on in Fedora that I find interesting. That's going to be hurried and will not be comprehensive. Then I'm going to talk a little bit about the future. How many people are jet lag still? Okay. Awesome. That is good because I'm going to start right in with classwork here. How many people have seen something like this before? All right. Awesome. You've been listening to me maybe. This is a program logic model, which is a thing that comes from the nonprofit world. It's a way of both planning and also evaluating whether the thing you're doing has actual impact on the world. The way it works, you start with your planning over at the right side with the mission and vision and what you want to accomplish in the world. If we're, for example, we're trying to end homelessness in a city, our mission might be and homelessness in the city, and the vision might be something about how everybody is cared for and things like that. Then everything gets more concrete going to the left. The outcomes are things that are measurable change. That might be half of the homeless population is in housing, something or you might want to pick some number that's achievable. These should be things that are something like a three to five-year timeframe usually, something that is a number that you can move, so maybe also 20 percent more affordable housing stock or something like that. Then there's a little squiggly line because those two things are things that you want to happen, but they're not things you can actually do yourself. Everything on the left is more concrete and those are things, so outputs are actually things that you actually do. An output might be if you go the Habitat for Humanity approach, output might be built houses like a number of houses that you've built, or it might be community grants, local developers, banks, or it might be zoning laws change. Those are things, actual results. Then it gets more obvious going to the left, like the activities are the things you have to do that, like build houses or do community organizing, those kind of things. Then resources are what you have to make that happen. If you've seen OKRs, the objectives and key results thing, that's actually a small logic model thing that doesn't quite as fleshed out as this one. I like the big model for programs. OKRs is a nice thing for personal achievements, but it's really the same idea. Since I started in this job, wanted to build one of these for Fedora because it's a thing where we want to see what is the impact of Fedora and we want to be able to organize our resources. That's actually one of the reasons we started on making a new Fedora mission, because when we started to look at the mission that was set in 2012 or so, it was so big and grand. It's a great thing about leading open source in the world, but it was kind of hard to go from what would we do to do that and also make an operating system was not one of the things that occurred to me when I was thinking of what are the things we should do to make that mission come true. Clearly, making an operating system is fundamental to what Fedora does, so we changed that mission a little bit to this, which is in such fine print I can't actually read it there. Basically, we make an operating system and we also make it easy for the community to build solutions for users on that operating system. That's the mission that we've got here. However, we are kind of missing a vision statement. When we worked on that mission before, we were kind of focused on solving this problem of the mission is too broad and we need to have something that we can act on that we're still also bruised about and proud of. So we kind of set aside the vision setting, which I kind of think that we need to fill that in and have something that kind of talks about the world we want to make with Fedora. So this is actually a pitch, it's in disguise. We have elected positions on the Fedora Council. Working on this stuff is one of the main jobs of the Fedora Council. If this interests you even a little bit, if you kind of have an idea for how you want Fedora to change the world, run for the Fedora Council in the next election and come help us do this. We also have kind of some vagueness in the outcome. So this is kind of one of the problems here is it's hard to measure Fedora, for privacy reasons and because we're doing a lot of different messy things. So this is something else we could do some more work on. Obviously I'll show you my charts and graphs later, which is some part of it. But there's a lot of other things that we could measure, that we could probably do better. But we do have these things that are the Fedora objectives that are kind of specific things, each which has its own outcome that is a measurable thing. So those things kind of fit into what we have as the Fedora outcomes. Then the outputs are the things we make and I think these are pretty good. And in a lot of ways, we're actually doing this in the middle, from the middle out. When you do this process, you're really supposed to start with the impact and a green field and work back to what you want to do. Obviously we kind of have outputs and then we go both directions from there, which is just the reality of working with a project that's whatever, 15, 16, 17 years old. So yeah, and then activities, the stuff we actually do, resources of our time, the money we get from various sources, the hardware we have, those kind of things. So in theory, once you have this all done, everything that's a resource flows nicely into the things we do and all the way to the right. And you can kind of go both ways back and forth in a nice, satisfying, neat way that both shows that what you're doing has impact on the mission and also that the mission has all the things it needs to actually be accomplished. And so this is a really useful tool like when I go to, for example, Denise here and say, hey, we need help with this and I can say we need this thing here because look at this line through to the thing we're trying to accomplish in Fedora and then it's a much easier argument to make than just I wish I had this argument, which I also do make sometimes. All right, so to the Fedora Council Hackfest, we kind of went in with that. So we had this mission. We want to make it easy for people to build Fedora solutions in Fedora and the basic problem we went in with is it's too hard. Things are kind of chaotic in Fedora. How do we actually make that mission be a true statement? What can we do to adjust the way Fedora is structured to work on that? And so we came up with basically two major themes. There's a nice blog post, which is now actually in the docs. FedoraProject.org page that kind of goes through this. I encourage you to read, but I'm also going to summarize here. So yeah, the first thing is these objectives. And so I've talked about the objectives before. Objective leads are people who are tasked with driving this to completion and that's actually a part-time council position as well. We have a new thing where these objectives get status updates and dashboard and actually any team in Fedora can talk to Ben Cotton and get your weekly status added there. This is kind of a business-style red, green, yellow, kind of what's the state of this sub-project. And one of the reasons to do this is a lot of times we've had trouble getting good status reads from the objectives, even when there's work going on. And it's kind of hard to do that communication in sync with the Fedora meetings if maybe you're not a full-time red-hatter. And we really wanted this to be open to anybody who wants to have this kind of big impact on improving the project. So we wanted to make it so we can have kind of a more async approach to giving the status outputs. And again, Ben, our program manager is taking care of that. So yeah, here's some examples of some of the objectives that are kind of tied directly to this idea of making it easier to build solutions in Fedora. The minimization effort, which is basically we could, if we start with a smaller Fedora core, then it's easier to build things on top of that. Of course, as I always say, it doesn't mean we're going back to a Fedora core that is a red hat thing. The Fedora core, in this sense, would belongs to all of us. And that's why we're not calling it Fedora core because we don't have that argument, right? But I think that's a pretty exciting thing. The gating stuff, there's a huge amount of talks at this conference about gating and automation and CI that I think will be really interesting. Modularity, it's still a work in progress, of course, but it's still, again, it is for this goal of making it easier to build things that move at different speeds too fast, too slow, kind of the fundamental problem of operating systems. We are very slowly but steadily going to solve that. Again, making it easier to package things in Fedora, packaging is a fundamental activity of the project. And then also, again, going back to the long form of the mission where it says we have platforms for hardware, clouds, and containers, IoT is an area where we didn't really have a very good offering. So launching it in addition is made an objective because we want to make sure we're covering that segment that we hadn't really before, so making the addition part of the thing. So the other thing we worked on was this idea of teams, building blocks, services, and solutions. And we actually went into this with a longer document with a whole lot of jargon and terminology, taking some of the existing jargon with SIGs and working groups and spins and labs and all of these things, and we'd actually come up with a pretty complicated process. And then about halfway through the day, we threw that all away and so we narrowed down the jargon to a smaller things. Basically, in any group in Fedora, whether it's a SIG or a more formal structured working group or any of the things, are basically just a team. And you can call your team whatever seems appropriate for the team. We decided not to have codified hierarchy of different sub-projects in Fedora. But a team is anybody that provides a building block and output that can be used to do other things or services to something else. So for example, these are some teams in Fedora. I think they're all existing, well-established teams. They make something or they do something for somebody else. And then the services that they provide, and I think that's all pretty obvious. So the end goal of that is once you have all of these teams that are providing services and making building blocks, those building blocks can actually be put together to make a solution. This is not a marketing term. We don't want to have a Fedora solutions page somewhere. I think that will probably upset our corporate benefactors among other things. But it's kind of what the idea of what we're actually doing. This is something for end users that addresses a problem they have. And that's kind of, we want the things that Fedora does to actually be useful to people. It's not just an abstract thing where we're building an operating system for ourselves. We want to make sure we're building it for other people because otherwise what's the point of it? So the things that are our traditional additions and labs and spins, those are basically the solutions. And one of the things we highlighted in this is that if you're a team in Fedora, again, this is one of the Debian social contract things I think is important is you can't make somebody else do work because a lot of us are volunteers and even people working for Red Hat are either following a team agenda they have at Red Hat or else they're volunteering on this thing. And just because you want to have something done doesn't necessarily mean that you're going to line up everybody else to do it. So the teams can set what they are going to do and why we would really like teams to kind of advertise. This is what we do and this is how you get services from our team and what kind of levels they will do it for. So we might, for example, if you're a web development team you might say, this is one of Fedora's big offerings we'll prioritize making a nice fancy splash page for you. If somebody comes and Bex is not here but I'll use his favorite example, if you want to make a Fedora for Lama Herders, Lama Farmers that might not be one of our bigger target audiences it's still important to the people who use it but it's not necessarily a gigantic mass market thing. So the web design team might say, okay we can provide you a scaffolding and we don't know anything about Lama Farming so you can fill out what that's going to look like but here's the process, that kind of thing. Again solution, not a marketing term it's just kind of the practical impact of it. So if you looked at the mission statement here one of the things that's a little bit complicated about it and kind of unique is that mission statement kind of looks like it's eating its own tail because we have at this side, Fedora creates this innovative platform for hardware and cloud containers and then that enables software developers and community members to build solutions. So there's kind of a this is, which side are we? It might be, it seems like it might be easier if we say oh we build solutions for users, that's our mission or it might be we create this platform who cares about the users but we kind of wanted to put that all together. An example of that kind of might be some other distribution might say this is our main focus, we make this one thing and if you have a solution for some other problem you can be a downstream of us but you're not really part of the project. In Fedora we want to have a different approach where we all work together no matter you know even if you are addressing the llama herding problem like we would like you to come do that as part of Fedora in Fedora because when we work all together like that it the shared work can be useful to other people and it just kind of builds a nice bigger everybody is friends thing that I like. So to rephrase that the same mission statement basically and putting the teams concept in it teams create this platform when we enable other teams also in Fedora to make the solution. So that's kind of that's the structure we came to and kind of makes I hope makes that eating its own tail mission statement can make more sense about how we want Fedora to work. And so an example that you know for example might be the Python classroom lab which is meant for teaching Python in a classroom. That team makes that solution for that particular use case but also does a lot of work on Python in general that benefits the whole project. So that's an example of a team that kind of exists mainly for that end solution but also has the whole benefit altogether when we do it that way. So yeah back to the overall policy putting all together Fedora as a whole focuses on enabling teams to build solutions. So when someone in marketing right had asked me what's Fedora's user base. I say well it's complicated but Fedora Fedora's user base is really Fedora other Fedora teams like the what is Fedora as a general project like it's for the teams to build solutions. But then the Fedora teams each have their own audience and mission and those kind of things. So it's a multi-level things. Fedora is big and we're basically a portfolio project so we try to address a lot of these different use cases but we also still have some of these big category platform solutions we have Fedora workstation we have Fedora server and these kind of things that hit these areas that we've identified as big strategic things. These are the things that kind of enable that platform through being an end user solution like the work that the desktop team does on all of the things for the GNOME based Fedora workstation benefits all of the desktop Linux's in huge amount of ways. So it's both an enabler and a basic platform to build on. But right now as a project again with the objectives we're focusing on we really need to focus on the things that make the story about we build this operating system and we make this available to people. We need to focus on the things that make that true. So this is one of the things, we focus a lot on the gating and CI kind of things. We haven't focused so much on end user things a lot. That's why the objectives, we kind of had a university outreach objective and it didn't really go anywhere. And part of it is we're not ready for that right now. We've got to get some of these things like our developer outreach, our developer story. We are the best at making this platform story together before we get there. So if some of these things go well, I hope that next flock will be talking about a little bit more about some of the user outreach and those kind of things that we can do. And I want to end this with this part with some of the kind of basic guidelines we came up with teams. One of the things we kind of had, this is something we talked about in the council. When do you need to ask permission to do things? Generally don't. If it's something that's in your area and especially if it's something that could be put back if you accidentally made a mistake, just do the thing in your area. It's not something you need to stop and ask permission for. This is something I often get where people are like, I would do that, but I don't want to post a develop list because people are going to complain and then I will not get anywhere with it. You should post a develop list because there are a lot of people here with a lot of wisdom who can give feedback and input. But people who have feedback and input who which are not involved in the thing are also not able to block you. Just because somebody complains about something doesn't mean that you shouldn't go ahead and experiment with that. But you might want to take their concerns into account especially if it's affecting something they're doing. So communication is important, please do it. I guess that's the thing. Again, teams, right, yeah, if a majority of Fesco say not to do it, then we may have a further conversation. But we also may want to find a place where you can do that thing. So if Fesco says, for example, you should not move the architecture that's the base architecture up to something that only works on new hardware. But some people really want to have a build that only works on that hardware. We should try and find out a way so that both of those things can be accommodated. That's a pretty big one right there. So that one, particularly when it's hard, but there are a lot of things that are smaller where it's like, okay, well, let's find a place to the side where you can do this and make that available to people. And of course, that's very situationally dependent. Again, focus on what you can do in this thing. This is, how could we make this happen? Clearly, you're coming to us with some need or some idea. Let's figure out how to let people's ideas happen rather than saying your idea doesn't work for us, go somewhere else. Because again, I want Fedora to be this big, inviting, experimental area where people can do all these different things. And again, if you're a team and you're like, wow, I'm being asked to do so many different things, like take a look at this not quite filled out mission logic model and see where do these things fit into the current Fedora goals and kind of try and prioritize around those things. I think that will help us overall as a project. One of the tools we have to kind of help with this, we have a site, teams.fedoraproject.org, which is running a hosted version of Tyga. Tyga is an entirely open source project planning Kanban board software. You may find the Kanban features, it's a cards in columns kind of workflow thing. You may find that helpful. It's something that maybe doesn't scale as big as if you are a 20 person team working on some sort of project. I know Lee is not a gigantic fan of this for his team's project work. But it also is a place where if every team has some amount of presence here, we have kind of a live update of which teams are actually active right now. And we try to show the organization of Fedora. We look at all the teams in the Wiki and we've got Wiki pages that are 10 years old and out of date, like there's a Fedora minimization sig, which never actually did anything, but has like a hundred people signed up for it. Adam, who is the objective lead for minimization, didn't even know that it existed. Because it wasn't really, it didn't really exist. And there's no really good way to tell from the Wiki if a team is active. So if everybody has, who is an active team makes a presence on Tyga, anybody with a FAS account can log in and create a project and then if you have to file a ticket to be moved to a top level Fedora than a personal project. But create something like that and show some of your team's activity. I think that will help us kind of have a directory of what the active teams are in Fedora. This is something that I was kind of hoping the hubs project would rest in peace. The hubs project would provide us, but since we don't really have the resources to develop this, this can kind of give us a lightweight view of that kind of active teams. And one of the things I've talked about is a possible intern project. So Tyga has like an activity feed kind of thing. One of the things that would be nice is there's an API for injecting stuff into it. So an intern project might be some tools to take existing things in Fedora, Fed messages, Pagger issues, and things like that and inject them into the feed so that that teams work in other parts of the project becomes visible in this teams thing. So this is an idea, an experiment. We'll see if it works out. If it doesn't, it's a hosted service so it will be very easy for us to turn off, but that's one of the places we want to have teams. All right, thus end the talking about strategy portion of the talk. It is time for some dinosaurs. Probably you're familiar with this already. Fedora doesn't do deep invasive tracking or very much tracking at all of systems. So my knowledge of which systems are installed in the wild comes solely from observing our mirror traffic data and there are a lot of reasons that these numbers are not concrete. Network topology influences it, all sorts of things. There's some work to do some better statistics gathering on DNF and the CoreOS team also has a kind of opt out but on by default metrics gathering system which I think will be interesting to see but that's not hooked up yet. So this is still the same traditional numbers here. This is the mirror stats for the last 10 Fedora releases here so we can see Fedora 30 growing up there. It is kind of leveling off there. It'll be interesting to see if this ends up being a growth release. I think partly rel 8 coming out may have stolen some of the excitement from that and there's a pretty decent theory that every time there's a new rel release people who are like to follow the leading edge concentrate on that release for a little bit but we'll see how the impact of that is. The overall picture here is still general growth. You'll notice there's a little slope down at the end. Every time I give a talk at Flock the slides have a little slope down in the end so I think that's kind of a seasonal thing. I am quite confident that it's going to continue going up there. I also wanted to show the stats for Fedora Apple. Actually we did it out of order. This is the total for Apple, the red line there and the blue line is the total for the Fedora OS mirror stats. So I wanna emphasize the place where we have the biggest user impact in the world is clearly in Apple. So even if you feel like, oh that's something over on the enterprise CentOS-E side of things I encourage you to care about it a little bit because there's a lot of users for whom it's very important. So this is something that I think we've got a lot of we could do more there. And yeah, this slide is just the Apple by versions there. You can see just in time for a rel eight to come out Apple seven is finally beat six. So again, you know enterprise Linux users are somewhat conservative. So that's also worth taking into account. All right, that was all the graphs. I'm gonna show this time because I'm going to run out of time if I do a lot more. I could, I could do another 20 minutes of talking about graphs, but I will not. A lightning talk? Yeah. All right, so I'm going to talk a little bit about some of the things I find interesting going on right now and there are a lot of talks about these things at this conference. Rawhide gating is finally enabled. This is something we've been talking about for, thank you Denise, for a very long time, five years at least, about making Rawhide the development tree something that actually isn't broken all the time something you can use. I remember a Linux weekly news article about this from like 2010. So it's been on our minds for a long time and finally we're doing something about it. So I find this amazing. Thank you everybody who worked on this. It's very cool. Another big effort, this minimization objective. Thank you. Finding a way to define a smaller base operating system for Fedora and making it so that we can have smaller containers and smaller bases for all of these solutions is just the flexibility that having everything neatly organized and not having a lot of baggage that does not spark joy in our minimal containers is gonna bring a lot of flexibility to us. Fedora CoroS has launched. It's been a year and a half since Red Hat acquired that company and so we finally actually have a release out the door of this, our container operating system based on Fedora. I think this is a huge achievement and pretty exciting. I think it's neat that how we could integrate that into the Fedora family. They've kind of brought along some of their own tooling and ideas and kind of a new tool chain for building it that I think we could learn a lot from in the rest of Fedora. There's also ways that we could tie that tool chain into Fedora better. I think right now it's not sending out Fed messages when it would be nice too so that we can kind of get some of the statistics on that. So this is an example of doing some experimentation that we also want to make sure it doesn't just leave floating out as an experiment and we can take the successes from it and integrate it into the way we do other things in the project. Fedora Silver Blue is kind of based on the same RPM OS tree technologies. It's a workstation that is based on these kind of made for the cloud technologies that give us an immutable operating system. This has been the desktop team is working very heavily on and I'm particularly excited about this because I have seen more blog posts and YouTube videos and excitement, your Reddit threads from people not in this room than I have about Fedora for anything for a lot of years. So there's a lot that's scary about this. It makes your desktop system work very differently from people are used to with the traditional Linux desktop operating system. But I think the potential here is so huge that this is something we really should be interested in. And there's a talk on Fedora Toolbox which is a container based way of working on Silver Blue that I think is kind of very interesting. We'll make it so that this is an operating system that's sort of focused on living in a container world and this will give us a desktop offering that we really like we show people this is something different from what you're used to and this is something that will give you tools and an experience that is better for living in the modern computing world. So that's very exciting. Fedora IoT, I mentioned that before. This is an addition made for this use case that we hadn't really covered before. We've had ARM, SPIN kind of things before. But again, this uses that same RPM OS tree technology to provide an experience that actually be used for people out actually running you run this in your home and not have to worry about updating it yourself every six months and will my home automation still work after updating the next version. This uses that container model to deliver that in a way that will be consistent. You can actually use it to do things. I'm particularly excited about this. We have some really big like corporate users who are interested in this. I'm actually very interested in for the home user use case because this is, when I got into computers, I could make an Apple II do just about anything that Apple II could possibly do. Now, my kids using computers, the games and everything they look at is nothing that was developed by one person. Like you can't take a computer and you can't make Fortnite or whatever just yourself in your spare time. Whereas, so we've lost that hands-on computing thing and I think IoT is a place where you can take a little device and you can actually make it control your lights, you can make it control the heating in your house and you can do these kind of home projects that actually your use of computing is something within your hands, in your scale and you can actually do cool things with it. So I think this is an important basically gateway to the next generation of Fedora contributors that we need to make sure we are investing in. Another big thing, I didn't have a cool graphic for this so I just did a screenshot. This is the new Ask Fedora site. It was previously based on Askbot which is a terrible clone of Stack Exchange. We switched to, for a number of reasons that I can talk about in the hallway, Discourse which is an entirely open source web forum kind of platform that we're using a hosted version of and this was really entirely run by people from the Fedora Join SIG who kind of took this and set it up with the different languages and all things and this has been very successful. The traffic is already at the levels where we're maybe needing to consider paying for the next hire hosting plan which is a great problem to have. Yeah, so this is, and this is, if people come to you with Fedora questions and you don't have time to answer them like I often do not, this is a good place to send people to because there's a pretty good community of people who are interested in helping out other people in Fedora and also if you are bored and want to help out people, stop by and find some questions in your area and answer them. On the less optimistic side, year or so ago, Robyduck, Robert Mayer who's been our web team lead for a long time, got a different job and ended up with a lot less spare time to work on Fedora. He's been doing Fedora web stuff for an amazing job for a long time. We are basically without a functional web team in Fedora right now and we've gotten some temporary work from people at Red Hat to do this but Red Hat is not going to fund a web team for us. So this is a team that kind of needs to be rebuilt because you can't be a modern thing without the web at all. So if you're interested in working on web development in Fedora, come talk to me because we need a new team built up around this. All right, I'm gonna need to get some water. I'll just let you read that while I drink. All right, so some of the things that are basically challenges to work on, things that we need to do better, particularly in order to really make this whole thing of people can provide solutions right now to make something that's an output in Fedora, a spin or a container or whatever you wanna make. That is a lot of manual work that goes into this thing called the compose. It's all capital letters, the compose. And I don't know what the time for that compose is right now but it was up to the time where it was like taking, oh, over. What's that? Okay, yeah, so it's down to four and a half hours which is pretty awesome. It was up to like 18 hours and pretty crazy. But even with a shorter compose time, that is almost ability to make two composes in a day which is gonna be huge. One of the problems that we have is this idea of like blocking the release. So every release we have something like where we can either say our artifacts stopped Fedora from being released. So if there's an error in the llama herding distribution we will not release Fedora at all that week which would make a lot of people sad and angry to various degrees. Or we can say, well, sorry llama people, no updates for you until the next six months which of course makes those people sad. And as I said earlier, we want to make sure that everybody who has these solutions is able to do them in Fedora and is treated with value. So an alternate approach would be okay llama people, you are on your own, but here's a push button you can push. You put your parameters in here, hit this button and out will come your llama spin on the Fedora release cycle or the week after or the week, if you're ready two weeks before, why wait? So you could make, maybe for some reason the llama farming cycle is a seasonal thing. So you maybe want to have a new llama farming release every three months. You should be able to do that or maybe once a year because you only need to update things infrequently. So we need to be able to decouple those things. And I think that in order to do this, to do this right, we should do this for everything. All of the outputs in Fedora, from the big things like Fedora Workstation, down to the little things Nero, Fedora and other things, they should all be self-service like this in the same sort of way, even if it turns out that for the big things, the release engineering team, one of the things they provide is, yeah, we shepherd that through, not a llama joke, just. We need a lot more automation in order to do this. A lot of the work we do in Fedora is manual labor that is not really great use of human intelligence. A lot of the packaging we do where we take something that is an upstream package and then we reformat into our packaging format. We're not really adding any value to that at all. There's no reason you'd go for Fedora because our version of this Perl sub-dependency is the better one than the Debian one. At least I hope that's not true, that would be awful. But we've gotta find ways that the human effort we have, and we only have so many people, we wanna make sure that the human effort we have is used to the best amount. Well, we still are able to cope with the exploding amount of open source software out in the world, and this just doesn't scale to humans. So we need to find a better way to do that. We also, as part of automation, we need to move where we do our quality checks, and I think we've been doing some of this, but mostly right now, we check for quality basically at the borders. When a new package comes into Fedora, we do a rigorous package review, and then after you pass the review, the dirty secret is you can do whatever you want to that spec file, and people have, and nothing really stops you. So we need to do some kind of things that make that better. And then the other place is with QA, like we do extensive QA, using other users' passwords requires permission, thank you. All right. We do extensive QA at the Fedora releases, but we don't do QA on update batches and things like that. Again, it's a border check as it leaves the project out to users, we do a check, but we don't do much continuous QA. So again, a CI CD efforts will really help with that. Finally, we've got to do something that would be better about packaging dependencies. In general, people who are interested in, I know some of you are exceptions to this in this room, but in general, people who want to make something available in Fedora want to make an application available, something for end users, and it usually is the case that that package, especially these days, has 300 dependencies, and getting each of those 300 dependencies through individual package review is not a good use of time. And what's worse, if you do what we call the right thing and debundle and get each one of those things through package review, you now end up being the owner of one application you care about and 300 dependencies that you don't give any cares about. But you've told everybody, I'm the maintainer of this. And that lie is not really very helpful because someone else comes along and sees, oh, this is in Fedora, it must be maintained and builds dependencies on it, and it's not a good situation. So we need, I don't know the answer to that, but in a lot of ways, this is a big data problem these days, when there's thousands of dependencies, like there are other ways we can attach this rather than having a human go through and package up those and claim ownership of it even when they don't really own it. So I don't know the answer to that, but that's something we really should work on. Switching, this is actually organized after the first part of the talk. It all comes together in a nice way if you see the whole thing together. But from the teams and building blocks, another thing I talked about, there are a couple things that kind of fall out of this about how we present and market and organize Fedora. One of them is something I've been saying for a while, but which is hard to have it to break. This is just like Red Hat doesn't want you to call Red Hat Enterprise Linux Red Hat. When I was in college, some of my friends would call Microsoft Word Microsoft, drive me crazy, or the thing that comes with Lego, the little thing that says, please do not call our blocks Legos, call them Lego building blocks, this is the same thing. We want Fedora to be, this is Fedora in this room, we're Fedora, we're the project. Fedora operating systems and outputs are Fedora, workstation, Fedora, the Fedora package collection, those kind of things. That's a, I know that's a hard discipline, but if we all start doing it, maybe it will slowly trickle out into the world. And then the other part of that is, like if we want these different artifacts to connect with their audiences, it's okay if we make it be Lometron OS by Fedora, rather than saying Fedora's Lometron OS. You know, if people want to do it the other way around, that's fine, but I think if we go back with these here, you can see both of these have Fedora, and then CoroS is a strong brand. Silver, blue as, it's a little bit less bold there, but kind of the strong brand is the thing. And this is, with these two things is kind of happening naturally. We started out with Fedora, Cloud, Fedora, workstation, Fedora server, these kind of generic descriptors, and we're moving to kind of a branded thing. And I actually asked the IoT edition people to come up with a shiny name for the IoT edition as well, because I think that kind of fits the scheme. Now I've lost where I was. Yeah, so I think that's kind of a shift from how we've marketed things. I know there's a little bit of worry, like is this all gonna fall apart into a kind of chaotic thing where nothing's tied together and everything in its own little fiefdom, maybe. I think that the communication and just the idea that we do want to all work together and even if Fedora is not the front of the name, it all still is Fedora and we're all working together, I think that will help. And I think that branding that way is better than the alternative, which is that Fedora slowly becomes irrelevant to everybody who's not already in this room, in the Fedora world already, where Fedora is a primary value. So I think it allows us to reach out. So that's kind of a change to how we've done things and I'd be interesting to see how that goes, but that's my preference for it. And then finally, I talked about what the vision is and I don't have a vision statement for Fedora yet, but again, run for council, help me work on it. Some things that I know though, the next time there's a docker, the next time someone wants to build Coralas, we want them to be, oh yeah, well Fedora is the obvious place to work on that. We don't want them to say, go off and build their own district from scratch, we want to be the place to do those things. We should find a way, all that open source, all those thousands of packages, Java and Python and Ruby and Node and those things, we should find a place to integrate all of those into something that all works together, even if it doesn't mean repackaging in all our RPMs, or if it does mean repackaging in all our RPMs, make that such a minor detail that nobody even needs to know that that's happening unless they really care. We've got to catch the next generation of developers and sysadmins where they are. Where they are right now is GitHub, so we need to figure that out because we have a very strong open source ethos, you know all the hosted things that I talked about, like those are open source products, they're not even open core, those are like pure open source play companies, which is awesome and I love to support those, but if all of the energy in the world around open source is really kind of in these areas, maybe GitLab is a possibility, but that doesn't really have the network effect, everybody's individual GitLab. GitHub has such a strong network effect that we need to be able to address that. I don't, again, I don't know the answer to that and I don't know how to figure out how to keep true to our freedom foundation and something that really is important to us about making this world where everybody has an open source free software experience, I don't know how to do that, but we need to find an answer to that because we're in trouble if we don't. And finally, this thing where every operating system it moves both too fast and too slow at the same time, it's still a problem, the technologies we're working on with modularity, the container stuff, flat packs, snaps for our friends working on snaps, these things are attempting to work on that, but we don't have it solved yet and I would really like the register headlines to be, wow, Fedora has solved this big problem, that's what I would like to see. So how we get there? It's up to you guys, so let's figure out how to do it together. There are a lot of talks here about automation and modularity and things towards these problems, so I think this will be an exciting good conference. And yeah, thank you everybody.