a16z Podcast - The Open Source CIO

Episode Date: February 28, 2020

In 2014, in "Why There Will Never Be Another Red Hat," Peter Levine argued that Red Hat’s open source business model of commercializing support and services was highly difficult to replicate. Instead, he predicted the future of open source companies would be open source-as-a-service. And today SaaS has emerged as the dominant business model.In this podcast, recorded as a hallway-style conversation as part of the a16z Innovation Summit last year, Peter chats with Red Hat CIO, Mike Kelly, about what it means to be an open source CIO today – and how even Red Hat is evolving in the open SaaS era. They cover everything from why open hybrid has become the dominant enterprise architecture to how CIOs should think about adopting new technologies to what it takes for an M&A to be successful, beyond the spreadsheets.

The content here is for informational purposes only, should not be taken as legal business, tax, or investment advice, or be used to evaluate any investment or security and is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Hi, and welcome to the A16Z podcast. I'm Doss, and in this episode, we pull Mike Kelly, CIO of Red Hat into a hallway-style conversation with A16Z general partner. Peter Levine as part of our annual A16 Z Innovation Summit, which happened late last year. We cover a lot of ground. They finish with M&A, given Red Hat has both been acquired and been an acquirer. Along the way, though, they touch on open-hybrid architectures, when an open-source project becomes a product, and where services come in for an open-source startup. They start with a quick take from Peter on his classic post from 2014, why there will never be

another Red Hat. Red Hat did such a great job in pioneering what I call open source 1.0, the free and support model, that their scale and capacity really made them a one-off. As a startup, to be able to go and create the same backend infrastructure is quite expensive to go and do. So let me go one step further here. I don't believe there will be another Red Hat. with the Red Hat business model. However, I believe that there will be many, many, many successful open source companies into the future that have different business models from Red Hat that are further unlocking the potential of open source, specifically open source as a service.

If we look at the history of open source, as soon as the economics come into balance with the technology, we see entrepreneurs flourish and the community flourishes because there's sustainability. And I think this whole SaaS, you know, open source as a service has unlocked a whole new economic model. Peter's article ended with maybe even Red Hat should think about becoming the next Amazon. And I think alluding to this kind of SaaS era that we're in, how has that changed how you're approaching open source and open source communities. Well, I think that our model started off as a on-prem subscription, which was pretty unique at the time. And as the cloud, the public cloud has taken home,

one of the benefits that we see is all of those technologies are built on the core asset that we have, which is Linux, and the different providers have different instantiations of that technology, different distributions of it. But our approach was to make sure that our technology runs on all of them because to us it doesn't really make a difference. So we have partnerships with all of the major cloud providers, and we obviously have our on-prem capabilities,

as well. And so the idea of this hybrid world is the one we placed a lot of bets on, the one that actually fortunately has evolved to sort of be the dominant design. So you talk a little bit about the dominant design. How do you view this emerging enterprise architecture? Where are we in that open or hybrid future? There was this view about five years ago, I would say, that the cloud takes over. There would be no more on-prem. There would only be one cloud provider. And now what we're seeing is that there are multiple cloud providers. And the pendulum has sort of swung back to where there's a right place for certain on-prem software and infrastructure and applications.

And there's the right use of the cloud. And there are many tools now that makes the integration of public and private, i.e. hybrid seamless across these different domains. And once we have that, there's really no edge or core, there's just compute. When we first started studying cloud and all of its different instantiations of what it was going to be and the hype that surrounded it, it was a binary thing, right? It was either you're all public or you're all on-prem, and it's just like, come on, that doesn't make any sense.

So what has come to fruition now, I think, is everybody's starting to recognize all the choice that's available, and all the just incredible amount of innovation that's taken place that for someone in a job like mine, it's our responsibility and our job to take advantage of it. So the means by which I can manage it is almost as important as the means in which I can just use it. If you're in my job, your partners and other functions in the company shouldn't care where, you know, what's underneath the solution. All they should care about is that the solution is correct and it's optimized both for agility and cost purposes for whatever problem you're trying to solve. Peter, you've said software as a service has really cracked open open source in terms of its valuations and its potential. But at the same time,

the end customer doesn't really know if it's open source or not. From a development standpoint, we get all the innovation, the community, the bug fixing that open source has been great at for the past what, 30, 40 years. But really, we can monetize open source at the full value of that software. software because people don't care. All they want is the service. Just give me whatever that software provides, and I don't really care whether it's open source or not. And oh, by the way, I'm willing to pay full value for that stack. In the 1.0 era, the economic problem, and I ran an open source company in the 1.0 era, I know the economic problem, is a buyer would compare, would say, okay, you're giving away your software for free and charging for support. Then I'm going to go

compare you to your proprietary counterpart. And the proprietary counterpart charges 80 cents for the software and 20 cents for support. Therefore, we're going to only pay you 20 cents because all you're doing is providing support. Now, if it's run as a service and support and the service of the software is all built in together, it's a hundred cents. And let me also add that going from open source bits, the source code, to creating a reliable, manageable service, there's a lot of work in that. So it's not like you have open source and all of a sudden you cobble this stuff together and you get open source as a service. There's a huge difference between a project and a product. And that is really, really important, especially if you're in my role in a company

and you are inevitably going to have members of your team saying, well, we'll just get the free version. Right. And it's like, okay, well, who's going to patch it? Who we're relying on to provide, you know, feature function updates, integration, et cetera, et cetera, et cetera. So the notion that people don't care because it's a service, I think is true to a certain extent. but the person that's ultimately responsible ought to care on who's behind the scenes. The good thing is all this innovation that's happening, especially in the software, like in the infrastructure and cloud space, it's all user-driven innovation. It's all people that are practitioners that have a problem, and they try to go solve the problem, they create a open, and there's a group

that rallies around it, and, you know, the dominant design forms, and then it take the upstream project and create products. So you mentioned this idea of the difference between a project and a product. How do you evaluate or think about that difference? What tells you something is no longer just a project? It's a fully baked product. You as an IT buyer might want to invest in. Well, I think when a company stands up and puts some service around it, anybody can go get the community version of a piece of software and use it as they see fit. The minute it becomes a product is when a company says we offer a business model around that particular project. It's interesting what happened with the role of IT in a lot of companies. For the longest time, what is our

core competency was the discussion? And we said, well, we're really not great at IT, so we should try to run that at an optimal cost and look for partners that can run it better than we end because we're not in the IT business. And back in that time, open source was mostly a commodity play. That's how Red Hat got put on the map, was we were commoditizing a product. Nowadays, where every company is all of a sudden a technology company and companies are looking to IT as, oh, we're going to use technology to disrupt our competitors. People are in a job like mine have to sort of retool ourselves. Having the capability for one individual team to run a distribution of open source software, the community version, is more tricky than having a

trusted advisor partner with you and do it side by side. And as a buyer, I encourage everybody to inspect pretty heavily. What's behind the scenes? there. And how do I know whose hand to shake when everything goes really well? So let's say I start an open source company. When does Red Hat say, you know what, we're going to grab those bits and put them into our distribution versus we're going to allow that company to exist? I mean, there's always the self-rationalized argument, which I would do if I were Red Hat to say, look, our customers want one stop. And for anything infrastructure, we're going to go offer that because that's what our customers are asking for. Maybe help me and us to understand how you think about that.

First and foremost, you got to look through it through the filter of what is our strategy. Like, what are we going after? Right. There are lots of parts of the enterprise where we have not played historically. And there are our parts where we play and we would try to play well. So we're always looking at the portfolio, right? What's the right mix? What's the value proposition for us? It's interesting just from an entrepreneur's viewpoint. If I start company, A versus B, like, what's the likelihood that, you know, Red Hat is either going to want to partner with me or adopt that technology? Yeah, from my lens, if the company that's founded is the founder of the project is the CEO

and the five people that he worked with on the project, that's the, you know, maybe there's seven or eight employees total, I'm probably going to scratch my head about that in terms of the longevity and just the sustainability of it. It might be good for some experimental stuff I'm doing in my shop, but for production type stuff, you've got to think twice about it. Yeah, for sure. But those companies that are small, I mean, they start out that way, and then they get a tailwind, and then now they're 50 people.

And at that point, as was with the company that I ran, we got to be of a scale where customers actually trusted us and we could go do things. Yeah. As somebody in IT who's kind of evaluating these different projects, maybe the first ones to test things out, as you mentioned. How do you decide which bets are worth making from a technology perspective? What are you looking for?

Every CIO in the planet is trying to do this. You're trying to balance operational excellence and running the business with innovation and driving the business forward. And again, if much of the innovation is coming from the open source community, then a lot of the bets that you're placing for new technologies are rooted in solutions that are born there. So for me, it's like I always try to think about what are we, how are we balancing those two things? things because it's really important. If all you do is focus on keeping the lights on and making sure everything hums, you're going to miss opportunity to drive the business forward. So to me,

it's all about striking a balance. And our team, we spend a lot of time thinking about what are the strategic priorities of the company, how do we want to translate those in IT? Where can we take some calculated risks? Really curious to just hear how that has informed product development within Red Hat and what sort of advice you might have for others in terms of using their own software to advance it. We have a program within Red Hat. It's called Red Hat on Red Hat. And I made it pretty clear from the beginning that that doesn't mean by default we're

just going to choose our products. I mean, they have to work. And so we had to create some bridges and some trust with engineering and try to demonstrate that we could be that customer zero and drink our own champagne. What advice do you have, I guess, for somebody who's in that process of trying to build that feedback loop? What does it take to get trust between kind of IT or your internal customer and engineering to actually get them to listen to that feedback?

You have to prove that what you're really hired to do, which is make sure the company runs, is happening really, really well and garner some respect and some credibility that way. Then you can start to build trust. If all you're focusing on is giving feedback and the servers go down every five minutes, you can't have a problem, right? To me, I've always viewed the ability for us to deploy Red Hat's product and give feedback is sort of like a privilege.

I mean, we have to earn that because if you don't, you're just a noisy distraction. Let's talk a little bit about mergers and acquisitions because I think that's an example where often you're looking to buy innovation or core functionality. How do you then, as an IT department approach,

integrating that in? Every acquisition and coming together of companies or divestiture or whatever, they're all different. I've been through a lot of them. To me, the common denominator in all of them is a deep understanding of the culture of each company because that will determine how close you want to be and how far apart you need to remain with a focus on the original thesis for why you're buying the company in the first place.

In a lot of cases, open source companies, it's about the people. And if you buy a company for the people that are there and you try to integrate things, people don't want integrated, you destroy all the value of why you bought it in the first place. There's a spectrum of M&A, and if you're acquiring a small organization, and it's the few technical people, that's very different than acquiring a much larger company that has a full sales, marketing, kind of whole energy around it. I mean, you guys were just acquired by IBM, right? So there you go, you know, tiny company swallowed by a giant, you know. But there was a lot beyond the technical capabilities.

There's a lot of channel and go-to-market capabilities. And you all are pretty independent from IBM, right? So that's an example of full independence. Yeah, yeah. Because I would imagine the two cultures, when integrated together, might have really hampered the technical and go-to-market capability of Red Hat. And so, therefore, in that case, you leave it alone. In other cases, you would combine things to where, let's say,

in my company, we were acquired, and we leverage the sales organization of the acquiring company, but were standalone from a technical standpoint because it was believed that our product fed into a much larger sales organization would increase the traction as opposed to us doing it alone. From a spreadsheet standpoint, when the two companies meet initially, everything looks wonderful. It's one plus one equals three. everything's accretive, we're going to go, you know, do all these great things. And a lot of times it doesn't quite work out that way. And a lot of it has to do with integration and how you think about the operating framework of the two organizations post-acquisition. And my view is if you take the time

and study that and you get it right, the spreadsheet model that was produced will be proven to be incorrect because you'll beat it by so much. My advice to entrepreneurs, I gave myself this advice, was if you are considering an acquisition, think about the level of autonomy that you are comfortable with once you're inside the new organization. Because let's say I'm the CEO of my company, even if there's five people in my company, I'm the one who's making all the decisions and then you're acquired by a larger organization. In the new company, you might be a director in the engineering company. group with five direct reports. So I would really think about your own level of happiness

inside this big company, am I going to be able to really do what I need to do? That's fascinating. That's not something I've heard talked about a lot because usually people are thinking about the dollar amounts, the valuations, and that's a very human component to it. You know, the dollar, the dollar part, of course, is a factor. The company that's acquiring the small company wants that team to stay. so they may negotiate a deal where you get paid out over three years and you don't get it all up front if you're making a commitment to the buying organization that me and my team we're going to stick around and the day after you get your pay day you leave like I mean that's a credibility issue

and I think it's very important to make sure that if you are committing to stay or let's even say financially you are incented to stay make sure it's a job that you're able to be able to and willing to go and do. Otherwise, stay independent. But don't fool yourself into believing that if it's a miserable environment that you're going into, that you're just going to be happy because you happen to get paid. It's like basic relationship advice. If it's bad now, it's probably going to be bad later. Right. As an entrepreneur, as a CEO, you have an obligation to your team. They're going to trust that you're going to make the right decision, put that team in a reasonably good place in the new organization.

And those are the discussions that I would have with the acquiring organization to make sure that everything aligns beyond just the financial numbers. And it is a negotiation with the acquiring company because if I'm, let's say, an entrepreneur and I have a couple of hundred people and I have a sales organization, the best case for me is that we're left as an independent company. And all we do is get funding from the mother's ship. Now, the acquiring company may say, well, wait a minute, we have this. tremendous go-to-market engine with 3,000 salespeople and marketing and all that.

And we believe that it's better for your sales to actually be incorporated into our sales so we don't have confusion at the customer site. So that's a negotiation. And then whatever you come up with, you want to make sure that it's durable and that everyone is reasonably happy with the outcome. You know, for me, it was all about establishing the guiding principles up front, knowing that there's probably somebody who's done something like this before, and you should go talk to them. If a large company is acquiring a small company, chances are that large company has done many, many, many acquisitions. So there are plenty of people to go talk to inside the company to say, like, hey, how did it go? What would you do differently? And furthermore,

these acquisitions have to be successful. I mean, there are big deals, and like some manager is on the hook to make them work successfully, maybe all the way up to the CEO. And if there are elements that the acquiring company can improve relative to their overall process or org design or whatever, they're happy to go and make those changes. And I think that kind of goes back into a community and how you're treating the communities that you become the custodians of. What advice do you have for somebody who's managing an open source project to be good custodians of the community?

I mean, my advice would be stay focused on the problem you're trying to solve, be a good citizen of the community, build partnerships, and continue to recognize that it's not about you, it's about us. I think that's a great note to end on. So I just want to say, thank you, Mike. Thank you, Peter, for joining. Sure. Thank you.