Starts the discussion on source{d}'s business model #137
Conversation
general/business_model.md
Outdated
|
|
||
| ### Business model meets our technology | ||
|
|
||
| The current model that we are exploring is to have single node versions of our technology stack be fully open-source under a permissive licenses such as [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0) but multiple nodes of our stack that allow distributed computing over a large amount of repositories with a large number of concurent users to be under a restrictive license. |
There was a problem hiding this comment.
Really interested to see, how that would be possible in case of a single codebase.
Personally, I do not see a way for this to happen yet, except if a VERY restrictive license (non-OSS?) is used firsthand, so enterprises are incentivized to pay or buy a re-license of the same codebase, under a comercial license that has the desired terms.
AGPL my be not restrictive enough, as it would allow multiple node usage, in case enterprises do not need modify/re-distributer the “derivative work” on top of this codebase.
But even if they do, it still could be free (as a 🍺) for them to use, if they are willing to contribute all the changes upstream.
But of course I’m not a lawyer, thus the excitement to see how this works out.
There was a problem hiding this comment.
@bzz this is why we're having the discussion now. Since the new reposdb project (we really need more than a code-name for this project) is now underway, it could open up the possibility to separate code bases of the main data source. Having separation of concerns across different code bases will make it significantly easier for the community to understand what is pure OSS and what is restrictive, otherwise we're making things too confusing.
There was a problem hiding this comment.
I think you need to consult with a lawyer specialized in open source licenses to evaliuate options to reach your goal.
If it' a single code base, the limitation single node vs distributed you want to enforce will not work since it is against the open source definition. https://en.wikipedia.org/wiki/The_Open_Source_Definition https://opensource.org/faq#commercial
You might want to look into what Chef did in 2014 with a mix of commercial and open source components in the product, and a proprietary license for the commercial pieces that limited the number of nodes for free to 25. https://blog.chef.io/2014/09/08/there-is-one-chef-server-and-it-is-open-source/
https://www.chef.io/online-master-agreement-archive-20151101/
But it seems they changed that in 2016 https://blog.chef.io/2016/04/26/changes-to-how-chef-products-handle-licenses/
https://www.chef.io/online-master-agreement/
I don't think you'll be able to have a single open source codebase covering both open source and limited parts, you will need some kind of proprietary offering targeting Enterprise needs with a proprietary license.
Having that part under a proprietary license if not unfriendly to individual developers: without a business model for sourced there will be no corporation funding the development of the open source offering.
There was a problem hiding this comment.
@chanezon thank you very much for the insights. What is your opinion on keeping proprietarily licensed code public and not in a private repo?
| ## Context related to our culture | ||
|
|
||
| > ‘We want to always remain a company that does everything with the individual developer in mind. Not the developer as an employee of a company, but the developer as an individual in the developer community.’ | ||
|
|
There was a problem hiding this comment.
Better formatting:
> ‘We want to always remain a company that does everything with the individual developer in mind. Not the developer as an employee of a company, but the developer as an individual in the developer community.’
>
> _source: [source{d}'s culture document](culture.md#for-developers)_
general/business_model.md
Outdated
|
|
||
| **By choosing to monetize in this manner, are we still doing what is best for the individual developer in the community?** | ||
|
|
||
| An example of a situation where we wouldn't be, is when for instance as a company we would choose to make a core feature that would benefit the individual developer not under an open-source permissive license. |
There was a problem hiding this comment.
That sentence is a mouthful. What about:
This means, for instance, that we will never release a core feature under a license that would not allow individual developers to benefit.
There was a problem hiding this comment.
The only case where this would be acceptable if the feature was irrelevant to individual users and only beneficial to large enterprises.
general/business_model.md
Outdated
|
|
||
| It's important to note that while often proprietary means closed source code, it doesn't have to be. You can have your source code open to the world but with a restrictive license that for instance can only be used for academic research. | ||
|
|
||
| **Side-note:** as an organization whatever we do, we should never write/implement our own open source licenses, the community has already done a great job of creating and vetting a selection of licenses that are the status quo. |
There was a problem hiding this comment.
drop the "whatever we do", it doesn't add anything
general/business_model.md
Outdated
|
|
||
| To make sure we stay true to doing what is right for individual developers in the community, we do not want to charge any individual users. | ||
|
|
||
| We don't believe startups and SME's make up a large enough market to build a sustainable company in the long term. The amount you can charge to small organizations pales in comparission to what you can charge enterprises (value add * # of developers). At the same time, selling to SME's is almost always a [SaaS](https://en.wikipedia.org/wiki/Software_as_a_service) business. While there are success stories of this, such as [Travis CI](https://travis-ci.com/) we don't think it's the right route for source{d}. |
There was a problem hiding this comment.
replace the * with x, this is text, not code
general/business_model.md
Outdated
|
|
||
| We don't believe startups and SME's make up a large enough market to build a sustainable company in the long term. The amount you can charge to small organizations pales in comparission to what you can charge enterprises (value add * # of developers). At the same time, selling to SME's is almost always a [SaaS](https://en.wikipedia.org/wiki/Software_as_a_service) business. While there are success stories of this, such as [Travis CI](https://travis-ci.com/) we don't think it's the right route for source{d}. | ||
|
|
||
| **source{d} focuses on enterprises as its customers** |
general/business_model.md
Outdated
|
|
||
| Today every large organization has become/is becoming a software company. The number of software developers in what were once considered traditional businesses, such as banks and airlines, is often already in the 1,000s or 10,000s. | ||
|
|
||
| There is a growing number of challenges that enterprises face within their [Software Development Life Cycle (SDLC)](https://en.wikipedia.org/wiki/Systems_development_life_cycle) that can start to be tackled with large scale language-agnostic analysis of their source code, and trained ML models. |
There was a problem hiding this comment.
"start to be tackled" -> "be tackled"
tackling doesn't imply solving it
|
Just posting a link to discussion that is collapsed in here #137 (comment)
|
|
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
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. |
|
Any updates @eiso? |
|
Very relevant to this discussion (particularly the 2nd half), analysis of MongoDB business model and SSPL licensing given their IPO filing: |
|
@eiso Shall we merge this? One year has passed... |
I would like to also tag our advisors here:
This document is drafted to be discussed, anything can still change. This is only a starting point.