• [^] # Re: Community over code

    Posté par . En réponse au lien Elastic Search préforké. É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:

    • Gnome
    • Apache Spark
    • Apache Flink
    • Apache Kafka
    • Apache Hadoop ecosysteme
    • Apache Lucene
    • Nextcloud