This article was originally published on the Andreessen Horowitz blog and translated/shared by InfoQ Chinese.
Editor’s Note: The open source software (OSS) movement has created some of the most important and widely used technologies, including operating systems, web browsers, and databases. Without open source software, our world would not function, or at least not function well.
Open source has brought amazing technological innovation, and at the same time, business innovation—especially the recently emerging Software as a Service—is equally crucial to the success of this movement. Since open source is defined as software that anyone can use, modify, and distribute for free, open source enterprises need different models and different market positioning compared to other types of software companies.
As a developer, entrepreneur, and investor, Peter Levine has been working in open source for over 30 years. Recently, he gave a presentation titled “Open Source: From Community to Commercialization” (you can download the full presentation here), where he introduced his experience and interviews with dozens of open source experts. Below is the text version of this presentation, where Peter explores the rise of open source software and provides a practical end-to-end framework for turning open source projects into successful businesses.
Open source started as a fringe activity but later became the center of software development. In the early days of open source, one of my favorite anecdotes is about the Linux/Unix command [~}$ BIFF—it wasn’t called “open source” yet, just “free software”—it could notify users when new mail arrived. This command was named after a hippie’s dog at Berkeley that would come out and bark at the mailman. I love this anecdote because in the early days open source was so fringe that an important command was named after a developer’s dog.
I’ve been working in open source for decades, first as a developer at MIT’s Athena project and the Open Software Foundation, then as CEO of the open source company XenSource. Over the past 10 years, I’ve been on the boards of several open source-related companies. From developer to board member, I’ve witnessed the evolution of open source and seen large companies built on open source projects.
I really think now is the best time to build open source enterprises. Business innovation is crucial to the open source movement, and here I provide a framework for bringing open source products to market.
The Open Source Renaissance is Underway
The past decade has been a renaissance for open source. The image above shows that over the past 30 years, approximately 200 companies have been built around open source technology. These companies have raised over $10 billion in total capital, and over the past 10 years, their deal sizes have grown larger. In fact, three-quarters of the companies and 80% of the financing were completed after 2005. I think we’re at the beginning of this renaissance.
These investments are leading to larger IPOs and larger M&A deals.
Interestingly, in 2008, MySQL was acquired by Sun Microsystems (later acquired by Oracle) for $1 billion. At the time, I was convinced that $1 billion was the highest price any open source company could fetch. This was a barrier that couldn’t be broken for years, and in the software industry that viewed open source as a commodity, $1 billion was a very spectacular curtain call.
However, look at what’s happened in the past few years. We have Cloudera, MongoDB, Mulesoft, Elastic, and GitHub, all part of multi-billion dollar IPOs or M&A deals. And of course, Red Hat. In 1999, it went public at $3.6 billion, and this year, it was sold to IBM for $34 billion. In the future, I very much hope to see if new highs will be reached.
Open source has also expanded to other software areas. Traditionally, OSS was mainly developed around enterprise infrastructure, such as databases and operating systems (like Linux and MySQL). With the current open source renaissance, active OSS development is appearing in almost every industry—fintech, e-commerce, education, cybersecurity, and so on.
So, what’s driving this renaissance? To understand this, let’s look back at the past and history of open source.
Open Source History: From Free to SaaS
Open Source 0.0—The “Free Software” Era
Open source began in the mid-1970s. As a programmer, I call this era 0.0—the “Free Software” era. Academics and hobbyists developed software, and the whole ethos was: provide software for free. As ARPANET gave way to the internet, networks made collaborative development and code exchange easier.
I remember when I went to work at MIT or the Open Software Foundation, I didn’t know where my salary came from. There was no concept of a business model yet, and the funding supporting “free software” development (if any) was provided in the form of university or corporate research grants.
Open Source 1.0—The Technical Support and Services Era
With the arrival of Linux in 1991, open source became increasingly important for enterprises and was proven to be a faster and better method for core software technology development. As more foundational open source technologies emerged, open source communities and enterprises began experimenting with commercialization.
In 1998, the Open Source Initiative coined the term “open source,” and around that time, the first real business models emerged, providing paid support and services for RedHat, MySQL, and many other free software. This was the first time we saw a viable economic model that could support the development of these organizations.
At the time, there was another noteworthy thing: compared to proprietary software companies, open source companies’ market caps seemed insignificant. I compared Microsoft with Red Hat, MySQL with Oracle, XenSource with VMWare, and I found that closed-source companies’ market caps were far larger than open source companies. Industry insiders believed that OSS was a commodity that could never approach the potential economic value of proprietary software companies.
Open Source 2.0—The SaaS & Open Core Era
By the mid-2000s, these valuations began to change. Cloud computing opened an opportunity, allowing companies to run open source software as a service (SaaS). Once I could host an open source service on the cloud, users didn’t know or care whether open source software or proprietary software was behind it, which led to similar valuations for open source software companies and proprietary software companies, while also showing that open source has real economic and strategic value.
A series of acquisitions, including my own startup XenSource being acquired by Citrix (not to mention Sun acquiring MySQL and Oracle acquiring Sun), made open source a key component of large tech companies. In 2001, Microsoft CEO Steve Ballmer called Linux a “cancer.” Now, even Microsoft uses open source software in its tech stack and invests heavily in open source projects. Therefore, the next open source startup may well emerge from a large tech company, just as it might emerge from an academic research lab or a developer’s garage.
The Virtuous Cycle of Open Source
The history of open source shows that its rise is due to a virtuous cycle of technological and business innovation. On the technology side, open source is the best way to create software because it accelerates product feedback and innovation, improves software reliability, expands support scope, drives adoption, and pools technical talent. Open source is a technology-driven model, and these characteristics have existed since the “free software” era.
However, only when technological innovation combines with business innovation can open source’s potential be fully realized. Without business models (like paid support, open core, and SaaS models), there would be no open source renaissance.
Economic benefits create a virtuous cycle. The more business innovation we have, the larger the developer community becomes, which stimulates more technological innovation and increases the economic incentives for open source. Finally, I’ll talk about views on the future of open source 3.0 and point out some interesting innovations currently happening in technology and business.
But first, let’s talk about how to establish open source enterprises.
Three Pillars for Open Source Enterprise Success
Open source enterprise success is built on three pillars. They start as sequential stages. In a mature company, they become pillars that need to be maintained and balanced for sustainable enterprise development:
Project-Community Fit: Your open source project creates a developer community that actively contributes to the open source codebase. This can be measured by GitHub stars, commits, pull requests, or contributor growth.
- Product-Market Fit: Your open source software is adopted by users. This can be measured by downloads and usage.
- Value-Market Fit: You discover a value proposition customers are willing to pay for. Success here is measured by revenue.
- These three pillars must run through the company’s entire lifecycle, and each pillar has a measurable goal.
Project-Community Fit
Project-community fit is the first pillar, concerning the critical community masses and the project’s appeal to developers. Although open source software communities vary in size, a loyal following and growing popularity are key indicators that an open source project has激发d strong interest among a group of developers. These indicators include GitHub stars, number of collaborators, and number of pull requests.
Open source projects can be initiated in many places, including large companies or academia. However, where the project starts doesn’t matter; what matters is having a project leader to drive the work, and this project leader usually becomes the CEO of the commercial entity.
Achieving project-community fit requires high-touch engagement and continuous recognition from the developer community. The best project leaders will strike a delicate balance between inclusion and assertion—making clear decisions to indicate project direction while ensuring everyone’s voice is heard and contributions are recognized. When this balance is achieved, the project will continue to develop healthily and attract more people to participate in contributing and distributing the project.
As investors, we strongly tend to fund OSS project leaders because they understand the inputs and outputs of the codebase and are the guardians of the spirit and vision that sustain the developer community.
Product-Market Fit
Once you have a project leader and a group of active collaborators, the next stage is understanding and measuring product-market fit. In this process, the project leader needs to clarify: What problem does the open source software help solve? Who is it solving that problem for? What other alternatives exist in the market? Without a clear understanding of users and their use cases, the project may be pulled in multiple directions and lose momentum.
When these questions are answered, you can observe natural adoption, such as measured by downloads. Product-market fit is a prelude to future sales activities. Ideally, OSS users will become top-of-funnel leads for value-added products or services—we’ll see more of this as we go to market.
When studying product-market fit, it’s important to consider how to describe your commercial product and how you’ll deliver value people are willing to pay for. I want to point out that there’s a common pitfall: sometimes OSS products might be too good. Product-market fit might be so good that there’s no need for value-market fit, which means no natural expansion to drive revenue. Therefore, while driving natural adoption, you and your community should carefully consider what you might commercialize in the future.
Value-Market Fit
The final stage, usually the most difficult, is finding value-market fit and generating revenue. Product-market fit is usually obtained by individual users, while value-market fit usually centers on departmental and enterprise buyers. The secret to value-market fit is focusing on what customers care about and are willing to pay for, not what you can make money from.
Value-market fit usually has less to do with product features and more to do with how the product is adopted and what type of value it drives. The value OSS provides lies not only in its features but also in its operational advantages and scale characteristics. Therefore, when considering commercial products, consider these questions: Does your product solve a core business problem or provide clear operational advantages? Is it hard to replicate or find alternatives? Are there scale characteristics needed by teams or organizations that aren’t implemented in OSS?
While this list isn’t exhaustive, open source companies have found value-market fit features such as:
- RAS (Reliability, Availability, Security)
- Tools, plugins
- Performance
- Auditing
- Services
Choosing a Business Model
The business model you choose depends on what value you can provide to customers and how best to deliver that value. Note that these business models aren’t mutually exclusive, and you can build hybrid businesses using elements from multiple models.
Support and services are the open source 1.0 era model, where RedHat monopolized the market and achieved scale. If you decide to go down this path, you might eventually compete with RedHat (which is why five years ago, I wrote a blog post “Why There Will Never Be Another RedHat: The Economics of Open Source).
The open core model adds value-added proprietary code layers on top of open source software, which is a good model for internal software. If you have super valuable components (like security or integration) that can be kept proprietary without affecting open source adoption, then open core will be a good model. Note: With open core, community alienation can become an issue when deciding which features belong to which code. I saw this in my own company; finding the right approach to calibrate with the community is very important. The ultimate trap here is that the community decides they don’t like your behavior on the proprietary side, so they fork the project or start a new project around the same codebase.
In the SaaS model, you provide complete hosted software. If your value and competitive advantage lies in the operational excellence of the software, then SaaS is a good choice. However, since SaaS is usually cloud-hosted, public clouds might choose to take your open source code and compete.
Cloud & Competitive Barriers
Once open source enterprises reach a certain maturity, the threat from public clouds and licensing topics may arise. Licensing is a hotly debated topic, and while it’s important, I see companies spending too much time discussing licensing early on.
I also think we over-focus on threats from public cloud providers. While these providers might offer open source projects, to date, as far as I know, no open source company has been completely replaced by a cloud provider.
For open source companies, the more important question is: if code isn’t the competitive barrier, then what is?
The answer goes back to open source’s original strength: community and your perspective on development. Independent open source companies have three major competitive advantages:
- Enterprise customers don’t want to be locked in by vendors;
- Enterprise customers want to buy software from the people who write the code;
- Large companies don’t have your expertise.
When you combine these three things, I think this is a truly competitive value-add, and why we haven’t seen big cloud providers completely replace independent open source companies.
Now that we’ve covered these three pillars, let’s look at how to build an organization around them.
For open source companies, the more important question is: if code isn’t the competitive barrier, then what is? Community.
Going to Market: Open Source at the Top of the Funnel
Your open source community is a developer-driven top-of-funnel activity. Building an enterprise is about connecting this open source top-of-funnel to a strong value-driven commercial product. The funnel idea isn’t new, but it’s truly different for open source companies. In this section, I’ll introduce how open source work integrates and blends into commercial work at different stages of the funnel, and how to make each stage work in coordination with other stages.
The open source go-to-market funnel is divided into four stages and key organizational functions:
- Developer community management promotes awareness and interest in your open source product.
- Effective product management will bring large numbers of users to your free open source product.
- Leadership and business development assess these users’ intent to identify potential value and sales opportunities in the enterprise.
- Self-service (bottom-up) and sales service (top-down) deliver and scale the value of paid products or services to the enterprise.
Let’s look at these stages and functions in more detail.
Stage 1: Awareness and Interest—Developer Community Management
Driving developer word-of-mouth—measured by user signups and downloads—is critical for success in later stages of this funnel. When a company is founded, founders are often the first evangelists during this period. As the company expands, having a dedicated team of developer evangelists with both strong technical skills and strong communication skills is very important. While this is usually a rare combination, when a person has both technical and communication skills, they’re often easily spotted. Once you find such developers, hire them, let them communicate with the developer community at conferences and on social media, and explain the importance and value of your project.
While you need to align sales and developer messaging, you don’t want your community managers to “sell.” They should generate interest in the product and help people understand it; emphasizing sales might damage their credibility in the community.
When founding a company, you also need to decide whether it has the same name and brand as the open source project. Either approach has worked for companies, each with pros and cons. Independent names, like Databricks and Spark, can prevent brand dilution and provide licensing flexibility, while the same name can usually provide more momentum for the OSS project but might alienate the open source community if they think they’re being used for profit.
Finally, user signups and downloads are common standards for measuring open source software and proprietary software, so the secret isn’t what you measure, but the precision of measurement. At XenSource, we once got inaccurate numbers because the downloads we measured included a large number of downloads that had started but hadn’t completed. Continuously optimizing how you measure user signups and interest will prevent downloads from becoming a vanity metric that can’t achieve the next funnel stage.
Stage 2: Consideration—Product Management
The next stage is consideration. Once you’ve engaged the developer community, your goal is to maximize developer and user love, adoption, and value. The second stage of the open source funnel is usually accomplished through product management.
Effective product management will perform many functions to support this stage: managing closed-source roadmaps and open source roadmaps, communicating decisions with developers and users, building analytics into products to gather more information about usage patterns and predict sales opportunities.
Unlike proprietary software, open source enterprises usually need to manage two roadmaps. OSS CEOs and founders usually spend most of their time managing these roadmaps and how one satisfies the other. I like to see them on the same page so it’s easy to see the relationships between them and what features each provides.
The most successful companies and founders have a framework or guidelines to help them describe and communicate what’s paid and what’s free. For example, PlanetScale is committed to ensuring that projects that create vendor lock-in are open sourced, which brings the value of maintaining good will from both the open source community and enterprise customers. Having a feature comparison table is helpful so customers and the community can understand the different values provided by free software and paid software.
Transparency in research and development and incorporating community feedback into your product roadmap is particularly important for maintaining community trust. Many successful open source companies remain active and are often the main contributors to corresponding open source projects. For example, Databricks’ contribution to Spark is 10 times that of other companies.
When it comes to the product itself, you should build analytics to help you understand users and predict the percentage of OSS users who will convert to buyers. Once users have the product, product usage analytics will help you determine product-market fit through value-market fit and figure out the number of people moving from free users to paid users, which can then predict sales opportunities. For example, if 5 out of every 100 users always convert to paid users, you can use 5% as an estimate to build your financial model.
This can be a complex process, and you should experiment with different product packages to identify the best boundary between free and paid. For many open source founders, this product experimentation is an endless journey, and product go-to-market success depends on tight product feedback cycles.
Stage 3: Evaluation & Intent—Lead Generation & Business Development
The next stage of the funnel—evaluation and intent—is about validating and refining theories related to lead generation & business development. The goal is to find the successful path from users to enterprise buyers through the success metric of sales qualified leads (SQL).
The first part is outbound marketing. Outbound marketing should prioritize specific market segments based on patterns known by developer evangelists at the top of the funnel. Focus on your open source users to understand which roles and departments are using the product and what their interests are. Then, you can target outbound marketing at engineering managers, DevOps, or IT personnel who think your product is valuable.
Next is sales development work. Sales development representatives (SDRs) should adopt an approach that makes customers successful rather than just selling products, and always be curious about user needs and their product usage.
When you get leads from activities, there are two main screening criteria: 1) What organization does the developer or user represent? 2) Have they downloaded or participated in your project, and is the goal to use it as something that helps achieve larger enterprise goals?
Stage 4: Purchase & Expansion—Inside & Field Sales
Once you have qualified leads, you might have two types of activities selling to enterprises. The first might be a self-service bottom-up activity where users within the enterprise gradually adopt and pay for the product. Generally, this product is for individuals. The second is a sales service activity that uses a more traditional top-down approach, transacting at the department level or expanding usage across the entire enterprise.
What Success Looks Like, What Failure Looks Like
As my colleague Martin Casado pointed out in his book “Growth, Sales, and a New Era of B2B”, treating organic growth and enterprise sales equally can lead to several common open source business failure modes. First, your open source users won’t become buyers. In this case, you have good product-market fit but no value-market fit.
In the second failure mode, your OSS project development lags behind your enterprise sales. At this point, product-market fit might not be very good. In the third case, your commercial product damages your credibility in the developer community. There might be too much proprietary stuff and too little open source, so your open source project loses vitality.
The top of the funnel is key to all subsequent work, so first invest in your developer community, open source project, and users, then formal marketing and sales. Never forget these three central questions: Who are your users? Who are your buyers? How do your open source and commercial products provide value to each?
If successful, you might see a chart similar to the one above. The y-axis is revenue per customer, and the x-axis is time. This chart is what I directly observed as a former GitHub board member, showing top-down and bottom-up sales as their revenue is aggregated. The point here is: if your revenue looks like a layered cake, that’s a good sign. The orange line is bottom-up revenue from individuals, usually there’s such a revenue line. The next revenue line might be selling to department buyers, but this is top-down, usually using inside sales. The next part of the layered cake is field sales, or direct sales, selling or expanding accounts across the enterprise. To optimize each revenue line, don’t conduct sales activities randomly; find someone with specific functions who purposefully drives this work.
Finally, depending on your product, you might only have self-service or only inside sales. That’s fine, depending on the complexity of the product and where and how best to use it. I do find that most open source companies have some combination of top-down and bottom-up sales activities, usually starting with bottom-up and then adding a revenue expansion activity on top.
OSS 3.0—Open Source Becomes Part of Every Software Company
Just as software ate the world, open source is eating software.
Today, almost all major tech companies, from Facebook to Google, are based on open source software. These companies are also increasingly building their own open source projects—for example, Airbnb has over 30 open source projects, and Google has over 2,000!
In the future, this virtuous cycle will continue. Technically, artificial intelligence, open source data, and blockchain are some examples of emerging innovations. The next generation of business models might include ad-supported OSS (just like large proprietary enterprises support open source projects), data-driven revenue, and crypto tokens (monetizing blockchain).
I believe open source 3.0 will expand our thinking and definition of open source enterprises. Open source will no longer be just RedHat, Elastic, Databricks, and Cloudera; it will be—at least in part—Facebook, Airbnb, Google, and any other enterprise that uses open source as its core business. When we look at open source this way, the ongoing renaissance might just be in its infancy. The market and possibilities for open source software are far greater than we imagine.
Original link: https://a16z.com/2019/10/04/commercializing-open-source/
Reposted from: Developer Relations »
