Refactoring open source business models

https://opensource.com/business/16/4/refactoring-open-source-business-models

They say you never forget your first. In my case it was 2008 and Lucidworks had just raised our Series A round and hired our first salesperson. I was asked to jump on a call with a prospective client looking for help troubleshooting Apache Solr. During the call, the prospect asked me a number of "stump the chump" style questions. After hanging up and patting myself on the back for answering all their questions with flying colors, I got a call from my salesperson. Although I don't remember his exact words, they amounted to:

Salesperson: "Great job, but you just blew that opportunity."
Me: "Why is that? I showed him we knew what we were talking about and gave them the answers they were looking for to fix their problem."
Salesperson: "Yep, you sure did, and now he has all the answers and doesn't need us."

Sure enough, he was right. The follow-up call was quick and to the point: "Thanks for the help, we fixed our issue and are good to go." I quickly realized that running an open source business is a lot different than being a part of an open source community. Don't get me wrong—I'm still happy to share my knowledge and help build community. But I also have to pay the bills, especially in the early stages of the company, and my knowledge and time is my primary asset.

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. And like every business, eventually we have to figure out how we're going to make money. Open source businesses, however, 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.

With customers, the thinking often goes: "We'll just hire a handful of developers who can take the source and implement it, and we can get our answers on the mailing list. Perhaps we'll pay some consultants if we get in jam."

I like to call this the "I want yours free, but you pay for mine" software movement. These companies expect everyone to pay for their product/service, of course. This thinking demonstrates why so many companies are happy to consume open source, but never contribute back. That's not sour grapes on my part, so much as the reality of a lot of software companies these days. I'm not sure how sustainable this practice is in the long run, especially given developer's ever-rising salaries. But it is what it is, and 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 my company, 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—or "open core" as it is often called—as well as a support option for those wishing to build directly on the open source (i.e., community edition) support. There are pros and cons to each of these approaches, some of which I'll outline:

Consulting

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. Consulting businesses are often feast or famine, especially in the early days of an organization's lifecycle. On the pro side, nothing else gives you direct insight into what customers are doing with the software like consulting. For us, our early consulting projects were critical in informing us about what data connectors and administrative features to build. Today, consulting is purposely constrained and is only offered to clients who have a subscription with us or those that are directly contributing back to the upstream open source projects we support.

Support

Often involving a certified distribution of an open source project, support can be a really nice line of business if your software is ubiquitous (think core infrastructure, such as operating systems, storage, computing) and you can convert a percentage of users to a recurring support contract. In some cases, support is only needed for the first year or for the early, buggy years of the software, and companies are forced to come up with another model for sales once customers are up the initial learning curve and successfully deployed. In other cases, such as the highly competitive Hadoop market, the switching cost these days is so little that there is a near constant downward pressure on margins.

For us, a traditional "break/fix" support model didn't work, and instead we switched to a higher touch "customer success" model that involves encouraging customers to ask questions, regardless of whether they would be traditionally triaged as support questions. For instance, in our old, traditional support model, we might only handle requests related to stack traces and production issues, but not business/developer issues, such as how best to improve the quality of results or how to incorporate machine learning into an application. Today, we routinely answer all types of questions, as they help the customer be successful. For those cases in which the answer is more involved or the client wants detailed help, we offer consulting. In many cases, the customer just needed a point in the right direction when implementing a feature. This may seem obvious, but most support centers at most companies are geared toward call deflection, not engagement. Our approach has yielded a significant improvement in renewal rates for us on the pure support side of our business. Care must be taken to make sure support expenses don't spiral out of control, however, and that these touchpoints don't turn into hours of free consulting.

Open core or commercial extensions

Many companies go this route hoping they can get people to pay for value-add capabilities, such as better administration tools. The challenge for companies in this space usually falls under the category of fear of vendor lock-in (never mind that any choice locks you in). Or the community builds similar features, which you're also forced to support and differentiate against. 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. For example, in our first iteration of our product (Lucidworks Search), it was developed mainly by looking at features of the previous generation of search products on the market, and it was tightly coupled to Solr, which prevented users from taking advantage of Solr's full feature set.

Although the product wasn't completely designed in a vacuum, feedback often focused on how we were hiding too much of Solr or that their plugins didn't work with it. Internally, even our own developers often felt conflicted working on it because it was competing too much with the open source project itself instead of complementing it. With our new architecture and product (Lucidworks Fusion), we can connect and work with a number of different versions of the main project (Solr) we support, and we also integrate other key open source projects, like Apache Spark. We look at it as an extension of, not a replacement for the open source. We also look for more ways to capture and use more data intelligently, as opposed to writing smarter, proprietary algorithms.

Cloud/hosted

Some projects naturally align with a hosted model, where the deployment and management of the open source is managed for the customer, while still giving the customer access to the full (or partial) suite of tools of the open source project. If you can achieve a true multi-tenant solution, this approach can yield significant margins with nice recurring revenue streams. The challenges in this space are often associated with data protection, uptime, security, and how to get customer's data uploaded if it is not in the cloud already. Heavily regulated industries (financial services, healthcare) often are especially hard to penetrate due to concerns about security and personally identifiable information. The big cloud providers (AWS, Azure, Google) seem to be going hard after this approach, but niche players can also be successful if you run lean.

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 is the case with software, you should never be afraid to refactor the model if it isn't working.