The latest episode of the Emerging Leadership Network podcast features an interview with Daniel Riek, who works on special projects and strategy with the CTO at Red Hat. In this episode, Daniel shares his insights on the future of open source in the cloud and the key leadership skills required to succeed in this space.
Here are the key takeaways from the interview:
Expand the concept of open source: Open source should not just be limited to code in a repository and its license. It should also include operationalizing the code, which means running the software as a service, as part of a service in a cloud-native model. This will enable others to build on the service and create a virtuous cycle of open source contribution.
Decentralization is crucial: With cloud services, there is a risk of centralization, which leads to dependencies on a few entities. A decentralized approach is essential to counter this effect. Open source projects should be aware of these issues and aim to move towards decentralization.
Understand the benefit of open source: It is essential to understand how it can benefit your business, strategically think about your dependencies, and find synergy between your principles and your primary goals.
Open source in the Cloud era requires different leadership skills: Understanding dependencies, centralization/decentralization, control, sustainability, and the difference between software, product, and the service itself.
Overall, this podcast episode is a must-listen for leaders in the tech industry and elsewhere interested in software’s future in the cloud era. It provides valuable insights into the evolving landscape of technology and the leadership skills needed to navigate this space successfully.
Listen to the episode:
Here is the transcript of the episode:
Welcome to the podcast on emerging leadership. I’m Alexis Monville. Today we are joined by Daniel Riek, who works on special projects and strategy at Red Hat. His previous roles include leading Red Hat’s AI Center of Excellence, managing cross-product integration engineering, leading Red Hat Enterprise Linux Product Management, and multiple startups, including ID-Pro, one of Europe’s first open-source service providers. Daniel has spent most of his career in the open-source space, and today we will discuss the future of open source in the cloud era and how individuals and leaders can support open source and ensure that it remains accessible and open. For those who may not be familiar with the term, Daniel, could you explain what open source is and why it’s important?
Of course. I actually prefer the term “free software,” which is not about free as in no cost. It’s about free as in freedom. Free software allows you to change the software, understand how it works, improve it, and redistribute changed versions of the software. “Open source” is basically just a marketing term for the same thing. Often we refer to free and open-source software (FOSS) to combine them. I use them largely synonymously. The point is that it’s about empowering the people who use software and giving them the right to understand the software, adapt it to their needs, improve it, redistribute, and collaborate on the software. It’s really about sovereignty in technology. It’s about controlling the technology that defines your life.
Okay, really interesting. In a very interesting talk at FOSDEM, you’ve spoken about the challenges facing open source in the Cloud Era. Could you tell us more about these challenges and why they are important for those in the tech industry to be aware of? Why should people outside of the tech industry care?
Right. Free software is about empowering you to control the technology. As everyone is probably aware, more and more of our life is defined by software. An example I often use is a connected mousetrap I have in my basement, which does a very traditional task. It’s a mousetrap, but now it’s connected to the internet. It talks to my local Wi-Fi network and then talks to a cloud server and then notifies an app on my phone when it did what it does, which has a huge advantage. It avoids me finding things weeks later in the basement, so it’s really useful, and I bought that mousetrap, which is a very physical, very mechanical thing, because of that software feature. My light switches in my house are all small microcontrollers. They’re all small computers running software and talk to each other and, through some home automation, talk to the internet. So everything in our world is defined by software. Basically, everyone is exposed to that to some degree. Every business is definitely exposed to that, and more and more businesses differentiate through software features in their internal organization, in their customer interactions, and progressively even in their product. So everything is software, and logic is done in software. Our interactions with the world are with software. Because we control our physical world with software, the software complexity is approaching the complexity of the physical world. It’s no surprise there.
And part of that of course is that things need to be always connected it means that there’s more and more software and a paradigm that really came along with that expansion and you can argue about cause and effect. But, you know, I think they just co-evolved is the concept of Cloud computing which I would define as the mixture of an operational paradigm – how do you run your software – and the underlying Infrastructure. That’s optimized for developer velocity so you can keep building software without having to stop for things that are underlying dependencies, whether that is infrastructure like a computer you need to run on, a network connection or a service like a database. You compose your software and you try not to stop for underlying infrastructure or have your developers stop for underlying infrastructure, so developer velocities. The second part is operational excellence. You want because if your business or your world or your house depends on software running, you don’t want to have any kind of operational fragility. You want your software always to run and you want the best practices that are common in whatever one does. You want that to be applied to how your software runs. Because if, even if you cannot have a positive differentiation from optimizing things because you’re just doing something that’s very mundane like running a web service or something, you still would have a disadvantage if you weren’t doing it as well as your competitor, right? So you want the operational excellence, the best practices embedded in how your stuff is run, how your underlying services and infrastructure is run, and lastly, you want elasticity which means that you can increase or decrease your usage dynamically at any time. So if you have, for example, a sale, a new product launch, and you expect a lot of traffic, you want the ability of your services to scale up, and then when you don’t need that anymore, you don’t want to keep paying for services you don’t need anymore. That’s what we call elasticity, so things can grow and can reduce as needed. And that is really what Cloud is about. It’s a paradigm that gives you a software architecture and infrastructure that supports maximizing developer velocity so you never have to stop when you create your own stuff. It embeds the operational excellence best practices, and it’s elastic. And yeah, most people know someone like Amazon or Google or Microsoft or in Asia, Alibaba, and you know there are big cloud vendors, IBM is a cloud vendor, Oracle is a cloud vendor, so these are companies that provide that kind of infrastructure, and there are many smaller ones. Even people running their own data center want to run them in this paradigm. So the goal is to support modern software and your dependencies by running yourself in the cloud paradigm.
Yeah, so Daniel, if everything around us is defined by software, and we have that great capability of the cloud that is, as you said, optimized for developer velocity, we have operational excellence so things can continue to run always, and we have elasticity, so we don’t pay for what we don’t need, so we pay only for what we need, and we can increase our capacity. That’s absolutely perfect. So why are there challenges for open source?
Yeah, that’s really interesting. So first of all, everything that people do in the cloud nowadays is built on top of open source. All the major clouds use open source. They’re usually based on Linux as the operating system. Open source virtualization technology that’s in Linux like KVM, or container concepts like Podman and Docker, and orchestration tools like Kubernetes. So, it’s a lot of open source in there. The place where open source is successful right now is the common base of what I call “code assets” – software program code that sits in a repository or is a binary that you can take and run when you need it, and that’s what most of the cloud vendors use. It’s what the cloud services are built on the highest. So, if you have a database in there, that has usually for most, a strong open source base. Even most of what any user does nowadays is built on the foundation of open source code. People build their own business differentiation in software. For example, let’s stick with the example if I build this control stack for my connected mousetrap, right? There’s a lot of open source in there, both on the device itself, some of the pieces in the microcontroller, our open source libraries. You can basically assume that because it’s most of the common underlying software, the middleware that they use to talk through the internet is based on open source. The parts on your mobile phone also include open source libraries, and you can verify that if you go to your mobile phone settings, you will find somewhere the open-source licenses that they have to list.
Now, the issue is that when you operationalize software, and in fact, operationalizing open source software, is the biggest differentiator for any kind of cloud vendor or people who provide software as a service. Even in some cases, they take the same open source code that’s publicly available, but they know how to run it with that operational excellence, and that becomes suddenly a proprietary differentiator. It includes knowing how to make it scale, how to run it, how to configure it securely, and how to keep it secure against attacks, which is a common problem. Software gets attacked directly or through supply chain issues, and if you don’t have the right process in place, and you download random open source software from the internet, there’s a risk in that. So, the cloud providers have these processes nailed down, and taking open source software and actually running it as cloud-grade enterprise-grade software is suddenly a proprietary thing. That obviously creates a conflict because now the point of open-source software of “I want to empower people to be in control of their technology, I want to provide freedom” is running up against the problem of actually running the software now being a proprietary feature.
Okay, so the point of open source was that freedom and that control and if you have a software that is open source, but if you don’t know how it’s run, then you don’t have that freedom and you don’t have that control anymore. So that’s the problem. So what can you do about it?
So that’s the first problem. There’s another problem that is kind of a second-degree problem, but I want to mention it. The first one becomes very obvious as soon as you try to do this. It’s a common discussion in the open-source industry or business. Even people who do a lot of open source, for example, don’t run their own mail servers anymore because of the complexities of running it securely, keeping it operational, protecting it. Or even being able to get your mail accepted by other services, the way to use it is not as free as the underlying code anymore. That becomes pretty obvious that, “oh, I have this open-source software, but I don’t know how to run it or at least not as securely as you know at that scale or as well as performant as efficiently.” But the other problem then compounds that because, if you do cloud-native development right, the point is of cloud is to abstract from underlying complexity, so you can focus on the core way you want to differentiate. If you’re a business, you want to implement your business differentiation in software and all the things that are not differentiating for you that are just the requirements that you have that you know like a database. Most businesses just need the database, and having a better database probably is not going to help you sell more of your product in most cases, right? So, you want to focus on your application that uses the database. You don’t want to spend your time on figuring out how to run the database. The same is true for an open-source project. If I’m doing an open-source project, I want to focus on the core of my project. Let’s say it’s Home Assistant, home automation software. I want to focus on making that better, not on how to run the underlying database or message bus or whatnot. So, what happens is that people start building abstractions on top of abstractions on top of abstractions, and that creates a distance from the underlying open-source software.
Yeah, that’s why I gave up on running my own mail server when all my emails were going nowhere. I gave up and used the service, and then some of them were finally reaching their destination.
Right, exactly. And that sounds like a small problem, but it’s a symptom of the bigger problem, which is really that people are building abstractions on top of abstractions on top of abstractions, and they start to lose sight of the underlying open-source software. So, it becomes really hard to know what is running where, how it’s configured, and how it’s secured. And when something goes wrong, it’s really hard to debug because there are so many layers of abstractions that could be the problem. So, that’s really the second-degree problem.
I want to figure out how to do the best home automation. I don’t want to have to figure out how to run the underlying service to provide that. And because those services in the cloud are run as a proprietary concept, you, as an open source project, have two choices: either you start depending on proprietary black box services that you can’t look into and you can’t control, or you have to run all of it on your own. And that creates a fundamental disadvantage for open source projects when they try to develop in a cloud-native way. It means they benefit from all the greatness of the cloud paradigm, where they either have to do it themselves and figure out the operational excellence or depend on a proprietary service, and thereby undermine the whole point of open source even when they create code. And that creates a downward spiral of open source value when open source development itself starts depending on proprietary approaches. A great example here is GitHub, right? Most open source projects use GitHub, which is an awesome service that gives you management for your source code, collaboration issue management, CI management, more and more integrations, now an AI bot that helps you write code. It’s built on open source software, right? It’s in the name. Git is an open source project created by Linus Torvalds, the same person who created Linux. But the service itself, the glue code, all the differentiation, everything that makes it such a great tool other than the core open source code underneath Git, everything else is proprietary. So the moment you use GitHub, you have built this kind of proprietary dependency in any open source code. And it’s not just GitHub; it’s actually owned by Microsoft, so for people who have a long history in open source, Microsoft was always anti-open source. They called open source a cancer back in the day, and they were very anti-open source. Now, most open source projects, at least in their ongoing practice, depend on the Microsoft service to keep building and managing their source code.
Yeah, Dependency is an interesting challenge for open source. So if we want to escape that downward spiral that you mentioned, what can we do about it?
So ultimately, on a high level, I think that open source needs to expand the concept of open source from code – you know, code in a repository and the code license – to include operationalizing the code. That means two things, right? One is like, and it’s not going to be the same for every open source project, but ultimately, open source projects should include in the project charter running their software as a service or as part of a service. And with the goal to enable other open source projects to then build on that service in a cloud-native model so that you create the same kind of development approach that you have in the proprietary world, where people can aggregate existing services and come together and create this you know, it creates an exponential growth rate, right? Because you can build on top of all the things that other people have done which in open source, you do that kind of at the code level, you reuse libraries. But if applicable, I should be able to reuse an existing service and then create a virtuous cycle of open source. It’s what we call this contribution cycle where people come together and contribute to open source projects to bring them forward to expand that to a similar cloud-native concept of things running and then other things aggregating beyond just the code in a repository.
Wow, okay, what’s the first step to do that?
I think that depends a little bit. There are different approaches for different projects that will be taken, and there are a bunch of ongoing things. I think one key point is starting with awareness right? We need open source projects to be aware of the problems, aware of the dependencies. I think we need to get a push towards decentralization, and that’s an interesting topic, right? Part of the problem, part of the benefit of the cloud that how people consume it today kind of co-evolves with increasing centralization. So people move to the same thing, which is part, like, it increases the benefit for keeping things proprietary for that centralized entity, and increases these dependencies on very few entities. So a decentralized approach automatically counters that, and we’ve seen that in a different space, right? Like if you look at the Twitter situation, a lot of people have decided that Twitter, for this or that reason, isn’t a great platform anymore. It’s too centralized, and many people don’t agree with the approach of the previous or current ownership, and whatever. I don’t want to get into that issue. The structure is the point though, is people have a problem with this one centralized platform being the one place where everyone comes together, having to submit to their rules, and not being able to have sovereignty over your own content. And the answer that kind of is a front answer right now interesting is a project called Mastodon, which is an open source project with a decentralized approach, right? Where everyone can run their own social media instance of Mastodon. It is the true open source project. It already has this concept of running it as part of the project, and there are many people, you know? So, it’s not just code in a repository, the people involved in the project themselves are also running instances of it, and everyone can go and run it. It’s easy to run because it’s part of the project. And then you just connect, you negotiate with others to connect to them so you create a decentralized social network of people running their own instances of Mastodon. So that’s a great example of an open source project that has cloud-native operationization as part of the content. I’m sure it could be improved but it you know it obviously is working to some degree because a lot of people are now using Mastodon, and it’s evolving fast to be an alternative to centralized social media platforms.
So that’s a great example, right? It comes down to expanding the project scope to include operationalizing, so running the software as a service, and a decentralized approach, which means that many people can run it and you somehow bring that together to create a joint benefit and growth and collaboration on top of that.
So awareness of dependencies, running your project as a service, and thinking of decentralization. So avoid that effect of centralization that will put you in that trap of building things proprietary. Okay, that sounds like something people can do. The question would be, next, why they are not all doing it, but Mastodon is a good example. So, let’s go with that. What are, from your perspective, the key leadership traits and skills needed to succeed in open source in that cloud era and to make that happen?
That’s a hard one, right? Because now I’m looking at a crystal ball, and it’s very much like it’s my opinion, not an experience because it’s an ongoing struggle, and you know, it’s generating like open source as a concept for code at rest has one, right? It’s the standard base for everything. So it’s in it has proven that it’s the most efficient way of creating and maintaining the underlying common code that everyone needs but that no one can actually differentiate on. And we all have also proven that you can professionalize that and create businesses around that without compromising the underlying concept. I work at Red Hat as you know, and with me and that’s what Red Hat does. Red Hat has a subscription business model that is fully compliant with the concept of open source. Ultimately, selling the similar to how cloud is kind of about the embedded best practices. Red Hat’s business model is the best practice of maintaining enterprise-grade open source and increasing cloud-grade open source code for business users. A huge benefit for everyone, right? It benefits everyone because it’s complying with the open source model and contributing back. It is also collaborative with everyone else in the space, usually. Reddit does not solve problems on its own. It’s always in collaboration, even with competitors because it’s this common underlying base, right? So that works really well, and that’s proven, call it: The normative power of the factual that is working in the software industry.
And, you know, that doesn’t mean that there is no proprietary software, but that’s usually kind of close to the customer use case, you know. Ultimately, what customers implement themselves usually, they keep proprietary because that’s their business differentiation. But soon as you get like one or two levels down, you get into common services. And I think, to my predictions, that model can be expanded to services right with a decentralized approach. And I think a key leadership really like it’s understanding the benefit of open source and ultimately like, I have kind of two minds there, right? But in my private life, it’s something like a conviction that I want to be in charge of my own technology. And I want to be, so I use open source even when it’s not necessarily convenient, right? That if you go into the business side, I have a more utilitarian view on that, right? I want to do open source so it benefits me. And I think, so I think not going to be sustainable, so you have to find a synergy where open source is really useful for you, which aspects of it are critical for you, think strategically, think about your dependencies, and how you want to have control and sustainability and sovereignty so that you don’t get into dependencies that harm your business. Then, focus on those areas. I think that is the key leadership skill that people need to develop, but it’s not the same for traditional open source for code at rest. It’s just about adapting it to not accept, for example, for cloud services, the things that you wouldn’t accept for code at rest.
I like what you said about conviction, and some people are saying you don’t want to leave your principles behind for convenience reasons. But the line is probably blurry and there’s probably a limit that you cannot overpass and that’s interesting to be aware of that too.
And yeah, and I mean, we always, if you look at the cycles in the tech industry, it’s always a little bit of pendulum swinging back and forth between concepts, right? You always have, for example, a trend to centralization, like the mainframe. Then we had the PC, then we got the cloud, which turned back into centralization. Some people say it’s just a reinvention of the mainframe, right? Like it’s a black box service running on someone else’s leased hardware that you pay by the hour. It’s really convenient, and I use it for certain things. I use traditional data center approaches for other things still, but in the cloud-native mindset. But sometimes it’s better to buy the hardware and not run pay by the hour because you’re always utilizing it. So you have to, and I think we see right now, we had a huge expansion, there is an economic crisis going on, and we see a lot of people reconsidering that, going into cost control mode and suddenly reducing their cloud spend or even rediscovering their data center. We have other trends like edge, which comes from software defining the world. Now software needs to move closer to the data sources and interaction points. The classic example is a self-driving car. A self-driving car needs to take decisions locally because if it has to ask the cloud, it will fail to brake in time. So it has to take the decision locally, so you need local compute power. So suddenly, you need a decentralized approach there, and so it comes back to leadership, looking at the trends and the requirements honestly, reconsidering decisions, reconsidering the trends, and making your own choices informed by a mix of strategy and principles and immediate needs.
And among those are an understanding of dependencies, an understanding of centralization, decentralization, and that understanding of the difference between software or product and the service itself. It’s really fantastic, Daniel. Thank you so much for joining us today and sharing your insights on the future of free and open-source software on the cloud. Your experience and expertise in this field are truly valuable and inspiring to emerging leaders in the tech industry and everywhere else. Thank you, Daniel.
Thank you, Alexis.