Amazon tente de dire que non ce n'est pas un fork, avec autant de rajout et une opposition frontale au business d'elastic, c'est un vrai fork.
Que certaines modifications soient reportées upstream le temps que ce dernier est encore en vie oui, mais par exemple les parties sécurité qui font doublons avec la version Enterprise d'Elastic elles ne seront jamais intégrées upstream en open source.
Je pense qu'on va avoir une pénurie d'investisseurs pendant quelques temps pour lancer de nouveau gros outils comme ça avant que la parade à AWS ne soit trouvée. Car là certains vont perdre beaucoup d'argent, et ça ne sera pas Amazon ^
Ils disent qu'ils contribuent à l'écosystème "open source", mais je doute beaucoup qu'ils le fassent en monnaie sonnante et trébuchante, sinon j'ai des doutes qu'elasticsearch ait des problèmes de modèle économique.
On ne peux pas leur demander de fournir directement des $ aux auteurs alors qu'ils fournissent déjà du code. Pour moi c'est l'un ou l'autre, mais demander les deux ce n'est pas très correct pour eux.
Ensuite c'est plus que là le modèle économique de coo-pétition arrive à ses limites. Le développement et surtout l'organisation et le marketing nécessaire pour faire connaitre son produit est juste faramineux désormais avec la concentration des utilisations vers quelques outils au lieu d'une large diversité avant.
Mais l'essentiel des flux économiques n'arrivent pas vers les auteurs car désormais les utilisateurs préfèrent payer pour le service tout compris que mettre en place et gérer eux même (on ne peux pas leur reprocher).
Ici AWS et Elastic sont en compétition frontale, avec AWS qui récupère les plus values et Elastic qui a principalement investi (et là on parle en M$), donc forcément ça coince et ça se tire dans les pattes.
On risque donc d'arriver à une situation où on aura:
* un retour des outils sous licence pour une utilisation en interne, basé sur des moteurs open source, mais avec une scalabilité limitée (mais bien souvent suffisante)
* un service SaaS/PaaS avec les sources des moteurs des services qu'on utilisera, mais bien sûr pas le code et surtout la configuration et l'expertise pour le mettre en place à grande échelle (c'est leur métier à Amazon, et on ne donne pas gratuitement son métier)
Dans tous les cas on aura de bon moteurs, c'est déjà ça ^
Posté par Paf .
Évalué à 3.
Dernière modification le 12 mars 2019 à 23:46.
Je pense que cette situation est le resultat d'une communaute qui n'est pas saine et ne remet pas en cause le financement de projets libres.
D'autant plus qu'Elastic a aussi un service d'hebergement pour Elasticsearch qui se porte plutot bien.
Le probleme ici est que Elastic a un controle total sur le projet et qu'ils ont commence a en profiter pour leur avantage, au detriment du projet lui-meme et de sa communaute.
Ce n'est pas la premiere fois et ce ne sera pas la derniere fois non plus. Voir entre autre:
Oracle et OpenOffice
Oracle et Hudson
Oracle et Java
InfluxDB et les fonctionnalites qu'ils ont enleve dans le code libre pour le garder seulement dans leur version proprietaire
Parfois ca passe, parfois ca fork ou parfois le projet se meurt.
En general cela repose sur le fait que la partie libre n'est qu'une version shareware deguisee. C'est tres bien pour experimenter et meme avoir des contributions externes (avec attribution a la boite derriere le projet bien entendu, au cas ou ils veulent changer la license…), mais il faut soit passer a la caisse quand on veut passer en production ou avoir la capacite technique de le faire soi-meme (et qui a un certain cout).
Si l'on rajoute a ca le fait que tout ce qui irait a l'encontre de la boite derriere le projet serait rejete ou rendu impossible, la situation actuelle n'est pas vraiment ideale pour un ecosysteme libre et sain.
Donc le fait qu'AWS pousse vers une remise a niveau n'est pas un mal en soit. C'est une opportunite de rendre le projet plus libre. J'imagine qu'a ce niveau, soit Elastic reste tetu est essaye de resister, soit ils coupent l'herbe sous le pied d'AWS et donnent le projet a l'ASF ou il deviendra plus neutre.
Faire rentrer le projet a l'ASF serait vraiment bien. Il ne peut pas y avoir de co-opetition si les acteurs ne sont pas au meme niveau et c'est exactement ce que fournit la fondation Apache. D'ailleurs on entend souvent "community over code" pour souligner le fait qu'avoir une communaute saine est beaucoup plus important que le code.
Et meme si ce n'est pas parfait, ils ont fait un bon boulot. On peut voir plusieurs entreprises supportant Apache Hadoop, plusieurs entreprises derriere Apache Lucene et Solr et se portent toutes tres bien.
Donc non, le fait que le createur d'Elasticsearch bosse a Elastic ne donne pas le droit a Elastic d'etablir une rente a vie sur du logiciel libre.
Ouais alors l'ASF c'est bien, mais ça fait quand même un peu poubelle à projets morts parfois. Par exemple on a Google Wave qui a atteri là et dont personne n'a jamais rien fait: http://incubator.apache.org/projects/wave.html (et c'est pas le seul projet dans ce cas).
Ils peuvent fournir un peu d'infrastructure pour héberger un projet, mais si y'a pas de communauté autour pour prendre le relais et poursuivre les devs, ça ne donnera pas grand chose.
Il y avait la meme question lorsqu'Oracle voulait donner OpenOffice a la fondation Apache. Il existait deja LibreOffice et la reputation d'Oracle n'etait pas franchement bonne. Donc c'etait quoi l'interet de jouer le jeu et de l'accepter?
La position de l'ASF est que ce n'est pas un investisseur ou ne specule pas sur les projets. Ils ne font que fournir un cocon pour aider les projets a se gerer. Donc ils ne vont pas juger en se basant sur les chances de success.
L'interet est que l'on se retrouve avec le choix:
l'ASF refuse et ne fait rien -> Le code source n'est jamais libere et disparait
l'ASF accepte mais il n'y pas vraiment de communaute qui se forme -> On archive le projet mais l'ASF a toujours les droits et le code est toujours dispo sous license libre. Voir https://attic.apache.org/ pour les projets archives
l'ASF accepte et une communaute se construit autour du projet -> Tout va bien, on a un projet vibrant et libre
Et du point de vus succes, la fondation Apache n'a rien d'une poubelle. Rien que le poids financier des projets genre Apache Hadoop/hbase/spark/mesos/flink/lucene/solr/camel se compte en millards de dollars. Ou je pourrais aussi mentioner l'impacte que d'autres projets ont sur l'ecosysteme entier comme Apache Httpd, Maven, ivy, commons, groovy
C'est tout à fait juste, et d'un point de vue utilisateur on va y gagner sur le court terme, mais d'un point de vue économique il va y avoir un problème dans le financement de futur projets. Qui va encore financer le bootstrap de gros projets comme ça sans espoir d'éviter que le mastodonte Amazon ne vienne lui manger son business?
Or il ne faut pas se leurrer, on a mongo, elastic ou docker à ce niveau de finition car ils ont eu des financements qui ont permis de payer les dev et surtout le marketing qui après à permis à la communauté de se focaliser sur ces projets et les améliorer/industrialiser ensuite. Ce n'est plus l'inverse comme avant où c'était les communauté qui créait des champions qui après pouvaient se financer.
Bon si ce sont surtout les gros acteur du SaaS qui développent des moteurs en open source why not, mais alors in-fine 90% de l'utilisation qu'on aura sera sur ces plates formes, donc bah… non open source ^
Posté par Paf .
Évalué à 3.
Dernière modification le 14 mars 2019 à 09:36.
Il faut tout d'abord separer les differents problemes.
En premier lieu, je ne pense pas que ce soit un bon echange de sacrifier sa liberte pour du code. Si moi ou AWS ne peuvent fournir un service d'hebergement d'elasticsearch, ce n'est pas libre. Donc je ne vois rien de mal a avoir AWS ou autre fournir un tel service d'hebergement.
Ce serait aussi injuste vis a vis des autres projets qui sont au coeur d'Elasticsearch comme netty ou apache lucene. Elastic devrait les remunerer.
Tout ca me rappelle d'ailleurs ce qu'ecrivait RMS il y a presque 30ans: https://www.albertopettarin.it/fsfs2/fsfs2.xhtml#x1-590006
Par ailleurs, AWS l'a demontre avec mongodb: si ca vaut le coup, ils developperont une facade pour supporter le protocole de mongodb sans utiliser une seule ligne de code de mongodb. Donc ca ne protege en rien elastic.
Donc que peut faire Elastic? Ils peuvent se congratuler! Ils sont devenus si populaire et gros qu'AWS leur paie attention. Ensuite ils peuvent accepter qu'Elasticsearch est devenue une commodite. Se fermer et se replier serait une erreur car la communaute l'abandonnerait au profit du fork le plus accueillant (ou Apache Solr) et ne ferait que renforcer sa competition. A la place:
S'ouvrir plus et accepter qu'Elasticsearch est une commodite. Mine de rien Elastic a le plus de contributeurs sur le projet, ce qui lui donne le plus d'influence. Ils baissent la barre pour contibuer a Elasticsearch et ainsi rendre le developpement trop gros/rapide pour un fork.
Redoubler d'efforts sur l'hebergement. Il y a plusieurs opportunites qu'AWS ne pourra jamais supporter comme cross-cloud federation. Ils peuvent aussi s'etendre horizontalement (comme une plateforme) ou verticalement (plutot cote applicatif comme ils ont tente avec un APM). Faciliter son integration avec les domaines en poupes comme le deep learning (ex: tres utile pour chercher a base de vecteur) ou IoT. S'assurer aussi d'une bonne integration avec les bibliotheques et cadres populaires (spring, react, ruby, etc.)
Monter au prochain niveau d'abstraction avec une strategie open core. Etablir une separation claire et nette entre la commodite (elasticsearch) et la partie proprietaire qui sera au dessus. Ca permet de non seulement garder la communaute, mais de l'etendre tout en beneficiant de ses avancees
Reduire le pouvoir d'AWS avec un investissement dans les technologies cloud agnostic. Genre s'assurer une bonne integration avec Kubernetes
Quant au financenent en general, c'est assez vague. Mais si elasticsearch n'existait pas, tout le monde utiliserait Apache Solr :)
La difference de popularite s'explique surtout a la facilite d'utilisation d'elasticsearch a mon avis.
Un gros facteur ici est le fait qu'Elastic a recu pas mal d'investissements, ce qui rajoute pas mal de pression pour des retours.
Un autre example serait aussi de regarder et s'inspirer d'autres gros projets qui ont beaucoup de succes et ont du developpement finance par plusieurs entreprises:
Perso je ne trouve pas que leur réponse ne soit pas cohérente. Ils disent qu'ils ne veulent pas de partenariat qui privilégie plus une entreprise qu'un programmeur lambda de la communauté. Ils disent qu'ils ont toujours été clair qu'ils auraient des service payants (un système bien connu et accepté).
Perso pour utiliser beaucoup Elastic, il me semble que la plupart des choses sont vraiment fair-play. La part de l'Open-Source dans leur produit est énorme, et ce qui est proprio n'est pas du tout essentiel.
On peut effectivement leur reprocher leur manœuvre d'avoir mélanger du code proprio avec leur code opensource, mais ils ont quand même bien documenté ce qui est proprio ou non, leur but était bien sur d'élargir le nombre d'utilisateurs du propriétaire en simplifiant l'accès. Je peux le comprendre et je peux comprendre que ça plaise pas trop. Mais pour moi, soit la boite installe Elastic sans trop se soucier de l'open source et hop elle se retrouve à payer, soit elle se soucie de l'open-source et saura faire la différence (il me semble).
Perso, j'ai un peu plus de mal à croire à l'honnêteté d'Amazon que en celle d'Elastic. La vérité est sûrement quelque part entre les deux…
# A ce niveau là c'est un vrai fork
Posté par Jean Gabes (site web personnel) . Évalué à 2.
Amazon tente de dire que non ce n'est pas un fork, avec autant de rajout et une opposition frontale au business d'elastic, c'est un vrai fork.
Que certaines modifications soient reportées upstream le temps que ce dernier est encore en vie oui, mais par exemple les parties sécurité qui font doublons avec la version Enterprise d'Elastic elles ne seront jamais intégrées upstream en open source.
Je pense qu'on va avoir une pénurie d'investisseurs pendant quelques temps pour lancer de nouveau gros outils comme ça avant que la parade à AWS ne soit trouvée. Car là certains vont perdre beaucoup d'argent, et ça ne sera pas Amazon ^
# contribuer
Posté par Xavier Combelle (site web personnel) . Évalué à 1.
Ils disent qu'ils contribuent à l'écosystème "open source", mais je doute beaucoup qu'ils le fassent en monnaie sonnante et trébuchante, sinon j'ai des doutes qu'elasticsearch ait des problèmes de modèle économique.
[^] # Re: contribuer
Posté par Jean Gabes (site web personnel) . Évalué à 3.
On ne peux pas leur demander de fournir directement des $ aux auteurs alors qu'ils fournissent déjà du code. Pour moi c'est l'un ou l'autre, mais demander les deux ce n'est pas très correct pour eux.
Ensuite c'est plus que là le modèle économique de coo-pétition arrive à ses limites. Le développement et surtout l'organisation et le marketing nécessaire pour faire connaitre son produit est juste faramineux désormais avec la concentration des utilisations vers quelques outils au lieu d'une large diversité avant.
Mais l'essentiel des flux économiques n'arrivent pas vers les auteurs car désormais les utilisateurs préfèrent payer pour le service tout compris que mettre en place et gérer eux même (on ne peux pas leur reprocher).
Ici AWS et Elastic sont en compétition frontale, avec AWS qui récupère les plus values et Elastic qui a principalement investi (et là on parle en M$), donc forcément ça coince et ça se tire dans les pattes.
On risque donc d'arriver à une situation où on aura:
* un retour des outils sous licence pour une utilisation en interne, basé sur des moteurs open source, mais avec une scalabilité limitée (mais bien souvent suffisante)
* un service SaaS/PaaS avec les sources des moteurs des services qu'on utilisera, mais bien sûr pas le code et surtout la configuration et l'expertise pour le mettre en place à grande échelle (c'est leur métier à Amazon, et on ne donne pas gratuitement son métier)
Dans tous les cas on aura de bon moteurs, c'est déjà ça ^
[^] # Community over code
Posté par Paf . Évalué à 3. Dernière modification le 12 mars 2019 à 23:46.
Je pense que cette situation est le resultat d'une communaute qui n'est pas saine et ne remet pas en cause le financement de projets libres.
D'autant plus qu'Elastic a aussi un service d'hebergement pour Elasticsearch qui se porte plutot bien.
Le probleme ici est que Elastic a un controle total sur le projet et qu'ils ont commence a en profiter pour leur avantage, au detriment du projet lui-meme et de sa communaute.
Ce n'est pas la premiere fois et ce ne sera pas la derniere fois non plus. Voir entre autre:
Parfois ca passe, parfois ca fork ou parfois le projet se meurt.
En general cela repose sur le fait que la partie libre n'est qu'une version shareware deguisee. C'est tres bien pour experimenter et meme avoir des contributions externes (avec attribution a la boite derriere le projet bien entendu, au cas ou ils veulent changer la license…), mais il faut soit passer a la caisse quand on veut passer en production ou avoir la capacite technique de le faire soi-meme (et qui a un certain cout).
Si l'on rajoute a ca le fait que tout ce qui irait a l'encontre de la boite derriere le projet serait rejete ou rendu impossible, la situation actuelle n'est pas vraiment ideale pour un ecosysteme libre et sain.
Donc le fait qu'AWS pousse vers une remise a niveau n'est pas un mal en soit. C'est une opportunite de rendre le projet plus libre. J'imagine qu'a ce niveau, soit Elastic reste tetu est essaye de resister, soit ils coupent l'herbe sous le pied d'AWS et donnent le projet a l'ASF ou il deviendra plus neutre.
Faire rentrer le projet a l'ASF serait vraiment bien. Il ne peut pas y avoir de co-opetition si les acteurs ne sont pas au meme niveau et c'est exactement ce que fournit la fondation Apache. D'ailleurs on entend souvent "community over code" pour souligner le fait qu'avoir une communaute saine est beaucoup plus important que le code.
Et meme si ce n'est pas parfait, ils ont fait un bon boulot. On peut voir plusieurs entreprises supportant Apache Hadoop, plusieurs entreprises derriere Apache Lucene et Solr et se portent toutes tres bien.
Donc non, le fait que le createur d'Elasticsearch bosse a Elastic ne donne pas le droit a Elastic d'etablir une rente a vie sur du logiciel libre.
[^] # Re: Community over code
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Ouais alors l'ASF c'est bien, mais ça fait quand même un peu poubelle à projets morts parfois. Par exemple on a Google Wave qui a atteri là et dont personne n'a jamais rien fait: http://incubator.apache.org/projects/wave.html (et c'est pas le seul projet dans ce cas).
Ils peuvent fournir un peu d'infrastructure pour héberger un projet, mais si y'a pas de communauté autour pour prendre le relais et poursuivre les devs, ça ne donnera pas grand chose.
[^] # Re: Community over code
Posté par Paf . Évalué à 2.
Et c'est un probleme?
Il y avait la meme question lorsqu'Oracle voulait donner OpenOffice a la fondation Apache. Il existait deja LibreOffice et la reputation d'Oracle n'etait pas franchement bonne. Donc c'etait quoi l'interet de jouer le jeu et de l'accepter?
La position de l'ASF est que ce n'est pas un investisseur ou ne specule pas sur les projets. Ils ne font que fournir un cocon pour aider les projets a se gerer. Donc ils ne vont pas juger en se basant sur les chances de success.
L'interet est que l'on se retrouve avec le choix:
Et du point de vus succes, la fondation Apache n'a rien d'une poubelle. Rien que le poids financier des projets genre Apache Hadoop/hbase/spark/mesos/flink/lucene/solr/camel se compte en millards de dollars. Ou je pourrais aussi mentioner l'impacte que d'autres projets ont sur l'ecosysteme entier comme Apache Httpd, Maven, ivy, commons, groovy
[^] # Re: Community over code
Posté par Jean Gabes (site web personnel) . Évalué à 2.
C'est tout à fait juste, et d'un point de vue utilisateur on va y gagner sur le court terme, mais d'un point de vue économique il va y avoir un problème dans le financement de futur projets. Qui va encore financer le bootstrap de gros projets comme ça sans espoir d'éviter que le mastodonte Amazon ne vienne lui manger son business?
Or il ne faut pas se leurrer, on a mongo, elastic ou docker à ce niveau de finition car ils ont eu des financements qui ont permis de payer les dev et surtout le marketing qui après à permis à la communauté de se focaliser sur ces projets et les améliorer/industrialiser ensuite. Ce n'est plus l'inverse comme avant où c'était les communauté qui créait des champions qui après pouvaient se financer.
Bon si ce sont surtout les gros acteur du SaaS qui développent des moteurs en open source why not, mais alors in-fine 90% de l'utilisation qu'on aura sera sur ces plates formes, donc bah… non open source ^
[^] # Re: Community over code
Posté par Paf . Évalué à 3. Dernière modification le 14 mars 2019 à 09:36.
Il faut tout d'abord separer les differents problemes.
En premier lieu, je ne pense pas que ce soit un bon echange de sacrifier sa liberte pour du code. Si moi ou AWS ne peuvent fournir un service d'hebergement d'elasticsearch, ce n'est pas libre. Donc je ne vois rien de mal a avoir AWS ou autre fournir un tel service d'hebergement.
Ce serait aussi injuste vis a vis des autres projets qui sont au coeur d'Elasticsearch comme netty ou apache lucene. Elastic devrait les remunerer.
Tout ca me rappelle d'ailleurs ce qu'ecrivait RMS il y a presque 30ans: https://www.albertopettarin.it/fsfs2/fsfs2.xhtml#x1-590006
Par ailleurs, AWS l'a demontre avec mongodb: si ca vaut le coup, ils developperont une facade pour supporter le protocole de mongodb sans utiliser une seule ligne de code de mongodb. Donc ca ne protege en rien elastic.
Donc que peut faire Elastic? Ils peuvent se congratuler! Ils sont devenus si populaire et gros qu'AWS leur paie attention. Ensuite ils peuvent accepter qu'Elasticsearch est devenue une commodite. Se fermer et se replier serait une erreur car la communaute l'abandonnerait au profit du fork le plus accueillant (ou Apache Solr) et ne ferait que renforcer sa competition. A la place:
S'ouvrir plus et accepter qu'Elasticsearch est une commodite. Mine de rien Elastic a le plus de contributeurs sur le projet, ce qui lui donne le plus d'influence. Ils baissent la barre pour contibuer a Elasticsearch et ainsi rendre le developpement trop gros/rapide pour un fork.
Redoubler d'efforts sur l'hebergement. Il y a plusieurs opportunites qu'AWS ne pourra jamais supporter comme cross-cloud federation. Ils peuvent aussi s'etendre horizontalement (comme une plateforme) ou verticalement (plutot cote applicatif comme ils ont tente avec un APM). Faciliter son integration avec les domaines en poupes comme le deep learning (ex: tres utile pour chercher a base de vecteur) ou IoT. S'assurer aussi d'une bonne integration avec les bibliotheques et cadres populaires (spring, react, ruby, etc.)
Monter au prochain niveau d'abstraction avec une strategie open core. Etablir une separation claire et nette entre la commodite (elasticsearch) et la partie proprietaire qui sera au dessus. Ca permet de non seulement garder la communaute, mais de l'etendre tout en beneficiant de ses avancees
Reduire le pouvoir d'AWS avec un investissement dans les technologies cloud agnostic. Genre s'assurer une bonne integration avec Kubernetes
Quant au financenent en general, c'est assez vague. Mais si elasticsearch n'existait pas, tout le monde utiliserait Apache Solr :)
La difference de popularite s'explique surtout a la facilite d'utilisation d'elasticsearch a mon avis.
Un gros facteur ici est le fait qu'Elastic a recu pas mal d'investissements, ce qui rajoute pas mal de pression pour des retours.
Un autre example serait aussi de regarder et s'inspirer d'autres gros projets qui ont beaucoup de succes et ont du developpement finance par plusieurs entreprises:
# Sur reddit
Posté par Benoît Laurent (site web personnel) . Évalué à 0.
Assez peu de réactions sur ce fil reddit https://www.reddit.com/r/elasticsearch/comments/azvgz9/aws_netflix_expedia_collaborate_on_new/
à suivre…
[^] # Re: Sur reddit
Posté par Benoît Laurent (site web personnel) . Évalué à 0.
La discussion est un peu plus animée sur r/programming https://www.reddit.com/r/programming/comments/b0awd5/amazon_netflix_expedia_group_and_others_partner/
Et la réponse d'Elastic https://www.elastic.co/blog/on-open-distros-open-source-and-building-a-company
[^] # Re: Sur reddit
Posté par Psychofox (Mastodon) . Évalué à 2.
Le réponse d'elastic ne les sort pas grandis.
Sinon j'ai l'impression que ce sont surtout des petites entreprises comme Floragunn/SearchGuard voir Graylog qui risquent de souffrir.
[^] # Re: Sur reddit
Posté par Alex G. . Évalué à 3.
Pourquoi tu dis ça ?
Perso je ne trouve pas que leur réponse ne soit pas cohérente. Ils disent qu'ils ne veulent pas de partenariat qui privilégie plus une entreprise qu'un programmeur lambda de la communauté. Ils disent qu'ils ont toujours été clair qu'ils auraient des service payants (un système bien connu et accepté).
Perso pour utiliser beaucoup Elastic, il me semble que la plupart des choses sont vraiment fair-play. La part de l'Open-Source dans leur produit est énorme, et ce qui est proprio n'est pas du tout essentiel.
On peut effectivement leur reprocher leur manœuvre d'avoir mélanger du code proprio avec leur code opensource, mais ils ont quand même bien documenté ce qui est proprio ou non, leur but était bien sur d'élargir le nombre d'utilisateurs du propriétaire en simplifiant l'accès. Je peux le comprendre et je peux comprendre que ça plaise pas trop. Mais pour moi, soit la boite installe Elastic sans trop se soucier de l'open source et hop elle se retrouve à payer, soit elle se soucie de l'open-source et saura faire la différence (il me semble).
Perso, j'ai un peu plus de mal à croire à l'honnêteté d'Amazon que en celle d'Elastic. La vérité est sûrement quelque part entre les deux…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.