The a16z Show - a16z Podcast: Selling to Developers & Open Source Business Models

Starting point is 00:00:00 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, everyone. Welcome to the A6NZ podcast. I'm Sonal, and I'm here today with two general partners who are focused on all things, infrastructure and enterprise. And we have our newest general partner, Martin Casado. Welcome again. Thank you. And we have Peter Levine, who has probably pretty much every company in our portfolio that covers the space in his, he's on the board of those companies. I'm an old general.

Starting point is 00:00:40 I was trying to avoid saying that. Today we're going to talk about one of the themes that's become really interesting to us is this focus on developers and how that changes everything, from how you sell to developers, to how you build a business that markets to developers to just every aspect of this. I think one of the most notable transformations over the past five. years has been the pauper to prints of the developer as a buying center within a company. I used to be a developer, and when I was a developer, I had no budget, and I couldn't buy a pencil. Like when pencils were popular, you know, but like, I couldn't buy anything. Basically, whatever Central IT had ordered, that's what showed up on my desk. And I wrote code and I compiled it, and out popped the program, but I could not buy any. I wouldn't, didn't even know how to

Starting point is 00:01:29 buy anything. Other departments in company, sales and marketing and IT and GNA all had buying centers and budgets to go buy things. Developers didn't have anything until about five years ago. That's when GitHub got started and kind of this whole collaborative sort of, you know, let's bring developers together as a community. And as software infiltrates every part of our economy, it's not just tech companies with programmers. It's every company with programmers. It's kind of the tail wagging the dog that these are the lead innovators and they're the lead buyers in companies. And what we see are many of our startup companies now deliberately selling to developers as the first wedge point into an organization. So 30 plus million developers and they all very much have opinions and

Starting point is 00:02:26 buying potential and that has now become very well noticed among among startup companies selling into enterprises. Conviss me a little harder that this isn't just a Silicon Valley thing, that this is just the perspective that we who sit in the heart of tech are biased towards this view because that happens to be the worldview. We have, are big companies seeing this sort of transformation play out in their companies as well? Every company has software development in the,

Starting point is 00:02:56 inside, whether you're a tech company or not. That's fact. Whether you are GE or a financial institution or the government or a retail organization or an e-commerce organization. So this is not a Silicon Valley phenomena. This is a worldwide phenomena where there are developers in every organization building software. They're the ones building the most innovative products in those organizations to move any industry into a next generation company. So we are seeing across the board the proliferation and the opinion leadership of the development organization as, again, a key buying influence in every large organization. So then how then do they get the budget to be able to buy those pencils or the equivalent today? Because, I mean, them being the center of power is clear. But now does the

Starting point is 00:03:52 company, how did they get that budget? The thing that's so powerful about the developer is they line to the line of business, right? So generally they align to the line of business, which is a profit center. So if I'm a developer for, you know, a piece of a car, whatever, that, you know, selling the car is what makes the company business, where IT is often viewed as a cost center. So it's just in a very natural business dynamics, you see budget shifting towards the profit center and trying to contract on the cost center. Behavior always follows business. So the business will very naturally align, you know, behind the cost center. The other part of that is the ease by which developers can consume infrastructure,

Starting point is 00:04:30 programming tools, open source is so much easier now than five years ago. A while back, the reason why we had IT departments is because we had on-prem software. You had a first, in order for anybody to even use this stuff, you had to set up a whole server lab, put the on-prem software on those servers, do a business. beta trial internally. Now, it's all try before you buy. Let me just give you an anecdote from the infrastructure side to kind of demonstrate how pervasive this is. From an infrastructure perspective, it's now becoming something that programmers programmed to. It's becoming an abstraction to programmers. I think, for example, the container's phenomenon is infrastructure being consumed by developers.

Starting point is 00:05:11 The container is basically a piece of infrastructure abstraction that programmers can use so they have app portability. Containers can run on bare metal. They can run on VMs, but from the perspective of a developer, it's a piece of infrastructure that if they build it to it, then they can run it in Amazon or locally or anywhere else. It just makes app portability really easy to do. Now it's something that developers write to. So now there's somehow a bleeding between developers and what's typically been in IT budgets. There's no resistance anymore to really trying and embracing the best tools. And once the developers in an organization have coalesced around this set of great tools, it becomes a foregone conclusion that the

Starting point is 00:05:49 The company ought to step up and go purchase those particular tools and services. So it really has gotten much easier for the individual developer and teams of developers to embrace and incorporate new technology into their workflow as opposed to the past, where it was literally handed down to the developer. So that also sounds like it would make it a lot harder to sell to developers, because then you have developers all with their different pet. I mean, yes, there's a period before they coalesce around a popular single one or two tools where they're just trying out a bunch of different stuff. And at least before you had a

Starting point is 00:06:23 direct arc to go to central IT department and say, I'm going to sell you this and that was that. So how then do you now sell to developers? You know, anytime users have more choice and more flexibility, it benefits everyone. And there was a time where IT would go make a decision. And many of us have heard or have used the word shelfware many times where IT would buy something and no one would use this stuff because it was some slick sales guy who sold to some golfing partner who happened to be running the IT department and that's how the that's how the software got deployed and then it got rolled out and no one would use it. Here we have the democratization of applications of developer tools through open source through SaaS that I believe really moves the needle in terms of innovation

Starting point is 00:07:12 and the best products are the ones that win. Now that doesn't mean that that's the end of the the sales cycle, that's the start. Really, the whole indoctrination of open source and SaaS as a starting point is a marketing vehicle to build a pipeline for an organization. And then in order for that to be sold into the, it's sort of the upside down approach. You start from the bottom and then you sell to the top. In the old days, it was sell to the top and then proliferate down. Here, the real users start with it. And then there are typically enterprise. wide licenses and all of that. So you use the open source SaaS tools and services as a marketing and pipeline development and also a way to influence innovation in your company and then layer

Starting point is 00:08:01 up an inside sales or sales organization that then can sell value into that company to expand the footprint. That's what we see happening. You can't underscore this point enough, which is the developers are influencers. The developers have control and a large lateral voice on budget. But in my experience, they aren't explicitly the buying center. The buying center is still, it could be a dev manager, it could be a VP of engineering. It also is very often still IT or someone higher in the organization. And so that means that you have to be very good at two motions, right?

Starting point is 00:08:34 You know, actually appealing to the developer and still having an enterprise-focused Salesforce, which, again, this is not common that you see both of these in the same entity. And the most successful companies who are going to crack the code on this will do both these excellently. You have to do both really well. And just to say that we're going to have a free offering that's going to virally penetrate the enterprise, I think is a false hope. It doesn't happen that way. There is a point every company has to sell higher into the organization. Why is that, though? I mean, I still don't quite buy it because if something is taking off popular, like by sheer popularity, why do you need to, why do you need to shore that company

Starting point is 00:09:15 yet. Right now, often why you have to sell higher in the organization is because the technology is being sold cut across silos. For example, when you look at cloud as a general thing, it touches many traditional aspects, compute, networking, storage, and security. So you either have to go and get every one of those decision makers on board or you just go to someone that has all of them under them and sell to that point, which is why, you know, existing companies with C-level, CIO-level relationships are successful at those higher-level. sales. And like when you see companies like startups, for example, move into infrastructure, you want them to sell higher into the organization so they don't have to fight four different

Starting point is 00:09:53 battles. Very similar to my answer, but I'll start from the bottom. So let's say we have a particular silo in an organization that has organically adopted a tool, a developer tool set. And that's in one organization. Here's why you need a sales organization. Let's say the other silos haven't quite adopted that particular tool set. And let's for a minute assume that those other silos will ascribe value to those services in slightly different ways than the original silo. What a salesperson can do is highlight the value of a software product as different from maybe when one group uses it, they get a value, but they may not know, even with

Starting point is 00:10:43 that silo, they may not know that there are 10 other features. Did you know that if you did this, you now have collaboration with a remote office. And you might never know that. And so within another silo, it might be, did you know that this product has these features and it can connect to this? And what a sales organization is able to do is to promote maximum value for a product where is not self-evident through the use of that particular product in and of itself. And that's why you need a sales organization on top of this what I'll call the freemium model. I totally agree. And from a predictable business driver standpoint, organic growth is very difficult to control. And if you're building a business, organic growth is naturally fragmented. You want to bootstrap, drive through

Starting point is 00:11:30 kind of organic growth, but then you need a real discipline enterprise engagement point to turn that into a predictable, monetizable business. And this includes things like, for example, using a beachhead within the organization and then driving it throughout through consistent messaging. The enterprise sales force is something that will drive any of these companies into being a large company. So certainly my personal quandaries around this is it's very obvious to me that open source is becoming more important on the buying cycle because, I mean, A, it's a way to get access to a lot of developers, but also you get credibility with those developers.

Starting point is 00:12:05 But at the same time, it raises all of these questions in the company. How do you market to operators like IT buyers? You know, like a lot of IT buyers, they like certifications, like the CCI is a classic one. I mean, a very classic way of marketing to, you know, operators or IT buyers is you create classrooms, you put them in and you train them on specific types of products. And that's not how developers like to buy it all. Developers don't like to take classes about other people's products. They like to understand everything.

Starting point is 00:12:33 They like to be engaged. And that's why I've always kind of maintained that open source is a phenomenal marketing tool to get developers engaged. But then as a big. business, now you have another question, which is okay, if you have open source out there to get the intention of developers, what does that mean to your business model and your ability to monetize? What's a viable business model? You know, there are a number of models we see out there. One of them is you give everything away open source, but then you end up becoming, you know, basically a service

Starting point is 00:12:55 company. Or you could do open source and then come up with a close source product behind it, but this open core model hasn't shown to be a lot of success yet. Or maybe, you know, there's some open source and there's a service model on the back end. So now there's all these open questions on what's the delivery model, how much is open source, what role does it put? play. How do you do pricing and packaging and so forth? Well, let's answer those questions. Well, I believe that the most successful open source companies not only will innovate on technology, but they're going to innovate on their business model. The problem has been about how you really make money as compared to the proprietary counterpart has been a bit of an enigma, right? Like,

Starting point is 00:13:33 sometimes it might work here and not there and every, and the original sort of thinking was, well, we'll just go copy the Red Hat model. Which was? You give away all the software for free and you charge for support and maintenance. And that model has worked, in my opinion, exactly one time. That's worked for Red Hat and not so great for everyone else. And that's because Red Hat started at a time where open source wasn't even known. They had a lot of time to go build out their scale and capacity to do the two things that they do incredibly well,

Starting point is 00:14:07 which is support and service and updating products online. And for startups to come in and reach that scale is very difficult to go and do. And then, of course, it's open source, and Red Hat can grab the bits just like anyone else, and it becomes a bit of a free-for-all. I am very skeptical that we are going to see franchise businesses, that is a large as proprietary companies being built on the Red Hat model, And I think moving to models like software open source as a service. So if I run open source as a service offering in the cloud, you can monetize it any way you want.

Starting point is 00:14:50 There is no differentiation between free and paid. You just, the customer pays for the service. And so I am very bullish on companies that use open source and stand up that open source, whether it's part proprietary or part open, but standing those product. up as a service completely eliminates this disaggregation of the pricing model that occurs with free and support. I think one more level of nuance to add, which I find often gets lost, is that if you look at these examples of quote-unquote successful open source companies, in almost every case,

Starting point is 00:15:30 they were going after and cannibalizing an existing market, which is way more different. than actually doing new innovation, right? Creating something, a new market. And people miss this. Like, they look at open source and like, oh, this is like Red Hat was massively innovative. And like the reality is it's much easier to say, listen, you've got Unix, you pay a lot of money for it. I've got Linux, which isn't as good, but it's a lot cheaper. And, you know, you can develop it.

Starting point is 00:15:55 And so, I mean, when I look at MySQL, I think, okay, it's going after an existing very mature database market. If I look at Android, even though that wasn't a standalone independent company, you know, Palm and Blackberry and iPhone. created this massive market. And so open source, not always, but often is something that enters these existing markets and is a commoditizing force. And so that almost already limits what you can do from a company perspective. And so, like, when you're viewing open source and what it means, I think you have to be very careful about and very clear about how are you going to monetize what the impact is in the business

Starting point is 00:16:26 and what type of market you're entering. So I think another way to monetize is let's assume that open source proliferates and is out there, there's a very, to me, there's an interesting trend where companies ought to be moving up the stack to where you build on open source and you build, whether it's proprietary or open, build a great product that leverages the open source base. So you're not necessarily in the open source business, but you're leveraging the proliferation of open source using standardized APIs and building data and analytics products or applications that now, sit higher up in the stack. And I believe that that's an excellent new business model based on

Starting point is 00:17:10 what I'll call the commoditization of some of the infrastructure components with new products and services. And then as a startup, you can put all your wood behind a single arrow. It's very complicated as a startup to do all things, i.e. manage an open source project and build all these applications on top. So I think that the sort of separation point on these things will very likely unlock some really interesting franchise opportunities. Are you guys seeing any interesting examples out there of people doing really interesting examples of this or other monetization with open source? Yeah, one of the companies that were invested in a Remo, formerly a daytow, builds machine learning and big predictive big data applications that sit on top.

Starting point is 00:17:58 top of Spark and Hadoop installations. They don't support the Spark and Hadoop. They let that, they leverage that once it's out there. And so all of their development efforts are for these higher level applications. In the past, open source hadn't been so prolific. And now that it's more widespread, it's easier to go leverage that base and build things on top of it because there's actually a base there. So then clearly there's areas where startups can focus in this space. But what are the pitfalls or obstacles that they should think about as they try to build these businesses and how can they overcome them?

Starting point is 00:18:37 So the first one is if you're doing open source, really understand the impact of the value of your ultimate product. If basically that becomes your product, know that you're turning into a services company. And if you're doing an open core model, understand that pretty much nobody's pulled that off or not with the type of success you'd want. To be clear, it's not something that it's bad to be an. a services company, but there's not that much profitability in a services company. It's a different structure of companies. So just understand the impact to your pricing,

Starting point is 00:19:03 especially like your repeatable revenue, like license revenue on open source. The second one, and I peter wrote this, as you move up the stack, which is important, realize that it's a more fragmented market. And so you have to come up with some way of dealing with that fragmentation. I mean, the classic example is the languages. The problem with languages is there's so many of them, and it's so fragmented and bifurcated. So as you move up the stack, you tend to have this problem. And what we said is one thing that you can do to rein that in is actually have a direct sales force that actually shows the value across. And then the third one is open source is hard enough to sell on its own sometimes because you're talking about less features sometimes or whatever.

Starting point is 00:19:38 So know if you're entering a mature existing market and your value is basically a commoditization or understand if it's really innovation. I mean, market category creation is hard enough by itself. So if you have to do, you know, create a market category and explain kind of some new model of something else. maybe too many things. So I think like understanding whether you're trying to do market category creation or whether you're trying to enter an existing market will impact the way that you bring these technologies out. And then maybe a couple of others just that we, you know, highlighted developers want to use, not buy. So, you know, use before selling to and it will naturally take care of itself. Number two is organic virality works to a certain point, but in order to be a successful

Starting point is 00:20:21 organization in this new ecosystem, the notion of viral spread plus an enterprise sales organization, I think is the winning formula. So then to operationalize a little bit more, what does that mean for hiring and the order you have to build up your workforce for a particular startup? Does this mean now as a rule that you need to hire a community manager later or earlier? That's really a great point. I think community managers to developers is actually a very important early business function almost before a sales organization.

Starting point is 00:20:50 Right. So you want to coalesce that community and then layer up a sales organization because that's the community that's going to try your product and it's where you're going to get your pipeline of users that you can then feed into an inside sales organization following the adoption of your product. I actually think along with that, and it's kind of not what companies often think about, you know, in order to get something virally adopted, it has to be good. It should be obvious in a given, but you're right. So you end up putting basically your best development. resources. In my case, I put my best developer on the open source side of the house, which from a company is kind of difficult to do

Starting point is 00:21:26 because you basically want that best developer to be working on the core product on the inside. But, you know, a community manager is great. A community manager is not going to drive adoption like the best engineer on the planet. I agree with that. I agree with that. So, I mean, if you're going to be doing this, you have to make sure and there's attention internally that your best

Starting point is 00:21:42 developers are one that are driving the open source project because that's how you'll get real credibility. And then you have to realize that that developer is not contributing to the core. I also think along these lines, you have to navigate the roadmap of what goes into open source on how you think about your business model. Exactly. Because you could, you know, now you put your best developers on open source and there is a very natural tendency to go make that product, arguably the best product it is. Go add all the features and all the functionality.

Starting point is 00:22:13 And if your business model is the assumption that you're going to upsell something into that, but your best developers have already created that in open source. You're kind of down a path where there's nothing to upsell anymore. You have to understand the dividing line and be very clear in an organization about what goes into open source and how you monetize all of this as opposed to just say, okay, build the best product you can, and then we'll figure out the segmentation. We've met with a number of companies that are trying to do this, and I'm always very interested in how you structure the organization.

Starting point is 00:22:50 Like, who does the open source team report to? Because if you have them report to like the core product team, I mean, there's a lot of internal dynamics that have to be managed because there's just fundamental tension. That was actually my next question, which is, to kind of close this out, then, how does this change all the knowledge we have about how to do product management that we've all learned through these traditional companies? It heightens the importance of really putting a go-to-market plan in place early on, because the natural tendency, we have been conditioned to listen to our customer.

Starting point is 00:23:23 And I can tell you what a customer says when you release open source is make it easier and more functional and I will adopt it. So let's say we now take that back to our developers and they say, great, we're going to add, let's take all of these features that we thought we'd go charge for and throw it into open source because that's going to increase adoption. But the defeating point there is that, well, there's no revenue anymore because the customer has taken all this stuff and it works great and they're using it everywhere, but we don't have anything else to sell. And so having a real awareness on that, and I'm not saying

Starting point is 00:23:58 don't listen to customers, but I think we have to be very, very careful in terms of that fluidity between open source and the revenue opportunities for the company and to make sure we always understand the tradeoff between adding another feature into open source versus the monetization and go-to-market plan that we established when we started out. And so I think it becomes important very early on. We're in the past, it didn't really matter that much. You can kind of figure out features as you go, and customers would tell us and all that stuff. And now you have to be a lot clear and a lot more intentional about your plans up front

Starting point is 00:24:39 so that when things change, you actually have a milestone by which to measure the change against. And I think organizationally, you almost have to reflect that. which is like if the open source is subservient to the closed source, it's very unstable because basically the closed source product is going to keep it anemic in a way that feels like a negative dynamic. And if you happen to the other side of the open source actually controls the close source, you know, it would be very difficult to enforce, you know, that separation. So, you know, I've tried both models and I ended up, you know, doing the one where they're actually separate teams so that someone above them that actually is very clear about the go-to-market and about the dividing lines is able to arbitrate. Now, that was just my personal experience, but I do think it's something that entrepreneurs should think through is how to structure the teams, given that you've got this very natural tension internally. That's great, you guys. Well, thank you.

Starting point is 00:25:25 Thank you. Awesome.

The a16z Show - a16z Podcast: Selling to Developers & Open Source Business Models

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.