MongoDB is pretty darn good at community. The open source database has been downloaded more than 8,000,000 times. The result: tens of thousands of companies run it in production. MongoDB has grown into the most popular NoSQL database for developers, and by a wide margin. MongoDB credits its thriving community as an integral part of its rapid growth, but how did they pull it off? And what value does an active developer community have to its customers?
To get a look under the hood, I recently spoke with Matt Asay, MongoDB's VP of Community. When I learned that Asay was not a developer himself, but has oodles of marketing experience, I was even more eager to put him on the hot seat. Developers have a way of eating marketers for lunch. But do developer communities need marketers after all? Here's what I learned.
Jon Reed: You're not a developer, and you've spent a fair amount of time in marketing roles, which is usually a kiss of death for developer engagement. How did you end up in this role?
Matt Asay: I'm an English major with an International Relations master's degree - then I went to law school. I think I'm a pretty good writer, but I'm not a very good writer of code. If somebody asked me to write something in C#, I would fail. When it comes to developers, sometimes we think the only thing that matters is writing great code. But there's a lot more to it.
Reed: So it's not as simple as writing great software?
Asay: If you want to build a developer community, it's not. You need to avoid a "Field of Dreams", "If I build it, they will come" mentality. That's not the way the non-developer world works. It turns out it's not the way the developer world works either, because you need some element of storytelling or marketing to frame the code so that people understand why it matters, why they should contribute to an open source product, why they should use it.
Despite not being a developer, I'm technical enough that I can appreciate what the code means and then put that in plain English for people to understand. That's what I spend most of my time doing - trying to create stories around the software itself.
If you don't have a good story, developers won't show up
Reed: How does telling a great developer story make a difference?
Asay: At the most fundamental level, any open source project - and practically any software for that matter - withers on the vine if there's not great documentation. This isn't necessarily storytelling but it's learning to communicate about how the software is supposed to work: "Here's some code samples. Here's how you get started" With MongoDB, early on, some developers reported problems because they were trying to run MongoDB on AWS. They were struggling. They blamed MongoDB, or they blamed AWS. But there wasn't a fault in either system. It was a fault in how it was set up.
That came from poor documentation. Guess what? That's our fault. We need to make it as easy as possible. Some people would say, "Well, they have the source code. Just look at the source code and figure it out." No! Most people don't have that much time and even given access to the source, they're still not necessarily able to figure out what to do. Documentation is what I'd call first level storytelling.
We spent a lot of time improving the documentation on how to run MongoDB successfully on AWS. As a result, there's been a huge uptake of running MongoDB in Cloud, and running it successfully.
Reed: Documentation is the beginning - but that's not the end of the story either.
Asay: No. Take NoSQL databases as an example. I think if you go to DB-Engines, DB-engines.com, there's over a hundred NoSQL databases, You have all sorts of choices. Let's say you're a developer sitting at Target or Chevron, and you need a key value store. Guess what? You have over 100 NoSQL databases to choose from. How are you going to figure out which one you should use? An open source project that has invested time and attention in articulating why their particular value store matters, and what you would use it for, has an advantage. It's much more likely to get used.
I think we sometimes overestimate how much developers want technical information. Yes, they need it - but not always right away. The first gate they go through has plenty of noise. You need a message to stand out in that noise. Nathan Marz of the Apache Storm Project says that one of the best things he ever did for Storm was coining the phase "Real Time Hadoop," which isn't a perfect description of what Storm is or does, but it was a nice shorthand. So if a developer talking to another developer says, "I need something that will process my data in real time," the other developer might aay, "Oh, there's real time Hadoop, it's called Storm."
That might be just enough to get somebody interested. It's by no means the end of the process. If you're a developer, you need to get through that gate and quickly get to the code as fast as possible. But you're never going to try to use that project in the first place if somebody hasn't framed it in a way that makes sense to you.
Why does developer engagement matter to customers?
Reed: What about your own customers? How does building out a developer community impact them?
Asay: I've been working in and around open source for about 15 years. Speaking first about MongoDB, one of the main reasons that a company will choose us is very much the vibrancy of the community around it. There are a few reasons for that. It's really about how community mitigates risks of a technology purchase. Anytime you're choosing a new technology, there's a risk that it's going to fail - either that the technology is bad or more likely that it's just not a good fit for your organization.
Having a community de-risks that in a few ways. If there's a sizable community, it's a declaration that this technology is going to be here for a long time. People are going to keep using it, maybe contribute code to it. The second way to de-risk a technology purchase is by ensuring there's a lot of talent out there that you can hire. You might like a particular technology, but you might find it basically impossible to find anyone you could hire to work on it. If there's a strong community around it, your odds of finding a qualified person to help you are much, much greater. The third way community de-risks the investment is the third party software community that builds up around it.
With a NoSQL community like ours, the odds are pretty good that your content management system is going to work with our database. Your Teradata is going to work with it, whatever cloud system - you name it. You have that assurance that these other investments that you're making adjacent to the new purchase are complementary. That's important - you can't go it alone.
Reed: Got a customer example?
Asay: When IBM came to work with us about a year and half ago, they told us they had picked MongoDB after going through extensive process of evaluating the strength of the communities around a variety of NoSQL databases. They ultimately chose to work with us because they felt the community made it certain that it's going to be around for a while, and that there was going to be a broad base of talent that they could draw from. That's typical - we hear that from many customers and partners that it's really important.
Open source or bust - MongoDB's lessons
Reed: MongoDB's open source approach has been instrumental to attracting developers, who thrive on free downloads and shared code. What advice would you have for companies that have not open sourced any products or who are cautious about sharing their code?
Asay: There was a time when open source was the anomaly, this cute little Linux thing off to the side. Now open source is the foundation for the biggest mobile ecosystem. For big data, all of the infrastructure is open source. If you want developers to work with you, or even if you want developers to use your stuff, you're going to fail unless it's open source.
Reed: What's the hardest thing about running an open source community?
Asay: For companies managing open source projects, the biggest challenge is finding the right balance between controlling everything or opening up and allowing people to contribute in meaningful ways. At MongoDB, I don't think we've been perfect. But one thing we've done well is to open up the drivers which interact with the core database server on our Apache license. A lot of those drivers are written by people outside the company - by developers all over the world.
Reed: Matt, can you wrap it up with some final tips?
Asay: Rule number one is that you have to treat community as a top priority. That's obvious - but it turns out to be really hard in practice. You have to openly communicate about the project and the code that's being written. Whether it's GitHub, or however you choose to do it, the development needs to happen in the open so that people outside the company have as much access to what's going on as those inside the company.
Never, never assume that everyone else knows about your project, or that they know how to use the code. One of the things MongoDB did early on was put on a lot of events, We now have more than 30,000 members in our user group, and a lot more have signed up for the online university - 200,000 so far.
Reed: Companies talk a good game when it comes to community, but it's lip service more often than not.
Asay: I've seen so many companies, and not just companies but individual projects, where it has been an exclusive group. They act like they don't want anybody outside the company or outside of the project to contribute, and they have somewhat of a toxic environment. Like you said, it's lip service unless you can show your commitment to community on a day-to-day basis.
A lot of that is outbound communication through training, or speaking at events - you have to get face to face with people and engage with them. Then it's creating the mechanisms by which all the code development happens in the open, and people are able to talk back to you, either in person or online. You have to be very permeable.
Readers may also be interested in Matt Asay's recent piece on readwrite.com, Open-Source Projects Need More Than Good Code—They Need Marketing.
Image credits: Photo of Matt Asay provided by MongoDB, Inc. Feature image: Social Networking © dolphfyn - Fotolia.com.
Disclosure: Diginomica does not have a financial relationship with MongoDB as of this writing. I contacted MongoDB PR to arrange an interview on MongoDB's approach to developer engagement.
Update: factual corrections made 11:50ET 10/19/2014.