At a time when open-source enterprise software is at a crossroads, wracked by debates over licensing and monetization, Kubernetes stands as an unqualified success.

First released by three senior engineers at Google five years ago, Kubernetes has been one of the few open-source projects to make an outsized impact on distributed computing with a minimum of drama between users, maintainers, and vendors. There’s a lot of people who would argue the hype around Kubernetes raced well ahead of real-world usage, but there’s no question that companies modernizing their applications around containers are paying close attention to the potential of Kubernetes to serve as a bridge across multiple cloud providers.

During its fifth birthday celebration last week, we were thrilled to host a discussion between the three co-creators of Kubernetes — Joe Beda and Craig McLuckie of VMware, and Brendan Burns of Microsoft — at the 2019 GeekWire Cloud Summit. We talked about the history of the project, the current state of open-source software, and the unsolved problems that are holding back the future of cloud computing.

A lightly edited transcript of that discussion follows below.

GeekWire Cloud and Enterprise Editor Tom Krazit: So, I figure most of the people in this room know you guys, but if you could just introduce yourselves, say, “Hi” and tell me who your favorite person in the history of computer science is, and why.

Joe Beda: I’m Joe Beda and my favorite person in computer science … I would say Ada Lovelace ’cause she was the first programmer and was a badass and was super cool.

Brendan Burns: I’m Brendan. I would go with … I don’t know that I have a single favorite. But I’m going to go with Steve Wozniak, one of the co-founders of Apple and the unknown Beatle of Apple.

Craig McLuckie: Hey, I’m Craig. I’ll go with Jack Tramiel, the guy who created the Commodore 64. I would’ve had the loneliest, most depressing teenage years but for the Commodore 64. So, thank you Jack.

Tom Krazit: One of the reasons you guys are here, and the festivities of the week, are all around Kubernetes, this project that’s been following you around for a few years now. Looking back on the progress you’ve made so far and where we are today with Kubernetes … let’s just start there. Where are we today? How has the project evolved? What’s left to be done? And what are you most proud of over the course of that five year period?

Brendan Burns: I feel like we hit this inflection point when we started talking about things like our backend policy. I was like, “Oh, I guess we’re enterprise now.” It was not in the initial roadmap. But I think that’s … there’s a degree of ubiquity that comes along with that. I think for me the thing I’m most proud of is really the community. I feel like we’ve gotten incredibly lucky, both in how the community has expanded and supported the project. And the lack, in some ways, the lack of drama that’s there, has been really fantastic.

Joe Beda: I think for me, one of the things we talked about probably a year or two ago was talking about Kubernetes (as) boring. Getting to the point where it was reliable enough that it disappeared into the woodwork and folks didn’t think about it because they were just working and solving their problems. I think we have made good progress there. I feel like we’re getting this middle age where it is boring and it’s changing the tenor of the project in a good way, because folks are really depending on it.

Craig McLuckie: For me, I think, it’s interesting to see the evolution of Kubernetes. As, it started as almost a love letter to distributed systems engineers in the early days, indicating what could be. Embracing the idea of open design, open community, open development. And as it built into something that’s very real, it’s been just humbling and amazing to watch.

Where it is right now, it’s real. It’s fantastic. I spend a lot of time with a lot of enterprise organizations that are betting the farm on Kubernetes. They’re looking to go beyond Kubernetes as a primary platform for next-generation stateless-workload management. And they’re starting to really think about, “How do I create this platform that enables me to bring everything together?” Achieve their true Goldilocks abstraction: low-enough level you can run pretty much anything, high-enough level that it hides away a lot of the vagaries of the infrastructure.

When I look to the future I think there’s still a lot of work to be done to complete the offering in terms of hardening and getting the security there, working through a lot of the edge cases as we bring additional workloads into the platform. In terms of, “What am I most proud of?” I think the thing that I’m most proud of is seeing organizations really make it theirs. There’s a lot of folks that had every reason to take a look at Kubernetes as a competitive undertaking, like a Kubernetes that was threatening to an existing business or threatening to a set of technologies that they’d built.

And by and large, pretty much everyone, every significant vendor of scale, every power provider, every organization has, on the (cloud) provider’s side a Kubernetes strategy now. And it’s just been amazing to watch a lot of really big companies — that ought to be ostensibly be competing and trying to find ways to fit it to their environment in a unique way — really collaborating through this open and engaged community, and mutually advancing the needs and capabilities of all the end users. It’s just been wonderful to watch.

Tom Krazit: With the benefit of hindsight, what would you have done differently?

Brendan Burns: There were lots of mistakes. I don’t know that there’s … we corrected them along the way.

Joe Beda: One of the things that I … in VMware, we’re putting a lot of effort into the community is around how do you deploy and manage Kubernetes over time? And I think a lot of folks will use a managed service provided by the cloud providers, but I think one of the benefits of Kubernetes is it’s so flexible and go into so many different places.

We didn’t do a good job early on in terms of providing great tooling, great opinions, great guides in terms of the right way to run the system over time.mAnd I think we’re working on that now, but I think it took us too long to get there.

Brendan Burns: I think the other thing … there are two other things, now that I think about it, one is we didn’t build good integrations tests. And I think that haunts us to this day. We have unit tests and we have really heavy end-to-end tests. But if you want to do tests in that middle zone, really there’s not great infrastructure in the project and it’s one of those things that’s really hard to retrofit. We also did governance way too late. And we got lucky. And it didn’t really hurt us.

Tom Krazit: You mean in terms of a competing version emerging or … ?

Brendan Burns: No, no. I mean like project governance. Like when we brought the bootstrap committee together to set up the rules of how we were going to organize the project, we were too big. We did it reactively in response to seeing that we were growing too big. We should’ve proactively … I mean, it’s hard to know.

Joe Beda: So, a little bit of history. So, when we started the project a bunch of relatively senior engineers with a mostly aligned vision were just rolling up their sleeves and writing code. And that worked for quite a while.

But as the project got more complicated as we moved past the stuff that was obviously early on, as it became clear that it was going to be big business, you started ending up with conflict in the community. “Should we go this direction or that direction?” We now have a governance structure in place with a steering committee and all that type of stuff going on. But we waited too long to do that.

Brendan Burns: The really telling thing for me was this moment when we did the first community survey, and there was tremendous enthusiasm about the project, what it could do for people and all that sort of stuff. And there was tremendous confusion about how to get involved and where the project was going.

It was like, “people are really excited about this but they have no idea how to help and they have no idea how decisions are made.” And that indicated that we had a governance problem.

One of my biggest regrets as I look back on the history of Kubernetes is that we weren’t more efficient in aligning the world of Kubernetes and the world of Docker.

Craig McLuckie: From my side I would say, it’s very hard to figure out how to do this differently, but one of my biggest regrets as I look back on the history of Kubernetes is that we weren’t more efficient in aligning the world of Kubernetes and the world of Docker.

If you actually think about what Docker brought to the party in the early days was, it was legitimately ground changing. The ability to package up and atomically see all the workload, a really elegant and nicely put together tool chain…and I felt like we were collectively hurt.

The two communities were hurt because we were not able to really bring it together. And I think Kubernetes could’ve benefited tremendously from a lot of the design ethos and the developer-tooling experiences that Docker and the Docker community had brought together. And I think the Kubernetes community could’ve brought a lot of richness in terms of distributed systems capabilities to Docker.

And so, I don’t know exactly how we would’ve done this differently but if we could’ve had our druthers, I think bringing those two worlds together in a much more harmonized fashion earlier would’ve benefited everyone significantly.

Tom Krazit: That’s interesting because there was nominal competition really between what Docker was trying to do with Swarm and what Kubernetes was trying to do. And I don’t know if you see it exactly that way because it was an open source project versus what Docker was trying to do as a commercial company. (But) what would that have looked like, do you think?

Brendan Burns: Well, concretely, I don’t think there had to be competition in the orchestration space. I think there was … and I think this was a thing they did right, we really tried to draw a line and say, “Above this line we’re going to have an ecosystem and we’re going to have places where you can create your own tooling and your own experiences.” And you see the benefits of that today.

I think that we could’ve probably gone forward as a joint community in that spirit. It didn’t happen. But I’m with Craig, I think (not only) could we have influenced each other in really positive ways, but I think it also hindered adoption for a while, because there was uncertainty and you’d see vendors being like, “Well, how do I target my monitor? Do I target my monitoring at Kubernetes? Do I target my monitoring somewhere else?”

Consolidation helps the ecosystem move forward.

Tom Krazit: So, I want to definitely talk about things that are upcoming, and things that you guys are thinking about (now) as well. But I do want to take one more look back: who wrote the sloppiest code in the early days of Kubernetes?

Brendan Burns: That’s me.

Joe Beda: Well, no, okay. So …

Brendan Burns: It depends on how you count.

Joe Beda: Yeah. ‘Cause …

Brendan Burns: You wrote a lot of Bash (a type of Unix shell code).

I’m going to paraphrase him here, but Craig said something to me like, ‘You have really great ideas and you’re really innovative and you leave this trail of filth behind you like you would never believe.’

Joe Beda: Yeah. So, Brendan is really good at just splatting some stuff out there to actually prove a point and get something up and running. I think that’s his super power. But early on I did a lot of work that was janitorial work. And that included some of the early stuff about, how do we actually launch a cluster, at that point, on GCE? And it was … those are the sins that we’re paying for now in terms of the lifecycle tools. And that original stuff was … it was not pretty.

Brendan Burns: That stuff lived far longer than …

Joe Beda: I can’t believe it’s actually still around.

Brendan Burns: … anyone thought it would. Although I do remember at one point Craig saying something … I’m going to paraphrase him here, but Craig said something to me like, “You have really great ideas and you’re really innovative and you leave this trail of filth behind you like you would never believe.”

Craig McLuckie: (smiles and nods)

Joe Beda: That sounds like Craig, the word, “Filth,” is like yeah, definitely.

Brendan Burns: We all have our different strengths I guess.

Steering the ship into the future

Tom Krazit: What would you consider the biggest unsolved problem in distributed computing right now? If we accept that Kubernetes is more or less of a solution, it’s moving towards maturity, it’s hardening, it’s getting all these things that you guys are talking about … just look at the broader world of distributed computing. What’s the biggest unsolved problem?

Joe Beda: So, (there are) different definitions of distributed computing. I think it’s everything from consensus algorithms and how do you do database replication across regions with vector clocks and that stuff. I think we’re moving to a world where it’s like, that’s hard, (so) you make that somebody else’s problem. And we’re getting to the point where the patterns and the algorithms are packaged up.

If we expand that to include things like cloud APIs and stuff like that, I think one of the hard problems is generally configuration. And this is everything from Puppet, Chef, Terraform … in the Kubernetes world like Helm, Kustomize. There’s like a gazillion projects. And none of them get it 100 percent right.

I think whereas we have a real good library of ideas of how we build abstractions in sort-of the programming language level, we don’t have a good agreed-upon tool set instead of abstractions for how you actually build higher level concepts when it comes to cloud configuration and API systems.

Brendan Burns: That’s an infinite … we could spend an infinite amount of time on that topic.

I think from my perspective it’s too hard. For people who know how to build the systems, it takes too long and there’s not enough re-use. And also the total addressable space of developers who can successfully build cloud based applications is far smaller than it should be.

Like if you consider the number of developers who work on front ends versus the number of people who work in the cloud, that should be the same number of people, I think, or even more people working on the cloud. And it’s not. And I think that’s a failure of us in terms of, we build the systems up to a point and then we don’t really build systems that are easy for developers to use.

I don’t think Kubernetes is easy for developers to use.

Tom Krazit: That’s what I also hear.

Brendan Burns: And so, I think that’s an area that we have to do better on. And unfortunately it’s not an area where people who like to build things, like Kubernetes, also like to spend time. So …

In our industry user experience is a well recognized discipline, people get degrees in it, it’s whole departments, you have heads of UX. We need a similar type of movement around developer experience in the infrastructure space.

Joe Beda: In our industry user experience is a well recognized discipline, people get degrees in it, it’s whole departments, you have heads of UX. We need a similar type of movement around developer experience in the infrastructure space. And I think DX, or developer experience, is not as well recognized as a discipline.

Craig McLuckie: Configuration. Looking beyond the configuration space, there’s one thing that’s certainly on my mind at the moment which is establishing the … Joe’s actually done some work on this. But the idea of service identity as a first class entity. And being able to deal with identity in a highly connected federated world. Not just in terms of the user principles but being able to establish service identity as a first class entity is an incredibly important area that we need to invest in as an industry.

And I don’t think we’ve yet got to a point where that critical mass around how to service identity as a first class entity is there. If you look inside a place like Google, they have great systems to deal with it. A lot of the big internet companies have figured this out. But it just hasn’t been made accessible to enterprises holistically. And I think that’s going to be an area that we’d want to see happen in the next five years.

Joe Beda: I would say security in general though there’s a huge gap. It’s seen as this other thing, somebody else’s problem, something that’s either layered on after the fact. We don’t make security accessible to developers and an ambient thing.

Tom Krazit: Discounting the companies you currently work for, who do you think is doing some of the most interesting things on top of Kubernetes right now? We’ve had several companies represented among those companies here today, startups who are working on things using the Kubernetes API layer, some interesting ways that I think tackle some of those problems. When you look out at people who are tapping into the power of Kubernetes, what comes up?

Brendan Burns: I like to think more about the projects that are spinning up on top rather than … and I think that’s actually the right way to think about it in general. Like this has become such a ubiquitous layer, such a uniform layer that if you’re going to build something interesting on top of Kubernetes, it has to go everywhere. And so, generally the way to do that is to build an open source project and then figure out how you integrate it back into the products.

I’ve actually been spending a lot of time thinking about policy. I mentioned policy at the start but thinking about policy and the open policy agent work that’s in the CNCF. There’s some really interesting things there as people realize that, yeah, you can guard the exterior of your cluster but actually you need to also be making rules about the kinds of objects that get placed into your cluster. Like, what imagery repository are you using, or what tags are you putting on objects. That stuff turns out to be incredibly important for some of the security stuff that people are talking about.

Open and shut

Tom Krazit: That’s actually a good segue into one of the other things I wanted to talk about which is open source right now.

Joe Beda: That’s a hot-button topic.

Tom Krazit: There have been several interesting developments that are happening. Over the last six months we’ve seen several, mostly database companies change the terms of their licenses in order to be more restrictive. And usually with the threat of looming catastrophe placed on (them) by a cloud provider (used as justification).

If you were starting a project like Kubernetes again today, would you still make it fully open source? Would you think about that differently?

Brendan Burns: I would make it very open source. I think it was clear that for the infrastructure if it’s going to be ubiquitous it has to be open.

Databases may be different, I don’t know. I haven’t built a database. But for something that is in the stack where Kubernetes is, you need to have a whole bunch of different companies taking very significant bets on it. Has to be fully open, has to be vendor neutral. I think actually getting it to foundation is critical for its success. So, beyond open source, it actually has to be in a foundation.

Joe Beda: I think in terms of forming a company around open source I think that we’re seeing an evolution in terms of what those business models are. I think the critical thing is to solve a business problem. It’s not about the technology, it’s about the problem that you solve. And sometimes that problem is if you’re a cloud provider, how do you actually provide operations as a service.

But I think that there’s other business problems that, as you start looking beyond just the developer persona, how does that technology actually impact the rest of the organization that goes beyond developers, that goes into operations folks, that goes into decision makers. I think that goes beyond just open source.

And I think as you construct your business model, that’s what you have to think of. I think one of the problems though is that so many companies, and I think this is part of the startup froth, is that they start with interesting technology and they figure they’ll figure out the business model later. And I think you get this confirmation bias looking at companies like Google were you’re like, “Well, it worked out for them.” It doesn’t always work out.

I think that making sure that you do have a plan, in terms of, how is open source part of your strategy as a company versus “we’ll just put some stuff out there and see what happens,” (is important.)

Brendan Burns: But I think also the challenge for a lot of these is, as you said, they start with technology. They don’t start with a business problem. And so, therefore, they’re in search of a way to monetize.

I think you see this also a lot in the start ecosystem which is people just take too much (venture capital) money. And then they’re suddenly like, “Oh my god, I have to get revenue to … ” That puts a lot of pressure on people too.

So, I don’t know. I hope that this doesn’t turn into a big judgment on open source because I don’t think that’s the right way to think about it. But it’s also worth saying, Kubernetes was intended to be an open source project. There wasn’t a business there. It wasn’t intended to be a business onto itself.

Tom Krazit: Well, that’s one thing I’ve heard a lot of people worry about though too, is if open source enterprise development is basically funded by big vendors, there are potentially innovative projects could not really find a home, could not really find a way to get noticed out in the world, and to support the development, time and effort needed to get a project up and running.

Craig McLuckie: So, from my side, this is a perennial problem. And what Joe said, if you’re going to start a company, you better have a plan. And the plan can’t be, “open source… and then commercialize later.” You have to have a line of sight on a business problem.

The way I’ve looked at it is, there’s a set of classic commercial models around open source. The first is the distro play. And that almost always ends in disaster.

So, there’s the idea of, “I’m going to create a distribution. I’m either going to go completely open source and eventually I’m going to have a competitor that will show up over time if I’m successful, and they will just coast after my business. They will pick up my renewals, because there’s nothing defensive there. Their cost of sales is lower than mine because their customers have already deployed the technology and they just pick up the support subscription back in.”

Which leads to the open core philosophy, or esoteric licensing things where you try to create artificial wall gardens. That inevitably gets you on the wrong side of your own community. And bad things happen.

The second way to monetize open source is to be Red Hat. I don’t mean, be like Red Hat, I mean, literally be Red Hat.

The second way to monetize open source is to be Red Hat. I don’t mean, be like Red Hat, I mean, literally be Red Hat.

They created a very nuanced model. And they achieved their point of singularity in the community where … they’re able to be the proxy between the OEMs and ODMs and the ISVs established that point.

They had a very nuanced way of approaching open source commercialization. And I think every distro provider wants to become that. But I think there will only ever be one Red Hat.

The third way to monetize open source is obvious, which is, monetize a secondary effect. And the organizations that are most efficient at monetizing the secondary effect are cloud providers. The secondary effect is infrastructure consumption. So, anyone that is able to monetize the secondary effect has a vested interested in consuming open source.

I actually think there is a fourth model. And I don’t think this has fully proven yet, but my sense is that there’s a set of things that open source is really good at; in terms of gaining adoption, gaining traction, gaining ubiquity, there’s nothing bad about open source. I think we’ll end up in a world where the code that sits between a company’s applications and the physical infrastructure will ultimately be all open source. I think that will happen. But there’s a lot of stuff that open source doesn’t know.

Open source doesn’t know about itself. It doesn’t know if it’s properly patched, it doesn’t know necessarily how to manage and update itself. It doesn’t know how to optimize itself. So, I think there’s an opportunity to create an intersection between open source and SaaS-like data services that enable folks to be far more efficient in how they provision, deploy, manage, operate, consume open source technologies.

I think there is a significant business in that fusion between SaaS to do the things that open source can’t do to enable the consumption of open source and open source itself, that hasn’t been fully explored and materialized in the industry yet.

Brendan Burns: Yeah, I think that’s totally true. I think one of the challenges that we’re seeing right now is that the people who are really good at operationalizing software are in the clouds, because that’s basically what they do, is operationalize software. And it is too hard for other people to operationalize software.

They’ve driven up the expectations. Your user expectation of how you consume software is now, “I pay a monthly fee or an hourly fee and I get SLAs and all this kind of stuff.” That’s your expectation of software. It’s not, “Hey, I installed something and I read the manual and I figure out how to run it.”

And it turns out that it’s very difficult if you’re a small company to deliver that. And I think that we will see the clouds and others make that easier. And I hope that that in turn produces a software economy that works.

I think it’s very clear evidence that if you do a good enough job of producing a service, you can compete with the clouds. Snowflake is a great example of that. Everybody has a data warehouse and yet Snowflake continues to sell on Azure and to sell everywhere else. And there’s plenty of other similar examples.

Tom Krazit: But Snowflake was not an open source project…

Brendan Burns: But I don’t think I see it … this is the problem that I have, which is I don’t think that the licensing model matters. Maybe Snowflake needs to be a closed source, I don’t know, I have no idea. But I don’t actually think … I think it has to do with the open rationalization of the software and the challenges of operationalizing the software more than the licensing model.

Joe Beda: I think there’s an interesting recursive property here. I think Kubernetes makes it easier to actually run systems at scale, distributed systems at scale. So, it’s actually lowering the cost and complexity around creating operationalized software.

And so, as Kubernetes becomes a tool kit for operationalizing software, we may find that we’re able to decouple managed software from the underlying cloud in a way, like Snowflake. And I think that that’s going to be an interesting opportunity. I think Kubernetes actually creates a lot of opportunity there.

Craig McLuckie: The other thing I’d observe is there’s this very interesting fragmentary force that we’re starting to see in the industry right now. Like it would be reasonable, if you look at the ascendancy of cloud, to assume that we would be in a period of massive consolidation. That everything would be getting simpler, everything would become consolidated.

But the reality is, when you look at the world of modern enterprise, it’s actually going the other way. Every enterprise that I work with has multicloud procurement policies. They’re being forced by their procurement groups to buy across multiple clouds. In some cases the regulators are saying, “What happens if a hostile actor gets into the cloud’s control plane? What are you going to do then?”

There’s a longer term trend which is, the utility of cloud as it stands today is really around … I can put down a lot of infrastructure next to cheap electricity. And I can achieve massive economy to scale. But we’re also starting to see the distribution of the electricity supply. We’re starting to see the emergence of things like GDPR. In Europe we’re starting to see local data privacy laws that are creating for the fragmentation.

There’s nothing stopping the cloud providers from thriving and flourishing in this world and actually being able to address these intrinsically distributed problems. But we are seeing a period of massive fragmentation across the computational fleet at a period where I think everyone was expecting more consolidation. And so speaking to the need to operationalize, I think there is an impetus to be able to operationalize not just in a specific environment but across this highly fragmented, highly distributed fleet.

I think that’s where the next 10 years of massive enterprise outcomes for enterprise software vendors is going to be fought. It’s not just in the massive cloud data center but it’s in this incredibly distributed, highly fragmented computational fleet.

Tom Krazit: So, say you all get the startup bug and you want to start a company around an open source project. What’s your business model?

Craig McLuckie: Oh this is easy. Services. (Heptio offered professional services around Kubernetes before joining VMware.)

It’s funny, because cause the VCs would be like, “You’re just going to be Mirantis, right?” And it’s like, “No … ” I’m sorry, there’s nothing wrong with Mirantis, they did a wonderful job with OpenStack and we have to appreciate and respect the work they did.

There’s a lot of folks that say, “You cannot commercialize open source on the back of services.” And they’re entirely right. You cannot scale a services business. But you have to start there. Because nothing will teach you more about the challenges the complexities, the necessities that enterprise organizations have for consuming open source technology and services.

So, start with services and you will learn so much. You go and spend six months in a enterprise data center deploying your technology with a big customer that’s breathing down your neck, you will learn a few things.

That will then give you a platform that will enable you to start to identify where are the key operating gaps, where are the key challenges, what’s really hard about this technology, and follow the customer needs. You’ll learn so much through that process that will really lead you to identify where those key areas that you can invest in to solve problems are.

Brendan Burns: I would answer the same way in a slightly different venue, which is, I’d start with SaaS. Maybe it’s open source, but believe and know that you’re eventually going to have to become a SaaS company. And so start there.

Open source, as Craig said, is great for market penetration and adoption and enthusiasm, but ultimately people don’t want to operate software. They want you to operate software for (them). Realize that that’s going to be your business and go in head first there and you’ll stand a chance.

I think Google’s a unique place. They hire a unique type of individual. I think they’re learning hard lessons in terms of what it takes to deliver to real enterprises.

Joe Beda: Yeah, I think you end up with SaaS but I think that … you know, I spent like 10 years at Google. Not all developers are the same. That experience at Google in no way prepares me to understand what the day to day life for a enterprise job developer in Midwest Bank is like.

Tom Krazit: Do you think that’s to account for a lot of Google struggles in this (cloud infrastructure) market?

Joe Beda: I think Google’s a unique place. They hire a unique type of individual. I think they’re learning hard lessons in terms of what it takes to deliver to real enterprises.

Tom Krazit: So, with the few remaining minutes we have here, I just wanted to check in on one thing. Kubernetes is a long name. It’s frequently mispronounced and misspelled.

Brendan Burns: Kupernekeys!

Tom Krazit: And I read a report that you went through 13 different names before you settled on Kubernetes, before Google would approve.

Joe Beda: Yeah.

Brendan Burns: There was a lot.

Tom Krazit: So, what was your favorite rejected name?

Craig McLuckie: Oh this is easy. Carina.

Brendan Burns: Oh that was sad. I actually renamed the entire code base. I’d actually done it. Like applied name…

Joe Beda: It’s a nebula.

Brendan Burns: It’s a three starred thing. I’d actually gone through and renamed the entire code base and then we decided not to do that one.

Joe Beda: We did a Google search.

Brendan Burns: That’s true.

Joe Beda: And it came up with like a softcore porn star. And we were like … “that’s not a good name.”

Tom Krazit: Vetoed that one.

Joe Beda: I was really hoping for Project Seven. That was what I was really hoping for.

Craig McLuckie: I think, if I had to actually … The one I liked the best was Locutus.

Brendan Burns: Yeah, I was going to say that.

Joe Beda: Oh, Locutus, yeah, Locutus was good.

Craig McLuckie: That would’ve been good.

Joe Beda: So, that was the Star Trek character, it was the Borg translator. But it was tied enough to …

Brendan Burns: Locutus is Picard when he turns into the Borg. (The Borg is what Google called the internal system it used to manage its infrastructure, and Kubernetes is a stripped-down version of Borg.)

Joe Beda: Is that it?

Brendan Burns: Isn’t that right?

Joe Beda: Yeah, I don’t know.

Brendan Burns: I think that’s right. (Gestures to the audience.) They will know. (Audience concurs.) They told me. See?

Craig McLuckie: But yeah, the ambassador for the Borg. Yeah, that was a pretty good one.