PostgreSQL vs. MySQL. MongoDB vs. Cassandra. Solr vs. Elasticsearch. ReactJS vs. AngularJS. If you have an open source project that you are passionate about, chances are a competing project exists and is doing similar things, with users as passionate as yours. Despite the "we're all happily sharing our code" vibe that many individuals in open source love to project, open source business, like any other, is filled with competition. Unlike other business models, however, open source presents unique challenges and opportunities when it comes to competition.
Can you imagine, for instance, if Ford published every last detail about its latest design, specifications, and process for its newest car before it rolled off the assembly line? Or if Apple did the same for the iPhone? Yet every open source company does this regularly. Additionally, many open source companies even have competitors contributing to the same product, sometimes resulting in heated, public discussions. For instance, in my world of search, my company (Lucidworks), Elastic, and IBM all contribute to the Apache Lucene and Solr projects, even while competing on the business front. Likewise, Hortonworks, MapR, and Cloudera all contribute to Apache Hadoop, competing in the big data space.
Returning to our Ford/Apple question, let's assume they did publish the details—does that mean General Motors or Samsung should spend time trying to make sense of those plans beyond a cursory review? This question illustrates one of the many unique opportunities and challenges that confront open source projects and businesses with regards to competition.
Commoditize, commoditize, commoditize
Regardless of whether your competition is open or closed, you should expend effort to open source—via clean room implementations, if necessary—key proprietary features of competitive products as quickly, efficiently, and cheaply as possible, effectively devaluing that feature. For instance, in the early days of Solr, the main competitor, especially in e-commerce, was Endeca Search (now owned by Oracle). Endeca Search users loved its ability to do faceting, a feature that counted the number of items with specific attributes in a set of search results (e.g., in a search for computers, the facets might show how many of those results have 32GB of RAM vs. 16GB vs. 8GB). Solr 1.0 didn't have faceting, but it quickly was added and it has expanded quite a bit since then. Likewise, these days, all of Solr's security features are free, whereas Elastic's are not.
Be aware, however, that commoditization can only be one part of your product strategy, and you should fully expect your open source competitor to do the same thing to you. Being a commodity of anything, by definition, means you will forever be facing downward price pressures due to the lack of differentiation and low barrier to entry. You may be fine with the requisite high-volume, low-margin business that goes with it, but at least be aware up front that this situation is what you will be supporting.
Don't be your own worst enemy
Like any other business, an open source business needs to make money. To do so, business leaders must understand what customers are willing to pay for (and what they aren't). For those open source companies selling a licensed product—rather than support and services—this often means adopting an open core approach, whereby part of the product is open and part is closed. This dichotomy always leads to a point in which not only your prospects, but also employees will ask, "Why not just use the open source version instead of paying for the product?" This is especially true for products based on community-driven governance, like those of the Apache Software Foundation (ASF). If you take an open core approach with your business, you must have a ready answer. You need to discuss and develop a shared vision of where and how to contribute to open source in a way that places sales, developers, product management, and support all on the same page.
Our first attempt at this (for our original product from way back when) was largely a failure, in hindsight because it lacked differentiation from Solr. I'm optimistic that our latest iteration of the product is trending in the right direction, in part because we've solved our internal conflict over what should be open sourced and what belongs in our product.
Peekaboo, I see you
At this moment, your competition is adding new features to their open source project, showing the world what they plan for future releases. Should you look? Keep a few things in mind:
- Heed the license. If your competition's license is not compatible with your license, you may want to avoid looking at the actual implementation and instead look at higher-level aspects, such as feature descriptions and discussions. Consult your legal department if you have doubts. You can borrow liberally if the licenses are compatible and the code is easily ported; otherwise, implementing the idea from scratch or adapting an existing feature to handle that use case is a better option.
- Try to limit the time you spend on analysis, because obsessing over every last change is all too easy. My first boss out of college used to joke that one of the best things you could do to your competition is give them your code, because they will then spend six months or more trying to understand it while you've moved on with your work. The reality is that most of your competitor's code isn't going to be applicable directly, so make sure to do a survey of the code to identify key features that you can re-implement. Also, look for weaknesses that you can leverage in sales and marketing. Do this every so often, depending on the frequency of changes or when key things change; otherwise, don't waste your time.
- Recognize a good idea when you see it. Many software shops refuse to recognize how competitors are changing the market or creating new markets. We wasted a lot of time in Solr a few years back dismissing ideas to improve ease of use, such as a schemaless datastore, and usability features that other NoSQL engines made cornerstones of their products. I think for the most part we've overcome other search engines when it comes to ease of use (and surpassed them in some cases). For a while, dismissing usability features hindered user adoption and created a perception that Solr was for only experts or users who have a lot of time to invest.
Coopetition: Why does something so right feel so wrong?
Two of the best developers on my "team" are not now, nor ever have worked for my company. In fact, they both currently work directly for one of our competitors, and they do good work making Lucene and Solr better. Such is the reality of open source projects, especially those run by foundations like the ASF. The lines are not always drawn clean and you won't always be happy, but in the long run you and your competitors benefit if you figure out a healthy balance for working together. Explicit conversations with competitors isn't required—you just need to be aware of what you care about in the code, and what they care about in the code, and plan accordingly.
Even though you are competing directly with each other in the marketplace, you both are likely competing with many other companies and projects in a much broader market. Keep in mind you are probably not in a winner-take-all market, and your competition may actually help you grow the overall market size. Given the real world of mergers, acquisitions, and job changes, you may find that one day you are working together with those same developers, so why not declare the codebase a DMZ? You'll have plenty of places to engage in the broader landscape about why you are better than your competitor.
Sometimes you just need to survive
For me and my company, late 2013 and early 2014 was a dark time. Our community seemed to be getting crushed by a hype cycle around an up-and-coming competitor, and internally we were struggling with how to discuss said "company that must not be named," and we had—emphasis on had—an undifferentiated commercial product. In hindsight, we also were suffering from the curse of knowledge cognitive bias and did not recognize a mind-shift in the way people were developing applications and why.
On the positive side, we knew our open source project had a number of high-quality, proven features, and we had a large community install base that wasn't going to vanish overnight. We also had a pretty good inkling that machine learning and more advanced features around natural language processing and higher quality relevance were going to become more important as people moved from their baseline implementations to more advanced ones, and things like ease of use would become less important. (Who cares how easy something is to use the first week you use it if it can't stay up in production or loses data?)
We also had a hunch that people in the big data world would grow fatigued from managing the complexity of the Hadoop stack, and would like a simpler, easier-to-manage solution with fewer moving parts. Most importantly, we had money in the bank, a supportive board, an injection of fresh talent who didn't have any stake in past decisions, and a mandate to overhaul our product architecture and resolve the dichotomy (what to open source and what to sell) mentioned earlier.
How did we survive? First, we focused on being around long enough to launch our next product by extending our monetary runway through hustle and financial prudence. Second, we focused on building an architecture that complemented the open source product with value-add capabilities the community wasn't interested in building or didn't want to integrate, but that we knew customers needed. Once we achieved that, we focused on creating a culture of winning. Looking back, I realize those dark times were absolutely critical for us to move forward as a business, because they taught us not only what mattered to customers, but also what mattered to us. To paraphrase Rascal Flatts, "Bless the broken road that made us who we are."
Focus on what you can control
Although my focus in this article is on dealing with competition, most of your time is best spent focusing on what your company can control:
- Who you hire.
- What features you develop to differentiate yourself, especially when you are in a coopetition situation.
- How you go to market (pricing, marketing, etc.).
- Helping customers become successful on your product (and understanding and fixing issues when they aren't).
- Your willingness to question your beliefs, learn from your mistakes, and find a way forward. (Regardless of whether you learn from your mistakes, you may be certain that someone else is doing so.)
Evolution
Although my organization has made progress on many of these fronts, we remain a work in progress. Only time will tell whether our approaches ultimately will be successful. Figuring it out is one of the main challenges when starting a company. Stay tuned.
Comments are closed.