Free Software and Open Source Business

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 CFI 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)?

Editor’s Note: Because this was recorded at a live event, there are some audio quality issues. We have published the full transcript below.

Transcript

Das: 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, Ali and Armon, how have you thought about commercializing open source, and why did you choose to turn a project into a business?

Armon: 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, DevOps tooling, and how do we actually provision things in cloud infrastructure. And then realizing it’s very hard to become a large sustainable project if you have negative cash flow forever.

If you’re at a university and you have grants and things that can fund it, or it’s a little hobby project and it’s two or three people doing it on a weekend. fine. But if you’re solving a large enough problem, you eventually need teams of dozens, hundreds, thousands to work on that problem. You need a business. There has to be a topline connected to your bottom line. Otherwise, it doesn’t make a lot of sense.

And so, for us, it 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.

If you’re solving a large enough problem, you eventually need teams of dozens, hundreds, thousands to work on that problem. You need a business. There has to be a topline connected to your bottom line. –Armon Dadgar, HashiCorp

Ali: I’m just gonna 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. We went to all the companies that were out there – went to Cloudera, all these guys. We said, “Please take the software. Take it with you. Take credit for it.” And they all just refused. They said, “This is just academic mumbo jumbo. Not interesting. What if these PhD students just leave?” This is enterprise software we’re selling, so they rejected us.

So, in 2013, we were kind of frustrated. We said, “If we wanna actually succeed, the only way we can get these projects off the ground is if we actually start something ourselves.” They wasted so much of our time.

Peter: What do you really think?

Ali: We were sending interns into these companies, hoping that they would adopt our software. It never happened. We were frustrated. In 2013, we just said, “Let’s create a company ourselves and do it.” I don’t think revenue was top of mind for us.

The first two years at Databricks, our only goal was how can we make Spark and the software that we have take over the world?

Das: Let’s talk about the flip side. You choose to go out and have a commercial venture. How have you gone about managing your community and communicating that with them and keeping their support for what you’re doing?

Armon: 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. For us, it was really trying to draw that line and saying: the things that are truly organizational complexity problems – you have role-based access control; you want audit logging; you need PCI, ISO, SOC compliance – if you have those problems, you’re probably a global 10,000 business. You’re not an SMB hobbyist.

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 were gonna pay for that are the people who have that problem. You as a hobbyist don’t care about hardware security device integration for your compliance. It’s not a problem you have.

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.

Ali: For us, we’re different – you guys are much smarter than us. We didn’t think these things through. We just wanted Spark to take over the world as an open source project, so we only had one roadmap. It was the open source roadmap. And we were frustrated that no one would adopt it.

The first three years, our only goal was get adoption. We didn’t care about any revenue – three or four years in, we only had one million revenue. We only had one roadmap. We only managed the community. –Ali Ghodsi, Databricks

There was a lot of FUD (fear, uncertainty, doubt) 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. We were super frustrated, and the first three years, our only goal was get adoption. We didn’t care about any revenue – three or four years in, we only had one million revenue. We only had one roadmap. We only managed the community.

Then in 2015, it just exploded. You saw some of the curves. Thousands of developers started contributing code to it. And at that point, that’s when things started turning. The community was so big, and this thing became way bigger than we were. We were unknown, and then the project was huge. So, at that point, we started thinking, “Hey. How do we actually monetize this thing?”

Das: Can you talk a little bit more about that moment in 2015 where you have this huge community and now you’re starting to think about the secondary roadmap where you’re commercializing something? How did the conversations change?

Ali: Well, 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,” and they took credit for it. At that point, we were like, “Wow, okay.” Everyone was adopting Spark, and these established vendors were actually taking credit for the product and we were an unknown small company with one million revenue.

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 what do the customers really need. Enterprise customers, what do they need to succeed?

We realized, actually, that the open source project itself 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. We started building that, and we kept a lot of that proprietary, frankly speaking. Starting in 2016, we kind of swung the pendulum the other way.

Das: You mentioned a little bit some of these other companies starting. And I think that’s an interesting space that happens with these open source communities as 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?

Armon: You have this natural advantage if you’re the 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, they’re like, “Why would I use your version instead of the HashiCorp version?” They’re the author. They’re the creator. They’re the one with the roadmap control.

So, I think, you see some of it, but it just falls by the wayside so rapidly because it’s so hard for someone else to build a community when there’s already an orbit and universe around the spiritual center of the project. So, I think it’s just super tough. You just don’t see a lot of that.

It’s so hard for someone else to build a community when there’s already an orbit and universe around the spiritual center of the project. –Armon Dadgar

Das: When you say that spiritual center of the project. What gives you that? Where does that come from?

Armon: I think a lot of it comes from the credibility of having the founders still there. It’s super hard if you don’t have, if not the founding team, at least the core contributing team. If you have that core development team, the core founders still there, it’s very much the spiritual center.

And it matters a lot in sales conversations, when you can say, “Hey, we have the creator. We have the top 20 contributors.” And I think that’s what gives us that spiritual center.

Das: Ali, you mentioned that you had all these other competitors starting around that same time. How did that play out for you with the community and making people realize you guys were the ones to go to for that?

Ali: I have a controversial opinion, and it’s that most open source projects are actually just led by one company. There’s really one company that’s contributing to it.

In fact, most open source projects are super brittle. If you actually look really closely, you’ll notice it’s 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 were two companies, and that created a huge mess. 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, Google, and it used to be Red Hat. So, it’s usually just one company or two companies.

In our case, while other people started saying, “Hey, we also, offer Spark,” on the ground, they weren’t really actually digging in. They were just selling it.

Armon: They’re just packaging it up.

Ali: They’re just packaging it up. In the case of HashiCorp, you guys are the only real major contributors. If you look at GitHub, if you sort on contributions and commits, you’ll find that the absolute majority is just probably HashiCorp.

Peter: We saw the exact same thing at XenSource. There’s a lot of people who look at the code and maybe put a comment in or whatever. But fundamentally, looking at really innovating and all that really happening, it’s down to really a handful of folks who do it. It’s actually very interesting not withstanding how large the company is getting and all that, there’s always the core group that knows it. Absolutely.

Armon: The way we sort of articulate it is almost all of our products make a distinction between what we’ll call core and then the extension points around the edge. If I look at the contributor graph, if you look at the core, it’s exactly that, it’s 5, 10, 20 people working at HashiCorp on 99% of the core.

It’s the contributions set at the edge where you have these integration points – take a Terraform, for example, its integration surface is infinite – And so, at that edge is where you go from 20 contributors to 2,000 contributors on the outside. I would guess for you guys it’s 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.

Ali: Yeah, I agree. I’m just saying, in terms of a core ownership of the project, it’s one company.

Peter: 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. OpenStack was really, to me, a great example of that where it was a jump ball. 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.

Das: While we’re kind of on the topic of participating in these communities, how have you gone about managing the engineering function within an organization, and keeping them involved? And how do they interact with that community?

Ali: The way I see it 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 gonna wow your customers. That’s it. A portion of it happens to be open source for us these days. And that portion, we manage the community, and we give them roadmaps, and do that.

But really, by and large, Databricks is a software company that focuses on building software. The fact that some portions of it happened 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 they say, “We know you guys. You guys created Spark.”

The way I look at the company is build amazing software that you can monetize with enterprise customers. That’s the only way I look at it.

The way I look at the company is build amazing software that you can monetize with enterprise customers. –Ali Ghodsi

Armon: Yeah, our engineering probably looks pretty similar. It’s not an open source side of engineering and then the enterprise side, it’s one team. They just work against two different roadmaps. And some of the features land in open source, some of them land in enterprise, but it’s the same engineering team, same product management team.

Peter: 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?

Armon: We articulated something early 2017, which was we think of our split as what’s technical complexity versus what’s organizational. So, if we’re solving for something that’s fundamentally caused by the organization – you have, for example, a silo between networking and security ops, you have a collaboration problem now. Or you have a PKI (public key infrastructure) team that’s distinct from your security team. Those are enterprise things. Versus is it a core technical thing that we’re solving where the tool fundamentally needs it? That’s open source.

Ali: SaaS software is very different from the Red Hat support and services on-prem. That’s really the big difference for Databricks. What we open source and what we don’t open source doesn’t really matter to our customers because we’re a SaaS company.

If we were 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. They just want us to work in the cloud, and we manage it for them.

Where it would maybe get iffy is if 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. As an enterprise, they have over a million customers now. 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.

The truth is when you’re renting a service in the cloud, 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.

Armon: I think that’s an interesting thing because we sit in phase 1.0 and you’re phase 2.0. We’re by and large an on-premise desktop software vendor.

Ali: This is why we didn’t go to on-prem at Databricks because we wanted to have this model. We didn’t want to have to worry about this. You just rent the service from us in the cloud. That’s it. It’s very inspired by Amazon’s business model rather than the Red Hat model, which is what exists on-prem and is harder to monetize, I think.

Das: Since you’re talking about these cloud vendors, you mentioned AWS. Peter said in his presentation, “Hey, we’ve maybe over-rotated on this threat.” Agree or disagree with that?

Armon: I think it depends on the type of software you run. And what I mean by that is there’s things that are super compelling for the cloud to want to run, and there’s things that maybe they care less about.

I think about, HashiCorp tooling, for example. Terraform, for example, allows you to consume more cloud. And so, in that sense, anything that allows you to conceive more cloud, wonderful. What do they care? They don’t care if you’re running Windows or Linux or whatever you want to do, if you just draw more power basically. And so, in that sense, is there value in them co-opting Terraform or Consul or Vault and running it themselves? You’re going to run two more extra nodes in Amazon, it’s a rounding error for them.

By the nature being management tooling, it doesn’t drive what they really monetize, which is CPU hours, network I/O, disk gigs. That’s it. Everything else is just different packaging of that. So, I think it depends where you sit in that and how aligned are you to what the cloud cares about.

You guys are an interesting case. You sort of drive all three of those, probably heavy users of compute, network, and storage. I think it’s probably a different interest.

What we open source and what we don’t open source doesn’t really matter to our customers because we’re a SaaS company. –Ali Ghodsi

Ali: We don’t get paid on those things. We only get paid on the software. They get a separate bill from the cloud vendors.

I agree with Peter. I see it differently from the community or the media in how they describe this problem. The way I see it is, basically, there’s a bunch of on-prem vendors, ISVs (independent software vendors), startups like us. They’re running successful open source projects, and then their customer base is moving to the cloud. So, they say, “Okay, we’ll also offer our service in the cloud,” Then they try to offer it in the cloud.

It turns out it’s actually extremely hard to offer a cloud service, and it takes so 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 they pay you for it. And we can run it really well in the cloud.

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. 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 took a long time to get good at it. When we did the shift over to start monetizing it, you tell your engineers, “Hey, dude. Can you have this pager duty? I might have to wake you up at 3 a.m. if the thing goes down.” And then they’re like, “What? I don’t want to.” It’s like, “Yeah, you’re on-call. This is the rotation. You have to wake up at 4 a.m. Between 4 and 6, you’re covering if there’s any outage or security breach and so on.”

That’s the hard thing that we have to do, which the on-prem vendors don’t have to do for their service. Because it’s the responsibility of the IT department of that private data center of your customer to handle outages, security breaches, SLAs. Whereas in our case, we had to tell our engineers, “Hey, sorry. It’s why you’re getting paid the big bucks. Carry this pager.”

Armon: It feels like there’s an interesting analogy, which is 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 skillset, the core competency of writing and developing software actually doesn’t translate that well into being good operationally. It’s a completely different skillset.

As you go through from being 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.

Peter: My sort of opinion on this. It’s very hard to do both. And many startups are tempted to do both so that we have optionality. “Hey, a customer can buy in any case, right?” But I think you guys have pointed out a very important part here that doing both is really, really hard to do as a large company, let alone as a startup.

Ali: The misunderstanding is, in the media, they say, “Oh, these big cloud vendors, they’re just taking other people’s open source software and 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’s really hard to do. And they’re getting paid the big bucks for that. That’s what they don’t tell you because, it ruins the villain and hero story.

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. –Ali Ghodsi

Das: 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?

Ali: I think you can partner with them. They’re good partners. We have an extremely close partnership with Microsoft. We also have a good partnership with Amazon and other cloud vendors. You can partner with them.

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.

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 sales force comp models to be compatible with the big company’s 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. They get a bill for the hardware storage, the watts, from the cloud vendors, and they 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 sales people. Hence, they like us. So, they partner with us in the field in every account.

However, if we changed the pricing model so that they don’t get paid, then they would hate us and block us from all the accounts. That’s 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.

One mistake a lot of big companies are doing is they don’t align their sales force comp models to be compatible with the big company’s comp model.–Ali Ghodsi

Das: I want to zoom in a little bit and put Peter in the hot seat. He shared that four-stage funnel from developer community management, to product management, to the lead gen and sales dev, and then to sales. I’m curious, how has that played out for you? Has that held true? What parts didn’t necessarily hold true?

Armon: I think it goes through those exact phases that Peter laid out. Those phases actually map pretty well into the funnel as well. 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 repeatable sales cycle, that only works if you have a tight fit between product management and product marketing in terms of, “Okay, great. We need the features customers are asking for and then we should tell them about that.” There has to be an integration there in that phase.

Then as you start going to scale, you get to those phases 3 and 4 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 we experienced slightly differently would be in that fourth phase. You laid out that start with SaaS self-service, then go departmental, then go enterprise. For us, it’s always been exactly the opposite.

Again, I think it’s because we were sort of a phase 1.0 versus a phase 2.0.

Peter: I also think it depends on what product you’re actually selling. 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.

Many companies start with field sales first. It was an example of how to layer it up, as opposed to every company ought to be that.

Armon: But I think it goes to your point of having a framework in terms of what you decide goes open versus enterprise. Because as I described our framework, our dividing line is what accretes to an individual — well, that’s open source. And what accretes to an enterprise?

Because of the divide we use in product management, it’s very hard for us to have a sort of self-service model.

Peter: There is no self-service. That’s given away for free. You could look at that bottom curve and say, “This is the open source line.”

Armon: Bingo.

Peter: “It’s not dollars per customer,” whatever the y-axis would be. And then you’d build your revenue model on top of that.

Armon: Exactly. For us, once you acknowledge that’s the divide, it makes sense to start on the enterprise side.

Ali: In an article that Peter wrote in 2013 – that was the same time we started Databricks – he really accentuated the big difference between this Red Hat model and the SaaS model. And it really resonated with us. We really thought this on-prem, Red Hat open source model is dead. It’s bad. We looked down on it. We didn’t wanna have anything to do with it.

We really saw this sort of SaaS model as extremely powerful. And it’s pretty prescient because 2012-13 AWS was not the huge phenomenon it is today. Now, it’s absolutely exploded. It’s like taken over the whole planet.

So, agree with it, but the thing that I would really emphasize is the difference between SaaS and non-SaaS 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’ll give you an example. I’m not gonna name the names. But basically, there was an open source vendor – this is one of those cases where the open source software actually had two companies fighting over it. They had contributors. One would run it on-prem and give support and services. 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. If you don’t want to have a contract with us, we would shut down the service. You can’t use it anymore.

And then what they would do is 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.

Peter: It’s super interesting as I think about it, well, there’s an exact example of commodity. 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. That’s what was happening during that era when I mentioned the difference between open source valuation versus proprietary. This was exactly that characteristic that propagated that particular dynamic.

Red Hat is a great company. It’s just very hard for a startup to go replicate what they have done because their value-add is the scale. And the thing that startups don’t do very well is scale because you don’t have the money to go and do that. –Peter Levine, CFI

Ali: Open source, the software itself has zero intrinsic value. Anyone can download it.

What these companies were selling, their value was support and services, which quickly gets commoditized. And it boils down to who can do that most efficiently where on the planet and they can manage that P&L.

Armon: And any other company like Red Hat, which has a scale advantage.

Peter: Exactly. That’s their value add. It’s a scale advantage to do exactly that.

Das: For people who aren’t familiar with that article from back in 2013, could you give kind of a quick summary…

Peter: The title of this blog was “Why There Will Never Be Another Red Hat.” And I made the argument, to Ali’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.

That’s basically all the points that we argued here. Red Hat, they had 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-add is the scale. And the thing that startups don’t do very well is scale because you don’t have the money to go and do that. So, it’s counterproductive on that dimension.

Armon: It’s like trying to compete with Procter & Gamble on distribution.

Peter: Exactly, you can’t do that as a startup.

Ali: SaaS also is killing that business model even more. The thing that’s weird about Red Hat is that of all the open source companies that existed 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 open source software. 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 free software that you’re just distributing, they can also pick it up and offer it. So, it’s very unlikely there’ll ever be another Red Hat because of that.

Das: So, what practical advice might you give to an entrepreneur starting down that journey?

Armon: Having done on-prem, I’d say skip on-prem. Go straight to SaaS. Save yourself.

The advantages that Ali has talked about around the SaaS model are very true. And to Peter’s point about changing competence being very hard, if you go down the road of building software competence and then realize you want to switch to SaaS competence, which is very much the bucket we’re in, to be honest, you realize it’s a hard shift. It is a different skillset. It’s a different set of practices. And so the earlier you can do that, ideally at inception, the easier your life will be. The further you get down one road, the harder and more painful that shift really is.

Infrastructure software isn’t like, “Hey, I’m gonna bang it out over a week and launch my cool new app and put it on Hacker News.” You spend years building this stuff. –Armon Dadgar

Ali: For me, I would say SaaS is obviously the one. I definitely would just start with SaaS. Wall Street likes SaaS and gives you higher multiples. You get a higher valuation, so there’s that as well.

But ignoring that aspect, what do you want your company to do? Which space do you pick? And the way I think about it is you have to expect these three cloud vendors — Amazon, Microsoft, Google — they each have roughly $100 billion of cash sitting around. They actually have a printing press that’s not the cloud business. They either have an ad business as a printing press or they have the Windows or something server business that is a printing press, or they have a retail of everything on the planet as a printing press.

You should just assume that they’re gonna 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 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.

As you move up the stack, it gets more and more verticalized. 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 gonna 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.

So, pick a space higher up in the stack. Competition will be much less. It’s going to be much more verticalized. Go with SaaS and you’ll probably be very successful.

Das: I did want to touch on briefly kind of your backgrounds and the origin of open source as well as your own start in academia. Those two have been really tightly linked. Now, with commercializing open source, what does that relationship look like? How are academia and open source connected in your mind?

Armon: One of the interesting things about academia is going back forever, it’s always had this ethos of “it’s free software.” It’s publicly funded. You’re getting government grants to pay for this stuff. So, you’re naturally giving it out or your code is there so other people can reproduce the work and extend it and add on to it. If you spend time in that, you soak in that ethos, that notion that the software is free and other people collaborate and extend it and remix it becomes normal. It doesn’t seem weird.

Infrastructure software isn’t like, “Hey, I’m gonna bang it out over a week and launch my cool new app and put it on Hacker News.” You spend years building this stuff and really getting it to a point of broad usability, scalability, etc. And where are the environments where you can spend years and years working on a thing? You have that luxury in academia to be able to do that. And so the first few years of development take place at a university. Then it becomes an industrial project from there. But it would be very hard to boot strap some of the stuff from zero in an industrial setting.

Ali: I actually think academia is misconfigured. I’m an adjunct professor, so I wear that hat, too. But I think in the systems research field, it’s misconfigured. 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 pushing the boundaries of what software you can build and disrupt the world with it, all these universities with all these students that have five years to sit and create the open source project could completely disrupt how software is done on the planet. It’s a gigantic opportunity for any university to take on.

If the focus was on pushing the boundaries of what software you can build and disrupt the world with it, all these universities with all these students that have five years to sit and create the open source project could completely disrupt how software is done. –Ali Ghodsi

Berkeley actually did it to our credit. We pushed forward on that with some of these labs that we had like AMPLab, RISELab. But it’s just scratching the surface.

There is a scenario if all the universities figured this out, which they haven’t, that they could completely start owning the software space. It could become the future of how software has developed. It’s basically open source projects that the different universities are leading. That’s not happening right now.

Das: So, time for a last question. What area of open source right now is the most fascinating to you? Where do you think the most interesting things are happening?

Ali: So, I’m gonna kinda not answer that by saying: data, the value of data and the ecosystem around it, how you can buy it, how you can sell it, how you can leverage it, and the models that interpret that data.

We used to think of hardware, software and so on. I think data is the next thing. A lot of people have said it, it’s the new oil. But we’re just in the beginning of that. It’s the early innings of how there’s going to be an economy forming around data itself. And it’s already happening. So, that’s fascinating.

I think the next third wave of interesting market trend that you’re going to see in the software space, the software will be free, but who has the data and the models around that, that’s going to be the competitive edge.

Armon: I have always personally been a bit of a systems guy, so I love following what’s happening in database research land. To me, it’s been interesting because RDBMS has ruled the world for decades and decades. And I think what’s finally happening is you’re either seeing shifts because of scale – you’re no longer saying, “okay, let’s fit all the data on one machine. I need to fundamentally go to a clustered architecture.” Or now as we think about IoT, Edge, Fog computing, whatever you wanna call it, there’s these notions of hierarchical levels of data where you might have high bandwidth, high throughput cloud data centers and then go out to an Akamai or Fastly POP and then go out to someone’s house and then go out to your phone.

So, how do you actually design systems that can reconcile and handle data at a planetary scale, much higher volume, much lower latency, and reconcile and do it all in a comprehensible way? That’s a fascinating space in terms of is RDBMS finally being challenged as supreme when it comes to data management?

Peter: I think one of the fascinating elements of open source is the origination of projects now. These stats have Google doing 2,000 projects and all of that. Maybe that’s part of the answer. I love your academic 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 incredible. It’s unlocking a huge number of opportunities that I think will very much dominate the landscape as we roll into the future. That’s really interesting.

Das: I want to thank you, thank the panelists. And a huge thanks, Peter, to you for sharing all this information.