3 ms·

IMHO using "open" is just strategy to attract devs and companies that are looking for FOSS solutions, but in reality it's just another way to vendor lock-in. I

IMHO using "open" is just strategy to attract devs and companies that are looking for FOSS solutions, but in reality it's just another way to vendor lock-in. I hope i am wrong. Honest question, besides not paying licenses, is there any technical reason to do this?

phamilton 8y ago
If you are using AWS ESS I would imagine using this distro locally and in testing will be a closer match to what's running in prod.
- rooam-dev 8y ago
  Exactly my point. Most likely it will be more difficult migrate to the "normal" ES.
  - tracker1 8y ago
    As long as this remains cleanly open, I'm not sure why you wouldn't run this if you want to self-host. I'm not sure how this will, or won't play out for Elastic company though. I'm thinking AGPL for server, and MIT for client libraries is probably the best way to go for someone starting any kind of *Server project. Open-Core as a business model isn't something that the likes of AWS, Azure or GCP can really tolerate if they want to integrate SaaS that the customers want. DBaaS in particular is one of the bigger advantages of cloud providers in general. Discloser: A family member of mine does work for Elastic, but I have no knowledge of their internal practices or policies or reaction to this.
sl1ck731 8y ago
I was trying to implement ES previously but kept running into things I thought we're included "open source" but turned out to be an extra paid feature. With this I know what I'm getting. There is no more vendor lock-in with this than with Elastic.
- rooam-dev 8y ago
  Not yet, but it will be. Open Distro ES. At some point features will increase and migration from AWS will be more difficult.
  - otisg 8y ago
    Then, if that happens, we will see the "Open Open Distro for ES" ;)
scarhill 8y ago
Does knowing that you're running or contributing to Open Source code count? The AWS Open Source blog posted elsewhere in this topic implies that Elastic is making it hard to tell.

phamilton 8y ago

If you are using AWS ESS I would imagine using this distro locally and in testing will be a closer match to what's running in prod.

rooam-dev 8y ago
Exactly my point. Most likely it will be more difficult migrate to the "normal" ES.
- tracker1 8y ago
  As long as this remains cleanly open, I'm not sure why you wouldn't run this if you want to self-host. I'm not sure how this will, or won't play out for Elastic company though. I'm thinking AGPL for server, and MIT for client libraries is probably the best way to go for someone starting any kind of *Server project. Open-Core as a business model isn't something that the likes of AWS, Azure or GCP can really tolerate if they want to integrate SaaS that the customers want. DBaaS in particular is one of the bigger advantages of cloud providers in general. Discloser: A family member of mine does work for Elastic, but I have no knowledge of their internal practices or policies or reaction to this.

sl1ck731 8y ago

I was trying to implement ES previously but kept running into things I thought we're included "open source" but turned out to be an extra paid feature. With this I know what I'm getting. There is no more vendor lock-in with this than with Elastic.

rooam-dev 8y ago
Not yet, but it will be. Open Distro ES. At some point features will increase and migration from AWS will be more difficult.
- otisg 8y ago
  Then, if that happens, we will see the "Open Open Distro for ES" ;)

scarhill 8y ago

Does knowing that you're running or contributing to Open Source code count? The AWS Open Source blog posted elsewhere in this topic implies that Elastic is making it hard to tell.