When it comes to open source business models, the rules of engagement have changed—and it’s good news for entrepreneurs.

For years the concept of an “open source business model” was largely aspirational. The reinvention of software as we know it has been fueled by communities, not corporations. Passionate, creative, and intensely averse to software monopolies, these communities are accelerants and advocates for technological innovation. Yet it’s become clear over time that adoption, not technical merit, is the linchpin for a community’s long-term viability and success—and factors like reliability, performance, and scalability are crucial to enterprise adoption. The result is an inherent tension between a movement defined by software freedom, and the business models inevitably required to sustain it.

Companies built around open source technology have had to walk a razor thin line between community and customer. They must create a viable business, yet remain practically and ideologically committed to the spirit of open source—i.e., products must be transparent to the community and genuinely useful, without depriving the community of anything fundamental.

With paying customers generally accounting for just a tiny fraction of total users, the path to monetization has historically been a very steep climb. Most companies focused on selling support or enterprise-grade add-ons. Both approaches tended to rely heavily on a strategic acquisition premium to make a high return, because the financial models didn’t support the hype and neither scaled particularly well. There have been a handful of great exits (Red Hat, MySQL, Xensource, Sourcefire), but they are the exception rather than the rule.

Although it required some thick skin to be an early investor in these types of companies, the magnitude of the technological transformation was far too exciting to ignore. The real action is in open source, at every layer of the application stack; it was true ten years ago, and even more so today. Today, open source projects are tackling the meatiest challenges, often convening unlikely allies from developer groups to CIOs to Wall Street firms—people who need to solve an intractable problem and are ready to put muscle behind it.

Most open source projects have support from large players in the ecosystem and are among the most advanced technical projects anywhere (e.g. Spark, Hadoop, and projects around machine learning and distributed systems). With a multitude of contributors and reviewers, and more than a few reputations on the line, open source software can be higher quality and more secure than proprietary projects. Customers love not being locked in to vendors, and being able to change the code as they go. Increasingly seen as a mandate, a growing number of large enterprise companies are making strategic decisions to use open source products whenever feasible. Black Duck’s recent Future of Open Source survey claims that more than 50% of enterprises are expected to adopt and contribute to open source software projects. Even Microsoft is trying to adjust with aggressive moves like open-sourcing its server-side .NET stack.

Amid all this momentum, something critical has shifted in the landscape: finally, the opportunities for company building are as exciting as the underlying technology! Factors like cloud maturation, pervasiveness of APIs, adoption tipping points, and code quality have converged to create a new vector for software business models. The possibility of building a massive standalone open source business now seems more achievable than ever. Especially as the potential client base has expanded from a core group of developers to encompass giant swaths within organizations.

Today open source is playing a vital role in solving major problems for major corporations, and with critical mass comes a greater tolerance for a commercial entity to make money. In this new modality, businesses can layer products and services atop a thriving open source community. Organizations wearing both hats still walk a fine line, but they are proving it can be done successfully. Following are some of the most interesting approaches, with many companies incorporating more than one into their models.

• Differentiate by expanding the capabilities of the open core platform (e.g., enterprise extension or overbox solutions tackling management, security, etc.). Companies that do this well can enrich an open source community and deliver exceptional value to customers without imposing vendor lock-in. Nginx fits this bill—while web servers have not historically been monetized, the company is aggressively gaining market share by offering value far beyond traditional web servers (e.g. load balancing, application acceleration, content streaming) and a sophisticated set of controls for enabling web applications to scale. In other cases the company builds value by making the core itself better or “hardened” and contributing to the open source community in surrounding areas. MapR is a classic example—the API stays in the community, and MapR is innovating around it. The company is actively contributing to the open source project, while at the same time differentiating by delivering a higher-performance product.
• Run the applications and building blocks for the open source project’s ecosystem—ideally with such deep knowledge of the project that you can offer substantial improvements in performance, integration, and management. It’s hard to come up with a better example than Databricks—founded by Ion Stoica and the creators of Apache Spark, the company is building an easy-to-use, unified application platform that will help Spark developers bring more big data applications to market in less time, and run them better.
• Provide a centralized place for hosted repositories that anchors an online developer community. Monetize by charging customers to make their repositories private and/or allow developers to market support, training, and other services via the hosted platform and take a cut. This model is best suited for bigger projects. GitHub is a great example of this – it’s free for anyone to use, which helps promote collaboration and coheres with the ethos of open source software, but if you want to limit access to your source code, you need to pay. Docker also got its start with hosted repositories, though they recently expanded into on-premise container storage and differentiated orchestration tools.
• Subscription models are a variation on the traditional enterprise license, but the growth in SaaS has enabled broader acceptance of a recurring revenue model for open source companies, leading to healthier business models. They work well when adoption reaches a tipping point within enterprises, in part because the user base demographics shift—they are willing to spend money to save time. Reliability, performance, security, ease of management, and support are highly valued and customers will pay. Companies like NGINX, MapR, MongoDB, Elasticsearch and Acquia all demonstrate the company building potential for subscription models.

Regardless of approach, the more deeply rooted you are in the community—and the more control you have over the code—the better situated you are to build a business around it. After all, who better to build a product around code than its creators? However, that control carries a responsibility to contribute to the project and be responsive to the community’s needs—it means keeping the feedback loop open and continuing to cultivate passionate advocates among that core user base. This will never go away.

There are still big hurdles in building a company within an open-source community. The entrepreneur who stormed the world with free product has to muster the courage to stand up to his community to ask for a dollar. That’s a hard ask, and it’s even harder to get it right—not only do you have to convince someone that your free product is now worth paying for, but you have to get your offering right. That requires a combination of guts, creativity, and almost certainly some trial and error.

As open source pioneer Marten Mickos has pointed out, it is also critical to get branding right. An open source license gives the user right to the code, but not the name; branding is how you can control the behavior of the ecosystem. This is why Amazon could use Android code in their Kindle Fire, but they couldn’t use the name without signing Google’s Open Handset Alliance. Similarly, you can build something on Hadoop but you can’t use the name in a commercial product—just ask MapR, Cloudera and Hortonworks.

If you can get the model and the branding right, there is tremendous opportunity for talented entrepreneurs to build something that has real value—both to an open source community and to a company’s bottom line. Fortunately, some of the leadership qualities that produce great business outcomes will also help a community flourish: developing a strong culture, spurring advocacy/evangelism, understanding the power of positioning, knowing how to build a brand, and recognizing individual and team contributions.

Remember that the open source movement has been built bottom up, not top down. Today is unquestionably a major inflection point in the evolution of open source business models—and there’s no limit to what you can build, as long as your foundation stays strong.