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: Happy 100th episode!

CRAIG BOX: Whoo-hoo!

ADAM GLICK: We've made it to 100 episodes, which means we are at the two year mark here. And it's been an incredible journey.

CRAIG BOX: It has indeed.

ADAM GLICK: Haven't even come close to running out of guests or topics, which is an amazing statement about how big this community is and how much it's grown in the time we've been doing this. Special thank you to all of you who've been listening. We've seen our numbers grow tremendously over this time since we started at KubeCon back two years ago.

CRAIG BOX: We have the best numbers.

ADAM GLICK: [CHUCKLES] Craig, you kicked it off in the keynote, actually.

CRAIG BOX: Yes. Five of my 15 minutes of fame was spent talking about a couple of new announcements and sharing the news of this nascent show with the audience. And thank you everyone who came along to that and to everyone who subscribed since.

ADAM GLICK: Yeah. We've had literally tens of thousands of listeners who are listening to the show now. Ton of amazing guests. And some great notes about all the places that we've touched around the globe, right Craig?

CRAIG BOX: Yes. We've recorded episodes on four continents, and we've sent out a lot of stickers all around the world. I think we've probably hit six continents with those.

ADAM GLICK: Still waiting on Antarctica, I think. If anyone knows the artist in residence who is currently stationed at the South Pole, we would love to hear from them. Happy to send them a sticker.

CRAIG BOX: We'd love to hear from you too. Please, if you've enjoyed the show over the course of the last two years, just tweet to us at @KubernetesPod. We'd love to hear from you. If you've got any feedback at all, we'd definitely love to hear that as well. We're going to continue bringing you some great shows, including this one we've got here for you today.

ADAM GLICK: Let's get to the news.

[MUSIC PLAYING]

CRAIG BOX: VMware announced a number of commercial launches this week. Tanzu Kubernetes Grid Service, built on the cluster API, is now generally available, as well as Tanzu Kubernetes Grid, quote, "Integrated Edition," previously known as Pivotal Kubernetes Service, which is built on Cloud Foundry's BOSH. Tanzu Application Service 2.9 is generally available, and the Tanzu Application Service on Kubernetes is now in beta. Both are based on the Cloud Foundry runtime. Rounding out the announcements, Tanzu Build Service for Container Packaging is now on beta.

ADAM GLICK: Google Cloud has introduced surge upgrades for their Anthos GKE service. This feature provides fine grained control over node upgrades, allowing new nodes to be spun up before the old nodes are turned down, helping ensure higher availability during the automatic node upgrade process. Surge upgrades will be turned on by default for all new nodes starting on April 20th, while existing nodes will be migrated to the surge update system later this quarter.

CRAIG BOX: Microsoft has added different node pool types to the Azure Kubernetes Service. Spot node pools offer a way to use spare Azure VM capacity to lower node costs. Node pools can now be marked as system or user. Cluster needs to have at least one system node pool which runs the kube-system pods, and that must run on Linux. Using node pools can run on Windows or Linux, and can now be scaled to zero nodes.

ADAM GLICK: Portworx (with an x) has announced Essentials, a free version of their storage offering for persistent data in Kubernetes. Portworx Essentials is differentiated from their regular enterprise offering by the removal of support and day-two features like backup and capacity management and a limit of five nodes and five terabytes of storage.

CRAIG BOX: OpenShift Container Storage 4.3 is out, bringing support for using a local attached storage on AWS, VMware, and bare metal. Red Hat says that future releases will happen on the same schedule as the parent platform. So look out for 4.4 coming soon.

ADAM GLICK: Hiromi Ogawa has released Magicpak (with a k), a way of building minimal Docker images that avoid static linking. The tool looks for what dependencies are needed at runtime and only includes those, thus avoiding container bloat from libraries that aren't actually used. The project is open source and available on GitHub.

CRAIG BOX: Fairwinds has released an open source tool called Pluto to detect outdated resource types. You can run it on your cluster or on a directory of files, and it will identify resources that will fail to create after you upgrade to a version which deprecates those APIs. This will be especially of interest to anyone not yet running Kubernetes 1.16.

ADAM GLICK: Container Solutions open source container registry Trow was in the news this week. Trow is designed to offer quicker container boot times, better auditing, and greater control over the images that run in the cluster. It also removes an external potential source of failure.

CRAIG BOX: The Apache SkyWalking project is an open source application performance monitoring tool for distributed systems. Their recent version 7 release introduces distributed profiling, which lets you find which thread is slow across the distributed trace. In the post on "The New Stack," SkyWalking and Zipkin team members point out how this approach complements and extends distributed tracing.

ADAM GLICK: Speaking of Zipkin, congratulations to the project on the fifth anniversary of Open Zipkin. Zipkin started out in 2010 as a Twitter Hack Week project to implement distributed tracing, as described in the Dapper paper from Google, on top of the Apache Thrift framework. It was open sourced in 2012, and in 2015, it was forked into an open Zipkin repository, which Twitter then decided to make the official upstream.

CRAIG BOX: One year after their first commit to Envoy Mobile, Lyft is now testing it for production use. The ride sharing company has stabilized and hardened the library via experiments in their alpha and beta apps, and this week, started to expose a percentage of their production clients to it.

ADAM GLICK: In episode 94, Richard Belleville listed the many languages that gRPC supports. This week, the team added one more, Kotlin, the second most popular JVM language behind Java itself. Kotlin is commonly used on Android, and this release will make it easier to consume gRPC services from the mobile platform.

CRAIG BOX: Gloo, the Envoy powered API gateway from Solo.io, has been updated to version 1.3. It adds a developer portal for publishing and managing APIs, better integration with Knative, and extensibility through Wasm and Solo's WebAssembly hub.

Also looking at Wasm is the team from Banzai Cloud, who have written up an example of how to build an Envoy filter in C++ and deploy it for Istio. They present two options for deployment using the WebAssembly hub or secure private distribution using a config map.

ADAM GLICK: Alex Ellis, the founder of OpenFaas, has announced faasd, a way of running OpenFaas without Kubernetes. The new version promises faster cold start times, a smaller memory footprint, and not needing Kubernetes knowledge. But Ellis still suggests that all production use should still be on Kubernetes.

CRAIG BOX: Version 1.1 of the Kubernetes Fury Distribution from Italian company SIGHUP is out, along with a new website. KFD is unique in that it is a set of modules that are installed on top of an upstream Kubernetes installation or a vendor hosted version, such as GKE. This release adds support for open Policy Agent and Cert-manager, as well as traffic shaping via Calico.

ADAM GLICK: NeuVector has announced an addition to their platform for container security in the form of a vulnerability and compliance explorer. The new feature purports to provide for quick investigation, prioritization, reporting, and mitigation of vulnerabilities. High performance, large registry scanning, and enhanced node security processes have also been added.

CRAIG BOX: Infra has released vision 0.25 of their desktop Kubernetes app, with a number of updates, including support for Linux, outback support for connecting to clusters, and other fixes to server connectivity.

ADAM GLICK: Povilas Versockas has posted a deep dive on understanding node local DNS caching in Kubernetes, a feature which is currently in beta. He dives into how running a DNS cache on each node can decrease response times impacted by DNS lookup time outs and some existing issues with DNS response delays.

CRAIG BOX: It's always DNS.

Rich Stokes spent his last lockdown weekend building a project called Cheeky Monkey, a cross between Chaos Monkey in Super Mario Brothers. The game lets you play a monkey who jumps around the level causing chaos with crates. Every time the monkey destroys a crate, a pod in your cluster is randomly selected and deleted.

ADAM GLICK: Google Cloud has launched an e-book called "Anthos, Under the Hood." In it, they provide an in-depth look at each layer of the Anthos platform and how they can be used to transform Enterprise applications. Red Hat has also recently written a book on "Kubernetes Operators," published by O'Reilly, and they are making that e-book version available for free. Both can be downloaded in exchange for your email address.

CRAIG BOX: Cloud Foundry has added its new Kubernetes runtime to its certification program. The updated version of the Cloud Foundry Platform Certification now allows providers to choose Kubernetes, the Legacy Diego scheduler, or both as the container orchestration service.

ADAM GLICK: The Kubernetes Contributor Experience SIG has announced the creation of an upstream marketing team to focus on communicating to the tens of thousands of contributors to the Kubernetes project. Roles include internal marketing manager, social media manager, and storyteller, the last of which focuses on SIG profiles, contributor stories, and more. People with a penchant for words or design are being asked to volunteer, and you can find the link in the show notes.

CRAIG BOX: Congratulations to Lachie Evenson from Microsoft, our guest of episode 72, who yesterday joined the Kubernetes Steering Committee. He replaces Timothy St. Clair of VMware.

ADAM GLICK: The call for proposals for KubeCon US opens April 22nd. The event will be held in Boston on November 17th through the 20th. The co-chairs will be Constance Caramanolis and Stephen Augustus.

CRAIG BOX: The CNCF have published a Fluentd project journey report, the fifth such report for a graduated project. Fluentd, a data collection tool for log data, started in 2011 and joined the CNCF in November 2016, graduating a year ago. Since joining, the project has grown to over 7,400 contributors, 43,000 contributions, over 52,000 commits, and now has over 1,000 companies contributing.

ADAM GLICK: The CNCF is a member of Community Bridge, a platform offering paid internships to developers to contribute to open source communities. This week, they announced the graduation of seven interns comprising their first batch. Projects looking for interns to work on their projects can apply now for the next batch.

CRAIG BOX: And that's the news.

[MUSIC PLAYING]

CRAIG BOX: Paris Pittman is an open source program manager at Google, a member of the Kubernetes steering committee, and the guest of episode one of this very podcast. Welcome back to the show, Paris.

PARIS PITTMAN: Thank you so much for having me. It's been 100 awesome episodes, y'all. I'm so proud that this is a thing and that you get to highlight some of the end user and contributor journeys with the project.

CRAIG BOX: Well thank you. We were very happy to have you as the guest two years ago. How would you say the Kubernetes community has changed in that time?

PARIS PITTMAN: I would say both "exponentially", and also "not much". One of the exponential ways that we grow is through SIGs, working groups, and committees, as well as number of contributors. Back when I was first on, we had 13,000 contributors, which - even saying 13,000 out loud now is still like a wow moment - but today, it's 45,000. And to just kind of conceptually grasp that, that's larger than most companies and larger than most companies that even contribute to the project. So we have a humongous, humongous network of people to help us with this humongous project.

ADAM GLICK: Last time that we talked, we talked a little bit about how people communicate and we talked about how big the Slack was with Kubernetes, which is a pretty impressive 30,000 people back then.

PARIS PITTMAN: That's still like one of those numbers where you're like, is that really coming out of my mouth right now? But no, the second number that's shocking is today's number, which is over 90,000 people in the Slack with over like 250 channels. We have an entire admin team now, which is something we didn't have before either that was just George and myself and Jace just hanging out at one point, trying to manage 30,000 to 50,000 people. Now we have a team of almost 20 people that do all kinds of automation. And we've even done some cool stuff on like the code of conduct side for recording inside of Slack.

The Slack journey in itself has been wild. And Slack is really only one of five major ways that we communicate within the project.

ADAM GLICK: Indeed. Back then you also had 40 SIGs and working groups. We talked a little bit about those. Where are we at now?

PARIS PITTMAN: Yeah. Right now, we are at 30 SIGs. So I mean if, you know, we want to put a tilde there, we've got mostly 40.

The major changes have been with the cloud provider SIGs. Now we have a one overarching SIG for them called SIG Cloud Provider. We actually have a lot more working groups now, which is great, because it signals that there's a lot of cross SIG communication and collaboration going on with different temporary problems or issues that they're trying to solve.

There's also user groups and even more committees now, for example, the Code of Conduct Committee, the Product Security Committee. There's a ton of people doing work in these spaces and forming those community groups has really allowed that kind of intentional space and intentional work to happen.

CRAIG BOX: What is the process to merge SIGs, or wind down a working group?

PARIS PITTMAN: There is a lovely document in our community repo for that. It's a SIG/Working Group lifecycle doc. But it pretty much details out, if it's a SIG, for instance, getting a proposal together, shopping that around with people that are doing the work who think that we need to solve a problem, and then also getting it approved by the steering committee. So there's definitely a process there to get a stake up. And the reason being is that SIGs own code. There's not any other community groups that code-- I mean, maybe some committees might earn some automation and things like that. But as far as the code base is concerned, that's where the real work is happening within SIGs.

And then as far as like turning them down and retiring, we did had one recently retire, which is SIG PM. Stephen Augustus is leading that charge. But it's a process where they decided that it would be best to have their sub-projects, in this case KEPs, owned by different SIGs, and in this case SIG architecture.

So that's coming down. And that's totally OK. Goes into the archives, and we all move on.

CRAIG BOX: You mentioned the steering committee in your last answer, and since we've spoken, you have been elected to the Kubernetes Steering Committee. So first of all, congratulations.

PARIS PITTMAN: Thank you.

CRAIG BOX: What responsibilities does that give you? Being the chair for contributor experience for so long and being a sub-project owner there, I kind of call continue contributor experience the governance operations arm of the project, whereas steering committee is the governance with the policy and procedure. But since I kind of dabble between both and helping out both previously, it's not too much of a difference. Now I actually just get to vote and get to actually have a formal say instead of suggesting a vote or talking to other steering members about how I feel about that thing or that vote.

So it's definitely neat to sit on a steering committee with so many esteemed folks. And I was shocked that we had so many people run. And I don't necessarily mean shocked in a negative sense. So it's just great to see so many people from the community step up that wanted one of the steering committee roles. They really want to grow the community and see the community flourish and stay healthy. And honestly, my job is as a community manager, that really made me feel good.

ADAM GLICK: What has turnover been like in chairs and committees?

PARIS PITTMAN: I think, as expected, for the work that they do, believe it or not, it's a lot. I think the term chair can mean something different no matter-- you know, in the organization that you're in. And here, chair means that they're running the operations for that SIG or working group. Operations are things like making everything transparent, so having open meetings, open notes, having decisions and GitHub, things like that, but not necessarily having a say over the code or the code direction or the design proposals.

But we've had about 50% turnover since the last time I was on. And that's great, just because it's giving people new shots to take on those roles. Gives people fresh eyes, fresh operational eyes anyway. Anytime we turn over any kind of leadership role in our corporate jobs, it gives teams that kind of new fresh approach, or maybe even the same steadfast approach, depending on, you know, if the person grew up in that SIG or working group or whatever and they already had a good grasp on it.

So I think it's super important for our chairs to definitely have some kind of turnover there. I think turnover is actually very healthy for the organization.

ADAM GLICK: In politics, you sometimes hear people refer to things like term limits. Is that something you'd advocate?

PARIS PITTMAN: For sure. I think Apache and some other projects have term limits with some of their roles as well. And now we've hit this five year mark. And I think their term limits weren't necessarily decided from the jump, because you do want to see people grow and see where they take these kind of roles, and that's absolutely appropriate at that time. But now that we're here and it's been five years, I think we should probably talk about term limits and what that means.

Steering, for instance, does have term limits. We don't necessarily have like lifetime term limits. Maybe we should also have those too. But I think it's really healthy just to have this natural flow of folks in those roles.

ADAM GLICK: I also noticed that chairs and tech lead roles have split as the community has grown. Do you think that's the right choice that every project might want to do just from the get go, or is this a function of the community getting larger and specialization of roles and tasks?

PARIS PITTMAN: The latter, for sure. With open source, it's not like having a road map in your department at work, right? I mean, open source road maps are usually vague and ambiguous on purpose, because there needs to allow for growth and things to happen. But having a hard line on that in the beginning, bootstrapping, meaning having have split roles, is probably not the best strategy, because again, you want to see where things grow and where people take it.

But now that we are so large-- I mean, again, 45,000 people. Some of our SIGs are seeing, you know, 30 plus people join on their weekly meetings.

ADAM GLICK: Wow.

PARIS PITTMAN: So these folks are having to manage large departments on their own. Again, I just relate the word SIG to department, because it helps people kind of visualize things a little bit better.

But Yeah, it's really-- it's just the massive amount of folks that they have to manage, essentially. So people can experience burnout if you're hanging out too long in that kind of a role. So it's just really just naturally healthy to, at this point, possibly split roles and think about, OK, if I'm a chair, what are the other 90 things that I'm doing in this role, and could I essentially delegate some of that work to other people? And in this case, it could be the creation of a tech lead role, who then takes on things like sub-project creation decisions, design decisions. And then that role is also split between the facilitator and the person making some tough technical calls, which as we know, running large remote meetings and things like that, you really need a good facilitator. So that model between like split chair and tech lead really works when you need someone focused on facilitating in operations versus wearing both that decision making hat as well as a facilitator.

ADAM GLICK: Does that mean that the role of non-technical contributors in the community is growing?

PARIS PITTMAN: 100%. It's even more present now than it was before, I think, two years ago. There's too many groups, too many people, and therefore, a lot more glue.

CRAIG BOX: Not much love to go around?

PARIS PITTMAN: Oh yeah. Well, the love is the glue! The love is the glue, for sure. Tell people that all the time. I think that's the differentiator between our project and others is that we do have a lot of people working on the Gloo work and a lot of very passionate folks nonetheless.

CRAIG BOX: You mentioned sub-projects there. The Kubernetes projects started off as a single repository and now has hundreds of projects underneath. What does that look like in terms of community and governance?

PARIS PITTMAN: Sub-projects rule everything around me, is, I think, a good line there! We have over 200 sub-projects. And just to get a brief definition anyway, as brief as I can for a sub-project, it's really just the component, the initiative, the program that is under a special interest group. So it's that specific repo that might be a large component, a plug-in, whatever.

I like to compare it to business terms, and in this case, I consider them projects and programs. So it's kind of being in a PMO and all of those sub-projects would be your projects and programs. All of those folks have owners, because again, we do owners files and those owners-- and they're called sub-project owners, and they're the ones that are making tons of decisions day to day, technical day to day decisions on what gets merged, what gets put into a release, outside of the release team anyway. So that's really where the work is happening. And there's so many SIGs now that have over five sub-projects. So it's very, very in-depth and detailed.

CRAIG BOX: In the last two years, the CNCF has adopted the Kubernetes SIG model and now has SIGs of its own. You've been involved in starting the CNCF contributor strategy SIG. What can you tell us about that group?

PARIS PITTMAN: First, I think there is a difference a little bit between CNCF SIGs and Kubernetes SIGs. And they do use the same word, but there is a little bit of a difference and I think it's important to note that, which is Kubernetes SIGs do own code. CNCF SIGs do not, again, unless it's their own "meta-code" to help run their SIG from an automation perspective or something like that. But for the most part, they are an extension of the TOC, again, the technical oversight committee here in this case, that committee is made up of quite a few individuals, but they're responsible for the graduation and really cycling projects through different stages within the CNCF.

And right now, there's over 40 projects in sandbox incubation or graduated status. And these folks look to the TOC for different advice, as well as, again, graduating them and coming up with those graduation requirements. But the TOC is made up of super busy individuals, and they rely on these SIGs to help them out with either due diligence in that special area. For instance, there is another new SIF called Observability.

So when projects are going through these cycles, they call on these SIGs to give due diligence reports for instance, and you know, how is this SIG doing with this. And then also counsel those projects and give them advice. So in my case, I was just being a lurker on CNCF TOC threads for such a long time being in my silo with Kubernetes, I still, you know, had to kind of see what's going on at the TOC level.

But I noticed a ton of things around contributor related things, like contributor experience, growing and retaining contributors, questions around diversity, both company and individuals. That's when I realized there could be a good value add here to form a special interest group for the TOC to help them out with high level contributors strategy and help the projects out too so we can give them guidance, templates. We can give them talks on high level strategy stuff.

This SIG is not intended to do their day to day, but ideally, we would love to help other projects bootstrap things like a Kubernetes contributor experience. Helping them create that intentional space that will help them scale so that they never have one community manager and that it's always a group community effort. But that stuff takes time and it's very hard to bootstrap especially when you're busy with things like getting adopters for your project, which is also super important, and testing and security.

So this SIG is really there to help both the TOC and those projects really succeed in those areas. And right now, I have some other folks that have hopped on board with us, Josh Berkus, Gerred Dillon, April Nassi, so many others that also believe in this too and saw how much the Kubernetes contributor experience has helped the day to day operations of our project. So we would like to spread that love.

And selfishly, honestly, I'd like to learn as well. I mean, this SIG is going to be a huge listening SIG. I would love to hear what problems those projects are facing with contributor strategy and building their contributor bases.

And not only that, but I also want to know what's working. I've seen a ton of things going on within other CNCF projects where I've said, hey, wow, that looks really cool. I wonder if we could do that in Kubernetes? So also being a sponge and listening to some of these stuff that other projects are doing and taking it back to both Kubernetes and some of the other projects that our folks are really passionate about and active in.

ADAM GLICK: Community seems all the more important these days, especially with all that's going on with COVID-19, and social distancing is recommended for much of the world, and many of our listeners--

CRAIG BOX: And for much of the rest of the year.

PARIS PITTMAN: Yeah. Right.

ADAM GLICK: How has this changed how Kubernetes works?

PARIS PITTMAN: Well, we've always been a remote, distributed project. I want to say not much, but I know how insensitive that sounds with the current pandemic and current events. But I mean, as an open source project, and like most other open source projects, we make decisions online or in meetings that are public.

ADAM GLICK: I think it's great that so much of the stuff has already been happening online. For many of us, we haven't been doing most of our work in collaboration online. Are there any best practices that you think people have learned from the community that they can actually share outside of the community with people that are adapting to this new world?

PARIS PITTMAN: All of our guidance, especially communication related channel guidance, whether it's how to manage large Slack communities, whether it's Zoom, mailing lists, or just communication guidance in general and how to communicate and where to communicate what you're doing and whatnot, I think, is all things that either other projects or even companies can look to as guidance. If open source can run without, you know, everybody being in one location, then I think there's a good chance that a lot of companies can look to this as, well, maybe we can do this too and change our culture, or change what they're expecting out of their employees or change expectations in general.

CRAIG BOX: One specific tool that the Kubernetes community uses is the Zoom video conferencing tool, which has been in the news a lot lately with people joining meetings and causing grief this is a problem that I believe the Kubernetes community has had to deal with in the past. So what can other companies take from how Kubernetes solved this problem?

PARIS PITTMAN: We definitely have very explicit Zoom guidelines as well, and I know a couple of projects have already forked that, that are using Zoom too. But I think that some of the key takeaways there are for your Zoom administrators, or whoever is running your Zoom, to really understand some of those security settings. Zoom does have a lot of features to it, so it's important that folks really understand how to run any kind of tools that they're working with. I mean not necessarily just Zoom, but whatever teleconferencing that you're using. Understand the security, understand what that means for your community members, and also, get training for the people running those meetings and make sure that they understand how to deal with bad actors.

I think we're at a point in society where no matter what community you're in, you're probably going to have a bad actor of some variety. And it's not about not having a bad actor these days, it's about what you do when you do. So I think it's super important that people know how to deal with those situations, know you're not going to prepare for everyone. It's just the same thing on the security side of software. It's impossible to prepare for everything but you should still be prepared.

CRAIG BOX: Do you think that even when we are able to go back to having in-person events we should?

PARIS PITTMAN: Yes.

CRAIG BOX: What do we get out of the in-person events above and beyond the interaction we can have in these teleconferencing platforms?

PARIS PITTMAN: I think we have hit that limit of interaction that we can have with people on any kind of teleconferencing platform. I think the joy way that people get face to face, especially in the open source community, because again, we are mostly remote, mostly distributed teams that are working on this big gigantic project, and people get a lot of joy of just being able to shake someone's hand or give a hug if that's their thing. I mean, they're working with them on months at a time. You know how much goes into getting a feature GA, it's years. So some of these folks maybe don't work for the same company, but the only time to see each other is at a KubeCon or a contributor summit or something like that.

My personal hot take is we definitely have too many conferences in general and too many events in general, and we're all kind of evented out sort of anyway. But I think there is still a place for in-person events, I think they just might need to change it up a little bit.

CRAIG BOX: Conversely, I heard about a San Francisco company who have 400 employees in an office that they are now going to get rid of and instead fly the entire company two different times of year to somewhere in the world.

PARIS PITTMAN: Yeah.

CRAIG BOX: Do you think that model might be more common after this situation we're all in today?

PARIS PITTMAN: Definitely. I'm a fan. I won't lie.

CRAIG BOX: Depends where they're flying everybody.

PARIS PITTMAN: Yeah. And I think one of the things that also has worked that I've seen, you know, in comparing this project to a business, is I've seen companies having a hard time with having some remote employees, but then a lot of people in one office. So having the whole company go remote, making everybody need to work from home would be, I think, a better approach than having just a few people remote and feeling kind of left out from those conversations, especially those key hallway conversations.

ADAM GLICK: I think that is so important when you think about inclusion. It's very easy if you've got one or two remote people for them to feel like they're not included in everything. And when you have a fully remote culture, yeah, like the community has that really makes sure that there's an opportunity for everyone's voice. Although that said, I do hope that in-person events do come back I think that there is something about the human nature that I agree with you.

I also noticed that there was an announcement about a new marketing team. What can you tell us about that?

PARIS PITTMAN: It's a upstream marketing team. And I know, in engineering, sometimes marketing is a dirty word. But marketing is definitely needed. And we're talking about internal comms. We're talking about storytelling. But this is upstream work with Kubernetes. Like I said a million times already, we have a ton of people, we have a ton of groups. For us to talk about this stuff all the time would be very beneficial to people to understand what's the comings and goings of the crew.

CRAIG BOX: So when you talk about internal comms, a lot of times throughout this interview you've mentioned Kubernetes as a very large company. Are you talking about having all the other contributors be aware of what everybody is doing, or are you talking about the broader group of people who use Kubernetes?

PARIS PITTMAN: I would say the first objective is the contributors, and then the second objective would be end users. We are very specifically targeting contributors. However, there are things like KEPs, Kubernetes enhancement proposals, when they need end user feedback for alpha features for instance, and sometimes that's hard to surface. Getting things like our own contributor Twitter, for instance, would amplify some of the stuff that we need feedback for. But for the most part, this is 100% contributor related content, making sure that there's cross, say, collaboration going on, making sure that the work that these folks are doing is being told.

Because again, we are not just releasing, but constantly changing things for even the better. Whether it's new mentoring programs for code reviewers, whether it's new communication platforms that better target certain issues, people just need to be in the know. Being on the same page is super important, especially if you're very active in the project. If you're a drive-by contributor, it's not on your level of importance probably. But we have anywhere between 600 to 1,000 very active people a year, and obviously, very active isn't a standard definition. It's mine, and I consider very active, you know, someone that has like--

CRAIG BOX: That they're all doing YouTube PE in the morning.

PARIS PITTMAN: [CHUCKLES] So over 50 contributions a year. And that's actually, for instance, for the last steering committee election, that's what was defined as a member that could vote. So in my opinion, very active members are voting members for the steering committee. So again, that's not a project definition, that's my personal definition. So again, these 600 to 1,000 people really need good communications, first and foremost. So it's very important to us that we see that through.

ADAM GLICK: This is a really interesting idea, because I normally think of marketing and PR teams as people that operate not necessarily in open source. That they work very much in how do they keep those pieces of information together and put them out at particular times. Is there a precedent to have an open sourced marketing organization.

PARIS PITTMAN: Yes. Fedora actually has one. So shout outs to Fedora. You can see where all their info is located just with a simple Fedora marketing team search. But I saw that, and they definitely have a focus on release.

And then there's also a past precedent that we have in Kubernetes as well, which is there's a comms manager on the release team itself. That person is responsible for doing things like blog posts about the features describing the features that are in each release but again very scope to release and then we also have, on the contributors summit team they chiseled out a role for communications there. And again, we're running between 400 to 500 person contributor summits at least once a year at this point, so it's pretty much like a mini conference. So that person is very much scoped into doing communications for that.

So there is definitely prior art, and we see the need for people that do this dedicated work. We've even created an ethos as well. We have a charter, if you want to take a look at that so you can see kind of what our focus is and our guidelines. We have social guidelines now. So again, we're going to have our own contributor Twitter account. We also will eventually have a contributor website as well.

We just have so much documentation, y'all. I can't tell you how much documentation we have. From a community angle anyway, if you look at the Kubernetes community repo, it's just documentation of documentation on how to run a community and stuff that's really, really necessary to get surfaced, things like the developer guy for instance and API conventions. The API conventions doc is by far and away our most viewed doc in the community repo. So surfacing some of that information and having that information discoverability improve is really the main goal and objective for this crew.

And so just making sure that the flow of information is going that people are actually reading the stuff that they need to read. Using things like action required or action requested, again, like that internal comms piece. So there's a lot of things going on there, but it's so, so, so necessary.

CRAIG BOX: Jono Bacon from Ubuntu wrote a book on community management many years ago. Do you think that from everything the Kubernetes community has learned, it might be time for your group to publish a similar book?

PARIS PITTMAN: [CHUCKLES] I do! That is one of the books that I keep on my desk. I only keep a few, but that was the-- for me, the guideline on building communities, at one point.

I definitely think that we could get a more modern version of that. Especially when we talk about communications, Jono does have a communications chunk in the book as well. But now that we've got the real time communication like Slack and other vehicles, Meet, et cetera they're here to stay, we really have to account that kind of communication style within projects as well and figure out how to make sure that that stuff is still transparent and things like that. So we could definitely write a chapter, that's for sure. Whether or not we read a whole book is another story, but for the most part, yeah, I definitely think that we can do at least an addendum.

ADAM GLICK: Sounds like we definitely need to build a working group, possibly another SIG on SIG community management book.

[PARIS LAUGHS]

PARIS PITTMAN: Well, technically, I don't know, that would probably be some project of contributor experience.

ADAM GLICK: Fair enough. Fair enough.

PARIS PITTMAN: Now you know what I do in steering committee, FYI. When there's, hey, where does this thing go, it's probably, oh, probably in the SIG kind of thing.

ADAM GLICK: You mentioned that you had only a few books on your desk, and that community management was one. What are the others?

PARIS PITTMAN: One of them is an O'Reilly Linux pocket guide, which is hilarious, because obviously, I know what Google.com is and, yes, I absolutely Google every Linux command I ever could possibly need. But for some reason, it just kind of sits there and it's just like a good reminder of how I've turned my life around, if you will. I got that book at a good time in my life at a Oz Con, which is no longer going to be a thing either. So it's kind of a memory book, if you will. And then there's some other books that my mom gave me a long time ago, like Dr. Seuss, so "The Places That You'll Go" and just some other sentimental books. But as far as professional books, that is between a Linux pocket guide and the Jono Bacon community book that those are the only two that are sitting there.

CRAIG BOX: We've talked a lot about what has changed in the community over the last two years. What hasn't changed? What are things that you feel that you really nailed the first time?

PARIS PITTMAN: The sense of belonging. There's so many of us that have come together, especially in this time in this pandemic, and have really just had a strong sense of community.

And we do work across companies. Some of those companies compete, and we all have this understanding and camaraderie and respect for each other. And honestly, that hasn't changed after five years. Like, you know, sure we get into individual spats and discrepancies, and that is the human condition. But for the most part, we're all still here and kicking and loving it. You know, like I said, we all have bad days for the most part, but that hasn't changed.

ADAM GLICK: If we're fortunate enough to have you back a third time, two years from now, what do you think would have happened with the community? What should change?

PARIS PITTMAN: Probably getting some more mentoring program smoothed out for key roles that are a little bit more ambiguous, like for instance, code reviewers. We're close, but we're not there yet. I mean, this is obviously another problem that all open source communities go through, which is, you know, how you build trust. And especially quickly, or how do you scale trust, things like that. So in that time period, I hope we can get our act together there, because trying to transfer institutional knowledge is difficult when you need to do it quickly for whatever reason. So I definitely think that we could do some things there.

CRAIG BOX: Finally, the last time we talked about community on the show was with Jorge Castro in episode 74. And he mentioned that one thing that a lot of Kubernetes people do was play online games, and Destiny II was the game of choice at the time. What's everyone playing at the moment?

PARIS PITTMAN: [CHUCKLES] Well, some are still in their Destiny hole. However, a ton of us are on Animal Crossing hopping between our islands and trying to stay safe inside and sane, and also not work all of the time. Now that we're all hanging out inside, it's super easy for us to pick up that extra PR, file that other issue for things that you just thought about. And Animal Crossing gives us this kind of space to escape. And it's not a video teleconferencing call where we are all just kind of staring at each other, which is awesome too.

But Animal Crossing is awesome, and I'm so happy that we can all kind of find community here together. We've even blended some communities via islands as well. So it's been pretty neat.

CRAIG BOX: Where would someone go if they wanted to join your game?

PARIS PITTMAN: Twitter. We use just the Animal Crossing hashtags, and if somebody-- and you can say Kubernetes if you want to. But all of us are active Twitterers monitoring the Animal Crossing hashtag. Shout out to April Nassi who is on the freaking ball with figuring out like what islands have the best furniture and fruits and stuff like that. So we've got April looking out for us and, yeah, we've got, like I said, like a little small community of Animal Crossing experts to say the least.

CRAIG BOX: I've never played the game, but the way you describe it makes it sound like a cross between the Sims, Minecraft, and Bed Bath and Beyond.

PARIS PITTMAN: It is! [LAUGHS]

ADAM GLICK: You missed your calling in video game marketing, Craig.

PARIS PITTMAN: I know! Craig, that was really, really good. Honestly, yes. That's like you want to build the city you want to live in right now, except it's on an island, and who doesn't want to be on an island right now? I mean, sure maybe you'd prefer snow capped hills or something, but who doesn't want to be on an island, tending to a garden, picking fruits, talking to neighbors. Putting on like high fashion, because literally, they have high fashion in Animal Crossing. Who doesn't want to, right? And they're super cute.

ADAM GLICK: That's fantastic. As a gamer, I love that the community is coming together on things outside of just building the software. It truly is a community.

Thank you very much for joining us. As last time, it was fantastic having you on, Paris.

PARIS PITTMAN: Thank you so much. I really appreciate it.

ADAM GLICK: You can find Paris Pittman on Twitter @ParisInBmore or on community Slack as Paris, and as mentioned previously, on Animal Crossing.

[MUSIC PLAYING]

CRAIG BOX: We hope you enjoyed our 100th episode extravaganza.

ADAM GLICK: Whoo!

CRAIG BOX: Thank you again for listening. If you've enjoyed the show, please tweet to us at @KubernetesPod and let us know. We're under lockdown too. So it's great to know that we're being heard all around the world. And we'd love to take any other feedback, either by Twitter or email to kubernetespodcast@google.com.

ADAM GLICK: As always, you can check out our website and get our show notes at kubernetespodcast.com. Until next time, take care.

CRAIG BOX: See you for 101.

[MUSIC PLAYING]