Taking a break from my recent spurt of writing on the semiconductor industry in China, today’s post discusses the difference between an open source technology and a commercial product that leverages said open source technology. It’s an important, but often not well understood difference, which leads many startup founders down a path of frustration and lacklustre revenue growth, despite having built a fairly popular open source project.
As many readers know, I spend a lot of time and energy actively investing in startups in the developer tool and/or commercial open source space globally. We will produce more materials on Interconnected to help entrepreneurs in this space build successful products, durable companies, and grow in a globally connected market. (These materials will be under the “For Founders” tag.) This post is a refined update of my thinking on this topic, first published on opensource.com a year and a half ago.
Let’s first start with a personal anecdote.
DIY PC vs Polished Mac
My first memory of playing with a computer was through an MS-DOS terminal on the x86 PC in my grandfather's pharmaceutical research lab in Shenyang, China in the early '90s. I played driving games stored on 3.5" floppy disks and practiced touch-typing. As the type of games I wanted to play became more advanced and needed better configurations, I spent an obscene amount of time taking that giant desktop computer apart to add more RAM, a new graphics card, and a new fan. It was a fun, continuous project of tinkering, and I bonded with my father over the experience. It was also way cheaper than buying a new computer.
I didn’t know what "open source" was back then. Unbeknownst to me, my behavior resembled how a typical developer today would treat open source projects. I willingly spent my free time stitching together parts to upgrade my computer -- sometimes because I really needed it, sometimes as a process to learn new things, and sometimes as a way to connect with other people (in my case, my dad).
Over time, I stopped stitching and tinkering. For one reason or another, I decided that my time was becoming too "valuable" to retrofit my old computer. I bought a MacBook, and when it got older and wasn't functioning well, I paid a pretty penny for a new one, instead of unscrewing the bottom to see if I could jam in some more RAM.
My behavior evolved into more of a commercial product buyer -- saving time and trouble by spending money.
You can’t “sell” an open source technology
If your experience with technology resembles mine in any way, you know intuitively that the projects we DIY are not the same as the products we spend money to buy.
This isn't a new observation in the open source community.
Stephen Walli, an IT industry veteran and part of the Open Container Initiative, has written numerous detailed blog posts on this topic. Sarah Novotny, who was an early member of the Kubernetes community and was heavily involved in the Nginx and MySQL communities, emphatically articulated the same point at the first Open Core Summit a couple of years ago.
Yet, the difference between the open source project and the commercial product continues to get mixed up, especially (and ironically) when the open source part is popular. Frustration often ensues when the open source version is clearly popular and growing, but the paid commercial version is not.
How to Differentiate Your Commercial Product?
There are generally two ways to think about commercial product differentiation: packaged experience and buyer-specific needs.
Packaging your project so that it has that out-of-the-box user experience isn't just about a polished user interface (UI) or hosting it on some cloud servers as SaaS (although that could be part of it). It's an opinion of how you, the founder, believe this open source technology should be used to solve your customer's business problem. As the domain expert and oftentimes the creator or maintainer of the open source version, your opinion holds value and is essentially the commercial product experience your customers want to pay for. They don’t want to spend time and energy thinking about what kind of resources, workflows, or best practices is the “right” way to solve their problems.
This opinionated approach stands in stark contrast to running an open source community, where it’s typically good to be not opinionated and let your community members organically use, extend, and flourish, albeit ideally along the same roadmap direction.
It's my retrofitted x86 PC versus the MacBook dynamic.
It’s also a tricky balance to strike, and the most successful founders and executives in this space know when to be opinionated and when not to be.
Dave McJannet, CEO of Hashicorp, and Peter Reinhardt, CEO of Segment (acquired by Twilio), both cited packaging as a crucial step to get right in order to turn an open source project into a scalable commercial product. A convenient, opinionated, and packaged experience around open source is often attractive to startups or small application teams within a big company that have the freedom to experiment. The commonality between these two audiences is that they may have some money to spend, but they are always short on time.
Catering to different types of buyers’ needs, often in the form of closed-source features, is the other way to achieve commercial product differentiation.
This observation is not exactly earth-shattering. But what founders often overlook is how much you can charge for your commercial product depends less on the cost or effort to build it, but more on how much value the buyers assign to what your product can do. The buy-specific needs are not just about features, but also pricing power.
A large, Global 2000 enterprise will have a set of needs and the money to pay for these needs, so your product should be priced accordingly.
A small- or medium-sized business buyer, say your local mom-and-pop bakery, will have different needs with less financial resources, but a faster buying decision-making time than a large enterprise, so your product should reflect those needs and realities.
These differences can also appear along industry lines. A buyer from the e-commerce world (high volume, low margin) may have different buy-specific needs and capacity to pay than a buyer from the real estate industry (low volume, high margin).
As a commercial open source startup team, it’s important to understand the relationship between buyer-specific needs, relative pricing power, and the product and engineering input required to satisfy those needs. This relationship is not always positively correlated. A hard to build feature may not command the highest price.
Sid Sijbrandij, co-founder and CEO of GitLab, has a nice articulation of GitLab's buyer-based open core commercialization model in this video that targets large enterprises.
Certainly, other elements can be added to further the differentiation. But either building a packaged experience or meeting buyer-specific needs is essential. Without one or the other, your prospective customers might as well just tinker on their own, for free.
A perennial difficulty in commercial product development is establishing a metrics-driven framework to determine whether you are on the right track or not. I'm a fan of the One Metric That Matters (OMTM) mentality, elaborated in Lean Analytics, where you focus on one single number (above everything else) at each stage of your startup journey. This approach enforces focus and discipline among a sea of data you can gather and measure without yielding much insight. Organizationally, a single metric can also rally your company around one tangible goal or mission -- especially critical for an early-stage startup, where focus and discipline can both be in short supply.
So what's the right OMTM in the early days of commercial open source product development?
I propose time-to-usefulness.
I used to use “time-to-value”, but it has now become a trendy and diluted term in the industry. The word “value” is also so vague that it has lost a lot of...well...usefulness!
"Time" here is straightforward: shorter the better.
But what is "usefulness"? The plain language definition I use in this context is: “something technical” your user cannot do before but now can. The “technical” part is important, because all open source projects are technical in nature and are intended to solve a technical problem, unlike social media or marketplaces. Thus, the “usefulness” should be technical in nature.
However, the “something” is problem-specific and needs a precise, rigorous definition of its own.
A distributed database is useful, because it can serve production data with no downtime when one or two servers fail (that’s why you have a distributed architecture to begin with). Your continuous integration tool is useful, because it enables application developers to push improvements automatically without breaking dependency and speeds up product iteration (otherwise, you might as well just manually Q&A every change). You get the idea.
How quickly can a customer experience that usefulness is what you measure and optimize for. What is a sufficiently short time? To match the expectations that come with the increasing consumerization of enterprise technology, a product's time-to-usefulness should be 30 minutes or less.
Discovering and rigorously defining that "usefulness" is hard and iterative but worthwhile. It is table stakes in today’s competitive startup environment in the developer tool and/or commercial open source space. Without a deep understanding of what is useful for your customers, there's probably not much of a company to build.
At the end of the day, as much fun as it was to "beef up" my x86 PC, I'm satisfied with my MacBook and happy to pay the premium. So don't get too enamored with the joy of tinkering in open source, if your goal is to sell many MacBooks.
Special thanks to Joseph Jacks and Sarah Novotny for feedback on this post's original draft.
If you like what you've read, please SUBSCRIBE to the Interconnected email list. To read all previous posts, please check out the Archive section. New content will be delivered to your inbox (twice per week). Follow and interact with me on: Twitter, LinkedIn, Clubhouse (@kevinsxu).
那时我还不懂什么是 "开源"。殊不知，我当时的行为和当今的一个开发者对待开源的态度极为相似。我心甘情愿地用我的业余时间去拼接零件升级电脑 -- 有时是因为我真的需要，有时只是想学点新东西，有时则是与他人建立关系和感情的方式（比如说我爸）。
我的行为慢慢演变成了许多商业产品买家的态度 -- 通过花钱来节省时间和麻烦。
Hashicorp的CEO，Dave McJannet，和被Twilio收购了的Segment的CEO，Peter Reinhardt，都公开发表过他们对包装的重要性的观点。要想把一个开源项目变成一个有潜力、可扩展的商业产品，包装是必须要做好的关键步骤。给一项开源技术一种便捷、有“观点”、原装包装的用户体验，对于创业公司客户或大公司内部有自由的小型产品团队来说，非常有吸引力。这两个受众的共同点是，他们可能有些钱可以花，但他们的时间永远是不够的。
GitLab的联合创始人兼CEO，Sid Sijbrandij，对其公司基于“买方开核商业化”（buyer-based open core）在这个视频里有很好的解释，模式主要面对大型企业。
商业产品开发中的一个普遍难题是建立一个以指标为导向的框架，以确定产品是否走上正轨。我很喜欢 Lean Analytics 这本书里提倡的 One Metric That Matters (OMTM)，在每个创业阶段用一项单一的数字来做指南针。这种方法可以有效的帮助团队关注重点，加强纪律，在可以收集的各种海量数据中，不被疑惑和干扰。从动员组织这个层面来说，一项单一的指标也可以使你的团队围绕着一个具体的目标或使命操作具体任务。这对早期阶段的创业公司来说尤其重要，因为在这个阶段，专注执行和保持纪律的能力普遍都很匮乏。
过去我一直用 "时间到价值"（Time-to-Value）这个概念，但它现在已经成为行业内一个时髦又淡化的流行词汇。"价值" 这个词本身也太模糊了，已经失去了应有的......有用性!
但 "有用性"（usefulness）该怎么去想呢？我喜欢用的一个通俗定义是："某些技术问题，用户以前做不到的，现在可以做到了”。"技术" 这个部分很重要，因为所有的开源项目都是从解决某个技术问题开始的，与社交媒体或双边市场模式很不同。因此，"有用性" 的本质应该是技术性的。
如何以最快速度让客户体验到“有用性”应该是衡量产品和优化的目标。那多短是够短？为了满足企业服务产品日益 “toC化” 而带来的期望值，“时间到有用性”这个指标应该在30分钟以下。
发觉并严格定义这个 "有用性" 也是一件艰难而需要反复迭代的事情，但是非常值得做。在当今开发者工具和/或商业化开源领域竞争激烈的创业环境中，也基本是个表桩了。如果不深入了解什么对客户有用，即便创业也建立不出一个像样的公司。
特别感谢Joseph Jacks和Sarah Novotny对这篇文章原稿的反馈。