MongoDB ft. Dev Ittycheria – How an Early Pivot Catalyzed an Open Source Movement

Contents

Dwight Merriman: We could see the writing on the wall. In other words, the hyperscalers were going to offer their own Atlas-like things based on the MongoDB source code. It’s almost 100% chance that would happen. If they did, it would be kinda like game over. 

Introduction

Roelof Botha: Welcome to Season 2 of Crucible Moments, a podcast about the critical crossroads and inflection points that shaped some of the world’s most remarkable companies. I’m your host and the Managing Partner of Sequoia Capital, Roelof Botha. 

In 2007, Dwight Merriman and his co-founders identified a problem: the databases of the pre-internet era were not built for the scale of modern applications. New internet companies that were exploding in growth would regularly crash and go dark because their databases failed. 

The world would need a next-generation database. 

Today, MongoDB, a document-based database solution, generates nearly two billion dollars in annual revenue and powers thousands of companies worldwide, including many of the apps at your fingertips. 

However, back in the early days of the company, there was a question mark about whether MongoDB could translate early traction with developers into a sustainable business. 

In today’s episode, we’ll look at MongoDB’s early decision to drastically reduce its scope and pivot from a platform to a single product. 

We’ll learn how the company migrated its business model from open source on-prem software to fully managed cloud services. And we’ll hear how it gambled on a change to its licensing model that risked community and user revolt. 

Dwight Merriman: My name is Dwight Merriman. I am a Director at MongoDB and one of the original founders of the company.

How did we get started with MongoDB? Why did we want to do it? What was on our mind at the time? I’d worked on a lot of startups. I was Co-Founder of DoubleClick in 1995. And then after 10 years at DoubleClick, decided it was a good time to maybe do something new. And myself and Kevin Ryan, who was CEO of DoubleClick, and Eliot Horowitz, who was one of our most senior engineers there, we were all interested in doing a startup as our next thing.

We started brainstorming some ideas for startups and we would see the same issues coming up time and time again on the tech side in terms of the design development of these systems… issues around maybe scaling, issues around just other ways systems are maybe fragile. 

Cloud computing was very new around this time period, and there’s a lot of properties to cloud computing that are important. You scale horizontally, not vertically, and a lot of our traditional tools including programming languages, but also databases, they weren’t really designed for this. 

We felt like, can we come up with something that’s a better way to build systems and apps than the way we’re doing it right now? 

The original idea of the company, which is now called MongoDB Inc., originally was called 10gen, was to basically create a platform as a service system, an open source platform as a service system, with this whole new stack of modern things that we thought were appropriate for that point in time, in kind of evolution of software development. So, that’s what we were doing. So, we had new stuff, we had new ideas, concepts and tools at the application layer. And then, we had written our own data layer, which was called MongoDB. It wasn’t a product. It was the name of that subsystem. 

Roelof Botha: For decades, dating back to the 1970s, applications were powered by relational databases. Companies like Oracle and Sybase commercialized these databases that harnessed a query language called SQL. 

And if you want to think about it, a relational database is really structured rows and columns. And there are many different stores of those. You can almost think of them as a spreadsheet, and there are many different tabs to the spreadsheet. I mean, it’s a very simplistic analogy of that, but the relational database has that kind of a structure.

And they’re incredibly powerful. These transactional database systems powered so many of the applications that we built in the 1980s, the 1990s. The challenge was that with the advent of the internet, the scale of applications just grew beyond what those technologies were originally built for.

And I experienced this firsthand first at PayPal and then at YouTube, where the thing that caused the site to go down in both cases was the database. And in the case of PayPal, we were built on Oracle originally. And I remember we had these DBAs, Database Administrators, who were these magicians, these wizards, that would do tuning of databases, which I still had a hard time wrapping my head around. You tune a musical instrument, it seems like technology shouldn’t be that fickle. But they would tune the databases and do things like sharding, which is this approach of trying to break your database into many smaller databases so that you can string together many of them to serve the scale needs of internet companies that had millions or tens of millions of customers.

But fundamentally, the database wasn’t built for that scale. And so, often, PayPal would have outages because the database just fell over, it just couldn’t cope with the scale that we needed. 

The NoSQL movement

Roelof Botha: Dwight and his co-founders designed their data layer, MongoDB, to address these shortcomings. It was a database built for the modern internet era and notably, it didn’t use SQL. MongoDB would be at the forefront of the “so-called” NoSQL movement. 

So, if you recall earlier, I talked about how the relational database solutions are rows and columns. Think about MongoDB as really having the document as the central unit.

And so, one analogy that I always like to think about is an invoice for a transaction. If you had an invoice for a transaction, it would have the date, the item being purchased, the taxes that were charged, the customer, the customer’s address… all the details were encapsulated in that single document. And you could reconstruct the financials of a company if you assembled all those invoices ’cause you’d have all the underlying transaction data. 

And so, you can think of MongoDB as building that document as an invoice. And when you do that, it’s really flexible. Because if the tax rate changes, you can just easily add that to all your future invoices. Whereas with the legacy relational systems, it was actually technologically very difficult to go and add new fields over time.

A solution like Mongo would make it flexible and very easy for developers to build applications.

Dwight Merriman: So, we made the decision, okay, we’re going to do platform as a service. We have all these various details to our plan, we start writing it and the name of the company is 10gen, and that’s the name of the platform as a service product. We start building it and within, say, 12 months, we release it as a beta. Things were going pretty well. People were signing up to use the beta version and the feedback was good. What happened was, about the same time we released as a beta, Google released App Engine as a beta. 

We had no idea it was coming. It was released. All of a sudden, it’s like, oh, this is interesting. Like 10gen, Google App Engine is conceptually very similar. 

We had a little family vacation. So, I had my laptop with me so I could work every day even though we’re not home and they’re out playing. So, I’ve got some time to think and kind of get out of the day-to-day frenzy of minutiae and then think about the big picture, right?

And as I started thinking more and more about it, I started to realize that the scope of the problem was huge. We knew the scope was big, right? But, even bigger than we thought. For you to really be able to do everything on this platform, it takes a long time to build and you’re going to need a tremendous amount of runway… and I think it’s more runway than a startup’s going to get. 

It’s like, if you’re the VC and I come in and I say, here’s our concept for platform as a service. It’s going to take us 10 years to build this, and you’re going to need a billion dollars. It just seemed like, that’s not gonna fly. Maybe platform as a service makes sense, but the companies that need to do it are ones who can afford that runway and have a very long-term thinking like a Microsoft or maybe like Google.

So, after going through this line of thought on platform as a service, it’s like, okay, what should we do? We need to reduce scope. What should we do?

Roelof Botha: MongoDB, then 10gen, faced a crucible moment. A year into building, despite positive user feedback, they began to feel their initial vision was doomed. And so, the question was, do you scrap your original business plan, the majority of your code and pivot to a smaller scope? And if so, what exactly is that new scope? 

One thing that was interesting once we got into beta with the product is that people actually said, oh, I really like this database thing as they’re using the whole platform as a service.

So, we were getting some very nice feedback on the data layer. So, this got me thinking maybe this database, this is a thing and we could focus on it and just scrap being platform as a service.

Dwight Merriman: I think the term crucible moment is a really good one because it’s a big decision, right? It’s kind of a curious story because usually when you do a pivot as a startup, something bad is happening, right? But that wasn’t our situation. So, it’s much more difficult to do that. If we started doing database only, and it didn’t work, there was no going back to a platform as a service. We would have figured out 18 months later it wasn’t working and then it’s too late.

Scrapping the platform for the database

The first person I talked to about this was Eliot. So, co-founder, CTO, super smart. And we go talk in our little tiny conference room and I laid this out to him, it’s like, okay, I propose that we throw away our entire current business, which is in beta and people like it and do this other thing instead.

He kind of looked at me like I was slightly crazy for a second and paused and didn’t say anything. He said something like, let me think about it. We met back up an hour later and he said, okay, he’s like, I think this is right. We should do it.

So that’s kind of amazing. When you say, I’m going to take a business plan, I’m going to rip it in half, 99% of people would not have reacted like that. 

And then, the third founder of the company, Kevin Ryan, he was very pragmatic, I think, about this. So, he was kind of like, “well, I’m kind of shocked you’re saying this, but if you guys both agree that this is a good idea, then let’s do it.” 

Was this stressful, emotional? Was it scary? I would say the answer is yes. I think it’s even more scary because we’re doing this very proactively.

We may be killing something that would have worked. So now, if the new one doesn’t work at all? Boy, that was maybe one of the dumbest things ever done. And it’s emotional. When we did this, we threw the app stack, the app layer code in the trash and we started writing drivers, but then, we also had a few people who, they weren’t working on the database layer at all and I laid them off and that feels terrible. 

So, it was a big deal. 

Roelof Botha: In psychology, there’s this term called commitment and consistency. And we all experience this in various forms where once you’ve made a certain decision, the instinct is to remain consistent with that decision. So, that’s why they call these commitment and consistency processes. And letting go of that is, it’s traumatic, it’s difficult. And I think, if you’re a founder in particular, when you had a vision of something you wanted to build and the thing you’re building now is… even if it’s similar, it is significantly different from what you originally set out to do, I think it’s emotionally taxing.

The thing for which you raised your seed round or your series A financing, you’re now telling a different story to those investors. You think about the first few people who joined your company who joined with an expectation that you’re building a particular product and now you’re telling them it’s something slightly different.

But, I also think the founders that end up building truly successful companies are able to get through these difficult, crucible decisions of letting go sometimes of a wrong idea, sometimes letting go of the wrong hire. And as we’ve reflected on success across our experience at Sequoia, the speed with which founders are willing to make these difficult decisions is one of the best predictors of ultimate success. 

Dwight Merriman: So, when we made this pivot decision, okay, what’s the first thing we need to do? The first thing we needed to do was basically just write a bunch of drivers for every programming language so you could talk to the existing database we had already written.

So, we had this database, but it only worked within the platform as a service stack, within the 10gen stack. That was the only way to use it. So, we just kind of pulled it out and then we made database drivers for all the popular languages. And then, you could use it, right?

Roelof Botha: In 2009, MongoDB launched for public use. 

Dwight Merriman: The product was open source, so we were really trying to execute an open source, go-to market plan. By being open source, we’re going to get a lot of cheap or free marketing. So, we’re going to every meetup group we can and giving demos of the database.

In city X, we go to the Python meetup group and we do a demo, a MongoDB from Python. And then, we go do that in 10 cities for the same equivalent group in that city. We tried to do that for as many languages as we could. And then, in addition, we started doing a lot of conferences city by city.

We did Mongo SF and we did Mongo SV and we did Mongo NYC. And then, we started to do Europe and Asia. And that was really how we were approaching the go-to market. And at the same time, this notion of NoSQL kind of came out of the woodwork. It’s like the big companies, you know, Amazon, Microsoft, LinkedIn, Netflix, Google, they had all internally built some sort of NoSQL database, but there wasn’t much out there that anyone could use.

Roelof Botha: In 2010, we intersected with MongoDB. It was immediately obvious that they were the likely winner in this new category of these NoSQL solutions. They had developer love. The references were very positive. The number of downloads the company was getting for its database solution was growing very quickly, month over month. It was still a tiny company. At the time that we invested in MongoDB in late 2010, they had 12 people. There were 12 employees at the company, but there was something magical happening. And we immediately went to a rush to close the financing and become the new lead investor.

Launching as MongoDB

Roelof Botha: In 2013, the company officially changed its name from 10gen to MongoDB, a reflection of its successful pivot. 

Dwight Merriman: From day one, my background… I was a CS major in college. I loved programming and when I was CEO at MongoDB, I was spending some fraction of my time, like one third to one half, coding. Or designing things.

You can go in GitHub. If you go all the way back in the commit list, you’ll see a bunch of commits for me. And then over time, it goes down because as the company’s growing, other work that the CEO has to do takes a lot of time. So, I very much wanted to get someone else to be CEO quite early on.

Roelof Botha: In the middle of 2014, the company’s revenue run rate was approximately 40 million dollars. The company was doing well and the CEO was performing well. And yet, we, as a Board, felt that there was an opportunity for us to hire somebody who was both a former founder, who was deeply technical himself, who had led a public company before and had seen scale and would be able to help us move MongoDB from a 40 million per year business to a multi-hundred million dollar a year business.

Dev Ittycheria: One of the jokes I have with my friends is, when you get called for a CEO role, the first question you’re trained to ask is, “what’s wrong” because no one makes a CEO change when things are going well.

My name is Dev Ittycheria and I’m the President and CEO of MongoDB.

Prior to joining MongoDB, I was actually in venture investing. I was a partner at Greylock Partners and I had recently joined a small venture firm out of Boston called OpenView Ventures. 

And I had done a lot of work on looking at next generation databases. And I looked at a number of competing investments to MongoDB and I ended up passing on those investments. 

When I did my diligence, it became clear that the level of developer traction that MongoDB had relative to the opportunities that I was pursuing was significantly better. I ended up passing because I didn’t want to invest in the second or third player in the space. 

That’s how I got to know MongoDB.

I was happy as an investor. I felt I was doing quite well. And then, out of the blue, I got a call from a search firm that was leading the search for MongoDB for the CEO role. 

Roelof Rotha: Dev, he’d been a founder more than once. He successfully founded a company and led it as CEO through the IPO and through a successful acquisition. He had been a general manager in a significant role in a large public company, which gave him experience at scale. Having somebody like Dev, who is demanding and supportive of his team and would hold himself and his team accountable, those are just wonderful attributes around which to build. 

Dev Ittycheria: I had a lot of people who, when I talked to them about joining MongoDB, were quite skeptical that MongoDB was going to be a good decision.

As I met with the Board, I met with the management team, I learned a couple things. It was clear that the company was generating some momentum. It was clear that MongoDB had meaningfully more developer traction than some of the other next generation databases that I had looked at, but the company was also struggling. 

Yeah, it was badly missing plan. The leadership team was somewhat dysfunctional. The go-to market efforts were not very effective. And so, you might ask yourself, so why did he consider joining the company? I asked myself the question, if this company is doing well with, essentially, not a very good team, a lot of dysfunction in how decisions are being made, imagine what this company could do with an A-team in place. So, it was somewhat counterintuitive, but I decided that it was worth taking a risk.

Roelof Botha: When Dev joined MongoDB as CEO, the company offered open source, on-prem software, meaning it was downloaded and operated by developers. However, MongoDB began to see more and more users accessing software as a service directly through the cloud. Offering on-prem software in an increasingly cloud world began to pose a conundrum. 

One of the strategic challenges we faced at MongoDB was that many of our customers were taking our database and building applications and deploying it on cloud infrastructure on their own. But at the point that they started to run and operate their database, they didn’t have an ongoing relationship with MongoDB. And often they’d run into challenges. Maybe a database was misconfigured or maybe they didn’t make use of all the potential capabilities that we had, but because we didn’t understand how they were using the product, we couldn’t help them.

And then, from a business point of view, because we weren’t operating their databases on their behalf, we were missing out on an opportunity to build a business around the cloud delivery of our solution.

Dev Ittycheria: We realized that if we could offer a cloud service, by definition, we would be able to let customers outsource all that undifferentiated labor and really focus on the things that really and truly mattered. So, that was the catalyst for thinking hard about Atlas. 

Moving to the cloud with Atlas

Roelof Botha: The company began considering a wholesale move from downloadable software to a fully managed cloud-based solution called Atlas. 

Dev Ittycheria: I will tell you that there was a lot of skepticism because we were the first independent company to try and offer an infrastructure service on the cloud.

This is pre-Snowflake, pre-Elastic, pre-Confluent. So, it was not exactly viewed as a slam dunk to consider doing this. Could we really execute on this? 

Roelof Botha: Just knowing that you needed to build a cloud offering, it’s easier said than done. We had to go from being a company that shipped a product that people downloaded and used on their own, to building the operational skill set ourselves to be able to operate databases on behalf of our customers.

And I think downstream changes are often underestimated by people as they undergo crucible moments or key strategic decisions like this.

Roelof Botha: MongoDB had a decision to make: How should it adapt to an increasingly cloud-based world? If the company were to shift from downloadable open source software to a managed cloud service, could they actually manage that transformation? 

Dwight Merriman: I thought if the company didn’t pursue Atlas, that would be a giant mistake, kind of borderline disaster. There were issues with the business. It is a change. We needed to do it. 

Roelof Botha: There was a real risk that if we didn’t successfully develop a cloud strategy, that would lead to our ultimate demise.

And so, it’s with that spirit that we recruited Tom Killalea to the Board of the company.

Tom Killalea: To be honest, I said to Roelof, “I’d love to serve on another Board with you, but this may not be the one.” 

My name is Tom Killalea and I’m the Chair of MongoDB. 

Roelof Botha: Tom had been a key executive at AWS. He was originally the CISO, the Chief Information Security Officer, of Amazon and then, had been part of the team that built AWS in the early days. And so, here’s somebody who had firsthand experience and knowledge of the biggest cloud service provider on the planet. And I thought that his experience at AWS coupled with the opportunity at Mongo was a perfect marriage. He wasn’t too keen initially. 

Tom Killalea: My big concern related to product positioning. I felt that there was a danger with any persistence offering and presenting Atlas as a jack-of-all-trades. I had a deep sense that one size does not fit all. A very highly optimized around a single use case approach that AWS in particular was taking may win out. 

Roelof Botha: Tom lives in Seattle and MongoDB is based in New York, but I convinced him to take a meeting with the team. 

Tom Killalea: I did fly out to spend time with the engineering team and it turned out that I was flat out wrong. I became convinced that, in fact, there were huge advantages to the product positioning and the approach that MongoDB was taking with respect to building a data platform that would serve many different use cases and would obviate the need for you to extract and shift data from one platform to another in order to get your job done.

And so, I said yes.

In December of 2015, my first Board meeting, the essence of the debate was not do or don’t do, but do now or do later. That was the biggest danger that sort of wait and see, versus, let’s charge into this and make it happen. 

I was very much on the side of, we need to act now. 

You have to seize the opportunity of a lifetime during the lifetime of the opportunity. You can be too early, you can be too late, but when you see that the timing is right, you really have to move with very significant urgency.

Roelof Botha: The team decided to give itself a deadline of June 2016 to launch the platform at the MongoDB user conference, Mongo World. An aggressive timeline of under six months.  

Dev Ittycheria: So, one of the key strategies to really ensure that Atlas was successful is, we have this saying of a startup in a startup. We ourselves viewed our whole business as a startup, but we said that we are actually starting a startup within a startup. So, all the care and the tension that we put in our core business, we wanted to make sure that Atlas had the same amount of focus. 

Tom Killalea: Some of the harder and more frustrating topics were around the product roadmap between now and launch in June, figuring out what was actually feasible, entertainable, and rationalizing the things that would have to be left out. People and the muscles that had to be built up in the company that weren’t there. So, for example, site reliability engineers in the company, getting to truly understand what it would take to operate people’s databases for them and have it be completely transparent and have them not have to worry about the care that we were taking with respect to that operation.

Assigning a directly responsible individual

Dev Ittycheria: We assigned a Directly Responsible Individual, what we call a DRI, who really would be the person who is really focused on building and growing the Atlas business. That meant not only working with our engineering and product teams to ensure that we were building all the features in the right way to ensure Atlas was successful, but also working with our go-to market teams.

Roelof Botha: We had to build a skillset of marketers, where you’d have to manage a funnel of people going through your own sign up flow and understanding how people converted and what is your free tier and how do you upgrade people to pay plans and how do you change your compensation scheme? Because your salespeople are now selling a completely different product from what they’d sold before.

After a whirlwind six months, Atlas launched on June 28th, 2016. 

Tom Killalea: My abiding feeling was, it’s great that this has happened, but this is the start. There was so much that had been left out of the product. The work was very much underway and the engineering and product teams were remarkably focused on the next release. A launch is just a day and a key aspect of it is getting the word out to the world, but you end that first day with a number of customers that rounds to zero.

Dev Ittycheria: One of the challenges of starting a new product offering is that the numbers are so small. No one really cares if you hit or miss your numbers because it doesn’t really move the needle for the rest of the business. 

So, our business at that time was roughly a hundred million dollar run rate business and Atlas was essentially starting at zero. So, the risk is that, will people in the organization really care about making sure Atlas was successful?

Roelof Botha: Dev did something very important, which is to isolate the metrics and numbers of Atlas and spotlight them completely separately with his team and with the Board so that we had a proper appreciation for the scale of it and how it was growing and avoiding it being drowned out by the scale of the business we had already built by then.

Dev Ittycheria: We launched Atlas in 2016 and we went public in 2017. 

The memories I have of people raising concerns about Atlas really happened when we went public. 

Roelof Botha: It’s a pretty daunting challenge to take a company public in the midst of this kind of a business model transition.

On the roadshow, many public investors wondered why we’re making the investment in Atlas and who cares about this thing that’s only two or three percent of the company today? 

Dev Ittycheria: They said, “wait a minute, how are you going to partner and compete with the hyperscalers? They’re going to eat you for lunch.” That was one question.

Two, there was no analogs of other companies who had been successful doing that. Three, some of our own salespeople who had not been successful selling Atlas really wondered if this was more of a low-end solution, maybe focused on the early stage of the market. But large enterprises who are late to the cloud, would they really buy something like Atlas because of all the security concerns that people would have about running workloads in the cloud? 

We basically went through the work of knocking down all these potential objections and focused on building Atlas, but there was clearly a lot of concerns across different stakeholders about whether or not we were going to be successful.

Tom Killalea: There could have been an argument for, okay, given how central the Atlas cloud offering is to your strategy, doesn’t it make sense to wait a couple of years before you go public?

We decided that the time was now and it was appropriate, especially with what we were hearing from investors and from bankers in terms of the centrality of the cloud portion of our revenue to embrace the moment now, to go to the public markets now. And at the same point as I discussed with the launch of MongoDB Atlas, the IPO day is just a day. And the next day you’re back to work and you’re trying to sell product, you’re trying to build the next feature, you’re working out operational issues and you carry on… And you’ve been through a funding event, but the world moves on.

Dev Ittycheria: A seminal moment happened in 2019 when Amazon launched a competitor to Atlas called DocumentDB. Investors panicked and said, “oh my goodness, they have a clone of your product.” Our stock took a beating. We went down 15, 20% on the day of that announcement.

So, there was a lot of concern. And my statement to the investors that time is that, in some ways, AWS is validating Atlas, it’s validating MongoDB, because the fact that AWS is launching a document-based database as a service is telling the market that document databases are here to stay and that you can run mission critical workloads on document databases.

And if it’s a comparison on which product is the best document database, we felt really good about our value proposition relative to the clone that AWS has built because we knew architecturally it had a number of issues and it didn’t have the features and the performance that Atlas could deliver.

And that’s essentially what happened. Just to put things in perspective, it took us about 10 years to get to a hundred million in revenue. And it took us five years later to get to a billion dollars in revenue. And a big part of getting to a billion dollars in revenue was the fast growth of Atlas.

How Atlas changed MongoDB

Roelof Botha: Today, Atlas represents 70% of MongoDB’s revenue. It’s north of a billion dollar run rate business on its own. 

Tom Killalae: Atlas changed MongoDB in that the motion for how you interact with your customers changed. It became far more about a relationship. Dev went through a process of both helping the company to understand what great operations means. Also, what does customer success mean? And what is it that you do today that will cause a customer to say,  

Dev Ittycheria: If anyone’s contemplating tackling a project of something of a similar scale or size to Atlas, I think my advice would be the following: focus on your customers needs and what they really want, what their buying behavior may be. And for us, we noticed that their customers’ buying behavior was changing from buying infrastructure software to consuming it as a service.

Understand what are the points of friction that prevent your customers from buying and using more of your product. Our traditional open source model had limits in terms of how fast we could grow and the only way we thought we could remove that friction was by offering Atlas. Be very clear on what you need to do and what are the associated risks.

Are all your stakeholders aligned? Are they all incentivized to make sure that this project is successful? Do you have the right single-threaded leader, what we call our Directly Responsible Individual? Do you need to get people to disagree and commit? Because some people may be skeptical, but you need everyone’s commitment to make it happen.

Are other stakeholders, like your Board, involved because there are potentially financing implications, margin implications by launching a new business or business with a different business model? So all those things are factors that you have to consider when you contemplate a decision like this.

Roelof Botha: As Atlas took off and the market became increasingly aware of the company’s unique cloud database, its success exposed another vulnerability.

After MongoDB had already gone public, by 2018, we were starting to worry that the big cloud service providers would test the limits of the AGPL license.

Dev Ittycheria: So, in open source, there are a variety of different open source licensing models. And for people who are not familiar with this, they might be surprised at the number of variations of licensing models that do exist. MongoDB was initially built on the AGPL licensing model, which is a bit more restrictive than the GPL or Apache license model.

And stepping back, most open source licensing models are designed to induce the public to help contribute to the building of the product. So, you want people to look at the product, make enhancements, improvements to the product and contribute that back to the community that’s driving the product’s innovation. 

We had a very, very different strategy. We wanted to use open source as a freemium strategy. We wanted to use open source so that it would be easy for developers to use the product, and also leverage open source to drive virality of adoption of MongoDB all around the world, but we still want to retain all the benefits and margin structure of a traditional software company, which is why AGPL was selected.

Roelof Botha: The founders here made a brilliant, absolutely brilliant decision that we called out in our investment memo on page one, in that they picked the AGPL license, so-called Affero GPL license, which was a more restrictive license that enabled customers to download the software and use it, but it limited the ability for other people to make changes and then offer that software commercially. 

Dev Ittycheria: Now, one of the things with open source is that the open source licenses were built in a pre-cloud era. And one of the things that happened in the cloud was that we saw the hyperscalers take the free version of a lot of open source technology, plug it into their platform and offer it as a service and make money on it.

What we were worried about is that since we wanted to build an independent stand alone business, we were worried that the hyperscalers would do what people call strip mine MongoDB, which is take our free product and essentially do the same thing they’ve done with other open source projects. 

And while AGPL had more restrictions, there was some terminology that was not exactly black and white, so there’s a little bit of gray and what we didn’t want to do was end up litigating this issue in court if some hyperscaler did decide to try and take our free version and go compete with us.

Updating the licensing model to avoid “strip mining”

Dwight Merriman: We could see the writing on the wall. In other words, the hyperscalers were going to offer their own Atlas-like things based on the MongoDB source code if we did nothing. They had not done that yet, but if they did, it would be kinda like game over.

Roelof Botha: We had a Board meeting in 2018. We were actually in Las Vegas at the time at AWS Reinvent, their conference.

And at the Board meeting, we wrestled with this decision about whether or not we should embrace an alternative licensing scheme.

The licensing model the management team and the Board debated was called SSPL, or Server Side Public License. 

SSPL would maintain the same basic structure as AGPL with one major condition: any organization offering a service using MongoDB’s code would have to either obtain a commercial license or make their own source code publicly available. 

Dev Ittycheria: The reason changing a license was a crucible moment was that there was definitely a lot of concern about how users would take to this license change. 

While SSPL conforms to all the principles of open source, it was not an officially sanctioned license from the OSI. 

Roelof Botha: Our fear was that our customers would not trust us, that they may think that the change in licensing scheme is a way to circumvent them or take advantage of them and that we weren’t true to our open source roots. So, it was a very, very difficult decision for us, not knowing the reaction. This is one of those things that you announce and there is no small beta trial that you could do. 

Dwight Merriman: There’s been many examples of companies, open source companies, changing their license and there was backlash and sometimes they even reverted. They backed off and they said, “sorry.” So, it was scary, but I couldn’t think of any other solution to the problem. 

I would say it took months and months and months and months to make the decision. Part of it is, like I said, if it doesn’t go well, this is a giant problem. You’ve got to get it right. You need to be a hundred percent sure you really need to do this.

Dev Ittycheria: As I thought about this problem and I thought about developers, not just here in New York, but say developers in Mumbai or Shanghai or Palo Alto or anywhere else in the world, I said, if our software is open source in the sense that they can see and access our source code, they can modify the source code, they can redistribute that code, they can essentially do anything they want with it like they do with any other open source license, would they really care whether or not this was an officially sanctioned OSI license?

And I felt, if you could solve their problem better than any other alternative out there, they wouldn’t care. And that was the bet we made. 

Some people thought this will have some long-term negative impact on the business and ultimately, I made the call that we are going to go ahead with this license because it’s too important to not do this for our future. 

Roelof Botha: In October of 2018, MongoDB debuted SSPL. The company pioneered this licensing model, and in the days that followed, we held our breath for the community’s response. 

Dev Ittycheria: When we announced the shift, there was clearly some reaction. Most of it was positive, but there was some negative reaction. The zealots of the open source community came out and made it clear that this was not a sanctioned open source license. They didn’t support this and they didn’t view MongoDB as an open source company anymore.

There were definitely some customers who weren’t clear exactly what this meant. So, we spent a lot of time, invested a lot of time and effort to educate our customers on what the implications of this license change was. We posted blogs about why we did this and tried to address questions that anyone would have, and then obviously, we armed our salespeople to explain to our customers who were reaching out to us why we did this and what the implications it had on them.

Our Atlas business only grew faster after this change, but there were some people who definitely predicted our potential doom, and luckily, those naysayers were completely wrong.

Roelof Botha: Given the experience that I’ve had with MongoDB, both in the original choice of AGPL and then the choice of SSPL is that, when I meet young companies that are open source, one of the first questions I ask them is “what is the open source licensing approach that they’ve adopted?” Because you can make changes early on much more easily than you can later.

And I wish more founders who build open source companies would study the MongoDB case study to appreciate how important it is for them to choose the right licensing scheme early on in their company journey to ensure that they can build a thriving business.

Evolving back into a platform

Dev Ittycheria: Roelof always pushed us on thinking about the scale of our ambition. MongoDB had taken a long time to get a hundred million dollars in revenue. Now, there’s many, many companies, a high percentage of companies don’t even get to a hundred million dollars in revenue. So, that’s a pretty big milestone. But it took us 10 years as a company to get to a hundred million.

But Roelof always pushed on me and pushed on the exec team and was confident that we could be a far bigger company. Now we’re approaching to be almost a 2 billion dollar company and we’ve done that, essentially, in a pretty short period of time.

Roelof Botha: While MongoDB began its journey by narrowing its scope, today, by creating such a successful database, it’s earned the right to evolve back into a platform.  

Dev Ittycheria: We realized that our customers were coming to us and asking us to do more things. Customers tell us, “hey, I’m using MongoDB for a bunch of my workloads, but then I have to use a search database along with MongoDB, and why can’t you do both?” Other people would say, “I’m using these single point, single function databases and I’d much rather do everything on your platform because then all the data is in one place.” 

That really drove the focus of building out a broader set of features so that customers could essentially do more things on MongoDB, but still do it in a very unified and elegant way, essentially across any deployment model. They could do it on premise, they could do it in the cloud, they could do it cross cloud, and for some uses, they could also do it at the edge.

Executing on points of leverage

Dwight Merriman: I think it’s kind of interesting how we started with this platform as a service idea where the idea is to create a platform. And then, we did the pivot, so now we’re making a product, right? But as the product gets bigger, it’s kind of ironic that it is kind of a platform.

Roelof Botha: The founding mission of being a platform business is now what is shaping our future, as we’ve gone from being a compelling database solution to now thinking of ourselves as a developer data platform and offering many more of the tools and capabilities as a single point to make life easier for developers and to really help solve their problems.

Dev Ittycheria: My main takeaways from the crucible moments I’ve been through is to think about a few things. One, think about what kind of outcomes you want, whether it’s for yourself or the company or organization you’re working for and working backwards from there. Then, thinking about what are the biggest points of leverage that really have an outsized impact on getting to those outcomes and really, really focusing on executing on those points of leverage very well.

And the third thing is learning how to deal with adversity. There will be times when your commitment is tested. There’ll be times when you question yourself about whether or not you’re doing the right thing. There may be other stakeholders who challenge your assumptions and while you want to listen to the feedback and maybe there’s things you haven’t thought through, it’s really, really important to deal with those adverse moments and continue to plow ahead because, as the definition goes, a decision you make today can have an outsized impact on the future of your business or the future of your career. 

Roelof Botha: This has been Crucible Moments, a podcast from Sequoia Capital. 

Crucible Moments is produced by the Epic Stories and Vox Creative Podcast teams, along with Sequoia Capital. Special thanks to Dev Ittycheria, Tom Killalea, and Dwight Merriman for sharing their stories.