>> Announcer: From around the globe, it's theCUBE with digital coverage of Ansible Fest 2020, brought to you by Red Hat. >> Everyone welcome back to theCUBEs, virtual coverage of Ansible Fest 2020. I'm John Furrier, host of theCUBE, we're here virtual, we're not face to face obviously because of COVID. So we're doing a virtual event Ansible Fest coverage. We have Mary Johnston Turner, research Vice President of Cloud Management at IDC international data Corp. Mary great to see you, thanks for coming on for Ansible Fest 2020. >> Thanks for inviting me. >> So obviously Cloud Management, everything's Cloud native we're seeing that at VM world, we've got Re-invent coming up, Azure has got growth. The enterprises have gotten some religion on Cloud Native, COVID certainly is forcing that. What are you seeing from your research at IDC around the convergence of Cloud strategies. What's the data tell you, what's the research show? >> Well, obviously with COVID a lot of folks have pivoted or accelerated their move to the Cloud in many ways. And I think what's happening is that we're seeing many, many organizations recognizing they continue to have need for On-prem resources. They're building out edge, they've got remote work from home, they've got traditional VM workloads, They've got modern Cloud Native container-based workloads running On-Prem and in public Clouds and public Cloud services. So it's really kind of a striking world of connected Clouds is how I'm talking about it increasingly. And I think what that means from an operational perspective is that it's getting more and more challenging for organizations to maintain consistent configuration, stable APIs, security, compliance and conformance. And they're really starting to look at Automation as the way to deal with the increasing scale and velocity of change because that's one of the things that's happening. And I think COVID accelerated that is we've seen organizations stand up applications they never thought they were going to have to stand up and they not only stood them up very quickly, but then they continue to update them with great frequency often multiple times a day or a week. And and the infrastructure has had to pivot and the workloads have had to migrate. So it's really been a very challenging time for many organizations. And I think those that are coping the best with it are the ones who have been investing in Automation particularly Automation in CICD pipeline and code based environment. >> Yeah, you know, you're seeing the releases, obviously Automation has helped on the agile side, VMs and containers have been a great way to automate, how are customers looking at this? Because it seems to be Automation is like the first step towards everything as a service, right? So it's XAAS as it's says, as it's called in the industry. Services is ultimately the holy grail in all this because you get, when the Automation and services used to be Automation, Automation, Automation. Now you're hearing as a service, as a service, as a service as the top three priorities. So it seems to be a trajectory. How are customers getting first of all... Do you agree with that? And then how do customers think about this? Cause sometimes we're ahead of the customers. Automation is the first step. What's your take on this, and what are customers planning when it comes to Automation? Are they thinking as a service? What'd you hearing from the customers? >> Let's talk a little bit about what we mean by as a service. Cause that's a really interesting concept, right? And I've been hearing this conversation with folks as a service started a decade or more ago, taking things that particularly software that ran On-prem infrastructure or software. And putting it into share Data Centers where we could run Multi tenant Environments we could scale it, and each Cloud provider basically got that scale by investing in their own set of infrastructure Automation. So whether it was Azure or VMware or whoever, they build a whole repeatable, scalable environment that they could control. What's happening now is that we're seeing these control planes get stretched back to On-prem resources. And I think what's really happening is that the line about where does the thing physically have to run? Becomes more of a discussion around the physics of the matter, Latency, Data Volumes, transaction processing cost of installed equipment. And every organization is making its own choice about what's the right mix, in terms of where physically do things have to run, and how they want to manage them. But I think that we're starting to see a abstraction layer coming in between that. And a lot of that abstraction is Automation that's portable that can be applied across all these environments. And that can be used to standardize configurations, to maintain standard APIs, to deploy at very fast speed and consistency across all these different resources. And so Automation and the related management layer to me is that new abstraction layer that actually is going to allow most enterprises to stop worrying quite so much about (chuckles) what kind of as a service am I buying? And focus more on the economics and the performance and the physics of the infrastructure, and then maintain consistency with highly Automated, Repeatable, Programmable Style Environments that are consistent across all these different platforms. >> Yeah, that's a great point. It's great insight, I love that. It's almost, as you can almost visualize the boardroom. We need to change our business model as a service. Go do it, climb that hill, get it done, what are you talking about? What you're trying to manage workloads inside our enterprise and outside as they started looking at the workload aspect of it, it's not trivial to just say it, right? So your containers has barely filled the void here. How are customers and how are people getting started with this initial building block of saying okay, do we just containerize it? Cause that's another hand waving activity which has a lot of traction. Also you put some containers has got some goodness to it, are many people getting started with solving this problem? And what are some of the roadblocks of just managing these workloads inside and outside the enterprise? >> Well, again I think, yeah many organizations are still in the early stages of working with containers. Right now I think our research shows that maybe five to 10% of applications have been containerized. And that's a mix of lift and shift of traditional workloads as well as net new Cloud Native. Over the next couple of years almost enterprise has tell us to think a third of their workloads could be containerized. So it's ramping very, very quickly. Again, I think that the goal for many organizations is certainly containers allow for faster development, very supportive microservices, but increasingly it's also about portability. I talk to many organizations that say, yeah, one of the reasons I'm moving, even traditional workloads into containers is so that I have that flexibility. And again, they're trying to get away from the tight coupling of workloads to physical resources and saying I'm going to make those choices, but they might change over time or I might need to go what happens. I have to scale much faster than I ever thought. I'm never going to be able to do that my own data center, I'm going to go to the Cloud. So I think that we're seeing increasing investments in, Kubernetes and containers to promote more rapid scaling and increased business agility. And again, I think that means that organizations are looking for those workloads to run across a whole set of environments, geographies, physical locations, edge. And so they're investing in platforms and they count on Automation to help them do that. >> So your point here is that in five, 10% that's a lot of growth opportunity. So containers is actually happening now so you starting to see that progression. So that's great insight. So I've got to ask you on the COVID impact, that's certainly changed some orientation because hey, this project let's double down on this is a tailwind for us, work from home this new environment and these projects, maybe we want to wait on those, how do we come out of COVID? Some people have been saying, some spending in some areas are increasing, some are not, how are customers spending money on infrastructure with COVID impact? What are you seeing from the numbers? >> Well, that's a great question, and I do see one of the major things we do is track IT markets and spending and purchasing around the world. And as you might expect, if you go back to the early part of the year, there was a very rapid shift to Cloud, particularly to support work from home. And obviously there was a lot of investment in virtual desktops and remote work kinds of and collaboration very early on. But now that we're sort of maturing a little bit and moving into more of ongoing recovery resiliency sort of phase, we continue to see very strong spending on Cloud. I think overall it's accelerated this move to more connected environments. Many of the new initiatives are being built and deployed in Cloud environments. But again, we're not seeing a Whole Hog exit from On-prem resources. The other thing is Edge. We're seeing a lot of growth on Edge, both again there's sort of work from home, but also more remote monitoring, more support for all kinds of IOT and remote work environments, whether it's Lab Testing or Data Analysis or Contact Tracing. I mean, there's just so many different use cases. >> I'm going to ask you about Ansible and Red Hat. I see you've been following Ansible since the acquisition by Red Hat. How do you think they're doing Visa Vie the market, their competitors that have also been acquired? What's your take on their performance, their transition, their transformation? >> Well, this infrastructure is code or Automation is code market has really matured a lot over the last 10 or more years. And I think the Ansible acquisition was about five years ago now. I think we've moved from just focusing on trying to build elegant Automation languages, which certainly was an early initiative. Ansible offered one of the earlier human readable Python based approaches as opposed to more challenging programming languages that some of the earlier solutions had. But I think what's been really interesting to me over the last couple years with Red Hat is just what a great job they've done in promoting the community and building out that ecosystem, because at the end of the day the value of any of these infrastructures code solutions is how much they promote the connectivity across networks, Clouds, servers, security, and do that in a consistent, scalable way. And I think that's what really is going to matter going forward. And then that's probably why you've seen a range of acquisitions in this market over the last couple of years, is that as a standalone entity, it's hard to build those really robust ecosystems, and to do the analytics and the curation and the support at large scale. So it kind of makes sense as these things mature that they become fun homes with larger organizations that can put all that value around it. >> That's great commentary on the infrastructure as code, I totally agree. You can't go wrong by building abstraction layers and making things more agile. I want to get your take on some announcements that are going on here and get your thoughts on your perspective. Obviously they released with the private Automation hub and a bunch of other great stuff. I mean, bringing Automation, Kubernetes, and series of new features to the platform together, obviously continuation of their mission. But one of the things when I talked to the engineers is I say, what's the top three things, Ansible Fest, legal collections, collections, collections, so you start to see this movement around collections and the platform. The other thing is, it's a tool market and everyone's got tools we need a platform. So it's a classic tools. As you saw that in big data other areas where need start getting into platform, and you need management and orchestration you need Automation, services. What's your perspective on these announcements? Have they been investing aggressively? What does it mean? What's your take? And what does it mean? >> Yeah, I would agree that Red Hat has continued to invest very aggressively in Red Hat and in Ansible over the last few years. What's really interesting is if you go back a couple years, we had ASML engine, which included periodic, maybe every quarter or even longer than that distributions that pretty much all Ansible code got shipped on. And then we had tower which provided an API and a way to do some audit and logging and integration with source control. And that was great, but it didn't move fast enough. And we just got done talking about how everything's accelerated and everything's now connected Clouds. And I think a lot of what the Red Hat has done is really, approach the architecture for scale and ecosystem for scale. And so the collections have been really important because they provide a framework to not only validate and curate content but also to help customers navigate it and can quickly find the best content for their use cases. And also for the partners to engage, there's I think it's 50 plus collections now that are focused on partner content. And so it's I think it's really provided an environment where the ecosystem can grow, where customers can get the support that they need. And then with the Automation hub and the ability to support really robust source control and distribution. And again, it's promoting this idea of an Automation environment that can scale not only within a data center, but really across these connected environments. >> Great stuff. I want to get your thoughts cause I want to define and understand what Red Hat and Ansible, when they talk about curated content, which includes support for open shifts, versus pulling content from the community. I hear content I'm like, oh, content is that a video? Is that like, what is content? So can you explain what they mean when they say they're currently building out, aggressively building curated content and this idea of what does content mean? Is it content, is it code? >> Yeah, I think any of these Automation as code environments. You really have a set of building blocks that in the Ansible framework would be be modules and playbooks and roles. And those are relatively small stable pieces of code, much of it is actually written by third parties or folks in the community to do a very specific task. And then what the Ansible platform is really great at is integrating those modules and playbooks and roles to create much more robust Automations and to give folks a starting point, and ability to do, rather than having to code everything from scratch to really kind of pull together things that have been validated have been tested, get security updates when they need it that kind of thing. And so the customers can focus on essentially changing these things together and customizing them for their own environment as opposed to having to write all the code from step one. >> So content means what, in this context, what does content mean for them? >> It's Automation building blocks. It's code, it's small amounts of code that do very specific things (chuckles) and in a collections environment, it's tagged, it's tested, it's supported. >> It's not a research report like of a Cube video, it's like code, it's not content. >> Yeah, I know. But again, this is Automation as code, right? So it it's pieces of code that rather than needing an expert who understands everything about how a particular device or system works, you've got reusable pieces of code that can be integrated together, customized and run on a repeatable, scalable basis. And if they need to be updated cause an API changes or something, there's a chain that goes back to the the vendors who, again are part of the ecosystem and then there's a validation and testing. So that by the time it goes back into the collections, the customers can have some confidence that when they pull it down, it's not going to break their whole environment. Whereas in a pure community supported model, the contents made by the community, may be beautiful, but you don't know, and you could have five submissions that kind of do the same thing. How do you know what's going to work and what's going to be stable? So it's a lot of helping organizations get Automation faster in a more stable environment. >> We can certainly follow up on this train cause one of things I've been digging into is this idea of, open source and contribution, integrations are huge. The collections to me is super important because when we start thinking about integration that's one of Cloud native, supposedly strength is to be horizontally scalable, integrated, building abstraction layers as you had pointed out. So I've got to ask you with respect to open source. I was just talking with a bunch of founders yesterday here in Silicon Valley around as Cloud scales and certainly you seeing snowflake build on top of AWS. I mean, that's an amazing success story. You're starting to see these new innovations where the Cloud scale providers are providing great value propositions and the role open source is trying to keep pace. And so I got to ask you is still open source, let me say I believe it's important, but how does open source maintain its relevance as Cloud scale goes on? Because that's going to force Automation to go faster. Okay, and you got the major Cloud vendors promoting their own Cloud platforms. Yet you got the innovation of startups and companies. Your enterprises are starting to act like startups as container starts to get through this lift and shift phase. You'll see innovation coming from enterprises as well as startups. So you start to see this notion bring real value on top of these Clouds. What's your take on all this? >> Well, I think open source and the communities continue to be very, very important, particularly at the infrastructure layer, because to get all this innovation that you're talking about, you act, if you believe you've got a connected environment where folks are going to have different footprints and, and probably, you know, more than one public Cloud set of resources, it's only going to, the value is only going to be delivered if the workloads are portable, they're stable, they can be integrated, they can be secure. And so I think that the open source communities have become, you know, continue to be an incredibly important as a way to get industry alignment and shared innovation on the, on the platform and infrastructure and operational levels. And I think that that's, you know, going to be, be something that we're going to see for a long time. >> Well Mary, I really appreciate your insights, I got one final question, but I'll just give you a plug for the folks watching, check out Mary's work at IDC, really cutting edge and super important as Cloud management really is at the heart of all the, whether it's multicloud, on-premise hybrid or full Cloud lift and shift or Cloud native, management plays a huge important role right now. That's where the action is. You looking at the container growth as Mary you pointed out is great. So I have to ask you what comes next. What do you think management will do relative to Cloud management, as it evolves in these priority environments around Cloud, around on-premise as the operations start to move along, containers are critical. You talked about the growth is only five, 10%, a lot of headroom there. How is management going to evolve? >> Well, again, I think a lot of it is going to be is everything has to move faster. And that means that Automation actually becomes more and more important, but we're going to have to move from Automation at human speed to Automation at container and Cloud speed. And that means a lot is going to have to be driven by AI and ML analytics that can and observability solutions. So I think that that's going to be the next way is taking these, you know, very diverse sources of, of log and metrics and application traces and performance and end user experience and all these different things that tell us, how is the application actually running and how is the infrastructure behaving? And then putting together an analytics and Automation layer that can be a very autonomous. We have at IDC for doing a lot of research on the future of digital infrastructure. And this is a really fundamental tenant of what we believe is that autonomous operations is the future for a Cloud and IT. >> Final point for our friends out there and your friends out there watching who some are on the cutting edge, riding the big wave of Cloud native, they're at Cube calm, they're digging in, they're at service meshes, Kubernetes containers, you name it. And for the folks who have just been kind of grinding it out, an it operations, holding down the Fort, running the networks, running all the apps. What advice do you give the IT skillset friends out there that are watching. What should they be doing? What's your advice to them, Mary? >> Well, you know, we're going to continue to see the convergence of, of virtualized and container based infrastructure operations. So I think anyone out there that is in those sorts of roles really needs to be getting comfortable with programmatic code driven Automation and, and figuring out how to think about operations from more of a policy and scale scalability, point of view. Increasingly, you know, if you believe what I just said about the role of analytics driving Automation, it's going to have to be based on something, right? There's going to have to be rules. There's going to have to be policies is going to have to be, you know, configuration standards. And so kind of making that shift to not thinking so much about, you know, the one off lovingly handcrafted, handcrafted environment, thinking about how do we scale, how do we program it and starting to get comfort with, with some of these tools, like an Ansible, which is designed to be pretty accessible by folks with a large range of skillsets, it's human readable, it's Python based. You don't have to be a computer science major to be able to get started with it. So I think that that's what many folks have to do is start to think about expanding their skill sets to operate at even greater scale and speed. >> Mary, thanks so much for your time. Mary Johnston Turner, Vice President of Research at Cloud for Cloud management at IDC for the Ansible Fest virtual. I'm John Ferrier with theCUBE for cube coverage, cube virtual coverage of Ansible Fest, 2020 virtual. Thanks for watching.

>> Announcer: Live from Atlanta, Georgia, it's theCUBE. Covering AnsibleFest 2019. Brought to you by Red Hat. >> Welcome back everyone it's theCUBE's live coverage here in Atlanta, Georgia for Red Hat's AnsibleFest. #AnsibleFest, check out all the commentary on Twitter. Of course, we're here for two days, I'm John Furrier with Stu Miniman. Our next guest is Mary Johnston Turner, Research VP Cloud Management International Data Corp IDC. Welcome to theCUBE, thanks for joining us. >> Thank you. >> So IT operations has been an evolving thing. AI and automation really changing the landscape of this data equation. IT operations used to be, "Hey, you go to IT ops, no problem." Now with the world changing to be more software-driven, software-led, a lot's changed. What's your take? What's your research say about the IT ops landscape? >> Well, I mean, you have to put it in the context of what's going on generally with IT, right? I mean, we're clearly seeing DevOps, you know it's either in production or in large scale testing and the majority of enterprises. We've got lots and lots of containers and Kubernetes usage, we've got multiple clouds in just about every enterprise you talk to. It's, you know, well over 90%. And what that all means is that there's just a lot of change on a lot of different levels. And so that's kind of really put stress on traditional, operational approaches on task-oriented automation. you know, siloed approaches to control and monitoring. And what we're really starting to see is now a move to how to become more integrated, more unified and more collaborative across all these teams. And that's actually kind of driving to me for a new generation of monitoring automation and analytics kind of all put together. >> It's interesting how management software has always been part of every IT conversation we've had in over the past decades. And, but recently if you look up the evolution of cloud and hybrid multi-cloud, you mentioned that. CloudOne, Dot, Amazon, public cloud, pretty straightforward to comprehend. Start-up start there. But this whole other cloud paradigm is shifting has taken these categories like network management, turned them into observability. Five companies go public and M&A activity booming. Automation similar kind of vibe to it here. It's got this management piece to it that used to be this white space. Now the aperture seems to be increasing. What's your take on this? Because we're trying to make sense of it. Customers are trying to figure it out, obviously. They've been doing configuration management. But now they got scale, they got some of the things you mentioned. What's this automation category look like or is it a category? >> I don't know if it's a category or not but it's certainly a thing, right? I think what we're seeing with automation is historically, it was very individual driven. It was, "I have a problem", right? I have to configure something or deploy something and I could whip up a script, you know, do a little code and it worked for me and it wasn't documented and that was great, you know. And I think what we're happening now with just the way applications are being architected, I mean, you're moving to very modular, microservices-based approach to applications, the way they're deployed. All the dependencies across all the different tiers from network to storage to public cloud to private cloud. It's really very, very difficult to rely on a bunch of ad hoc tools to do that. And so I think what's happened with automation is it's expanding up to become as much a business collaboration platform, as it is just sort of a task, feeds and speeds sort of control platform. We're kind of in the middle of that evolution. Even, you know, two years ago I don't think you saw the kinds of analytics, you know, and machine learning and AI that we're now starting to see come in as an overlay to the automation environment. >> Mary, one of the things we've been talking about for the last couple of years is that great buzz word of digital transformation. The real driver for that is I need to be a data driven organization, not just ad hoc things. So where does automation fit into that broader discussion of, you know, changing operational models like you were talking about? >> Well I think, you know done right, it can really be a platform for collaboration and accelerating digital transformation across the enterprise. Because rather than having, you know, each team have to do their own thing and then do a manual hand off or a big change control meeting, you know, these things just don't scale and move quick enough in today's environments. Particularly if you're trying to update your applications every five minutes, right? So, I think the collaboration, the different teams and also a creative environment where you can have more generalists too, right? you know, there's collaboration across IT ops and DevOps and sort of the lines start to blur. >> Yeah, you mentioned the word platform and we were talking to the Ansible team, they were very specific as to how they chose that for customers out there. You know, choosing a platform is a bit of a commitment. It's not just a tactical, "We're going to do this." What's your thoughts on the Ansible automation platform and what feedback do you have to customers as to how they're deciding which platforms and how many platforms that they'll develop on? >> Yeah, it's a really interesting conversation. I mean, I think one of the things that the Ansible team's really focusing on that's important is the modularity. The fact that you can plug and play and kind of grow over time. And also that it's a very software-driven paradigm with the automation artifacts under source control. Which again is kind of different for a lot of ops teams. They don't have that notion of Git and software development all the time. So I think that having a platform approach that still allows a fair amount of modularity integration, and it lets different parts of the organization decide over time how much they want to participate in a very curated, consistent integration. And at the same time, at least in the Ansible world, because of the way it's architected, they can still have modules that call out to other automation, you know, solutions that are in the environment. So it's not an all or nothing, and I think that's really, really important. And it's also a platform for analytics. I'm sorry, but data, you know, about what's going on with the automation. >> The data's critical, but we had mentioned earlier on our previous interview with Red Hat folks and Stu and I's intro about the cloud and how the complexity that is being introduced, and you mentioned some of those earlier, the complexities are there. Of the automation solutions that you've seen, which one's having the most impact for customers? >> Well that, what do you mean by impact? There's such a, such a range of them. If you look in certainly the configuration, infrastructure as code space, obviously Ansible, there's a couple others. If you look into the CI/CD space, right? I mean there's a whole set of very optimized CI/CD tools out there that are very important to the DevOps environment. And, again, you'll see integrations between the infrastructure and the CI/CD, and they're all kind of blurring. And then you've got very specific, almost domain controllers, whether they're for hardware or converged infrastructure-type platforms, or whether they're for public clouds. And those don't go away, right? You still need something that understands the lower level system. And so, I think what we're seeing is organizations trying to reduce the number of individual siloed automation tools they've got, but they're still probably going to have more than one to do the full stack with something, you know, acting as kind of a policy-driven control plane in analytics-driven control plane in the middle. >> So, you've still got to run the plumbing. >> Right, exactly. >> You've still got to run the system now. >> Yeah, I mean something like 70 to 80% of the customers we talk to that are using one or more of the big public clouds, they're also using a fair amount of control tooling that's provided by those cloud vendors. And those aren't going to go away, because, you know, it's just like a hardware system. You got to have the drivers, right? You got to have the core, but you've got to be able to again have the process flow across it that's really important. >> What's your take on the market place shaking out the winners and losers? Because I know you like to track the marketplace from a research standpoint. It just seems that all the events we go to at theCube, everyone's jockeying for the control plane. >> They are. >> Or something. The control plane of the data. We're the control plane for the management. So, the control plane, meaning horizontally scalable, much more platform-centric. You're starting to see kind of a systems thinking coming back into the enterprise versus the siloed IT, but this illustrious control plane, (Mary laughing) I mean, how many control planes can there be? What's your take on all this craziness? >> That's a good question. I mean again, I think there is a difference between sort of the driver level, right? Which it used to be, again, those scripts. They were kind of like drivers, right? That's almost becoming just the playing field. You've got to have those integrations. You've got to have a nice modular way to architect that. What really is going to be the control plane is the data. It's the metrics around what are you doing. It's the performance, it's the security, and being able to actually optimize a lot of the SLOs that go along with that. That's really where the, you know, being able to do a good thing with the data, and tie it to the business and the app is where the real control is going to be. >> Mary, how's Ansible doing as a business? We saw a lot of proof points in the keynote about the community growth, obviously, adoption is up. But, anything you can share about how, you know, they've been doing really about four years into the Red Hat acquisition? >> Well they're, I mean, they're growing pretty effectively. They, I think this whole category is growing, and so they're benefiting quite a lot from that. I think we are seeing really strong growth in the partner communities. Particularly here at this show we are seeing some really, you know, larger and larger scale partnerships, more and more investment. And I think that is really important, because ultimately for a technology like this to scale, it's got to become embedded in all kinds of solutions. So, I look at much as the partner adoption as a good sign as anything. >> Well it's, you know, I guess two things. One is, the whole market's growing. Is Ansible doing better or worse than that? And what is the impact of those cloud-native tooling that you mentioned is, you know, I looked there's kind of Red Hat, the Ansible traditional competition, which was more in the infrastructure management space and now, yes, they do containerization, and work more in the cloud environment. They're kind of spanning between those environments. >> Well, I think, you know, again I see most organizations using multiple tools. I think, from a revenue and growth rate, I can't really get into it, because, as you know, Ansible is actually part of Red Hat, and Red Hat doesn't report out numbers at that level. But we see certainly see a lot of adoption. And we see Ansible, you know, at least if not the primary, as one of the major tools in more and more organizations. And that's across compute, storage, network, very, very popular in the network space, and then growing. Probably not quite as strong, but growing interest in like security and IoT. >> It's interesting you mention the numbers and how Ansible is now part of Red Hat. When Red Hat bought Ansible a couple years ago, I think the year before Stu and I were talking about how configuration management automation was going to come. We kind of saw it, but one of the things that in the community and Red Hat had publicly talked about is, Red Hat didn't screw it up. They kind of got it right, they kept them alone. They grew organically and this organic growth is kind of a forcing function for these new things. Are you happy with what Red Hat has done here with Ansible and this platform? What's your take on this platform? Because platforms have to enable. Good things and value. >> I think you're right. Ansible grew very virally and organically for a long time, but you kind of hit a wall with that at some point. I think they rightly recognized that they needed to have the kind of tooling, the kind of metrics, the kind of hub and modularity that would allow it to go the next level. So, I'm actually really encouraged by this announcement, and I think it also, again, it positions it I think to make partner driven-solutions much more easily standardized. It opens up, probably more ways for people to contribute to the communities. So I think it's really positive. >> And as a platform, if it's enabling value, what kind of value propositions do you see emerging? 'Cause you've got the content collections, the automation hub, automation analytics. Is it just bolting onto RHEL as value? What is some of the value that you might see coming out of the Ansible automation platform? >> Oh, well I mean Ansible's always been very agnostic. It's always been its own business which certainly can compliment RHEL. There's RHEL rolls and all kinds of stuff. But that's not really the focal point for Ansible. Ansible really is about providing that modular consistent automation approach that can span all these different operational domains, and really reach into the business process. So, I think it's great for the Red Hat portfolio, but now as we start to see them building bridges into the bigger IBM portfolio, you know, we haven't had a lot of IBM/Ansible announcements yet, but I would expect that we're going to see more over time. I think the OpenShift Operator integrations are going to be important as part of the things that IBM is doing with OpenShift. So, I think there's more to come. >> Mary, I wonder what your research finds regarding open source consumption in general. You know, how many of the customers out there are just using the free community addition? You know, Red Hat's very clear, you know, they are not, the open source is not Red Hat's business model. It is the way that they work. >> Mary: It's a development model. >> It's their development model. So, any general comments about open source, and specifically around Ansible, kind of the community free edition versus paid. >> Well, it's obviously been an interesting week in open source world with, not Red Hat, but some other vendors getting a little bit of flack for some of the choices they've made about their business practices. I think, you know, there are many, many organizations that continue to get started with unpaid, unsupported open source. What typically happens is if it gets to a critical mass within a company, at some point they're going to say, either I have to invest a lot of people and time and do all the testing, hardening, integration, tracking the security updates you know, and they're still never going to get notified directly from intel when there's a problem, right? So, I think many organizations as they, if they decide this is mission critical then they start to look for supported editions. And we've done a lot of research looking at the benefits of getting that level of support and typically, it's just 50 to 60% improvements and, you know, stability, security, time-to-market because you're not having to do all that work. So, its a trade-off, but you'll always have some, particularly smaller organizations, individual teams that they're not going to pay for it. But I think its scale is when it really becomes valuable. >> Mary, final question for you, for the folks watching that couldn't make the event or industry insiders that aren't in this area. Why is this AnsibleFest more important this year than ever before? What's the big story? What's the top thing happening now in this world? >> I mean, there's great energy here this year. And I've gone to a couple of these over the years. First of all, it's the biggest one they've ever had. I think really though, it's the story of collaboration, building teams, automating end-to-end processes. And that's really powerful, because it's very clear that the community has stepped up from just saying, I can do a great job with network automation, or I can do a great job with cloud or with server. And they're really saying, this is about transforming the organization. Making the organization more productive, making the business more agile. And I think that is a big step for Ansible. >> You know, I think that is a huge point. I think that's something that's really important, because you know, we've talked about capabilities before. It does this, it does that to your point. This is kind of a testament to the operationalizing of DevOps. 'Cause people have always been the bottleneck. So this seems to be the trend. Is that what you're saying? >> Yeah, I think so. And I also see, again, this community talking so much about upscaling the people. Embracing things like unit testing and source control. And it's a maturation of the whole automation conversation among this community. And remember, this community is only what? Six, seven years old? >> Stu: 2012. >> Yeah, I mean it's really a very, very young community. So I think it's a really important pivot point, just in terms of the scale of the problems they can address. >> Solve for abstractions. Solving big problem, automation will be a great category. Mary, thanks so much for coming on theCUBE. Sharing your insights and your research and your analysis. I appreciate it. >> Okay, thank you. >> Mary Johnston Turner Research VP of Cloud Management at IDC, here inside theCUBE. Breaking down the analysis of Red Hat's Ansible position vis-a-vis the market trends. It's theCUBE, I'm John Furrier with Stu Miniman. Stay with us for more coverage after this short break. (upbeat techno music)

>> From the SiliconANGLE Media office in Boston, Massachusetts, it's theCube! (funky electronic music) Now, here's your host, Dave Vellante! >> Welcome, everybody, to this Cube conversation here in our Marlborough offices. I am very excited today, I spent a number of years at IDC, which, of course, is owned by IDG. And there's a new book out, relatively new, called Future Forward: Leadership Lessons from Patrick McGovern, the Visionary Who Circled the Globe and Built a Technology Media Empire. And it's a great book, lotta stories that I didn't know, many that I did know, and the author of that book, Glenn Rifkin, is here to talk about not only Pat McGovern but also some of the lessons that he put forth to help us as entrepreneurs and leaders apply to create better businesses and change the world. Glenn, thanks so much for comin' on theCube. >> Thank you, Dave, great to see ya. >> So let me start with, why did you write this book? >> Well, a couple reasons. The main reason was Patrick McGovern III, Pat's son, came to me at the end of 2016 and said, "My father had died in 2014 and I feel like his legacy deserves a book, and many people told me you were the guy to do it." So the background on that I, myself, worked at IDG back in the 1980s, I was an editor at Computerworld, got to know Pat during that time, did some work for him after I left Computerworld, on a one-on-one basis. Then I would see him over the years, interview him for the New York Times or other magazines, and every time I'd see Pat, I'd end our conversation by saying, "Pat, when are we gonna do your book?" And he would laugh, and he would say, "I'm not ready to do that yet, there's just still too much to do." And so it became sort of an inside joke for us, but I always really did wanna write this book about him because I felt he deserved a book. He was just one of these game-changing pioneers in the tech industry. >> He really was, of course, the book was even more meaningful for me, we, you and I started right in the same time, 1983-- >> Yeah. >> And by that time, IDG was almost 20 years old and it was quite a powerhouse then, but boy, we saw, really the ascendancy of IDG as a brand and, you know, the book reviews on, you know, the back covers are tech elite: Benioff wrote the forward, Mark Benioff, you had Bill Gates in there, Walter Isaacson was in there, Guy Kawasaki, Bob Metcalfe, George Colony-- >> Right. >> Who actually worked for a little stint at IDC for a while. John Markoff of The New York Times, so, you know, the elite of tech really sort of blessed this book and it was really a lot to do with Pat McGovern, right? >> Oh, absolutely, I think that the people on the inside understood how important he was to the history of the tech industry. He was not, you know, a household name, first of all, you didn't think of Steve Jobs, Bill Gates, and then Pat McGovern, however, those who are in the know realize that he was as important in his own way as they were. Because somebody had to chronicle this story, somebody had to share the story of the evolution of this amazing information technology and how it changed the world. And Pat was never a front-of-the-TV-camera guy-- >> Right. >> He was a guy who put his people forward, he put his products forward, for sure, which is why IDG, as a corporate name, you know, most people don't know what that means, but people did know Macworld, people did know PCWorld, they knew IDC, they knew Computerworld for sure. So that was Pat's view of the world, he didn't care whether he had the spotlight on him or not. >> When you listen to leaders like Reed Hoffman or Eric Schmidt talk about, you know, great companies and how to build great companies, they always come back to culture. >> Yup. >> The book opens with a scene of, and we all, that I usually remember this, well, we're just hangin' around, waitin' for Pat to come in and hand out what was then called the Christmas bonus-- >> Right. >> Back when that wasn't politically incorrect to say. Now, of course, it's the holiday bonus. But it was, it was the Christmas bonus time and Pat was coming around and he was gonna personally hand a bonus, which was a substantial bonus, to every single employee at the company. I mean, and he did that, really, literally, forever. >> Forever, yeah. >> Throughout his career. >> Yeah, it was unheard of, CEOs just didn't do that and still don't do that, you were lucky, you got a message on the, you know, in the lunchroom from the CEO, "Good work, troops! Keep up the good work!" Pat just had a really different view of the culture of this company, as you know from having been there, and I know. It was very familial, there was a sense that we were all in this together, and it really was important for him to let every employee know that. The idea that he went to every desk in every office for IDG around the United States, when we were there in the '80s there were probably 5,000 employees in the US, he had to devote substantial amount-- >> Weeks and weeks! >> Weeks at a time to come to every building and do this, but year after year he insisted on doing it, his assistant at the time, Mary Dolaher told me she wanted to sign the cards, the Christmas cards, and he insisted that he ensign every one of them personally. This was the kind of view he had of how you keep employees happy, if your employees are happy, the customers are gonna be happy, and you're gonna make a lot of money. And that's what he did. >> And it wasn't just that. He had this awesome holiday party that you described, which was epic, and during the party, they would actually take pictures of every single person at the party and then they would load the carousel, you remember the 35-mm. carousel, and then, you know, toward the end of the evening, they would play that and everybody was transfixed 'cause they wanted to see their, the picture of themselves! >> Yeah, yeah. (laughs) >> I mean, it was ge-- and to actually pull that off in the 1980s was not trivial! Today, it would be a piece of cake. And then there was the IDG update, you know, the Good News memos, there was the 10-year lunch, the 20-year trips around the world, there were a lot of really rich benefits that, you know, in and of themselves maybe not a huge deal, but that was the culture that he set. >> Yeah, there was no question that if you talked to anybody who worked in this company over, say, the last 50 years, you were gonna get the same kind of stories. I've been kind of amazed, I'm going around, you know, marketing the book, talking about the book at various events, and the deep affection for this guy that still holds five years after he died, it's just remarkable. You don't really see that with the CEO class, there's a couple, you know, Steve Jobs left a great legacy of creativity, he was not a wonderful guy to his employees, but Pat McGovern, people loved this guy, and they st-- I would be signing books and somebody'd say, "Oh, I've been at IDG for 27 years and I remember all of this," and "I've been there 33 years," and there's a real longevity to this impact that he had on people. >> Now, the book was just, it was not just sort of a biography on McGovern, it was really about lessons from a leader and an entrepreneur and a media mogul who grew this great company in this culture that we can apply, you know, as business people and business leaders. Just to give you a sense of what Pat McGovern did, he really didn't take any outside capital, he did a little bit of, you know, public offering with IDG Books, but, really, you know, no outside capital, it was completely self-funded. He built a $3.8 billion empire, 300 publications, 280 million readers, and I think it was almost 100 or maybe even more, 100 countries. And so, that's an-- like you were, used the word remarkable, that is a remarkable achievement for a self-funded company. >> Yeah, Pat had a very clear vision of how, first of all, Pat had a photographic memory and if you were a manager in the company, you got a chance to sit in meetings with Pat and if you didn't know the numbers better than he did, which was a tough challenge, you were in trouble! 'Cause he knew everything, and so, he was really a numbers-focused guy and he understood that, you know, his best way to make profit was to not be looking for outside funding, not to have to share the wealth with investors, that you could do this yourself if you ran it tightly, you know, I called it in the book a 'loose-tight organization,' loose meaning he was a deep believer in decentralization, that every market needed its own leadership because they knew the market, you know, in Austria or in Russia or wherever, better than you would know it from a headquarters in Boston, but you also needed that tightness, a firm grip on the finances, you needed to know what was going on with each of the budgets or you were gonna end up in big trouble, which a lot of companies find themselves in. >> Well, and, you know, having worked there, I mean, essentially, if you made your numbers and did so ethically, and if you just kind of followed some of the corporate rules, which we'll talk about, he kind of left you alone. You know, you could, you could pretty much do whatever you wanted, you could stay in any hotel, you really couldn't fly first class, and we'll maybe talk about that-- >> Right. >> But he was a complex man, I mean, he was obviously wealthy, he was a billionaire, he was very generous, but at the same time he was frugal, you know, he drove, you know, a little, a car that was, you know, unremarkable, and we had buy him a car. He flew coach, and I remember one time, I was at a United flight, and I was, I had upgraded, you know, using my miles, and I sat down and right there was Lore McGovern, and we both looked at each other and said right at the same time, "I upgraded!" (laughs) Because Pat never flew up front, but he would always fly with a stack of newspapers in the seat next to him. >> Yeah, well, woe to, you were lucky he wasn't on the plane and spotted you as he was walking past you into coach, because he was not real forgiving when he saw people, people would hide and, you know, try to avoid him at all cost. And, I mean, he was a big man, Pat was 6'3", you know, 250 lbs. at least, built like a linebacker, so he didn't fit into coach that well, and he wasn't flying, you know, the shuttle to New York, he was flyin' to Beijing, he was flyin' to Moscow, he was going all over the world, squeezing himself into these seats. Now, you know, full disclosure, as he got older and had, like, probably 10 million air miles at his disposal, he would upgrade too, occasionally, for those long-haul flights, just 'cause he wanted to be fresh when he would get off the plane. But, yeah, these are legends about Pat that his frugality was just pure legend in the company, he owned this, you know, several versions of that dark blue suit, and that's what you would see him in. He would never deviate from that. And, but, he had his patterns, but he understood the impact those patterns had on his employees and on his customers. >> I wanna get into some of the lessons, because, really, this is what the book is all about, the heart of it. And you mentioned, you know, one, and we're gonna tell from others, but you really gotta stay close to the customer, that was one of the 10 corporate values, and you remember, he used to go to the meetings and he'd sometimes randomly ask people to recite, "What's number eight?" (laughs) And you'd be like, oh, you'd have your cheat sheet there. And so, so, just to give you a sense, this man was an entrepreneur, he started the company in 1964 with a database that he kind of pre-sold, he was kind of the sell, design, build type of mentality, he would pre-sold this thing, and then he started Computerworld in 1967, so it was really only a few years after he launched the company that he started the Computerworld, and other than Data Nation, there was nothing there, huge pent-up demand for that type of publication, and he caught lightning in a bottle, and that's really how he funded, you know, the growth. >> Yeah, oh, no question. Computerworld became, you know, the bible of the industry, it became a cash cow for IDG, you know, but at the time, it's so easy to look in hindsight and say, oh, well, obviously. But when Pat was doing this, one little-known fact is he was an editor at a publication called Computers and Automation that was based in Newton, Massachusetts and he kept that job even after he started IDC, which was the original company in 1964. It was gonna be a research company, and it was doing great, he was seeing the build-up, but it wasn't 'til '67 when he started Computerworld, that he said, "Okay, now this is gonna be a full-time gig for me," and he left the other publication for good. But, you know, he was sorta hedging his bets there for a little while. >> And that's where he really gained respect for what we'll call the 'Chinese Wallet,' the, you know, editorial versus advertising. We're gonna talk about that some more. So I mentioned, 1967, Computerworld. So he launched in 1964, by 1971, he was goin' to Japan, we're gonna talk about the China Stories as well, so, he named the company International Data Corp, where he was at a little spot in Newton, Mass.-- >> Right, right. >> So, he had a vision. You said in your book, you mention, how did this gentleman get it so right for so long? And that really leads to some of the leadership lessons, and one of them in the book was, sort of, have a mission, have a vision, and really, Pat was always talking about information, about information technology, in fact, when Wine for Dummies came out, it kind of created a little friction, that was really off the center. >> Or Wine for Dummies, or Sex for Dummies! >> Yeah, Sex for Dummies, boy, yeah! >> With, that's right, Ruth Westheimer-- >> Dr. Ruth Westheimer. >> But generally speaking, Glenn, he was on that mark, he really didn't deviate from that vision. >> Yeah, no, it was very crucial to the development of the company that he got people to, you know, buy into that mission, because the mission was everything. And he understood, you know, he had the numbers, but he also saw what was happening out there, from the 1960s, when IBM mainframes filled a room, and, you know, only the high priests of data centers could touch them. He had a vision for, you know, what was coming next and he started to understand that there would be many facets to this information about information technology, it wasn't gonna be boring, if anything, it was gonna be the story of our age and he was gonna stick to it and sell it. >> And, you know, timing is everything, but so is, you know, Pat was a workaholic and had an amazing mind, but one of the things I learned from the book, and you said this, Pat Kenealy mentioned it, all American industrial and social revolutions have had a media company linked to them, Crane and automobiles, Penton and energy, McGraw-Hill and aerospace, Annenberg, of course, and TV, and in technology, it was IDG. >> Yeah, he, like I said earlier, he really was a key figure in the development of this industry and it was, you know, one of the key things about that, a lot publications that came and went made the mistake of being platform or, you know, vertical market specific. And if that market changed, and it was inevitably gonna change in high tech, you were done. He never, you know, he never married himself to some specific technology cycle. His idea was the audience was not gonna change, the audience was gonna have to roll with this, so, the company, IDG, would produce publications that got that, you know, Computerworld was actually a little bit late to the PC game, but eventually got into it and we tracked the different cycles, you know, things in tech move in sine waves, they come and go. And Pat never was, you know, flustered by that, he could handle any kind of changes from the mainframes down to the smartphone when it came. And so, that kind of flexibility, and ability to adjust to markets, really was unprecedented in that particular part of the market. >> One of the other lessons in the book, I call it 'nation-building,' and Pat shared with you that, look, that you shared, actually, with your readers, if you wanna do it right, you've gotta be on the ground, you've gotta be there. And the China story is one that I didn't know about how Pat kind of talked his way into China, tell us, give us a little summary of that story. >> Sure, I love that story because it's so Pat. It was 1978, Pat was in Tokyo on a business trip, one of his many business trips, and he was gonna be flying to Moscow for a trade show. And he got a flight that was gonna make a stopover in Beijing, which in those days was called Peking, and was not open to Americans. There were no US and China diplomatic relations then. But Pat had it in mind that he was going to get off that plane in Beijing and see what he could see. So that meant that he had to leave the flight when it landed in Beijing and talk his way through the customs as they were in China at the time with folks in the, wherever, the Quonset hut that served for the airport, speaking no English, and him speaking no Chinese, he somehow convinced these folks to give him a day pass, 'cause he kept saying to them, "I'm only in transit, it's okay!" (laughs) Like, he wasn't coming, you know, to spy on them on them or anything. So here's this massive American businessman in his dark suit, and he somehow gets into downtown Beijing, which at the time was mostly bicycles, very few cars, there were camels walking down the street, they'd come with traders from Mongolia. The people were still wearing the drab outfits from the Mao era, and Pat just spent the whole day wandering around the city, just soaking it in. He was that kind of a world traveler. He loved different cultures, mostly eastern cultures, and he would pop his head into bookstores. And what he saw were people just clamoring to get their hands on anything, a newspaper, a magazine, and it just, it didn't take long for the light bulb to go on and said, this is a market we need to play in. >> He was fascinated with China, I, you know, as an employee and a business P&L manager, I never understood it, I said, you know, the per capita spending on IT in China was like a dollar, you know? >> Right. >> And I remember my lunch with him, my 10-year lunch, he said, "Yeah, but, you know, there's gonna be a huge opportunity there, and yeah, I don't know how we're gonna get the money out, maybe we'll buy a bunch of tea and ship it over, but I'm not worried about that." And, of course, he meets Hugo Shong, which is a huge player in the book, and the home run out of China was, of course, the venture capital, which he started before there was even a stock market, really, to exit in China. >> Right, yeah. No, he was really a visionary, I mean, that word gets tossed around maybe more than it should, but Pat was a bonafide visionary and he saw things in China that were developing that others didn't see, including, for example, his own board, who told him he was crazy because in 1980, he went back to China without telling them and within days he had a meeting with the ministry of technology and set up a joint venture, cost IDG $250,000, and six months later, the first issue of China Computerworld was being published and within a couple of years it was the biggest publication in China. He said, told me at some point that $250,0000 investment turned into $85 million and when he got home, that first trip, the board was furious, they said, "How can you do business with the commies? You're gonna ruin our brand!" And Pat said, "Just, you know, stick with me on this one, you're gonna see." And the venture capital story was just an offshoot, he saw the opportunity in the early '90s, that venture in China could in fact be a huge market, why not help build it? And that's what he did. >> What's your take on, so, IDG sold to, basically, Chinese investors. >> Yeah. >> It's kind of bittersweet, but in the same time, it's symbolic given Pat's love for China and the Chinese people. There's been a little bit of criticism about that, I know that the US government required IDC to spin out its supercomputer division because of concerns there. I'm always teasing Michael Dow that at the next IDG board meeting, those Lenovo numbers, they're gonna look kinda law. (laughs) But what are your, what's your, what are your thoughts on that, in terms of, you know, people criticize China in terms of IP protections, etc. What would Pat have said to that, do you think? >> You know, Pat made 130 trips to China in his life, that's, we calculated at some point that just the air time in planes would have been something like three and a half to four years of his life on planes going to China and back. I think Pat would, today, acknowledge, as he did then, that China has issues, there's not, you can't be that naive. He got that. But he also understood that these were people, at the end of the day, who were thirsty and hungry for information and that they were gonna be a player in the world economy at some point, and that it was crucial for IDG to be at the forefront of that, not just play later, but let's get in early, let's lead the parade. And I think that, you know, some part of him would have been okay with the sale of the company to this conglomerate there, called China Oceanwide. Clearly controversial, I mean, but once Pat died, everyone knew that the company was never gonna be the same with the leader who had been at the helm for 50 years, it was gonna be a tough transition for whoever took over. And I think, you know, it's hard to say, certainly there's criticism of things going on with China. China's gonna be the hot topic page one of the New York Times almost every single day for a long time to come. I think Pat would have said, this was appropriate given my love of China, the kind of return on investment he got from China, I think he would have been okay with it. >> Yeah, and to invoke the Ben Franklin maxim, "Trading partners seldom wage war," and so, you know, I think Pat would have probably looked at it that way, but, huge home run, I mean, I think he was early on into Baidu and Alibaba and Tencent and amazing story. I wanna talk about decentralization because that was always something that was just on our minds as employees of IDG, it was keep the corporate staff lean, have a flat organization, if you had eight, 10, 12 direct reports, that was okay, Pat really meant it when he said, "You're the CEO of your own business!" Whether that business was, you know, IDC, big company, or a manager at IDC, where you might have, you know, done tens of millions of dollars, but you felt like a CEO, you were encouraged to try new things, you were encouraged to fail, and fail fast. Their arch nemesis of IDG was Ziff Davis, they were a command and control, sort of Bill Ziff, CMP to a certain extent was kind of the same way out of Manhasset, totally different philosophies and I think Pat never, ever even came close to wavering from that decentralization philosophy, did he? >> No, no, I mean, I think that the story that he told me that I found fascinating was, he didn't have an epiphany that decentralization would be the mechanism for success, it was more that he had started traveling, and when he'd come back to his office, the memos and requests and papers to sign were stacked up two feet high. And he realized that he was holding up the company because he wasn't there to do this and that at some point, he couldn't do it all, it was gonna be too big for that, and that's when the light came on and said this decentralization concept really makes sense for us, if we're gonna be an international company, which clearly was his mission from the beginning, we have to say the people on the ground in those markets are the people who are gonna make the decisions because we can't make 'em from Boston. And I talked to many people who, were, you know, did a trip to Europe, met the folks in London, met the folks in Munich, and they said to a person, you know, it was so ahead of its time, today it just seems obvious, but in the 1960s, early '70s, it was really not a, you know, a regular leadership tenet in most companies. The command and control that you talked about was the way that you did business. >> And, you know, they both worked, but, you know, from a cultural standpoint, clearly IDG and IDC have had staying power, and he had the three-quarter rule, you talked about it in your book, if you missed your numbers three quarters in a row, you were in trouble. >> Right. >> You know, one quarter, hey, let's talk, two quarters, we maybe make some changes, three quarters, you're gone. >> Right. >> And so, as I said, if you were makin' your numbers, you had wide latitude. One of the things you didn't have latitude on was I'll call it 'pay to play,' you know, crossing that line between editorial and advertising. And Pat would, I remember I was at a meeting one time, I'm sorry to tell these stories, but-- >> That's okay. (laughs) >> But we were at an offsite meeting at a woods meeting and, you know, they give you a exercise, go off and tell us what the customer wants. Bill Laberis, who's the editor-in-chief at Computerworld at the time, said, "Who's the customer?" And Pat said, "That's a great question! To the publisher, it's the advertiser. To you, Bill, and the editorial staff, it's the reader. And both are equally important." And Pat would never allow the editorial to be compromised by the advertiser. >> Yeah, no, he, there was a clear barrier between church and state in that company and he, you know, consistently backed editorial on that issue because, you know, keep in mind when we started then, and I was, you know, a journalist hoping to, you know, change the world, the trade press then was considered, like, a little below the mainstream business press. The trade press had a reputation for being a little too cozy with the advertisers, so, and Pat said early on, "We can't do that, because everything we have, our product is built, the brand is built on integrity. And if the reader doesn't believe that what we're reporting is actually true and factual and unbiased, we're gonna lose to the advertisers in the long run anyway." So he was clear that that had to be the case and time and again, there would be conflict that would come up, it was just, as you just described it, the publishers, the sales guys, they wanted to bring in money, and if it, you know, occasionally, hey, we could nudge the editor of this particular publication, "Take it a little bit easier on this vendor because they're gonna advertise big with us," Pat just would always back the editor and say, "That's not gonna happen." And it caused, you know, friction for sure, but he was unwavering in his support. >> Well, it's interesting because, you know, Macworld, I think, is an interesting case study because there were sort of some backroom dealings and Pat maneuvered to be able to get the Macworld, you know, brand, the license for that. >> Right. >> But it caused friction between Steve Jobs and the writers of Macworld, they would write something that Steve Jobs, who was a control freak, couldn't control! >> Yeah. (laughs) >> And he regretted giving IDG the license. >> Yeah, yeah, he once said that was the worst decision he ever made was to give the license to Pat to, you know, Macworlld was published on the day that Mac was introduced in 1984, that was the deal that they had and it was, what Jobs forgot was how important it was to the development of that product to have a whole magazine devoted to it on day one, and a really good magazine that, you know, a lot of people still lament the glory days of Macworld. But yeah, he was, he and Steve Jobs did not get along, and I think that almost says a lot more about Jobs because Pat pretty much got along with everybody. >> That church and state dynamic seems to be changing, across the industry, I mean, in tech journalism, there aren't any more tech journalists in the United States, I mean, I'm overstating that, but there are far fewer than there were when we were at IDG. You're seeing all kinds of publications and media companies struggling, you know, Kara Swisher, who's the greatest journalist, and Walt Mossberg, in the tech industry, try to make it, you know, on their own, and they couldn't. So, those lines are somewhat blurring, not that Kara Swisher is blurring those lines, she's, you know, I think, very, very solid in that regard, but it seems like the business model is changing. As an observer of the markets, what do you think's happening in the publishing world? >> Well, I, you know, as a journalist, I'm sort of aghast at what's goin' on these days, a lot of my, I've been around a long time, and seeing former colleagues who are no longer in journalism because the jobs just started drying up is, it's a scary prospect, you know, unlike being the enemy of the people, the first amendment is pretty important to the future of the democracy, so to see these, you know, cutbacks and newspapers going out of business is difficult. At the same time, the internet was inevitable and it was going to change that dynamic dramatically, so how does that play out? Well, the problem is, anybody can post anything they want on social media and call it news, and the challenge is to maintain some level of integrity in the kind of reporting that you do, and it's more important now than ever, so I think that, you know, somebody like Pat would be an important figure if he was still around, in trying to keep that going. >> Well, Facebook and Google have cut the heart out of, you know, a lot of the business models of many media companies, and you're seeing sort of a pendulum swing back to nonprofits, which, I understand, speaking of folks back in the mid to early 1900s, nonprofits were the way in which, you know, journalism got funded, you know, maybe it's billionaires buying things like the Washington Post that help fund it, but clearly the model's shifting and it's somewhat unclear, you know, what's happening there. I wanted to talk about another lesson, which, Pat was the head cheerleader. So, I remember, it was kind of just after we started, the Computerworld's 20th anniversary, and they hired the marching band and they walked Pat and Mary Dolaher walked from 5 Speen Street, you know, IDG headquarters, they walked to Computerworld, which was up Old, I guess Old Connecticut Path, or maybe it was-- >> It was actually on Route 30-- >> Route 30 at the time, yeah. And Pat was dressed up as the drum major and Mary as well, (laughs) and he would do crazy things like that, he'd jump out of a plane with IDG is number one again, he'd post a, you know, a flag in Antarctica, IDG is number one again! It was just a, it was an amazing dynamic that he had, always cheering people on. >> Yeah, he was, he was, when he called himself the CEO, the Chief Encouragement Officer, you mentioned earlier the Good News notes. Everyone who worked there, at some point received this 8x10" piece of paper with a rainbow logo on it and it said, "Good News!" And there was a personal note from Pat McGovern, out of the blue, totally unexpected, to thank you and congratulate you on some bit of work, whatever it was, if you were a reporter, some article you wrote, if you were a sales guy, a sale that you made, and people all over the world would get these from him and put them up in their cubicles because it was like a badge of honor to have them, and people, I still have 'em, (laughs) you know, in a folder somewhere. And he was just unrelenting in supporting the people who worked there, and it was, the impact of that is something you can't put a price tag on, it's just, it stays with people for all their lives, people who have left there and gone on to four or five different jobs always think fondly back to the days at IDG and having, knowing that the CEO had your back in that manner. >> The legend of, and the legacy of Patrick J. McGovern is not just in IDG and IDC, which you were interested in in your book, I mean, you weren't at IDC, I was, and I was started when I saw the sort of downturn and then now it's very, very successful company, you know, whatever, $3-400 million, throwin' off a lot of profits, just to decide, I worked for every single CEO at IDC with the exception of Pat McGovern, and now, Kirk Campbell, the current CEO, is moving on Crawford del Prete's moving into the role of president, it's just a matter of time before he gets CEO, so I will, and I hired Crawford-- >> Oh, you did? (laughs) >> So, I've worked for and/or hired every CEO of IDC except for Pat McGovern, so, but, the legacy goes beyond IDG and IDC, great brands. The McGovern Brain Institute, 350 million, is that right? >> That's right. >> He dedicated to studying, you know, the human brain, he and Lore, very much involved. >> Yup. >> Typical of Pat, he wasn't just, "Hey, here's the check," and disappear. He was goin' in, "Hey, I have some ideas"-- >> Oh yeah. >> Talk about that a little. >> Yeah, well, this was a guy who spent his whole life fascinated by the human brain and the impact technology would have on the human brain, so when he had enough money, he and Lore, in 2000, gave a $350 million gift to MIT to create the McGovern Institute for Brain Research. At the time, the largest academic gift ever given to any university. And, as you said, Pat wasn't a guy who was gonna write a check and leave and wave goodbye. Pat was involved from day one. He and Lore would come and sit in day-long seminars listening to researchers talk about about the most esoteric research going on, and he would take notes, and he wasn't a brain scientist, but he wanted to know more, and he would talk to researchers, he would send Good News notes to them, just like he did with IDG, and it had same impact. People said, "This guy is a serious supporter here, he's not just showin' up with a checkbook." Bob Desimone, who's the director of the Brain Institute, just marveled at this guy's energy level, that he would come in and for days, just sit there and listen and take it all in. And it just, it was an indicator of what kind of person he was, this insatiable curiosity to learn more and more about the world. And he wanted his legacy to be this intersection of technology and brain research, he felt that this institute could cure all sorts of brain-related diseases, Alzheimer's, Parkinson's, etc. And it would then just make a better future for mankind, and as corny as that might sound, that was really the motivator for Pat McGovern. >> Well, it's funny that you mention the word corny, 'cause a lot of people saw Pat as somewhat corny, but, as you got to know him, you're like, wow, he really means this, he loves his company, the company was his extended family. When Pat met his untimely demise, we held a crowd chat, crowdchat.net/thankspat, and there's a voting mechanism in there, and the number one vote was from Paul Gillen, who posted, "Leo Durocher said that nice guys finish last, Pat McGovern proved that wrong." >> Yeah. >> And I think that's very true and, again, awesome legacy. What number book is this for you? You've written a lot of books. >> This is number 13. >> 13, well, congratulations, lucky 13. >> Thank you. >> The book is Fast Forward-- >> Future Forward. >> I'm sorry, Future Forward! (laughs) Future Forward by Glenn Rifkin. Check out, there's a link in the YouTube down below, check that out and there's some additional information there. Glenn, congratulations on getting the book done, and thanks so much for-- >> Thank you for having me, this is great, really enjoyed it. It's always good to chat with another former IDGer who gets it. (laughs) >> Brought back a lot of memories, so, again, thanks for writing the book. All right, thanks for watching, everybody, we'll see you next time. This is Dave Vellante. You're watchin' theCube. (electronic music)