CRAIG BOX: Hi, and welcome to the Kubernetes Podcast from Google. I'm Craig Box.

ADAM GLICK: And I'm Adam Glick.

[MUSIC PLAYING]

ADAM GLICK: This week, I got a chance to play with a new toy. Some of you may have played around with some of these SDRs, the Software-Defined Radios.

For those of use who like to play around with hardware, these are great little devices. They're super cheap these days. You can get them for around $25 or so. And you plug it into USB, and you can basically have a scanner that you can see the entire spectrum. And there's lots of open software that lets you do decoding of various things and just sniff around as to what's in the airwaves.

And I remember, oh, gosh many, many years ago when I was in college taking an old physical scanner and opening it up and soldering a tap onto the discriminator and then building a serial data acquisition board that I plugged into my old DB9 serial port in order to be able to grab POCSAG, which is what, if you remember pagers, what pagers would go out as.

And this just has that plus all sorts of other data transmission stuff built in. You can track airplanes travel and see them on maps. It's just a neat little toy. And so had one of those arrive this past weekend and have had fun playing with it.

CRAIG BOX: A number of questions. With your college radio experiments, were you listening in for the fuzz?

ADAM GLICK: (LAUGHING) The fuzz? No, I was mostly just tinkering around with the electronics and the building of it. And at that point, digital communications in terms of over-the-air, like broadcast digital communication, was not super common. You had a little bit of it with some of the radio stuff as it had evolved from single frequency to frequency hopping to spread spectrum to digital, and so just wanting to see what you could capture out there.

Plus, at the time, I actually had a pager. And I thought it was really interesting that you could actually tune in and capture the messages that went to every pager in the area because that's the way pagers worked because it was broadcast, and just see what was on those things. It was a fun experiment, kind of like a packet sniffer.

CRAIG BOX: A little bit. I do wonder about the legality of that, but I guess that they're just broadcasting everything out in the open.

ADAM GLICK: It is broadcast. And so it is legal depending on where you're at. There's some laws depending on your states about whether you can do those mobile or not. Usually, there are exceptions if you have a ham radio license, but broadcast is fine.

You get into murkier waters if you're decrypting things. So POCSAG is an understood format. It'd be like putting things in ASCII. It's not really encrypted. There are MDTs, Mobile Data Terminals, things you'll see most commonly in police cars. And usually capturing those and decrypting them will get you in a little bit of trouble, so I don't recommend that.

CRAIG BOX: Don't use this to listen to the fuzz. Can you can use it to communicate with the International Space Station?

ADAM GLICK: This is receive only. So the cheap ones are usually receive only. If you actually want to do you a broadcast and ping out, you can do it. It requires some more expensive ones. And that usually requires you to have some sort of ham radio license because it operates on the ham band.

CRAIG BOX: Will you be studying up for your ham license?

ADAM GLICK: I already have mine.

CRAIG BOX: Oh.

ADAM GLICK: For any of you that are out there, feel free to find me. I'm usually on 2-meter, 70 centimeter, which means it's local to the area here in Seattle. I don't normally go on HF.

CRAIG BOX: Do you have a call sign?

ADAM GLICK: Of course.

CRAIG BOX: Will you be sharing it with us?

ADAM GLICK: [LAUGHS]

CRAIG BOX: Breaker, breaker.

ADAM GLICK: You can hear my voice every week on this podcast.

CRAIG BOX: That's good enough. Let's get to the news.

[MUSIC PLAYING]

ADAM GLICK: SUSE has announced that it plans to acquire Rancher Labs, our guest on episode 57, for a reported $600 to $700 million. The companies point to their shared use and support for open-source software, as well as Gartner predictions that container management software use will more than double in the next four years. Congratulations to our friends at Rancher.

CRAIG BOX: Last week, Google announced the creation of a new independent industry body to manage open-source trademarks, the Open Usage Commons. Along with the announcement, Google said that trademarks relating to Angular, Gerrit, and Istio would be transferred to the body. A robust discussion ensued online regarding Istio from a number of people who had hoped for a different outcome.

Meanwhile, the members of the Istio Steering Committee from both Google and IBM are working on a proposal to extend the governance to more companies and community members, which is currently being discussed in the pull request on GitHub. You'll learn all about the OUC in today's interview.

ADAM GLICK: The technical oversight committee of the CNCF voted to move Red Hat's Operator framework into the incubation phase. The framework comprises an Operator Lifecycle Manager and an Operator SDK and was originally created by CoreOS in 2016. Also accepted at incubation level is Contour, an ingress controller for Kubernetes that provides a control plane for Envoy that was originally created by Heptio in 2017.

CRAIG BOX: The nine weeks of Google Cloud Next OnAir start today, and the first announcements are already in. BigQuery Omni, a new cross-cloud data warehouse service, will bring GCP's popular BigQuery to AWS and Azure. Of note for this podcast is that they have adopted Anthos as the platform for running on those other clouds. BigQuery Omni is a managed service and the Anthos clusters are run by Google. It launches an alpha for AWS with Azure support, quote, "coming soon."

ADAM GLICK: If you're running Spark, you're most likely doing it on Yarn. Support for running Spark on Kubernetes came in version 2.3, and since then the number of users has been growing. Data Mechanics has posted a new benchmark study showing a new milestone has been achieved. The results show no significant difference in performance between Spark on Yarn or Kubernetes. Check out their blog for all the graphs and data, but I suspect we're going to see more big data workloads coming to Kubernetes.

CRAIG BOX: Friend of the show, Tim Hockin, guest of episode 41, has published a slide deck explaining the different networking models available for multiple Kubernetes clusters. Running a single cluster with an overlay network is easy. But when you add multiple clusters, your options include using the same IP space in each with gateways, using completely different IP space, or giving up and sobbing into your IPv6 forever coffee mug.

Tim walks through all options except that last one, and helps explain why one size does not fit all. Given certain job postings going around the community this week, we should point out that Tim is one of a handful of people who could honestly have been said to have 12 years of Kubernetes experience.

ADAM GLICK: Pulumi, our guests on episode 76, have announced the addition of customized support to version 2.4.0 of their SDK. Kustomize, with a K, is a tool that allows you to customize, with a C, Kubernetes objects, and support for it joins the already existing Helm, YAML, and native SDK support.

CRAIG BOX: Security vendor Soluble has passed around the glass slipper and launched Cinderella clusters, hosted k3s clusters that last one hour before self-destructing in a cloud of fairy dust. They come pre-configured with agents that send telemetry to Soluble's service, and you get one per user free during the beta period.

ADAM GLICK: Google Cloud and HPE have announced HPE Greenlake for Anthos. Greenlake is a cloud-in-the-box solution which provides pay-as-you go infrastructure outside of the public cloud. HPE places capacity in your data center and allows you to grow into those added machines with utility pricing. This new partnership will allow the infrastructure to be used to run Google's Anthos as part of a hybrid environment.

CRAIG BOX: After announcing a recent developer collaboration with Microsoft Azure, which we mentioned in episode 106, Docker has launched a similar partnership with Amazon. New Docker ECS commands will let users deploy containers directly to ECS or Fargate with proper context support coming at GA later this year.

ADAM GLICK: Two other tooling updates from AWS this week-- AWS Copilot is the new name for the ECS command-line experience, and cdk8s+ extends the recently announced machine-generated cdk8s library with handcrafted artisanal API constructs.

CRAIG BOX: This week's Azure Kubernetes service release adds integration with Azure RBAC for controlling identities from the Azure portal and Azure policy using Gatekeeper to secure pods with Open Policy Agent both in preview. In return, pod security policies will be deprecated at a later date.

ADAM GLICK: Kublr has made a number of announcements this week. First is their support for Kubernetes 1.18 and the ability to do in-place upgrades of the platform and the cluster to reduce manual work and downtime. They have also decoupled their agent release from their platform release and have started a technical preview for external cluster support.

CRAIG BOX: Finally, it's no secret that Kubernetes skills are in high demand, and many organizations are looking for ways to get their teams more Kubernetes training. D2iQ has just announced Conductor-- on-demand, browser-based, hands-on training. Topics expand beyond just Kubernetes and reach other areas, such CICD, observability, and security. Access is gated through a contact sales form, and pricing has not been announced.

ADAM GLICK: And that's the news.

[MUSIC PLAYING]

Chris DiBona is the director of open source at Google. Welcome to the show, Chris.

CHRIS DIBONA: Thanks for having me.

ADAM GLICK: You've had a long career in open source. How did you get started?

CHRIS DIBONA: So I'm old? That's what we're leading on? [CHUCKLES] No, so I was doing my computer science program in the early '90s. And the Sun Workstation Lab at George Mason University in Virginia was crowded and hot.

And it was, charmingly put, filled with 'coder odor'. And I just remember I had homework to do and I was getting a little frustrated. And so I heard about this thing called Linux. And so I would install it, and it was pretty great. This was, I think, '95. I mean, it was like right after the first kernels had come out, and one of the first slackware distributions.

And so I just loved it. I just really, really loved it. I could do work at home and do a great job in my operating systems class and my compilers class. And then a couple of years later, I moved to California, and I joined the local Linux Users Group, and then I sort of took it over. And we grew it from 50 people to 1,000 people.

And then I joined a Linux company, VA Linux. I worked for Larry Augustin, who's still a good friend. And you know, the rest is history. We did a lot of stuff, and then I joined Google in 2004 as-- I'm using air quotes-- their open-source person.

And so I started here. And jeez, since then, we launched Developer Relations at Google because we needed a place to do open-source software. So we started Developer Relations at Google.

And then what else did we do? We did a lot of stuff. We released, I guess about 13,000 projects, 3,000 are 30-day active We've done a lot. So there you go.

CRAIG BOX: When you joined, it was actually two months after Tim Hockin. Was the company small enough that your paths crossed back then?

CHRIS DIBONA: More than you know. So when I started at Google, I referred a number of people, one of which was San Mehat. San and Tim were already fast friends, and they were roommates. So I would come to know Tim really well through San.

And San was initially on our kernel team, and then he was in our platform's group, which became known as technical infrastructure, which became known as cloud. Anyway, and then San would write the hypervisor that we would use that underlies all of Google and the rest.

And then San went into Android and did some great work there. And now he's in our Stadia group. But Tim, as you know, as everyone knows, he's wonderful in Kubernetes.

CRAIG BOX: What were the open-source problems Google had 15 years ago that necessitated bringing someone on to solve them?

CHRIS DIBONA: We didn't have many problems. We didn't have many products. We shipped the Google Search Appliance and a couple of other very, very small things, largely to ad partners. And so making sure they were in compliance with open source licenses was pretty easy in the grand scheme of things.

Craig Silverstein and Sergei and Larry and Mike Burrows had already put together some pretty solid guidance on how to bring software that wasn't written at Google into the company, into the code bases. So I just expanded on that work as a way of bringing discipline to incoming code and library and focus on that quality.

And then as we grew, we had a need to hire more people like, frankly, Tim and San. And so we had a hard time doing it, though, because our interviewing at the time was very much an engineer has to be able to work on search. They have to be able to work on platforms. They have to be able to work juggling and petting a cat.

CRAIG BOX: They need to figure out how many ping pong balls fit in the bus.

CHRIS DIBONA: Well, that's sort of spatial reasoning. That's easy. No. But then we would need someone who was the world expert in high-velocity network fabrics or SNMP. And we're talking about people who are so specialized and so niche that if you ask them a search and sort question, they're going to be like, I don't know why I'm here. And then you just won't hire them, right?

And so we had a problem. So Bill Coughran, who was my boss at the time-- and he's a legend in technology. He's now at Sequoia. Bill Coughran-- and he was on the board, I believe, of Docker and half a dozen other cloud-native companies. He would come to me.

Anyway, so Bill says, hey, Chris, would you please-- because I was doing a lot of hiring work at the time. He's like, would you please go into the platforms hiring committee with Walt Drummond, who I had referred, and will you fix it so that we hire the people we need in technical infrastructure and cloud and working for Urs? And I'm like, sure, sounds great. So we went in there and we started hiring, hiring, hiring.

And then when we bought Android, Bill said, OK, we're having trouble hiring for Android because they keep getting stuck in our normal hiring processes. Can you do for Android what you did for platforms? And I'm like, sure, sounds good. So that's what I did. We would hire, I guess 600 people through that hiring committee alone, and then yeah.

So I did a lot of hiring work early on. And the open-source developer community is a great place to hire because you have a lot of people who are enthusiastic developers who are very skilled who just want to work on software, just want to code, just want to release code too. So we were able to hire a lot of people very, very quickly. And it was pretty great.

And a lot of those people still work at Google. Like, the maintainer of Git, the version control system, works for me. So I'm really proud.

ADAM GLICK: [LAUGHS]

CHRIS DIBONA: So we have a lot of just fantastic people working for us, and it's been very rewarding.

CRAIG BOX: Have you ever tried to recruit the guy that created Git?

CHRIS DIBONA: That's a really funny story. So I've known Linus for a long time. I think I wrote on his immigration application back in the day. But I've known Linus a long time. We've talked about it. I've been helpful in his career because it's the right thing to do.

I don't think it's a problem. It's been 20 years. When VA Linux went public, we included 1,200 people from the open-source software movement, developers. So all the people who were in the Linux credits at the time and the Perl credits at the time and all the various important projects, we included them in our IPO. We provided shares for them. And so what's to say Linus gets more than other people?

ADAM GLICK: So when we think about open source, what's Google's perspective on it today?

CHRIS DIBONA: What I like to tell people is, what perspective do you want? Because I've got them all. If you look across the company, we have, I mentioned earlier, 3,000 30-day active projects. And those are from the very teeny, little projects and enabling code for APIs all the way through to really big projects like, oh, gosh, Android, Chromium--

CRAIG BOX: Kubernetes.

CHRIS DIBONA: --Kubernetes, things like Angular, Gerrit, and Istio. And just, I've always seen my job actually is not one of I don't have to get people excited about open source. I don't have to get people convinced that this is something that they want to do.

My job has always been to keep the wheels greased with release and with patching, because one of the truisms of any company as it grows is as you grow, things get harder to do. And so I didn't want to spend my whole time convincing people that a Kubernetes release was important. What I wanted to do was have every release happen at such a speed that there was no question, when open source was the right answer, that it could be done.

So to give you an idea, every day, I start the exact same way-- not with a podcast, although that does seem to happen a lot. Every day, for me, is very boring, OK? I wake up.

CRAIG BOX: Two eggs on rye.

CHRIS DIBONA: Nah, nah. Rye's OK, but rye is really for very specific kind of sandwiches. No. So I wake up. I get to my computer. I turn it on. I visit my list of pending launches, and I launch them.

And there's usually, in the morning section, lately-- we'll talk about that. But regularly, that's between five and eight open-source projects being released today, usually very small ones. And then about once a week will be-- let's call it a medium-sized one. And once every three months will be a Kubernetes-sized one from a code-commitment standpoint, right?

So I keep the wheels greased every day. I maintain the clockwork that is our releasing process. Our patching process for existing projects is actually asynchronous, and I'll sometimes have a number of emails saying human required, human intervention required, because they're in a situation that's complicated. It's an atypical license. It's to a partner who we're very, very careful about how we interact with them because we have relations with them across the company.

There's a lot of reasons that we say, hey, let's just take a minute and take a good, hard look at this particular patch and make sure it's OK. And so that happens. So we'll also see one or two of those a day-- oh, my team does. I don't really do a lot of them anymore. Yeah, so that's how I start my morning, is the "OSPO Task Notifier (palead)". I just walk down my work list.

But the thing is it's almost like a morning affirmation where it's like, listen, I know that for Google, every morning, I'm starting on the right foot. I am releasing software. I am making computer science better. I'm making the computer industry better. I'm making all these things better.

And that's how we came to be 1% of GitHub traffic. It's how we came to be in the position we're in with all of these projects, and it's fantastic. There is literally no downside. There's never been a downside to that level of contribution.

CRAIG BOX: Under which circumstances do you have to say no to those launches?

CHRIS DIBONA: In the old days, I used to say, OK, we can launch anything so long as it doesn't hurt the internet. It doesn't hurt search quality. Then we can do it. And so we would sometimes stall out on things that were meant to make web spam, address issues of web spam, because we'd be like, OK, we need to make sure we're actually not making web spam worse by creating these tools.

And also, we had to be extremely careful around things that could be perceived as search engine optimization tools. Because on one side, we really wanted the web to be more performant and faster. We had a whole project called Faster Web under Steve Souders, who I believe is now at Facebook doing work like this.

So we would come to evolve our releasing processes. We used to go through every patch to make sure it wasn't harmful. But then we got to this point where we were like, listen, actually, Googlers don't release things that hurt the internet. It's not in their nature. And so we decided to optimize for the 99.99% case and just say if it's a patch to an existing project under a proper OSI license and it isn't x, y, or z-- and the x, y, or z are always interesting-- then we can ship.

And then there was the case where we have competitors who don't like us or who are actively suing us. And so we had to be really, really careful how we interact with their copyright-controlled code bases. So we have some little red flags that go up.

But there are certain code bases with contributor license agreements that are way more grabby than ours. And so I would tell people, listen, I would love for you to patch into that project, but you can't because of our current relationship with that company. And how they collect rights in their contributor license agreement is way too aggressive, way more than we do or the Apache Software Foundation does.

And so in those cases, what we'd say is you can still release your patch, though. You just can't give it to them. So we would put it on GitHub. We would put it on our own site at the time. We would put it anywhere else, basically.

And then a funny, funny thing would happen. Customers of that code base would then find that patch. They would install that patch, and then they would go to the company, who was now upset with us and accusing us of forking or whatever. And they'd say to that company, we're paying you for support. We're using this patch. Support it, you know? So it was just like--

ADAM GLICK: That's kind of a long way around a PR there.

CHRIS DIBONA: It is a long way around a PR, but it also changed a lot of companies. Because the reality is when you patch as much as we do-- and this is actually why a lot of people are pissed at me from time to time or afraid of us, is because we understand open-source licensing. We know what it means to fork a code base.

We know what it means to accept a fork as the new mainline. We know what it means when our code is forked. And you know what? Maybe that fork's better. So you know what that means in open source? That means we can just take that code and run with it. And we don't have a beef.

So people really sometimes see us as being extremely aggressive when all we're doing is-- and I firmly believe this-- is we're doing what's best for the code base. And it's funny because in the context of cloud-native, I get accused of this all the time.

And I say to them the same things. I'm like, we want nothing from this code that you and your customers are not going to want soon. So we never architect and release open-source code to hurt other providers. That's not a thing. That is just not a thing.

So if we want to make a change-- like when Tim, this wonderful, wonderful person, he's like, you know what? The Kubernetes ingress API, it's outlived its utility. We have to advance it.

And so he looked at how Contour and Istio did network traffic. And he's like, you know what? I'm going to take the best of both of them, and I'm going to make that the new Kubernetes ingress API. And it was absolutely the right thing to do. And there were some people who were really, really upset about it.

And you know what? They're not upset about it anymore because they're all where we are now, right? So it's like, whenever somebody gets really upset that we're trying to move a code base in a certain direction, I just tell them, I'll talk to you in two to three months or in a year, and then this won't be a problem.

And then of course, they get upset with me. But it's fine. I'd rather they be upset with me than upset at Tim or someone else because they're just such neat people. They don't need people upset with them.

ADAM GLICK: You've talked about the 3,000-plus projects that Google has released. Is there a consistent definition that you use for success, or is that something that's more project-dependent? How do you define what success is when you undertake an open-source project?

CHRIS DIBONA: I don't. I don't. I leave that up to the engineers and the program managers and the product managers and all the rest. For me, I'm very tautological. A successful open-source project is an open-source project that's available under an open-source license. That is what expands the pool of available useful software.

So I consider it a success to release, a success especially to patch and to maintain. And then I would kick it back to you. It's like, what do you think is a successful Kubernetes participation? What do you think is a successful Istio release? What do you think is a successful Go iteration?

Because in the end, I never wanted to be a gatekeeper inside the company. Because some people in my position, they like to make sure that every byte that goes to the outside world goes through me. I don't want that. One, I'm really lazy, and that's a lot of work. But also, inside a company growing like Google has grown, there is no profit, there's no upside to me being the person who tells Chen Goldberg or Eyal Manor, who's now my boss, what's a successful product in the cloud-native space.

I like to say I'm sort of the rope in a tug of war sometimes between very powerful personalities in a company. And all I try to do is I say, if we go this direction, here are the potential outcomes. My goal is that they have all the information they need to make decisions under whatever rubric they want to decide.

So I have this meeting probably monthly where I say, if we go in this direction with this code base, this is likely to happen. Is that OK? And sometimes those are like, hey, if we go this direction, someone's going to fork and then we might have to rebase to theirs. And they go, OK, sounds like open source working the way it's supposed to. I'm like, OK. And if we're right, they'll rebase to us. It's like, OK.

So I consider my job to be one of letting people know outcomes and ensuring that open-source software continues to flow because I see it as the lifeblood of Google, right? We use so much open-source code. I believe that I'm unique in the industry in that I'm tasked with not just ensuring that Google is healthy, but also that the open-source developer community is healthy.

So this is why we've taken part in all these organizations going back to before my employment where I've worked on these things. But also, starting in 2004 at Google, I was the first person to fund the Apache Software Foundation, to join the Linux Foundation. We created-- and actually, that was not even me. That was me enabling people elsewhere in the company because I wasn't in cloud at the time.

When we created the CNCF, it's like, there was a discussion that happened. And we were like, OK, what does it mean to release Kubernetes as open source and in the nature in which way we did that, you know?

CRAIG BOX: Let's dig into some of those things. So as a consultant to these engineering teams, there are a number of ways that you can suggest that they go. There are projects at Google that are Google-purchased and operate themselves-- Android, Chrome, for example. There are projects that Google has created a foundation in order to host. There are projects that Google has just given to another foundation wholesale. Could you contrast a few of these different ways of operating?

CHRIS DIBONA: And this all happened in the last week.

[LAUGHTER]

Seriously. Yeah, OK. So again, I think I said earlier-- I was like, if you're looking for a model of open-source engagement, I'll find it for you inside Google, and I'll probably find it for you sometime in the last month.

So we donated wholesale AMP to a foundation. I think it was a Linux Foundation subproject. We donated Wasm two months ago to a W3C subgroup. We releaseed, on average, between five and eight projects a day just into open source from Google.

The thing is, what story do you want? I got it for you. And the thing is it is not inconsistent to say we have been very, very successful with projects that we've donated to foundations, and we've also been very, very successful with projects that we've kept and not donated to a foundation.

And I would say the commonality for all of them from my perspective is they're really open-source software. It means you can fork it. It means you can ship it. It means you can modify it and keep those modifications to yourself or bring them back into the mainline.

So if I were going to say one thing that makes our open-source releasing process successful, it's that we are literally everywhere. And the only commonality is that the open-source software license binds us together, right? So I feel like I'm Paul Atreides talking about the spice in "Dune." It surrounds us and encapsulates us and binds us all together. Or is that the force in "Star Wars"? I don't know.

ADAM GLICK: Spice is life.

CHRIS DIBONA: Spice is the life. Yeah, it's funny, because when we created the Summer of Code, which is a program that introduces new people into open-source and free software, we actually called the software we wrote to manage the Summer of Code Melange, which was the name of the spice in "Dune" because it brings the whole universe together.

ADAM GLICK: Speaking of things that Google does every week, last week, Google announced the founding of the Open Usage Commons.

CHRIS DIBONA: That's right.

ADAM GLICK: What is the OUC?

CHRIS DIBONA: One of the things that happens at Google is we hit the corner cases in open-source software licensing before anybody else. Often, frankly, we get sued over those corner cases before anybody else because open-source software licensing only covers copyright and patents, and they cover them in a very specific way.

So what does it mean when we hit those corner cases? And so the Open Usage Commons, which I honestly considered calling it the Corner Case Commons, but no one would have gotten the joke and that would have been the whole press cycle describing what I meant by that.

The Open Usage Commons was designed initially to look at the problems of trademark use and open-source software and provide guidance much in the same way that the Apache Software License and the GPL provide guidance around copyright and patents in accordance with the open-source definition, so that when we release open-source software projects that have trademarks attached, that people understand what they can do. And it's exactly tracking with what they can do with the copyright and with the patents in accordance with the OSD.

So I don't want to minimize the work, but it's just that. It's just we want to do some thinking about what it means to have trademarks and open-source projects. So over the last 15 years, when we've had trademarks on open-source projects that we released, people would accept them basically under the terms of the Apache License and they would assume an implied license to the trademark. And we'd be like, OK, sure.

But over the last three or five years, we were like, we really need to give them better guidance. And so we would create these one-off documents expressing what they can do with a trademark without violating or adding an additional restriction on the open-source licenses. And that would also extend to mascots. That would extend to logos. That would extend to all these unusual trade dress things and not just the names of things.

CRAIG BOX: In the cloud-native community, the project that matters the most in the context of OUC is Istio. Why did Google choose to put the Istio trademark into the OUC?

CHRIS DIBONA: Istio, Angular, and Gerrit all have third parties shipping it as a business. And so we wanted to have the first three marks that we put into the OUC have that commercial interest.

The thing about trademarks is if there's no one trying to resell something, a trademark is the easiest thing in the world to share. It's when people want to monetize a name that you have to start being careful. And so there was a lot of storm and drama.

We had created an Istio guidance document for the trademark and for the logo, and people wanted more and different. And I started noticing that what they wanted sometimes amounted to things that I would consider restrictions on the Apache License.

And the reason why I keep on saying restrictions, restrictions, restrictions is that if you read the Apache License in the later versions of the GPL, they say if you add additional restrictions to this license outside the license, inside the license, whatever, you're no longer covered by the Apache License. This license no longer applies. You're not open source.

And so I was like, I think it's clear that we need a standardized way of sharing trademarks consistent with the OSD. And back when we first started as a company sharing new projects, we didn't create the Google open-source license. And what I realized was we were basically creating a Google trademark license. And instead, I was like, you know what? We really need a neutral third party to create these standards. We need to do it with our friends in open source and computer science. And so let's do that.

So we created the OUC to create guidance that could be shared with anyone using these projects and move it forward. So we created the OUC with friends from academia-- from the CS dean of Georgia Tech, Dr. Charles Isbell, and then an old friend, Cliff Lampe over at the University of Michigan and their CS department, and then Allison Randall, who has been in open source longer than anyone-- frankly, other than me, longer than Tim, longer than Linux.

And she's really remarkable. She was on the Debian board for awhile. She ran Perl for a long time. She wrote the Perl Parrot compiler, which, if you're a Perl head, you know what I'm talking about. She's great. And then myself and Jen Phillips from Google.

And that's what we're doing-- oh, and Miles Ward. He's the CTO over at SADA, which is a system integrator. And he's sort of the voice of the cloud-native user, which is really important to us. We want to talk to the people who end up using the software and production.

And so that's, in the case of Istio, some very interesting companies. And they're all people that Miles knows. So we can make sure that we're creating the kind of regimes that make a lot of sense to those people using those software.

CRAIG BOX: There were two Googlers and a famous ex-Googler on the board of the OUC. Is this an organization that is independent from Google?

CHRIS DIBONA: So it is. The thing about Google that a lot of people don't seem to realize is that when we create a company outside of Google, if we have more than 49% of that company or if we vote more than half the shares of the company or vote more than half the board votes in that company, it is, for all intents and purposes, a Google company and it has to act like it in terms of how it interacts with antitrust authorities and the rest.

So we created the OUC to specifically be never under Google majority or even plurality control. And the thing is, one of the realities of Google and of people who don't like us is they don't believe you when you say stuff like this, and that's OK. They don't have to.

I mean, it's the kind of thing where time will tell more than what someone on Twitter says. Because we can honestly return to our knitting, come up with good guidance, and release it. And if I can convince folks at Debian that projects that use these guidelines belong within the Debian Free Software Guidelines, and so the projects that use it belong in the free software part of Debian and not in the non-free part, then that's an audience I care about.

Because here's the thing. I love my friends in cloud-native and across cloud-native at Google and the world. But if I get into the Debian package servers and I get my point across there, then everyone else falls into line because they consume Debian work.

And it's like, I don't have to convince everybody on Twitter with more than 12 followers. I have to convince open-source and free software developers in the Debian project. So those are the people. I mean, I care about the other people. Believe me. But I really care.

I said this to the Debian developers on a Jitsi call the other day. I was like, I would much rather talk with Debian developers any day of the week because they're idealists who believe in software freedom, and that is just so great. So this is my bread and butter.

CRAIG BOX: That all being said, cloud-native software isn't really installed through the app repositories anymore. There is an affiliation, at least with a lot of cloud-native software, with the Cloud Native Computing Foundation. There are a lot of people who have questioned why Istio was not donated or placed into the CNCF. What can you say to that?

CHRIS DIBONA: They asked this about Wasm when we put Wasm inside W3C as well, and they asked this about a bunch of projects. We support so many organizations, whether it's the W3C or the IETF, the SFC-- there are so many project-holding organizations.

And the CNCF is great. We are a platinum member, we helped create it. But we're not going to put every project into one organization. We're going to put it where we see fit to put it, or we're not going to put it in them at all.

The OUC doesn't impact Istio governance. We're consumers of the Istio steering committee's guidance around what to do with the trademark in the context of the open-source definition. And so I've spoken with Sean [Suchter] and folks about what it means for them to give the OUC help.

So we're going to have something along the lines of an Istio trademark escalation committee so we can figure out all the little corner cases that Istio represents. For instance, Istio, is it a piece of software or is it an API? When they create a conformance test for Istio, if some other project basically responds appropriately, would it be able to be called Istio, or derived from Istio, or is Istio-compatible?

I mean, what's the right thing to do? Because I can think of all of them being inappropriate inside the context of the open-source definition, and so can a bunch of Debian developers. So what does it mean for the team, though, right? So from a governance standpoint, we are passive consumers of the governance of Istio, Gerrit, and Angular. so that's fine.

CRAIG BOX: When you transfer the ownership or the marks of a project to a different organization, what actually moves and what doesn't?

CHRIS DIBONA: It's important that people get their own lawyers and legal counsel to think about this. But Google, because of our status as a very large commercial operator, we get to enjoy trademark status absent filing. So what we do when we transfer a unregistered trademark is we actually register it and make it formal. Then we transfer it over.

And there's these corners of trademark law where basically, in some cases, you have to not just transfer the mark to an outside board, you also have to transfer over some technical capability. So is that a conformance test? Is that something as simple as a registry? And how can you do those without being an additional restriction on the GPL and Apache?

It's one of those things where it's early days for the OUC. We really are just getting started. We knew that we had to talk about it to the outside world, but now we're returning to our knitting and doing all the things that are fundamental in the creation of a new organization.

CRAIG BOX: One thing that organization does not handle is copyright on source code. Who owns the copyright to source code contributed under the Google contributor license agreement?

CHRIS DIBONA: Ah, the CLA. So a lot of people are like, oh, the CLA is so harsh. So what we did is we took the Apache CLA. We replaced the word "Apache" and we put in the name "Google." And then we require people to click through, sign, in the case of companies, the CLA to contribute patches to projects that we release.

And it's funny because when we moved the Kubernetes code base to the CNCF, we required they maintain the CLA. And we're actually going through changes right now so that the CLA for Kubernetes can be signed much in the same way that DCO is signed.

Anyway, license nerds, keep paying attention. When you sign the Google CLA, much like when you sign the Apache CLA, you are not giving up copyright. You're giving us a non-exclusive license to relicense. And some people think that's to relicense to proprietary software. That is not the case. The reason we collect that right is because there are times when we want to change or update the license of a given project.

And a really good example of this is not in Angular because I think that-- oh, maybe it was Angular. Yeah, so we've released a lot of software into the JavaScript realm under the Apache License. And the reality is the JavaScript world doesn't care about the Apache License. They care about BSD or MIT and nothing else. Sometimes nothing at all, and we can't patch them.

But for the most part, they don't want to have anything do with the GPL, the AGPL, the Apache License, or any of the other licenses. They just use those two.

So we released-- I'm not kidding-- hundreds of projects under the Apache License because it's our default license. Some people wanted to release things. They would say, oh, I'll just use the Apache License. They would release some piece of JavaScript, and then they would be popular.

And then three or four months later, they come back and they go hey, so all these Java scriptees are asking me for a BSD version of this. Can I do that? And we're like, yeah, it's fine. Just change your license to BSD. You can do that because of the CLA. So even if you've taken patches, you can just do it.

And we hate maintaining dual-license projects. It's a huge pain in the butt from a bookkeeping perspective. So the CLA is there literally so that I can change the license and update it whenever the heck the user community needs it to be. And that's the great thing about the CLA and why we're going to keep using it.

And it's funny because we have literally tens of thousands of developers, probably even more than that now, who have signed and clicked through the CLA, the individual one. And then we also have thousands of companies who have signed, like wet signatured, the contributor license agreement. And these are every company involved in cloud-native, every single one of them.

So it's like, this CLA is fair enough that even people who absolutely hate us, who are actively suing us, have signed it because they see it as being the fair document consistent with our open-source values. So there you go.

CRAIG BOX: Given that CLA and now having a neutral body that owns the Istio trademark, is there any practical difference between Istio today and what it would be if it had been donated to the CNCF?

CHRIS DIBONA: Every organization runs things differently. So I think the CNCF is pretty high functioning, but I can tell you that there's bureaucracy in every single organization out there. And one thing that Istio hasn't adopted is another organization's bureaucracy. They have their own.

So they're keeping to their governance structures, which is multicompany. They're keeping to their intake policy, which is the CLA, and their technical committees which has, I guess, four companies in it.

I have to tell you, Istio, for a project its size, which I consider Istio medium-sized project. Even though I think it has a very complicated governance structure, it is efficient. And so long and short of it is the CNCF's great, but Istio's gone a different way. And I think it's a really fair and efficient manner in which they run their projects.

ADAM GLICK: Open source far predates the cloud. And since the cloud has come about, how do you think that's changed open source and how people view it?

CHRIS DIBONA: I don't want to anger you or your listeners. Not nearly as much as cloud thinks it has. I think that cloud has been an interesting use case of open-source software. And when I say "cloud," I mean basically Docker on out-- so Docker, Kubernetes, all the things around it.

I think that the impact on actual open-source software development has been nice, but not to the scale of something like Linux itself. Or even, I would say that LLVM is still a more important project than Kubernetes. I would say that EGCS is probably a more important project than many of them.

But I guess I'm sort of an old-timey fundamentalist. It's like, compilers, system software is exciting to me. When we wanted to release Kubernetes, I was like, OK, so Kubernetes, in my mind-- so let's go all the way back to cgroups.

In 2000, 1999-ish, so you had BSD jails and inside Solaris, you had an isolation system. I forget the name of it. And that goes back actually past to the Amdahl and IBM isolation systems inside their operating systems architected by some very talented developers.

And I remember when we were at VA Linux and San Mehat, whose name you heard recently, and Simon Horman, they worked on cgroups and system isolation inside the Linux kernel. And almost nobody really understood what they were doing except for a couple of people working on SELinux, which was a security-enhanced Linux product, because they saw in cgroups a way of doing process isolation for security, right?

So from that work, people would go on to create root jails and various things that looked like Docker before Docker did it. Docker did some really remarkable work in making that work accessible, and then Kubernetes did a lot of work in making that work manageable across large clusters. So I see what we all call cloud-native as an iteration of work that I have been attached to tangentially or directly-- because I worked on SELinux and I worked on some other stuff-- for 25 years.

So the next thing you're going to say is, but wait a second. There's so much commerce around it. Isn't it so important? And yeah, absolutely. There's is a ton of commerce around cloud-native. I will say, though, if you look at how companies like Google have distributed and used Linux from the beginning, there's a really interesting story in there that doesn't get said very much.

And it's funny because we did tell that story with the release of Kubernetes, right? So Kubernetes was born out of the Omega team, which was born out of the Borg team, which was born out of four Borg teams before it around system management. So I guess I just see everything as a continuum.

And I think that cloud software is really interesting, but then there's that person inside me who adores efficiency of data systems more than anything else. I think, wow, there's a lot of layers. They got to get out of the way. They got to get out of the way between me and the chip. But that's just me hammering that point like an old man yelling at the cloud.

CRAIG BOX: At the top of the show, you said you didn't want to be identified as the old man, but you've obviously had a long history here, which we've been very pleased to have you tell us about. One other place where you've been telling stories is as a technical advisor to the "Silicon Valley" TV show. When did you get onto that show?

CHRIS DIBONA: So "Silicon Valley," the producers-- OK, it's a little embarrassing. They came out to the area of Silicon Valley. And they said, hey, we want to take tours of companies. So this was right between seasons one and two.

They'd done some tours before season one. They came back after season one was successful, and they wanted to see more of the room where it happens here in the Valley. And Karen Wikcre at Twitter, she said to them, have you talked to Chris yet? And they were like, no, we don't know who this guy is. And they're like, go talk to Chris. I'm like, OK.

So she introduces me in email, and I say, hey, why don't I just get together a bunch of the old Unix nerds and have them come talk to you so you can just get an idea of what the Valley looks like from a deep technological perspective? And so we had a call, and I mentioned that one of the people I was bringing, he runs an ISP, which is he's been running an ISP in Palo Alto for 25 years. And he operates basically the Palo Alto fiber ring. So every company in Palo Alto that ties into the Palo Alto fiber ring, they talk to Joe, and he hooks them up, right?

And so they're like, wait, wait, that's a thing? That is an actual thing? And I'm like, yeah, fiber is a thing. And they're like, can we see it? And I'm like, sure. So we go over to Joe's ISP, which is over here off San Antonio. And we go in there. We've got a camera guy and a couple other producers there.

And Joe is honestly-- he's like a central casting Unix nerd, right? And so he shows them around his ISP, which is mostly empty because he's mostly just routing packets over at the Palo Alto Internet eXchange. And so he's got a bunch of empty racks-- well, half-empty. And then when we went into his back room where the actual tube comes out of the ground with the fiber in it, it turns out he was running a bitcoin mining operation. [LAUGHS]

And so there's just walls of GPUs running. And this is awhile ago, so everybody was still using GPUs. And they're just like, what is going on here? And it was kind of messy and dirty. And he's like, oh, just mining some bitcoin. And he's just like-- [LAUGHS]

ADAM GLICK: Chris, it's been fantastic having you on the show today. Thanks for joining us.

CHRIS DIBONA: Thanks so much for having me. I really appreciate it.

ADAM GLICK: You can find Chris DiBona on Twitter @cdibona, and you can find the open-source work from Google at opensource.google.

[MUSIC PLAYING]

CRAIG BOX: Thanks for listening. As always, if you've enjoyed the show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on Twitter @KubernetesPod, or reach us by email at kubernetespodcast@google.com.

ADAM GLICK: You can also check out our website at kubernetespodcast.com, where you'll find transcripts and show notes as well as links to subscribe. Until next time, take care.

CRAIG BOX: See you next week.

[MUSIC PLAYING]