4 ms·

>Elasticsearch contributors were Elastic employees; that, unsurprisingly, did not change afterward. OpenSearch started with no strong contributor base, so had t

>Elasticsearch contributors were Elastic employees; that, unsurprisingly, did not change afterward. OpenSearch started with no strong contributor base, so had to build its community from scratch. As a result, the project has been dominated by Amazon contributors ever since So in a way the "rug pull" achieved what it wanted, amazon is now contributing to development. I think discussing these "rug pulls" without discussing the destructive habit of many large companies to only profit without giving back misses the mark. Any community where there is a large imbalance between the ones doing the work and the ones profiting will over the long run become unstable.

preisschild 1y ago
There are copyleft licenses like AGPL/GPL that basically require them to contribute back, without going to a proprietary license.
- pabs3 1y ago
  AGPL/GPL require people to contribute forward to users, not back to maintainers. They also don't require any monetary compensation, which is what companies like Elastic are mainly after, not code contributions.
thayne 1y ago
It didn't achieve what Elastic wanted. It didn't lead to more people paying for Elastic licenses, it lead to users switching from Elasticsearch to a fork. And they eventually backpedaled and relicensed again under the AGPL. Now, it might be better for the Open/elasticsearch ecosystem, because AWS is contributing more, and possibly the competition drives both Opensearch and Elasticsearch to be better. But on the other hand, there is now a split between two incompatible products, and Elastic has certainly lost some trust.
- dwood_dev 1y ago
  Elastic might be fine in the long run. But everyone I know(sample size <20 orgs) migrated to OpenSearch and never looked back. They were never interested in running Elastic in a separate cloud or running it themselves, and that's what a lot of these DbaaS providers have to overcome. It's already annoying to create your first terraform module for a new AWS managed service, but they then want the users to have the extra complexity of VPC peering/privatelink/vpn and then manage that lifecycle as well.
- mskkm 1y ago
  true
overfeed 1y ago
> I think discussing these "rug pulls" without discussing the destructive habit of many large companies to only profit without giving back misses the mark There's nothing destructive about using software in accordance to it's license, no one's puppy is being kicked. The problem is too many developers and startups decide to be "paid" in exposure and use permissive licenses as a growth hack while chasing deployment counts and GitHub stars. They are perfectly fine with widespread, unpaid adoption until a hyperscaler with superior infra is involved, then suddenly the license becomes a liability. You can't have your cake and eat it.
- evanelias 1y ago
  > There's nothing destructive about using software in accordance to it's license Doesn't this exact same argument work in the opposite direction too? In other words, the "rug puller" is just exercising their rights (explicit in a CLA, or implicit in a permissive license) to use a different license moving forwards. There's nothing destructive because the previous FOSS releases continue to exist and can be forked and maintained by the community if they wish. > You can't have your cake and eat it. So what's the alternative? Let's say you independently create an innovative backend/infrastructure software project in 2025, but one that doesn't lend itself well to a SaaS-only model. You require income from it to continue developing it. Realistically, what license do you pick on day one that doesn't doom you to failure?
  - overfeed 1y ago
    > Doesn't this exact same argument work in the opposite direction too It absolutely does; the article discuses this, and at no point did anyone describe license-changes as "destructive". The community/competition also has the right to fork the project when there's a change they don't like (with no assurance of success). > Realistically, what license do you pick on day one that doesn't doom you to failure? That's my point exactly! If I have a slice of cake, I can either eat it now or save it for later - not both. You have to pick a poison: AGPL or a custom license will prevent hyperscalers hosting your service, but will slow adoption. MIT or BSD will juice your growth and leave you vulnerable to SaaS alternatives. Switching licenses after achieving popularity leaves you vulnerable to forking - this strategy has been popular lately, but valkey proved that it carries a major risk as well. AFAICT, there's no license that assures one can maximize adoption, and capture most of the projects value, because these two objectives are in tension. Continuing with the cake theme: the options for project authors are growing the cake and likely capturing a slice of it along others, or having the entirety of a much smaller cake. edit: the article does outline a strategy that maximizes upside for project author: make outsider contributors sign CLAs, and ensure your org is responsible for most of the contributions.

preisschild 1y ago

There are copyleft licenses like AGPL/GPL that basically require them to contribute back, without going to a proprietary license.

pabs3 1y ago
AGPL/GPL require people to contribute forward to users, not back to maintainers. They also don't require any monetary compensation, which is what companies like Elastic are mainly after, not code contributions.

thayne 1y ago

It didn't achieve what Elastic wanted. It didn't lead to more people paying for Elastic licenses, it lead to users switching from Elasticsearch to a fork. And they eventually backpedaled and relicensed again under the AGPL. Now, it might be better for the Open/elasticsearch ecosystem, because AWS is contributing more, and possibly the competition drives both Opensearch and Elasticsearch to be better. But on the other hand, there is now a split between two incompatible products, and Elastic has certainly lost some trust.

dwood_dev 1y ago
Elastic might be fine in the long run. But everyone I know(sample size <20 orgs) migrated to OpenSearch and never looked back. They were never interested in running Elastic in a separate cloud or running it themselves, and that's what a lot of these DbaaS providers have to overcome. It's already annoying to create your first terraform module for a new AWS managed service, but they then want the users to have the extra complexity of VPC peering/privatelink/vpn and then manage that lifecycle as well.
mskkm 1y ago
true

overfeed 1y ago

> I think discussing these "rug pulls" without discussing the destructive habit of many large companies to only profit without giving back misses the mark There's nothing destructive about using software in accordance to it's license, no one's puppy is being kicked. The problem is too many developers and startups decide to be "paid" in exposure and use permissive licenses as a growth hack while chasing deployment counts and GitHub stars. They are perfectly fine with widespread, unpaid adoption until a hyperscaler with superior infra is involved, then suddenly the license becomes a liability. You can't have your cake and eat it.

evanelias 1y ago
> There's nothing destructive about using software in accordance to it's license Doesn't this exact same argument work in the opposite direction too? In other words, the "rug puller" is just exercising their rights (explicit in a CLA, or implicit in a permissive license) to use a different license moving forwards. There's nothing destructive because the previous FOSS releases continue to exist and can be forked and maintained by the community if they wish. > You can't have your cake and eat it. So what's the alternative? Let's say you independently create an innovative backend/infrastructure software project in 2025, but one that doesn't lend itself well to a SaaS-only model. You require income from it to continue developing it. Realistically, what license do you pick on day one that doesn't doom you to failure?
- overfeed 1y ago
  > Doesn't this exact same argument work in the opposite direction too It absolutely does; the article discuses this, and at no point did anyone describe license-changes as "destructive". The community/competition also has the right to fork the project when there's a change they don't like (with no assurance of success). > Realistically, what license do you pick on day one that doesn't doom you to failure? That's my point exactly! If I have a slice of cake, I can either eat it now or save it for later - not both. You have to pick a poison: AGPL or a custom license will prevent hyperscalers hosting your service, but will slow adoption. MIT or BSD will juice your growth and leave you vulnerable to SaaS alternatives. Switching licenses after achieving popularity leaves you vulnerable to forking - this strategy has been popular lately, but valkey proved that it carries a major risk as well. AFAICT, there's no license that assures one can maximize adoption, and capture most of the projects value, because these two objectives are in tension. Continuing with the cake theme: the options for project authors are growing the cake and likely capturing a slice of it along others, or having the entirety of a much smaller cake. edit: the article does outline a strategy that maximizes upside for project author: make outsider contributors sign CLAs, and ensure your org is responsible for most of the contributions.