 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon North America 2020 virtual brought to you by Red Hat, the Cloud Native Computing Foundation and Ecosystem Partners. Welcome back to theCUBE's coverage, virtual coverage of KubeCon and CloudNativeCon 2020. We're not in person this year. Normally we're there in person. We have to do remote because of the pandemic, but hey, opens up more conversations and this is theCUBE virtual. I'm John Furrier, your host and you see a lot of interviews. We've got some great guests talking to the leaders, the developers, the end users, as well as the vendors with the CNCF. We've got two great guests, Priyanka Sharma, the general manager of the CNCF. Great to see you and Steven Augustus, OSS engineer at VMware. There's also the KubeCon co-chair back on theCUBE. Thanks for coming on folks, appreciate it. Thank you for having us. So thanks for coming on. Obviously remote and virtual. We're doing a lot of interviews. We're getting some perspectives. People are chatting in Slack. It's still got the hallway vibe feel, a lot of talks, a lot of action, keynotes happening, but I think the big story for me and I would like to talk about and I want to get your perspective is this new working group that's out there. So I know there's some news around it. Could you take a minute to explain kind of what this is all about? Sure, I'll give a little bit of context for those who may have missed my keynote, which very bad. As I announced, I'm so proud to be working with the likes of Steven Augustus here and a bunch of other folks from different companies, different open source projects, et cetera, to bring inclusive naming to code. I think it's been a forever issue, but frankly we've had many problematic terms in software out there, the most obvious one being MasterSlave. That really shouldn't be there, that have no place in an inclusive world, inclusive software and inclusive community. With the help of amazing people like Steven, folks from IBM, Red Hat, and many, many others, we came together because while there's a lot of positive enthusiasm and excitement for people to make the changes that are necessary to make the community welcome for all, there's a lot of different work streams happening and we really wanted to make sure there is a centralized place for guidelines and discussion for everybody in a very non, ban organizational kind of way. And so that's the working group that John is talking about. With that said, Steven, I think you can do the best justice to speak to the overall initiative. Yeah, absolutely. So I think that to Priyanka's point, there's lots of people who are interested in this work and again, lots of work streams where this is already happening, which is very exciting to see. But as any good engineer, I think that it's important to not duplicate your work. It's important to recognize the efforts that are happening elsewhere and work towards bringing people together. So part of this is providing, being able to provide a forum for discussion for a variety of companies, for a variety of associations and foundations that are involved in inclusive naming efforts. And then to also provide a framework for walking people through how we evaluate language and how we make these kinds of changes. As an example for Kubernetes, we started off the Kubernetes working group naming and the hope for the working group naming was that it was going to evolve into hopefully an effort like this where we could bring a lot of people on and not just talk about Kubernetes. So since we formed that back in, I wanna say, June-ish, we've done some work on providing language evaluation framework, providing templates for recommendations, providing a workflow for moving from just a suggestion into kind of actuating those ideas, removing that language. Where it gets tricky in code is thinking about, thinking about say a Kubernetes API and the fact that we have API deprecation policies and that's something that we have to, if offensive language is in one of our APIs, we have to work through our deprecation policy to get that done. So lots of moving parts but very excited about the overall effort. I mean, your mind can explode if you're just thinking about all the complications involved but I think this is super important. I think the world has voted on this. I think it's pretty obvious and Priyanka, you hit some of the key top line points, inclusive software, right? This is kind of the high order bit. But when you get down to it, it's hard as hell to do because if you wanna get new namings and or changing namings accepted by the community and code owners, you're dealing with two things. A polarizing environment around the world today and two, the hassles involved which includes duplicate efforts. So you got kind of a juggling act going on between two forces. So it's a hard problem. So how are you tackling this? Because it's certainly the right thing to do. There's no debate there. How do you make it happen? How do you go in without kind of blowing things up if you will and do it in a way that's elegant and clean and accepted? Because that's the end of the day. Acceptance and putting it to code owners. Absolutely. I think, so as you've said, right? We live in a polarizing environment right now. We, most of us here though, know that this is the right thing to do. Team cloud native is for everyone and that is the biggest takeaway I hope people get from our work in this initiative. Open source belongs to everybody and it was built for the problems of today. That's why we're working on this. Now, when it goes into actual execution, as you said, there are many moving parts. Steven and the Kubernetes working group is our shining example and a really good blueprint for many folks to utilize. In addition to that, we have to bring in diverse organizations. It's not just open source projects. It's not just companies. It's also standards organizations. It's also folks who think about language. It's folks who have literally done PhDs in the subject. And then there are folks who are really struggling through making the changes today and tomorrow and giving them hope and excitement. So that at the end of this journey, not only do you know you've done a right thing, but you'll be recognized for it and more people will be encouraged by your own experience. So we and the LF have been thinking at it from a holistic perspective. Let's bring in the standards bodies. Let's bring in the vendors. Let's bring in the open source projects. Give them guidelines and blueprints that we are lucky that our projects are able to generate. Combine it with learnings from other people because many people are doing great work so that there is one cohesive place where people can go and learn from each other. Eventually, what we hope to do is also have like a recognition program so that it's like, hey, this open source project did this. They are now certified X or there's like an awards program. We're still figuring that piece out but more to come on that space. That's my part, but Steven can tell you about all the heavy lifting that they've been doing. Before we get to Steven, I just want to say congratulations to you. That's great leadership. And I think you're taking a pragmatic approach and you put the stake in the ground. And that's the number one thing. And I want to take my hat off to you guys and Priyanka, thank you for that leadership. All right, Steven, let's talk about how this gets done because you guys open source is what it's all about. It's about the people, it's about building on the successes of others, staying on the shoulders of others. You guys are used to sitting in rooms now virtually and squabbling over things like code reviews and you got governing bodies. This is not a new thing in collaboration. So this is also a collaboration test. What are you seeing as the playbook to get this going? Can you share your insights into what the Kubernetes groups doing and how you see this? What are the first few steps you see happening so people can either understand it, understand the context and get involved? So I think it comes down to a lot of it is scope, right? So as a new contributor, as a current contributor, maybe you are one of those language experts that is interested in getting involved. As a co-chair myself for SIG release, a lot of the things that we do, we have to consider scope, right? If we make this change, how is it affecting an end user? And maybe you work in contributor experience, maybe you work in release, maybe you work in architecture, right? But you may not have the entire scope that you need to make a change, right? So I think that first it's amazing to see all of the thought that has gone through making certain changes, right? Discussing master slave, discussing how we name control plane members, doing the, you know, having the discussion around whitelist and blacklist, right? What's hard about it is when people start making those changes, right? We've already seen several instances of, you know, a invigorated contributor, maybe a new contributor coming in and starting to kind of like search and replace words, right? And I wish it was that simple. It's a discussion that has to be had. It's, you know, you need buy-in from the code owners, right? If it's an API that you're touching, it's a conversation that you need to have with the state architecture as well as SIG docs, right? If it's something that's happening in release, you know, in release, then it's a little easier because you can come talk to me. But, you know, overall, I think it's getting people to the point where they can clearly understand how a change affects the community, right? So we kind of, in the language evaluation framework, we have this idea of like first, second, and third-order concerns, right? And as you go through those concerns, there are like diminishing impacts of potential harm that a piece of language might be causing to people, right? So first-order concerns are the ones that we want to eliminate immediately, right? And the ones that we commonly hear this discussion framed around, so master-slave and, you know, whitelist, blacklist. So those are ones that we know that are kind of like on the track to be removed. The next portion of that is kind of like understanding what it means to provide a recommendation and who actually approves a recommendation, right? Because this group is, you know, we have several language-efficient autos in this group, but we are by no means experts. And we also want to make sure that we do not make decisions entirely for the community, right? So discussing that workflow from turning a recommendation into actuating a solution for that is something that we would also do with the steering committee, right? So Kubernetes is kind of like top governing body, right? So making sure that the decision is made from the top level and kind of filtered out to all of the places where people may own code or documentation around it is, I think it was really the biggest thing. And having a framework to make it easy to do those evaluations is what we've been craving and now have. Well, congratulations. That's awesome. I think it's easier said than done, right? I mean, when you have systems and code, it's like there's always consequences in systems architecture. You know that, you know large scales, OSS, you guys know what that means. I think the low-hanging fruit, obviously, master, slave, blacklist, whitelist, that's just got to get done. I mean, to me, if that just doesn't get done, that's just like a stake in the ground. That must happen. But I think this idea of it takes a village, kind of is that play here. People just buy into it. That's, so it's a little bit of a PR thing going on too, for get buy-in. This is again a classic, you know, getting people on board, Priyanka, isn't it? It's, you know, the obvious. And then it's like, okay, let's just do this. And then what's the framework? What's the process? What's the scope? Yeah, absolutely agree. And you know, many people are midway through the journey. That's one of the big challenges. Some people are different phases of the journey. And that was one of the big reasons we started this working group because we want to be able to provide a place of conversation for people at different stages. So we can align now rather than a year later where everybody has their own terms as replacements and nothing works. And maybe the downstream projects are affected. Like who knows, right? It can go pretty bad. And it's very complex when it's large scale open source or close source anywhere, large scale software. And so because team cloud native belongs to everyone, because open source belongs to everyone, we got to get people on the same page. For those who are eager to learn more, as I said in my keynote, please do join the two sessions that we have planned. One is going to happen, which is about inclusive naming in general. It's an hour and a half session happening on Thursday. Pretty sure. And there we will talk about all the various arms who are involved. Everybody will have a seat at the table and we'll have documentation and presentation to share on how we recommend we all move together as an ecosystem. And then second is a presentation by Celeste in the Kubernetes working group about how Kubernetes specifically has done naming. And I feel like Steven, you and your peers have done such amazing work that many can benefit from it. Well, I think engineers are, you got two things going working for you, which is one, it's a mission and that's certainly societal benefits for this code is for the people. Love that, that's always been the marching orders. But also engineers are efficient. If you have duplicate efforts, I mean it's like, you think about people just doing on their own, why not do it now, do it together, more efficient, fixing bugs over stuff you could have solved now. I mean, this is the huge issue. So totally, totally believe it. I know we got to go, but I want to get the news in Priyanka. You guys had some new stuff coming out from the CNCF, new things, survey, certifications, all kinds of new reports. Give us the quick highlights on the news. Yes, absolutely. So much news, so many talking points. Well, you know, and that's a good thing. Why? Because the cloud native ecosystem is thriving. There is so many people doing so much awesome stuff that I have a lot to share with you. And what does that tell us about our spirit? It tells you about the spirit of resilience. You heard about that briefly in the conversation we just had with Steven about our working group to align various parties and initiatives together to bring inclusive naming to code. It's about resilience because we did not get demoralized. We did not say, oh, it's a pandemic, I can't meet anyone. So this isn't happening. No, we kept going. And that is happening in inclusive naming. That is happening in the cloud native surveys we're doing. That's happening in the new members that are joining. As you may have seen, Volcano Engine just joined as Platinum Member and that's super exciting. They come from China. They're part of the larger organization that builds TikTok, which is pretty cool as a frequent peruser, I can say that. In addition, on a more serious note, security is really free. And as I was talking to someone just minutes ago, security is not something that's a fad. Security is something that as we keep innovating, as cloud native keeps being the ground zero for all future innovation, it keeps evolving. The problems keep getting more complex and we have to keep solving them. So in that spirit, we in CMCF see it as our job, our duty to enable the ecosystem to be better conversant in the security needs of our code. So to that end, we are launching the CKS program which is a certification for Kubernetes security specialist. And it's been in the works for a while, as many of you may know, and today we are able to accept registrations. So that's a really exciting piece of news. I recommend you go ahead and do that as part of the KubeCon registration. Folks have a discount to get started and I think they should do it now because as I said, the security problems keep getting worse, keep getting more complicated and this is a great baseline for folks to start when they are thinking about these. It's also a great boon for any company out there whether they're end users, vendors, it's all sometimes a blurry line between the two which is all healthy. Everybody needs developers who are security conversant, I would say. And this certification helps you achieve that. So send all of your people to go take it. So that's one of the announcements. Then other things I would like to share are as you go, sorry, were you saying something? Yeah, go ahead. No, as you know, we talked about the whole thing of team cloud native is for everyone, open source is for everyone. And I'm really proud that CNCF has offered over 1000 diversity scholarships since 2016 to traditionally underrepresented and or marginalized groups. And I think that is so nice and but just the very, very beginning. As we grow into 2021, you will see more and more of these initiatives. Every member I talked to is so excited that we put our money where our mouth is and we support people with scholarships, mentorships and this is only going to grow. And just so you know, at almost 17%, the CNCF mentors in our program are women. So for folks who are looking for that inspiration, for folks who wanna see someone who looks like them in these places, they have more diverse people to look up to. And so overall, I think our DEI focus is something I'm very proud of and something you may hear about in other news items. And then finally, I would like to say is that cloud native continues to grow. The cloud native wave is strong. The 2.0 for team cloud native is going very well for the cloud native annual survey 2020. We found an astonishing number of places where cloud native technologies are in production. You heard some stories that I told in my keynote of people using multiple CNCF projects together. And these are amazing end users who have this running in production. So our ecosystem has matured. And today I can tell you that Kubernetes is used in production at about 83% of the places out there. And this is up by 5% from 78% last year. And just so much strength in this ecosystem. I mean, 92% of people are using containers. So at this point, we are ubiquitous. And as you've heard from us in various times, our 70 plus project portfolio shows that we are the ground zero of innovation in cloud native. So if you asked me to summarize the news, it's number one, team cloud native and open source is for everyone. Number two, we take pride in our diversity and over a thousand scholarships have been given out since 2016 to recipients from underrepresented groups. Number three, this is the home base for innovation with 83% of folks using Kubernetes in production and 70 plus projects that deliver a wide variety of support to enterprises as they modernize their software and utilize containers. Awesome, that was a great summary. First of all, you're a great host. You should be coasting the queue with us. I know you're a great keynote. Love the virtual events that you guys have been doing. Love the innovation. I think I would just say, just from my perspective and being there from the beginning is it's always been inclusive and the experience of the events in the community have been top notch. People squabble, people talk, people have conversations, but at the end of the day, it is a great community and it's fun, memorable, and people are accepting. It's a great job. Steven, good job as co-chair this year. Well done, congratulations. Thank you very much. Okay, thanks for coming on, appreciate it. Take it easy. Okay, this is theCUBE virtual. We wish we were there in person, but we're not, we're remote. This is the VirtualCube. I'm John Furrier, your host. Thanks for watching.