Opensource Business Models
Posted février 23rd, 2008 by uxmalDeux trois schémas de business modèles open source. Je les ai nommés en fonction de ce à quoi ils me font penser.
C’est un brouillon donc je le complèterais de temps en temps, c’est avant tout pour me faire un aide mémoire si jamais j’ai à réfléchir à un financement pour un éventuel projet opensource de type “moyen”.
Modèle double jeu :
Publier le logiciel avec une licence autorisant l’utilisation dans les logiciels libres, mais pas dans les applications commerciales (ex GPL).
Avantages :
- Si on publie en GPL, ça reste totalement open source et donc la communauté peut récupérer le code, on peut l’utiliser sans problèmes pour des porjets étudiants, de recherche etc…
- Un développeur ou un étudiant habitué au logiciel et l’ayant utilisé sous licence open source sera plus enclin à le recommander pour une application commerciale dans son entreprise par exemple (sous licence payante) c’est donc très astucieux :)
- Si la licence open source interdit la réutilisation dans des applications commerciales, il y a moins de soucis à se faire (d’un point de vu business/marketing) qu’avec les licences plus “permissives”.
Ligne de conduite :
- -
Exemple : Qt/PyQt, de Trolltech
Modèle du dealer :
Mettre en GPL la version N-1 de l’application. On continue de vendre la version N.
Avantages :
- le programme reste gratuit et ouvert, toute la doc existe déjà, et surtout les personnes sachant l”utiliser aussi
- dissuade la modification d’OpenGL (car tout ajout serait à recommencer dans la version d’OpenGL suivante)
- L’application commerciale conserve toujours un petit plus “business” : docs, features de dernières minutes, suivi des tendances
- La communauté libre a intérêt a voir le projet développé de manière industrielle, puisque cela fait évoluer la version opensource (à la même fréquence, mais à un niveau différent)
Ligne de conduite :
- Release often and early :) pour décourager la concurrence de modifier le produit pour l’améliorer.
- Suivre la communauté pour directement intégrer les requêtes de fonctionnalités dans la version commerciale
- La version N-1 doit reste utilisable quand même, sinon personne ne l’utilisera !
Exemple : Silicon Graphics, avec GL et la version “alter” OpenGL
Modèle deluxe :
Mettre dans le domaine publique une version “light” de la version courante. On vend des versions à valeur ajoutée, avec des fonctions adaptées aux entreprises par exemple (possibilité de faire des plugins etc..)
Avantages :
- La version opensource est la dernière mise à jour, et pas une version en retard par rapport à”l’époque”
- La version opensource reste modifiable par la communauté si ils le souhaitent
- L’application commerciale conserve toujours un petit plus “business” : docs, features de dernière minute, suivi des besoins des clients..
Exemple : Toutes les version “openXXXXX” ou “community” qu’on peut rencontrer : solaris, suse, des éditeurs UML…
Modèle libre service :
Aux modèles précédents peuvent se greffer des services : consulting, formations, version modifiée pour chaque client…Ces services peuvent aussi purement et simplement justifier le tarif d’un “package” applicatif, qui serait alors totalement mis dans le libre, à la version N.
Avantages :
- Approche professionnelle et industrielle.
- L’application sera entièrement libre et donc sûrement récupérée ou modifié : mais en contrepartie elle bénéficiera d’extensions, plugins, libres ou non, de partenariat… tout ceci participant à la diffusion de l’application. Très positif.
Ligne de conduite : Il faut un bon support technique, doc etc.. toute cette partie doit être irréprochable.
Exemple : nombreux
L’ange gardien :
Application 100% libre. Fonctionne par dons, dans une entité indépendante. Le business se fait par une entreprise de services et/ou consulting et/ou formation à part, et qui utilise l’outil libre avec de la valeur ajoutée.C’est un peu comme la version précédente, sauf que c’est un peu plus “séparé”.
Avantages :
- L’application se développera grâce aux dons et aux développeurs bénévole
- Ca a le mérite de ne pas associer l’application à une boite “commerciale et lucrative”. en contrepartie la boite de service sera un peu plus anonyme par contre, et clairement exposée à la concurrence…
Note : cette liste n’a pas la prétention d’être pertinente ou exhaustive malgré son titre tape à l’oeil. Elle le sera peut-être un jour, je la modifierais au fur et à mesure de l’évolution des choses
