 Hi, this is your host, Sapin Bhartiya. And today we have with us Liz Rice, chief open source officer at Isovellan. Liz, it's great to have you on the show. Thanks for having me. Pleasure to be here. It's my honor to have you on the show. I've been, of course, tracking your career, ever since I entered this whole clouded space, open source space. But I would love to kind of take you on the kind of journey, your own tech journey, not like not going too much back in the but just talk about when you got, you know, in traditional open source and how you started this journey. I was always a software engineer, you know, sort of all my adult life. And even as a child, I was really into computing. So but a huge part of my early career was all around proprietary software. It took me a long time to really get to grips with this whole idea of open source. And it wasn't really till I got involved in, well, containers and the kind of cloud native community. Maybe I'd used a few open source libraries. And I think I'd probably, you know, I remember one thing I submitted to a Python library once, you know, something that I needed and, you know, submitted back upstream. And that was quite exciting. But I hadn't really been that involved in open source until I got involved in the kind of Docker community initially and that kind of whole world of containers that's now evolved into cloud native. And all of that infrastructure software was being built open source. And I started to understand how this was, you know, the best way for people to collaborate and that people weren't wasting time kind of duplicating their effort. And I really fell in love with the model of both the sort of efficiency of it, the innovation of it and the fact that you get to kind of work with people from around the world. You don't just work with the people that you're, you know, in your own company, but all sorts of other people as well. And I love that. I love going to events and meeting the folks that I know from online. And that's always really fun. Thank you for your question. But is there something, you know, specifically open source that you kind of fell in love with hate? This is, as you mentioned that you submitted a pattern with me, but either you can talk about the community, either you can talk about the contribution model that you don't have to prove yourself. What, you know, what is unique about open source? I think it's the fact that people can take a thing, you know, something that's already out there and run with it and do something completely different with it or, you know, tune it to their advantage whether that's, you know, commercially or just because they're fascinated. I guess some examples that spring to mind are things like, you know, the Raspberry Pi community, how they seem to take everything, you know, that we do really focus sort of data centers and then they get it running on tiny little homelabs running on Raspberry Pies. And obviously that's kind of fun. Or another example that I did personally, and it was completely utterly pointless, but when Virtual Cubelet first came out and I had this crazy idea that I was going to use Virtual Cubelet to control a drone, and I'm going to say I never completely got it to the point where I could get the particular drone I had to sort of fly for long enough before the battery ran out. But, you know, just Virtual Cubelet was never at all intended to fly drones, but the idea that you can sort of mash up ideas and come up with all sorts of interesting inventions. And I think that's really, you know, a useless example of the kind of innovation that can happen when all sorts of people around the world can kind of build on each other's ideas. No, I mean, it's so true with the open source. I mean, if you look at the Linux kernel, you know, the way it's being used today, Linux never, you know, even imagined, and you know, you give example of Raspberry Pi's and so yeah, it's incredible. Now, if you can also talk about, if you remember, you did touch upon your first, you know, contribution, but what were the first open source project that you fully got involved with, which can be seen as the first, you know, kind of stepping stone into your open journey if you can remember? Oh, I mean, I suppose the slightly strange thing about the way that I came into open source was that a lot of the, what I think I've now recognized as contributions were really around doing talks, you know. So I was doing things like explaining how containers worked. I did a talk that, you know, it's a few years ago now, but it was pretty well received about writing a container runtime essentially in about 80 lines of Go code. And that wasn't really a project, but it was really, I think helping a lot of people to understand what a container is. I mean, putting that talk together helped me understand what a container is. And I built that talk based on a talk that I'd seen by Julian Friedman. So again, this whole idea of building on other people's work and, you know, we continually stand on the shoulders of the giants before us. Yeah, so I was, yeah, I suppose making talks and you know, the codes out there, you know, the code that I used in that talk is available open source. So I suppose that was probably the first thing that I did. It's certainly the first thing that really got any attention and that people were interested in what I'd done. And then you look at open source, contributing code is not the only way people can contribute. Writing documentation, as you said, you know, it's pretty awareness, you know, that is also, you know. So I would also like, since you brought it up, that when we look at open source, talk a bit about not only based on your own, you know, experience, but since you're also involved with a lot of projects and, you know, when we talk to projects, they're like, hey, yes, we have enough contributors, but these are the areas where we need help. Sometimes it's about advocacy. So talking a bit about what are the areas where folks can contribute to open source projects which goes beyond just code contribution. Yeah, so today I'm really involved in the, in the Cillium project and we have this huge range of, I guess, expertise or skills that are needed across the project. You know, at one end we have kernel developers. I get to work with some incredible people who really know the ins and outs of the kernel and who builds EBPF in the kernel. So that's an incredible skill set. But we also have, you know, people working on Go code, the interfaces with the EBPF. There are people working on the UI. There's people working on the documentation. There's people working on demos. There's so many different skills that we need across the project. And also, you know, this idea of sharing knowledge, I think increasingly we recognize in cloud native, how important it is to acknowledge the folks who do go out and talk about technology and teach the technology and explain to other people why they find it compelling, why they think it's useful, why they think it's, you know, more efficient or whatever other benefits it has. Yeah, so there's loads of different skills that people can bring. I mean, art, you know. You see things like the logos that people build. We just put together a thing called EBDex, which is a collection of drawings of bees that essentially represent EBPF. And, you know, they're really fun characters. And we know that people sort of engage with that kind of emotional side. It's not all just about the bits and bytes and the lines of code. It's also about how do people sort of emotionally resonate with the project and the people in that project? And I think things like the EBDex is, you know, it's something that we've done to try and, you know, encourage people to feel involved with that kind of community. Now, let's talk a bit about, since we're talking about how people can contribute, I also want to talk about how you've seen the evolution of open source communities. First of all, there is no open source community. You know, there are communities depending on which project you look at. Because very early days were where people were working in their free time at night. They would just write a code. Now, most of the developers, they are on payroll to work on open source code base. So, which also means the whole community has also changed and evolved. How has it evolved? Yeah, I think it's very important that people are actually being paid, you know, proper salaries to work on this infrastructure code that companies rely on. And I think it's a very good thing that the majority of people working on, at least the projects that I see across Cloud Native, most people are doing that with the backing of an employer who's making sure that they're financially secure. And that, I think, puts everybody in a much more solid footing for contributing. I mean, there are still folks who are, you know, freelance or, you know, finding ways to keep themselves afloat. But I do think it's a good thing, really, that people don't think I'm just gonna sit in my bedroom, write a thousand lines of code, and magically, somebody will send me some money. You know, it just doesn't work like that. And I think a lot of the open source community has realized that one of the main ways we can make this work is to have companies involved. You know, most people on the planet work for a company, and there's no reason why open source shouldn't be structured the same kind of way. And it's all about aligning interests. The interesting thing about open source is we're not just aligning interests within one corporation. We're aligning interests across many organizations, you know, for everybody involved in Cloud Native. The rising tide floats all the boats. We have this incredible infrastructure of software that we're building that means that businesses can do whatever application-specific things they want to do more effectively, more quickly. They can deploy things faster and get things out to their users more quickly. And it's in all their interests that we all collaborate effectively on this underlying infrastructure. And I think that's great. Since we're talking about, you know, also one of the most important aspect of open source health is commercialization. So with these companies coming in, it also ensures that these projects are sustainably not relying on one person's free time or one company's, you know, resources, not charities, like tied to your business interests. With this commercialization, you know, and as you said, a lot of folks who are on the payroll, how have you seen the culture within open source change? Because I do remember in early days, even when I got involved with Linux, you know, sometimes they will say, hey, go and read the manual, you know, sometimes you will see things were a bit rude. Hey, go and figure it out yourself. Some communities were very friendly. Some because everybody was working the free time and people were like, hey, you know, I'm just doing a charity and you are like, you cannot come and demand something from me. So can you talk about how you have seen the evolution of the culture of the community where you see that it's becoming more welcoming, more friendly, or do you think that it's still the community where people do feel apprehensive when they send a patch or code? I think a lot of the reason why Cloud Native at least has been really successful is because in the early days, people were very intentional, people who have much better understanding of how to build communities than I do, really put in place some ground rules about things like code of conduct and how governance works in the different projects. Thinking very carefully up front about, well, what are we going to do if the maintainers disagree about something important? How are we going to resolve those issues? And how are we going to make sure that people know the boundaries of, we expect people to behave respectfully to each other? Let's actually write that down. And I think that intentionality in the early days really laid a solid foundation for Cloud Native being a really welcoming place. And the project essentially being, it's expected that projects should welcome new contributors and help people through that initial phase where people are figuring out, okay, how do I, you know, what are the steps I need to go through in this project to make my contribution? I think projects these days do make efforts and they know they are expected to encourage people and give people that sort of onboarding path. So that's a really good thing. And I think that has improved a lot. And we still have, you know, the tension between different organizations who maybe do have different, you know, interests. And, but I think it's really important that we, you know, balance and the organizations like the CNCF continue to provide this playing field where we can balance the interests of the big organizations, the smaller vendors, the up and coming startups, the individual developers, the projects as a whole, the end users, all these different kind of cohorts of people who are involved. And we have to kind of balance everybody's interests across the foundation. And once again, you brought a very good point which is, you know, we don't live a perfect world. So there will always be companies who are competing in the market but their developers may be working together or they do see value. But traditionally it's very hard for them to work together but some of these neutral foundation like Linux foundation CNCF which is a part of Linux foundation. What role do you think these foundations have played in creating an event playing field or also build some confidence? Because, you know, we are also seeing companies they just change license of their code base and they can lock a lot of, you know, potential contributors or existing contributors out. So do you see that these foundations have also played a very big role in popularizing the adoption of open source in the commercial space? Absolutely. And I think some of the ground rules that foundations can set can really give people confidence. So for example, in the CNCF the default license that people contribute under is Apache 2 which is a, you know, permissive license. There are some other licenses that are similar that are also accepted but, you know, almost everything is Apache 2 and the intellectual property is owned by the CNCF. So that provides a kind of guarantee to vendors, contributors and end users alike that that's not gonna change and those licenses are not going to suddenly get converted into something different. So I think particularly for contributors it's important for people to know that the basis on which they made their initial contributions will continue into the future and that nobody can come and take that work and, you know, they can build businesses that leverage that work for sure but they can't appropriate that intellectual property. And I think the foundations owning that mutual property in sort of on behalf of the community and providing that neutrality is really important to how it's foundational even to how these, how we can have this collaboration across all these different organizations. Now I want to switch gear and quickly talk about security a bit open source is often, you know, call, it's more secure than close source. First of all, nothing is fully secure. If you're adding a code, there will be bugs. People will make mistakes with the configurations, you know and especially the cloud network where, you know, API will leave a lot of things out there. So talk a bit about what is your approach when we look at open source is more secure. What makes it more secure? And on top of that, what kind of things folks should do when they look at or consume open source without blindly saying, hey, it's open source. I can close my and use it blindly as the most secure code written. So yeah, nothing is ever secure. As you say. And it's all a case of, you know trying to remove risk as much as we can. Things like the fact that many pairs of eyes can look at the lines of code that are added is one way that we can try and avoid malicious code being added into the source code of open source projects. Things like supply chain security which has been a huge kind of buzzword for the last year or two. Making sure that when users are deploying code it is actually built from the source code that they think it is because it's all well and good having this open source code but you need to know that's what you're actually using in your deployment. And I think a lot of work is really improving the security posture of these projects. You know, things like projects being encouraged to have S-bombs, so bill of materials, software bill of materials having the ability to scan projects. You know, foundations offer scanning for free for, you know, it's paid for on behalf of the projects so that projects can disclose the vulnerabilities in their packages very much more easily. So that's all giving end users a lot more confidence. I think there are some interesting kind of political angles to this. So things like different regulations that are being put in around the world requiring businesses to, you know, take responsibility for the software supply chain that they're using and making sure that that doesn't create some unnecessary, you know, open source is open source and we can't impose commercial requirements on the open source code. We can impose requirements on a commercial build of open source software, but not on the source code itself. And I know, particularly in the EU, some of the regulations, people have been a bit worried about how some of that's been phrased. So I think that's important that, you know, I never imagined that my career would end up involving thinking about things like, you know, EU regulations, but, you know, this stuff is really important. I actually, I do quite a lot of work with an organization called Open UK and a lot of that is involved with making sure that government in the UK and beyond understand the benefits of open source and how not to cripple it through terrible regulation, you know. Yes, thank you so much for taking time out today and of course talk about not only this topic, share your journey and more importantly, you know, the how open source is evolving and also sharing how, you know, individuals or organizations can, you know, get involved with open source. Thanks for all those insights. And as well, I'd love to have you back on the show. Thank you. Absolutely my pleasure. I hope to see you again soon.