4 ms·

The problem with this business model is it creates a tension between the OSS version and the paid versions - you want the OSS version to be good, but not such a

by msy 3y ago

The problem with this business model is it creates a tension between the OSS version and the paid versions - you want the OSS version to be good, but not such a good solution that nobody feels the need to pay for your SaaS/consulting/etc. That tension seems to inevitably lead to obvious features missing or functionality/knowledge that's needed to operate at any scale coistered away as closed source so the sponsoring entity can make some money. If the product is more infrastructural you also now have an established pattern (Elastic, Hashicorp etc) of switching to look-but-don't-touch licences to avoid being obliterated as a one-click service for the major cloud providers. Which isn't to say the article is wrong, I just wish they wouldn't pretend commerically backed OSS is some kind of kumbaya win-win for everyone instead of being effectively a trust growth hack for startups before the need to generate revenue inevitably leads them to turning the screws one way or another on the beloved community that helped them grow.

38 3y ago
> That tension seems to inevitably lead to obvious features missing or functionality/knowledge that's needed to operate at any scale coistered away as closed source so the sponsoring entity can make some money. I dont think this is a problem at all. I maintain a small module, and have had many feature requests and support requests over the years. Until I am making enough money to pay my rent, I dont feel one bit guilty about charging for these things. even down to me clicking the Merge Pull Request button. anything that takes even one second of my time, I am charging for. I put months and years of works into the code. and I put the code out in the world for free. If you want an additional feature, or any of my time, pay up.
- tadfisher 3y ago
  With all due respect, your model as described is different: the way I read it is that you're charging for work, not charging for a product incorporating your work. The same tension doesn't exist, because you don't have an incentive to paywall a feature; if someone pays you, everyone benefits. Forgive me if I'm off-base with my interpretation of your comment.
  - 38 3y ago
    > if someone pays you, everyone benefits. this is not guaranteed to be the case. if its a feature I dont care about, then likely I will just implement it privately and provide the modified code privately. It would only be if someone was going to be an ongoing donor that I would defer to their concerns regarding public release of any feature requests.
brap 3y ago
What’s the pattern you’re referring to? I’m curious how these infra projects keep AWS/GCP from killing them
- lolinder 3y ago
  HashiCorp is the latest big name to do it—they switched to the BUSL, which more or less says you can only use the product if you aren't offering it for sale in competition with HashiCorp: https://www.hashicorp.com/bsl https://www.hashicorp.com/bsl
  - maxloh 3y ago
    That seems to be a fair license to me. The entire codebase will be open-sourced a few years after a version is released. You can use the old version and fix security vulnerabilities yourself. If you really want the latest features, you pay.
    - itsafarqueue 3y ago
      Doesn’t this turn on the definition of competition (in the license). I remember reading about a bunch of game and server tech being in very murky water following the license change. If they ever decide to enter your specific business they have an automatic kill switch on you.
- nonameiguess 3y ago
  If your product is sufficiently complex, you may have organizational expertise in running it that the cloud providers can't match, though I can't think of any examples of this. There security requirements like fips-validation and released STIGs that make organizations depend on your product. Off the top of my head, other than these, I can't think of anything RHEL offers that Amazon Linux doesn't, but plenty of orgs still choose the RHEL ami for their EC2s. Some orgs may want or be required to self-host. Some orgs may use your cloud but only in a FedRamp-accredited or classified enclave, where many managed services available in the commercial enclave are not available or not yet approved by your sponsoring agency. I don't know how much of a moat this constitutes for vendors like Elastic, though. Those markets are inherently smaller than what they hoped to get out of managed Elastic cloud, and more labor-intensive to service. It's more of a moat for the big five defense contractors and why Raytheon is still writing all the software for spy satellites rather than Google and Lockheed does all the hardware rather than SpaceX. Of course, they're not open source, but the contracts usually specify the government owns your code, not you, and they can share it with any other contractor they choose if they want to replace you.
imiric 3y ago
> That tension seems to inevitably lead to obvious features missing or functionality/knowledge that's needed to operate at any scale coistered away as closed source so the sponsoring entity can make some money. This is not inevitable at all. You're right that there's a tension there, but there are companies that manage to do this right, and please both OSS and commercial users. The fact many companies don't is not an indication that this business model doesn't work, but that it's very hard to do correctly.
- thinkmassive 3y ago
  One of the main reasons to donate a project to a foundation, such as the Cloud Native Computing Foundation (CNCF), is to protect the community against this type of rugpull. A requirement for them to even consider adopting a project is that it isn’t under majority control of one single commercial entity. Do people honestly believe none of these projects compete with commercial solutions, or are they mostly oblivious these exist at all? https://www.cncf.io/projects/ https://www.cncf.io/projects/
  - pjmlp 3y ago
    A better measurement would be how many of those projects are still relevant in 10 years from now.
    - thinkmassive 3y ago
      From today, or from when they first joined? Also consider that a project needs to not only have existed, but to already have an established track record of being vendor-neutral before it can join. Kubernetes joined CNCF on March 10, 2016. Prometheus joined May 9, 2016. In 2017, these 10 projects joined: - Linkerd - gRPC - CoreDNS - Containerd - rkt - CNI - Envoy - Jaeger - Notary - TUF Of those 12, only one (rkt) has been archived. Do you honestly believe the majority of these will be unsupported 10 years from now, let alone 10 years from when they were added (or started in the first place)?
      - 3y ago
poisonborz 3y ago
There is a very easy distinction that so many projects make: target group business or home user. Paid support, scaling features can be reserved for commercial world where most software makes its profit anyway. Doesn't fit every use case of course, but it doesn't have to. Most computing should be personal.
dosplatos 3y ago
>...instead of being effectively a trust growth hack for startups before the need to generate revenue inevitably leads them to turning the screws one way or another on the beloved community that helped them grow. I totally get this. Pulling the rug out from users definitely feels a bit grimy. I'd like to think most people are generally good, and in that light wouldn't it be worth considering that companies or people who do this are just approaching the market wrong? Incompetence vs. maliciousness. If they are transparent from day one about what will be free forever, and what will eventually be paid, then I wouldn't consider that shifting on their community. That assumes they are true to the roadmap, and make adjustments based on feedback and contributions.

by msy 3y ago

38 3y ago

> That tension seems to inevitably lead to obvious features missing or functionality/knowledge that's needed to operate at any scale coistered away as closed source so the sponsoring entity can make some money. I dont think this is a problem at all. I maintain a small module, and have had many feature requests and support requests over the years. Until I am making enough money to pay my rent, I dont feel one bit guilty about charging for these things. even down to me clicking the Merge Pull Request button. anything that takes even one second of my time, I am charging for. I put months and years of works into the code. and I put the code out in the world for free. If you want an additional feature, or any of my time, pay up.

tadfisher 3y ago
With all due respect, your model as described is different: the way I read it is that you're charging for work, not charging for a product incorporating your work. The same tension doesn't exist, because you don't have an incentive to paywall a feature; if someone pays you, everyone benefits. Forgive me if I'm off-base with my interpretation of your comment.
- 38 3y ago
  > if someone pays you, everyone benefits. this is not guaranteed to be the case. if its a feature I dont care about, then likely I will just implement it privately and provide the modified code privately. It would only be if someone was going to be an ongoing donor that I would defer to their concerns regarding public release of any feature requests.

brap 3y ago

What’s the pattern you’re referring to? I’m curious how these infra projects keep AWS/GCP from killing them

lolinder 3y ago
HashiCorp is the latest big name to do it—they switched to the BUSL, which more or less says you can only use the product if you aren't offering it for sale in competition with HashiCorp: https://www.hashicorp.com/bsl https://www.hashicorp.com/bsl
- maxloh 3y ago
  That seems to be a fair license to me. The entire codebase will be open-sourced a few years after a version is released. You can use the old version and fix security vulnerabilities yourself. If you really want the latest features, you pay.
  - itsafarqueue 3y ago
    Doesn’t this turn on the definition of competition (in the license). I remember reading about a bunch of game and server tech being in very murky water following the license change. If they ever decide to enter your specific business they have an automatic kill switch on you.
nonameiguess 3y ago
If your product is sufficiently complex, you may have organizational expertise in running it that the cloud providers can't match, though I can't think of any examples of this. There security requirements like fips-validation and released STIGs that make organizations depend on your product. Off the top of my head, other than these, I can't think of anything RHEL offers that Amazon Linux doesn't, but plenty of orgs still choose the RHEL ami for their EC2s. Some orgs may want or be required to self-host. Some orgs may use your cloud but only in a FedRamp-accredited or classified enclave, where many managed services available in the commercial enclave are not available or not yet approved by your sponsoring agency. I don't know how much of a moat this constitutes for vendors like Elastic, though. Those markets are inherently smaller than what they hoped to get out of managed Elastic cloud, and more labor-intensive to service. It's more of a moat for the big five defense contractors and why Raytheon is still writing all the software for spy satellites rather than Google and Lockheed does all the hardware rather than SpaceX. Of course, they're not open source, but the contracts usually specify the government owns your code, not you, and they can share it with any other contractor they choose if they want to replace you.

imiric 3y ago

> That tension seems to inevitably lead to obvious features missing or functionality/knowledge that's needed to operate at any scale coistered away as closed source so the sponsoring entity can make some money. This is not inevitable at all. You're right that there's a tension there, but there are companies that manage to do this right, and please both OSS and commercial users. The fact many companies don't is not an indication that this business model doesn't work, but that it's very hard to do correctly.

thinkmassive 3y ago
One of the main reasons to donate a project to a foundation, such as the Cloud Native Computing Foundation (CNCF), is to protect the community against this type of rugpull. A requirement for them to even consider adopting a project is that it isn’t under majority control of one single commercial entity. Do people honestly believe none of these projects compete with commercial solutions, or are they mostly oblivious these exist at all? https://www.cncf.io/projects/ https://www.cncf.io/projects/
- pjmlp 3y ago
  A better measurement would be how many of those projects are still relevant in 10 years from now.
  - thinkmassive 3y ago
    From today, or from when they first joined? Also consider that a project needs to not only have existed, but to already have an established track record of being vendor-neutral before it can join. Kubernetes joined CNCF on March 10, 2016. Prometheus joined May 9, 2016. In 2017, these 10 projects joined: - Linkerd - gRPC - CoreDNS - Containerd - rkt - CNI - Envoy - Jaeger - Notary - TUF Of those 12, only one (rkt) has been archived. Do you honestly believe the majority of these will be unsupported 10 years from now, let alone 10 years from when they were added (or started in the first place)?
    - 3y ago

poisonborz 3y ago

There is a very easy distinction that so many projects make: target group business or home user. Paid support, scaling features can be reserved for commercial world where most software makes its profit anyway. Doesn't fit every use case of course, but it doesn't have to. Most computing should be personal.

dosplatos 3y ago

>...instead of being effectively a trust growth hack for startups before the need to generate revenue inevitably leads them to turning the screws one way or another on the beloved community that helped them grow. I totally get this. Pulling the rug out from users definitely feels a bit grimy. I'd like to think most people are generally good, and in that light wouldn't it be worth considering that companies or people who do this are just approaching the market wrong? Incompetence vs. maliciousness. If they are transparent from day one about what will be free forever, and what will eventually be paid, then I wouldn't consider that shifting on their community. That assumes they are true to the roadmap, and make adjustments based on feedback and contributions.