Developing Commercial Product from Open Source Technology

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