 I'm super excited about modularity and enabling technology for us working together. I know it's one of those things that's kind of, it's been hard to share the user value and even the packageer value of it, but to me it's really clear that it is something that lets us maintain a package once and build it across multiple bases. And also for Apple and you know, it's a way that we can actually make alternate streams of things available so that if there's a patch that somebody has to a package in RHEL, the currently the rules in Apple are Apple can't override RHEL at all. With the next version of Apple, the rules are going to be that if you have a module, the default stream can't override RHEL, but you can have an alternate stream that can override RHEL packages. You can opt into this. Oh, I'm sorry. So that's a super exciting thing that will let us collaborate in a way we haven't been able to before and will enable that feedback loop that Jim wants because we can actually, it can be more than a patch just sitting there in Bugzilla waiting for somebody to apply it. We can actually build those packages and people can use them and then it'll be a matter of a get a cherry pick to pull that patch in. If most of what you want is the absolute latest and greatest, you like running Fedora. Oh, I was gonna, my God. If you want the latest and greatest, you're used to running Fedora, but you need one module that lives a little bit longer so that you can target some development for RHEL. Maybe you run Fedora with a CentOS or Apple enabled module. If you're primarily doing, you know, long-term stable stuff, you're used to working on CentOS, but you need PHP to just iterate all the time, you run that module from Fedora built on, built against either CentOS or Apple. However, we have that structure. In theory, we could be able to tag a module from Fedora into Apple that runs just fine on CentOS. Possibly. In theory. Implementation detail. I'm not talking static binaries or anything like that or copying across. I'm saying here's one module where we all share the source, build it for these different things so that it runs everywhere. So just kind of rounding that, was your question answered? Okay, so just rounding it out. So there are technical enablers and the increased collaboration, but there's also a social angle. But just sticking, kind of rounding out the technical side. Modularity, specifically stream branching to me is this... It could open up an entire world of difference in the way we do Linux distributions because is there really a difference between the Firefox that Fedora ships and CentOS ships and RHEL ships, at least at a source level? Not really. Is there a value in differentiation? Not really. What about shared libraries? Is Libla SO7 really... Is there some reason that Fedora should have one set of patches and sent a different? I think we just want to kind of increase the quality of each one of those versions of a library that are in some way linked to an ecosystem and have just the highest quality shared library at any major library version. And if we do that, it increases sharing but it pushes all of the problem space to the social side of agreeing to do that together. So the question is, who do you need in your community that you do not have right now and what are you going to do to attract them? So I'm going to let these folks answer that question, but I want to start by kind of setting a base. One of the things that has changed in the last... I believe it's the last year, but it may be slightly longer, is that one of my colleagues, Rich Bowen, is serving as the community counterpart to me in Centos. And one of the things that we have been able to do with the Red Hat support and sponsorship that we get is he and I work very closely together to try and help these communities start a conversation between themselves. And one of our long-term goals is to try and get people to stop having two versions of the exact same meeting where they pretend they didn't just have this conversation an hour ago so they could use a different Zadbat. So that's part of what we're trying to do, because from a community perspective, I look at the communities, and we had the measles slide up earlier, but I look at it as there is a huge group of people in Fedora that Centos would benefit from having their insight. And there is a massive group of Centos people who Fedora would benefit from their insight. And that's the conversation that Rich and I are trying to figure out how to have. And if you haven't been to the Fedora booth, get one of our innovation bags that has both logos on it, because they're awesome. And now I'll let these guys speak to the specific things that they see within the community. And I'm going to let Matthew start. Let Jim start. He sounded like he wanted to. All right. I like where you went with that, because I think that one of the things that within Centos we need the most are developers. Centos as a community has been, no, I'm not going to do the developer, developer, developer chant. We have primarily been a community focused around operations. We pick up CIS admins. We pick up SREs. We don't pick up developers, and we struggle with that, because a lot of times our skill set revolves around, hey, we made 60,000 machines work fairly flawlessly. Thank you, Daddy Shadowman, for some of the support and some of the code. But the developer aspect for, hey, we need a new website designer. We need some software that does this one piece. Now, suddenly we're looking around, but we don't have a bunch of Python developers running around. We don't have some of the different folks that Fedora does for the community or developer aspect. We're mostly an ops shop, so we could benefit from some of the developers that Fedora has and some of the community focus that Fedora has to offset our skill set. And I think that applies in kind of the opposite direction as well. Yes, all of that. I think, like if I could make people magically show up to work on things in Fedora, I think the largest thing I'm worried about right now is some of our, not the engineering and development on the operating system itself part, because I think we've got that working pretty well. We could always use more, but there's a lot of things around like our websites, documentation, the mind share outreach kind of things, connecting people together, making it easier to get started, finding different use cases and talking about them. We need to build up that community more and more, because I think that's one of the things that as the excitement of an operating system, like Linux distros in the 90s, that was a cool thing to be working on if you were a certain set of cool. But it really isn't so much anymore. Like if you want to go make a name for yourself in open source, like I'm going to go work on a Linux distro is quirky. And I would love to make that cool again, and I would like to have the community around that. That's not just the developer community, not just the engineering community, but the more we need that I would like to build up. So Laura's question was about the people that we need, but I think in order to answer that, you have to answer what are the activities that need to be done, and there's kind of two classes of them. There's the kind of driving policy changes, because Fedora has one set of policies that are kind of Fedora centric, and Cent has its, and Rail has its. So there's like creating compatible policies. And then there's just like some technical things that come out of that. So if stream branching is the way that we create a differential between the distributions, then we need to have things like common branch naming semantics and that kind of thing. So really it just comes down to a little bit of technical leadership, a little bit of kind of social leadership creating compassion and empathy between the distributions. There was a bunch of talk about like how it's unclear to a lot of people how there are these interrelates and send us and comes back, and that's in the arguably more simple world where you don't have modules that can like cross compile across all of these different structures. And so if you have a world in which any given module or stream, the terminology is still fuzzy in my head, may be available on the discos, but they come from like one place or the other place. I think one of the concerns I have is that like the enablement here is amazing. If you happen to know the magical version of this module on this stream is available for this thing from this thing, it seems like all the sort of technical underpinnings are now being kind of built, but how do you surface to people who aren't deep into one of these communities, how the fuck you put all of these pieces together in any way to solve your problem? We'll probably know because like I happen to know most of you people like I can call you or email you, but like what if I didn't, how do you get this information how to name the same one? Sure, so let me rephrase, but I'm going to take your question, I'm going to twist it just a little bit. No man, I'm good with that. So here, let me take this. So Laura asked a great question, we talked about technical enablers, we asked who do we need to show up, so what do contributors get out of it, like you do this, but then there's a confusion around modularity, how it works, if you're new to it, so that kind of leads into this question as well. I will say that there's some modularity talks later in the day, so if you want to understand the technical underpinnings, then please attend those. I think Langdon White and Steven Gallagher are doing those talks, and they will be able to answer like how do you know what stream is available and stuff like that. It's not quite as confusing as it sounds because the module build service kind of makes it easier to do. It's not that you have this... That was exaggerating for him. Right, exactly, right. I think your point, underlying that, is what do contributors get out of it, how are they going to know how to participate in things like that? Is that fair? So what are they going to get out of it, how are they going to know how to help? You guys say you have needs, what are they going to get out of it in return? First I want to apologize for using my phone behind his back. I'm also hoping to run this conference and my phone exploded and I needed to know why. So one of the things that I would start with is completely non-technical. If I have my feedback loop, then why do I keep showing up? If my contribution matters, people need to be reading it. I need to see that it goes somewhere. And that is a key thing that I think all of our communities have struggled with at times in various different areas where somebody well-meaning shows up and really does the right thing and gets zero. I mean it's like... Even the crickets are actually gone, you get like their out-of-office message. So that is a key thing that I think that we need to drive here and I wanted to emphasize and apologize for my phone win. So I think it just kind of goes to the question of why do you want a community in the first place? If you're participating in one, if we can create some sort of feedback loop, if we can create some sharing, you're actually just expanding the potential pool of community contributors. So if you want a community, if you want feedback, if you want patches, if you want bug fixes, if you want interaction with the greater world, then I think we're better united than is three independent, completely independent, disassociated entities. It's disingenuous... It's disingenuous to think of us as three separate communities to begin with. I mean, how many people here have Fedora on a laptop right now? From those people who SSH is to ascent or rail box to do work. Alright, we're all using it, we're all overlap. There's a pretty significant Venn diagram of community going on here. So if we stop pretending that we're all separate and we start sharing, that makes things a little better and a little easier. So we don't have just one person trying to throw a patch into Fedora or into... Quick follow-on question. Do we have any package maintainers in here? Alright, I wanted you to keep your hand up if you maintain packages in two distributions. So there's four total. So rail, sentos, Apple, Fedora, two. Alright, we still have about half the hands up, three. Still have a few hands up, so four. Alright, nobody does four, but there's a good chunk to do three. Most people that do one do two also. But treating it as two different things means you have two different policy sets to keep track of, schedules, all this other stuff that... It's just kind of wasted administrative stuff. We don't do this for administration. We want to hack on code. We want to do cool stuff. And to touch on one piece from your question, having one central git structure that builds across everything except rail kind of makes things a bit simpler as well to go here for sentos, go here for Fedora, putting it all in one basket, unifying it, and then as a side effect of that, spreading it out geographically so we can get some better performance and you're not just tied to one specific thing. Oh, Phoenix is offline. Great, I'm stuck. Now, we can have a split between Phoenix, we can have a split between Raleigh, we can put it a couple other places once we start getting that in. We could absolutely kind of possibly make that happen. All right. Matthew, you want to talk to it all? You're good? Okay. So I actually have one more question, but we're about 10 minutes before the end of the session. I want to make sure there's time for any questions you guys have. So, questions. Raise your hand if you think this is crazy and we're out of our minds. Okay. Keep your hands up, though, if crazy is why you want to be part of it. Sweet. Yeah. All right. That's cool. That's cool. So nobody has any questions because I do have one more for this group and they have no idea what it is. Well, now we want to know what the question is. Yeah, go for it. So the question was, when do we think the shared CentOS and Fedora Disguiet repo will see the light of day? That's something that I legitimately cannot answer. The CentOS work for that is mostly done apart from some final sign off. The Fedora work that is mostly done apart from some final sign off. The problem is the Rails source code pushes directly into our Git structure. That's outside of our control and as part of the new technology or as part of this new system, we had to make a couple of tweaks to have that happen. And when we went to the internal folks for Red Hat who were dealing with that, they looked at us and said, but I have this list of product things I have to happen to make real eight beta an actual thing and get in line. So I don't know what the timetable looks like for that. And I can add just a little bit of that. So how many of you have tried the beta, real eight beta? So that's a good portion. Yay. Thanks. That's what I work on. So thanks. So in there, obviously we have modules, right? And so as part of distributing the source, it's a drastic difference from how we ship the source to CentOS for REL7 because now you can't just push the latest NVR of the RPMs because you have multiple streams. And so there's actually code that has to be written on the internal side to get the source delivery for the streams correct so they don't overwrite each other. And the teams that were responsible for doing that were also the teams responsible for getting the beta out the door. All right, cool. Good question. Any other questions? What are you guys going to do when... What are we going to do when Red Hat switches to Debs in REL9? My answer to that question is we'll be perfectly prepared because all these communities will have switched before that. Oh. That's right. We're not. We're going to go package-less. It'll be a new server-less. It's package-less, right? In JSON. In JSON. No, it'll be something else. So Slackware again? Yeah, Slackware. Big old circle. Okay, any other questions? All right. It's a message. I use that as a blanket statement. Sorry, Jim. So the question was... It applies. Do we need infrastructure engineers and not necessarily packages? And I actually think the answer is no. We have a lot of infrastructure engineers. Jim employs some of them. Paul Freels, who's not here, employs another set of them. Mike employs all of them, which is kind of funny. So there's definitely... Yeah, so we talked about website work, scripts and stuff like that. Yeah, so we have lots of great packages and we're always happy to have more of them. And we have fantastic, amazing infrastructure people and we're always happy to have more of them. And in fact, one of my big requests of the Mike employed individuals has been make it easier for people who don't work for Mike to help you as well. But the other side of this is that, yeah, documentation, websites, but also people who want to show up and make more measles. Because quite frankly, there's an audience of people who want to go help llama farmers and we'd like to be their OS of choice because we know that we can deliver the value over time for the llama farming community. And we need those folks to be able to show up and be successful even if their primary skill set involves determining the gender of a llama. Okay, how many people in the audience maintain a package? We had hands up for that. How many people in the audience write documentation? You don't count. How many of those people are lying? Yeah. That's the real question. Legitimately, we do have a documentation shortfall and right now if you pull up Google and you start looking for documentation for I want to do this on Linux on a laptop, you get Arch, you get Arch as Wiki. It's good information that's there, but you don't get the Fedora documentation. You don't get the Rail documentation. That's a problem where we've got a weak spot because we've been focused kind of inside and focusing on the tooling and making the tooling and the packaging fantastic, but broader community, bigger picture, we need the documentation. That draws people in. I think that's absolutely true. I think the purpose of this panel, the purpose of this talk originally is that we need people to start buying into change. We're not trying to force change because it's cool and new and we want to reinvent the world. We're trying to force change because we think we can do better. A lot of the communities and a lot of interaction we have hasn't changed, as Matthew said, in a very long time. That's kind of what... If you take away anything from any of this conversation, I would hope that it's, trying to do something that makes collaboration, feedback, and your actual engineering jobs if you work across these distros easier, even if it's going to be harder up front. Any other questions? We have about four minutes left, so we're going to move on to this one. This kind of gets to that. What happens if none of this happens, in your opinion? If we leave this room today and everybody says those guys are all crazy, they're Lord of the Rings fans and we hate them, what are you going to do? What happens? Let me think while somebody else talks. See, I told you, they had not seen these slides. This is fun. I think we fade away into your relevance, basically, because the changes you're talking about, we're not changing just for fun or just to, like, we could do cool new stuff. We're changing because the world is changing and users' needs are changing and what people want out of what we're providing changes. So we need to adapt to that and this is a better structure to adapt to how the world is changing and what our users actually need. So if we are not able to do that, we become a project that is very inward focused and we're only working on the things that the people who are already here are working on and eventually we will all get more and more gray in our veers and then die. We need the next generation to people who are interested in the same kind of problems but in a different way to come on board. I agree with what Matthew said. I would also say proprietary software then succeeds. Whoa, whoa, whoa. Hang on, I want you to elaborate. Because we have been saying in multiple places across multiple open source projects that open source has won, right? And so how do we go from open source has won to if we change nothing, proprietary software succeeds? Yeah, well they thought they had defeated Soron before but he came back, the ring was discovered. Like it doesn't end, right? I mean, we had a head start. We had all of the stuff from System 5, Unix and BSD. Eventually the hole is greater than some of the parts or no, some of the parts are greater than the hole. But in the end, even though distributions are awesome, I love working on operating system distributions. I've done it my entire life. Look at iOS. Look at Android. It came out much later. I'm sure there's a little external on the Android side but there are millions of applications, millions of them. They've had this incredible growth spurt and while Fedora is still growing, Rel is still growing, Census is still growing, it's exponentially smaller. So if we continue to have like one year growth and the rest of the world has exponential growth, eventually our one year growth will plateau and get smaller because making an operating system isn't a thing most people have to do anymore. They get to do applications and stuff. So you won't grow on old phones that is a platform. Right hand embedded light bulbs. Yes. All right, just to point out we have one minute left and I have one very important question left, so hurry up. You know what? Okay, cool. Yeah, all right. I have an answer to this too, and I'm going to try and make it quick. That was an amazing question. I know, but we're going to get to the amazing question. I worry that... So Mike, you did a keynote last year, or maybe it was a year before, where you talked about the Kodak Eastman... It was good. It was good. No, thriller was your thing last year. Anyway, so as quick as I can, Kodak kind of went downhill, right? Because they focused on film and digital cameras came along, right? It kind of goes back to what Brunnan was saying. And I worry that if we do nothing, if we don't pay attention to what's happening, the same thing will happen to us, right? We're going to be continuing to make these really cool film cameras that nobody's using anymore. The key part of that was they became number one in camera sales in 2005. What happened in 2007? The iPhone came out. And then seven years later they turned bankrupt. They weren't ahead. They kind of got ahead and did it. So we took a lot of questions now. Thank you for participation. And here's the last question, guys. If we do this, will you attend next year's DevConf dressed as your Lord of the Ring character? I will totally do that because Aragorn is a badass. I don't ever have to watch it. You've never seen them, have you? I was forced to watch them one day all in sequence and they're better in Klingon because it's terrible. Aw, you guys are no fun. I will watch just about anything else with anyone in the room. You heard it. Am I allowed to bring the axe? Am I allowed to bring the axe? Yes, you can totally bring the axe.