 in person and see all of you and thank you so much for being here. So with that we will invite our next keynote speaker up to the stage this morning for the talk What Does Red Hat Want? This is from Brian Exelbeard. So Brian enjoys a good beer, a nice coffee, and a rousing conversation about taxation. Born in the U.S., he now lives with his partner and daughter, Inburno, in the Czech Republic. His focus is on family, walks on artisanal bread, and reading long form articles. By night he tinkers with his thousands of spreadsheets and occasionally works on projects that are often glue code or the interstitial pieces that fill the spaces between systems. By day he is the real business strategist at Red Hat. Welcome Brian Exelbeard to the stage. It's true about the tax conversation at dinner last night. Very very passionate, exciting thing about how taxes have done. Yeah I'm realizing that wherever he got this bio from probably needs a slight update but yeah let's go taxes. I have no slides. No slides. Thank you. I would like you to, please. So I'll try the handheld mic, we'll see how that works. If I need to grip the podium, we'll bounce as needed. I guess I should start by saying that there are no slides, that is not a mistake. There's a lot of reasons for that. If we have Q&A you can ask why. So it's great to be back at Flock. This is my first Flock's actually since 2018, not 2019. 2018 also happens to be the last Flock that I helped plan. I didn't get to 2019 in Budapest because my daughter had just been born and I like all of you but I really love her and when she was only a few months old I wanted to spend more days with her than with you, nothing personal. If I did have slides I would spend the next 10 minutes showing you pictures of the most beautiful child you have ever seen. Me for all of you, she is here in Ireland at this event and she hopes to come to game night tonight and she invites all of you, she told me this this morning to come and play Unicorn Glitter Luck with her, which is a cooperative game that my partner tells me is also a metaphor for software development. This is also great to be at a Sentos Connect. My understanding is this is actually the second event to carry that name. You'll notice a theme here. I also missed the previous Sentos Connect that was in Brussels earlier this year. This time it wasn't my daughter though, it was an airline. I had been doing some personal travel right before this and they canceled my flight home. So they trapped me on the beautiful island of Madeira for a week. So I was trapped in paradise, literally. And if I had slides I would be showing you pictures of me being very, very grumpy in paradise. My understanding is that someone plans to circulate one of those pictures. So good luck. That is not a badge but it could be useful. There's also a picture of me in cat ear headphones because I was trying to work with all of the equipment I had, including my daughter's headphones. Now, there's some debate about whether speakers should introduce themselves at the beginning of a talk or at the end of a talk. And either all of you got way fitter and way more beautiful or there's a lot of new faces in the crowd. So I'm gonna go with the beginning of the talk. I am Brian Exelbeard and today I'm a technical business strategist for Red Hat Enterprise Linux and the REL business unit. I focus on what REL should be doing in like 18 to 36 months. So way out there. My specific area of focus is on upstream communities, developers and something that we call the unpaid Linux market. And as a part of this work, I happen to work directly with the CentOS project as I sit on the CentOS board as the Red Hat liaison to that project. Prior to this, I was the Fcake, the Fedora Community Action and Impact Coordinator. And that's why I had the privilege of planning Flock 2018 in Dresden. But 2019, this role had passed to Marie Norden and now it's being held by Justin wherever he has run off to. And they are both doing amazing jobs way better than I ever could have. This talk, it has a bit of a history. It's not always a keynote, that's unusual. But traditionally Flock, I should say Red Hat has shown up to Flock. And the VP of Platform Engineering would usually stand up and tell Fedorans what Red Hat was thinking. And when my role was created, they gave the talk to me. This is also the first time that this talk has ever been delivered to the CentOS project. There's a little bit of debate on that, but I haven't been able to find any actual evidence of this talk having been given to the CentOS project. And because of that, I'm gonna spend a little more time on CentOS project concerns, because a lot of Fedorans have heard variants of this talk over the years. And as for the title, well, it is what it is. The talk has always been called the what does Red Hat want talk. And so for tradition's sake, I didn't change it. But I've tried to play with the format over the last few years, and I think you'll see that I've done that again. So before I get into that, I'd like to do what someone in my management chain, Gunnar Helixson, calls some table setting. So let me start with this. I work for Red Hat, and I am here talking on behalf of Red Hat. And that means that I am biased. I like RHEL, I like the outputs of the Fedor and the CentOS projects. Everything else is fourth place at best. At Red Hat, we view operating systems through the lens of the problems that the customers, potential customers, and partners face in the markets that we wanna serve. We're cautious in what we say and in what we promise. Because we expect to be held to those promises and we expect to have to back them up. So we don't casually use words like production or casually try to predict the future. And so with that having been said to kind of give you a frame of reference for where I'm talking from, I wanna start by comparing a few things. I wanna compare code and community. To paraphrase my friend Matthew Miller, Fedora Linux is an operating system. It's bits. In Fedora, it's a reference to the Fedora project, which is the community, and that's people. And I'm noticing more and more that people are using the language of community to talk about bits. For example, I'm seeing a lot of conversation about CentOS Stream, which is bits. And then someone tries to conclude by making a conclusion about the CentOS project, which is people. That's a problem. Something else that I've been noticing is that there's a lot of confusion about companies and communities. Especially when the community project is sponsored by a company. And this is something else that comes up a lot when Red Hat's talked about. Because we sponsor a lot of projects. And I'm seeing that some of our new enterprise Linux friends, they're having this same challenge too. So we need to think about the difference in those. You see, done right, and I do think Red Hat does this right. The community is held at arm's length. The community has the independence to be able to have a separate opinion on the same things that the company has. It means that they have agency, that ability to have an independent viewpoint or opinion. And I want to talk about agency for a minute, because it's a very critical topic. Agency is that ability to act independently, and it is very important. When agency is denied, you will find that actors get carried along a path that they didn't choose. An open source is all about agency. The four essential freedoms of free software are about ensuring that users have agency. Forking is an expression of agency. Special interest groups are SIGs, working groups, spins and labs. These can all be expressions of agency. And Red Hat strongly believes in agency. When Red Hatters go to work in open source projects, they have agency. They're expected to act in the best interests of the project. They have things they want to do, for sure. But they have that agency to go and do it in the way that is best for that community, not just best for Red Hat. And that agency, it shows up in the community projects that we sponsor. Both the Fedora Project and the Centos Project have governing bodies that are set up to govern through consensus. Red Hat doesn't have a magic veto here. Both projects have someone who's in a dual role. That person represents Red Hat to the project and represents the project inside of Red Hat. Now in the Fedora Project, that person is Matthew Miller. I'm not sure where he has gone. But that person is Matthew. And in the Centos Project, that person is me and my role as the Red Hat liaison. We both have the ability to share Red Hat's viewpoint to the project. And if necessary, to vote against a decision on behalf of Red Hat. But we don't have a veto power. Because these communities govern through consensus, any governing board member can stop anything. And so the agency that I'm talking about here that exists for these projects, it's demonstrated actually by how infrequently Red Hat has anything to say. And how we haven't acted to deny consensus. Now Matthew is very active in Fedora Project governance. But he has almost never had to speak as Red Hat. And if you look at the Fedora Council's decisions, you'll find that they're almost all unanimous consensus, but all by consensus. And in the Centos Project, you can see that agency very directly because there's a liaison. For those of you who know me personally, you know that I like to talk, often about taxation. But if you go to a Centos Project board meeting, you will find that I say very, very little. And that is because there I speak as Red Hat, and Red Hat doesn't have a lot of opinions. And we haven't needed to deny consensus. The Fedora Project and the Centos Project have agency. There is not an interlocking governance structure that is shared with its corporate sponsors. And while the projects may at times have a significant number of Red Haters in them, and in their governance in particular, it isn't because this is a requirement. It's because those Red Haters are passionate about the community and the community has recognized this. And they've selected those Red Haters through whatever the process that each project uses to select members of its leadership. They're not being selected because they represent or are acting on behalf of Red Hat. To put a very fine point on this, there are several Linux projects where the CEO of a company is also the project leader, and I like Matthew a lot. And he keeps looking up every time I say his name, which is great. He is a distinguished engineer at Red Hat. And I really believe he deserves this title, but he is not the CEO of Red Hat. And you have a lot of agency. You have the agency to start or join a SIG. You can build a new spin, you can land your code, you can go build a user base and bring them with you. And you should feel confident and safe in your ability to inspire and influence people and know that your work will help many. And I think the real message for this part of this is, if you think you're blocked by Red Hat somehow, come talk to me. I will be very happy to remind you that you're not, because you have agency. Now, before I tell you what Red Hat wants, I do want to spend just a minute talking about CentOS Stream in particular. So the CentOS project is a community, and CentOS Stream is a code base. And people need to stop confusing that. Success for the CentOS project is not measured solely on CentOS Stream. In fact, from my perspective, the SIGs are really the manifestation of a lot of the CentOS project's success. And a lot of this comes about because of the way CentOS Stream is structured. Specifically, it's maintainer model. It's all Red Hat by design. So anyone can contribute or propose a change to the CentOS Stream code base. And those changes get made subject to the agreements of the maintainers. And at Red Hat, we've been very consistent in describing it this way. You can propose a change, the maintainers will review the change. So the real question is, why is it like this in terms of the Red Hat only maintainership? And it's because Red Hat conceived of CentOS Stream for several reasons. And the two that we talk about the most are, that we wanted a place that we could open up minor release contribution and development for RHEL to a broad non-Red Hat audience in an accessible way. This is very much like what we do with major release RHEL development in the Fedora project. Also, we wanted to further enable participation for our open source ecosystem partners. And we've been consistent in describing our goals with CentOS Stream this way. But I think what people are missing is that at its core, what CentOS Stream really is, is it is an open sourcing of the practice of controlled, limited operating system change. Now that is part of what we deliver as the value of RHEL. And that practice results in a code base that is fantastic to use to build Linux distributions. It makes slow and deliberate changes only after extensive testing and a lot of contemplation. And this is why you may see contributions get rejected. You see, if that contribution isn't required by RHEL, then that contribution isn't needed in the operating system. You have to have a basis for accepting contributions and this is the one that we chose. But what if you need that change? Well, this goes back to the agency. You see, that's where SIGs come in. SIGs can build their own Linux distributions. They can layer software on top of them. And this allows them to focus on their differentiation. It lets them focus on serving a specific set of use cases or a specific audience and they only have to do the work where what they want varies from what a RHEL audience would want. And this is a real model. It's existed long before CentOS Stream did and we're seeing other industry actors and open source actors embrace the idea of building on CentOS Stream, which proves the value of the model and the value of CentOS Stream. But it also shows how refinement and targeting make everything better. It makes each Linux distribution more valuable to its users, because you can't be all things for all people. Another proof point for the value of CentOS Stream is that we use it to build almost all of the approximately 17 different versions of RHEL that we are shipping at any one time. The only ones that we're not building from CentOS Stream are the ones in the RHEL 7 major release family. And we don't do that because there is no CentOS Stream 7 to start from. Now, I've talked a lot about CentOS Stream's code, and I can't talk about the code without also addressing the very complicated view that Red Hat has of CentOS Stream binaries. So remember, Red Hat's cautious. We take CentOS Stream, we pass it through a productization process, and we wrap it with a bunch of promises and agreements and services for delivery to our customers. So we only recommend RHEL be used in production. If you have a RHEL-shaped problem, we're gonna tell you to use RHEL. Now, the converse of that is this. If you come to Red Hat and you go, hey, Red Hat, is this recommended for use in production? We're going to say, okay, well, how does it relate to the promises and agreements that we make with our customers? And if it doesn't match, we're not gonna recommend it. And so this is why you can find a statement on a Red Hat website. Right now, today, it says, CentOS Stream is not designed for production use. And the reason for that is that it doesn't fulfill the specific promises and the specific agreements that we make with our customers. Now, there are a lot of Linux distributions out there. And there are a few that claim to solve the same problems that RHEL does. We think RHEL is the best of all of them, and we don't recommend any of the others for use in production. But this doesn't make them bad operating systems. It just means we're not recommending them. And we're not going to make a promise about them. But I want to be super clear here, because there seems to be a lot of confusion. If you've got a problem that CentOS Stream or Fedora Linux solves, use it. They're both great operating systems. They're operating systems you can trust. I know people who use CentOS Stream personally. They're very, very happy with it. I happened to run Fedora Linux, specifically Fedora Workstation and Fedora IoT on my own devices. It fits the bill for me. I don't need what CentOS Stream or RHEL is offering. I've chosen what meets my needs. And when I have this conversation with folks, inevitably they come back to me and they go, okay, Brian, all this is true. Why did Red Hat put that code in the CentOS project in the first place? And so for CentOS Stream to be successful by our measures, we knew that we needed infrastructure that a successful open source project has. And this really comes down to an investment question. Because we could have stood up whole new infrastructure, but we didn't do that. There was obviously some other choices, and we obviously went with one of them. So why do we do that? Well, it all comes back to this investment. When you invest, you're investing for the future at the cost of not doing something else today. A dollar that I save is a dollar I don't get to spend on craft ice cream. So when we were looking around, we were like, where are we making similar investments? We found two places. We were making an investment in the Fedora project, and we were making an investment in the CentOS project. And we didn't want to stop those investments. We need a place like the Fedora project. It is where innovation and integration meet. And Fedora Linux sits right at that intersection point. And we need a place like the CentOS project. It is where we do work in technologies above the operating system, like virtualization. And it's where a lot of work happens, where well stops. And these folks carry it forward in different and exciting ways. So we had to make a choice. We have infrastructure over here in the Fedora project. We have more infrastructure over here in the CentOS project. What is the value of yet more infrastructure? And the answer is, it's wasted duplication. It's gonna deny me craft ice cream. It's gonna deny resources to better uses. And so it was obvious we needed to co-locate this code. The choice of the CentOS project just made sense. So this brings us to the question, or I should say the major topic today, which is, what does Red Hat want? So let me start by saying this. Red Hat does not show up to a project and say, do this. That is not how open source works. Now you will absolutely find Red Hatters from various teams all over the company who will show up on a project and say, hey, we wanna do this. But they don't get to do it by fiat. They do it the open source way. They will propose that change, they'll discuss that change. They'll make that change safe for people to consume in the community. And then they will do the heavy lifting to land that change. Those are not the teams or the themes that I wanna talk about today. So I wanna go back similar to my CentOS stream comments and tell you that this is really an investment question. So we're making an investment in these projects to achieve some goals. And here are some of those goals. And I wanna be clear, these goals apply equally to both the Fedora project and the CentOS project. We wanna see fantastic open source communities. This means you're growing, you're active, you're vibrant. There are places where Red Hatters can go to engage the open source way. And we know that a part of having functioning great open source communities are that people are using your outputs. And so we wanna see your outputs be specific. We want you to know who do you wanna serve, why do you wanna serve them, and how do you plan to serve them? We want the projects to have a voice. Be you, Red Hat is not gonna be your proxy when you choose not to talk. And we're not gonna show up and tell you what to do or what to say. We want you to fill in the white space in Enterprise Linux. White space here is a reference to all that place that, like it's in the background, it never seems to get looked at. And so an example of this is actually in the desktop operating system space. Red Hat and REL are deliberately not in that market. We chose to exit that market, we're not there. We do offer a workstation. Workstations are very specific kinds of hardware, doing very specific kinds of work, not general purpose desktops. The very confusingly named Fedora workstation is a fantastic desktop. And it is doing a very good job of filling that white space in Enterprise Linux. Related to that, we'd like to see cross-pollination between the projects and within the projects. That could be the projects working together themselves. It could be SIGs working together. We wanna see you connect yourself where it makes sense. We wanna be able to realize flows like somebody needing to make a contribution to Fedora Linux, even though Fedora Linux doesn't meet their consumption needs. And then consuming that contribution through either CentOS Stream or REL. Now, I've talked some about what Red Hat wants. Inevitably, someone will ask in the Q&A, is there anything Red Hat doesn't want? Well, yes, yes there is. Red Hat does not actually wanna monetize the entire market of Linux consumers. We're not interested in that. We know that there are people who do not ever wanna pay Red Hat or may not ever wanna pay for Linux. And that's great, good for you, have a nice day. And I wanna be clear that within the market of folks that we do not wanna monetize, there's a significant number of people who just don't want the things that REL promises and delivers. If you don't need REL, we're not gonna sell you REL. And while I'm talking about this monetization concept, even within the part of the market that we wanna monetize, there are significant segments that we don't want to. And you can see that in the REL developer programs for individual and teams. We're not interested in monetizing what we call the development use case. And there's a related point here. And that is that Red Hat's open source strategy is one of differentiation. Now, people on the internet have suggested that Red Hat might wanna make products out of Fedora Linux or CentOS Stream. And I can't see how that works the way the people on the internet claim. Because if we were to do that, we would have to then go build all brand new communities to stand in front of whatever those things are now called. And the company that just told you that a third infrastructure was not a good investment is not gonna go build yet even more communities that we have to invest in and stand up and help be successful when we already have two amazing communities. Besides, if we really wanted to somehow make one of these things a product, we'd just go create a derivative operating system. Which is exactly what we're telling everybody else that they should go do. It is a model that just works for everybody here. Another thing that we don't wanna see is we don't wanna see the Fedora project or the CentOS project try to deliver the real value and promises. And the reason for this is because we don't see the projects as competition. We wanna make sure it stays that way. But the bigger reason for that is that the projects shouldn't be trying to duplicate each other or Red Hat. Because if there's a legitimate reason why one of the projects feels the need to do that, we have a major problem in our ecosystem and in Enterprise Linux. And we need to go solve that problem, not worry about trying to duplicate each other. So, I apologize, I've lost my place in my notes. While I'm mentioning competitors, we're not worried about competitors. Competitors make a market stronger by bringing differentiated value. And the key here is differentiated value. The operating system is not a commodity, and you can prove this by the number of operating systems that are available for you to use in the market. And so in our view, if someone tries to copy well, without adding any improvement, but just making it cheaper, it harms everyone. This activity creates confusion for consumers who often come away with a false sense of security, cuz they think a promise has been made about the copy that hasn't been made. And when you consider the act of copying, it creates a race to the bottom. It generally starts with a lowering of prices, which is because the copier has an almost zero lower bound for pricing. And all of the costs, they're being born by the thing that's being copied. So this reduces the funding that's available to improve and grow the original. And the response in other industries is to start to cut it. You try to focus it more narrow and more narrow. In software, what you'd see is the code base would become more specialized, and it would meet fewer people's needs. Now as an open source community, we like to think that open source is immune to this. We have the ability to contribute upstream, so none of this is gonna happen for us. But if you start to examine this, what you'll find is, those upstream contributions, they're not the thing being copied. What's being copied is the distribution. And the distribution is an opinionated collection of all of those upstream components. And that opinionation is the differentiation, and that's what's being copied. That opinionation, that differentiation, it's developed by product managers, by market needs. And if you destroy that market, you destroy that ability for that differentiation to exist, and for a strong, healthy market of differentiated offerings to exist. Now what I've outlined today is not new. Over the years, this talk has gone from generalities to specifics and back again. And in every version that I've seen or given, there is an underlying theme here. Rithub really wants to build the best in class enterprise products for the problems that we wanna solve in the markets that we wanna serve. And critically, we wanna do this through an open source development model. This model enables entire ecosystems to grow well beyond what we can directly address, or even have an interest in addressing. And truly amazing communities like the Fedora community and the CentOS community multiply that even more. Now we've stumbled along this journey at times, and every time we do so, we do it publicly. And every time this happens, we learn a lesson, often alongside or along with most of you. But we pick ourselves up, and we keep moving forward. We stand by our decisions as a commercial open source company, but we recognize that these stumbles, they can cause some of you to have doubts or waver in your trust of us. But our commitment to open source and collaboration has never wavered. And when we say we wanna collaborate, we mean it. So as we continue to walk this path, we're gonna listen and learn and adjust. And we hope that you're gonna walk this path with us to continue to improve enterprise Linux and the open source ecosystem every day. I look forward to seeing all of you in the Fedora project and in the CentOS project. Thank you very much. Justin, Matt, thank you. Justin is supposed to tell me if I'm allowed to have questions or not, cuz Matthew talks a lot. So we're at 1030, so we have a coffee break lined up. But I figure we can take one question here cuz I see one hand and then we'll break for coffee from 1030 to 11. The speech was really good, but one thing I'm thinking of is like a commercial open source project. There's been stumbles. When does the business kind of take over? Like what's happened last month where Red Hat and IBM decided to make closed sourced? So what I wanted to ask is when does profits basically take away open source? I don't know, this is the first time I'm asking a question, so. So a couple of clarifications just to make sure that we're, I'm answering the question that was asked. First, the decisions that were taken recently were all taken by Red Hat as an independent entity. IBM had nothing to do with it and Red Hat's code is still open, it is not closed. However, the core of your question seemed to be, and please correct me here if I'm wrong, when does the business drive decision making that from your perspective may or may not have an impact on open source broadly speaking? Yeah. Okay, I think the answer to that is that like all companies, Red Hat is constantly looking at the market and looking at what is going on in the world and we have to make adjustments to how we handle our product. One of the things that we do is that we have an upstream first philosophy at Red Hat, which means that we contribute all of our code as far upstream as it is possible to contribute it. What we find sometimes is that upstream projects are like, they're super excited to take our code and they do it and their output becomes better and the broader community of us, our competitors, everyone is enriched by this contribution that Red Hat has made. In some cases, we show up to upstream projects and they're like, wait, we wrote this? This is like 10 years old, dude, seriously, no. And that's cool too. Oftentimes we visit our friends in Fedora where they're like, no, that's not happening. We do every 13 months, please go away. But eventually we do find a home for it, CentOS Stream being I'll say the home of last resort because ideally things flow into CentOS Stream. And so in that sense, I think that the business can do whatever it wants on the product side and the code is always out there. The code is guaranteed to be available. Anyone can pick up these upstream components and build the opinionated, differentiated Linux distribution of their dreams. There are absolutely going to be decisions that Red Hat has to undertake for its own fiscal well-being. Otherwise, we can't afford to pay all of those developers that are doing all of this contribution into the upstream. But I will say that there's a natural tension in engineering companies in general, which Red Hat is one of. Between engineering led and business led. And I think that all companies face that tension. And most of the time, most people don't notice it because it's like ripples below the ocean. And sure, occasionally sometimes you're like, whoa, what was that? Oh, one of the teams must have just suddenly asserted themselves. But in reality, a lot of it is around the idea of when you're in an engineering led organization, you are focused on solving the problem that you perceive the customers having from the point of view of an engineer. And when you're in a business led organization, you are solving the problem that the customer has from the perspective of what the market is telling you. And if you, I'm not sure whom you work for. You may very well work for Red Hat, I don't know. But if you go talk to your peers in the industry, I think you'll find out that a lot of people sometimes wind up working on a piece of code that they never execute themselves. Or that their execution of it is, for lack of a better way of saying this, they have the hello world level execution. I happen to run a piece of a server virtually that's running Fedora IoT. I would not pretend to be the example of what Fedora IoT is trying to target. So my ideas of how that product should improve personally are not necessarily relevant to the vision of the market that that product's actually trying to serve. And I think that's the tension that you're seeing a lot of here. Thank you all very much. Enjoy coffee, because I know Justin wants to get me off stage. Thank you, Brian. So quick housekeeping. We are going to break for coffee speakers. Just as a note, we will have laptop provided in the room. So you can open up an online link. Or if you have offline slides, you'll need to make sure you have a USB key or some way to put those on the laptop. We do have some, either me or Sean can get you a USB key if you need. Otherwise, we'll be starting back up at 11. There's three rooms upstairs that have three smaller sessions. We'll have a session back here at the main stage. And we'll be back at 11. Enjoy your coffee.