How a Successful Open Source Project Becomes a Business

The concept of open source software wasn’t born with making money in mind, so business isn’t a natural segment of most open source projects’ DNA. Yet, an open source project is considered successful when it births a piece of software many people want to use; naturally, high demand for a thing stimulates the entrepreneurial mind, and there are plenty of examples of business success built on top of successful open source projects.

Getting lots of folks to use and contribute to an open source project and getting people to give you money are two different problems of course. It’s a lot easier to get someone to use a thing (especially if it’s a nice thing) if they don’t have to pay for the privilege of using it.

As Kinvolk co-founder Andy Randall put it, “There’s a project and a product, and they aren’t the same thing.” You do need the former to create the latter, but it’s only one piece of the puzzle.

Even the people who use your open source software will in most cases be different from the people you’ll be selling your product to. So, the feedback they give you might help you improve the technology—that’s clearly very important—but it won’t necessarily be the feedback you need to close a deal.

Randall, who delivered a talk about this for the recent Equinix-produced online event titled The Business of Open Source (you can watch all the talks here), speaks from experience. He is currently a principal program manager at Microsoft, a role he took after Microsoft’s recent acquisition of Kinvolk, the company behind the popular Flatcar Container Linux. He also co-founded Tigera, the startup behind the container networking and security solution Calico Open Source.

From a distance, the typical arc of a successful business built on top of an open source project looks something like this (slide by Andy Randall):

That question mark inside the black circle on the slide represents the business decisions, their execution, the outcomes, all the non-technical components that may or may not lead to profit. In his talk Randall described six strategies for turning an open source project into a product and a business. Here’s a rundown of these strategies’ strengths and weaknesses.

Open Source Business Strategy 1: Support and Consulting Services

Assuming an open source project is popular, helping companies use it and collecting fees for doing it is the easiest strategy for monetizing the software. But, after that initial burst of support-contract revenue, it becomes harder and harder to not only scale the business but even keep it at that early income level. (This is why venture capital investors, for example, aren't crazy about this strategy, Randall pointed out.)

Customers pay such a business for the time its experts spend supporting and advising them. That’s time those experts can’t spend improving the product and its scalability. 

There’s also what Randall called “the renewal conundrum.” Paying customers may be reluctant to renew their support contract after a year of using the technology and getting more familiar with it. Besides, the software itself will likely (hopefully!) have been improved over the course of the year, requiring less hand holding by the vendor.

All this doesn’t mean an open source startup shouldn’t pursue a services-based business strategy when getting the business off the ground. It’s an excellent way to roll up one’s sleeves in close contact with the product’s users and learn how to improve it. Plus, that initial revenue potential can be meaningful for an early stage business. (Randall recalled his time with Tigera, saying the startup used to close “seven-figure” support deals in its early days.) But, it’s important to keep in mind that support services aren’t a reliable long-term strategy in the open source context.

Open Source Business Strategy 2: Proprietary Features

This strategy is also known as “open core.” Getting it right is tricky, but it’s a good path to revenue that scales, Randall explained. In essence, it’s the traditional proprietary software business model wrapped around an open source project.

An open-core business keeps its fundamental code base living and developing as an open source project while building commercial proprietary extensions and tools on top.

The tricky part is determining where to draw the line between the open source parts and the proprietary features and making clear where that line is for users. There’s also the risk of undermining the open source project’s success by making the premium features proprietary. It means the open source version isn’t as good as it can be by definition.

The ideal situation is when the commercial features fall in a domain that is separate from the core software, Randall said. A classic example (and a widely used business strategy) is making enterprise policy compliance the commercial feature. Compliance as a product can easily stand completely apart from all the core functionality.

Open Source Business Strategy 3: SaaS

This is another solid strategy for generating and scaling recurring revenue. It takes expertise to run software, and it needs to run somewhere. Not all customers can or want to do that part themselves and will gladly pay someone else to do it. Besides, if the open source startup has the right expertise and a critical mass of customers to scale it across, chance are it can run the code at a lower cost than each individual customer can on their own.

Unlike open core, the SaaS model doesn’t require the balancing act of having to build quality commercial features while keeping the open source software useful and relevant. An open source SaaS company charges purely for maintaining the infrastructure the software runs on, so it’s free to go on building the best features it can build, keeping it all fully open source.

The danger of this approach of course is that someone else can build a SaaS business around the same open source software and run that infrastructure better and cheaper than the original company—especially if that someone else is one of the hyperscale cloud platforms.

Open Source Business Strategy 4: Support Plus Proprietary Features

Randall said he especially liked this business strategy for early stage open source startups, because it combines the best aspects of the open core and support strategies. “And I’ve tried it successfully a couple of times,” he said. Kinvolk used this strategy to monetize its Flatcar Container Linux.

This model packages proprietary features together with support subscriptions. It helps mitigate the pure support-based model’s “renewal conundrum,” because the proprietary features add enough value to justify renewing the subscription.

Kinvolk kept Flatcar entirely open source but hosted an update server for its support subscribers, Randall explained. Each subscriber would get an individual instance of the support server and wouldn’t have to manage it themselves. Between one-third and half of the company’s customers found the product compelling enough to pay up, he said.

A business employing this strategy must make it very clear to its paying customers that a feature they are relying on is proprietary and part of their support contract. The year-end renewal stage would not be a good time for them to realize this, Randall warned.

Open Source Business Strategy 5: Distribution/Branding

One cannot say this strategy isn’t viable, but, according to Randall, it’s only ever worked for one company: Red Hat, which successfully managed to monetize its branded distribution of Linux.

The key to this strategy is to build a very high-quality distribution of open source components, put your brand on it, and protect it with a trademark.

Open Source Business Strategy 6: Dual Licensing

This strategy has become less popular nowadays, because of its many drawbacks. It boils down to creating different licenses for a piece of open source software: a free one with restrictions and a paid one for commercial use.

“As you can imagine, people really don’t like the idea of having an open license which constrains them,” Randall said. “So, it creates some kind of perception issues.”

Pricing in Open Source

With any of the above business strategies, it’s important to remember that the price a startup decides to charge its paying customers should not reflect the value of the core open source technology. That part is and should remain free, Randall said. The price should only reflect the value of whatever it is the company is offering on top of the open source technology.

With the exception of the last two, which got on the list only for the sake of completeness, the strategies aren’t mutually exclusive. Startups can mix and match. A company may enter the marketplace with a support product around an open source tool and eventually transition to being an open core or a SaaS business, for example.

Closed source or open source, business models change and adjust over time. The one constant that remains, however, is the importance of quality of the software at the heart of the open source project and the business.