How do you build a successful, profitable company on top of open-source software, when you’re giving away the core product? In this post, which accompanies a talk I’m giving at the Linux Foundation’s 2018 Open Source Leadership Summit, I’ll discuss how building a company on an open-source foundation is a fundamentally aggressive move, yet has the potential to create a strong ecosystem and community that can lead to greater profitability and agility than a traditional, closed-source business.
Over the last ten years, Chef has launched multiple popular open source projects. Open-source projects become successful in many different ways. Sometimes they are overnight successes, like the Chef configuration management project, because they solve clear, immediate pain in a way that’s different than how others have solved the problem. Sometimes, like the InSpec compliance-as-code project, they provide a fresh approach to a longstanding problem – communication between security engineers, devops, and compliance – in a way that nobody has solved it before. Or, as with Habitat, they immediately attack a problem attractive to enterprises, who have tens of thousands of applications they’re seeking to modernize, make portable, and cloud-native.
Success means that a project spawns a passionate worldwide community and dozens of tertiary projects around it to do additional jobs to extend that project’s reach. This happened initially with Chef. It is an incredibly healthy pattern for an open source project and one that we now intentionally repeat at Chef Software. We see this repeated in other long-lived and successful open source communities that are not our own: know what your project is, and where its boundaries lie. Make it open and extensible so that additional related projects can grow around it – but don’t try to cram every job into one project or to own the world.
Building an Open-Source Business
Great. Now that the open-source project is successful, how do you actually drive a profitable, successful business out of it?
The most crucial concept you must be ready to embrace as a company is that launching and maintaining an open source software project is a fundamentally aggressive move that you must commit to for several years in order for the move to make sense in the
first place. You are giving away valuable software for free, to build a community. That is risky and requires an investment of valuable engineers, product people, and community builders that could be spent on other efforts. It also takes time.
You must launch the software, evangelize the software, show progress on adding needed features and extensions to the project, show good community management and engagement practices and successfully encourage people who are not members of your company
to begin to trust and use and contribute back to the project, of their own good will and in their own time (or company’s time).
As the Chef project grew, Chef Software evolved a reliable approach to understanding how to build a business that exists in harmony with the tools it ships. Many people (us included, for a short time), experiment with paths that restrict the adoption of their kit and ultimately hurt the community, the worst possible outcome for an open source project. Tactics such as “open core,” or attempting to leave out important building blocks of value to your project in order to monetize them later, end up hampering adoption and alienating the very people you open-sourced your valuable software to gain the attention and adoption of. Other common anti-patterns include only open-sourcing your points of integration, which strongly discourages community growth and the ability to contribute back; support-only business models, which generate returns that are untenable for a venture backed company; and the cardinal sin of conflating your community members and software users with your enterprise software buyers.
We’ve learned quickly, and established a regular model of open sourcing projects across the board – from Chef’s infrastructure as code, to Inspec’s compliance as code, to Habitat’s application automation framework – where the entire engine of automation and value is completely open sourced. This is the gamble and the investment you have to make if you’re going to compete in this space: any other offer to a community is limited and ultimately unacceptable.
From this basis of value, we have a strong and varied platform of incredibly powerful open source tools to drive a vibrant and satisfied community of users and contributors. Next step: profit!
An Enterprise Product On Top of Open Source
When you’ve accepted that the entire engine must be open in order to succeed, users can trust and rely on your software to begin to drive huge workloads of their own business value. Scrappy startups will try out your tool, and if your net is wide enough, a few of them will grow to incredible size, giving you the opportunity to prove yourself at scale. For Chef, this happened with several notable accounts, including Facebook. These initial successes begin to open the door to on-site success with large enterprises.
Now you are able to build a sales model and practice as you gain access to the future buyers of your software. Enterprises have unique management and control requirements and needs that do not impact the power and completeness of an open-source automation engine. In a rapidly changing technology space, they need cutting edge technology partners to help advise them in how to adopt the latest software practices, agile processes, and out-compete new and existing challengers by being the most agile and modern development shop.
Since the path to building a successful software business lays in having valuable software to sell, this means building an enterprise control plane that can provide every layer of role based access control and team collaboration and management, and can fully comply with worldwide government, financial, and industry regulations. It means understanding how to integrate with enterprise workflows and tooling so you can add in your product as seamlessly as possible to start moving workloads and shipping customer business value fast, without requiring huge and costly migrations off existing toolsets or re-writing thousands of valuable but older applications from scratch to adopt a new framework. If you write the basis of these tools in a future-focused manner, then as you invest in creating new open source technology and popularize those tools, the control plane you’ve developed can grow with you, creating views and management layers for new personas, and opening your business up to new sales opportunities within different departments.
Deciding on Consumption Models
You can deliver your control plane in three main ways: on-premise deployments, SaaS, and PaaS. On-premise is still crucial for enterprise and government sector adoption, at least today, and may always be as the various cost-benefit analyses of cloud adoption versus data center control continue. However, it can be incredibly healthy for an organization to commit to a SaaS or PaaS offering of their control plane both to have a robust offering to cloud-comfortable clients and the mid-market, but also to require operational excellence and expertise in your own kit as you evolve it far faster than an on-premise product that is infrequently upgraded. Living and dying by your own software every day means it will get better, fast, and you can provide that benefit directly back to both cohorts of customers.
At Chef Software, we have Hosted Chef, Opsworks for Chef Automate where we partner with the AWS Opsworks team to provide our premium product as part of their managed offering, and AWS and Azure marketplace images for Chef Automate. Also, the Habitat project runs its own Habitat Builder which is made available for free to the community to power their builds. Each of these projects has taught our teams invaluable lessons about running our software, both proprietary and open source, in different scenarios and at different scales, that we can then feed directly back into both our open source projects and our premium management platform.
Conclusion
Open source software provides a fantastic engine on which to build a profitable and successful company, when deployed strategically. Key things to remember when you are considering going down this route are:
- Launch: Make a set of valuable software available, for free, no strings attached.
- Commit: Commit to maintaining and building the project for a significant period of time, remembering that innovation investments show a period of return only over a five-to-ten-year period.
- Run it: be a very large consumer of your own technology, so that you have a deep investment in making sure it runs well every time, at scale.
- Be open: Be prepared to see people use your technology in ways you never imagined (or may even philosophically disagree with), and be excited for it.
- Have clear boundaries: Know organizationally what belongs inside and outside of your open source project, and encourage extensibility so that projects that integrate very well but belong elsewhere have a robust and supported way to grow around you.
- Align your go-to-market: It is incredibly tempting to step outside your organization’s comfort zone when you have a cool new project that can extend your addressable market, but land it with your core users first, so you can leverage your existing sales and product marketing strength, and seek to expand as the next step when you’ve succeeded in enabling your existing team.
- Know the difference between your community members and your purchasers, and honor both personas with the products you build together.
