The a16z Show - Free Software and Open Source Business

Episode Date: October 21, 2019

Today, despite the critical importance of open source to software, it’s still seen by some as blasphemous to make money as an open source business. In this podcast, Armon Dadgar, Cofounder and CTO of HashiCorp; Ali Ghodsi, CEO of Databricks; and a16z General Partner Peter Levine explain why it's necessary to turn some open source projects into businesses.They also cover the most important questions for open source leaders to answer: How do you keep community engaged while building a business? What new opportunities does SaaS (software-as-a-service) present? And if you are a SaaS business, how should you approach cloud service companies, like Amazon Web Services (AWS)? Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that 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. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Welcome to the A16Z podcast. I'm Doss Rush, our enterprise technology editor, and in this podcast, I moderate a panel discussion on some of the most heated topics in open source with two of the leading founders of open source companies. Armand Dodger, co-founder and CTO of Hashikorp, which does open source tools for managing multi-cloud, and Ali Goetzee, the CEO of Databricks, a SaaS offering of Apache Spark. Joining them in conversation is A16Z general partner, Peter Levine, who's invested and been on the board of numerous open source companies such as GitHub and Nettoe. It's a great discussion and it takes on everything from making money on open source while managing community to the nuance of partnering and sometimes competing with big cloud vendors. Just to note that this was recorded at a live event, so there are some audio issues. The first voice that you're going to hear in this is Armands, then Ali, and a few minutes into the conversation Peter joins them. Finally, please note that 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 it is not directed at any investors or potential investors in any A16Z fund. For more details, please see A16Z.com slash disclosures. Throughout the history of open source, talking about making money on open source has been a pretty controversial topic with a lot of different views. So I'm curious, Alian Arman, how have you thought about commercializing open source and why did you choose to turn a project into a business? For us, it didn't start necessarily as thinking about

turning the open source into the business. It was more around recognizing that there's a clear market gap in terms of, in our case, sort of DevOps tooling, how do we actually provision things in sort of cloud infrastructure, and then realizing it's very hard to become a large sustainable project if you have negative cash flow forever. And if you're out of university and great, you have grants and things like that, they can sort of fund it or it's a little hobby project and it's two, three people doing it on a weekend, fine. But if you're solving a large enough problem, you know, you eventually need teams of dozens, hundreds, thousands to work on that problem. You kind of need a business. There has to be sort of a top line, you know, connected to

their bottom line. Otherwise it doesn't make a lot of sense. And so I think for us, it was, you know, started pretty pragmatically in terms of, hey, we are passionate about the technology, passionate about the space. We want this to be viable long term. Well, the only way for it to be viable long term is if you make money. I'm just going to be honest. We were academics. We just wanted to have impact and we wanted to publish papers. And the software we built, people didn't want to adopt it. So we went to all the companies that were out there, went to Cloud Era, all these guys. I said, please take the software, take it with you, take credit for it.

And they all just refused. They said, this is just academic, you know, Mambo-Jumbo, not interesting. What if these PhD students just leave? Then there is, you know, then this is enterprise software we're selling. So they just rejected us. So in 2013, we were kind of frustrated and we said, if we want to actually succeed, The only way we can get these projects off the ground is we actually start something ourselves.

They wasted so much of our time. We put interns into these companies. What do you really think? We were sending interns into these companies, hoping that we'd adopt our software. It never happened. Since we were frustrated in 2013, we just said let's create a company ourselves to do it.

I don't think revenue was sort of top of mind for us. First two years in Databricks, our only goal was how can we make Spark and these software that we have take over the world? Let's talk about the flip side. You know, you choose to go out and have a commercial venue, How have you gone about managing your community and communicating that with them, kind of keeping their support for what you're doing?

You know, I think for us it goes back to Peter's point around having a clear product management framework that you can articulate where your community doesn't feel like you're just randomly picking what goes one way or the other. And I think for us, it was really trying to draw that line and saying, okay, great, the things that are truly organizational complexity problems, right? You need role-based access control. You want audit logging. You need PCI ISO-Soc compliance, things like that. You're like, okay, great. If you have those problems, you're probably a global 10,000 business. You're not a SMB hobbyist.

And I think we drew that line and articulated to the community and said, hey, things in this bucket, great. They go into Enterprise, and the people who are going to pay for that are the people who have that problem. You as a hobbyist don't care about, you know, hardware security device integration for your compliance, right? Like, it's not a problem you have. And so I think if you articulate it clearly that way

and have the discipline to stick to it, then the community doesn't feel like they're sort of randomly being jerked around. And they don't feel like they're losing value because those aren't problems they have. Yeah. For us, we're different. I mean, these guys are much smarter than us.

We didn't think these things through. I mean, we just want it to start to take over the world as open source projects. So we only had one roadmap. It was the open source roadmap. We wanted to sort of, and we were frustrated that no one would adopt it. And there was a lot of fun in the market

that the technology we built won't work for this and won't work for that. It only works if it's in memory, not if it's on disk. this kind of thing, so we were super frustrated. So the first three years, our only goal was get adoption. We didn't care about any revenue. I mean, three, four years in, we only had one million revenue.

So we only had one roadmap. We only managed the community. And then in 2015, it just exploded. Like, it exploded like, I mean, you saw some of the curves. It's like, you know, thousands of developers started contributing code to it. And at that point, that's when things started, the community was so big,

and this thing became way bigger than we are. Like, we were like unknown, and then the project was huge. So at that point, we started thinking through, hey, how do we actually monetize this thing? Can you talk a little bit more about, you know, that moment in 2015 when you have this huge community, and now you're starting to think about the secondary road bat where you're commercializing something? How did the conversations change? Yeah, well, so what happened is remember those guys that said, hey, we don't want your stuff?

It's crap. In 2015, they all took it, and then they went and said, we are the Spark Company. Right. And they took credit for it. So, you know, so at that point, we were like, wow, okay. So everyone was adopting Spark, and actually these established vendors were actually taking credit for the project, and we were unknown small company with one million revenue, right? So it was at that point that we had to start figure out, okay, how do we do this?

And that's when we actually started leveraging product management and really listening to, you know, what are the customers really need? Enterprise customers, what are we need to succeed. And we realized, actually, that the open source project itself is far from what it is. It just covers a small portion of it. So we started building all the other things that they need to have a managed solution for enterprises. And then we started building that, and we kept a lot of that proprietary, frankly speaking, starting in 2016. We kind of like swung the pendulum the other way.

You mentioned there a little bit some of these other companies starting, and I think that's an interesting space that happens with these open source communities, is you're not just the only company contributing back to this code base. How have you navigated some of those relationships where you have competitors in there as well? you have this natural advantage if you're the sort of spiritual center of the project. Yes, you could take one of our projects and fork it and go contribute to yourself, but in any

conversation, right, they're like, why would I use your version instead of the Hashikor version? They're the author, they're the creator, they're the one with the roadmap control. So I think, you know, you see some of it, but it just falls by the way side so rapidly, right? Because it's so hard for someone else to build a community when there's already sort of

an orbit and universe around sort of the spiritual center. of the project. So I think it's just super tough. You just don't see a lot of that. When you say that spiritual center of the project, like what gives you that? Where does that come from? I think a lot of it comes from the credibility of having the founders still there, right? I think it's super hard if you don't have, if not the founding team, at least the core contributing team. I think if you have that core development team, the core founders still there, it's very much the spiritual center, right? And it matters a lot in sales conversations, right? When you can

say, hey, we have the creator, we have the top, you know, 20 contributors, right? And I think that's what gives it that sort of spiritual center. And, you know, Oli, you mentioned that, you know, you had all these other competitors starting around that same time. How did that play out for you with the community, kind of making people realize, like, you guys were the ones to go to for that? Yeah, I mean, I have a controversial opinion, and it's that most open source projects are actually just led by one company.

Like, there's really one company that's contributing to it. And if you look at the, and in fact, most open source projects are super brittle. If you actually look really closely, you'll notice it's actually five people only. It's six guys or gals that are building the project. And that's just one company. There are some counter examples. In the case of Hadoop, there was two companies, and that created a huge mess. So they were fighting each other.

One would contribute code to it. The other one would delete it, and then the other one would add it back. Kubernetes maybe has two companies, like maybe Google and it used to be Red Hat. So it's usually anyway just only one company or two companies. So in our case, while other people started saying, hey, we also, like offers Spark on the ground, they weren't really actually digging in. They were just selling it. There's packaging it up.

They were packaged up. So, I mean, I think in case of Hashy Corp, you guys are only real major contributors. But if you look at GitHub, I'm sure you sort on contributions and commits, you'll find that it's the absolute majority is just probably hash. Yeah, we saw the exact same thing. It's in source. Same thing. You know, everyone said, yeah, we're, like a lot of, there's a lot of people who look at the code

and maybe, you know, put a comment in or whatever. but fundamentally looking at like really innovating and all that really happen. It's like down to, you know, really a handful of folks who do it. It's actually very interesting, notwithstanding how large the companies get and all that. There's always the core group that knows it. Absolutely. The way we sort of articulate is almost all of our products make a distinction between what we'll call it core and then sort of the extension points around the edge. And if I look at the contributor graph, if you look at core, it's exactly that.

Yeah, it's like 5, 10, 20 people working at HashiCorp, the 99% of the core. it's the contributions sit at the edge where you have these integration points where it's, take a terraform, for example, it's integration surface is infinite. Right? And so at that edge is like where you go from 20 contributors to 2,000 contributors on the outside.

And I would guess for you guys is a similar thing around. There's the core versus maybe some of the algorithms or plugins that sit at the edge where it's easier to contribute. You don't have to be a core expert. Yeah, I agree. I'm just saying in terms of a core ownership of the project,

it's one company. And I would say that where open source sort of degrades is the opposite of that where you have many companies all arguing with each other. I mean, OpenStack was a really great, to me, and a great example of that, where, you know, like it was a jump ball on every company had their own version, had their own thing, and there was no consistency with it

because there was, in my mind, no leadership of that project. While we're kind of on the topic of participating in these communities, how have you gone about managing kind of the engineering function within an organization and keeping them involved and how do they interact with that community? So the way I see these days is you run a company, you have an engineering department, you have your product management, and you're building an awesome product that's going to, you know, wow your customers. That's it. A portion of it happens to be open source for us these days. And that portion, we manage a community and we give them roadmaps and, you know, do that.

but really, by and large, Databricks is a software company. I focus on building software. The fact that some portions of it happen to be open source, that's just an amazing lead-gen machine that makes us be able to walk into accounts and get ahead of the competition because we know you guys. You guys created SPAR.

But really, the way I look at the company is, you know, build amazing software that you can monetize with enterprise customers. That's the only way I look at it. Yeah, I guess our engineering probably looks pretty similar, It's not like a open source side of engineering and then an enterprise side. It's sort of one team, and they just work against two different roadmaps. And some of the futures land in open source, some of them land in enterprise, but it's the same engineering team, same sort of product management team.

Do you guys have a framework for how to think about what goes in open source and not? And is that consistent over time or for each release? Do you debate that? Yeah, so we sort of articulated something probably early 2017, which was we think about sort of our split is what's technical complexity versus what's organizational. So if we're solving something

that's fundamentally caused by the organization, you have, for example, a silo between networking and security and ops, right? You have a collaboration problem now. Or you have a PKI team that's distinct from your security team, right? And those are enterprise things. Got it.

Versus it, oh, is it a core technical thing that we're solving? Like the tool fundamentally needs it, that's open source. SaaS software is very defined. from the Red Hat support services on-prem. That's really the big difference for Databricks. So kind of what we open source and what we don't open source

doesn't really matter to our customers. Exactly, yeah. That's just because we're a SaaS company. If we're on-prem it would have been a different business. But because we're in the cloud, they're renting the service from us. They're not trying to run our software. They're just renting it from us and they're paying us rent for that service, right? They just want this to work in the cloud and we manage it for them.

Where it would maybe get iffy is if some someone else decides to take all of our software and offer it as well. So it's just that competitive angle. Otherwise, our customers don't care. And I think the perfect example of that is Amazon Web Services. People use Amazon Web Services, like Enterprise, they have over a million customers now, right? They never ask, hey, is EC2 from Amazon open source? Is S3 from Amazon open source?

Is Redshift from Amazon open source? They're not. And no one seems to care. And you know, the truth is when you're renting a service in the cloud, you know, it's just a different dynamic. So we don't have to worry too much about these things, what becomes open source and what's not. That's an interesting thing because I think we sit in phase 1.0 and you're sort of in phase 2.0, which is like we're by and large a on-premise desktop software vendor.

This is why we didn't go to on-prem at Diderix, because we wanted to have this model. We didn't want to have to worry about this. So you just rent the service from us in the cloud. That's it. It's very inspired by Amazon's sort of business model rather than the Red Hat model, which is what exists on-prem. Harder to monetize, I think. Absolutely. Well, since you're talking about kind of these cloud vendors, you mentioned AWS.

Peter said in this presentation, you know, hey, we've maybe over-rotated on this threat. Agree or disagree with that. I think it depends on the type of software you run. And what I mean by that is, you know, there's things that are super compelling for the clouds to want to run, and there's things that, you know, maybe they care less so, right? So I think about like HashiCorp tooling, for example. You know, Terraform, for example, it allows you to consume more cloud. And so in that sense, anything that allows you.

consume more cloud, wonderful. What do they care? They don't care if you're running Windows or Linux or whatever you want to do. Just draw more power, basically. And so in that sense, it's like, is there value in them co-opting, Terraform, or console, or vault, and running themselves? Like, okay, you're going to run two more extra nodes in Amazon. Like, the amount, it's a rounding error for them. So I think by the nature of being management tooling, it doesn't drive what they really monetize, which is CPU hours, network I.O., disk gigs. Right, that's it. Everything else is just different packaging of that. So I think, you know, it depends kind of where you sit in that, you know, how aligned are you to what the cloud cares about, I think.

I think you guys are an interesting case, which is if you sort of drive all three of those, you know, probably have users of compute network and storage. So I think it's probably a different interest. We don't get any paid on those things. We only get paid on the software. We, they get a separate bill from the cloud vendors. I mean, I kind of agree with Peter. I see it differently from like the community or the media, how they describe this problem. the way I see it is

basically there's a bunch of on-prem vendors, ISVs, you know, startups like us, they're running successful open-source projects, and then their customer base is moving to the cloud. So they talk to their customers, and the customers like, hey, we're about to move into the cloud. So then I say, oh, okay, we'll also offer our service in the cloud. So then I try to offer it in the cloud,

then it turns out it's actually extremely hard to offer a cloud service. And it takes you many years to get good at it. In our case, we've only been in the cloud from the very beginning. We've never been on-prem. We're good at running cloud services. there's no problem in offering services that has a lot of value to customers and to pay for it, and we can run it really well in the cloud.

So as an example of that, we had a proprietary thing called Delta, which had massive adoption in the last few years. It's completely proprietary, and we decided to open source it this year, and we open sourced it with completely liberal open licenses with no shenanigans in there. You don't need to freak out and be afraid of the cloud vendors if you know how to run a cloud service. But it's hard to run a cloud service. Running the SaaS model has been very hard. It takes long time to get good at it.

So like when we did the shift over sort of to start monetizing it, you tell your engineers, hey dude, can you, you know, have this pager duty and you know, might have to wake you up at 3 a.m. if the thing goes down. And then you're like, what? Like I don't want it. It's like, yeah, you're on call. This is the rotation. You know, you have to wake up at 4 a.m.

You have to be 4 and 6 you're covering if there's any outage or any security breach and so on. That's the hard thing that you have to do, which the on-prem vendors don't have to do really for their service, right? Because it's the responsibility of the IT department of that private data center of your customer to handle outages, security breaches, SLAs, yada yada. Whereas in our case, we had to tell our engineers, hey, sorry, like, it's why you're getting paid the big bucks, you know, carry this pager. It feels like there's an interesting analogy, right, which is, you know, there was an era where, as everything went from hardware to software, you saw the

hardware companies really struggle because fundamentally, if your core competency is hardware, it doesn't translate super well to software. And I think as you go from being a software vendor to saying, hey, I want to be a cloud service provider, the skill set, the core competency of writing and developing software actually doesn't translate that well into being good operationally. It's a completely different skill set. So I think as you go through

from a software vendor into saying I want to be a cloud SaaS vendor, you might find that actually your internal core competency isn't there. My sort of opinion on this it's very hard to do both. And we're all tempted to go, many startups are tempted to do both

so that we have optionality. Hey, if they, we can, customer can buy in any case, right? But I think you guys have pointed a very important part here, that doing both is really, really hard to do as a large company, let alone as a startup. The misunderstanding is, in the media, they say,

oh, you know, these big cloud vendors, they're just taking other people's open source software, not contributing anything back, and just exploiting that. What they forget to tell you is they're really, really good at running that software in the cloud, and almost no one else can do it that stuff. It's really hard to do.

And actually, they're getting paid the big bucks for that. That's what they like to tell you, because, you know, it kind of ruins the villain and, you know, hero story. Yeah. Well, I mean, I think that speaks to the fact that there's a lot more nuance to the relationship between an open source company and a cloud vendor than maybe what we see in the media. How have you or how have you seen other open source companies navigate the nuance of a cloud vendor relationship or other partnerships around open source?

I think you can partner with them. You know, they're good partners. We have extremely close partnership with Microsoft. We also had good partnership with Amazon and other cloud vendors. You can partner with them. You know, it's like all these workloads on the planet are moving into the cloud. There's just so much for us all to eat.

Figure out what the cloud vendors are good at. Let them add value there. Look at where they're not adding value. You can go there and focus on that. And then partner with them. It's a win-win situation. You can do that. So I do think one has to figure out how to align with them.

And I think one mistake a lot of big companies are doing is they don't align their Salesforce comp models to be compatible with the big companies' comp model. The way it works at Databricks is our customers get two bills, one bill from the cloud vendor, and then one bill from us. You get a bill for the hardware storage, the watts from the cloud vendors, and then get a bill from us on the software. The reason that is really important is that that other bill that they get from the cloud vendors

is actually paying the sales compensation of the cloud company salespeople. Hence they like us, so they partner with us in the field, in every account. However, if we change the pricing model so that they don't get paid, then they would hate us and block us from all the accounts. So I think that's like a minor nuance that some companies haven't figured out, and they end up in a really fierce competitive situation with the cloud vendors. We don't have that problem. The cloud vendors are very friendly to us.

I kind of want to zoom in a little bit and put Peter in the hot seat. He shared kind of that four-stage funnel from developer community management to product management to kind of the lead gen and sales dev, and then those sales. I'm curious, how has that played out for you? Is that held true? what parts didn't necessarily hold true. I think it goes through those exact phases that sort of Peter laid out. I think then those phases actually map pretty well into the funnel as well, right,

which is at that early phase of product market fit. It's a lot about developer advocacy, building the community, things like that. As you go into sort of repeatable sales cycle, well, that only works if you have a tight fit between product management and product marketing in terms of, okay, great, we need the futures customers are asking for, and then we should tell them about that, right? So there has to be sort of an integration there at that phase. And then I think as you start going to scale, you get to sort of those phases three and four in the funnel to really be able to amplify that message and bring in the cloud partners as part of your channel.

I think the only thing that maybe we experienced slightly differently actually would be on that fourth phase. I think you laid out sort of start with SaaS, self-service, then go departmental, then go enterprise. For us, it's almost been exactly the opposite, right? And I think it, again, I think it's because we were sort of a phase 1.0 versus a phase 2. I also think it depends on what product you're actually selling. You may not have, your value may not accrete to an individual user, in which case, I just want to make it clear, you may not have that line because the product doesn't support that line, right?

And so then you may start, many companies start with field sales first. So it was an example of how to layer it up as opposed to that's, every company ought to be that. But I think it goes to your point that you made of having a framework in terms of what do you decide goes open versus enterprise, right? Because as I describe our framework, our dividing line is what accreeds to an individual. Well, that's open source and what accrues to an enterprise. And so because of the divide we use in product management, it's very hard for us to have a sort of a self-service model. There is no self. That's given away for free. So you could look at that

bottom curve and say this is the open source line. It's not dollars per customer, whatever the y-axis would be. And then you'd build your revenue model on top of that. Exactly. Exactly. Right, so I think for us, once you sort of acknowledge, hey, that's the divide, it makes sense to start on the enterprise side. In an article that Peter wrote in 2013, I think, that was the same time as we started Databricks, in which he really accentuated the big difference between this Red Hat model and the SaaS model.

And it really resonated with us. And, you know, we really thought, you know, I mean, our view was really like this on-prem red hat open source model is dead. It's bad. We looked down on it. We didn't want to have anything to do with it. it and we really saw this sort of SaaS model as extremely powerful. And it's pretty prescient because 2012-13, you know, AWS was not the huge phenomenon it is today, right? Now it's

absolutely exploded, right? It's like taken over the whole planet. So I agree with it, but I think the thing that, you know, I would really like emphasize is for me the difference between SaaS and non-sass. It makes a huge difference. I think churn is higher if you're not SaaS. I think net expansion rates are lower. I think everything is worse if you're not SaaS. Because what can happen, I give you an example, I'm not going to name the names, but basically there was an open source event. This is one of those cases where the open source software was actually had two companies

fighting over it. They had contributors. One would run it on-prem and give support and services. And then what would happen is after a couple years, the customer would keep the software because it's free, but then migrate and get support from the other cheaper vendor. but keep the same software. That you can't do with SaaS services, right? If you want to move away, if you don't want to have a contract with us,

we would shut down the service. You can't use it anymore. And so hence, you know, and then what they would do is then they get the cheaper vendor. And then after a couple years, they would not even renew with the cheaper vendor because they would say, I actually hired your support guy into my company, so I don't need to buy any support from you anymore, and I'm still going to keep the software. With SaaS, you can't do that.

So churn ends up being lower, expansion rates are higher, everything is just better. It's super interesting as I think about it. Well, there's an exact example of commodity when I can go swat like all this software has been developed, and yet it's total commodity that I can basically go from one vendor to another to hiring a person to actually support this thing. And that's what was happening during that era when I mentioned the difference between open source valuations versus proprietary. This was exactly that characteristic that propagated that particular dangarious. So open source, the software itself has zero about intrinsic value, right? Anyone can download it.

Exactly. So what these companies were selling, their value was support and services, which quickly gets commoditized. And it goes down to who can do that most efficiently where on the planet and they can manage that P&L. And then you have a company like Red Hat, which has sort of a scale advantage. Exactly. That's their value at it.

It's a scale advantage to do exactly that. So for people who aren't familiar with that article from back in 2013, could you give kind of a quick summary of what you're doing. I mean, the title of this blog was why there will never be another redhead was the title. And I made the argument to Ollie's point that the support model was pretty broken at the time. And thinking about going to a service, to an open source service model, hosted service, was a way to really uncover and accentuate the value of the product that you're bringing to the market.

So that was, and I, I mean, there's basically all the points that we argued here. Red Hat had the, you know, they have the scale and capacity to go and do that. Don't get me wrong. Red Hat is a great company. It's just very hard for a startup to go replicate what they have done because their value at is the scale. And the things that startups don't do very well is scale because you don't have the money to go and do that.

So it's counter, you know, it's sort of counterproductive on that dimension. to compete with Procter and Gamble and Distribution. Exactly. Like it doesn't, you can't do that. You can't do that as a startup. SAS also is killing that business model even more. Totally. The secret sauce, like the thing that's weird about Red Hat

is that of all the open source company that exists, that for some reason that people can analyze and debate forever, they ended up being a monopoly without really any fierce competition, which is generally not true about the open source software. You end up because the software has zero intrinsic value, you end up getting lots of competitors, which commoditizes the price and brings it down. But with the cloud vendors now,

you're much more unlikely to have a monopoly like they had, because if you offer just free software that you're just distributing, they can also pick it up and offer it. So it's very unlikely there will ever be another red hat because of that. So what practical advice might you give? Having done on-prem, I'd say skip on-prem. Go straight to SaaS. Save yourself. Yeah, I mean, I think

Yeah, I think that the advantages that Alley has talked about around the SaaS model are very true and I think to Peter's point about changing competence being very hard. You know, if you go down the road of building software competence and then realize you want to switch to sort of SaaS competence,

you know, very much the bucket we're in, to be honest, you realize it's a hard shift, right? It is a different skill set. It's a different set of, you know, practices. And so, you know, the earlier you can do, that, ideally at inception, the sort of easier your life will be. The further you get down one road, the harder and more painful that shift really is. Yeah, for me, I would say SaaS is obviously the one, like definitely just start with the SaaS. By the way, Wall Street likes

SaaS and gives you higher multiples, so you make, you know, you get a higher valuation, so there's that as well. But ignoring that aspect, I think what is it you want to, what do you want your company to do? Which space do you pick? And the way I think about it is, you have to have a lot of, you to expect these three cloud vendors, Amazon, Microsoft, Google, they each have roughly $100 billion of cash sitting around. And they actually have a printing press that's not the cloud business, right? They either have an ads business as a printing press or they have a Windows or something server business that is a printing press, or, you know, they have a retail of everything on the planet, it's their printing press. So you should just assume that they're

going to get really, really good at the lower levels of the stack. And the lower levels of the stack, there aren't that many things. There's like machines, there's storage, there's networking, there's some databases, that's it. You move up the stack a little bit, you start having much more. And as you move up the stack, it gets more and more verticalized, and it actually becomes a lot of different things, a lot of different products. The cloud vendors can't win all of those. They can dominate and crush and just completely own the bottom layers. The higher up you go, there's going to be a lot of vendors. Otherwise, if I'm wrong about the statement, there will only be three companies on the whole planet.

in software. That's very unlikely, right? So pick a space higher up in the stack. Competition will be much less. It's going to get much more verticalized, and you know, and do it as SaaS, and you'll probably be very successful. I did want to touch on briefly kind of your backgrounds and the origin of open source, as well as kind of your own start in academia. Those two have been really tightly linked. Now we see, you know, with commercializing open source. What does that relationship look like? Like how are academia and open source connected in your mind.

I mean, I think one of the interesting things about academia is, like, going back forever, it's always had this ethos of, like, it's free software. Right. It's sort of publicly funded, right? You get in government grants to pay for the stuff, so you're sort of naturally giving it out or the code is there for so other people can reproduce the work and extend it and add on it. So I think you kind of, you know, if you spend time in that, you kind of soak in that ethos. And that's sort of the notion of that the software is free and other people collaborate and

extend and remix becomes normal, like it doesn't seem weird. I think the other nice thing is, especially infrastructure software, this stuff isn't like, hey, I'm going to bang it out over a weekend and launch my cool new app and put it on Hacker News, right? It's like spend years building this stuff, right, and really getting it to a point of broad usability, scalability, you know, et cetera. And so, you know, where are the environments where you can spend years and years working on a thing? Right? You kind of have that luxury in academia to be able to do that.

And so it's like, you know, the first few years of development might take place in a, you know, university. then it becomes sort of an industrial project from there, but it would be very hard to bootstrap some of the stuff from zero in an industrial setting. Yeah, I mean, I actually think academia has misconfigured. I mean, I'm actually a young professor, so I'm kind of, I wear that hat too, but I think in the systems research field, it's misconfigured. I think there's a huge opportunity for academia to come in

and completely disrupt the software scene. But the way it's configured right now is, as academics, we get incentivized on publishing papers in the top conferences, and that's what we focus on typically. If the focus was on push the boundaries of what kind of software you can build and disrupt the world with it, you know, all these universities,

with all these students that have five years to sit and create the open source project, could like completely disrupt how software is done on on the planet. It's a gigantic opportunity for any university to sort of take on. Berkeley actually did it, I mean, to our credit, I mean, we kind of pushed forward on that

with some of these labs that we had, like Rad Lab, Amplab, RISE Lab, But it's just scratching the surface. I think there is a scenario if all the universities kind of figure this out, which they haven't, that they could completely start owning the software space. It could become like the future of how software is developed. It's like basically open source projects that the different universities are leading. That's not happening right now.

All right. So kind of time for like a last question here. What area of open source right now is the most fascinating to you? Where do you think the most interesting things are happening? I mean, so I'm going to kind of not answer that by saying, data and how, you know, the value of data and the ecosystem around it, how you can buy it, how you can sell it, how it can leverage it, and the models that interpret that data, that's, you know, we think of software, we used to think of our hardware, software, and so on, I think

data is the next thing. And, you know, I mean, a lot of people have said it, it's the new oil, or, you know, but we're just in the beginning of that, this early innings of how that's, there's going to be an economy forming around data itself. I mean, it's already kind of happening. So that's, I think, fascinating. So then that's like the next third wave of interesting sort of market trend that you're going to see in the software space. Like the software will kind of be free, but who has the data will actually, and the models around that are going to be the, that's going to be the competitive edge.

I've always personally been a bit of a systems guy, so I love following sort of what's happening in database research land. And to me, I think, you know, it's been interesting because it's like RDBMS has sort of ruled the world for decades and decades. And I think what's finally happening is you're either saying shifts because of scale, right? You're no longer saying, okay, and fit all the data on one machine. I need to fundamentally go to a clustered architecture. Or now, as we think about sort of IoT, Edge, fog computing, whenever you want to call it, there's these notions sort of hierarchical levels of data where you might have high bandwidth, high throughput, you know, cloud data centers, and then, you know, go out to sort of an acomai

or fastly pop, and then go out to someone's house, and then go out to your phone. And so how do you actually design systems that can reconcile and handle data, sort of planetary scale, much higher volume, much lower latency, and reconcile and do it all in a comprehensible way. So I think that's a sort of a fascinating space in terms of, you know, is RDBMS finally being challenged as sort of, you know, supreme when it comes to data management? I think one of the fascinating elements of open source is the origination of projects now. Like these stats of Google doing 2,000 projects and all of that, maybe that's part of the answer of, I love your academic sort of comment.

It may not happen there, but the fact that all of these companies are really built on large backbones of open source and are releasing these projects into the market where there's not a lot of strategic value to them, I think it's unlocking a huge number of opportunities that I think will very much dominate the landscape as we sort of roll into the future.

That's really interesting. I want to thank you, thank the panelists, and a huge thanks, Peter, to you for sharing all this information. Thank you. You just heard Ali Goetzee of Databricks, Armand Dodger of Dahshikorp and A16Z general partner Peter Levine, with me, Das Rush, moderating the discussion. Thanks again for listening. And if you want to learn more about open source, the importance of commercializing it, and what it takes to turn an open source project into a business,

you can download and or watch Peter's presentation and other open source materials at ASSR. 16Z.com slash open source.