 Welcome back everybody, Jeff Frick here with theCUBE. We're at Node Summit 2017 at Douttown San Francisco Mission Bay Conference that we've been coming here for years. The vibe is growing and exciting and some really interesting use cases in earlier sessions about how fast the Node adoption is happening in some of these enterprises and we're excited to have Michael Dawson. He's a software developer but more importantly he's the Node.js community lead for IBM. Michael, welcome. Thank you. It's great to be here and nice to be able to talk to you and talk about Node.js and what's going on in the community. Absolutely, just to get your impressions in terms of a temporal perspective of how this has changed and evolved over time. A lot of talk about the community. I think the facility here only holds like 800 people. I think it's full to the capacity. How has it been growing and what's your perspective from a little bit of a higher point of view? It's really great. I was at Node Summit three years ago and it's great to see and other conferences and it's great to see that over the years how we get more and more people involved, different constituencies, more people who are deploying Node.js and even just day to day, we see a larger and larger number of collaborators who are getting involved and contributing to make the success of Node really grow and the functionality and all that great stuff. So what's your function inside of IBM as being kind of a Node advocate for the community I assume outside the walls of IBM but then also inside the walls of IBM? So I really have the pleasure to be able to work out in the community. That's the large part of my job but I also work very closely with our internal teams who focus on Node.js, supporting it for our bundling products. IBM has about 50, 60 products that bundled Node.js. We also support it through our platforms like Bluemix and so I work with the team to support those. If you're running Bluemix and Node it's the code that we've contributed and built and our development approach is very much out, do that out in the community. So if a particular product needs some sort of feature we'll go out and work in the community to do that and then pull that back in to use it. So you see we have about 10 collaborators. I'm one of them and the great thing is that I get to be involved in a lot of the working group efforts like the NAPI, the build work groups, the LTS work groups. And so my role is really to sort of bridge the community work that we do there to our internal needs and consumers as well. So how is the uptake within the IBM world of this technology within all the different stacks that you guys have? You know, I work in the Runtime Technologies team and we were called the Java Technology Center for a number of years. We're now called the Runtime Technology Center because we see it's a really, it's a polyglot world with Node.js being one of the three key runtimes. It's Node.js, Java and Swift. And we see that because we see our customers as well as our products really embracing Node and using it in all sorts of places. They've mentioned earlier that Bluemix, our PaaS is a very heavy user of Node.js in terms of the implementation of the UIs and the backend services, as well as Node.js is the biggest runtime in terms of deployments in that environment as well. So it's interesting, we had Monica on earlier from Intel. I think you're going to be on a panel with her later today about benchmarking. And she talked about that there's some unique challenges in trying to figure out how to benchmark these types of applications against the kind of benchmark standards of old. I wonder if you could share some of your thoughts on this challenge and for the folks that aren't going to be here watching the panel, what are some of the topic areas that you want to make sure to get exposed in that panel? So I've been working with the benchmarking workgroup. I actually kicked it off a number of years back. The approach that we're following is we want to document the key use cases for Node, as well as the key attributes of the runtime, like starting up PaaS, being small, the things that have made it successful, as well as the key use cases like a web front end, back end services for mobile, and then fill in that matrix with important benchmarks. I mean, that's where one of the challenges comes in and that other languages have a more mature and established set of benchmarks that different vendors and different people can use. Whereas the work in the working group is to try and either find benchmarks, encourage people to write those benchmarks and pull together a more comprehensive suite that we can use. Because performance is important to people. And as a community, we really want to make sure we still encourage a rapid pace of change, but be able to have a good handle on what's going on in the other side. And having the benchmarks in place should be an enabler in that if we can easily and quickly find out what a change impact has, positive or negative, that'll help us move things forward as opposed to if you're uncertain, it's a lot harder to make the decision as to which way you should go. It's funny on benchmarking, right? Because on the one hand, people just can poo poo benchmarks because I'm writing my benchmark so that it beats your product and my benchmark and you can write a benchmark the other way. But I think what you just touched on is really important. It's really for optimization of what you're doing for improving your own performance over time. That's really the key to the benchmark. Yeah, absolutely. The focus of the work in the benchmarking work group has been on a framework for regression testing and letting us make the right decision, not competition. I think some of the pieces that we develop will perhaps factor into that, but that's not really the core focus, it's to get a good established set and other individual companies can then maybe use it for other purposes as well. So Michael, before I let you go, I just want to get your perspective. You work for a big company. I don't think it's as much anymore. Used to be a lot of open source conferences, people were like, oh, we don't want the big people coming in, they're going to take it over. And to get your perspective of being that liaison between this really organic open source community and Big Blue back behind you and how kind of you navigate that and in your experience of the acceptance of IBM into this community, as well as your ability to bring some of that open source ESOs back into IBM. I've found that it's been really great. I love this community. They've been very welcoming. I've had no issues at all, getting involved. I think IBM has respected us in the way that we've contributed. We're trying to contribute in a very constructive and collaborative way. We, nothing that we do, do we really do on our own. If you look at the NAPI, we're working with other individuals, people from different companies or just individual contributors to come to a consensus on what it should be and to basically move things forward. So yeah, in terms of a big company coming in, you do hear some concerns, but I haven't seen any on the ground impediments for problems. It's been very welcoming and it's been a great experience. All right, very good. All right, well, before I let you go, kind of final thoughts on this event, where we are. It's a great event. I always enjoy being able to come and meet people. A lot of time you work on GitHub, you know somebody's handled, but there's nothing like making that personal connection to be able to put the face to the name. And I think it affects your ongoing sort of interactions when you're not face to face. And so it's a really important thing to do and that's why I like to come to a lot of these events. All right, well, Michael Dawson, we'll let you get back to meeting some more developers. Thanks for taking a few minutes out of your day. Thank you very much. Absolutely. He's Michael Dawson from IBM. I'm Jeff Frick, you're watching theCUBE. Thanks for watching, we'll catch you next time.