How PMs can win with open source - Dan Ciruli (Product Leader, Nutanix)

Dan Ciruli is VP and General Manager of Cloud Native at Nutanix. A computer science graduate of UC Berkeley, Dan spent a decade in engineering before pivoting to product management in 2003, a role that barely had a name when he started. Since then he has held product leadership positions at EMC and Google, where he was part of the team that helped create Kubernetes and open source Google's cloud infrastructure.

He was a founding member of the OpenAPI Initiative and a steering committee member for the Istio service mesh project, and has spent the last two decades with one foot in commercial product development and one in the open source community.

In this episode, Dan explains why open source is not a charity exercise, how companies actually make money from code they give away for free, and what product managers get wrong when they tell their engineers to avoid it.

Key takeaways
— Open source is not crowdsourcing from individuals — much of the contribution comes from companies investing on the clock, because broad adoption benefits everyone more than proprietary lock-in.
— The CNCF succeeded because it created a neutral space where the largest and smallest organisations felt equally safe contributing and consuming. That structure — not the code itself — is what made cloud native computing universal.
— Being a product manager in open source requires the same core instinct as any other PM role: understanding the why. The difference is that your engineers may work for a competitor, and your roadmap is not entirely yours to control.
— AI is multiplying the capability of both good actors and bad actors in open source security. The answer is not to slow adoption but to keep a credible human in the loop — someone with accumulated trust, judgement and accountability.
— Before open sourcing your own work, be clear on how your company will make money, articulate it concisely for leadership, and then find at least one other organisation — even a competitor — willing to join you. A consortium signals a standard. A solo release signals a gamble.

Chapters
1:16 — From engineering to product management
3:11 — Bridging open source and commercial work
5:05 — The origin of Kubernetes at Google
6:35 — How Nutanix embraces open source
7:16 — The crowdsourcing misconception
8:51 — Why the CNCF changed everything
11:25 — Building a defensible moat in open source
12:13 — The business models behind free code
14:18 — Managing roadmaps you don't fully control
15:04 — When your competitor writes your code
16:04 — The CEO who wore his secrets around his neck
18:13 — Developing an open source strategy
19:37 — The one question every PM must ask
22:44 — What is the CNCF?
23:34 — AI, open source and the security arms race
29:45 — Chop wood, carry water: the human in the loop
31:48 — Advice for PMs running open source products
33:15 — Harnessing a community you don't manage
34:38 — Should you open source your own work?
36:35 — How messy does it really get?
39:33 — Linux is an anti-pattern

Our Hosts
Lily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. She’s worked on a diverse range of products – leading the product teams through discovery, prototyping, testing and delivery. Lily also founded ProductTank Bristol and runs ProductCamp in Bristol and Bath.

Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He’s the author of What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon’s music stores in the US & UK.

Transcript

SPEAKER_00 0:00

I want to be clear, there will be more drama, and that's just part of the price you pay, right? It's just part of the price you pay for doing it in open source. For open source to succeed, by the way, one of the things that had to happen, like you had to allow competitors. You need to understand that your roadmap is not entirely your own. It is largely engineering driven. You're constantly doing a triangulation. What do I want? What does the community want? And how can we arrive at a thing that is going to be acceptable?

SPEAKER_01 0:27

Is there an anti-pattern out there? Is there's this one project or this one company that they should never have open sourced this thing?

SPEAKER_00 0:33

When there is a large open source movement, you realize that if you're not on that, you're going to be missing out.

SPEAKER_02 0:38

What about the honesting the community of engineers?

SPEAKER_00 0:43

Whether the engineer works for you or not, when you establish like here's what we want to do and here's why, when you can really communicate that, you can motivate them to do it.

SPEAKER_01 0:53

Dan, thank you so much for joining us today. How are you doing?

SPEAKER_00 0:56

I'm doing great. How are you doing today?

SPEAKER_01 0:59

Doing great. We've been trying to schedule this one for ages. And I'm delighted that you're finally here. But yeah, so we've had some back and forth. We know each other, but our audience doesn't know who you are yet. Do you mind doing a quick introduction? Who are you? How did you get into products in the first place?

SPEAKER_00 1:16

Don't mind a bit. Uh my name is Dan Ceruli, uh, and I am currently the vice president and general manager of cloud native at a company called Nutanix. And like many people in technical product management, I came up in engineering and I spent a degree in computer science from uh University of California, Berkeley, Gobert's, and uh spent about 10 years in engineering, uh starting in the 90s, before this role of product manager had really coalesced and and become a common thing in technology. And uh after about 10 years in the industry, some friends and I had started a company, we'd sold that company, taken a little time off. We were starting something new. And and we hadn't had product managers at our at the at the first company we were at. And if you were leading a product, you kind of talked to the customers about what it needed to do, you designed the architecture that we were gonna build, and then you ran the engineering team that was building the thing. And I knew that this role of product manager had evolved in the in the kind of interim. And so when my friends came and said, hey, we're starting a new company, do you want to join? I said, Yeah, but the the thing that I liked the most out of the last job was really that first part, talking to the customers, figuring out what we're gonna do. So I'll join, but I want to be, you know, I want to be director of product. And they're like, you know, we don't care what you put on your business card as long as you come on board. And and literally like since that day uh in 2003, I have been a product manager. Fantastic. And now you're and you know, then went through, you know, and by the way, just quickly, quickly, did it at a startup for a few years. Uh, that startup did not get sold. That failed. But then the next time I applied for a job, I had three years or four years of product management on my resume, right? So then I worked at EMC and grew my career there, ended up going to Google for seven years. Uh, it was a fantastic experience, and then have been in kind of leadership positions in a in a series of companies since then. Uh, Zora, day to IQ, and now Nutanix.

SPEAKER_01 3:15

And so you do this in a proper commercial way. You're working for commercial companies, you're a general manager, but you're also heavily involved with the open source uh movement. So tell us a little bit about how you got involved with that and what you do. What's what's the relationship between open source and your commercial work?

SPEAKER_00 3:32

Uh great. Uh happy to dive into that. And that really came out of my work at Google. Um, when I joined Google, there was no such thing as Google Cloud. You know, now it's, I think that might be a$100 billion business. I don't know. It's a big business now, right? Didn't exist when I joined. Um, I joined the group that was called Technical Infrastructure. And we built all the technology that the Google product teams built when they that they use, when they built Gmail, when they built search, when they built ads, when they built maps, all those things were built on top of proprietary Google technology. Well, in 2013, 2014, when uh Google finally decided to enter cloud computing for real and start creating enterprise products, uh, technical infrastructure renamed itself Google Cloud. And Uers Hotzler, who was employee number eight and ran uh TI and then cloud for years, you know, he said, hey, right now, in in my group, 95% of you are doing work internally and maybe 5% working on external products. He said, as of today, we're flipping that. And you're all working on external products. And at that time, Google sure started started building commercial products in cloud, but also very crucially realized that having a good open source strategy was gonna be very important and decided to start open sourcing things out of cloud. Google had done a lot of work in the open source for a lot of years, but not really related to commercial products. And this was a step saying, hey, we're gonna start doing things in open source. And one of the biggest ones to come out of that was a product called a project called Kubernetes. Um, I worked in a couple of different areas. My team at Google built API infrastructure and what's called service mesh infrastructure. API is how you uh how you expose your services to the outside world and service mesh, how you regulate traffic internally. And so in open source, I then turned to how do we how do we do this following that Kubernetes model? And we, I was there's a there's an initiative uh called the Open API Initiative, which governs the specification about public APIs. I was one of the founding members of that as we worked with other people in our community to formalize a standard around APIs. And then within service mesh, uh, we open sourced a whole project called Istio, which is an open source service mesh. So since that day, really, I've been working with one foot in the open source world and one foot firmly in the, okay, now how do we make money off this commercial aspect?

SPEAKER_02 6:00

So in my mind, you said it uh it's called Nutanix, but it's not, it's Nutanix.

SPEAKER_00 6:08

You're not the first one to say that. And it is Nutanix, and no, we do not make uh dietary supplements. No, no. Common misconception, maybe someday we'll have you know a plan B, but for now it's going pretty well, doing a couple billion dollars a year on the on the technical side.

SPEAKER_02 6:27

I think that sounds it sounds more professional.

SPEAKER_00 6:30

I'll let the marketing people know. We got the Lily seal of approval.

SPEAKER_02 6:34

Totally. Thumbs up, thumbs up. So, in your work at Nutanix, how has open source kind of been embraced in in that business? And has that been something that was there at the start when you came on board, or is it something that you've introduced in that role? Or I guess my sort of big question over this is to me, open source has always been about having like crowdsourcing the engineering community and um the development communities to contribute to your uh your code or your um your infrastructure, maybe not your infrastructure, but your code and your platform and everything. So, like how do you then commercialize that? Sorry, I'm asking so many questions all in one thing, but um, how do you commercialize that? Because is there not the need to then compensate these people who are making that code base better?

SPEAKER_00 7:29

That's a great question, Lily. And it is, I think it's crucial for people to understand, people who want to understand why open source exists and how it exists, um, understand why companies get into it at all and where the money comes from. Now, there is one misconception in your question, which is not that this is crowdsourced because it is, but that it's crowdsourced purely from individuals. Because clearly lots of individuals on their own time, on their own dime, do contribute to open source sometimes incredibly, incredibly. But a lot of the contribution to open source is done on company dollars, on company time. And I think this project Kubernetes, which is kind of universalized how we deploy applications in the 21st century, it's kind of how do you get a piece of code that you've written to the right server in a maybe in a data center or maybe somewhere else, but how do you how do you get it there in a in a way that is not dependent on any vendors and like an API that is, you know, anyone could use? So you're not tying yourself to any particular vendor. Um Kubernetes has become universal. And one of the reasons it's become universal is that it was created in an open source foundation that really encouraged contribution, not just from individuals, but from companies. And it's the the Cloud Native Computing Foundation, which is a foundation under the auspices of the Linux Foundation. Linux Foundation, you know, is a large open source organization that was centered on Linux at first, but now has all kinds of things in it. Um, the the genius of the CNCF is that it gave a home where the largest companies on earth, companies like Microsoft, Google, Red Hat, uh, IBM, Nutanix, eventually Amazon, even, they all felt comfortable essentially donating time, saying, I'm gonna let my engineers work in on these projects, as well as an environment in which very small companies felt safe doing the same thing. I'm gonna start a new company, a new open source project. I'm gonna put it in there. They all felt safe contributing with the knowledge that they would be free to commercialize what they did as well. And that was really the thing that they did in in setting up the CNCF that was really smart to say, hey, you can cur you can contribute here. All the stuff that you put in is open source. You're also welcome to build a commercial product on it effectively. And, you know, and we'll give you conformance tests, we'll let you prove that you're doing it the right way. And and what that did was it let these big companies know you can give dollars to this. And yeah, that there's, you know, some layer of this is open source, and when you write code in there, everybody gets it. The advantage there is to writing it in open source is that on the adoption side, big companies and small companies feel comfortable using it, right? They're not worried, oh, you know, when when company uses open source, um, if it's some little project with some little self-funded developer somewhere in in Iowa, you might be worried, what if what if she decides she doesn't want to do the project anymore? Uh now I'm in trouble, right? But when big companies are are are putting time and effort into it, you know it's going to be around. So open source created a feeling of safety both on the contributor side and on the consumption side. That made this become pretty quickly a really a universal success. Everyone decided, great, if we can have a non-vendor specific way to put a piece of code on a computer anywhere from any of many, many different vendors, well, that's a very safe adoption. So, yes, people can contribute on their own. That's very welcome. One of the interesting dynamics is that the recognition you get as a developer is on your own. Like you use your name. And if you're contributing a lot, you know, you might have done that on your own, but you you're you might now be attractive to another company to hire you because you've got so much expertise and you've got proof of your expertise because it's all in the open.

SPEAKER_01 11:24

Let's talk about the the economics of this, though, because there's, as you said, you everybody working together, whether individually or corporate, you are creating a marketplace, which is brilliant. You're you're you know, uh creating a place where you can compete, but you're also competing on an open standard. So, and one of the primary things we try to do in in our field is try to create a defensible moat around places. So, you know, iOS, you've got a defensible moat as an operating system, Windows, you've got it, Chrome-based ones, Linux-based, you don't have moat around the operating system, but you have it on other things. So, how do you and that's just operating systems? There's tons of other things. How do you, when you're working with in an open source environment, create the diff that defensible moat?

SPEAKER_00 12:13

There are a lot of different ways to do that, and and we see companies doing it in different ways. Um, in in some cases, it's because, and we do some of this in Nutanix for sure, is we have this open source uh kind of core of what we distribute. And then we have some tools to help you use it that are proprietary. And if you want to use those tools that make, you know, because open source is kind of a mess sometimes, like like, you know, to go into production, you might need to have 40 different open source projects working together, Kubernetes. I mentioned a service mesh, all kinds of different things. We're running all that stuff, it takes work and figuring out is it all tested together? Do these components, are they actually going to mesh the way I the way I want to? So one way you might do is say, hey, we have some proprietary stuff that manages it for you. Another way to do it, and this is what the cloud vendors do, is they say, hey, we'll run it for you. You don't even have to run it. You don't want uh to install and run a database, you want to use a database, right? So we'll charge you to run that. Uh in other cases, companies say, hey, you you you want to know that the people behind this code are going to help you if you ever have a problem. And so we'll offer support, right? And all we offer is support. It's not really differentiating, except that you do have that expertise. As long as those people work for you and they're happy working for you, then you can go out and you say, Hey, you like that project a lot, but you think it's kind of you know difficult or you're worried there will be a bug someday, pay us for support and we'll make sure that you get the patch faster than anyone. We'll make sure you get access to the engineers. So there are a variety of different ways. And sometimes that that open source can be embedded in and and no one really even knows that it's inside, but but it's open source inside, right? So there are a lot of different ways. And and one thing that we have seen in the in the last you know, 20 years, really, I think, is Linux is where this really got going, um, is that uh it's it is is absolutely financially viable, whether you're a big company or a small company, you can find ways to to make money in open source.

SPEAKER_01 14:13

So Dan, that all sounds great, but now you don't have control over your entire stack. You're dependent on others at times. And so now your roadmap is built on assumptions and dependencies that aren't necessarily in your control. How do you how do you manage in that sort of situation?

SPEAKER_00 14:33

Being a product manager in open source in particular has is very interesting and and different from my time doing product management over strictly proprietary uh technologies and and does kind of require thinking about some some different implications. It's actually more complicated than you even said, Randy, because sometimes that that other the the people you don't control on the project, the people you don't get to tell what to do, they might literally be from a competitor. Right? It's not just, oh, there's people you don't have control. Like literally you you and and for open source to succeed, by the way, one of the things that had to happen, like you had you you had to allow competitors in, right? If if Google had released Kubernetes on their own, if they hadn't involved Microsoft and IBM and Red Hat, all of whom are competitors and eventually Amazon, it would not have succeeded, right? So so you need to be able to do that. And and frankly, so it it is slightly different. You need to understand that your roadmap is not entirely your own. In fact, it's also very engineering driven, which is different than most uh even enterprise tech technical software where you know engineering always has a say, is always helping create the roadmap. But in open source, it is largely engineering driven. And so you're constantly doing a triangulation effectively, right? There's constantly, what do I want? What does the community want? And and and how can we how can we arrive at a thing that is going to be kind of mutually acceptable? Usually you can do that. I've have found it extremely rewarding, by the way, the that reaching out when we worked on the on the Istio project or the open API initiative, both of them, it was involving companies that we were very much, you know, commercially competitive with. But we all kind of agreed to work together for the greater good, with the knowledge that we would be able to monetize better individually by working together on a thing as a group. And that's a really strange notion. If we, you know, coming from my background, where you know, your source code was the most important thing, the most, the biggest secret you had, like in the 90s and early 2000s. I remember I was at a startup and our CEO kept the keys to our uh to our encryption that we use for our source code repository in a USB drive around his neck, right? Like there was nothing that company had that was more valuable in our minds than that.

SPEAKER_01 17:00

I thought you were gonna say a safety deposit box.

SPEAKER_00 17:02

No, no. He I'm not I'm not exaggerating. He wore the he wore a USB drive with the keys. So it is a very different world when you say, no, we're gonna compete in a different way. And and and what you're doing is that again, if Google had open source Kubernetes and not brought people in, they might have had some success, they might have gotten some usage, but they realized by getting everyone involved, we can make this pie a hundred times bigger, a thousand times bigger, and shoot for a bigger piece of that pie than we would have gotten had we tried on our own. And and in fact, you know, that's the absolutely bore fruit. Um, and is the reason the reason uh Kubernetes was allowed to be open sourced was they realized our management realized, because at Google there was always this, hey, can we open source this thing? And if it was going to be very high profile, that went up to the very top. And they realized, oh, in you know, as a third place that cloud vendor, we'll never be able to define a standard. But as a consortium, we can define a standard. And and then we can make things like Google Kubernetes engine and figure out ways to monetize this directly. So yeah, it requires a different form of product management.

SPEAKER_02 18:13

And you you talked earlier about like kind of defining your open source strategy. I feel like, you know, regardless of what business you're in, having some kind of open source strategy, whether it's like open sourcing some of your own source code, or whether it is deciding what projects you're gonna contribute to and like what open source projects out there are you're gonna use in your own business. There's there's always gonna be some kind of uh decision making around how you know how you use or contribute or put out uh code to open source. As product people, like you say, I think you said earlier, this tends to kind of sit with engineering, this type of decision making. Um, but as product people, I I mean, I've definitely had conversations before with engineers where they're like, well, we have a few options. There's this open source option, or there's this like paid for option, like, you know, we mean need to make a decision. And there's always a bit of a like, oh, open source seems, you know, less safe or less predictable, I guess. You know, what would you encourage the sort of average product person to be thinking about when in their own organization and with their, you know, with their team of engineers, like in order to develop that understanding of how they should work with open source?

SPEAKER_00 19:36

I think that it is it is the domain of the product manager to understand the question, why? Why are we doing this? Why are we gonna make this decision? This goes for launching a product, for you know, designing a particular feature, for re you know, releasing and opening an API or not like the product manager has to has to be really thinking about why we want to do this. And and I think it it goes to this as well. Why do we want to build on open source versus not build on open source? And I and I think what we've seen in the last, you know, last 10 years, especially, the CNCF uh was created uh around 2015, 2016. And if I were a you know a well-informed podcast guest, I would know this date. Um and it has become it really is the standard. It's it's the standard now for how you how you deploy uh software in in a data center, right? There's still a lot of VMs around, but they're waning. Um, they'll be around for decades, but but everything new is being written to go into a container and and and go this way. And the CNCF has had, uh I I think I I just saw at the at the last uh cloud native conference, has had had over 300,000 software developers contribute in the last decade. 300,000 is an amazing number. It is a ton of innovation. And if you want to be riding the wave of that innovation, right, you you want to build on top of this. If you if you build on something, if you say, no, let's do this proprietary, open source is risky, then you have to realize that the people who who do ride that wave are just going to be going way faster than you. You'll be doing something more controlled than them, but they will be doing something that's way faster. And so this isn't necessarily true in every realm, but when when there is a large open source movement, you realize that if you're not on that, you're you're going to be missing out. And and, you know, this is in in human history, we haven't had a software project that's had 300,000 developers contributing to it before, right? This is it's very loosely knit and it's actually a bunch of different open source projects, but they all do fit together. And so, in a way, it's it's you know, it's it's a way to take advantage of the strongest concentration of innovation in software we've we've ever seen. And and look what's happened, you know, just in the last two years as all this AI stuff is happening. That is all built in, like it's all built on top of Kubernetes. Everyone's using it. Kubernetes is no one really even mentions it. It's just de facto. But the one of the reasons that this innovation is happening so quickly is it's built on top of all this innovation that happened in the last 10 years. So you do have to understand why. You do have to understand what the pros and cons are. You know, if you're a product manager, you're probably going to need, or especially if you're in leadership, you're going to have to understand where you'll be making your money in this. How are you going to charge, you know, and and and making an informed decision? But it is, you know, in in certain areas in AI, in, you know, software deployment, like there's been no doubt in the last 10 years, people who decided to go this direction have not regretted it.

SPEAKER_02 22:44

And sorry, you mentioned then a couple of times CNCF. What's what does that stand for?

SPEAKER_00 22:49

It's the Cloud Native Computing Foundation. And it was created by a guy named Craig McClucky, who was my boss at Google, in order to bring it, it really was created to make a safe place for the for the very large and the very small companies to feel comfortable contributing code. And it is, you know, as I said, it's part of the Linux Foundation. So it's just an open source consortium. In a sense, it's a marketing group, right? In a sense, like they market cloud, cloud native computing. But but more than that, they do they do kind of offer this safe place to contribute to open source and this safe place for enterprises, for governments, for the very largest, most important companies on earth to to consume that open source.

SPEAKER_01 23:33

You also mentioned AI a moment ago. So as long as you've opened that jar, let's let's dive into it briefly. Um, the latest models from both OpenAI and from Anthropic, they've been, there's been a lot of chatter about them lately. They've now been used by a lot of uh companies to both expose uh vulnerabilities, a huge amount of them that they hadn't been hadn't found before, but also to start patching them at incredible speed, which is fantastic. But it's an arms race, and you're talking about the stuff in proprietary code. It's not like open source doesn't have vulnerabilities and bugs as well. So, how does this new approach to uh finding vulnerabilities and patching it and dealing with it in an open source and sometimes volunteer, sometimes uh corporate way? Uh where do you see this all going? What are the risks? What are the potential benefits from all this?

SPEAKER_00 24:28

Well, the risks are huge. Uh, you know, as you said, uh the this will undoubtedly, like any technology, be used by the, sorry for the term, bad guys as well as by the good guys, right? Like there's no doubt whether it's you know state sponsored or it is industrial espionage, it is in in you know intentional insertion of bugs that allow you know vulnerabilities. The existence of AI is is really it's it's multiplying by 10, maybe a hundredfold the number of people who can, you know, can write code, right? Because you can just you can just say in English, I want something that's gonna go do this, go figure it out. And then those people can write 10 times as much code as they used to, right? So it is clearly a tool that will be used by the people who are who are trying to create or take advantage of vulnerabilities. So on the on the other side, uh, people who are trying to contribute uh in in good spirit and consume in good spirit, it's very important that they use it as well. And undoubtedly, you know, I my own engineers say they're way, way more productive than they used to be. You know, I'm a firm believer that open source, and I think the you know, federal government's defense departments around the world are believers that open source in general is more secure than proprietary. And the reason is uh it goes back to, oh, now I'm gonna forget who first said it, but uh with with many eyes, all bugs are shallow. And and and that's true. You know, when code is in the open, yes, someone can can check something in that that is, you know, deleterious is a bug. But in reality, you because it's out in the open, anybody, anybody's, you know, now anybody's AI bot, anything can find that bug and can fix that bug. And we have well-known ways to publicize those bugs and to publish fixes and to make, you know, get get that out there. When something is a is a vulnerability in a proprietary code base, you might never know. And in fact, you don't know, right? And and I think this is this is one of the uh this is one of the huge, huge reasons open source will end up being like the the the US government decided, you know, at least five or seven years ago, like this is the way we want to run in open source. So this now becomes a tool that that the good guys can use as well. Um, Linus Torvalds just today published a thing. They're trying to get a new uh release candidate out. And he published a thing and he he did caution, he said, you know, we're of course we're seeing more AI generated bug reports than ever and AI, uh, you know, AI responses. And he said, please make sure that you, the individual, are adding value. Don't just say AI found this bug and leave it, right? Like do the things that that a good contributor would always have done, which is, you know, do some research, figure out how to do it. Use your eight AI tools to do that. Make yourself more productive with those tools, but also use your judgment. And and so I think that open source and this kind of vulnerability stuff, it's it's it's a small slice of what's going on in software in general, which is we need to be able to use these AI-based tools. Um, we need to be able to use them rationally and intelligently. We can't view them as independent actors. They're not going to write great software independently and they're not gonna fix great software independently. They need people who are curating them, who are figuring out how to use them. If they're making you more productive, fantastic. But don't trust them to just do the thing.

SPEAKER_01 27:55

Yeah, it's interesting. I've been watching what's going on in the UK government. Uh, I'm based over in London, and the NHS recently published something saying they're moving away from open source, at least in certain instances, and uh a more centralized part of the UK government digital infrastructure published something in response, you know, in a very polite way of not naming the NHS decision specifically, but saying, yeah, open source is the preferred way to go for exactly the reasons you just enunciated. So is it it's interesting to do that?

SPEAKER_00 28:26

And the value you get, you know, I I think, you know, I think, as I said before, monetizing this is very good, but the value you get of building on top of open source, as I said, that we've never seen innovation like this. And when you don't build on top of it, you are not taking advantage of that.

SPEAKER_01 28:39

And then the uh proliferation of the sheer amount of code that is being generated now, the throughput that we've got, it sounds like from uh if I'm being optimistic, all the bugs, all the vulnerabilities, all the weaknesses that have been there for years, they're being identified and they're being patched, and we're shoring up that infrastructure. You know, we can always go back to that XKCD comic of you know, the one little bit maintained by a piece in uh somebody in Omaha, a random guy in Omaha, kind of thing. But you we can shore up the infrastructure and be a lot more confident. If I'm being a pessimist, uh I also see people complaining about the sheer number of submissions that they're getting and the amount of time it takes to review it. We even, you know, whether it's human-reviewed uh pull requests or merge requests, or whether it is uh agent-assisted to do it, the sheer amount and the could potential quality of it is terrifying. The architectural standards aren't and the thought isn't always there. So, where are you on this? Are you an optimist? Are you a pessimist? Are you a realist? What does it look like coming up?

SPEAKER_00 29:44

All in all, I'm an optimist for sure. But I would say, you know, a pragmatist as well. Um, I think that I have seen open source projects who have said, do not any purely AI generated bug report or or CVE purely AI generated, we are gonna close it. You know, you you need to we need to know that there's a human in the loop. We need to know our this is, I think it was about pull requests. This wasn't about bug reports, it was about pull requests, but it's obvious it was uh just a AI generated. We're gonna, we're going to uh close it. And the reason is that in the end, you know, the trust that people get. And I said, you know, you have you have to make sure that you are running an open source project such that people feel safe consuming it, right? And that is, you know, the way this works in in open source, you kind of graduate from contributor, maybe to maintainer and eventually project owner. The people who do that work their way up and they prove themselves by by adding value, by contributing value to the project over time, right? In in Kubernetes world, they called this the the chop wood carry water mantra mantra. You know, go do work. And if you do work, you're going to be rewarded. You'll get you'll get positions of responsibility. And then you have a responsibility to kind of curate what goes into this project. How do we decide which which architectural designs it take, which pull requests to accept? And and the people who consume need faith that the that the project has people they can trust doing that. Um, that can't, I don't think, can be relegated to AI. And those people will have to use their judgment, their judgment that they've gotten over the years of writing, you know, first bug reports, later maybe fixes, maybe, you know, editing documentation, eventually being able, you know, a maintainer where they can accept pull requests, they can merge pull requests. So, so that that human in the loop, the human who is who is making the big decisions, uh, I think is what's going to what makes me optimistic in general, in in that and an adoption of these projects is going to depend on saying, yes, I have faith in that project, that that they're gonna they're gonna do the right thing for the community.

SPEAKER_02 31:47

And if there are product managers listening to this who work on products that are open sourced, you know, what advice do you have for them for running an open source product?

SPEAKER_00 32:00

I would say be an active participant. You know, you you do not need to, I was I was on the steering committee for the STO project, uh, as I said, and I was I was on the the governance board for the open API initiative. In in neither case was I like setting the entire roadmap. But in every case, I was trying to make sure that just as I do when I'm running a commercial product, I'm understanding the why. Why are we doing things? Help the engineers prioritize, definitely made some mistakes. The project I work on, uh Istio, you know, they they they made it way too complicated to start. They were trying to rebuild what we had at Google. I really wish I had asserted more, like, hey, no, let's start simple, let's go MVP. Um, so use the knowledge that you you have, the experience that you have as a product manager and understand the why. Why are we doing this? And so I talked about that in terms of why would we as a company maybe use open source or contribute to open source, but also think about that within the construct of the open source project if you've made that decision. Why do we want to build this next feature or why do we want to integrate that? Or you know, make sure that the engineering team is thinking about the why. And if you do that, you you give the project itself more of a chance to succeed, right? And that's our job and product.

SPEAKER_02 33:15

What about the harnessing the community of engineers? Because as product people, we're kind of very used to managing lots of different stakeholders and team members. But in that sort of scenario, it's slightly different, isn't it? The dynamic is different.

SPEAKER_00 33:32

It's slightly different. I will say, you know, in product management, we we always talk about the old trope. You've got to get people who don't work for you to do what you want them to do, right? In product management, no one works for you. Your engineers don't work for you, your marketing people don't work for you. Nobody works for you, right? We have the smallest work in the in the company, usually. And and your job is always uh, again, getting, you're explaining why. Why do we want to do this? Fundamentally, that's not very different when those engineers happen to have a different badge than you. It really isn't. And it is one of the things that has, you know, I again I found most rewarding working in open source was working earlier today. I was on a call with a company that's kind of direct competitor, but what we're focusing on is hey, what can we do in open source together that is, you know, where we're all comfortable doing? And so that's actually really fun. So whether the engineer works for you or not, when you establish like here's our here's what we want to do and here's why, when you can really communicate that, you can motivate them to do it. And then it doesn't matter that they've got a different login than you.

SPEAKER_01 34:35

So, Dan, if I'm working for a company, you talked uh at the beginning of this conversation about the decision to open source Kubernetes. But if I'm working at a company and we're doing something interesting, we've solved a problem in a novel way, but it's not necessarily a competitive advantage for us, or it's something that we think we might help create a market with others. What do I need to think about if I'm saying we should open source this?

SPEAKER_00 35:01

So I again understand how how it will lead to business success for you, because internally you'll have to be able to describe that, right? You'll have to be able to tell your boss, your CEO, here's here's how doing this is still going to allow us to succeed. And ideally, you will be able to explain how this is going to better make us succeed. And and make sure you're you're very clear on that. You can explain it succinctly. Um, and and the other advice I would give you is if you're thinking about doing this, and again, this is the voice of experience, figure out who else might be interested, even if they're a competitor, and reach out to them. It is so much more appealing to the end audience when they see, because it feels like a standard, even if you're not necessarily promoting a standard, when they see, oh, you know, Red Hat and Google are both saying they're going to do this. Okay, that makes me really interested. It it is immediate, it's not just twice as interesting, it makes, you know, it's very, very um uh confirming when companies see multiple companies in on the same open source project. It it makes it so much easier, most so much safer to consume. So that's the two things is make sure that you understand how your company is going to make money, explain that internally, and then figure out who else can we involve in this effort. They don't have to be a competitor, but who else can we involve from a different company so that it will give legitimacy immediately to this project when we kind of tell the world about it?

SPEAKER_01 36:34

Dan, it's all sounds great. It sounds like everyone is doing this from the from a position of let's make the world better, let's serve our own interests but serve everyone else's interests. But this is also the real world. I'm sure there are things that are legally complicated around this uh when you you or your company get involved. I'm sure there's politics involved in ooh, let's let this company in, but not that one in. Uh, without naming any names, without necessarily talking about any of the projects that you've been involved in, how messy does it actually get?

SPEAKER_00 37:04

Oh, I've seen it get really messy. It does, it, it is, it does add more drama. It it absolutely adds more drama. We had, you know, I've seen internal debates at Google, raging debates over whether this project or that project should be uh allowed to be open sourced. I've seen, you know, all of the people who work on it just have one opinion and management have another opinion. Um, it does get messy. I have absolutely seen it. And, you know, we've seen major schisms in open source before where a community will take a project and fork it. Um, we've seen companies who have changed the license on open source, right? Like big, big, big things. Um, there's no doubt that it that it adds to the drama. It it adds to the drama. And no one loves the drama. And and I've been I've been obviously talking about the the optimistic take on all of this. And I and I'm optimistic because this is a, you know, I've seen the creation of this multi-billion dollar industry that has sprung out of uh Kubernetes and the Cloud Native Computing Foundation. There is absolutely a ton of ton of value that has been created. But I want to be clear, there will be more drama. And that's just part of the price you pay, right? It's just part of the price you pay for doing it in open source. Trust me, the companies who who were in that initial founding of this and and have contributed so much, none of them regrets it. Google doesn't regret it, Red Hat doesn't regret it, Microsoft doesn't, no one does. Like there's tons and tons of value. And indeed, it's the you know, the group is greater than the sum of the individual parts. There's no doubt about it that because everybody has has created this value together, they they derive way more value than if they had tried to do this on their own. So yeah, part of what you pay there is you pay in drama. And I'm sorry in advance for the you know antacid you'll have to take to deal with it. But um, you know, it's what you'll deal with and and you'll be fine. As long as you understand why you're doing it, you've got a clear, you know, goal for your company as well as for that open source project, you can you can chart away.

SPEAKER_01 39:06

And sorry, last one, is there an anti-pattern out there? Is there uh a story that you all tell each other about? Oh, there's this one project or this one company that they should never have open sourced this thing. It totally killed the thing or the market.

SPEAKER_00 39:21

Uh I don't know if I can point to one exactly like that. I I I will say that the I think the projects that I think, you know what I will see in the anti-pattern? Linux is an anti-pattern. Okay. The benevolent dictator for life has worked out very well for Linux. It really has. However, it's in general, uh, I I think you Linux got lucky and we won't see that happen again. In general, you are better when you say, I'm not going to control this. I'm going to have multiple companies who all have a stake in it. Um, you know, it is really, you know, interesting to think about exactly why, how Linux succeeded. And it, you know, by the way, that happened in a different world, in a different time. Um, I would say that's the anti-pattern. Uh uh, Linus is, you know, he's he's done wonders, and and you know, Linux is it is amazing what it's like.

SPEAKER_01 40:12

But I see some of the flames he sent back to contributors.

SPEAKER_00 40:15

Right. Yeah. And and and and you know, one one snap away from yeah, it's just so so benevolent dictator for life. That's an anti-pattern. When if you decide to do this, do it in such a way that there's a foundation, whether it's an existing one or you need to create a new one, that can offer that assurance is hey, this will be this will be safe to adopt. I so uh that's what I'd say.

SPEAKER_02 40:35

I feel like there will, you know, there are definitely people who love the drama. So um maybe this will be an encouragement for them. But um thank you so much for um talking to us about this topic. I've learned a lot and I know our listeners will as well. Um it's been really, really interesting. Thank you again.

SPEAKER_00 40:53

Thanks for the opportunity. Uh open source needs good product managers. It has been a fantastic decision for me. And even though it sounds kind of weird and you're kind of losing some control, I strongly encourage product managers to look into it, think about it. It really is. It needs great product management. And one of the reasons I wanted to do this was to help get the words out to product managers. This is a safe place to work.

SPEAKER_01 41:17

Fantastic. Thank you. And well, safe places, it's a hard one to find these days.

SPEAKER_02 41:21

So the product experience hosts are me, Lily Smith, host by night and chief product officer by day.

SPEAKER_01 41:31

And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work.

SPEAKER_02 41:40

Lou Ron Pratt is our producer, and Luke Smith is our editor.