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.

Packaged Experience

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.

Buyer-Specific Needs

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.

OMTM: Time-to-usefulness

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).



许多读者都知道,我平常花很多时间和精力投资于开发者工具和/或商业化开源这个领域里的创业公司,范围也是全球的。今后将在《互联》发更多的资料,来帮助领域内的创业者打造成功的产品、持久的公司,并能在紧密互联的全球市场中成长。(这些资料都会放在 "For Founders" 的标签下。) 今天这篇文章是我对这个话题一年半前在openource.com上发表的文章之后的新思考。


DIY PC与原装Mac的区别

我一开始玩电脑是90年代初,在我爷爷在沈阳药科大学的研究实验室。当时用的是台x86 PC,用的是MS-DOS。我玩了很多开车驾驶有些,都存在3.5英寸软盘上,还有练打字。随着我想玩的游戏越来越高级,需要配置更高,我开始花大量的时间将把电脑拆开,往里面加内存、新的显卡和风扇。这是个有意思的、持续不断的修修补补的小project,我和我爸一起搞,也从中增进了感情。同时也比买一台新电脑便宜得多。

那时我还不懂什么是 "开源"。殊不知,我当时的行为和当今的一个开发者对待开源的态度极为相似。我心甘情愿地用我的业余时间去拼接零件升级电脑 -- 有时是因为我真的需要,有时只是想学点新东西,有时则是于他人建立关系和感情的方式(比如说,我爸)。

随着时间的推移,我在DIY散装电脑上花的时间减少了。由于各种原因,我觉得我的时间变得太 "宝贵"了,不该在花时间修老电脑。我买了一台原装的MacBook,当它老了不好用了,我就再花笔钱买台新的,而不是把底盖揭开,看看能不能再塞点内存进去。

我的行为慢慢演变成许多商业产品买家的态度 -- 通过花钱来节省时间和麻烦。




Stephen Walli是位IT行业的资深人士,也是Open Container Initiative的一员,他写了很多关于这个话题的详细博文Sarah Novotny是Kubernetes社区的早期成员,在Nginx和MySQL的社区里也有积极参与,她在几年前的第一届Open Core Summit上也强调了同样的观点





给开源技术一个开箱即用,原装包装的用户体验非常重要。这不仅仅要有易用精致的UI,或是把项目做成SaaS托管在云上(尽管这都是其中的一部分),而最终卖的是一种观点。这个“观点”即是你作为创始人觉得怎样最好去使用这项开源技术来解决客户的业务问题。作为领域的专家,也通常是开源项目的创造者或维护者,你的“观点”本身是有价值的,也是你的付费客户想花钱买到的产品体验。它们并不想花时间考虑用什么种类的硬件资源、工作流程或最佳实践去以 "正确"的方式解决业务问题。

这种“有观点” 的做法与运维一个开源社区形成了鲜明的对比。通常情况下,不持太强的观点是正确的做法,可以让你的社区自然的去使用、扩展和发展开源项目,当然最好还是沿着同一个roadmap方向去发展最好。

这即是我自己改装x86 PC与买MacBook之间的关系。


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)该怎么去想呢?我喜欢用的一个通俗定义是:"某些技术问题,用户以前做不到的,但现在可以做到了”。"技术" 这个部分很重要,因为所有的开源项目都是从解决某个技术问题开始的,于社交媒体或双边市场模式很不同。因此,"有用性" 的本质应该是技术性的。

但是,解决什么问题能体现出 “有用性”,取决于领域,也需要自己本身的一个准确、严谨的定义。

一套分布式数据库的“有用性”,是从它可以在一两台服务器出现故障时,持续提供数据保持服务继续运作有关(这就是为什么要采用分布式架构的根本原因)。一套持续集成工具(continuous integration)是“有用性”,是从它能让开发者在不破坏dependencies的情况下自动推送产品改进,加快迭代速度(否则,还不如手动QA每一个变动)。大体概念就是这样。

如何以最快速度让客户体验到“有用性”应该是衡量产品和优化的目标。那多短是够短?为了满足企业服务产品日益 “toC化” 而带来的期望值,“时间到有用性”这个指标应该在30分钟以下。

发觉并严格定义这个 "有用性" 也是一件艰难而需要反复迭代的事情,但是非常值得做的。在当今开发者工具和/或商业化开源领域竞争激烈的创业环境中,也基本是个表桩了。如果不深入了解什么对客户有用,即便创业也建立不出一个像样的公司。

尽管改装我的x86 PC很有乐趣,最终对我的MacBook还是很满意的,是个乐意的付费客户。所以,如果你的创业目标是要卖很多MacBook,就不要太迷恋开源里修修补补的乐趣。

特别感谢Joseph Jacks和Sarah Novotny对这篇文章原稿的反馈。