Refactoring open source business models
Running an open source business is a lot different than being a part of an open source community.
Navigating (source: From "Letters from High Latitudes ...", The British Library via Flickr)
I’ll never forget my first sales call at Lucidworks. We had just raised our first round of funding and hired our first salesperson. I joined the call with a prospective client as a technical resource. By the end of the call, I had answered all of the prospect’s technical questions—and in turn ruined the opportunity for the salesperson. The prospect could now go solve their issue without the help of our company.
I quickly realized that running an open source business is a lot different than being a part of an open source community. Over the years, variations on this theme have come up on a regular basis, as we’ve grown from primarily a support-based business to a product-focused organization. Like every business, we had to figure out how we were going to make money. Open source businesses have unique challenges as a result of the main product being freely licensed. In the best case, this causes significant downward price pressures, and in the worst case, an expectation of free: free software, free knowledge, free support.
Learn faster. Dig deeper. See farther.
If you want to build a business on an open source project, you’ll need to figure out how to navigate this reality—or not play at all. The situation gets even more complicated if “your” code base isn’t actually owned by you, as is the case when the software is owned by an open source foundation, such as the Apache Software Foundation, and you often have competing interests playing in “your” sandbox.
At Lucidworks, we’ve gone through several iterations of trying to answer the “how do we make money” question, the first few being primarily flavors of consulting and support. This gradually evolved to our current model of selling a platform built on open source as well as a support option for those wishing to build directly on the open source. There are pros and cons to each of these approaches.
Although consulting can make for a great income for the right team, it’s hard to scale, has thin margins, and rarely sees the type of returns a venture-backed company is expected to bring in. For us, early consulting projects were critical in learning what features to build.
Support can be a really nice line of business if your software is ubiquitous and you can convert a percentage of users to recurring contracts. In some cases, support is only needed for the early, buggy years of the software, and companies are forced to come up with a different model for sales once customers are up the initial learning curve and successfully deployed.
Many companies choose to build commercial extensions for open source projects, hoping they can get people to pay for value-add capabilities. The challenge here is fear of vendor lock-in, or being forced to support and differentiate against similar features being built by the community. If you find a sweet spot, you can maintain margins while still being good stewards of the community, but it takes a keen eye for product development, and is often grown into after doing a fair bit of consulting and support to better understand what users actually need.
What’s the best option? The answer, of course, depends on a variety of factors, including the particular capabilities of your open source project, how the company is capitalized, the team’s skill set, and the competitive landscape. Hybrid models also can be viable, as long as you aren’t spreading yourself too thin.
In the end, as an open source company, you must decide early on how to get out of the “it’s free” trap relatively quickly, while still growing and nurturing a community. Just as with software, you should never be afraid to refactor the model if it isn’t working.
This post is a collaboration between O’Reilly and Lucidworks. See our statement of editorial independence.
A version of this post was published at Opensource.com.