My first memory of playing with a computer was via a MS-DOS terminal on the x86 PC in my grandfather's pharmaceutical research lab in the early 90s – playing games stored on 3 1/2 floppy disks and doing touch typing exercises. As technology improved, I would later spend an obscene amount of time taking the computer apart to add more RAM, a new graphic card, or a new fan, mostly so I could play cooler games. It was a fun, ongoing project, and I bonded with my father over it. It was also way cheaper than buying new computer.

What's the point of this story in the context of open source?

Well, even though I had no idea what "open source" was at the time, I was behaving like what a typical developer would do with open source projects today – spending free time to piece together and build things I want, sometimes for a specific goal, sometimes to learn new things, sometimes as a way to connect with others.

But over time, I stopped tinkering. For whatever reason, I decided that my time was becoming too "valuable" to retrofit my older computers. I started using a MacBook, and when my older MacBook wasn't functioning well, I just paid a pretty penny for a new one with better configurations, instead of unscrewing the bottom to see if I could jam in a new RAM card.

My behavior became more akin to an enterprise buyer – saving time and trouble by spending money.

OSS Project != Product You Sell

If your experience with technology resembles mine in some way, then we all know intuitively that the projects we DIY with are not the same as products we spend money buying.

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 led the Kubernetes community and was heavily involved in the NGINX and MySQL communities, emphatically articulated at the inaugural Open Core Summit that the open source project a company shepherds and the product that company sells are two completely different things.

Yet, project and product continue to get conflated by maintainers-turn-founders of commercial open source software (COSS) companies, especially (and ironically) when the open source project gets traction.

This mistake gets repeated, I believe, because it's hard to mentally conceptualize how and why a commercial product should be different, when the open source project is already being used widely.

What Makes a COSS Product Different?

Two core elements differentiate a commercial product from its open source root: packaged experience and buyer-specific features.

Packaged Experience

Packaging your project, so it has that out-of-the-box user experience, isn't just about a polished UI or hosting on your server as a SaaS (though that could be part of it). It's an expressed opinion of how you, the creator or maintainer of the project turned founder of the company, believe the technology should be used to solve your customer's business problem. That "opinion" is essentially the product experience the customer is paying for.

When you are running an open source community project, it's usually good to be not opinionated and let your community organically flourish. When you are developing a product for customers, it's usually good to be opinionated.

It's the retrofitted x86 PC versus the MacBook dynamic.

Dave McJannet (CEO of Hashicorp) and Peter Reinhardt (CEO of Segment), both cited packaging as a crucial step to get right, in order to turn an open source project into a scalable commercial product.

Buyer-Specific Features

A well-packaged product must also have features that are necessary for your targeted buyer to justify a purchase. What these features are depend on the profile of your buyer, but the possibilities are finite and manageable.

An enterprise buyer, say a Global 2000, will have a relatively consistent set of features that they must have in order to purchase new products. (EnterpriseReady.io is a great resource for what some of those features tend to be.)

A small or medium sized business buyer, say your local mom-and-pop bakery, who has less financial resources, less people power, and is more price sensitive will need different things to be convinced to buy.

A consumer service monetized via ads will be different still, where your buyer is the advertisers while your users are everyday people.

One thing is for sure: your buyer is almost never your open source community.

Know what your buyer requires for a purchase, package that with your expert opinion on how to solve the buyer's problem, and that's what differentiates a product from a project.

Sid Sijbrandij's articulation of GitLab's Buyer-based Open Core model is a good example for enterprise.

Certainly, other elements can be added to further the differentiation. But a packaged experience with buy-specific features are essential. Without one or the other, your prospective customer might as well just tinker on their own, for free.

One Metric to Measure (OMTM): Time-to-Value

A perennially difficult thing in product development is measuring progress and establishing a data-driven framework to determine whether you are on the right path or not. I'm a fan of the One Metric to Measure (OMTM) mentality, elaborated in "Lean Analytics", where you focus on one single number above everything else for your current stage. This approach enforces focus and discipline, among a sea of data you can gather and distract yourself with (oftentimes vanity metrics like download numbers or GitHub stars). The single metric can effectively rally your entire company around one tangible goal or mission – especially critical for an early stage company. And the metric you focus on will be different at different stages.

So what's the right OMTM in the early day of your product development?

I propose: Time-to-value

"Time" here is straight forward – lower the better.

"Value" needs precise, rigorous definition that is technology and problem specific. Your distributed database is valuable because it can serve data with no down time when servers fail. Your continuous integration tool is valuable because it enables application developers to push improvements faster without breaking the application itself. You get the idea.

How quickly can a customer see or feel that one core piece of value is what you measure and optimize for. What is a sufficiently short enough time does depend on the use case, but given the increasing consumerization of enterprise technology, any product's time-to-value that's > 30 minutes is probably too long.

Finding and tightly defining that "value" is hard and iterative, but also table stakes if you are looking to build a product company around an open source project. Without a deep understanding of what that value is for your customer, 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 pretty satisfied with my MacBook and happy to pay the premium. So don't get too enamored with the joy of tinkering, if your goal is actually to sell MacBook.