 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, welcome back. This is theCUBE's exclusive coverage of KubeCon 2018 in Europe, part of the CNCF CloudNative Computing Foundation part of the Linux Foundation. I'm John Furrier with my co-host Lauren Cooney. Our next guest is Dirk Hundell, Vice President, Chief Open Source Officer for VMware. Great to see you, Kube 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. Take a minute to explain. I have some specific questions on VMware and 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 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 users engage in open source in the components that they're using in projects that are related to their business and we 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 upstream, focused 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, bringing it closer to the products and engaging across the company. I mean 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 this space. And how many people, just some stats can you share by the numbers, how many people on the teams, R&D, is also in the CTO office, how many folks on your team, roughly speaking? So I have currently, I want to say 20 or so 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. So your team centralized in the business units? No, that's great, I was going to say, what does 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? Or you know, we would all like that, but. Yeah, so we have an internal tool that we've developed where 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 BUVP and from me. And if you want to open source a project, so if you have something internally that you've done that you want to bring out into the community, it's a little more complicated with naming and branding and whatnot. A lot more people need to nod basically, but it still takes usually a couple of weeks and it goes through. But it's an automated process. It is 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 VMBA 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 as, 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 about before we came on about that role of the 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 you 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, or four and a half thousand people here. And you meet people 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. The face-to-face connections really make a difference on the community. I think it's the community, I mean, the community always comes first, I think. And I will say this, it's 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 Gelsing, our CEO, is 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 into VMware is much more of an upstream focus and 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 Cube Condos here. It's now cultural. It's a tier one, obviously a tier one role, not tier two when we were growing up in the industry, but it's part of the business, software-defined infrastructure, software's taking over the world, as Mark Andreessen said, is happening. And 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, say, 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 that people are talking about doing, not just putting the 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, 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 workflow? 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? That'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 to 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 contributing. You're operationalizing your business. Yes, you are. And then the next step is thinking about what are my internal tool sets that maybe I'm 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 useful to the broader 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 a 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. It's the trust relationship you're building. That is very much the 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 on your own because it's now open source. Yeah, it's a band and no one's paying attention. 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 release and all that. Then there's 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 and 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 is one of those things. So project. 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 Europe and 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. With the team. Versus your product that focuses on how does a 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 comes 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 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 needs and that an open source project in by themselves is unlikely to create. It's like putting money in the bank. You have a trend, you know, you can't just take money out of the bank. You got to deposit goodwill. The give get is part of that project and you're saying make the product focused on the customer problem. Absolutely. My question is, are you talking kind of about a services wrapper that you put around it and maybe a couple additional features or, you know, in part or what are you actually kind of just to get to the crux of it? There are many different ways, many different business models around open source. For us, we are still a 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 that 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 workloads grow and shrink? How do you manage your individual nodes? How do you deal with internal billing so that you can build your data center time to your departments? And all these operational aspects are things that we are 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. I mean, 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 got to bring something to the table, not just extract, it's a taker. If you're just taking all the time, this is not a good trust relationship building. That's what I hear you're 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 a productive part of that community. You need to have the in-depth understanding to then help them. You need to be genuine. I've seen people do things like they couldn't get a business model going, so they're saying, oh, we're just going to open source it and hope that miracle happens. And that'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. The customer wins. It's a good way to think about community wins, you win. So if you're out there thinking about it, thinking about your core competency and what you want to open source, you got a good fit. Okay, what's new for you? You're diving, you're having scuba diver. We talked about that last time you were on the cube. What's new? What's new with you? I haven't been diving. Actually, I drove up to the hoodsport 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 to Okinawa, 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 are developing a second generation internal set of processes to deal with all 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 are revamping our internal process around this. 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. It's done amazing work. CNCF has just exploded with success. And it's a result of the trend as everyone's friend, which is cloud computing and software-defined everything. So, VMware, thanks for coming on DIRT. 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.