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

Episode Date: April 14, 2016

Developers are more than just influencers inside the enterprise -- they're now buyers, too. That's a huge shift from before, when only IT and other departments had that kind of purchasing power. (It's not just a Silicon Valley thing, either, as every company becomes a software company.) So what's different then about selling and marketing to developers? One key is open source. But offering products and services built on top of open source brings up a whole slew of other questions: What are viable business models, how do you monetize? Especially since (as Peter Levine has argued before) there will never be another Red Hat a.k.a. a successful "open core" business model. a16z partners Levine and Martin Casado offer their observations and advice about selling to developers and open source business models in this episode of the podcast. The answers affect everything from sales -- yes, you still need sales even when selling to developers! -- to product management (what features to withhold, who builds them) and go to market plan. The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments and certain publicly traded cryptocurrencies/ digital assets for which the issuer has not provided permission for a16z to disclose publicly) is available at https://a16z.com/investments/. Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.

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 A16C 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, Martine 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 partner. I was trying to avoid saying that. Okay. 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 transformation 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, now popped the program, but I could not buy any. I wouldn't, didn't even know how to buy

anything. Other departments in companies, 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 of our economy. It's not just tech companies with 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 buying potential. And that has now become very well noticed 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 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 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, 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 behind the cost center. The other part of that is the ease by which developers can consume infrastructure, 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 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. 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 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. 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 a set of great tools, it becomes a foregone conclusion that 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 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 software got deployed. And then it got rolled out and no one would use it. Here we have the democratization of applications of developers, of developers, tools through open source through SaaS that I believe really moves the needle in terms of innovation and the best products are the ones that win. Now, that doesn't mean that that's the end of 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 up and inside sales or a 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. So that means that you have to be very good at two motions, right? 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 of 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. is the point at 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 competency app? 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 everyone

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 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 within 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 boot strap drive through 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, you know, one of certainly my personal quantities 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. 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, you know, to buy it all. Developers don't like to take classes about other people's products. They like to understand everything. 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 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 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 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, 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, 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, which is support and service and updating

products online. And for other, 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. 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 products 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, they were going after and cannibalizing an existing market, which is way more difficult 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. 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 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 what I'll call the

commoditization of some of the infrastructure components with new products. 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 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? 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 so much bad to be 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, especially like your repeatable revenue, like license revenue on open source. The second one, and I peter wrote this on, 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. So know if you're entering a mature existing market and your value is basically commoditization or understand if it's really innovation. I mean, market category 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, it may be 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 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. 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 because you basically want that best developer, do we work 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 actually building something good. So, I mean, if you're going to be doing this,

you have to make sure, and there's attention internally, that your best 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, 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. 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 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. 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 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 trade-off 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 upfront 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 closed 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's 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. Thank you. Awesome.