 Hi, this is your something party, and welcome to another episode of TFR newsroom. And today we have with us once again, Rob Hershfield, CEO and co-founder of Reckon. And today we are going to talk about latest announcement by Red Hat. A lot of discussions are going on, a lot of heated debates, a lot of unnecessary hype, but then there is also reality. So first of all, Rob, tell us what is actually going on there. Boy, I've read so many different summaries of what has happened. Um, the, without going into too much of the history of how things go, um, Red Hat, which is the by far dominant enterprise Linux distribution, something called Red Hat Enterprise Linux, or REL, uh, has, Red Hat has, um, been allowing in the community a version of its enterprise Linux distribution that is free and open. So you don't have to pay to get what had been, uh, since for the last year, the, the most recent version of Red Hat Enterprise Linux was available for people to update and download in as a product called Sentos. And, and that, when, when they made that change, it was called Sentos Streams caused a bit of consternation, because a lot of companies depend on that free open version of Red Hat Enterprise Linux to test, modify, run in a lot of cases, their infrastructure. So they, they depend on the fact that it's, it's a, exact what people call a bug for bug copy of this enterprise Linux, but then they don't have to have the subscription. It's actually a very expensive license subscription to get that Enterprise Linux. So it's created a huge ecosystem around it to have access to that, that Sentos system. But what Red Hat had done last year was they had said, you know what, we're not going to keep making all the old versions available. We're only going to allow you to have what I would call the TIP version, the very latest version of that code. So if you want, you know, a one year old version of Sentos or Red Hat, you know, access to the free open Red Hat, you can't do it anymore. We're not going to make those available. The industry responded very vigorously and people created Sentos copies that reflected other versions. So as a consequence of Red Hat saying you can only have the TIP, multiple companies, the two most notable are Rocky, three Rocky, Alma and Oracle all started maintaining versions that had back revs of that distro. So if you wanted an older version, you could go to one of their distributions and get that license or get that code. The change that Red Hat made last week was they stopped publishing all of that source code for Sentos. So while they'd only built the very latest, the TIP or the stream version they were calling it, you could still go and see the older versions. So if Red Hat 8 had a patch to it, you could see how they patched it and then you could build a Rocky 8 or an Alma 8 or an Oracle 8 distribution that would match Red Hat 8. Last week that changed. Last week, they stopped making all of those changes to anything but that very TIP, that stream version available, which meant that in all the other distros, you wouldn't get bug for bug changes to previous releases of Red Hat. Which people might say, I don't care about all that. I just need the latest, but that's not how enterprise works. Nobody releases the very latest code. They all have some historical version of the software. And so what's happened with this change is we no longer have the guarantee and the drift will happen actually pretty fast that these other distributions are exactly the same as Red Hat. So if you are relying on Red Hat 8.1 or even older 7.5 and there's a bug found in that that Red Hat fixes in 7.5, the other distributions actually don't know how that bug was fixed and it could cause behavioral changes in those other distros. It will never show up in CentOS Stream. CentOS Stream might fix the bug, but it might fix it differently than older versions. And that means that all of these other distros, now if they go fix that bug in their previous releases, one they have to do it, which they didn't have to do before. And now there's going to be drift between the standard, the Red Hat Enterprise Linux standard and all of these others. And so that drift is going to magnify over time. And for customers running data centers, depending on, you know, that the confidence of that, that that whole ecosystem now is at strifting. So you can't count on the compatibility between the Enterprise Linux, Red Hat Enterprise Linux version and anything else. Perfect. Thanks for explaining that. Now, I also want to understand if you look at the modern world, most of all, hey, we've done everything on the cloud, so I also want to understand what are the important significance of something like CentOS in today's world or, for example, REL, so that we do understand why folks are worried about these changes. It's a really significant question. And the number of Red Hat like, which for me is going to come back to how the packages are distributed, RPMs versus like Debian is going to use Debs, these Linux distributions, most people don't manage their own OS. Now, the cloud providers do and they will, they want to be compatible with these, with all these sources, these other distributions do, but the ultimate thing that people are packaging here are the RPMs, the packages that go into that Linux. And this is really where people get up in arms and where the concerns is. If you are building a package, an RPM for a distro, and because Red Hat Enterprise Linux is the dominant one, you would target that release and then get the benefit of all these other OSes. They could be versions that they have in the cloud like Amazon Linux, Microsoft is working as Mariner. Oracle has their own, right? There's a whole bunch of different distributions here that are part of how these ecosystems go. And the challenge becomes, if we start having drift in the operating systems, then when you build your RPMs as a target for Red Hat Enterprise Linux 7.5, if there's drift, that RPM might not work in any other distribution, or if you go and use Rocky 7.5 as your source and test against Rocky 7.5 and you're like, this is great, I got my RPM, I'm ready to go to market and you show up at your Red Hat Enterprise Linux customers, you might find that that RPM doesn't work because they're not binary compatible anymore. They have behaviors that you didn't expect. And so what has people alarmed here is the idea not so much that Red Hat is acting commercially and protecting their interests, but that now if I'm going to build any packaging for Linux, I actually now have to account for the variances across the different Linux distributions in a much more granular way. And we already had that with Debian and the Debian Linuxes, right? It was harder to produce packages that worked across all the Debian flavors of Linux. But now with this change, I might now have to be asking people which version of RPM packaging are you using? Because I have to package my Rocky and my Alma Linux and differently than my Amazon Linux differently. And that drift can be very expensive for the software ecosystem to manage. And there's an asterisk with this. We've been putting things in containers a lot more lately. Containers really depend on the kernel. This is not likely to impact the kernel as much. And so, you know, if it might have the effect of pushing the industry even more aggressively towards distribution, agnostic, distribution, agnostic distribution, ways to get your code into the market that don't rely on a distribution. And so containers, things like Go that don't care about the flavor of Linux, particularly much, those might become even more important from a packaging perspective than they have been in the past. Perfect. Since you brought this point, I also want to talk about when you look at Linux market, if you look at just not the, if you're going to destroy watch, there are at least a million distributions there. But if you look at the enterprise, we look at, you know, sleep. Susie Linux is there, of course, canonical. So Bantu is there. Debian is there. And Rel is there. Oracle Linux is also there. But once again, the point comes back to we are not even looking at Arch and Gen2s and Kubuntu and Ubuntu and all those things. But the thing is that a Lamp stack doesn't mean that it will just work across all the distribution. Once you pick a distribution, you kind of get logged into that vendor as well. You get logged into that ecosystem, which kind of is not just because Linux doesn't mean you will just move around very easily. And as you're talking about, folks will start to look at something which is distribution or agnostic. I'm kind of curious why it has happened so far because it kind of is pain to move from Susie to Red Hat to canonical. So Bantu to Debian. What kind of what kind of development you think you will see in this space and do you feel that, hey, maybe this is the right move to push people in that direction? Or you're like, you know, that was never a big problem. Boy, I, you know, Red Hat Enterprise Linux for our enterprise customers in Racken definitely interacts with the largest banks, service providers, gaming, we're across the board and Red Hat Linux dominates the market for Linux because you have the support, you have the reliability, but also because it's had this big ecosystem where the vendors of the, you know, of the customers, the vendor serving my customers know that if they build it for, say, Sentos, then they get the benefit of that bigger market. And I do think it's going to cause, I know it definitely caused Racken to step back and think through how we support those types of Linux flavors and those types of Linux variances. I think it's going to cause a lot of teams in some ways to tie in deeper to their vendors. It's going to cause us to build more walled gardens because the portability between vendors has disappeared a bit. But I already see this as a challenge. Machine learning has a lot of Ubuntu or Debian based work and, you know, that things surface there first. And I already hear from our customers that they are struggling to get that new machine learning pieces into the corporate standard because the Red Hat family does not move as quickly. By design, it doesn't move as quickly. And so, you know, what we're doing here is we're actually making it harder for people who want to move quickly to target Red Hat style distribution than people who want to move. That's the challenge. And so there's a lot of innovation happening here that I think will push people into the Debian releases and the Debian process. It also opens up the possibility that one of these other Red Hat, you know, what had been a Sentos derivative, to step forward and become more of the dominant one in this case. I think that's a much harder thing to do. I think they're going to be fighting Red Hat, you know, every step of the way and Red Hat's going to come in and defend their turf very aggressively. It will, like I said, I think push more people to give up on, you know, packaging except in containers because they don't want to, they really don't want to have that battle. But, and this is critical, most companies could run other Linux's but don't. And there isn't a lot of incentive for an enterprise that has a relationship with Red Hat to maintain multiple Linux relationships. This might be opening up the door for that to happen and for a company to say, you know what, I want another distro and I'll look at that. I haven't seen this have as much hand-wringing for the enterprise customer as it does for the rest of the industry that is trying to be part of this ecosystem. And that's sort of the observation I have today. I had the same observation about VMware a year ago and it took a year and then all of a sudden enterprises started waking up and being being very concerned about it. So there hasn't been a triggering event yet that causes an enterprise to really feel threatened by this move. But we haven't had time for software to only be available in Rocky or only in Alma or only in Oracle Linux in a way that says I can't support you if you're on Red Hat. Enterprise customers are not used to hearing that phrase. And this change for the first time in, boy, my experience in the industry, we might be entering a place where people say if you're using Red Hat Enterprise Linux that you can't get support for software on it because it's not as open or it's not as available as these other distros. Assuming they can figure out how to create a shared repo where Alma, Rocky, Oracle, you know, and all these other Linuxes, if they can figure out how to be bug for bug compatible between each other, then people will move to the multi-vendor version and we, you know, that will be a seismic shake when people start saying I can't support you on Red Hat but I could support you on something else. That, that conversation has not been, that phrase has not been widely heard. It's usually been the other direction. With this change, Red, and if the industry can respond, Red Hat might open them up to having the experience that Sousa and Canonical have in market. And I'll tell you, it's, you know, that's, that's not a bad thing necessarily. I don't want to have to support tons of different Linux distributions, but I sort of already do. And so that's, that's baked in. You know, having a little bit more multi-vendor choice and variety in here is potentially good for the market. What does that mean for REC and, and of course I talked to Rocky Linux yesterday. And I mean, of course, there are a couple of options that they have so that the users, because next year I think CentOS is reaching end of life, the last CentOS. So that will going to be a big challenge. What does it mean for REC and are you worried or you feel that these communities, as you mentioned, they, they, they are in a good hands. We're still trying to parse through, for, for us, what it, what it means. Last year when, when REC, when CentOS changed the CentOS streams, we migrated away from CentOS as the basis for our discovery image, which is now based on Alma Linux. We don't modify that, but we do, we do package it. And so it became necessary for us to migrate. We just for, for what it's worth, we produce at least four distinctive versions of our discovery image for exactly the reasons I'm talking about. Different distributions have different needs. We have one that's based on Debian for image based deployments, because the tools there favor, you know, Debian packaging. And so, you know, we already sort of bake this into our processes and what we have to support. It adds some expense for us, but it also, you know, mirrors what our customers ask us to do. And we already have to support, you know, flavors of Linux like crazy. So, you know, every flavor of Linux that we support has its own boot environment and its own deployment process. And that type of variation is baked into our system. Very pragmatically, it's better for our business to have more variation, because we abstract that business and help customers cope with it. So from a rack and perspective, you know, bring on the distros. It's, it's a little bit more work for us to support, but it's highly valuable work for us to provide abstraction layers for our customers, so that they don't have to reinvent the wheel every time somebody says, I can't use Alma. I have to use Rocky. Right, that's a very pragmatic benefit to us of having something that abstracts, just like we abstract out Dell, HP, Lenovo, Supermicro, Cisco, right, Raspberry ties, mainframes and everything else in the clouds. You know, the more variation in the market, the the more you need support in addressing that the harder it is for you to lock in and have one choice. And I think from, from a customer perspective, the ability to go at your own yourself and have just one thing keeps getting harder, that keeps going down. But the benefit on the other side is that as you get better at supporting multiple things, your supply chain neutrality, your ability to absorb shocks and supply chain and changes goes way, way up. And so, right, I think ultimately there is some some hardship that customers will feel and adapting to that hardship puts them in a much better commercial position anyway. So it's sort of like taking your vitamins. You're going to, you're going to have to do work to accommodate these changes. But if you had been doing that work all along, you would shrug off the changes. And that's that's sort of this this net in how the market should work. You know, this is very core to Racken's mission and philosophy. We don't believe that the market is served by having, you know, big, megalithic vendors that customers who have, you know, distributed supply chains have choices and how they operate ultimately are better positioned to own their own infrastructure, have control or destiny, have leverage in those relationships. And so from that perspective, you know, things that sort of expose market dominance and a single market player who's trying to exert their influence when those backfire like this may those actually result in a healthier market, a healthier ecosystem for everybody. And so I think that, you know, it's worth discussing. It's worth understanding how these things go. And it definitely, definitely companies should be discussing this and preparing for it. But just like VMware exposing, you know, the acquisition of VMware exposing people to the idea that they maybe were over indexed on a single hypervisor. I think there's there's potential upside for the industry after a couple of years. I was talking to founder of Rock in Linux and they were like, you know, in Jurassic Park, they were saying, you know, life always finds a way. So same thing with the open sources that open source always find a solution. So yes, we as we're talking to them and we talk to you that there are options. I also want to understand as these alternatives do emerge, a lot of enterprise customers, yes, they do love the idea of things are open source. We discussed earlier also, but they also want a throat to choke a commercial vendor because they may not have all the resources. They don't want to waste their resources in plumbing things. So also talk about the commercial aspect behind these alternatives. So I love the way you're phrasing this and bringing up. The magic with open source is when it's a collaborative environment, right? The thing that I hope to see is not that Rocky Linux or Alma Linux becomes a replacement for Red Hat, but that they actually do what open source communities do, which is collaborate on a shared good, build an ecosystem. And that's that is when that happens in open source, it is magical because it creates collaboration. It creates a place where there is a mutual benefit and an ecosystem gets created. And then I also agree with you very strongly. Enterprises don't have the expertise, the bandwidth, the time of doing that collaboration themselves, right? It doesn't work when it's a million people collaborating or a thousand people collaborating. It works when there's tens of tens of people who are really at the core of governance, right? Some people would say there can only be one. But at the end of the day, you need a core cadre of people who really understand what's going on to collaborate and run it and then a pyramid effect of downstream people who benefit from that and pay into the ecosystem. And so it would be very exciting for me to see a companies that actually can shop for the commercial distribution and the support they want, that they can put their licensing and monetary dollars behind some of these distribution companies that then would still collaborate around how the distribution works across multiple vendors. That would be an amazing change in the market. It would create long lasting benefits here for that type of work. If the commercial aspects were driving us to collaborate around an enterprise distribution of Linux, we could spend another hour talking about why that's hard and what commercial support and what support actually looks like and why it's such a challenge to maintain a distribution in production. And hat tip to Red Hat for having done that work for so long. It is hard work. It is expensive work. And I would love to see us be even more open in how that work gets done. So opportunities here definitely. And it is fun, especially as somebody who is not trying to be the one fighting for what that new distribution should look like. I'm more of an observer here with dealing with the consequences of those decisions. It is really remarkable to watch and the community come together and rally around what they want to happen. And we'll watch how that goes. Rob, thank you so much for taking time out today and talk about this very sensitive, very controversial topic. But I'm actually happy that we looked at the positive side of it, the solution side of it and what is happening. So thanks for all those insights and I would love to chat with you again. Thank you. I'm looking forward to it. Thanks.