Open Product Recipe
Open Product Recipe
How to turn an open source product into a commercial challenger is no longer a mystery.
This is an appendix to the openly written book called Open Source for Everyone.
All other things being equal, an open source product is objectively better than a closed source alternative, due to its accessibility and reduced lock-in. It’s already better at conception, but continuously more so going forward. That’s because an open product inherently invites greater product innovation. A closed product simply doesn’t get as many minds involved in the act of product development, thus stagnation is an inevitability.
The challenge for an open product is to build a business that can sustain continued product development whilst incentivising continued openness. By now the most basic recipe for making a successful Commercial Open Source Software company is quite straightforward:
Have some domain knowledge and a real itch for improving the status-quo of that domain.
Identify the most successful closed-source product in that domain.
Replicate the core offering of that closed-source product as an open product.
Make a better product by means of open source methodology and complaint-driven development.
If your product is at least as-good as the closed-source incumbent where it really matters (80/20 principle), you’ve secured yourself a minimum of customers who will prefer your product solely on the merit of its openness and lower lock-in. That on its own is never enough to become truly competitive with the incumbent, but it’s enough to get a solid footing.
I’m not advocating for cheap knock-offs here. I’m talking about legitimate iterations in pursuit of product improvement. The vast majority of closed source products would not exist without their open source foundation, and some even came into existence as a reaction to an open incumbent that had failed to capitalize on its early success, like Slack succeeding IRC.
No going back
This strategy of core-product replication is now being used successfully by many COSS Companies to carve out a space for themselves in a contested market.
Discourse vs VBulletin
Mattermost vs Slack
GitLab vs GitHub
MeiliSearch vs Algolia
Baserow vs Airtable
Sentry vs New Relic
PostHog vs Amplitude
WordPress vs Movable Type
It’s quite telling that this doesn’t happen the other way around. Once a product-archetype has been “broken open” by means of an open product achieving dominance, it’s incredibly hard for closed challengers to gain back any meaningful ground in that market segment.
Ever since WordPress displaced Movable Type as the go-to website builder, open source has remained the default in this industry, with WordPress firmly on top. The only way to challenge WordPress in the website builder game (blogging is different because it relies on networks, so closed platforms have made inroads here) is by making an equally open alternative with a novel take on the same problem. Strapi is an example of this.
Of the other companies listed above, some are well on their way to becoming the new industry default, while others might not make it. But, in time, another open alternative surely will; in no small part thanks to its open predecessors. The more the merrier!
Business models for open products
There’s no one-size-fits-all for sustainable, open product development. Models differ depending on product segment (e.g. infrastructure vs application products) and values (company-run vs community-run). But it all boils down to the same thing:
Dare to build in the open.
https://coss.media/open-core-definition-examples-tradeoffs/
https://coss.media/coss-business-model-progressions/
https://coss.media/creating-oss-value-capturing-oss-value/
https://blog.opentechstrategies.com/category/open-source-at-large/
https://nythesis.com/open-courses/commercial-open-source-startups/
I don’t care which model you pick. As long as your mission is to open up something that is currently closed, I wholeheartedly support your endeavor and will gladly respond if you reach out to me.