>> Announcer.: From Copenhagen, Denmark, it's theCUBE. Covering KubeCon and CloudNativeCon Europe 2018. Brought to you by the CloudNative Computing Foundation and its ecosystem partners. >> Hello everyone, and welcome back. This is theCUBE's exclusive coverage of KubeCon 2018 in Europe, part of the CNCF, Cloud Native Compute Foundation, part of the Linux Foundation. I'm John Furrier with my cohost Lauren Cooney. Our next guest is Dirk Hohndel, Vice President, Chief Open Source Officer for VMware. Great to see you. CUBE alumni, welcome back. >> Thank you, good to be here. >> So you had a keynote, smashing success today on stage, about open source, all five minutes of it, congratulations. (laughing) Take a minute to explain, I have some specific questions on VMWare, office of the CTO, how you guys are working on some really interesting things. But first, take a minute to explain, the VMware approach to open source that you're leading. What's the architecture of it, how is it organized, can you take a minute to explain-- >> Sure. >> The VMware? >> So we use open source components in literally every single one of our products, and we have a structure where each of the BUs is engaged in open source in the components that they're using, in projects that are related to the business, and they have a central organization that sits in the office of the CTO that I run, so the open source program office, which has much more of a focus of pure open source work. Focused on up stream, focus on the problems that the community sees much more than something that is product driven. I also own the whole compliance work that everyone needs to do to make sure that you follow the licenses and all that. But, fundamentally the balance between having the central organization that has maybe the center of expertise and has people who do open source and nothing but open source, and on the other hand bringing that expertise into the BU. Bring it closer to the products, and engaging across the company. We have more than 7,000 software engineers across the company and we want every single one of them to be mindful and understanding of how open source works, and how we are engaged in that space. >> And how many people, just some stats, can you share, by the numbers, how many people are on the teams, R&D, there's also in the CTO office. How many folks are on your team roughly speaking? >> So I have currently, I want to say, this is quick, 20 some odd people under me, but across the company it's a lot more. There are several hundred people who are, in their daily work engaged with open source all the time. >> That's great. >> So your team is centralized in the business units. Go ahead. >> No, that's great. I was going to say, what is it look like for people that want to contribute code that aren't on your team? Is there a process that's pretty easy to go through? Or can they just put it on GitHub? We would all like that but. >> Yeah so, we have an internal tool that we've developed they simply can request to contribute to an existing project and it goes through a very quick review and depending on the topic, this is typically a two day turnaround time, where they get approval from the BU VP and from me. And if you want to open source a project, so if you have something internal that you've done, that you want to bring out into the community, it's little more complicated with naming, and branding and what not. A lot more people need to nod basically, but it still takes usually a couple of weeks-- >> Yeah. >> And it goes through. But it's an automated process, it's driven by a PM out of my organization. >> That's great. >> And it tries to make it really, really easy. One of my big goals joining VMware was to remove friction out of this process, and to encourage people to engage with the projects that are out there, but also for us to bring software into the open that we've developed, for example internal tools, and make them useful for other people. >> Definitely, I think that's great. >> You mentioned open source models about people, can you elaborate on that because I think this is an important point, we were talking before we came on, about that role of people. >> Well, so open source is... People think of this as a software development methodology, and it is, but fundamentally it's a social phenomenon. It's this experiment of saying the way we do our work is based on relationships. It's based on trust. So I trust you that you've reviewed this code and I take that code that you've reviewed. I know that you are the expert in this area so if I make changes in this area I'll send them to you and ask for your review. It's all about relationships. And these relationships are between people, not between companies. So in so many ways, the role travels with the person, and not with the company. And we have seen this in many cases, where people move from company to company, but the work, their influence, the role comes with them. So it's very much empowering for the engineers. But it's also from a purely human perspective, an engagement where, it's not just about the code that you write, but it's about how you treat people. How you engage with them. This is why conferences like this are so wonderful. There are 4,000 people here, 4,500 people here, and you meet people whom, with whom you've been emailing for years. And this social aspect of this for an introvert like myself, is at the same time a little scary, but also it's super exciting because it is people who are driving this industry. >> John: The face to face connections really make a difference. >> I think it's the community. I mean the community always comes first, I think. I will say this, you build a community, you don't launch one, and I think that's absolutely critical. And I think, can you talk about some of the changes in mentality that you're working with across VMware right now with getting that community first sort of thing moving? >> Well, so, I mean, VMware is a very engineering centric organization. We are driven, we're founded by engineers and driven by engineers, I mean Pat Gelsinger our CEO was an engineer, and so the underlying ethos of contribution and of trying to fix problems and if you see something you go and fix it, that is something that has always been there at VMware, but what I've been trying to bring in to VMware is much more of an up-stream focus. An understanding of, it's not just important that you understand the technology well and you use it well, but also that you contribute back. And that you are seen as playing a big role in this industry. And if you look at the impact that VMware has had in the broader open source community, and how we have shifted our approach to being part of this over the last two years, I think it's been extremely successful. And you can see this with our footprint here, how many talks we have here, and how much presence we have here. I think there's 70 VMware employees at KubeCon this year. >> That's great. >> It's now cultural, it's a Tier One, I'll say Tier One role, not Tier Two when we were growing up in the industry, but part of the business software define, infrastructure, software is taking over the world as Mark Andress said is happening. Open source is there powering it. So I have to ask you the question, that would be on my mind if I'm thinking about going all in as a company, if I'm an enterprise. Hey, you know what, I like this approach. I'm going to go all in. Complete commitment. What's the best practice, what's your advice, because this is something people are talking about doing not just putting a toe in the water going all in and committing to an open source business model with their company. What's your advice for shepherding that process, cultural ethos. What's your take? >> It starts with language. It starts with how you talk about what you're doing. I hear a lot of people saying things like, "Oh, I consume open source," well it bugs me because you consume a commodity. You consume electricity, you don't care where it comes from it's just a plug in the wall. Whatever, right? Open source is always around, about the people. It's always about how do people work. How do they think about security, about releases, about maintenance? What's their work flow? And you can't just consume an open source component, you need to engage with them, you need to understand how their work affects your work. And so my recommendation is always, start with your own language. Start with the approach that you're taking when you're talking about all this. And then figure out, where are you using it, how are you using it, what are the changes that you've made to the components that you're using? How about contributing those changes back? It's a very simple first step to engage. And it's actually a step that makes total business sense because if you have your private branches, your private patches, the next time the upstream project goes through a new release, you need to port these changes, that costs money. So it's actually cheaper to simply contribute them back and have them maintained by the project. And you can use upstream, or you have a minimum set of small adjustments that don't make sense to return to the community. And this is really how you get your toe into the water. Because now you're not just a user of this, you're engaged, you're a contributor. >> You're operationalizing your business. >> Yes, you are, and then the next step is thinking about what of my internal tool sets that maybe are not my core product, but are the things that we build to build the product as part of our workflow. What of those could be used for the product community? So at VMware, for example, we built a software design system, it's called Clarity, and you can use it to create angular-based JavaScript UIs. So we use this for all of our products. We made this tool an open source tool and it's massively successful project, has weekly releases, has a ton of users, a very very active community. And it's one of those cases where you take something that isn't the core of your business, but you are earning your chops in the community. And take it one step at a time and broaden-- >> John: That's the trust relationship you're building? >> That is very much this trust relationship. And it's this track record that you're building of not only doing something, oh here's this old product and I'll open source it and then I walk away. So we call this dump and run right? You throw it over the wall, it's now open source and then you say, customer you're now on your own because it's now open source. >> It's abandoned no one's paying attention. >> Yeah that's a terrible model, but a very good model is one where you think about creating these relationships and creating a track record of being there every week, looking at the bug reports, looking at the issues, looking at the pull requests, and engaging with the people out there. And the value that this creates, the amount of value that you're getting from your outside contributor, very quickly outweighs the additional cost that it takes to get this IP clean and released and all that. >> And then there is documentation and documentation is a tremendous amount of heavy lifting on the inside of a company. But if you can spread it over an open source product that you have, it's great. And it's a really good way for people to start out in open source, I find. >> And you just said open source product, so this one of those things-- >> Project. >> Where, yeah. This is something that I think is where we come back to language being so important. I always talk to the folks internally about this distinction. What is the open source project? What is it, what the community does, what lives on GitHub or what lives in the public side of this? And then what is your product that is based on this project? And in your thinking always keep these two separate. Understand that everything that happens in the project is what is publicly available and what is done in conjunction with your community. >> John: With the team. >> Versus your product which focuses on how does the customer use this. Because open source projects, in and of themselves, are typically built by developers for developers. And the end user has actually different needs. And this is where the business model come in and that's kind of closing the question that you just asked, because the value that the company is providing this space is the understanding of the customer needs. And is the ability to take something that is creating enormous and impressive innovation, which is the community, and taking this to a place where then someone can use it in production. Where it's scales, where it's secure, where it has Day-One and Day-Two operationalization, where it has strong documentation. There is a support number you can call. All these things that a customer is-- >> John: Needs. >> Needs and that an open source project by themselves is unlikely to create. >> It's like putting money in the bank. You can't just take money out of the bank. You've got to deposit good will. The give-get is part of that project and you're saying make the product focus on the customer problems. >> Dirk: Absolutely. >> My question is are you talking kind of about a services wrapper that you put around it and maybe a couple of additional features? In part, or what are you actually kind of, just to get to the crux of it. >> So there are many different ways, many different business models around open source. For us, we are still an enterprise software company. So open source generally provides components of what we do. It may be the API that the customer is asking for. So today, Kubernetes is a set of APIs a lot of people want to use as their way to provide a container service for the orchestration, right? But what is the underlying infrastructure? How do you generate a persistent storage? A flexible networking infrastructure that can grow and shrink as your work loads grow and shrink? How do you manage your individual nodes? How do you deal with internal billings so that you can bill your data center time to your departments? And all these operational aspects are things that we're trying to solve with our products. But we offer to the customer an open source based API. So that's where our business value lies fundamentally. >> Lauren: Okay. >> Communities are a concept that's premised on create value before you capture it. And I think what you're saying is, if you have a project, you better bring something to the table, not just distract. It's a taker. >> Yes. >> If you're just taking all the time, it's not a good trust relationship building, that's what I hear you saying. >> And you will also not be successful because your customer needs, as your customers are coming to you and they're running into issues, you need to be able to address those issues. Which means you need to be productive part of that community. You need to have the in-depth understanding to then help them. >> I've seen people do things like they couldn't get a business model going so they say, "Oh we're just going to open source it, "and hope that a miracle happens." And it's not really that way. I mean, people do open source for the right reasons to bring code to the table, but you're saying nurturing that community project is a for all kind of thing. >> Fundamentally, I always think there are so many brilliant developers in these communities. And if you go into these communities with the assumption that you can learn something from the other developers, you can learn something from the other companies that are involved. And then you can contribute the areas where you are strong, where you have your core knowledge. And you wrap this into a product that provides value for your customers, everyone wins. Your customer wins, >> That a good way-- >> Your community wins, you win. >> So if you're out there thinking about it think about your core competency and what you want to open source, you got a good fit. Okay what's new for you? You diving, you're an avid scuba diver. We talked about that last time you were on theCUBE. What's new with you? >> I haven't been diving. Actually I drove up to Hootsbor to dive in 48 degrees Fahrenheit water, because I haven't been in the water for so long. My next trip is going to be Okinava which is a lot warmer than that. No, the work keeps me busy, so not as much scuba diving as I would want. But we've been very busy. We've been pushing a lot more contributions to a much larger set of projects. My team has been growing, so we've been actively hiring. And we're developing a second generation, internal set of processes to deal with all of these questions you asked about earlier, of how to make sure that you know where you contribute, how you contribute, which components you use. So we're revamping our internal processes around this. >> Lauren: That's great >> And it's keeping us very busy, but I have to say, especially, if you look at this conference here, the success is really very rewarding. We have so many more people actively engaged, and recognized in the community as key contributors. It's been a very very successful year since last we talked. >> It's awesome. Well thanks for your leadership at VMware. We love the KubeCon, we love the Linux Foundation, they've done amazing work. CNCF is just exploded with success and it's a result of, the trend is everyone's friend, which is cloud computing and software defined everything so, VMware. Thanks for coming out Dirk, appreciate it. Live coverage here in Copenhagen, Denmark. This is theCUBE, I'm John Furrier. Lauren Cooney co-hosting with me this week. And we'll be back with more, stay with us after this short break. (energetic music)