src-d
Starts the discussion on source{d}'s business model
I would like to also tag our advisors here:
- @josephjacks
- @chanezon
- @jbarbier
This document is drafted to be discussed, anything can still change. This is only a starting point.
Just posting a link to discussion that is collapsed in here https://github.com/src-d/guide/pull/137#discussion_r169607198
I think you should consider committing to one really permissive OSS license like Apache 2.0 for all the fully OSS bit, then another potentially permissive license for additional features that are unlocked easily without requiring users to undergo costly/expensive migrations/upgrade projects from OSS version(s) to paid version(s)...of course, depending on what makes sense to you. However, proprietary licenses have no standard implementations models since each company varies how warranties, IP access, unit of measures for pricing mechanisms, etc..work. You definitely do need an enterprise software license lawyer with OSS experience to help implement the details -- one of the best I've worked with is https://www.linkedin.com/in/wh-baird-garrett-89338812/, but I know others, just ping me. I'm a fan of how CockroachDB has designed their open core model, FWIW: https://www.cockroachlabs.com/blog/how-were-building-a-business-to-last/
One thing I'll say about open core is that it comes in many incarnations. This means that each company implementing open core (as a business model) implements it quite differently, as mentioned above. For e.g. the "distro" model is something that Cloudera and others do well.. *aaS/cloud-based offerings are also a kind of open core. See GitHub, Elastic (ElasticSearch company) Cloud, etc.
"Add on" extensions as an open core model - built on top of OSS bits - have historically performed poorly in terms of customer experience and conversion rates/retention given high friction implications -- usually add-ons mean that the additional features don't work "in-situ" with a fully deployed OSS install; instead, they typically require a new consulting agreement, architecture design and deployment cycles are needed to spawn a stack with the commercial features for the customer. This also hurts longer term customer satisfaction and retention for obvious reasons.
GitLab is trying to encourage everyone to download the fully enterprise-based version of their binaries/project since they can include features across all editions/versions (open and closed), then activate them with minimal friction by unlocking the features incrementally or completely via a license file given to users/customers upon signing a commercial agreement after going through a sales process, etc.
To extend on the GitLab example, a far superior open core model to "Add-ons" - one that you can think of as somewhere in between fully hosted and heavily automated on-prem install - is one that splits open/closed pieces while being closely aligned the customer adoption journey/maturity path .. and is also aligned with source{d}'s (also, ideally aligned) tightly integrated OSS/commercial product roadmap and engineering practices. This doesn't mean that the OSS/closed bits live in the same code repos... but it could mean that the engineering/product/QA/integration/etc resources working across those repos are very tightly integrated across interface boundaries, release cadences, iterations, etc. They should not be separate teams with isolated PMs, etc. Key here is to consider and operate like the OSS project(s) are as much of a "product" as the actually closed bits components that make up the real product.
For the end user, for e.g., the story could be as follows: an individual user/dev finds and runs engine on their VM, cloud instance, laptop...starts realizing lots of value.. then another handful of individuals from the same (large, enterprise.. say, Bank of America?) company also start to run and use engine. Before you know it, you have 15+ users (isolated, all singe-workstation/VM/node use) across BofA using engine. This soon percolates up to one of the leadership/decision makers in whatever BU/IT/CTO office/org these individuals users sit in. Then, either users or decision makers are heavily incentivized to engage source{d} for additional features and a platform that make it easier for all these isolated engine users to collaborate.. share models.. schedule jobs centrally.. monitor and control pipelines and work centrally..etc. That is your platform maturity progression which nicely integrates with the customer adoption progression. Organically. This is ideal. I've studied this extensively and the best and highest conversion rate prone commercial OSS companies implement their product offerings with this kind of philosophy. This approach is, I believe, a great way to ensure the incentives are aligned across engineering source{d}'s commercial bits and the end user experience.
Just some thoughts!
Thanks for that comment @josephjacks, specially the link to the CockroachDB article which I recommend anyone to read
@josephjacks thank you for sharing valuable insights!
From the cockroachDB article
Some OSS companies set the bar too low for paid features, making the core OSS product feel “hobbled”. In 2017, any product whose core capabilities cannot scale without requiring a commercial license is probably setting the bar too low.
Makes a lot of sense.
In general, their approach on keeping "paid" features in the same code base, turned off by default and their code covered by a non-oss license + providing 2 release binaries (oss and non-oss ones) sounds interesting.
Very relevant to this discussion (particularly the 2nd half), analysis of MongoDB business model and SSPL licensing given their IPO filing:
