9.6 KiB
A framework for building products from open source projects
Here is a roadmap for turning a project into a commercial open source
product.
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 the early '90s—playing games stored on 3.5" floppy disks and doing touch-typing exercises. As technology improved, I spent an obscene amount of time taking my computer apart to add more RAM, a new graphics 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 a new computer.
What's the point of this in the context of open source?
Well, even though I had no idea what "open source" was at the time, I was behaving like a typical developer does with open source projects today—spending my free time to piece together and build things I wanted, 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 paid a pretty penny for a new one with a better configuration instead of unscrewing the bottom to see if I could jam in a new RAM card.
My behavior became more like that of an enterprise buyer—saving time and trouble by spending money.
An open source software project is not a product you sell
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 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 a company sells are two completely different things.
Yet, project and product continue to be conflated by maintainers-turned-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 that it has that out-of-the-box user experience isn't just about a polished user interface (UI) or hosting it on your server as SaaS (although 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 the features that are necessary for your targeted buyer to justify a purchase. What these features are depends 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 it must have to purchase a product. (EnterpriseReady.io is a great resource about what those features tend to be.)
A small- or medium-sized business buyer, say your local mom-and-pop bakery, that has less financial resources and people power and is more price-sensitive, will need different things to be convinced to buy.
A consumer service monetized via ads, where your buyers are the advertisers while your users are everyday people, will be different still.
One thing is for sure: your buyer is almost never your open source community.
Know what your buyer requires for a purchase, and package that with your expert opinion on how to solve the buyer's problem; 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 enterprises.
Certainly, other elements can be added to further the differentiation. But a packaged experience with buyer-specific features is essential. Without one or the other, your prospective customers might as well just tinker on their own for free.
One metric that matters: 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 That Matters (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 days of product development?
I propose time-to-value
"Time" here is straightforward—the lower, the better.
"Value" needs a precise, rigorous definition that is technology- and problem-specific. Your distributed database is valuable because it can serve data with no downtime when servers fail. Your continuous integration tool is valuable because it enables application developers to push improvements faster without breaking the application. You get the idea.
How quickly can a customer see or feel the one core piece of value that you measure and optimize for? Whatever is "a sufficiently short time" depends on the use case, but given the increasing consumerization of enterprise technology, any product's time-to-value that's more than 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.
(P.S. The mental framework outlined here may not apply if you are building a consultancy or support-oriented company that services open source project users. For more expansive reading on different COSS business models, see COSS business model progressions by Joseph Jacks.)
Special thanks to Sarah Novotny for her feedback on this post's draft.
This article was previously published on COSS Media and is edited and republished with permission.
via: https://opensource.com/article/19/11/products-open-source-projects