How to Bottle Community Lightning Like Datadog
Flip through an economics textbook from the 70s and you’d find a very clear explanation for why the world of today could not possibly exist.
People are rational, it would argue. They always maximize self-interest. Given two prices, they’ll pay less. Given two equivalent jobs, they’ll choose the higher salary. We are homo economicus and you could never convince tens of thousands of smart people to voluntarily work grueling hours without pay. Yet today it happens.
And not only does it happen, but developer communities of just this sort are responsible for what the Ford Foundation calls our new roads and bridges—the open source infrastructure that undergirds our entire digital world.
Today, we examine how a wholly rational analysis of human motivation cannot explain these communities, and why those who attempt to create them on a rational basis often fail. We’ll also look at the wildly successful one that emerged around the observability platform Datadog, and how, in the admission of its VP of Product and Community, Ilan Rabinovich, one thing from those economics textbooks of the 70s is still true—nobody can convince people to join. They have to want to.
Datadog is an observability platform that helps you understand the health of your digital business. If that seems vague, it’s because the use cases are impossibly wide—from monitoring software security to looking at the uptime of digital billboards or the quality of milk flowing from cows. People can monitor whatever they want with it.
For many founders, that sort of open-ended remit begs to be narrowed. Why not choose a lane? Isn’t there a danger to boiling the ocean? But that’s where Datadog’s strategy excels—like the free hand of the market, the community helps drive the product.
Related read: An Inside Look at How Datadog Reached $500M in ARR (and Counting)
Datadog was founded back in 2010 on the idea that operations teams and developers needed a common language. These teams often got into disagreements based on opinions about how their product worked and who was using it. Datadog felt that if they were to fight, they should at least be fighting based on data.
“Developers and operations teams were looking at different things, using different tools, and referencing different data,” said Ilan. “It’s the old story of the Mars orbiter that slammed into the planet—one team was working in metric and the other in customary. That’s where failures come from.”
At each stage of development, as Datadog has added more products to tackle different aspects of that story, they found themselves drawn to develop the product in new areas based on customer requests. In turn, customers felt drawn to a platform that was highly receptive to accommodating their needs.
“Years ago, we were receiving tons of requests from people saying, ‘I’m using a lot of Docker, help me monitor Docker. Here’s some code that goes with it,’” says Ilan. “The same happened with Kubernetes. One client was an early pioneer of Kubernetes and a large-scale adopter of OpenStack, back when these things weren’t even 1.0, but they sensed it was important, and we did too.”
This development based on requests went hand-in-hand with their open source approach. Datadog contributes heavily to others’ projects, but also maintains its own. The agent most customers use to run Datadog on their systems is open source, as are many of their libraries. “It’s not purely out of altruism,” says Ilan. “Open source is something our customers need. The reality is they want to see it, pull it apart, understand it, audit it, and make changes if it doesn’t meet their needs. It’s very functional.”
“Nobody can convince people to join. They have to want to.”
This symbiosis has had a profound effect. Open source projects have expanded the product team’s network of awareness far beyond the walls of the company, not unlike a mycelial network that links a forest of trees and allows them to exchange nutrients. At the community’s farthest reaches, users are able to reconfigure Datadog’s open source components to function in countries where the team doesn’t speak the language, for use cases they’d never envisioned. And wherever demand for adjustments reaches a fever pitch, that’s a signal that helps Datadog guide its product. (Though it remains just one of many.)
“One of our key signals is that a customer went through the effort of adding support for monitoring, say, containers, on our behalf,” says Ilan. “If they’re paying us and doing extra work, maybe we should be looking at that. It’s just one of many signs, but it’s a strong signal.”
This is a vision of a user community going well. But that isn’t the usual story. Most open source endeavors fail for a lack of interest and maintenance. Most communities wind up as ghost towns because the road to them was paved with aspirations of profit.
Photo: Alexis Lê-Quôc (left) and Olivier Pomel (right), Datadog’s founders.
Why so many user communities fail
In Brooklyn, not far from where I live, there is a house with a chain-link fence and chickens. Outside sits a gumball machine. If you place a quarter and turn the wheel, it deposits grubs you can toss to the chickens.
Every child within a 10-block radius knows about it. In effect, strangers not only feed this couple’s chickens, but pay for the opportunity to do so. I’ve long wondered how this arrangement came into being, and the people who live there told me it all began with observation.
From their home-office window, they used to watch as children dragged parents to talk to the chickens. Barnyard fowl? In Brooklyn? The attraction sold itself. They set out a gumball machine thinking it’d increase the fun and within a week they began receiving angry knocks at the door from parents and teachers demanding to know why the machine had gone empty. A public institution had formed. Others now expected them to maintain it. This is how real communities form—around intrinsic value, by happenstance.
“Most communities wind up as ghost towns because the road to them was paved with aspirations of profit.”
I think about this story whenever I read statistics like this: 70% of user communities fail. The reason the failure rate is so high is because so many of them start with some sort of profit motive. Someone sets up a gumball machine to nowhere, replete with a revenue objective and lacking any understanding of why people would actually care. (These goals are often phrased as, “If we only capture 1% …”) Often, there’s a presumption that some sort of kickback or monetary reward—micropayments, cryptocurrencies, badges, etc.—are what will get busy adults contributing. But alas, these people are designing for homo economicus.
Datadog has never run into these problems. At the time of writing, the Datadog Slack has over 28,000 members and its GitHub projects have 519 repositories and none of their “community,” which encompasses a wide but federated swatch of activities, began with a conversation about “hacking growth.” Whenever Datadog does act to guide it, it’s always based on observation.
“We are particularly customer-focused,” says Ilan. “I know everybody says that but I think it’s something we do particularly well. Datadog product managers spent a lot of time with customers. Possibly as much time as they spend with other employees. That informs everything we do, what we work on next, what we stop working on, and when we shift gears. We’re beyond curious to know how we find themes across what they’re doing.”
The Datadog community was always an organic solution to a preexisting problem. It was always chickens first.
The right reasons lead to the right payoffs
Ilan was also clear that there is no formula to fostering community. There is no playbook we can offer, and communities and open source projects are not necessarily the answer for every company.
“You have to ask yourself what your goal is with open source. Some companies open source for the sake of open sourcing, without sitting down to say, ‘What were we looking to get out of this? What does the community get out of it? What’s the long-term plan?’” says Ilan. Sometimes, there is a better play. Sometimes, open source is suitable for side projects that make customers’ lives slightly better, but which have no connection to the product. “That’s fine,” says Ilan. “But if you’re going all-in, you have to know it supports your model.”
There are other considerations as well. With open source, you take on a maintenance burden without necessarily having a clear connection to revenue. And as the Ford Foundation pointed out in its “Roads and Bridges” report, maintenance can often be lonely and daunting.
“First ask yourself, do your customers care that it’s open source? Is it something they even want? Will they run it themselves? Are they going to contribute? If people show up with pull-requests, will you take them? Can you take them?,” says Ilan. “Also, that code is open. What if people really want to do something with it that doesn’t align to your roadmap? Are you okay with a competitor using it? Keep that in mind. You can’t be angry about it later.”
But thus is the paradox of communities. Questioning them is the key to keeping them. The more attentive you are to customers’ needs, the more of your own company’s needs are met. The community grows and not only guides the product, but becomes a highly credible form of marketing, recruiting, and retention. According to one open source software engineer who moved from Datadog customer to employee, the company’s open source commitment was key to his interest.
“There exists something deeper within all of us that makes us want to be a part of something greater, and good communities can activate it.”
“Back in the beginning, if you used anything non-standard, you pretty much had to write it yourself and Datadog would hope that you would contribute it upstream for everyone else to use,” said Brett Langdon, Engineering Team Lead at Datadog. “But nowadays, everything is already available!”
When Brett says practically everything is available, it isn’t thanks to some clever system of crypto-kickbacks—it’s because there exists something deeper within all of us that makes us want to be a part of something greater, and good communities can activate it. It starts with a company that’s genuinely trying to do the right thing for its users, who then feel inspired to repay the effort in a virtuous cycle of creation.
And eventually, after years, you have tens of thousands smart people voluntarily working grueling hours without pay. And in the end, they all win.