How Do You Build a Cloud Native Open Source Business?

June 25, 2019 –

Do you really want to build a business? That’s a question I find myself asking some pretty talented people who have embarked on open source software projects and who come to me for advice. That simple question, which they often haven’t asked themselves yet, provides only a starting point. It leads to a decision tree of hard choices.

I’ll give you an example. Matt Klein is the creator of the Envoy project, a layer 7 proxy, that has been adopted en masse in the community and by companies like Microsoft, eBay, Google, Airbnb and Amazon Web Services. Matt started his project at Lyft in 2015, and he didn’t do it for business reasons but “to satisfy customer problems,” he said at a recent event that Mayfield co-hosted with the Cloud Native Computing Foundation (CNCF). Matt eventually open sourced Envoy and by 2017, he said, “it started to blow up.”

By choosing not to start a company with Envoy, Matt said he was able to create a more vibrant developer and customer community. And that helped make Envoy ubiquitous. 

A split model like open core, where a company does both open source and commercial versions, has the risk of alienating developer communities, he said. “But that doesn’t mean you can’t have a viable business,” he added. 

I agree. But you need to first ask yourself what you want.


Tell me what you want, what you really, really want?

Building a company around a project is hard. It’s a long road that requires different skills and tools than just building a successful open source project, which is hard enough. So you should start by thinking hard about your goals and what success means to you. 

If you’re happy with your project’s community, the innovation and scale it brings, fine. Some of the most successful open source projects, and communities, like Kubernetes, have thrived that way. 

There are many reasons to pursue an open source project. It’s a way to give back. It’s altruistic. And it’s about being part of a wider movement. If those are your goals, your road is not as hard. 

But if you define success as being an entrepreneur, and you’re dead set on taking on the challenges of building a thriving business, here’s what you need to consider.


Building a company vs. building a project

Building a company is more than just turning a community project into a commercial product. You’ll have to build out sales, marketing, human resources and other company functions. A company is not just a product. 

There’s also going to be an inevitable tension between what your developer community wants, what your customers want, and what’s good for your business. Balancing all three is extremely difficult. Unless you have a true North Star, it’s easy to be led astray.


You must have a must-have

If you made the decision to go commercial and raise capital, you need to be sure you’ve built a fundamentally valuable product or service for a paying customer. Or as my partner Navin Chaddha says about one of Mayfield’s criteria for funding an open source-based startup: “You look at the problem they’re trying to solve and see is it a must-have or a nice to have?” 

Defining must-have can be hard, but it generally means finding a burning pain point that a customer will pay to alleviate. Perhaps you’ve heard the painkillers versus vitamins comparison. A vitamin is something you take because it might make you feel better in the future. But a painkiller is something you need to fix a problem now, and you’re willing to pay to get it as soon as possible. 


Embrace the tension

As you continue building the product, you’ll need to make decisions about what goes in the open source product and what is reserved for paying customers. You do this knowing there are people in the developer community who are going to feel short-changed. That’s the tension you have to navigate. That means you, as the founder, will have to understand what companies find valuable and worth paying for. And you’ll have to be okay with not giving that to the community.

At InfluxData, a Mayfield-funded time series database startup that has more than 230,000 server installations, CEO Evan Kaplan embraced that tension, opting to leave scaling and high availability features out of the open source product. “Had we been able to stay pure open source, would we have 700,000 [installations]? Would we have 1 million?” he asked during the CNCF event. “I think it is very possible we would. But I don’t think we’d have a company.” He then added: “The fact that we monetized that scale-out layer hurts us a little, but it hasn’t hurt our community at all.”

There are general guidelines about what belongs in an enterprise version of an open source product, including security features, analytics and operational high-availability services. Being clear with everyone—the community, your customers and your employees—about where the dividing line is will be critical to your success.

Finally, in order to manage these tensions, you’ll need to make sure one team is making the decisions about what goes in the open source versus what goes in the commercial product. You can have two teams separated by a firewall.


Nurturing the community

Always remember that if you don’t take care of your developer community, you’ll end up with nothing. After all, the most successful open source projects thrive largely because of the dedication of those developers. “We have a community that actually will self-identify as Kubernetes developers before their company,” said Sarah Novotny, head of open source strategy at Google Cloud, which developed Kubernetes before putting it under the direction of CNCF. 

That means your company cannot be solely focused on commercial success and treat open source as an afterthought. You can’t cynically do open source because you’ve chosen it as a business model. Your team needs to consider what is best for both sides.

On the developer side, you need to engage the community and offer ways for its members to contribute to both your product and your culture. At Docker, for example, we came up with the idea of having “Docker Captains,” people within the community who had made outsized contributions to the project, championed the movement within their organizations, or had evangelized and helped build our network. They received special recognition as a result, which in turn, helped to preserve cohesion in the community. 


Balancing your internal culture

From the start, you must build a workforce and culture that understand the dual value proposition of your company. That means hiring people who are equally comfortable on the open source and enterprise sides of the business.

If you bolt on a purely commercial team on top of an open source team, you will likely have a culture clash. Make sure the teams are balanced and understand the needs and roles of each other. As mentioned above, ideally it is one team which cohesively integrates both open source and commercial-oriented people, making fair judgments about what features should end up on either side of the house. It’s not about “us vs them,” it is an inclusive culture that understands the value both groups bring to the table.


Open source and go-to-market

Let’s say you’ve built the product. How do you make open source work for your business from a go-to-market perspective?

Start by focusing on the value proposition for the customer. “Open source is a great go-to-market,” said GitLab’s Priyanka Sharma, a member of the governing board of CNCF. “There’s just so many different experiences that we can learn from.” 

Number one is avoiding vendor lock in, giving the ability for the customer to operate in hybrid environments. Number two is the ability for the customer to test at scale, as they can run the code themselves. Number three is the ability to evaluate how secure your product is and to test for vulnerabilities. That’s hugely important given how common security breaches have become in today’s world.

There’s also an internal value proposition for your company, and that’s the ability to test product market fit. But you have to be careful. Product market fit within the community is not necessarily product market fit within the enterprise. At any rate, you’ll be able to test and iterate very quickly. “That’s a really incredible thing,” Kaplan said. Early users of the product provide critical feedback that leads to product changes and, he added, “end up being way more valuable in our product cycles than the truly paid customers. So that ends up being the long term competitive advantage and it’s under appreciated.”

Finally, a bottoms up adoption model is going to be one of your biggest upsides—and the clearest path to sales leads. Sheng Liang, co-founder and CEO of container management startup Rancher, said at the CNCF event that the bottoms up approach was key, and led to his company choosing to monetize its success through paid support services. “Rancher’s been downloaded over a 100 million times,” said Liang. “It would have been inconceivable if we had chosen a different business model.”

Build your product the right way, with the right incentives to upgrade to a commercial version—or commercial add-on services—and the customers will come to you. You’ll be able to service them through an inside sales process instead of spending on a field sales team.

Ultimately, it’s all about respecting the balance. Sometimes you will be focusing on bolstering mindshare with your community and sometimes on strengthening the commercial product. Just make sure to understand at any given moment what you are doing and how it will ultimately help both your developers and your customers.