 Hi, this is Yoav Sapil Bhartiya and welcome to another episode of TFI Newsroom and today we have with us once again Greg Kurtzer, founder of Rocket Linux. Greg is great to have you on the show. Thank you so much. It's great to be here. From your perspective, how do you see these changes that it is making? Red Hat for a number of years have released their source code as part of CentoStream for the last couple of years. They have mentioned that in order to increase their efficiency internally, they were not going to be posting all of the rel source code to CentoStream moving forward and that they were going to be making this available specifically to their customers and their customers alone. Now, that obviously creates a number of challenges for anybody who is downstream of Red Hat Enterprise Linux in terms of building an operating system or any solution around that. And so we got hit with that kind of hard. The news was pretty shocking to us and to the community. So we had to figure out how to move forward. What does it mean for you folks, all the downstream that are in a red hat clone? Typically, Red Hat Enterprise Linux is a solution that they charged for. So if you want to get access to that source code or those binaries or that operating system, you pay and you go into a contract with Red Hat. Now, given the fact that most of the code that is part of Red Hat Enterprise Linux is freely available from upstream via the community, this is all open source and they're leveraging that open source code. There's a lot of people out there in the world who do feel as though that, well, everything that is based on that should always continue to remain freely distributed. And so Rocky, Alma, Sentos, Beforehand and other downstream derivatives, we make this source code and we make this platform still available, it's still freely available to everyone in the world. And that's one of the reasons that so many people leverage this is because you have that compatibility and you have that availability again to everybody out there in the community. What does it mean for Rocky Linux? How will you build the future versions of Rocky Linux when Sentos reaches the end of life? The announcements about this were very disruptive to the community. There were a lot of people that were very upset and there was a lot of concern as you can probably imagine. All of a sudden, again, we went from a 20 years of legacy of Sentos being a freely available and compatible version of Red Hat Enterprise Linux. To now all of a sudden, we've gotten news that that's going to be more difficult and a lot of people even said this was now not going to be possible. We went forward and tried to figure out what does this actually mean? And we actually started seeing this a little bit before the announcement. We started seeing that not all of the versions of software that was in Red Hat Enterprise Linux was making its way into Sentos Stream. So we've seen these bugs before happen, so we figured it was just a bug and we waited a little bit and then this announcement came out. So now we knew that it wasn't actually a bug. It was by intention. There's been a number of conversations and opinions that have come out across the internet at this point. And yeah, so long story short, we got very nervous. Our community got very nervous. We looked into what does it actually mean? And we can confirm that not all of the sources in Red Hat Enterprise Linux are available publicly anymore, at least via Sentos Stream, which was how we were supposed to get it. That was how we were asked to get it from Red Hat two, two and a half years ago. So we started looking at options and alternatives. And it didn't take us long to figure out that there's actually multiple different ways that we can continue to get the source code. And so we're actually not concerned that Rocky can continue. This disruption is not going to change anything for our user base or for our community. As a matter of fact, it makes it a little bit more difficult for some of our volunteers and some of our community members to to obtain the source code. But for the most part, we're confident that we can continue moving forward. Again, assuming nothing else changes. What is your plan? There's a couple of different options. One option is, of course, we're going to continue to use Sentos Stream. Another option is Oracle. Oracle Linux does exist. And they are, at least to my knowledge, still releasing their source code. Some of my team members actually reviewed that. And I believe that they found that that was an up potential option as well. But we did want to stay more in alignment with Red Hat first and foremost. So there's two ways that you can obtain the Red Hat source code today. The first way is with the universal base container images, the UVIs. Those are freely available to everybody. You can go download those from Docker or from wherever else. And from that, you can obtain all the binaries for Red Hat Enterprise Linux as that is what it is based on. So there's definitely an option there. Because you can obtain those binaries, you can also obtain that source code. The other option, and this one actually seems more compelling to us because it's a little bit easier to deal with, is using cloud instances. Now, if you were to go to AWS or you go to GCP and obtain a pay-as-you-go type cloud instance for Red Hat Enterprise Linux, there is no click-through agreement that you need to abide by in terms of limiting the redistribution of that source code. And again, because you can get access to those binaries and you can get access to the source code. So that is one way that we are predominantly going forward on everything that is not in CentOStreme. Oh, and of course, I should also mention, there's always upstream. Like truly upstream, like in the community, you know, above Red Hat. So we do do that in a number of different cases, usually for something called hidden build requirements or hidden dependencies. We will go upstream to download those packages and then build binaries out of that and then we build against those binaries in many cases. So we use numerous ways of getting the source code. But I think the important message here is that we do have complete confidence that this, again, is not changing anything from the Rocky Linux perspective for our community and for our user base. Everything is still moving exactly as it was before, so nothing has actually changed. I mean, of course, we cannot talk about what is Red Hat's motivation, but when things do change in the world, you know, we have seen a lot of companies that change their licenses from fully open source, which is compatible with GanuGPL to something which is not compatible, but because they are worried about cloud players or what do you think is actually happening here? We've seen this a number of times over the last, I'd almost say almost a decade back now. You know, one of the first ones that made a lot of press was MongoDB when they changed their license. And again, it's happened a number of times between then and CentOS and even since then, Elasticsearch changed their license. This is something that I learned from via direct experience. Whenever a company is specifically engaged with open source, it's very difficult for that company to always act in the best interest of the community. It's, you know, decisions about what's going to happen with that open source project are always going to end up happening, you know, kind of in closed meetings within the company and even though, you know, many companies can manage this very, very well, it's a very difficult thing to manage. As a result of that, one of the things that went into, one of the ideas that went into creation of Rocky Linux was to ensure that no single company can ever hold the project hostage. And so we built an organizational structure which is fairly different from many of the other open source foundations and projects that are out there. And we put a lot of thought and consideration into our bylaws and charter to ensure that it's always going to remain completely community centric and not being held hostage by a single company. And at the same time, we're trying to balance the needs of companies and enterprises and organizations that have professional IT individuals because it's their job to make sure that these systems stay up, that they stay maintained and we don't want to make their jobs more difficult. As a matter of fact, we want to help them sleep at night so they're not concerned with what may happen tomorrow. And we want to ensure that we have confidence of stability in terms of what it is we're bringing forth. So there was a lot of things and a lot of considerations that went into the Rocky Enterprise Software Foundation and what we're doing with Rocky Linux that I think really gave it a big advantage and has made it very compelling for a number of professional IT organizations to use Rocky Linux. When you're working on CentOS in the very early age, I think it was called Chaos or something like that. I mean, it's so much time has passed that I don't even remember it. When you're building that at that time and you're looking at because the niche that CentOS filled was kind of the way I look at the whole Debian market, folks who did not want to get into... It's not that they don't want to. There are a lot of reasons where cost can be justified or researched. So many factors why somebody would use Debian or CentOS. When you're building that and when you're working on Rocky Linux, you're like, you know what? The problem was almost the same, the challenge was the same. Of course, the time has changed and the nature has changed. Or you're like, no, we are in a different time now. No, you're exactly right. So a couple points on this. Chaos Linux was a very interesting project because I actually came from Debian. I was a user of Debian beforehand. I joined Department of Energy at Berkeley and they were already standardized on Red Hat and RPM-based Linux distributions. And from there, I was like, well, this is great, but it's not Debian. It should be Debian. It should be community. And even back then, I was kind of nervous about a single company kind of running and leading the entire direction of open source. Of course, I had a lot of faith in it. I mean, Red Hat has done remarkably well by the community for decades now. So there was faith in that. But at the same token, I really wanted to see a community RPM distribution of Linux. So I created Chaos Linux. Now, as part of that, we also decided that we wanted to try to maintain compatibility quite a bit with Red Hat Enterprise Linux. So we actually used many of the base kind of foundation libraries like GLIB-C and et cetera to make sure that we were building compatibility and getting some of the compatibility there. So we had this idea of a core operating system and then everything on top of it. That core operating system, we were kind of leveraging Red Hat Linux at the time before Red Hat Enterprise Linux. And so when they end of life to Red Hat Linux, which was freely available and then moved to Red Hat Enterprise Linux, it left us without a direct solution there. So CentOS was born. Now, there was many different pieces of CentOS which we immediately identified we needed to solve and we needed to build out. And by the way, I just want to mention, like CentOS was not the first doing this. That was another distribution called White Box Enterprise Linux. But we came along and we were like, this is something that we need. So we started building it up. Now, there were a lot of lessons learned, a lot of lessons learned, both for Chaos Linux as well as CentOS. The first version of CentOS, by the way, was called Chaos EL to indicate that it was a little bit different than what we were initially doing with Chaos Linux. But the goals were fairly different, right? One was a new operating system that had a similar base and the other one was a whole different operating system. But again, the point is, is that there was a lot of overlap and a lot of lessons learned. And we took those lessons learned and we later in time fast forward, that was one of the reasons why I've thought that I might be a good person to help to create the next version. Now that CentOS is end of life, a lot of those lessons learned from early on are still applicable and they're still important. And that was one of the reasons why I kind of stood up and raised my hand and said, I'm interested in doing this if anyone else is interested in joining me. And that's when we got about 10,000 people from the community join in. Now, specifically, a long story short, going back to your question. Yes, there were a lot of things that were very similar in terms of what we saw then and what is happening even now. And what I will just kind of end with on this question is, the open source community is remarkable. The things that fire up the open source community are changes that hurt or harm or make things more difficult or create pain for individuals. And when this happens, it empowers the open source community. It fuels the open source community to such a massive event that when we started Rocky, we had 10,000 plus people join in like a month and a half. Like it was insane watching how big that and how fastly that's quickly that scaled up. And now we're seeing exactly the same thing. Red Hat changed some of their, some of the model of how they're operating it created pain and created concern. And all of a sudden open source community got fueled again and empowered. And again, we're seeing a huge amount of interest, a huge amount of uptake in what it is we're doing and support of this vision that open source should always be freely available, freely accessible and really for and by the community. Of course, blog spirit, Twitter words, LinkedIn, things become controversial there. But after listening to you, what I do feel is number one is that open source communities are very, very resourceful. And I have never seen ever where something goes down and open source community will not pitch in to find a solution. And that's the whole point of open source right now, whatever. I mean, Linux creator, Linux kernel, that's the whole point with that, the whole GNU GPL ecosystem there. So first thing is that now there's no, second is also that from Rocky Linux's perspective, I don't see that you folks are worried about things that is guys falling. You have not only a lot of options, but you also laid out some plans also, hey, this is the way we're moving forward. So your user base doesn't have to worry about it. Is that the right summary? If like, hey, if I ask, you know that, oh, right, I'm doing something bad. This is bad is happening. You're like, no, it's just, you know, some changes, something happening in the industry. They are adjusting themselves. But we're also responding in a very positive way. And our users are not at all. They should not be worried at all. First point completely agree with, and I'll just stop there on the first point. Exactly. Second point. There was a lot of fud and hype over the change and a lot of concern. A lot of people were very nervous and for good reason, right? We didn't know what this meant. You know, as a, as a, you know, a fair criticism, I think to Red Hat is their messaging is sometimes a little hard to follow and understand exactly what the outcome of it is. Even after the end of life sent us, many people did not understand what stream was to become and what the intention was behind stream until we actually saw it and it took a year or two of actually doing it to get to that point. So I'd like to see some of the messaging being a little bit more straightforward and understandable. I think some of the Red Hat members and Red Hat team members have blogged on it and have actually done a better job explaining it than the official, the official announcements. But with that being said, there was so much concern. There was so much nervousness. I just want to encourage people like go to TheRockyLinux.org website and if there is something that is catastrophic, I promise we will post it. We will let you know. We will be transparent. Join our Mattermost chat. We will be transparent. But in terms of this and what happened, we have complete confidence at this point that the open source software is here to stay. Nothing is going anywhere and everything is going to continue. There may be some optimizations still to come that we are of course discussing and we've always been discussing. But at the same token, nothing is going to be disrupted by a firm hand of a corporation. Everything is still very stable. And I anticipate that it will continue to be. What lessons we can learn from it at the same time? What advice you would have for other communities who have created a project and they might be potential for an expedition where you're like, you know what? Because I do remember that in the beginning, all the creators or founders say, no, we trust this company very well. Everything is going to be fine. And 10 years later, we're like, oh, okay. So talk about that. I think it's very important to separate community and company. From an open source project perspective, I think open source projects, and again, I kind of touched on this in the past, but open source projects should not be held hostage, controlled or owned by a company. And to fix that, it's a state of mind differentiation. We actually, as companies, like to see more companies be willing to relinquish the source code and relinquish the project into the community and create a level of separation there. When Fedora was first created, there was this idea of the Fedora Foundation. And Red Hat was very active in terms of saying, let's create an open source foundation around Fedora. Now, they went back on that and it's a difficult thing to do. And it's a more difficult thing to control. And I don't know what happened in their meetings behind closed doors on why that didn't happen. But if that was up to the community, I think for sure the community would have wanted a voice of very strong opinion that, yes, that absolutely should be a nonprofit or a separate organization, a foundation that separates it from Red Hat. As of right now, there is no separation with Fedora and Red Hat. There's no separation with Sentos and Red Hat. And I don't mean to create any sort of nervousness. Again, Red Hat has done tremendously well and operated in the best interest of the community around the Fedora project. I think they've done extremely well with that. But again, if you look at the board seats, you're going to find that pretty much everybody there, not necessarily everyone, but pretty close are all members of redhat.com. And again, not to poke Red Hat for this at all, but the separation of community and company actually kind of creates a completely different landscape of who's making the decisions and who has that control. And in that case, the company can get acquired. The company can go into a different direction. The company can change direction. And that forces the company to have ethical business practices that are not holding that project hostage behind a paywall. So separation has what Rocky and the Rocky Enterprise Software Foundation has been about since day one. And that was, again, why we separated from CIQ. When I first did this, honestly, I got to tell you, my first gut feeling was, well, CIQ can fund this and we'll just go run with this. But that's not what the community said they wanted. And you got to listen to the community. So as a company, listen to the community, think about it from the perspective of the community and make sure you're setting up a structure that isn't going to hold that community hostage or stunt the growth of that community simply to hold a semblance of control of it. You don't want your project being open source and name only. You want your project being truly open source. Get the full benefit of being open source. And again, that's what we did with the Rocky Enterprise Software Foundation. What is the importance, significance, place of Rocket Linux? Because the fact is that I sometimes feel that, of course, there is a very booming ecosystem and market there, but outside of that, people don't know. So what is the ideal user base for Rocket Linux? It's changed significantly over the last, I'd say, decade. When most people thought of a system or an operating system, right? The two were just, it was one to one. You buy a piece of hardware, you run an operating system on it. Virtualization started to change this. So you can have one base platform for your hardware, one base operating system, and then you run a series of virtual operating systems on top of it. Containers have really kind of made this, took this to an extreme level, but it also kind of broke apart what it meant to be your operating system. So on the host, you still have a one to one, you've got your base operating system on a single host or on a single cloud instance or single VM, but you still got that one to one mapping. But containers have now pivoted this considerably because when we think of an operating system, especially in Linux, it's kind of easy to think about it in two separate things. You got your kernel space, and this is the hardware interaction layer, right? It used to be called, I don't even know if it's still called this hardware abstraction layer for Windows, but you can think of this as this is the level that interacts with the hardware directly and then provides interfaces to the user space. Now the user space is a second piece. So you got kernel space underneath and you got your user space. The user space is what most people are familiar with in terms of interacting with their operating system. It's your commands, it's your shells, it's your tools, your utilities, your configurations, all of that exists inside of your user space. So again, for many years, the user space and the kernel space also had a one to one mapping. So you had hardware, you had your kernel, then you had your user space. What we've changed recently is now you can have many different user spaces running on top of your kernel space. And the kernel has gotten very good at now kind of creating these virtual partitions and namespaces for each one of these different user spaces. So the operating system and the role of the operating system is absolutely still critically important, but it's changed. And it's changed because of this idea of virtualization first, but now containers. And when we start distributing and start thinking about containers, we start thinking about a level of portability which 10 plus years ago, we weren't thinking of. Now all of a sudden, instead of packaging and distributing RPMs or distributing just binaries and programs, you can actually distribute your entire user space, which includes all of your dependencies, includes everything. And now all of a sudden, people are like, they can be running Debian, Ubuntu, Sousa, Red Hat Enterprise Linux and Rocky all in the same system. And so the operating system has definitely changed quite a bit. And as you start now superimposing this onto cloud, microservices, Kubernetes and other sorts of platforms like that, again, you start getting this effect of how massive and important that operating system is. But it also, it's changed in the fact that they've also become kind of swappable. So a lot of interesting things to be thinking about from the operating system perspective as we continue to move forward. And I'm really interested in one area that I'm personally excited about is the idea of how do we continue to gauge standardization and compatibility between these different levels of the operating system, especially considering now how swappable they're coming. Greg, thank you so much for taking time out today and talk about this important sense you're talking about. I think the takeaway here is that the open source communities are amazing, incredible. And the sky never falls when you are relying on open source technology. We will always find a way. So that is what I might take away from this discussion. Thank you so much. And I would love to chat with you again. Thank you. Thank you Swap. It was a pleasure.