Created by Rishabh Srivastava, Founder of Loki.ai
This summary was largely done for my own note-taking, sharing it just in case it adds more value to other people.
I have no affiliation whatsoever with anyone in this note. This is a summary largely taken for my own reference, and may contain errors :)
Context
Source URL:
Why is it important: Shows how the business model for a very successful open-source company works
Keywords
Open source, SaaS, Startups, Database, MongoDB
Summary
Trends
Storage costs have almost gone to zero and the biggest constraint now for organizations is developer productivity and developer capacity
Â
Open-source strategy
You have two kinds of open-source strategies: crowd-sourced R&D (which the MongoDB CEO things is a bad idea), and a "freemium" strategy that basically enabling developers and users to easily get access to the code and be able to quickly build applications in a very frictionless way
MongoDB's original strategy was to offer commercial features around management and security etc to enterprises companies that bought it for on-prem deployment. But cloud killed this strategy. What was interesting is when you offer open source as a service, a la through the cloud providers, you can actually monetize it better
Â
Licensing
One of the really smart things the founders did is the open source model that they used at first was AGPL, which is much more restrictive than the classic Apache license model
AGPL basically says everything has to be shared back, and that includes things that run as a service, whereas a more Apache model or an MIT model, you don’t have to share back changes and you can just take it and use it
Later, they changed it to SSPL. It basically mandates that it’s still a free-to-use license, but with one exception, that if you plan to monetize an offering of MongoDB as a service offering, you can still do that, but then you have to basically open source not just the code but also the management plane so that anyone can take that code and basically also offer MongoDB as a service offering
Â
Strategy for winning with open-source
- Get the product-market fit right. Developers must REALLY like your product
- Get a licensing model that allows you to build a real cloud business, without the cloud companies just ripping off your software and running it on their servers
- Get your go-to-market strategy right
Â
GTM Strategy
3-layered GTM:
- Frictionless self-serve. A lot of developers hate being sold to, hate being marketed to, they just wanted a very frictionless way of engaging. We found that not only did small companies like that but even developers of a large bank, for example, would use the self-serve option to play with the product as a precursor to doing a large project with MongoDB.
- Inside sales. When you have a lot of small customers, where it’s too expensive to send someone to go visit them, you should conduct business over the phone or over the web and build an inside-sales team to do this
- Enterprise sales. For large accounts - self explanatory
Â
Note: read the summary of the a16z approach when thinking deeply about this Approach to B2B Growth and Sales
Â
Flywheels in GTM
What’s interesting is that the different channels to become a flywheel effect, self-serve becomes a massive lead generation for us and then our sales people can cherry-pick the most important self-serve customers who show the most upside growth and then we help those customers not only be successful, but then they come back and consume a lot more
Â
Full article
An Update on MongoDB
In 2019 I wrote about a new AWS offering called Amazon DocumentDB (with MongoDB compatibility). The occasion was an opportunity to touch on a number of interrelated points: open source business models (traditionally services), what exactly AWS was selling (“performance, scalability, and availability”), and how MongoDB had created a new license that wasn’t technically open source to prevent Amazon from encroaching on its business.
Nearly two years on and it is clear that MongoDB’s approach has worked. I wrote after the company’s developer conference earlier this year that:
- MongoDB’s Atlas hosting service demonstrated that open source companies could and should shift their business models to “performance, scalability, and availability”; moreover, as I noted in the context of Snowflake, public cloud providers were heavily incentivized to not give their alternatives a price advantage.
- MongoDB’s licensing change was brilliant. Yes, it made open source advocates angry, but more importantly, it severely hamstrung AWS and Azure’s attempts to compete.
- The advantage of having a hosted service is that it provides a platform for additional differentiation above-and-beyond the open source product, which is exactly what Atlas was offering.
One of the advantage that Atlas has long had is the fact that it works across all three of the public clouds: AWS, Azure, and GCP. However, you had to choose which public cloud you wanted to use up-front — at least until late last month. That was when MongoDB announced multicloud cluster support, which lets companies run MongoDB across multiple public clouds at the same time.
An Interview with MongoDB CEO Dev Ittycheria
Shortly after MongoDB’s announcement I had a chance to sit down with Dev Ittycheria, CEO of MongoDB. We touched on all of the points I mentioned above: Atlas, cross-cloud clusters, competing with AWS, and the company’s controversial license change. As always, this interview can also be listened to via podcast in your favorite podcast player; get your feed here.
This interview has been lightly edited for clarity.
Topics:
- About Dev Ittycheria
- What is MongoDB?
- Open Source Business Models
- Atlas and Public Clouds
- MongoDB’s Go-to-market
- Investing in Open Source
About Dev Ittycheria
I’m here with Dev Ittycheria, the CEO of MongoDB. What was your path with MongoDB? Because in this case, you came on as CEO after it was already started. What’s the background there?
Dev Ittycheria: Well, first Ben, thanks for having me. The way I got to MongoDB was through a recruiter. But I had been an entrepreneur, I’d started two different companies and then I became a VC, I was a partner at Greylock and then I actually joined a smaller firm in Boston called OpenView Venture Partners. And what was interesting is being a VC in 2012-2013, I’d done some homework on the next generation database space, and actually, I’d looked at some competing investments to MongoDB. When I did my diligence, it became clear, even then, that MongoDB was way ahead of the other competitors in terms of developer mind share, the virality of the product, and even commercial traction. And so I ended up passing on those investments.
Meanwhile, MongoDB was based in New York, and I was based in New York, and literally it was in the spring of 2014, I got a call from the head of a recruiting firm who basically said, “You have to take a meeting with MongoDB.” Now I wasn’t looking, I was happy being a VC. In fact, I just made the investment in Datadog. And obviously Datadog has done really well, so I was not looking to leave the venture ranks.
That’s a nice one to drop. Congratulations on that.
DI: (laughs) Thank you. But obviously I knew of the company, I knew it was doing well. So I said, “I’ll take a meeting.” They’re in my backyard, might as well take a meeting, get to know the company a little bit better. I met the founders and met some of the board members and it became clear to me that they really needed some leadership to really help the company scale.
I knew developers loved the product, and as I did my diligence, I realized that there were lots of issues around the leadership team. There were lots of issues on their go-to-market strategy and the culture was also, I would say it wasn’t optimal. I knew I could fix all of those things and I always believed that you never bet against a product that that users love. That gave me conviction to join MongoDB and I joined MongoDB in September of 2014 and that’s how I ended up here.
What is MongoDB?
So, for the readers of Stratechery that don’t understand databases, what’s the high level elevator pitch for MongoDB?
DI: What MongoDB really offers is a different way to work with data, in fact, we think that we offer the best way for developers to work with data. The relational database, which is the standard architecture that every database has been built on since 1970, in fact, the first white paper on relational databases was issued in 1970 and Oracle was founded in 1977.
Yeah. Another IBM technology that they just gave away.
DI:Â Exactly, essentially basically organized data in tables, think of a relational database as an Excel spreadsheet on steroids. If you think about the constraints of that era, the biggest constraint was storage costs. Storage was incredibly expensive and so people wanted a way to store and retrieve data efficiently, and the best way to do that would be storing it in tables.
Fast forward thirty, forty years later, and essentially storage has almost gone basically to zero and the biggest constraint now for organizations is developer productivity and developer capacity. People want to use tools that enable people to produce great software and to innovate very quickly. The biggest constraint for organizations today is access to great developers that are a scarce commodity, and so you want to be able to get the most of out of your development capacity. Now, when you think about, “What are the biggest challenges that developers have?” the biggest challenge they have is working with data.
Essentially, what MongoDB does is allow developers to work with data in a very natural, intuitive way. I’ll give you a simple example. When you go to a doctor’s office, you show up and say, “Hey, I’m Ben Thompson”, they basically pull out your folder and in your folder has your name, what medications you might be on, the results of your last doctor’s visit, any allergies, et cetera, it’s all in one folder. They don’t go to different folders for your name, different folder for your medications, a different folder for what allergies you’re on, et cetera, et cetera. Everything’s stored in one folder. But relational databases essentially dis-aggregate data into all these different tables so it adds a lot of cognitive load for a developer to think about organizing data. Moreover, whenever you need to add new features and hence new data, you have to think about the data model and it becomes that much more complicated. So over time, this data model becomes incredibly brittle, so it becomes harder and harder for developers to innovate. If you ever talked to a developer, they’re invariably waiting for a schema change of their database to be able to keep a coding.
So what MongoDB does is essentially allow you to store data in one folder, we call it a document, which is much more natural and much more intuitive, and everything about Ben Thompson is stored in the document all the way from your name, to your contact information, to whatever medications you’re using, what are allergies you have, and any medical history that you may have and that makes it so much easier for developers, when they think about building apps, using this kind of data architecture.
The second big thing is that we are a distributed database so we give developers a lot of intelligence about where to store data, and they can store it for basic things like high availability. Our most basic configuration is what’s called a three node replica set. So, you have three copies of your data so invariably when there’s a system or network failure, your application never goes down. We allow you to scale your data, what’s called sharding, which is basically storing data across multiple machines or virtual machines in the cloud, so that you have elastic scalability which makes a developer’s life that much more easy. And then, what’s interesting, is we also give you a lot of intelligence about where to place data because with things like GDPR there’s all these data privacy and data regulations, so we’d even tell somebody if you’re capturing PII data say of a German citizen in Germany, you have to store that data in Germany and we allow people to tag data, and the database takes care of it. If the database didn’t take care of it, the developers would have to build so much complicated code to build that logic into the application. We save developers enormous time and effort, and that’s why we’ve become so popular.
Open Source Business Models
So, to what extent is the popularity, from your perspective — and again, you came in part way through so you may have a different perspective than maybe the folks that are there originally, and I’m curious about that — do you have a different view on why MongoDB became huge? And I’m starting to push towards the open source bit, could MongoDB have reached the level of success it did without being open source at the beginning, because it was such a new and better way of handling data, or was that as critical as anything else?
DI: I actually believe that MongoDB would not have been as popular if it was not for open source. Open source essentially allowed us, and our big difference with MongoDB versus other open source companies, most other open source companies basically take some prior art or they build some capability inside their four walls, but say it’s not core to the business. They say, “You know what I’m going to make this open source, and then let someone make it better” and basically use crowd-sourced R&D to make our product better. Then you might have some organization that takes that prior art and then builds a commercial business around it.
MongoDB was very different, there was no prior art to MongoDB, the founders basically started with a clean sheet of paper and built MongoDB. Our open source strategy was not crowd-sourced R&D, it was really a freemium strategy, basically enabling developers and users to easily get access to the code and be able to quickly build applications in a very frictionless way. The original strategy was then to offer commercial features around management and security, et cetera so that if you really wanted to run and manage your application, then you would buy the commercial features.
Right. Which is the very traditional open-source model. And I think, when I first wrote about MongoDB, it was when you were in a shift, and because that traditional model is great as long as the database is hosted on premises and companies need help with that, but it turns out there are companies that are willing to take care of all that trouble named Amazon in particular, but also Microsoft or Google, and I think that the challenge there, I wrote about MongoDB at the time, the real problem that needs to be solved is taking care of all the infrastructure. That’s what Amazon does and sells, and they sell reliability and so I think this has sort of get to the point where that’s when maybe the licensing started to not make as much sense. What was the process as you went through that transition?
DI: Right, we built a business and the challenge in that business model is we could only monetize certain usages of the product. If you’re just running a basic application that didn’t require the commercial features, there was no interest in the customer paying for anything and that was the trade off with an open source business model. What was interesting is when you offer open source as a service, a la through the cloud providers, you can actually monetize all the bits, not just the commercial bits. So even if you’re running a small instance, you’re still paying for something and the trade-off is that you don’t have to worry about provisioning, configuring, managing, backing up and updating your server, all that is taken care of for you. Now we saw this opportunity and we said, “MongoDB is really, really popular.” and one of the really smart things the founders did is the open source model that they used at first was AGPL, which is much more restrictive than the classic Apache license model. Remember, they were looking at open source as a distribution strategy, not as a crowd sourced R&D strategy.
Just for readers, the AGPL basically says everything has to be shared back, and that includes things that run as a service, whereas a more Apache model or an MIT model, you don’t have to share back changes and you can just take it and use it.
DI: Right, and so what became controversial was that the cloud providers, and not just the ones you mentioned, but even cloud providers in different parts of the world, would basically take the open source product, plug it into their management plane of the cloud platform, offer the technologies and service and not give anything back. We spent almost over $700 million in R&D, of which I would say half of that money goes to our free product, so we believe it’s patently unfair for someone to come and basically take all the benefits of our hard work and resources, and then not give anything back to the community.
So we made a structural change in 2018, where we basically changed the license model to be even more restricted with what we call SSPL. SSPL basically mandates that it’s still a free-to-use license, but with one exception, that if you plan to monetize an offering of MongoDB as a service offering, you can still do that, but then you have to basically open source not just the code but also the management plane so that anyone can take that code and basically also offer MongoDB as a service offering. We thought that that would be only fair and what’s happened since then is that our business has thrived. There was some concern in some circles, “Hey, this is not a sanctioned open-source license” — we did try and work with the open source bodies, but as you can imagine, some of them still needed time to think through all these issues and we felt this was really important. Our adoption never changed, in fact, just to give you a sense in 2020 our software has been downloaded over fifteen million times — that’s more downloads than we had in the first 10 years of the company, MongoDB has never been more popular than it is today.
What we also saw because MongoDB is so popular and because of our licensing model, that at first Microsoft and then later Amazon basically came out with clones of MongoDB, they call them MongoDB compatible document database, in fact Amazon’s document database is called DocumentDB (with MongoDB compatibility) and Microsoft’s offering is called Cosmos DB and they tried to emulate. The big difference is, unlike other open source products, say like ElasticSearch, where they can just take a free version and plug in their cloud, they had to simulate our capabilities, but on a relational backend. So they don’t support all features and they don’t deliver the performance we do, in fact they have about 30% of the features that we have. So when customers try these clones versus the real thing, it becomes very clear to customers which is the better product, which is why Atlas, which launched in 2016, basically got to over a $100 million in a little over three years, and now is a quarter of a billion dollar business and the fastest growing part of our business today.
So here’s the question I have: do you think MongoDB could have been as popular just on the features, or did it need to be open source? And you mentioned that being open source is really important, it let developers take it and try it and figure it out and it was developed in the open, and folks could feel good about using it in their products. Back then it was assumed every open source company would do this services sort of approach and now MongoDB I think has been extremely innovative and to MongoDB’s benefit with this new license model, where basically Amazon can’t just take it. ElasticSearch is a perfect example, to your point, they have to emulate it. I think they’re stuck back on 3.6, and you’re on 4.4.
DI:Â Four versions behind, yeah
So it was a brilliant move for MongoDB. Do you think if, maybe this is a hypothetical, so it’s hard to answer, but if you started with an SSPL-like license, which feels like open source, looks like open source, but I think the sense of the open source bodies is if you restrict anyone’s business model, that’s not open source, I think that’s the pushback — would it have been as successful, or do you think you needed to start out truly open and then have this closed down once it became popular?
DI: I’ll say a couple of things. First, you have to nail product-market fit, so it doesn’t matter what license you have, if you’re not building a product that solves a problem and it’s compelling for a user to use, it doesn’t matter what license you have. The founders really nailed product-market fit, and that’s what I discovered as a VC when I was looking at this space, that the popularity of MongoDB was way ahead of everyone else. And so that was point number one.
Number two is that yes, I would say in the early days of the company, there was this traditional bent of using sanctioned OSI, which is the open source body licenses, because then you were “an authorized open source company”. I think it would have been difficult to come out with that especially because no one really knew us, we were a small company, we didn’t have the credit rated track record. So it would have, I think, hindered our adoption in the early days. I think why it didn’t hinder us when we switched to SSPL in 2018 was that we had massive adoption, people who listened to us clearly understood why we’re doing what we’re doing. And if you’re a developer, whether you’re a developer in Silicon Valley in a garage, or a developer in Mumbai or Shanghai, you want a product that will help you solve a problem. So long as it’s free to use, there’s no constraints on what you can do with it, you can still look at the code, you can still modify the code if you wanted to. That’s all they care about, they don’t care about what variant of licensing model there is. What we really focused on was making the developers experience truly delightful and that was the underpinning of building our business and yes, what SSPL gives us is a strong motor on a business, so that a cloud provider can’t strip mine MongoDB and just run it on their cloud and not give anything back.
Atlas and Public Clouds
It’s been very interesting to see how you’ve been able to evolve since then. I think this week’s announcement fit in that. One of the things is you offer Atlas, and Atlas has been on all three of the major clouds for a while. It’s interesting because MongoDB actually gets to advertise more locations and more data regions than anyone else, because you’re on all three. And this week you had announced that MongoDB can actually run on multiple clouds at the same time, so instead of choosing Google or choosing Amazon, you can say, “No, I want to be on all of them.” Are you doing that in partnership with the cloud providers, or how does that relationship work?
DI:Â Well, to be clear, when we launched Atlas in 2016, the cloud providers were actually really supportive. In fact, we launched on Amazon the first year, and then we launched on Azure and GCP the following year, and they were really supportive, because they saw the popularity of MongoDB and they wanted to encourage people to move workloads to the cloud, obviously to their own clouds. They actually helped fund some of the development of Atlas and they were helping promote Atlas to the marketplace.
This is something I’ve written about too, and I think that people don’t realize, I know you’ve talked about this on your earnings call. At the end of the day, for these companies, the margin is going to go somewhere, and I think that there’s a sense that they can always undercut people on price on the platform level, but the reality is that that’s just taking the money from their infrastructure service. I think you get a situation where the infrastructure guys are happy to help whoever wants to sort of run on there and if the platform guys are competing with them, then that’s their problem, they have to win on the merits, and people don’t quite think through the economics of that. It makes total sense for Amazon to want you on there because you’re going to use a whole bunch of compute and a whole bunch of storage, and that’s a good thing for their business.
DI: And even more so, the customers using Atlas will ended up using lots of other services as well. So we estimate easily, they get a 5x multiple on every dollar spent with MongoDB, both through the consumption of incremental storage and compute, as well as other services that are consumed by service offerings to the cloud provider. After the second year, we offered customers to run Atlas on all the three major cloud providers. What we announced this week was something very unique, what we said is you can run now one application across multiple cloud providers. In the past you could say, “I’ll run an application A on Amazon, application B on Google and application C on Azure.” Now application A can run across all three cloud providers. Why is that important?
One, customers want some flexibility. They like the ability to have platform independence, they want to be able to choose where they want to run the cloud. Two, high availability. There’s many situations when certain regions go down and they want the ability to be able to run across different cloud providers in case one cloud provider goes down. For example, if you’re in France, you can run on AWS Paris and Azure Paris at the same time. We have Canadian customers right now who for example want to run Atlas, and Canada is running on Azure in Quebec City, Azure in Toronto, and then AWS in Montreal. So there’s a few big reasons. And then the third reason is that what we’re also seeing is the cloud providers differentiating among themselves. Some people may become stronger in machine learning, some people are stronger in serverless offerings, some people may offer better networking performance, et cetera. So what customers can do is by running an app across different cloud providers, they can pick and choose the services they want to leverage across the three different cloud providers. It gives them enormous optionality and we think from the customer first and why wouldn’t a customer want to do this? And so we’re the only cloud database that you can run one app natively across the three different cloud forms.
If you think about conceptually, you’re building an abstraction layer above all these cloud providers. So MongoDB or Atlas in particular is taking care of all that complexity, but I mean, all these cloud providers, they have their own lock-in, they have huge egress fees for example, once the data’s there, it’s hard to get it out. So is this just MongoDB pushing down to all of them and then taking care of that, just from a top down perspective, or is this a situation where you went to Azure, you went to Amazon and said, “Look, we can drive a lot more services to differentiate offerings if you help us out in a way to keep these in sync” or did you have go at it alone?
DI: We did do it ourselves. We obviously work in partnership with all different cloud providers, but we’d want it to take the integration risks off the table for the customer. We want to make it very, very easy for customers to migrate data, for customers to seamlessly manage an app across different cloud providers to basically provision new capacity if they’re seeing demand in the particular region very, very quickly. They may be primarily in one cloud provider, but because they’re seeing demand in another part of the world that where another cloud provider has a bigger presence, they can easily extend their application there. So we did all the heavy lifting to make that really easy for the customer. And we think that’s one of the real advantages of MongoDB Atlas is that we do provide the ability to abstract the complexity of working with these three different cloud providers. The irony is that a lot of people talk about multi-cloud, but no one really does it because the integration risks, everyone puts the onus on the customer to figure out the integration risks and the challenges of how to integrate the different services across the different cloud providers. We take that off the table.
Are you pricing this differently? Again, I’m just stuck on this. The way these cloud providers lock you in is it’s really easy to get data into them and it’s really difficult to get data out. So how do you handle that complexity without exposing yourself financially?
DI: Well, we do pass on whatever network charges the cloud provider so if you’re going to migrate the data from one cloud provider, and as you said, it’s free to move data in, it does cost you to move data out and so we do pass on those costs to customer. What we really take care of is all the operational overhead, because it’s not just the cost, it’s the operational-
Right, it’s the difficulty-
DI:Â Added complexities, syncing data across different regions, et cetera. All that backing up data, et cetera, is all taken care of by MongoDB.
A last question. You mentioned that something that the team needed help with at the beginning, it was go-to-market. You mentioned on an earnings call earlier this year that analysts still get stuck on the cloud providers being threats to you as far as a product perspective and you just don’t see that being the case and so the real issue is that folks don’t even know about MongoDB. They just go with whatever the default is or Cosmos DB or whatever, or DocumentDB, I think it’s in parentheses with MongoDB, compatibility or whatever Amazon calls it. Now that we’re two years down and you’ve made clear, you’re not going back on this license, MongoDB is going to continue to progress, it can really give a ton of usage even if it’s egress costs, how can you get more plugged into Microsoft and Amazon’s go-to-market, or is it something where you feel confident that over time you’ll keep building your own abilities there and you don’t need their help?
DI: No, we do partner. Actually, so I’ve had one-on-one meetings with Andy Jassy, with Thomas Kurian, with Scott Guthrie, all the leaders of all the three cloud providers. They know that we’re an important partner to them, so they do listen. In fact, they themselves see the growth of Atlas because they see the growth on their cloud platforms, so they’re devoting more resources dedicated to partnership. They’re devoting more marketing dollars to promote customers to get on the platform. Frankly, they’re also incentivizing their sales people to work with us more because they’re a net beneficiary of our growth. So even though we may compete on the database here, they’re a huge beneficiary on all the other services that we offer. Essentially it’s that old cliche term, it’s a spirit of coopetition.
The thing that we worry about is the deals that are happening, that we’re not participating in, because obviously these cloud providers have massive reach, they have much larger sales forces. A customer may naively just pick the default option that the cloud provider offers without really realizing there’s other alternatives. But that being said, when we went public in 2017, there were real questions from investors about could we really build a meaningful cloud business, going head to head with these massive cloud providers that have enormous resources and brand and technical skills? I think we’ve proven over the last three years that we were able to do that.
Candidly, I think Snowflake has also proven that they’re not an open source company, but they’ve also proven that when you have a best-of-breed platform, we’re both companies going after large markets encumbered with legacy technology. Customers are basically saying that they want to focus on differentiated work, not undifferentiated work, so they don’t want to be in the business of managing and maintaining their infrastructure, they want to at least in our case be able to deploy dollars to enable their developers to innovate more quickly, add new applications, add new features very, very fast. They want the flexibility of multi-cloud because they want to be able to move workloads, pick and choose whether they want to run apps. And while it’s also interesting, the most valuable part of the infrastructure layer is around data. And so I think, we’ve basically proven that over the last three years that you can build a meaningful franchise even while competing with the cloud providers on their platforms.
Yeah, that was my takeaway too. I think that when I was writing about the infrastructure versus platform bits with Snowflake, if you think through these economics, just on a theoretical level, there is going to be a separation there. I think these companies are so large and at the end of the day are so predicated on scale at the infrastructure level, that their motivations are always going to be to support the infrastructure side over their platform side, which means it is definitely possible and viable to build a platform business on top of their infrastructure and be successful doing so. I think you guys have demonstrated that.
MongoDB’s Go-to-market
You mentioned you wanted to add one more thing on the go-to-market bit.
DI: Yeah, so I would say that three ingredients of our success have been, obviously, the product-market fit of MongoDB. The licensing model that allowed us to build a real cloud business. And the third would be our go-to-market strategy. I cut my teeth in my career in the nineties, as an early employee and what I saw in those days was that even if you had a great product, all the large tech vendors had such amazing account control. That was very hard to break through and be able to sell a better mousetrap because the IBM’s and the HP’s and other large tech companies just have these enormous account control and most decisions were made top down. So what I realized was that in order to build a really strong business, not only do you have to build a great product, but you have to have a built a really strong go-to-market, where you’ve had a very aggressive and tenacious sales force that just wouldn’t give up and had a tremendous amount of grit. At Bladelogic, we showed that because even though in those days, the numbers were smaller, we built an amazing sales force, had a great product, and I think there’s probably been 40 plus CRO’s that have come out of the Bladelogic lineage.
What’s interesting with MongoDB is that we’re going after such a big market, we just could not use one distribution strategy. We’ve built a great field organization, but we realized this market’s so large that we should also build an inside sales team because there’s a lot of customers, small customers, where it’s too expensive to send someone to go visit them, or maybe fly to visit them and that you could actually conduct business over the phone or over the web. So we built an inside sales team that’s now become really successful. Then we actually also built a self-serve business because as we spent time with customers, a lot of developers hate being sold to, hate being marketed to, they just wanted a very frictionless way of engaging with us and Atlas allowed us to provide a self-serve offering and there was some features that you literally could play with Atlas. We found that not only did small companies like that but even developers of a large bank, for example, would use the self-serve option to play with the product as a precursor to doing a large project with MongoDB.
And then last but not least, we have our partner team, that actually works to expand our reach by working with larger size, working with the cloud providers themselves, working with ISB’s who are embedding MongoDB as part of their core product, and really enabled us to reach the market indirectly. What’s really been helpful to us is that we’ve been very thoughtful about how we go-to-market with these four different channels, which at some level is quite complex for a company of our scale, but it’s worked really well for us because we were very thoughtful about why we wanted to do what we wanted to do.
The point about the self-serve is very interesting, in part because one of the reasons to do an open source business model is “Oh, developers can just take it and try it out”, et cetera. But the reality is it’s still they could take it and run it on their local machine or whatever it might be but part of the whole benefit and aspect of MongoDB is the fact that it can run across multiple instances, it could be distributed in all the bits and pieces that are hard to experience without having a massive distributed back-end on which to run it. So the Atlas freemium version is almost like a spiritual successor to the open source ideal of just grab it and run it. But even though the model is totally different, you’re using the closed version, which MongoDB is operating, the spirit is the same and I think that captures a lot of the shifts that you guys have done. Yeah, the specifics are a little different because they have to adapt to a new era, but the idea and the ideals behind the way it used to be done are still valuable to figure out how to adapt that to the cloud era.
DI: Yeah, that’s well said. The other thing that we’ve found, actually, is that yes, the customer might be using our self-serve just fine, but when we come in — remember, we’re offering a new mousetrap, we’re offering a new way to think about working with data. So invariably customers are going to make mistakes because they’re not going to be experts in MongoDB. They may have a relational mindset and trying to model data like they would in a relational database and we can see product signals, we can see queries, not performing optimally, or suddenly there’s a spike in usage. We can very quickly see there’s something going on and we quickly come in and try and get a sense of, “Hey, what are you doing, and can we help making sure you’ve optimized MongoDB the way that you can get full value of the technology?” And customers love that. So what’s interesting is that the different channels to become a flywheel effect, self-serve becomes a massive lead generation for us and then our sales people can cherry-pick the most important self-serve customers who show the most upside growth and then we help those customers not only be successful, but then they come back and consume a lot more. That’s worked really well for us and I think you’re going to see a lot more of that business model get promulgated not just with open-source companies, but also with SaaS companies, as well.
Investing in Open Source
MongoDB had to figure a lot of stuff out, I think the license change was absolutely brilliant, I can understand why people got mad about it, but I think it was a company-defining moment and looking back — do you think this is a viable path now for open source companies going forward? Start out with a truly open license, change it once you want to build it as a service. Maybe your first business model is the professional services model like you folks did, then you shift to the service one. Is this a viable strategy going forward? Do you think that developers are going to be turned off because they know the switch is coming? Or do you think that this might become an accepted way to build an open source company?
DI: Yeah, I would say a couple of things. One, obviously, as I said, you have to nail product-market fit. Licensing doesn’t matter if you don’t have anyone using a product. So one, you have to nail your product-market fit, that is table stakes. Second, is if you do start off with another open source license, you have to understand that some open source license, you cannot go back and change, right? With a more permissive license, you don’t own all the IP rights, the contributors maintain their rights to the IP that they’ve contributed back to the open source community. Where with AGPL, 99% of the code was written by MongoDB employees but there were instances when some people contributed back, but if we were going to accept the contributions, the trade was that they had to assign the IP rights back to us because we wanted to control and have ownership of the IP in order to be able to move fast.
It’s very interesting because GPL has among some engineers, particularly in large companies, a bad reputation because they’re like, “Oh, it’s too controlling” et cetera, et cetera. I’m not sure if Richard Stallman was envisioning the MongoDB approach, but the fact that it forces you to give everything back and the strictness is to your point, it’s actually what’s kept MongoDB in the game up until that point.
DI:Â Right. What we did was then because we owned the IP, we were just like any other commercial software company. We could change the license rules because-
Yeah, it’s your product.
DI: Microsoft updating their terms of conditions to use Windows or Excel, et cetera. We were able to convert from AGPL to SSPL, and we do believe in open source, we do believe that’s important for our industry. It’s important to encourage this movement, but we also don’t want to be taken advantage of, and that’s why we made the change. I think someone like Elastic, if you saw what Elastic had to do, they had an open source version, but then they had a free version and then the free version was rate limited, and then once you hit the limit, then you have to go to the paid version. So they essentially stopped innovating on the open source version and started doing all the innovation on the paid version. What Amazon said was I’ll take your open source version and embed all the capabilities of building through the free and paid version and then fork the code and now they’re in a kerfuffle about trademark rights and so on, so forth. So that, we didn’t have to deal with and we can just stay focused on-
What I mean though is, I think we’ve recounted what MongoDB did, but do you think that if you were back at Greylock and you’re doing venture, is this something where do you think that more and more startups going to look at MongoDB and say, that’s the path we’re going to follow and and maybe the SSPL is going to become an industry standard or something similar, even if it’s not accepted by OSI, just because it’s the way to build these venture scale businesses on open source?
DI: Yes, I believe that’s the case. I think people have seen the challenges of building a meaningful software business with a very permissive open-source license. Whether you use SSPL or get inspiration through their own license, which is some derivative of SSPL, I don’t know what people will do, but I’ve gotten a lot of calls from venture capitalists. One, they’ve been watching us, and obviously someone had to make the move, and they were in some ways biting their fingernails, saying, “Oh my goodness, let’s see how this plays out.” because it was pretty nerve wracking. It’s always the first mover who can potentially get all the blow back.
You took a lot of arrows. A lot of arrows, for sure.
DI: But when someone spent the time and listened to us, they said, “Of course this makes sense.” I mean, obviously you had some customers who call saying, “Hey, is this a problem?” And when we explained to them, they’re like, “This makes complete sense. We have no issue with this.” I think as this become more and more well understood, I think it’ll surprise me if we see a lot of open-source companies get funded with a very traditional open-source license because of the challenges of what’s happened in the past.
Yeah. It makes a lot of sense. Well, I know that licensing talk is hardly the most interesting thing in the world to talk about, but I appreciate you diving into the weeds with me. I’ll say it for you, I think MongoDB is going to go down, not just as a great company, obviously your stock price and your adoption shows that product-market fit and how good the product is, but I think it will be memorable for pioneering a new way for open source. Again, people want to put open source in quotes around that because of the changes, but I agree with you. It makes lots of sense and I think it’s a good thing for the world, because that means more funding and more sourcing for these sort of products that ought to exist, and ought to be available to developers. Congratulations to you and I appreciate you getting into the weeds with me on that.
DI: Thank you, Ben. Well, I have to say it was a team effort, so I can’t take all the credit.
Well, the royal you, as it were.
DI:Â Thank you.