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

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, it would be kind of like game over.

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, Rolof Buurtong. 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 $2 billion 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.

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 that it was a good time to maybe do something new. And myself and Kevin Ryan, who was CEO of DoubleClick, And Elliot 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 know, 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, with this whole new stack of, of modern things that we thought were appropriate for that point in time in, it's kind of the 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.

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 wanna 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 were 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 know, you tune a musical instrument. It seemed 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 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. 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, because 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.

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 Tensent, 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 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, like Tengen, Google App Engine is conceptually very similar. We had a little family vacation, so I had my laptop with me so I could, I could work every day even though we're not at 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 minutia 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 $1 billion. It just seemed like that's not going to fly. Maybe platform as a service makes sense, but, you know, the companies that need to do it are ones who can afford that runway and have very long-term thinking, like a Microsoft or maybe like a 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?

MongoDB, then Tengen, 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 can, we could focus on it and just scrap being platform as a service. I think the term crucible moment is a really good one because it, it's a big decision, right? It's, 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 that made it much more difficult to do that. If we started doing database only and it didn't work, There was no going back to platform as a service. Like, we would've figured out 18 months later it wasn't working, and then it's too late. The first person I talked to about this was Elliot, so our co-founder, CTO, super smart. And, uh, we go talk in our little tiny conference room, and I lay 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 like, I want, I'm going to take a business plan. I'm going to, 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, it's even more scary because we're doing this very proactively. We may be killing something that would've worked. So now if the new one doesn't work at all, boy, that was maybe one of the dumbest things ever done. And, you know, and it's emotional, you know, like when we did this, you know, we threw the app stack, the app layer code in the trash and we started writing drivers. But, you know, then we also had a few people who like, they weren't working on the database layer at all and I laid them off and, you know, that feels terrible. So, so it, it was a big deal.

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 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 You know, even if it's similar, it is significantly different from what you originally set out to do. I think it's emotionally taxing. You know, 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.

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, we had this database, but it only worked within the platform as a service stack, within the Tengen stack. That was the only way to use it. So we, we just kind of pulled it out and then we made database drivers for every, all the popular languages, and then you could use it, right?

In 2009, MongoDB launched for public use.

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 of 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.

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, but 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 wanted to rush to close the financing and become the new lead investor. In 2013, the company officially changed its name from Tengen to MongoDB, a reflection of its successful pivot.

From day one, you know, my background, I mean, 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 1/3 to 1/2 coding or designing things. You can go on GitHub. If you go all the way back in the, in the commit list, you'll see a bunch of commits from me. And then over time it goes down because as the company's growing, you know, 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.

In the middle of 2014, the company's revenue run rate was approximately $40 million. 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.

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 outta 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 wanna 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 was, 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.

Dave, 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 Dave 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.

I had a lot of people who, when I talked to them about joining MongoDB, were quite skeptical that MongoDB was gonna 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 you consider joining the company? I asked myself the question, if this company's doing well with essentially not a very good team, a lot of dysfunction, 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.

When Dave 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.

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.

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

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. You know, 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?

Just knowing that you needed to build a cloud offering, you know, it was 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 skillset 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. 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?

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 need to do it.

There was a real risk that if we didn't successfully develop a cloud strategy, that would lead to our ultimate demise. And so, so with that spirit that we recruited Tom Killilea to the board of the company.

To be honest, I said to Roloff, I'd love to serve on another board with you, but this may not be the one. My name is Tom Killally, and I'm the chair of MongoDB.

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.

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

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

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, the sort of wait and see versus let's, 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.

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 6 months.

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're actually starting a startup within a startup. So all the care and attention that we put in our core business, we wanted to make sure that Atlas had the same amount of focus.

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 and attainable, 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.

We assigned a directly responsible individual, what we call a DRI, who really would be the, the person who was 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.

We had to build a skill set of marketers where you'd have to manage a funnel of people going through your own signup flow and understanding how people converted and what is your free tier and how do you upgrade people to paid 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 6 months, Atlas launched on June 28th, 2016.

My abiding feeling was, you know, 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.

One of the challenges of starting a new product offering is that the numbers are so small, no one really cares if you, 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 $100 million 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?

Dave 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.

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.

It, 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 what, why are we making the investment in Atlas and who cares about this thing that's only 2 or 3% of the company today?

They said, wait a minute, how are you going to partner and compete with the hyperscalers? They're going to, you know, eat you for lunch. That was one question. 2, there was no analogs of other companies who had been successful doing that. 3, 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 were 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 gonna be successful.

There would, could have been an argument for, okay, given how central the Atlas Cloud offering is to your strategy, doesn't it make sense to, you know, 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 products, you're trying to build the next feature, you're working out operational issues. And you carry on and you've, you've been through a funding event, but the world moves on.

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 at 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 $100 million revenue, and it took us 5 years later to get to $1 billion in revenue. And a big part of getting to $1 billion in revenue you was the fast growth of Atlas.

Today, Atlas represents 70% of MongoDB's revenue. It's north of a billion-dollar run rate business on its own.

Atlas changed MongoDB in that the motion for how you interact with your customers changed. It became far more about a relationship. Dave 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, hey, okay, for my next workload, for that important thing that is gonna get shipped, why would I put MongoDB at the center of that?

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 the 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 a business with a different business model. So all those things are factors that you have to consider when you contemplate a decision like this.

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.

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 wanted to retain all the benefits and margin structure of a traditional software company, which is why AGPL was selected.

The founders here made a brilliant, absolutely brilliant decision that we called out in our investment memo on page 1. in that they picked the AGPL license, so-called Afero 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.

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 with— 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 standalone 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 were some terminology that was not exactly black and white. So it was a little, there was 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.

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 kind of like a game over.

We had a board meeting in 2018. We were actually in Las Vegas at the time at AWS re:Invent, 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.

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 official sanctioned license.

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. You know, this is one of those things that you announce and there is no small beta trial that you could do.

There's been many examples of companies, open source companies changing their license, and there's backlash, and sometimes they even reverted. They backed off and they said, sorry. So it, it, it was scary, but it was, 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 this 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 100% sure you really need to do this.

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.

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.

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 weren't 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.

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.

Roelof always pushed us on thinking about the scale of our ambition. MongoDB had taken a long time to get $100 million in revenue. Now, Many, many companies, a high percentage of companies don't even get to $100 million revenue. So that's a pretty big milestone. But it took us 10 years as a company to get to $100 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 company, and we've done that essentially in a pretty short period of time.

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.

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 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's 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.

I think it's kind of interesting how we started with this platform as a service idea where it's definitely 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.

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.

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 wanna 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.

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 Dave Ittycheria, Tom Killaly, and Dwight Merriman for sharing their stories.