3 ms·

It's especially ... ironic, that they think Amazonification is not-ok, but Enterprizificaion (open core) is a-ok. That said hosting ES is basically the same as

by pas 6y ago

It's especially ... ironic, that they think Amazonification is not-ok, but Enterprizificaion (open core) is a-ok. That said hosting ES is basically the same as building a carwash, or a gas station, or let's say a printing house. You get the machinery and build your own support services around it. Even the unit economics are not that different. AWS spent probably millions of dollars to push the marginal price down. The initial cost of procurement for machinery might be zero for ES as opposed to buying a printing press, but none of the aforementioned sectors are limited by the cost of machinery. In case of brick and mortar services the cost of land, labor, construction, and logistics are all a lot more important. Yes, okay, but what about AWS's advantage, their "moat"? Elastic will never be able to match that. This is the same problem that plagues the browser, phone OS (and other) markets. Google can easily spend a billion USD each year on fiddling with Chrome and Android. Mozilla, Canonical, KDE, and others can't. AWS has the platform advantage, Google has money. It seems these market forces virtually force ES to become a "public good" like the Linux kernel. (Or Elastic could try to fork it and stop using any kind of free/open/available license. And try to find business niches.) But at this point the cat is out of the bag. Likely no amount of license engineering will be sufficient to overcome AWS' advantage.

jacobr1 6y ago
The cloud providers would just build a competing service if they couldn't co-opt an existing popular open source solution. Or anoint an adjacent solution, like solr in the case of elasticsearch. But what can be done and we really haven't seen a "open-core" type infra component try this yet: is require open-sourcing changes. The opendistro approach sorta gets us there, in a hard-fork sense, but seems in adequate and is really only being done for connivence rather than licensing requirements. But we already have a licensing solution: the AGPL. But no enterprise or saas startup wants to touch AGPL software for the fear of it contaminating proprietary code. So it seems to me the solution is a hybrid APGL for cloud providers and apache/mit for others approach. Such a license seems feasible to write and would be superior to open-core for most users.
- pas 6y ago
  ... a bit theoretical, but how is the GPLv3 with the anti-Tivo provision okay? OSI definition 10: License must not restrict interface, and def. 9. License must not restrict other software it gets distributed with. (So I can't put my encrypted bootloader and verifier into the same thing.)

by pas 6y ago

jacobr1 6y ago

The cloud providers would just build a competing service if they couldn't co-opt an existing popular open source solution. Or anoint an adjacent solution, like solr in the case of elasticsearch. But what can be done and we really haven't seen a "open-core" type infra component try this yet: is require open-sourcing changes. The opendistro approach sorta gets us there, in a hard-fork sense, but seems in adequate and is really only being done for connivence rather than licensing requirements. But we already have a licensing solution: the AGPL. But no enterprise or saas startup wants to touch AGPL software for the fear of it contaminating proprietary code. So it seems to me the solution is a hybrid APGL for cloud providers and apache/mit for others approach. Such a license seems feasible to write and would be superior to open-core for most users.

pas 6y ago
... a bit theoretical, but how is the GPLv3 with the anti-Tivo provision okay? OSI definition 10: License must not restrict interface, and def. 9. License must not restrict other software it gets distributed with. (So I can't put my encrypted bootloader and verifier into the same thing.)