a16z Podcast - a16z Podcast: Monetizing Open Source (Or, All Enterprise Software)

Episode Date: April 11, 2017

Here’s what we know about open source: Developers are the new buyers. Community matters. And there will never be another Red Hat (i.e., a successful “open core” business model … nor do we necessarily think there should be). Yet open source is real, and it’s here to stay. So how then do companies build a viable business model on top of open source? And not only make money, but become a huge business, like the IBMs, Microsofts, Oracles, and SAPs of the world? The answer, argues James Watters, has more to do with good software strategy and smart enterprise sales/procurement tactics (including design and a service-like experience) than with open source per se — from riding a huge trend or architectural shift, to being less transactional and more an extension of your customer’s team. Watters, who is the SVP of Product at Pivotal (part of VMWare and therefore also Dell-EMC), is a veteran of monetizing open source — from OpenSolaris (at Sun Microsystems) to Springsource (acquired by VMWare) to Pivotal Cloud Foundry — with plenty of failures, and successes, along the way. He shares those lessons learned in this episode of the a16z Podcast with Sonal Chokshi and general partner Martin Casado (who was co-founder and CTO of Nicira, later part of VMWare before joining Andreessen Horowitz). These lessons matter, especially as open source has become more of a requirement — and how large enterprises bet on big new trends.

Hi everyone, welcome to the A6 and Z podcast. I'm Sonal. We've talked quite a bit about open source on the podcast already, from the topics of open versus closed, to managing community and identity, to selling to developers. And a few years ago, partner Peter Levine put out a piece arguing why there'd never be another red hat, which is one of the only open core business models to survive. But given the current and coming wave of companies built on top of open source, the tricky question left to discuss is, how do they make money? And joining us to have that conversation, we have James Waters, who's the SVP of product at Bivital. a cloud platform company that runs software and multiple clouds and they're part of VMware. And then also moderating this podcast, we have general partner Martine Casato, who himself came out of VMware, which had acquired the company he co-founded and was CTO at previously Nysera. And he's the first voice you'll hear. One of the paradoxes in this entire space is there's been a ton of money that's been invested in open source, but almost no examples of successful companies built around it. Silicon Valley had a spidey sense that there was an opportunity there.

Like, nobody pulled it off. And now there's a number of examples of open source companies doing very well. James is one of the few people on the planet that's cracked that, where they've figured out how to monetize and build a big business out of open source. And just to give a sense of how real this is, Pivotal Count Foundry went from zero to $270 million in license, not support. What does that mean in license? In license and software sales.

Oh, so it's not professional services. Because that's a step that has like, that's the thing we talk about all the time in terms of building businesses is that you don't necessarily want to rely on professional services. because it doesn't give you a lot of margin on your business. Exactly. So this is like legitimate software sales. So James, tell us how you went from zero to 270 and million we're talking on seconds. How did you do it? Yeah, and I think it's fair to describe kind of my maturation and my thinking about this through failures, too.

I worked on Open Solaris at Sun. And then for a while at VMware, we were looking at how do you monetize SpringSource in and of itself. SpringSource is like the most popular Java programming framework in the world. bought by VMware for pretty famous money over $400 million as an open source project. I had worked on that, you know, both of those projects and had gotten my bumps and bruises along the way. And so I had some very particular opinions coming into doing the third round of PCF, Pivotal Cloud Foundry. I think there's kind of two dimensions.

One is the basics, which is if you look at IBM and Oracle, Microsoft, SAP, etc. What they get right in is a very basic thing is they understand how to cater to enterprises. Yeah. And I think the number one temptation that most open source companies fall into, is the first thing they do is they cater to their users. And by users, you mean the developers? The developers that, you know, fork it on GitHub, start on GitHub. And the misassociation as a first thing between the people that use it

and then the people they need to cater to selling to is kind of what you might call the first false horizon of open source monetization. Interesting. What I mean by cater to is like, I think this is the number one thing that I see open source companies maybe get wrong is those are the people that show up and talk to you. Those are the people that you're interacting with. When you're creating an open source community, you have to first get these unpaid users excited. But ultimately, IBM and Oracle are not out there mining their mailing

lists of end users to go do deals. Yeah. How do you sort of straddle this because theoretically you should be able to do both, but isn't sort of the mantra, mantra, I should say it the Indian way, of open source that you have to take care of your open source community and then also figure out how to become a business? Like, how does a company that's trying to become a real big company straddle that? It's super important, right? I'm not saying that that's not. What I'm saying is that your commercial strategy and your community strategy are not the same thing. That's a great point. It's tempting when you put so much heart and soul effort into building that proof of validation

around a community first to say, oh, well, then I'll go upsell them. And I remember meeting MongoDB when they were early in their rise. And they were selling a $4,000 support contract to thousands of users with a lot of expense. And when we built PCF, I was like, I don't think that's the right way for us to go be big. Just because your open source doesn't mean you only sell to your open source users. So what did you do? And getting across this first horizon. The next thing you have to get right is you've got to get a major trend that affects enterprise buyers.

So if you go back to enterprises being the source of the money, you know, Oracle didn't magically just exist one day. They caught the relational database market at the right time and they built a franchise. And that relational database market really changed how enterprises were building applications, what they could do on applications. And in the same way, we've tried to catch the microservices trend. as the major enterprise change that's happening. That's the kind of change then you need on your, you know, commercial strategy to generate CIO interest in enterprise purchases. It can't just be a tool that someone's potentially using lower levels.

There's been a long time this thought that open source was primarily a commoditizing force. There's an existing market, say Unix. It's an existing market with an existing buyer. Then you create an open source version, which is differentiated by being open and open source, and then you go commoditizing that existing market. And you're saying something quite a bit. different. You're actually saying that you can enter a new market using a shift and sell into that. So I guess two questions. One, do you believe in the commoditization? Is that still a

business plan? And then the second one is like, is there any difference in open source to identifying these shifts? Or is it just like if you're doing a close source product? Let's look at history a little bit. I think Zen and OpenStack both felt like they could go commoditize VMware, right? They both said, we're going to go commoditize VMware. The last time I checked, Oracle and IBM did not get to be the size they are by having commoditized a previous generation of suppliers. So if you just look at the record, and this is what I call like the false horizon of open source strategy, you might be tempted that your only play is to be a commoditization play. But history tells us that the largest software companies in the world that

get into the hundreds of billion evaluation, that's not what they did. They caught mega trends. They built something new. They didn't just commoditize something old. They did. And I know that that sounds like obvious. I'm glad you're pushing on it. I've learned over the years that open source is now both a necessary part of almost any major software company strategy because it's a buying criteria that enterprises have for major new initiatives. But that I think that open source got a little bit of a false start by only being low cost commoditization as a business model. It's actually, from my conversations, it's almost somewhat of a contrarian view because traditionally you're like open source projects chase after basically the sales dollars that have matured to market, like my see. SQL, you know, like Android, like Linux, like J-Boss, every one of these you can point to a close source incumbent that they were chasing after. So it's nice to hear that you believe

that open source is not somehow relegated to this commoditization, because I agree with you, that basically limits the upside you're going to get. It does because it limits your business model. It doesn't let you invest. We have a $100 million your R&D budget. When you're chasing a new big strategic trend and you're getting the kind of checks that we are, trust we are, you can build a big R&D team. If you're chasing commoditization... Well, I mean, you are trapped to

a fraction of the market you're chasing after. By definition, right? Like, if it wasn't a fraction of it, you wouldn't be commoditizing it. And it's very unlikely you're going to get it 100%. And so you're necessarily have a ceiling over you. It sounds to me that your recommendation does a lot like close source software sale. However, is it

more than just kind of software sales? Or is it just that, like, the industry is ready for open source now when it wasn't before? Like, what has happened in the last two years to make this viable or is there more to the puzzle that you haven't talked about? So the basics are strategy and segments. If your strategy and segment looks wildly different than every other big software company that's existed before, that's probably a pause. And then the second thing is I think that cloud has started to affect open source. And we've taken a model of continuous delivery of our software inclusive of cloud API. We don't do what I call shipping you the tarball on the support contract and say good luck.

we actually automate the continuous deployment and update of our software. And so we have an additional point of leverage other than just support, which is that if anything doesn't work in that large-scale update of thousands of nodes, you just blame us and call us. And that's a different vector. That's almost like a cloud vector in terms of value add of software packaging. That's exactly right. We hear this all the time, which is more and more the customer wants to consume things as a service.

And this is often conflated with whether it's the, deployed off-prem or on-prem. Like, to me, this is a total conflation, right? Like, whether or not the service does not mean it's necessarily deployed off-prem, right? These are two things. So one decision, off-prem or on-prem. Like, that's actually a decision often, like, bound by regulatory compliance and security, etc. There's an entirely different decision is my consumption model as a service.

That could be, I pay for it as a service, but it also could be somebody else basically manages it, does the update, manages the life cycle, I don't deal with the tar balls. That's very much in line with what we're seeing across the industry. too. And what makes this discussion particularly relevant to open source is that it seems that once you're talking about something as a service, questions around open source kind of diminish because they're not actually dealing with the code itself. They're dealing with the service. Big success stories sometimes have contrarian bets in them. And I would distill our two contrarian bets to we did not go for the commoditization play. We went for the sea change and app design play.

And then we also tried as best to deliver a service-like experience, even with software. Are there any challenges, though, in sort of bringing a polish to open-source work? Because when I think of traditional software companies, they have baked in design for user, like really client-facing versus developer-facing. So how do you sort of navigate that part of that is building a real business on top of open-source, if you don't have that experience natively? One of the decisions we made is we made our UI is closed-source.

So everything about the infrastructure of the platform is completely open source. And we chose to make the UI and that last mile of experience built off the APIs, close source. Okay. So I do think there is some room to differentiate there. And, you know, when you go to monetize, you're going to need some small checkboxes. I've learned a lot, you know, growing this about the importance of packaging for procurement. And one of the things I've observed is that procurement is exceptionally good at pricing a certain kind of thing, which is labor per hour. So I've seen very large software contract orders

and procurement will actually pick on the labor per hour because that has a near comparable. And so when you start to think about procurement's looking to compare things to exact replicas to price it, having a little bit of closed source UI or things that are maybe even immaterial to the product but are still there to say,

oh, well, this is different, is somewhat important. Interesting. That's really interesting. And thinking about dynamics of navigating the politics of procurement are important. What are some of the other dynamics of navigating the policy of procurement,

your lessons learn that you can share with us here. I mean, you guys are asking for the goods now. Yeah, we are. We love. Give it to us for free. Share it with our listeners. I think that I'd say is that generally in an enterprise, when you get to procurement,

somebody wants you to win. Yeah. And you're actually then in a political process to get through the last mile. Like, they're kind of like the guardians there. You mean the internal champion? The internal champion wants you to win. Like if you're in procurement,

they want you to win and they want to work with you. And this is why one of my other rules about open source monetization is try to avoid dog piles. So a dog pile is a little bit like everyone's doing X project. We've got a distro of X project. Think about that dynamics when you go into procurement then and 20 people show up with an offer for X project. Like no matter how much your champion loves you,

the procurement officer is going to have 10 comparables to compare you against. If you look at MongoDB, for instance, one of the things that protected them was that they are the only supplier of Mongo. So while they might not have had the high-end strategy right when they started, they at least were the sole supplier. So they could still somewhat dictate prices. If you look at OpenStack distros, I don't know that anyone made it out a lot of that gunfight. This is such an important point. And I think it's actually worth restating, which is if you've originated a project and you're bringing that to market, you should retain the ability to be the sole supplier, if only to set pricing and brand awareness in the market.

it. Companies live or die by this type of thing. Another thing I would like to hear this is true for you, having spent a lot of time dealing with procurement, more than anything else dictates the life of enterprise sales. Before going into procurement, I always expect procurement to need their pound of flesh. Like this is how these guys are comped often. It's like, okay, you know, whatever the discounting is. And so we would expect that going to procurement, you go a bit of a kabuki show. And then, you know, you end up with some pricing.

And that pricing is actually for the vertical has been set in the market somehow. So it's pretty well understood for forecasting by the business, it's pretty understood by the customer, and it's kind of motions you have to go through. Do you find an open source that that discussion is different because you are open source? Do you have more pricing pressure because it's open source? Do you have more of a push-word service components?

Or can I think about it the same way I think about close source? I think you can think about it the same way as close source. If your model is you've sold someone on a big new trend, you've helped train their organization to get there, And then you're working on a fresh demand forecast of the transaction together. If you're coming in and upselling support only and they're already installed and all you're upselling is a support model, that's going to be a lot more difficult because they already have it running.

They already have it working at their scale. And all they want is essentially professional services by phone. What happens when a big company comes in and competes with you as a smaller growing open source-based company? This is something that open source companies have to navigate, which is that sometimes large larger companies will adopt the same software by name if you're not careful about how you position yourself. What do you mean? Like they can literally just take your name even though it's very popular for large companies, say IBM or somebody else to say, we support X.

Oh, I see what you mean. Okay, got it. Larry Ellison famously did it with Larry Lennox, who tried to do it to Red Hat. They often don't have that much capability behind it, but they can at least push a little go-to-market on it. But wouldn't your internal champion in the procurement office be able to tell the difference? Like, why would they even pick something else when they can get your product, which is what they want? This is why having a unique market position is important, regardless of your open source or not, because I've seen cases where very large orders were suddenly stopped because another large company just quoted something that sounded similar for the same amount.

Now, that can happen open or closed, but if you're in an open source dog pile, as I mentioned, more of caution, it's especially rampant. That can actually drive your entire upside of ever being a half billion dollar a year software company. Like, your probabilities go down really hard. So how do you get out of it? The key is keeping a unique offer in the market, right? You don't want to be yet another distro of, you know, a certain famous technology that provides support. I think you want to have a fully packaged, differentiated approach.

Okay, so here's probably the most basic question in this space. If you have an open source project, it's probably available online. So if you're walking to somebody and you're about to sign a $10 million ELA for license, what's stopping them from just downloading and running it themselves? Yes. I have that same question. I'm glad you asked that. I want to know the answer to that too, James. You know, some of the origin of this discussion was we were speaking on Twitter around this

$100,000 or $200,000 contract value and even some sub that as sort of a value of death. I think if you go back to why the big software company is successful, they're an extended part of those companies' teams. So I don't really like the $100,000 a year relationship because it's very transactional. When you're part of a big change like my microservices in the enterprise, they're going to want advisory. They're going to want you there. They're going to want a team of two to three people that just live there. A key thing is that when the $10 million transaction comes, they're as much voting with, you know, they want you to be part of their extended team, part of their strategy, part of a relationship with you. Yeah.

Because you have an expertise that's been hard won that they do not have. So I've spent, you know, quite a while doing enterprise sales. And I've got this views and this caused this conversation that you and I had had on Twitter, which I had claimed that, you know, in direct enterprise software sales, it seems to be this value of death between like, say, 30K and 150k. If you're 20K or below, you know, you can call somebody up and they can pay for it. And let's say if you're 200k and above, then you have a hopes of supporting a direct sales force and still have good margins.

And then in between that, you've got this value of death where you can't really support a direct sale because you can't pay the people, but like, you know, like if you're trying to do something new and innovative, you don't have account control and it becomes very transactional. And like, so do the dynamics of that change with open source sales? I think what's happened is that open sources become how large enterprises want to bet on big new trends. And then that opens the capability for the first time of open source companies, I'll use the word being high end, meaning that IBM and Oracle are parking a bunch of good platform

architects, as we call them, technical architects at the account that explain the new things to that account, if you want to get a $10 million relationship going, you've got to become that extended part of their team. That is why I jumped in. For our original Twitter discussion around the $100,000 year deal, and I was like, hey, actually, I think 100 is too low. Like, I would try to get to 400 to 1.5. And the critical thing that happens at that is not that you extract more money. It's actually that you can be a better advisor. Like, you can actually put talent on the ground. And you'll find that these large enterprises, during times of big change, really value that talent on the ground. Interesting. So this is a, this is a, this is a, a nuance and new way of looking at

that discussion. So how much does your ACV have to be to support a sales force? I'd say it has to be at least 150, 200K. You would say that it actually should be higher than that because the goal isn't just the margins on a direct sales force. The goal is really strategic account control. And to get that, you need a deeper engagement. Yeah, and I think so many open source companies have died because they transacted around the edges with like director level or technician level for support. And they never got to the CTO, the CIO and true strategic account control like the big players had. So I'd love to get back to this question of like, why now? Like I'm just so curious, which is like, is it like, have you figured out something that nobody else has?

Or is it that the enterprise is now realized that they need to pay for this? software, or is it something else going on? Like, like, why are we starting to see the elastic searches? Why are we starting to see the mesosphere? Why are we starting to see these companies be successful? Well, if you look at the clock cycle of how often big new software companies get built, it's not every day. Enterprise architectures only change so often, right? Like, if you were to try to sell a middleware offer in 2008, I don't think you could have raised money. You would have had a really hard time because none of the design patterns were changing. I think what's happening now is that cloud is disrupting a lot of people's approach to software infrastructure, to how they

build applications. And so this crop of open source companies is getting a chance to be the leader of a new thought versus purely being a commoditization play. So you're saying that it's not inherent in open source. It's actually inherent in the trend that's going on. And open source is just becoming basically a requirement because of customer expectations and community. But I have to push back on this one. Isn't that inherent in open source? Because that's It has to do with the nature of a community, the speed of development, the fact that you don't have to necessarily go through a waterfall type of development process. I mean, isn't there something here that's inherent to open source by definition? Fixing problems is fixing problems,

whether you do it in open source or in source source. And the reason that we're seeing this rise in open source companies is not endemic to open source. It's the fact that we're seeing actually a transformation around developers and their aesthetic and technology. I totally buy all of that. And then the question is, well, where does open source come into the place? with it. It seems like there are intrinsic benefits to it and there's a level of expectations from the customer. Yeah. And I think that the commodifying open source companies did a really good job of normalizing open source as something that people did and even created an expectation that that's the right way of going. And then this wave of what you might

call like the microservices generation or the cloud generation open source companies are actually catching enterprises with a new need. And a new, you might call it hundreds of billions of need. And suddenly IBM and Oracle's earnings are missing every time. And suddenly these new companies are getting green shoots. Okay. That's fair. I just wanted to make sure there wasn't some inherent experimentation baked into an open source based project that then leads to this more innovative type of... You'll keep getting me to talk open source strategy. I'll keep talking software strategy. That's great. I love it. That's great. That's what we need to hear. Sometimes people say, oh, well, why is enterprise software so expensive? It's expensive because, you know, the trust

model of enterprise buyers is you're really going to take care of them, advise them, ensure outcomes. You're not just providing support. So what you're really fighting for is the chance to be one of those new trusted architectural advisors, I believe. Red Hat lived on the X-80s. This is the Red Hat kind of got lucky and find a commoditizing change, which was Unix to Lennox. That's an rare event to have a major chip system replatforming sea change. So let's talk about Red Hat, because Red Hat seems to not follow. There's a big transformation. Open source is a great way to do that because it gives you an edge with community, all the thing, all the bromides that we normally talk about. So you take advantage of the transformation,

you become a strategic advisor, et cetera. But if you look in the back, that's kind of like the one success case doesn't really follow that. For all of the time it's been in market, Red Hat is still a $2 billion your software company, right? If you compare it to what IBM or Oracle or SAP or Microsoft or any of the megas, they still haven't caught that size of a trend, even though their prices, frankly, are similar to Microsoft's now, like $2,500 in OS. So it's not that they're just down market, is they just didn't catch a trend big enough to become a company that big. Yeah. I see. Like, I don't think they, you know, in the same way that the mainframe captured all of the world's transactional processing or Oracle captured all relational database apps and

enterprises. I mean, you've described this now a few times on this podcast, catching. this trend, this wave, this need. That's just product market fit. That's that there's a real market need for this. Yeah, I think my thesis is that just saying we're an open source company can distract you from software strategy. Yeah, exactly. That's great. So what did Open Solaris get wrong? I mean, like, you've seen this from many angles. Oh, there's a pained look on his face. I'm not sure if I've kicked a, kick the wound. You know, it was a great learning experience for me because I think Jonathan Schwartz had a fairly early and simplistic open source strategy.

And he was one of the first CEOs of a mega enterprise company to do this. So I watched this firsthand. And he was like, we're an open source company. The problem was that Sun was still on the wrong side of all the trends. Like it was actually late to X86. It was late to everything that was happening

around WebScale. And so open source actually only heard us in a sense because, you know, working on monetizing Open Solaris, one day Jonathan said it's all free, it's no longer licensed, go sell support contracts, everyone will buy support. Well, what happened was that overnight, like hundreds of millions of dollars of revenue evaporated, and then it was a tactical challenge

to go get people to sign up for it again. Yep. We didn't have some strategic initiative to go talk to them about. Which goes right to building a strong, good software company to your original thesis. So we worked on that. And then the next thing I saw was within the spring group,

there was something called TC Server, which is just cheaper middleware. And it only got to, say, tens of millions of dollars in sales and an average selling price of, say, 80,000, somewhere in that range. And it never caught a strategic new design point either. So when we had PCF, I really said, hey, this microservices refactory is actually once in a generation change. We could take a different tact.

What I really like about your view on this conversation is you're basically saying, open source or not open source, you have to build, you know, a solution that solves a real problem, take advantage of a trend. It's like a traditional, it's like a traditional software company and software sales.

And then, you know, open source provides, you know, uplift and, et cetera. And often open source has been viewed very differently. Like it's got something magic that will save you. And so what you would see is you see these incumbents that are desperate. And like in an act of desperation, this swan song is to release something open source

because they think that somehow that's going to magically save them. Community development is really important, but if you just develop a little community and it doesn't change a CIO, a CTO, anyone that's writing as serious as checks priorities, like by definition, you didn't build a software company that had an opportunity to be the big new strategic advisor. That's a critical thing that I like about your view and all this, it seems like it's a very kind of planned, top-down view, which often discussions around open source to me are very organic, which is, you know, you get a community and that community will grow. and like this is kind of very kind of like organic progressive thing.

Well, this goes to my question about product vision, like having someone to direct it. No, exactly. Well, what I'm hearing is the next Steve Jobs will be the Steve Jobs of an open source company. Because it's a great CEO, great product guy, great business. It doesn't have to be open source or a close source. It's to your point, it's building a great software company. It's exactly right, which is like, listen, there's an industry trend. You're going to build real value added in that trend, and you're going to go from the top down,

the direct sales force. And this is really about kind of top down, like, strategy and planning and not just kind of progressive community. The great thing has happened is because buying open source has become a normative behavior. Yeah, exactly. Which means that you don't have to be shy about doing something audacious and asking for money. Is that even further? Do you think open sources become a requirement? Or is becoming a requirement? It's close to a requirement, I think, for major new bets. Like if you look at our biggest buyers, they don't want to get into what Oracle is doing to them right now. Like every year they're using less Oracle and every year they're paying as much. that's a very negative feedback loop.

Wait, to explain why? ELA structuring, enterprise license agreements. And what is that? Like, just kind of talk us through it. So what buyers are trying to escape from, and one reason they want open source as a protective measure, even if they don't use it,

is the right to keep using their software without paying more and more for it every year. Yeah. Companies like Oracle have been out there charging more and more for the same usage over the last few years. So they basically trap you into that and say, well, we can increase your unit costs,

even if you're decreasing your unit consumption. Yep, that's great. get back to this original question, which is a lot of the constituent that listens to this podcast or entrepreneurs or aspiring entrepreneurs or existing entrepreneurs. So let's say one of these entrepreneurs wants to create a company, Acme, Inc. And they have... Acme Inc. Great name naming there. Acme Inc. because I'm creative. So they're creating Acme Inc. They've got a software project they think is going to change the world. And they have a decision to do open source or close source. Is there a difference or is it the exact same thing? I think we got incredible lift off of open

source. For instance, IBM showed up and standardized on what we were doing, HP, SAP, other people. We got huge lift off of open source. That doesn't mean that you have to accept the usual low-end tarball and support contract business model. So I would probably not start a closed-source software company today unless I had a very niche novel idea that I felt no one else would try to do. Because quickly, there'll be an open-source alternative to what you're trying to do if you do not open source it. Okay, last question then. You started off describing how you've been through like two sort of failures before you kind of struck the right model for building a great software company, not necessarily a great open source company. What advice would you give to entrepreneurs

today who are trying to do the same thing or the next thing? I think the tradeoff that you're going to make as an entrepreneur is to come out into an existing trend with a lot of people having already validated that. That was easy to get into that trend. It wasn't a big risk. So I think the challenge for entrepreneurs is trading off like a vision of change that will happen over the next couple years that you're going to grow into versus just joining an existing parade around a standard open source community. Yeah. And I would add to that things that you could tangentially apply to previous architectures don't necessarily carry forward, right? I mean like often we're like, oh, this worked for VMs, therefore it works for containers. And so I do think that you really need to

be piped in the nervous system of the evolution of the market and you really need to be bold about kind of going after new solutions that are part of the evolving landscape. I mean, it's the first principles way of thinking. Exactly. It's sort of like saying don't derive it from what happened before. That's right.

Think about it from scratch. Martin said one of the most brilliant things, which I was sitting at home listening to the podcast cheering on, which he said there's so much metadata in a microservice now that you could change the way you think about networks. That is these fundamental shifts. If you catch something like that, then you have a game changer.

That's wonderful. Thank you for joining the A6 and Z podcast, James. That was great. Thank you.