MongoDB Inc. et Elastic se plaignent des fournisseurs de MongoDB / Elasticsearch / Kibana à la demande (en particulier les gros fournisseurs de cloud), car ça leur prendrait une part trop importante des flux financiers autour du logiciel.
D’autres éditeurs se plaignent des intégrateurs (ESN/SSII) qui captent une partie des revenus d’installation / intégration / déploiement / support / service autour de produits phare.
Dès qu’un produit est suffisamment visible et aisément déployable, alors une autre société a un intérêt financier à court terme à le proposer : elle n’a pas à payer les coûts de développement, R&D, etc. et le logiciel existe déjà, elle apprend à l’installer et ensuite chaque nouvelle installation est un gain net. Tandis que l’éditeur doit continuer à financer le développement. C’est évidemment un choix à court terme : si l’éditeur est étranglé financièrement, le produit n’évolue plus et à terme, tragédie des communs, mort du produit, fin des revenus... Si l’évaluation est purement financière, pourquoi le nouvel acteur contribuerait, améliorerait la documentation, les traductions, ferait des retours et des apports divers, etc. ? Le copyleft est parfois utilisé pour cela, mais ça ne marche pas forcément dans tous les cas : Amazon peut très bien déployer exactement le logiciel sans aucune modification, c’est juste le volume des déploiements (et la facilité de le faire) qui l’intéresse et qui lui donne un avantage commercial. Le copyleft n’aide pas forcément pour cela. (précision: aux deux extrémités, le nouvel acteur peut tout à fait devenir un acteur contributeur du logiciel faisant grossir le chiffre d’affaires de tout le monde, ou bien être un simple parasite économique opportuniste à souhait et profiteur, pour grossir le trait).
Autre effet pervers : l’éditeur a donc intérêt à ne pas avoir un logiciel facilement installable, à avoir une documentation lacunaire, une configuration trompeuse et des logs énigmatiques pour avoir des questions via son support et vendre ses services ? Avec un peu de chance son logiciel est tellement imparfait qu’il passera sous les radars des méchants concurrents potentiels, avec un risque certain de ne pas être beaucoup utilisé en général non plus.
Le périmètre fonctionnel du logiciel joue beaucoup : si c’est le seul logiciel libre du domaine concerné, alors il y a peu de risque au début, au moins le temps qu’il ait suffisamment de fonctionnalités, il peut y avoir besoin d’experts du domaine pour le coder. Puis les ajouts supplémentaires deviennent en gros de la maintenance et de l’industrialisation : c’est un peu mieux en performance mais ça marchait déjà suffisamment bien, c’est des fonctionnalités utilisées par 10% de gens, c’est des fonctions avancées orientées grosses entreprises, etc. Alors d’un côté j’ai potentiellement moins de revenus (moins de commandes d’évolution, moins de support) et de l’autre plus de concurrence (oh un logiciel suffisamment revendable).
[^] # Re: Business model : une question de dosage et de diversification ?
Posté par Benoît Sibaud (site web personnel) . En réponse au lien AWS fork Elastic Search qui n'est plus sous licence Apache. Évalué à 6.
MongoDB Inc. et Elastic se plaignent des fournisseurs de MongoDB / Elasticsearch / Kibana à la demande (en particulier les gros fournisseurs de cloud), car ça leur prendrait une part trop importante des flux financiers autour du logiciel.
D’autres éditeurs se plaignent des intégrateurs (ESN/SSII) qui captent une partie des revenus d’installation / intégration / déploiement / support / service autour de produits phare.
Dès qu’un produit est suffisamment visible et aisément déployable, alors une autre société a un intérêt financier à court terme à le proposer : elle n’a pas à payer les coûts de développement, R&D, etc. et le logiciel existe déjà, elle apprend à l’installer et ensuite chaque nouvelle installation est un gain net. Tandis que l’éditeur doit continuer à financer le développement. C’est évidemment un choix à court terme : si l’éditeur est étranglé financièrement, le produit n’évolue plus et à terme, tragédie des communs, mort du produit, fin des revenus... Si l’évaluation est purement financière, pourquoi le nouvel acteur contribuerait, améliorerait la documentation, les traductions, ferait des retours et des apports divers, etc. ? Le copyleft est parfois utilisé pour cela, mais ça ne marche pas forcément dans tous les cas : Amazon peut très bien déployer exactement le logiciel sans aucune modification, c’est juste le volume des déploiements (et la facilité de le faire) qui l’intéresse et qui lui donne un avantage commercial. Le copyleft n’aide pas forcément pour cela. (précision: aux deux extrémités, le nouvel acteur peut tout à fait devenir un acteur contributeur du logiciel faisant grossir le chiffre d’affaires de tout le monde, ou bien être un simple parasite économique opportuniste à souhait et profiteur, pour grossir le trait).
Autre effet pervers : l’éditeur a donc intérêt à ne pas avoir un logiciel facilement installable, à avoir une documentation lacunaire, une configuration trompeuse et des logs énigmatiques pour avoir des questions via son support et vendre ses services ? Avec un peu de chance son logiciel est tellement imparfait qu’il passera sous les radars des méchants concurrents potentiels, avec un risque certain de ne pas être beaucoup utilisé en général non plus.
Le périmètre fonctionnel du logiciel joue beaucoup : si c’est le seul logiciel libre du domaine concerné, alors il y a peu de risque au début, au moins le temps qu’il ait suffisamment de fonctionnalités, il peut y avoir besoin d’experts du domaine pour le coder. Puis les ajouts supplémentaires deviennent en gros de la maintenance et de l’industrialisation : c’est un peu mieux en performance mais ça marchait déjà suffisamment bien, c’est des fonctionnalités utilisées par 10% de gens, c’est des fonctions avancées orientées grosses entreprises, etc. Alors d’un côté j’ai potentiellement moins de revenus (moins de commandes d’évolution, moins de support) et de l’autre plus de concurrence (oh un logiciel suffisamment revendable).