EPISODE 1688

[INTRO]

[0:00:00] ANNOUNCER: Red Hat Enterprise Linux is a Linux distribution developed by Red Hat for the commercial market. The company recently announced changes to the availability of its source code. In response CIQ, Oracle, and SUSE formed the Open Enterprise Linux Association or OpenELA which aims to provide a consistent, insecure upstream location for Enterprise Linux Distribution sources. 

Wim Coekaerts is Executive Vice President of Software Development at Oracle and he joins the podcast to explain the recent changes in the Linux Enterprise space and discuss the OpenELA and its importance to the Linux ecosystem.

This episode is hosted by Lee Atchison. Lee Atchison is a software architect, author and thought leader on cloud computing and application modernization. His bestselling book, Architecting for Scale, is an essential resource for technical teams looking to maintain high availability and manage risk in their cloud environments. Lee is the host of his podcast, Modern Digital Business, produced for people looking to build and grow their digital business. Listen at mdb.fm. Follow Lee at softwarearchitectureinsights.com and see all his content at leeatchison.com.

[EPISODE]

[0:01:26] LA: Wim, welcome to Software Engineering Daily.

[0:01:28] WC: Thanks. Glad to be here and look forward to the chat.

[0:01:31] LA: Great. Great. So, at a very high level, we'll get into more specifics later. But why don't you start off by just saying what is OpenELA?

[0:01:39] WC: So, in a nutshell, OpenELA is basically at least initially three companies. CIQ, SUSE, and Oracle coming together to create a public workspace to share source code for Enterprise Linux-compatible distributions. That's fundamentally, it's the expectation that we all do similar work and since we do that, or we used to do that independently, now doing this together, and publicly makes it a lot easier for us and for everyone else, as well. So, it's get together, publish source code for Enterprise Linux, and anyone else can go and grab it for free. No membership required.

But having an association around it helps us be a little bit more formalized, so that there's an actual agreement in place. And we show commitment to this, rather than just saying, "Hey, yes, we're going to put some stuff on GitHub, and we might just stop. So, there's really no commitment behind a just project, and that's why a consortium helps and others can then join as well. But fundamentally, it's really just working together to publish source code. That's it.

[0:02:52] LA: So, how did it get started? How did you guys decide to just start working on this? What was the event that got it going?

[0:02:58] WC: So, we started this last year July, June, July, August timeframe when this big Enterprise Linux vendor decided to no longer publicly release source code for Linux, for the distribution. So, we continue - or if you look at it, let's take a step back. So, Oracle provides Oracle Enterprise Linux or Oracle, Linux and then CIQ uses Rocky, and SUSE has a SUSE version of Enterprise Linux for customers and we all do our own thing. We are fully compatible with RHEL and we maintain that compatibility. We provide support for customers, we provide bug fixes, security fixes, and all that stuff. 

So, as part of what we do, source code was always publicly available, at the same time as we release binaries. Then, at some point, access to that source code upstream, so to speak, became an issue. We feel that the source code for the distribution should just be part of it. That's part of the Linux ecosystem, and making that source code only available for subscribers doesn't seem to jive well with the mission of a GPL product, which is what EL is.

We have, using Oracle as the example, we obviously have a large support team. We have a large kernel development team. We have a user space development team. We built the distribution. We provide our trademarks and copyrights and the cute Linux penguin on top, the armored Linux penguin, and we support our customers and we have all the knowledge in-house to continue doing what we need to do with or without the upstream vendor.

Now, in order to do that, we take source code, we take bug fixes, we look at CVEs, we fix these things, and then republish the source code. So, when the upstream vendor made the decision to stop releasing source code, while we continue what we're doing, then SUSE and CIQ as two examples also continue to do what you're doing. We're all going, "Look, we're all doing exactly the same thing in isolation." It makes a lot more sense to join forces, take what we have, and make it publicly available in a central place. Now, one of the reasons to do that was to avoid more fragmentation.

So again, we could all keep doing what we did, but it would be slightly different, and then there's some other vendors out there or not necessarily vendors commercially, but groups, organizations and such that also built a clone of EL. This would create basically six, seven, eight, nine different streams of almost the same, not quite the same. Everyone doing exactly the same amount of work that they used to. So, working together means we have more freedom to focus on things like quality and, and ensuring things are done in an expedited way. But also, fragmentation wasn't really good. One of the things, when we had Oracle started Oracle Linux, one of the things we decided was building a completely new Linux distribution. It was technically - it's not rocket science. It's not hard. It's just work. But what's the advantage of doing something that has a different installer and a different color UI?

Fundamentally, it's Linux, and it's glibc version X to kernel version Y and people want to test something once and not 500 times. So, we decided that, what we wanted to make sure was that customers had choice of support, which fundamentally around these open source projects is really what matters. A customer says, "I want to use open-source products, I want to have the code." But I currently rather pay someone to support me if there's a need for support. But with the option that if I don't like that, then I can keep doing what I'm doing and potentially support it myself. That was why we started with compatibility from day one, day zero, really, back in 2006.

So, we wanted to continue that and in order to continue that, we have to do all this work. The other vendors do the same thing. Now, we just put it in one place. One of the things that's also important to note is that while we have the capability to do this, there are lots of vendors out there that built their own Linux appliances with their own software using CentOS in the past/EL as an embedded Linux platform. So, they're now basically dead in the water, or they were, for a while, because they're not Linux distribution builders, per se, they just need a subset, and they're more focused on their application. This way, we have the ability to provide them and make sure that they have a continued compatible distribution where they don't need to do a lot of work. So, it actually helps a lot -

[0:07:52] LA: A single consistent distribution that works, instead of multiple distributions.

[0:07:58] WC: That's right.

[0:07:59] LA: This is all great. But let's get into a basic question first. I'm sure everyone who's listening is familiar with Linux. But what does enterprise-grade Linux mean? Why is enterprise-grade so important? First, let's talk about from a code standpoint, and then we can talk about support as well. But just from a code standpoint first, what makes Linux enterprise grade versus non-enterprise grade?

[0:08:25] WC: So, one aspect is testing. When a new distribution version is released, or even just new packages are released, there's a large test platform, and everything gets QA'd really well, whether it's installation or runtime, but fundamentally testing is, I would say, one of the top things. Then the second one is rate of change. What ends up happening is that when an Enterprise Linux distribution comes out with a new major version, it starts out somewhat freezing the major package levels of every component in there.

So, when EL 9 comes out, and I'm not going to use the right version number, so I'm just going to make up a version number. But let's say Enterprise Linux 9 is released, and it uses glibc 2.41 as the main version. Now, what will happen is that to the lifetime of EL 9, that version stays the same. That will be 2.41.1, 2.41.10, 2.41.20. So, the minor version will increase because bug fixes happens, security vulnerability fixes happen, some minor changes happen, but otherwise it stays exactly the same. The reason for that is because the APIs need to remain the same. So that there's no issue with an application that's built against that 2.41.0 that it will continue to be the same across the entire lifetime for EL 9. I think that, from a pure code point of view, that's the most important part is maintaining versions, maintaining code compatibility and APIs, and not introduce change that can cause disruption, that can cause hangs or crashes in an application that runs. So, that an enterprise-grade vendor that builds a large application knows that for that lifetime, it will continue to work and they don't have to do new stuff.

For something like the Oracle database as being a big application that runs on Linux, that's absolutely critical. If everyone constantly were to update packages in between, then package update could break the database could break a bank from processing credit card transactions. So, there needs to be stability in terms of versioning.

[0:10:44] LA: Right. And pretty much all enterprise-grade Linux do that. And RHEL was really the - Red Hat Enterprise Linux was the main base for all Enterprise Linux for your versions, for everyone else's version on top of that, until recently. But now, rather than being a base, they're more of a competitor. Is that a fair statement?

[0:11:06] WC: It's an interesting way of putting it. So, I think we've always been competitors, because we compete on support quality. We wanted to make sure that we maintain the same codebase and that's still happening. So, even though these changes happened last spring, last summer, we continue to be fully compatible and that's a high priority for us. We don't want to deviate that. We want to maintain that compatibility. But we still continue to compete on support quality, on how quickly we can address problems if a customer runs into it, having a focus on enterprise software, which is still the same as many years ago, when we started. So, it's important to make compatibility because ISVs don't want to certify in many different versions. If they know that it's the same, they can pick one to certify on, and it will work on all these other derivatives as well and we compete on support quality and cost.

[0:12:03] LA: So, are you saying that OpenELA, even though it's split from RHEL, is really still maintaining backward compatibility with RHEL and all aspects?

[0:12:10] WC: Absolutely.

[0:12:11] LA: Okay.

[0:12:12] WC: So, what we do is, we work together to ensure that when a RHEL update happens, that we will provide the same update and put the source code on OpenELA, on the GitHub repo. But number one priority is provide public source code for the exact same code.

[0:12:33] LA: So, kind of the general process now is Red Hat makes an update, and they make it available to their customers. The APIs are made available, but the source code has not. But an OpenELA will make those same changes to make their version compatible with RHEL, but they make their changes available, open source on the public repository for anyone to have access to. What has changed and what's the differences going on here?

[0:12:58] WC: That's exactly correct. So, source code for RHEL is now available for paying customers and not other people. We make that code available to everyone. Now, one thing to keep in mind also is that when it comes to a Linux distribution, the source code is publicly available, and bug fixes are done typically upstream. So, Linux kernel fixes go to Linux and go into the latest kernel, then they get backported. Bug fixes for glibc and all that stuff, the same thing. It's not like there was any proprietary code in any RHEL or EL or OL. It's all public source code anyway. Now, when something gets backported, then we might have access to source code for a newer version that we then backport to the older version, the same way as what, let's say Red Hat would do. But it's the same code. We have this we have access to the same patches and all that.

[0:13:57] LA: So yes, all the packages that are - all of the changes made to base Linux are available to both you and to Red Hat and everyone else, but seems like there's something that RHEL is doing in there that they don't want to have exposed anymore. Do you know what that is? What is their motivation? Here, I'm asking you, but I am asking you. I am talking to you. So, I'd love your opinion. I know it's just that. But what is it that drove Red Hat to go the direction of more closed source?

[0:14:27] WC: So, yes, I mean, like I said, I can't speak for them so I don't know exactly what happened. But I can tell you the following. We compete for customers. We have been doing that since 2006. So does CIQ and SUSE. There's not that many Enterprise Linux distributions out there that are used in production, and there's not a huge amount of choice. So, we compete on support. We charge X amount, Red Hat charges Y, and CIQ, I don't know what they charge. They put the charge money as well.

Fundamentally, we go to customers and we say, "Hey, if you come to Oracle, then you have all these benefits. We understand enterprises. We understand enterprise customers. We're global. We're in all the different languages. We know back-end databases really well. If you run enterprise apps, our support team knows all this stuff." Red Hat/IBM have their goal and their messages towards customers and so we're competing.

One thing that happened way back when. This is sort of an evolution. In 2000, I believe 2010, 2011, one thing that happened was the source code for the Linux kernel in Enterprise Linux was always the base Linux version, let's say, 4.14. Then, a bunch of files that were the patches applied on top of that base version. That was really easy for developers to understand the changes that happened on a regular basis.

So, one of the changes that they made back then was to basically create a tarball of the code where the base kernel plus all the patches were applied, and only that was provided to anyone. So, the idea behind it was, "Oh, it makes it more difficult for people to understand what the patches are, so support is harder." For us, we have great kernel developers, we don't really care, but that was sort of the intent. There's been a gradual attempt at making it difficult for other vendors to build a compatible equivalent distribution, and this was the next step in that evolution.

[0:16:40] LA: Right. That makes sense. Fundamentally, the difference between you and RHEL isn't anything having to do with the implementation or the software, the system itself. It's the philosophy for how it's built and how it's put together. You're doing the work independently, producing the same result and different deliverables to your customers. Or to the community, not necessarily to customers. 

[0:17:04] WC: Yes. More so now than before. But it's still about providing support.

[0:17:12] LA: Customer support is the key. That's the real value add that you're putting on top of everything else. That is where you're truly unique, or where each vendor is truly unique, is how they do customer support.

[0:17:24] WC: That's right.

[0:17:25] LA: Let's talk about one of the things you often hear about in conversations about open source. I'm talking general open source here, not just Linux, not just Enterprise Linux. But one of the things you hear is, does open source contribute to higher security and software? Or does it compromise security and software? There's all sorts of philosophical views either direction, and it's an interesting debate in and of itself, and probably worth multiple episodes just on that topic. But how does open ELA think about enterprise-grade security in light of the open nature of what it produces?

[0:18:06] WC: Actually, it's a great question and there's no one answer to it. Like you said, it could be many episodes. I think, if I were to give my two cents on this, first of all, it sort of depends on the project. One of the things that that tends to happen is an open-source project is built by one or two people. They're very active in it. And then after a year, two year, three years, whatever happens in their lives, they take a step back, or they're the main contributor of the code, and then they take a step back, and there's a void, and nobody picks up.

When something like that happens to a project, then it becomes more vulnerable to potential security risks, because nobody's paying attention to it. The Linux Foundation, as you might have heard, has been working on some of this stuff, trying to see - they provide grants to important core infrastructure projects, to ensure that there's other people participate, or there's enough hardware available for testing and so forth. And OpenSSL was a good example where it was sort of slowing down and obviously, very critical, and then with the help of DLF, and some companies that it kind of picked itself back up.

That's one part. You arguably, security there became an issue, but that's no different than a company that has a product where they're spending less time on it, and they're not maintaining it. So, the open-source nature of that is less important than the funding and amount of time individuals have on that project to work on it.

Now, the other part is, as one often says, when development is done in the open and code check, and certainly in the Linux kernel. Code check-ins are viewed by hundreds if not thousands of people. So, it's really difficult to get something past that environment that hasn't had many eyes on it and the concept, certainly, on a little Linux kernel, the concept of having signed off by in the review process is pretty diligent. It's not that one developer has direct access to check something into the Git tree from Linux. It first has to go to the maintainer. The maintainer checks it and sends it to Linux who then actually commits it. So, there are multiple gates for code to go in and there is a good review. So, some of those projects are very secure. Some of them, we kind of have to take a look at each of them.

When it comes to OpenELA, one thing to keep in mind is that in the Linux and open source ecosystem, certainly in the Linux distribution space, there has been forever a mail list/group of people from distribution vendors that work together on agreeing on embargo dates for open source project security vulnerabilities. Because if something is discovered, in say, SUSE, and they release the source code for a bug fix, but don't tell anyone else, and everyone else is vulnerable until we find out and then fix it in our version or something like that.

What's happened forever is that, there's somebody from Oracle on there, somebody from SUSE, from Red Hat, from Ubuntu, and even from DSD in some of these groups. So, when a vulnerability is found in an open-source package, then it gets reported within that group privately. Then everyone agrees on one, who's going to work on the fix, or who already might have one. Two, what everyone agrees to in terms of embargo date. Since we're already part of that, this benefits OpenELA, because we make sure that we are in the know. If something happens in Red Hat Enterprise Linux, we know that there's some vulnerability fix coming. We're not going to be caught off guard. And since we have to fix this for our customers anyway, and it goes into the OpenELA source code, then OpenELA becomes equally safe, secure.

[0:22:04] LA: Makes sense. That makes a lot of sense. So, how is the work that goes on in OpenELA, different than the work that you're doing within Oracle itself on your Enterprise Edition. Is the difference, just your support, or is there more involved?

[0:22:22] WC: So, I would say OpenELA is a place where we publish the source code, full stop. There's not necessarily work happening within OpenELA that's unique to that. We work on code for Oracle, Linux, when we have the source code for that and it's something that gets released, then that goes into OpenELA. If the CIQ folks are doing something before us, and they release it, it goes into OpenELA and we use the same thing.

So, OpenEla is really more of a source code repo, where we stuff the code that we provide to our users and customers and developers out there. So, it's not like we have to fund people to do work for OpenELA. It's the work we do that we publish publicly.

[0:23:10] LA: Right. Maybe some different language. OpenELA isn't making the changes. The companies that are part of OpenELA, make the changes and share them among everyone who is part of the OpenELA ecosystem.

[0:23:23] WC: That's right. So, it's a very low-cost association, because we don't need to hire developers there were the developers on their own. Of course, it's public, right. So, if somebody, if a developer out there is playing with the OpenELA source code and building their own thing and finds a bug or something, they can certainly report that bug to that platform and we'll pick it up or they can release the patch, and we'll pick it up. So, it is a project where we do want people to participate and work as a community. Because as you know, everything makes stuff better. But our first goal is we have code, we publish it there. We have documentation that we've published there as well, because part of a Linux distribution is having documentation for the product. So, we've built documentation for many years and we've contributed that back to the OpenELA as well, so that it's unbranded generic documentation.

[0:24:18] LA: Open documentation, yes. So, you actually bring up something that I wanted to get into. It's actually a pretty good timing, and that is - so you, SUSE, CIQ, all contribute your changes to what is OpenELA. Correct me if I got the language, not quite right with that. But basically, that's what goes on. Anyone else can contribute as well. So, the million-dollar question is who else contributes? Who is contributing? Are there other companies who are contributing? Are there individuals that are contributing? Do you have a large community of contributors? Or is it mostly the three principles?

[0:24:53] WC: Right now, it's mostly us. It takes some time for others to really get involved and engaged in it. But I think that will happen over time, as people feel more comfortable with it. You have to understand that in the past, that was CentOS. CentOS has kind of changed its mission from being compatible to being, let's call it upstream. So, when you run CentOS now, you're sort of ahead of the game. But ahead of the game, it's not good when you build something stable and want enterprise-great code to run your applications on, which is why CentOS has been moving that direction. It's to no longer be an alternative, as a runtime for production, unfortunately. That's one aspect of what we're trying to do is if you build your code off of OpenELA, then you maintain that stability and quality.

So, there isn't that many folks are currently building off of this tree. But there's certainly a lot of marketing around it and making sure - like I said, the reason we started this quickly was to ensure we dropped, or we reduce the potential of fragmentation, because as soon as this announcement went out, there were lots of different private threads between different groups to say, "Hey, we'll do our own and we'll do our own and this is where we're going." When, we came together, we said, "Look, let's get the message out first, before the association existed, before we had the source code repos out." We just want to make sure we're going to work together and people don't have to be worried. Because there was a lot of concern or what's going to happen with Enterprise Linux now. We're like, "Look, we're behind this, we're committed long term, we want compatibility, don't worry, you're safe. There's an alternative, if you're concerned."

Then, we started doing all these other pieces. Now, in the last few months, and certainly last few weeks, even more, now that these repos are up and more changes are coming up, you'll see more folks starting to use it and I think in the next months, hopefully, this calendar year, more folks will participate. But I have to say, it's really more about stability for customers. It's a message to the public. If nobody contributes, we will continue to do that. We don't need more contributions. We certainly welcome them without having to be paying any money or something like that. But it's not required.

[0:27:24] LA: So, it sounds like you're in the uptake phase, and you're getting people to buy in. Basically, one of the biggest values you've provided is nothing more than the message that you're doing this adds stability to you in an already destabilized situation, given the announcements by Red Hat.

Given that, this may not be an easy, or even for that matter, a fair question, just because I'm not sure how to answer it. But what is the acceptance of OpenELA like? how has it been received? And how do you see it growing over the next year or so?

[0:27:57] WC: So, I think in general, it's been positive. I do think that the main message of providing users out there a sense of stability, and a level of comfort has certainly worked. I can tell you that in last year, in June, July, lots of customers were like, "Oh, no, what does this mean? What's going to happen?" So, by jumping on it the way we did with the three companies and also, individually, we've always had the message of like, they disappear from the face of the earth tomorrow, we have the right folks to continue. We are fully capable to continue our own way. That, of course, was still the case. But the intent of maintaining compatibility has always been important.

By being able to do that, I think our primary message of reducing concern has worked. I haven't had any conversations with customers in months that even asked about this. The whole conversation kind of disappeared. The confusion and the concern disappeared quickly, after all of these announcements. Life goes on, as usual, basically. So, in the future, it's the same thing. We will continue on our mission and we will have a place where we can create new repositories, which new projects that can be added on top, not to modify existing stuff. The base will always be the same and fully compatible. But for people to start experimenting with stuff and having broader access for ISVs or others to build their own things on top.

[0:29:34] LA: So, you actually went right into my next question, which was OpenELA 2024 is essentially a, "don't worry, everything's fine" message. What's OpenELA 2025 and what's OpenELA 2026?

[0:29:50] WC: Well, the primary goal is don't worry, everything will continue as is. And that will continue. That's the core mission, right?

[0:29:57] LA: But it does sound like there are some capabilities that you're working on, that you intend to extend into OpenELA, that will make it different from Red Hat's implementation?

[0:30:08] WC: That's right, because people want to have a way to experiment with, let's say, a new version of the kernel. Instead of having to go with a Linux distribution, that's completely different with every package being different. You can then say, "Okay, I installed the base version, and the only thing I changed is the Linux kernel package and I could try something out. If it doesn't work, I just go back and reboot into the original one. But it gives me a chance to have a stable distribution that I can build on, and then experiment with taking one or two components out of it, and see if that works or not." So, it makes it a little bit easier to do new stuff and try things out without breaking everything.

[0:30:51] LA: Right. What are some of the things that you see that will be added to OpenELA, in the upcoming years?

[0:31:00] WC: Newer versions of the Linux kernel, I think would be primarily because a lot of the innovation happens on the kernel side. So, I think that would be a very good example. I think mostly, add-ons, like building additional packages and projects that are not part of the base code, that we create a repo for special tools that otherwise you'd have to build yourself. It could be coming from the OpenELA repos, for instance, high-performance computing stuff. So, it really is more about individual saying, "Hey, I built this new thing. I want to have the enterprise customers use this." So, if I publish this on the OpenELA site, then it can be built and we know it runs on EL. I think it's more that.

[0:31:47] LA: So, the differences are going to be not saying this word derogatorily. But a hodgepodge of different packages based on what people are working on and want to contribute, as opposed to strategic direction change, or a strategic direction that OpenELA is headed. There's no direction you're trying to take OpenELA. OpenELA's strategic direction is don't worry, be happy. But there's no strategic direction beyond that, that you're identifying.

[0:32:19] WC: That's correct. It's basically stability, that we'd be happy, we maintain compatibility. If we didn't do anything but that, we achieve our mission.

[0:32:28] LA: Still, naturally, as time goes on, OpenELA and Red Hat Enterprise Linux will probably start to separate at some level, right? Whether it's because of additional packages that are added, or different decisions that are made by various companies, including Red Hat, including yourself. There's going to be deviation as time goes on. Do you see them deviating to the point where they're different, different to the point where - different the way other versions of Linux are different from each other? Do you see that happening? Or do you really want that not to happen?

[0:33:03] WC: I would say, and I think, I can speak for the other folks involved in this as well, for the most part, we want to maintain the same code, and that's definitely our goal. Fragmentation doesn't help anything or anyone. That's not the purpose. That wasn't the purpose of why we went into, on our end, in the Linux support business anyway. It really is about having stability and having fewer things to test and less deviation.

Now, if something does happen where proprietary becomes even more proprietary, I don't even know to what point that's possible at this point, because it's already pretty far off the main path of open source. So, if something worse were to happen, so to speak, then it might happen. But I'm not sure why they would want to go there, because that seems pretty extreme. So, I'm pretty comfortable with the current direction.

[0:34:01] LA: So, Oracle, or the OpenELA consortium, I'm not sure consortium is the right word. But whatever word you want to use there, doesn't want to do deviation. You can't speak for Red Hat what they want to do, but you don't anticipate them wanting too, either. So, you really hope and believe, and believe to be true, that they'll be compatible from a software standpoint, and that the deviations are going to be in the business value on top of the software supports, testing all those sorts of things, for the foreseeable future.

[0:34:35] WC: That's correct. Of course, who knows what happens? I guess nobody can predict the future there and what potential other thing could come out of the minds of the folks, in terms of restricting access to code. I would say, if someday, there would be a real restriction on our ability to do what we do, then OpenELA will provide a joint path forward even if it were to, let's say, fork or deviate from at some point, forced, then we would continue. So, that would create, I guess, a deviation, but then it would be a joint deviation rather than everyone on their own. It would still be better than the alternative.

[0:35:22] LA: How have the cloud providers, the AWS, the Azure, the GCP, and yourselves, what is their reaction been to this whole environment, both with what went on with RHEL, as well as what's going on with OpenELA?

[0:35:40] WC: There hasn't been that much change. So, a couple of things. One is that most of the cloud vendors do not provide the distribution they use for their cloud. They have their own internal thing. So, not exposed to something like that, necessarily. And as such, don't really care. Customers run whatever they want on their cloud platform and the third-party certify against their distribution, or they build images. We build Oracle Linux Images, and SUSE build SLES, and CIQ builds Rocky, and that's available in all the different cloud vendors, marketplaces anyway.

So, from a pure cloud vendor point of view, it wasn't really affecting them as much at all. Live continuous, I think it really was hurting the customers that felt that they suddenly were exposed, and now, they're less exposed. But that exposure was more running the distribution, whether that was on-premise or in a cloud, it wasn't really any different.

[0:36:48] LA: Got it. So, what's next for - well, I'll ask the question twice. Once for, what's next for you related to OpenELA, and what's next for Oracle in this area?

[0:37:00] WC: Next for OpenELA is continuing, ensuring release the source code and show people that this is real and that we are committed to this, and maintain that reduction of risk or eliminating the risk concern. Working more on a broader ecosystem around, like I said, documentation and providing test suites if somebody else wants to run some tests on their own, and we have some tests, we'll make them available. The documentation, I think, is quite useful. Because if you build a distribution, you do want to provide some level of docs with it. So, we've already built a lot of that. Contributing that back is helpful.

I think it's just really cleaning up the little rough edges that we need to do and just having a very clear, consistent release model. Same day, no delays in source code access to Open ELA, versus what we do, all that stuff. And be very transparent on everything. The code, the commits, the downloads are free public, no login, stuff like that.

In terms of Oracle and Oracle Linux, we have a great customer base. We use Oracle Linux everywhere inside Oracle, in their own appliances, the database appliances, and exit data and such that we shipped to customers have been OL forever. So, our focus is really the Linux part or the Linux distribution part is a very well-oiled machine. We continue building packages and updates and the compatibility stays. Our main focus is, and has always been make the upstream Linux kernel better, because there's always new chips, there's new - now, with GPUs and fast storage and different types of storage. So, we do a lot of work upstream that goes into Linux kernel and then trickles back into our kernel and the Enterprise Linux kernel. That is basically continuing what we have been doing in the past and no real change. So, British people.

[0:38:58] LA: Well, thank you very much for this time. This has been a great conversation. Obviously, I'd heard about OpenELA last year, but I didn't know a lot about it or what it really meant. So, I think this is going to help a lot of people figure out really what it is and what type of role I play in their future.

[0:39:15] WC: Okay. Well, my pleasure.

[0:39:16] LA: Wim Coekaerts is the Executive Vice President of Software Development at Oracle and a leader in the Open ELA project and he's been my guest today. Wim, thank you for joining me today on Software Engineering Daily. It's been a great conversation.

[0:39:31] WC: Thank you and thanks for having me. Have a nice day.

[END]