>> Voiceover: 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, it opens up more conversations. And this is theCUBE virtual. I'm John Furrier, your host. And you'll 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 got two great guests, Priyanka Sharma, the General Manager of the CNCF, great to see you and Stephen Augustus OSS Engineer at VMware. He's also the KubeCon co-chair back on the cube. Thanks for coming on folks. I appreciate it. >> Thank you for having us. So, thanks for coming on, actually, 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, 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. (Priyanka laughs) As I announced, I'm so proud to be working with the likes of Stephen 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. Quite frankly. We've had many problematic terms in software out there. The most obvious one being master-slave. That really shouldn't be there. That have no place in an inclusive world, inclusive software, inclusive community with the help of amazing people like Stephen, 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...pan-organizational kind of way. And so that's the working group that John is talking about. With that said, Stephen, I think you can do the best justice to speak to the overall initiative. >> Yeah, absolutely. So I think that's to Priyanka's point, there are lots of people who are interested in this work and again, lots of work where this is already happening, which is very exciting to say, but as any good engineer, I think that's 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 that... 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 want to say, June-ish, we've done some work on about of providing a language evaluation framework, providing templates for recommendations, providing a workflow for moving from just a suggestion into kind of actuating those ideas right and removing that language where it gets tricky and code is thinking about, thinking about, say a Kubernetes API. And in 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, I'm very excited about the overall effort. >> Yeah, I mean, your mind can explode if you just think 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. 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 want to get ne 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've 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 accept it. 'Cause that's the... end of the day, it's acceptance and putting it code owners. >> Absolutely. I think so, as you said, we live in a polarizing environment right now. Most of us here though know that this is the right thing to do. Team CloudNative 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 I've been working on this. Now, when it goes into actual execution, as you said, there are many moving parts, Stephen 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 in books, who have literally done PhDs in this 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 the right thing, but you'd 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. They're still figuring that piece out, but more to come on that space. That's my part. But Stephen can tell you about all the heavy lifting that they've been doing. >> Before we get to Steve, I just want to say congratulations to you. That's great leadership. And I think you're taking a pragmatic approach and you putting 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, Stephen, let's talk about how this gets done because you guys open sources is what it's all about is about the people, it's about building on the successes of others, standing 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 group's doing and how you see this. What are the few 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. 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. But you may not have the entire scope that you need to make a change. So I think that first it's amazing to see all of the thought that has gone through making certain changes, like discussing master and slave, discussing how we name control plane members, doing the... having the discussion around a whitelist and blacklist. What's hard about it is, is when people start making those changes. We've already seen several instances of an invigorated contributor, and maybe the new contributor coming in and starting to kind of like search and replace words. And it... I wish it was that simple, it's a discussion that has to be heard, you need buy-in from the code owners, if it's an API that you're touching, it's a conversation that you need to have with the SIG Architecture, as well as say SIG Docs. If it's something that's happening in Release, then it's a easier 'cause you can come and talk to me, but, overall I think it's getting people to the point where they can clearly understand how a change affects the community. So we kind of in this language evaluation framework, we have this idea of like first, second and third order concerns. 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. So first order concerns are the ones that we want to eliminate immediately. And the ones that we commonly hear this discussion framed around. So master-slave and 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 it's kind of like understanding what it means to provide a recommendation and who actually approves the recommendation. Because this group is, we have several language aficionados in this group, but we are by now means experts. And we also want to make sure that we do not make decisions entirely for the community. So, discussing that workflow from a turning a recommendation into actuating a solution for that is something that we would also do with the steering committee. So Kubernetes kind of like top governing body. 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 is really the biggest thing. And having a framework to make it easy to make, do those evaluations, is what we've been craving and now have. >> Well, congratulations. That's awesome. I think it's always... it's easier said than done. I mean, it's a system when you have systems and code, it's like, there's always consequences in systems architecture, you know that you do in large scales OSS. You guys know what that means. And 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 a play here. People just buy into it. That so it's a little bit of a PR thing going on too, for get buy-in, this is again a classic, getting people on board, Priyanka, isn't it? It's the obvious and then there'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 many people are midway through the journey. That's one of the big challenges. Some people are on 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 get align now rather than a year later, where everybody has their own terms as replacements and nothing works. And maybe the downstream projects that are affected, like who knows, right? It can go pretty bad. And it's very complex and it's large-scale opensource or coasters, anywhere, large software. And so because team CloudNative belongs to everyone because open source belongs to everyone. We got up, 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. I'm pretty sure. And there we will talk about all the various artists who are involved. Everybody will have a seat at the table and we'll have documentation and a presentation to share on how we recommend the all move, 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 Stephen, you and your peers have done such amazing work that many can benefit from it. >> Well, I think engineers, you got two things going to work in for you, which is one, it's a mission. And that's... There's certainly societal benefits for this code, 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 it 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 a huge issue. So totally believe it. I know we got to go, but I want to get the news and 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, and that's a good thing, why? Because the CloudNative 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 Stephen 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 CloudNative series 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 Tik Tok, which is pretty cool as a frequent bruiser I can say that, in addition, on a more serious note, security is really key 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 CNCF 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 our Kubernetes security specialist. And it's been in the works for awhile 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 this. 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 help you helps you achieve that. So send all of your people to go take it. So that's sort of the announcements. Then other things I would like to share are as you go, sorry, were you saying something? >> No. Go ahead. >> No, as you know, we talked about the whole thing of team CloudNative 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 under-representing our 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 was 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 it just so like at almost 17%, the CNCF mentors in our program are women. So for folks who are looking for that inspiration, for folks who want to 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 CloudNative continues to grow. The cloud native wave is strong. The 2.0 for team CloudNative is going very well. For the CloudNative annual survey, 2020, we found an astonishing number of places where CloudNative 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 and users who have this running in production. So our ecosystem has matured. And today I can tell you that Kubernetes is used in production, by 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, now at 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 CloudNative and open source is for everyone. Number two, we take pride in our diversity and over 1000 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 hosting theCUBE with us. 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 from there from the beginning is it's always been inclusive and the experience of the events and 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. Stephen, good job as co-chair this year. Well done. Congratulations. >> Thank you very much. >> Okay. Thanks for coming on, I 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 virtual Cube. I'm John Furrier, your host. Thanks for watching. (upbeat music)