It all sounds so straightforward: Put your code up on GitHub or start/join a project at the Apache Software Foundation (ASF), build a community of like-minded individuals, start a company, take in some funding, and then IPO. Or maybe not. One thing is certain: Running an open source company has unique challenges and opportunities. Although much has been written on the subject of open source and community building, I'd like to share three critical lessons learned in my travels as a co-founder and CTO of a venture-backed open source company.
First some background: Lucidworks is in the search and information access business. Our goal is simple: We want to make information more accessible. We do this by leveraging search, machine learning, natural language processing (NLP), and other emerging technologies. We implement this vision by building heavily on open source, both as contributors to and consumers of a large variety of projects. The main projects we build on are Apache Lucene and Solr, but we also rely on other open source projects, such as Apache Spark, Hadoop, and Tika. Our business model is twofold:
- Build a commercial product that extends the open source (aka, "open core") model, and that accelerates development and deployment
- Provide enterprise-grade support and an SLA for organizations deploying Solr. Both products are sold as an annual subscription.
Lesson I: What to contribute, what to sell?
We formed Lucidworks to build on an existing, well-established community at the ASF. Unlike projects that are open source but not open development (i.e., are run by a benevolent dictator), we often have to work with people who have other interests than our own. For people not used to that model, it can present some development, marketing, and selling challenges. For instance, the community may take on different implementations than you or even contribute features that you have been working long and hard to add to your commercial product as a differentiator. Moreover, you likely don't even own the actual brand you are commercializing. The key to this approach is to actually embrace the chaos: Communicate your intentions early for open source contributions, strive to bring the community together with live and virtual events, and work closely with others on their implementations to be sure your use cases are also addressed. Most importantly—and this took us a few attempts to get right—look to make contributions that enable you to do higher-level functionality, instead of doing a one off implementation in your product. For instance, we contributed core analytic functions that enable us to power recommendations in our product.
You might ask, "Why not open source it all and just provide support?" It's a fair question and one I think every company that open sources code struggles to answer, unless they are a data company (e.g., LinkedIn, Facebook), a consulting company, or a critical part of everyone's infrastructure (e.g., operating systems) and can live off of support alone. Many companies start by open sourcing to gain adoption and then add commercial features (and get accused of selling out), whereas others start commercial and then open source. Internally, the sales side almost always wants "something extra" that they can hang their quota on, while the engineers often want it all open because they know they can take their work with them. In a perfect world, you could try both experiments and put the genie back in the bottle if one failed. For now, we have decided to take a multi-tiered approach:
- We have a team of engineers who do nothing but contribute to the open source projects that form the foundation of our product.
- We commercialize the glue, third-party integrations, as well as the UI on top.
- We provide out of the box implementations of commonly used data analysis techniques.
In particular, item three has proven successful because most companies don't have an army of data scientists on board to build things like recommendation engines, search analytics, and more. The three of these approaches enable us to focus on how we complement and extend the open source, without undermining the community we have all worked so hard to build. It also helps make it clear what gets contributed and what doesn't.
Lesson II: Support vs. Consulting vs. Customer success
In the early days of Lucidworks, our main product was knowledge, as in consulting hours and the proverbial "one throat to choke" insurance policy approach to open source. Sure, we had a commercial product, but the main thing we sold was access to smart people who knew the core codebase. We sold a lot of consulting hours and support subscriptions, which was great for acquiring knowledge of the wide variety of deployments of our technology in the wild, but not so great for building long-term value, because once the issue is fixed, you often are no longer needed. Even our support contracts often only went for one year terms back then, because Solr pretty much just works and customers would realize that they didn't need break/fix insurance.
A funny thing happened in that time, though: We came to recognize that, although Solr didn't break (for the most part—it is software, after all), our customers kept asking us how to do harder and harder things. For instance, once they had basic search working, they wanted to know how to integrate NLP tools or factor in user feedback loops to improve relevance. These questions most often just needed an hour or two on the phone to point them in the right direction. Additionally, they greatly informed our product management team as to what customers cared most about. From this knowledge foundation, we have successfully evolved our support model to what we call our Customer Success model. In the past, any hard questions we received from customers were met with a pitch for consulting hours. Now, we treat these questions as if they are normal support questions and engage with the customer to make sure they are successful. (Anything more than a day is still likely consulting.) Many of these questions and suggestions are also fed back into the product to make it better. Additionally, we are much more proactive in reaching out from support, instead of waiting for the phone to ring. It may seem obvious, but I think for many open source companies that are built-on a support model mentality, where the goal is call deflection and self service, the difference is quite sharp. The upside is you are much more engaged with your customers, your product gets better because it is sharply focused on what people care about, and everyone is happier, including your sales team.
Lesson III: Managing the people part
As with any company, you don't succeed or fail based solely on the product itself, but also because of the people around you. In open source, one of the keys to hiring is finding people who align not just with the open source nature of the company, but also the commercial aspects that pay their salaries. If you are all open source, this is easy as the two are in perfect alignment (assuming people will actually pay for support alone). If you have a mix of free and paid, this can be more challenging, as sometimes people coming from closed source won't get the open source side of things (which is less common these days, due to the ubiquity of open source) and sometimes those coming from open source won't get or won't want to work on anything that isn't open.
The other challenge/opportunity on the open source people front is that many of the engineers you likely want to hire from the community will be remote, so you must build a company that can successfully support distributed employees. One of the more interesting challenges for us, especially in the early years, came from the engineers who were in the office, but not for the usual "out of sight, out of mind" reasons that most work from home employees are challenged by. Because most of our engineers at the time were distributed and were very used to distributed, asynchronous communication, they had a lot of ingrained open source conventions to development that didn't always translate to those used to in-office, proprietary development workflows. The key, of course, is communication and documentation, but you may not even recognize it is happening until you realize there is some event that highlights the disconnect. Thankfully, there are many great tools available that enable collaboration and can reduce any potential friction, but be sure also to budget for plenty of face to face gatherings, which is something we do several times a year as a whole team, and more frequently as smaller groups.
Finally, you must recognize that not all people are capable of working remotely. For example, jobs requiring a high degree of collaboration or that are visually oriented often are best done in person. For us, much of our server-side team is remote, whereas the large majority of our product management and UI team is together. The latter benefits significantly from the, "Hey, come look at this," type of interaction that being in the same room provides, whereas the former often benefits from large swaths of uninterrupted time.
Are we there yet?
As anyone who has ever done a startup before knows, you will go through many ups and downs as you seek out a business model that is repeatable and scalable. For us, the lessons above were hard fought and critical in not only building a product that we can sell, but also in hiring good people and building a broad community of users. Beyond that, if I've learned nothing else from 10+ years of contributing to open source, it is this: You never know where the next good idea is going to come from, so be open to it and grab on for the ride.
Quill
This article is part of the Apache Quill column coordinated by Rikki Endsley. Share your success stories and open source updates within projects at Apache Software Foundation by contacting us at open@opensource.com.
Comments are closed.