Open Source at Large

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to the CTO Advisor podcast, and I have one of my favorite guests on, Lisa Kaywood. Lisa, where are you working these days? These days I'm at Red Hat, and I'm in the open source program office, which is probably something I should explain a little bit, given the topic of our podcast, but why don't we go on for now? So we'll get into the office of open source or whatever, the ... OSPO. OSPO. Open source program office.

I like OSPO. Yeah. In a second, but I wanted to tell kind of an origin story. I think I've had you on a podcast at least once, maybe twice. Maybe even three times. Maybe even three times, and it's always a great conversation, but there's history here. Right before we hit record, we were talking about it, and I want to see if you remember the event. I can't remember the event, but I remember meeting you for the first time, seeing you for the first time.

You were talking to, you know, I don't remember his first name, but last name, Mechman McNamara. What was the guy? It was back in the open stack days, and you had on this ... I don't know if you ... Because I met you, I'm like, does she normally dress like this? You had on this like period dress, and it was really cool. Oh, Colin McNamara. Okay. No, but I don't think that was the first time we met.

I don't think that was the first time we met. That was actually, I think that was the ... Do you remember what event that was? It was, I think it was a Tech Field Day event. I think it was a Tech Field Day event. So it was a really long time ago, and I made the comment on Twitter that I was intimidated to meet you. Not in the whole, oh, the women are just too powerful type dynamic, but you were one of the first people that I followed on Twitter, and I'm like, oh my God, her writing and just her presence and her command of this part of technology is really intimidating, and I don't know if she'd know me from a hole in the wall, basically.

So it's really funny that I've had you on a podcast for the three times, and I meant to tell you this, that I tremendously respect you, and I've looked up to you most of my career, especially most of my career as a blogger. So I just wanted to make sure that didn't go without being said. I think our positions have greatly reversed in the eight years we've known each other. I think the first time I remember meeting you, because I was trying to, when you challenged me on Twitter about when we first actually met in person, the first time I remember was a Vodge Ball event in San Francisco, and I think it was one of the years when Melissa was there.

So that was probably the same year, because I have this picture of my first VMworld, because Vodge Ball is at VMworld. It was 2013, and that was probably the same year. So same year, and it could have even possibly been the same event, because Tech Field Day has been around VMworld. Maybe, yeah. And if you don't know what Tech Field Day is, I'll put something in the show notes, but if we have Lisa on the podcast, chances are we're talking open source.

Surprise, surprise. And we got into this really interesting conversation, Lisa and I and a group of other people, about open source project culture. And I think one of the myths of open source that I think some companies use to their marketing advantage, because there's not a very good reason to correct it otherwise, and Lisa, we can talk about this, is that open source is kind of this grassroots thing that a bunch of developers get together and form a project that goes on to be Kubernetes.

Let's talk about the extreme. So we'll talk about that as the topic of the podcast, but I wanted to give the audience some background. What is your responsibilities as it relates to Red Hat and your current job? Yeah, so an open source program office is a thing that has been around for a little while. They're starting to pop up more and more in medium to large enterprises. And actually, we, as Red Hat, actually get a lot of requests from our customers to kind of help them either make the case for building one or just figure out how to build one.

And the reason that they exist, in most cases, it starts out as a compliance thing. People suddenly realize that they may have legal liabilities if they're not using, because everybody uses open source, developers grab this and that and the other thing in the course of doing their jobs. Left, right, and center. But it's not necessarily always well documented. They don't comment it particularly, don't necessarily check the licenses. And so somebody at some point reads something or a lawyer suddenly wakes up or a new lawyer comes into the company and says, well, what's our exposure here?

And so then there's this mad scramble to make sure that they're in compliance with all of the licenses and all of the code that they have. And then it becomes an exercise in training engineers. And then they start thinking, oh, well, maybe we should bring in more engineers who actually know about this open source stuff so that they can teach us all how to do it right. But then people who are open source savvy take a look at the employment agreements, which basically say that the company owns everything you ever do during the course of your employment with them and say, no, thank you.

And so then HR has to get involved and employment agreements have to be rewritten. And it just becomes this whole thing. And eventually, sometimes they start thinking about maybe they want to join an open source project or they want to contribute to an open source project or they want to at least benefit from open source projects directly other than just copying the code. And so a lot of the time, the engagement with open source groups has been happening ad hoc throughout the organization.

But somebody realizes that it might be useful if that were somewhat more centralized so that communication about what the various individuals are doing can be communicated broadly. And so all these functions wind up being sort of centralized into an open source program office who then has the responsibility to work with legal and HR and engineering management and internal comms and so on. Sometimes external comms if they decide to make open source engagement a PR thing or a marketing thing. And so it's kind of this clearinghouse of everything that the company has to do that touches on open source.

So that's what an OSPO typically is. In Red Hat, because it's been an open source company for a really, really long time, it's a little bit different from that. But that's sort of fundamentally what we do. My particular group is actually focused more internally than many other parts of the Red Hat OSPO in that I'm focused on a particular vertical or set of verticals, primarily telco. And so there are a zillion and one telco open source communities and consortia and standards bodies and making sure that we are in the right ones, that we're not spreading ourselves too thin, that we're engaging effectively in the ones that we are in.

That's kind of my focus with my current job. So you sound like you've decided to take on the challenge of not only wrangling cats externally in terms of open source projects, but wrangling cats internally as well. That's exactly right. Yeah, wow, that doesn't sound like a job I want, Lisa. That sounds like an awful lot of work. The vast majority of open source work is herding cats anyway. So the herding cats. So let's talk about the image of open source from an end user organization perspective.

We've talked about this a little bit, and I think you're absolutely right. You tweeted out that end user organizations really like I don't care how a company develops the product that I end up consuming. If it was based on open source, great. If it was based on proprietary closed software, just as long as they're responsive and there's APIs and they're open, great. The open for me means API level access and I can build around the thing that I want to build on.

But open source for other people and software development for other people can mean something else. So specifically, I want to make because I have I have a somewhat of a dog in this fight because you asked me this on Twitter, kind of like, hey, keep what what what gives you this perception that there's not. Kind of a open. That the open secret of open source isn't so open and my good friend Alex Ellis does open fast and, you know, he is one of the more traditional open source models where it's him and a couple of the contributors and they they built this fairly sizable project that they just can't get funding for.

Like the customers are not consumers of the project, aren't supporting the project from a financial perspective. And then there's no big vendor sponsor. Then you look at, you know, K-Native and competing projects, and those are backed by Google and some other industry players. And then it just got me to thinking, I'm like, is open source kind of this thing that's moved on from a grassroots set of developers like Alex and his group that's able to build a project and then the project kind of just takes on a life?

Or is that just a myth of open source? No, I'd say that there are almost as many different models of open source projects as there are business models of commercial companies. I think it's also important to understand from an enterprise IT perspective, and this goes back to that very first reason for the existence of Ospos that I was touching on. Virtually no piece of commercial software that you buy does not have open source components in it. Like virtually all software is basically just in the same way that we are, you know, hosts to all different kinds of other organisms.

And in some sense, we're symbionts, right? You know, we've got gut bacteria and all these different kinds of bacteria that, you know, make us us. The same is true of commercial software. You know, you've got libraries from here and, you know, routines from there and, you know, from 16 different directions. It's not like it's just all from one place, right? And, you know, even large open source platforms like Kubernetes, you know, they themselves are composed of all of these other different lower level open source pieces and bits and pieces, right?

So it's all a big, you know, I don't want to say cluster in the negative sense that it's often used, but it's, you know, it's all a grand piece of putting things together, snapping pieces together as opposed to, you know, just creating something from whole cloth, right? And so where this becomes important for enterprises to understand is if, especially if they have government contracts, there are certain federal regulations that require that you either have or not have certain types of open source software in your products.

And, you know, that's part of where that code scanning and code compliance comes in. For the most part, when you're talking about a commercial software company, they take on the responsibility of making sure that all of those liabilities and everything is documented. And so, you know, if you buy that piece of software, you're in the clear as a customer because the commercial company has taken on that liability and those responsibilities. But, you know, there is, when we talk about different types of models of open source projects, there is, as you say, there's everything from the open FAS, or I'll also point out OpenSSL, which, you know, everybody on the internet uses OpenSSL, but it is, it's composed of two Steves and one other guy.

And, you know, when there was the Heartbleed incident a few years back, you know, OpenSSL happens to live under the Linux Foundation and basically Jim Zemlin was calling up the two Steves in the middle of the night going, oh my God, can you help us fix this? Because there isn't, like, it's not sexy, nobody's like investing in it particularly. It's, you know, it's hosted under the Linux Foundation as kind of a public good. But, you know, it's not like it's, you've got a million corporate sponsors for the thing, even though everybody uses it.

Go ahead. That actually, hate to cut you off, but that actually brought up a supply chain question for me. OpenSSL was, I'm glad you brought up OpenSSL because that's, I think, the perfect poster child for this question. How should, and maybe this is a Office of Open Source argument for Office of Open Source type of question within end user organizations, but how should end user organizations think about supply chain when they're using OpenSSL and most of their Linux and Unix distributions or some, and in some cases, let's pick on OpenFaaS.

OpenFaaS in some type of very advanced workflow, there's kind of this risk. If, you know, Alex just says, ah, you know what? I'm tired of doing this. I'm not going to do this anymore. There's really not anybody else to pick up the ball or the two Steves, one of the two decides, you know, yeah, yeah, I'm taking my ball. I'm going to go home and play with it. You've lost 50% of 100% of the development team. How should enterprises look at the supply chain for their major business processes that essentially end up open, depending on open source, because you would think, well, the big Linux distributions would have protected us from OpenSSL being a problem, but they didn't.

Yeah, well, I mean, OpenSSL isn't necessarily unique to Linux distributions either, but HP UX uses it. It's all over the place. Yeah, but, you know, it is, it is a real problem, especially with these, these like low level, but really fundamental building blocks that again, they're not sexy. Most people haven't ever heard of them, you know, well, most of us hadn't heard of OpenSSL until Heartbleed, right? And, and so, and this was actually one of the things where there has been an argument put forth by some of the foundations, including the Linux Foundation, some of the others are looking at it also of how do we financially compensate developers for their time, even if it's something that they just went off and did, because it looked like it was something that was going to be useful.

And so they did it, and now they're stuck maintaining the thing because everybody uses it, but, you know, they're not necessarily getting anything out of it other than, you know, you know, pats on the head every so often. So, you know, there is, there is definitely a movement to start thinking about how we compensate individual developers for their time and maintaining these types of projects. But sometimes it's not even just a matter of compensation. It's just, you know, one of the Steve's gets bored or whatever, and they're like, it's just, you know, one of the Steve's gets bored or one of the Steve types retire or, you know, heaven forbid, somebody gets hit by a bus, you know?

And this is where, when you're building a community, you always have to be thinking in terms of life cycle. And so, you know, the founder may well have a vision, but a good founder, just as with a commercial company, has to be open enough to say, this is my vision, but when I'm bringing it out to the world, I understand that other people are going to get involved, and they may take it slightly in slightly different directions, and that's okay, because the important thing is that we build something that's useful and meaningful for the rest of the world.

That and that type of attitude is really what allows for, you know, other people to come in and pick up the work of having, you know, of maintaining the project and ensuring its longevity. And so that's really key. That's really important. So let's end off on this last question, because I think the one of the things that I love about open source is that it reminds me of the V community, and if people aren't familiar with the V community, it's kind of the community built up around VMware.

A lot of similarities. People just want to help each other further there in the VMware community. They want to help each other further their careers, learn more about virtualization and cloud computing. Open source, it is a lot of times a labor of love. Some people are paid full time to kind of develop on open source projects, but I think in general, you have to have a certain. Moral about you, about community to do well in open source. So if you're not part of the community, as you're if you're looking, if someone's listening to this podcast and they're kind of looking at open source, you know, I really like to get involved in open source.

I visited GitHub, but I really don't get like, how do I get involved in an open source? How do you enter an open source community, a typical open source community? Yes, I mean, you know, there's there's often this misconception that, well, I'm not a coder. I can't I can't do anything. You know, I took a C class 20 years ago. I wasn't great at it. That's about as far as I went. But, you know, there are all kinds of needs that a community has, just as again, and as in any commercial organization that go well beyond developing code.

You know, a user perspective is having that user perspective is extremely important. Documentation is extremely important, especially when you're not talking about something that's a packaged product that's, you know, it's not necessarily super obvious how you use it. Right. And so, you know, poking around with it and going, oh, well, what happens if I do this? What happens if I do this? And why doesn't it work if I do this? And, you know, providing that feedback to the developers is extremely important work.

Helping get the word out, you know, that that that horrible M word marketing, you know, that that, you know, people kind of sometimes kind of, you know, scrunch their their their noses at that. But it's extremely important. Again, going back to that question of sustainability and longevity of a project, you know, people aren't going to join a project that they don't know about. They're not going to contribute to a project that they don't know about. They can't help grow a project that they don't know about.

And so even if you yourself are not a developer, if you think something is really cool and you want to see it, you know, evolve and be sustained over time, help get the word out to other people who can help with that. Right. me for a project that you let's say that I use whatever the open source solution is. Actually, there's one there's a hardware open source one that I'm really interested in. It's a continuous blood glucose monitor that that adapts and dispenses insulin to kind of make a synthetic pancreas, really, really cool stuff, life changing stuff.

And I want to get involved in that. Is it just as simply as just going to the about page and finding out who, you know, where the community is and just joining that community? A lot of the time, it really is that simple. I mean, usually there's, you know, the the lead contributors are they have their names there. They have their their emails there a lot of the time, or even if they don't, you know, on GitHub, you certainly have people's aliases and then you can message them within GitHub and say, hey, I'm really interested in this.

I'm not quite sure how I can contribute, but I'd love to contribute in some form or fashion. Here are my skills. Here's what I think I can contribute. And they'll be like, oh, great. You know, somebody who wants to help us. Yes, please come help us this way. I don't know. I don't know how much work. I don't know. I don't know how much free labor actually gets turned down. Exactly. They will help find you something to do.

Believe me, you others reviewing. It doesn't have to be as complicated as reviewing code. It can be reviewing documentation or editing for grammar. If you're a grammar nerd, which I know at least for even just clarity, just before clarity I'll review it. And did I understand it as a user of this product and offering updates and pull requests? So Lisa, again, we've run out of time and I think we could probably go on for another half an hour just talking about open source, open source community.

We didn't even hit on cheese. You kind of hit it there with the bacteria. I saw what you did there. We almost talked about cheese during the podcast. If people want to learn more about your cheese, how do they do that? You can follow me on Twitter at RealLisaC. com. And Lisa, I consider you a friend and as a friend, I really need to talk to you about this cheese thing. It's getting a little bit crazy. com.

You want to DM me. You have more questions for Lisa. And if like me, you've read her stuff, you've never seen her face and you're like, man, she's really sharp and I just don't feel like approaching her that I can approach her. You can DM me and I'll provide an introduction. I'm very friendly. I don't bite. I don't bite. No, she doesn't. She may offer you cheese, though. I'm serious about the cheese thing. We'll talk to you next episode of the CTO Advisor podcast.