Nouvelle politique de maintenance de Spring : La très périlleuse route de la monétisation de l’open source
Spring Source a publié l’information sous la forme d’une modification sibylline de la note d’Enterprise Maintenance Policy : Seuls les clients commerciaux bénéficieront des patchs publiés après les trois mois qui suivent le lancement d’une version majeure des projets majeurs Spring (framework, security, web flow, etc). L’objectif annoncé de Spring Source est de réduire les coûts de maintenance des anciennes versions de ses projets en incitant les utilisateurs à migrer vers les versions récentes.
Concrètement, les utilisateurs non commerciaux du framework seraient limités aux versions 2.0.1 (contre 2.0.8 pour les clients commerciaux) et 2.5.3 (contre 2.5.5) [1]. Une telle limitation serait bloquante pour la plupart des projets.
Au delà de l’objectif annoncé, on peut y voir la tentative de créer un modèle de monétisation de l’open source : « payer pour les mises à jour ».
Ce qui est sûr, c’est que cette annonce, au delà des sempiternels débats stériles que nous offre internet (Cf. : TSS), laisse quelques questions en suspens.
- Vers un dual licensing ?
- Une communauté Open Source Spring démotivée ?
- Une confiance ébranlée ?
- Affaire à suivre …
Vers un dual licensing ?
Légalement, l’Apache License, Version 2.0 utilisée pour le code de Spring Framework précise la gratuité de l’utilisation et de la redistribution du code. Spring Source va-t-il introduire un nouveau type de licence pour les patchs « post trois mois » et mettre en place un dual licensing qui nous rappellera la licence MySQL ?
Dans le cas contraire, si les patchs restent disponibles sous licence Apache sur le gestionnaire public de code de Spring Source, la prolifération de versions non maîtrisées risque d’être fatale au framework.
Un autre scénario serait que Spring publie les sources des patchs et tag les versions sur le gestionnaire de code public de Spring Source. Il suffirait alors que quelqu’un publie les jars compilés sur le repository repo1.maven.org. La prolifération de versions serait alors empêchée. Ce scénario est peu probable car l’action de Spring deviendrait alors caduque, le serveur de téléchargement de Spring serait juste remplacé par celui de maven.
Une communauté Open Source Spring démotivée ?
Cette mesure démotivera sûrement les contributeurs indépendants qui ne verraient pas leur travail reversé à la communauté. Cependant, l’effet devrait être négligeable car les contributeurs des projets Spring sont quasiment tous employés par Spring Source (Cf. : « How Open Source is Spring?: An Analytical Investigation » par Patrick Mularien). Spring Framework n’est pas un projet Open Source à la gouvernance partagée comme nous les connaissons avec la fondation Apache mais un projet à la gouvernance exclusive de Spring Source à l’instar de Glassfish avec Sun ou JBoss avec Redhat/JBoss.
Une confiance ébranlée ?
L’image de Spring Source avait déjà été touchée par la polémique autour de l’utilisation d’une licence open source « business unfriendly » GPL v3 pour Spring Source Application Platform plutôt que de continuer à utiliser la « business friendly » Apache Software License (Cf. : « SpringSource Application Platform : la brèche dans Java EE« ).
Rod Johnson avait adouci sa méthode de communication en expliquant sa stratégie dans « Open Source, Open Strategy: The SpringSource Manifesto« . On pouvait y lire en gras encadré « We are not changing and will not change the license of any existing project. The Spring Portfolio will remain under the Apache License. This covers the Spring Framework, Spring Security, Spring Web Flow and the rest of the Spring Portfolio ».
Aujourd’hui, la communication de Spring Source par mise à jour de « note contractuelle » est plus abrupte que jamais et l’impact sur les licences semble en contradiction avec le Spring Source Manifesto publié en mai dernier. La polémique est déjà très forte et l’impact sur la confiance dans la roadmap de Spring sera durable.
Affaire à suivre …
La mise en oeuvre de l’annonce de Spring Source peut rendre le framework inutilisable pour les clients non commerciaux et tourner la page de la période Open Source de ce framework. Des alternatives à la roadmap plus rassurantes existent, notamment au sein de la fondation Apache, et cette aventure pourrait se révéler fatale à ce projet qui a modelé le monde Java actuel.
La communication abrupte et le manque d’explication sur la modalité de mise en oeuvre des licences laissent penser que Spring Source n’est pas à l’aise avec une annonce derrière laquelle on peut imaginer la pression d’investisseurs soucieux des revenus de l’entreprise.
La monétisation de l’Open Source est un sujet très difficile et les innovations de Spring Source en la matière très périlleux.
En attendant que la situation s’éclaircisse, cet épisode nous rappellera qu’il ne faut pas associer trop rapidement Open Source et pérennité. Les utilisateurs de Spring Framework se doivent de réfléchir à un avenir exclusivement commercial de leur framework.
[1] Voir Spring Framework changelog
Liens connexes et autres avis :
Billets sur le même thème :
Petite précision : les corrections effectuées dans les versions Enterprise seront aussi disponibles avec un peu de retard dans la version communauté de la révision majeure suivante.
Une version libre sort, pendant 3 mois la communauté open-source peut télécharger des corrections. Ensuite passé 3 mois, seuls les clients de la version Enterprise peuvent continuer à récuperer des patches pour cette version.
Cependant les corrections « payantes » deviendront disponibles pour la version communauté dans la version majeure suivante de Spring. Logique.
Mais j’avoue que je reste perplexe face à ce discret changement de la part de SpringSource… A la limite pourquoi 3 mois ? ou 6 mois ?
Cyril,
Je ne pensais pas que toi aussi tu suivrais ce type de rumeur… Je ne sais pas qui a lancé cette histoire, mais on arrive dans le n’importe quoi :
- non la licence de Spring ne change pas
- oui le code est toujours Open Source, et dispo gratuitement sur notre gestionnaire de source
Concernant les contributeurs, il est vrai que nous employions maintenant tous les principaux contributeurs de Spring et des projets associés. Je ne pense pas que cette annonce va faire baisser leur motivation.
Concernant les utilisateurs non commerciaux (ou qui ne prennent pas de contrat de support), cela va peut-être les pousser à utiliser les dernières versions de Spring (ça reste à vérifier, nos versions sont généralement très stables, et après 3 mois de prod ça devrait quand même aller). C’est, de mon point de vue, tout à fait dans la logique de l’Open Source, et tout à fait dans l’intérêt de la communauté.
A ce propos, Xebia étant partenaire de SpringSource, vous aurez en plus accès aux versions packagées par SpringSource, via le portail partenaires.
C’est pas très grave. Au pire il se passera quoi ? il y aura un fork entre le Spring « officiel » de Spring Source et son équivalent sous Licence Apache. Reste à savoir dans ce cas, lequel évoluera le mieux. Et même si le projet est uniquement sous gouvernance Spring Source, je ne doute pas une seconde qu’une communauté se fédèrera pour faire évoluer le fork de son côté. Je suis même près à parier qu’il évoluera bien mieux et bien plus vite que la version commerciale.
Pourquoi pas imaginer une récupération par la fondation Apache d’ailleurs.
« La mise en oeuvre de l’annonce de Spring Source peut rendre le framework inutilisable pour les clients non commerciaux et tourner la page de la période Open Source de ce framework ». Cette phrase est un peu catégorique à mon goût. Le framework dans sa forme actuelle sera pour toujours utilisable pour les clients non-commerciaux puisqu’il est sous licence Apache. Une page sera tournée en effet, celle de la gouvernance de Spring Source, mais certainement pas celle de l’ouverture du framework.
@Julien,
Merci pour cette précision sur le libre accès au code source des « patchs post 3 mois » pour les utilisateurs non commerciaux, je n’avais pas trouvé de clarification sur le site de Spring Source.
Le repository public de Spring Source continuera-t-il à porter les tags des « releases post trois mois » ?
Si c’est le cas, on peut imaginer la publication des « releases post 3 mois » sur un repository compatible avec la structure maven.
Dans le cas contraire, il me semble probable de voir foisonner des versions « à date » (ie des snapshots). Ce type de versions n’a pas très bonne presse auprès des équipes de Q&A et d’exploitation.
Pour ce qui est de la stabilité des versions de Spring après 3 mois, je trouve la qualité du code de Spring Source remarquable mais des projets comme Spring Security ou Spring Web MVC couvrent aujourd’hui des domaines dans lesquels l’accès aux security-fixes est primordiale. L’utilisation non commerciale de ces projets risques donc de déranger les équipes sécurité. De plus, je suis sûr qu’une étude de l’historique des defects Spring montrera la correction de bugs critiques après trois mois.
@Waddle
De mémoire, les forks de projets renommés, comme ce fut le cas pour l’initiative Unbreakable Linux d’Oracle, ont la vie difficile. Je suis donc dubitatif sur le succès d’un fork de Spring. De plus, au risque de me répéter, je trouve remarquable la qualité du code de Spring et je doute qu’un fork soit plus réactif et je ne vois pas comment les merges à chaque release n’entraîneront pas de problème d’upgrade pour les utilisateurs.
Pour le cas de la Fondation Apache, elle a des critères de gouvernance partagée et de propriété intellectuelle très strictes et je n’ai pas souvenir qu’elle ait accueilli un fork.
@Tous
Rod Johnson vient de donner des clarifications officielles sur InfoQ, l’affaire est bien à suivre
http://www.infoq.com/news/2008/09/springsource-maintenance
Cyrille (Xebia)
Cyrille, tu touches là le vrai problème : on commence à avoir tellement de projets avec tellement de versions différentes, qu’on ne peut plus garantir une maintenance de qualité sur tout. D’où le choix de privilégier les versions les plus récentes (dans le pur esprit Open Source), et les clients (étant donné qu’ils payent, c’est la moindre de choses!).
Pour les tags dans le repo public, je ne sais pas si la réflexion en interne est allée jusque là. Par contre, et pour faire le lien avec les forks, il en existe déjà : il y a des sociétés qui proposent du support sur Spring, avec leurs propres patchs, et qui n’ont aucun lien avec nous. Il y en a même plusieurs en France. Dans la pratique, aucune d’entre elles n’a jamais redonné la moindre ligne de code au projet Spring. Donc, :
1) Soit elles ne font pas vraiment de patch, et attendent juste que SpringSource corrige : dans ce cas, je doute fort qu’elles aient les compétences techniques pour réaliser un fork.
2) Soit elles font réellement des patchs, et ne les redonnent pas au projet Open Source -> je pense que la communauté devrait plus s’inquiéter de ce type de comportement, sachant que du côté de SpringSource nous avons toujours redonné notre code à communauté, et nous continuerons de le faire.
Apache a hébergé les réfugiés de JBoss qui ont monté Geronimo. Pour ce qui est du résultat, je laisse le lecteur juger…
Au delà de tout ce que j’ai écrit (merci pour le lien, Cyrile) je pense que le coeur du sujet n’est pas technique ni même sur la monétisation de l’open source, mais sur la valeur du standard: s’appuyer sur un fournisseur unique est toujours risqué.
Julien, je suis étonné de ta phrase à Cyril : « Je ne pensais pas que toi aussi tu suivrais ce type de rumeur ».
Où est la rumeur ? Le communiqué de presse existe, soit de nombreuses personnes l’ont mal interprété, soit il est mal formulé. Dans tous les cas c’est à SpringSource de clarifier la situation sans agiter la théorie du complot anti-SpringSource vers tous ceux qui veulent des clarifications.
Sur le fond, si je prends une autre de tes phrases « Concernant les utilisateurs non commerciaux (ou qui ne prennent pas de contrat de support), cela va peut-être les pousser à utiliser les dernières versions de Spring », j’en déduis que seul les builds des versions antérieures ne seront pas disponibles pour la communauté dans ce cas c’est une mauvaise formulation du communiqué de presse qui est la base de la polémique. SpringSource publie une mise au point et le débat s’arrête là.
Par contre si aucun build n’est disponible pour la communauté, passé 3 mois, et ce même sur la version courante, là c’est clairement une façon de procéder peu commune dans le monde open-source qui va à l’encontre de ton argument sur le fait de pousser la communauté à utiliser les dernières versions.
@Alexis,
C’est justement en pensant aux anciens committers clefs de JBoss qui ont rejoint le projet Apache Geronimo que j’ai parlé de critères de propriété intellectuelle très strictes au sein de la Fondation Apache
. De mémoire, la Fondation avait même du répondre à une lettre des avocats de JBoss et chaque ligne de code a été vérifiée.
Pour le résultat de Geronimo, la dimension politique de ce projet est très importante. Gluecode, la société à l’origine de ce projet, savait qu’IBM percevait le serveur JBoss comme un rival difficile à contrer par sa nature open source et s’est habilement fait racheté près de 100 millions de dollars (cf The Server Side – 2005/05 : IBM Purchases GlueCode Software. Je vous rejoins, 100 millions de dollars plus tard, les parts de marché se font attendre
.
Quant à la valeur du standard. Je vous rejoins sur le fait qu’être open source n’offre que peu de garanties de pérennité malgré la croyance actuelle que l’open source offre plus de garanties qu’un standard. Les uns comme les autres sont aujourd’hui parfois utilisés par des éditeurs ou des groupes d’influence pour promouvoir leurs intérêts.
Avez vous un scoop Alexis ? Glassfish ESB implémentera-t-il les standards OSGI et SCA ?
.
Cyrille (Xebia)
@Alexis
Si l’on en croit d’autres rumeurs (http://www.adam-bien.com/roller/abien/entry/is_springsource_working_on_ejb) Spring serait en train d’implémenter un container pour les futurs EJB 3.1. Si tel est le cas, Spring implémenterai alors un standard.
@Cyrille
Pas d’OSGI dans GlassFish ESB. Par contre Project Fuji en prend résolument la direction: http://fuji.dev.java.net
@Antonio, Julien et Alexis,
Rod Johnson avait annoncé son vif intérêt pour le Web Profile dont l’introduction était prévue pour Java EE6 (cf Java EE 6 Gets it Right par Rod Johnson, Juillet 2007).
Avez-vous des informations sur cette nouveauté du standard JavaEE 6 ? Verrons-nous un Web Profile ? Spring Source prévoit-il toujours de l’implémenter ?
Cyrille (Xebia)
Je viens de poster une réponse « officielle » de SpringSource :
http://www.springsource.com/fr/blog/nouvelle_politique_de_maintenance
Sur notre site US, un FAQ va finir de clarifier tout cela très rapidement.
@Bruno : quand on dit que cette politique va s’appliquer maintenant, elle n’est bien entendu pas rétroactive!! On ne va pas t’enlever ton Spring 2.5.5. Comment d’ailleurs voudrais-tu qu’on fasse?
En pratique, il s’agit simplement d’un moyen de ‘capturer’ ses clients, tout en limitant les frais de maintenance. Tout projet un tant soit peu conséquent ne pouvant pas basculer d’une version à l’autre tous les trois mois, il est clair que cela devrait génèrer les revenus associés dès lors que le client a déjà investi massivement sur les technos Spring.
Il s’agit d’un model business comme un autre (on ne vit pas d’amour et d’eau fraiche), mais pour les gros utilisateurs, cela va poser un réel dilemme :
- continuer mais payer (combien ?)
- ou laisser tomber Spring ?
Cela dit, pour SpringSource, je crois que le problème est ailleurs : comment se positionner en tant qu’acteur économique majeur quand le monde de l’entreprise est déjà capturé par IBM/Oracle/RH, ou plutôt comment rendre la mariée plus belle avant son rachat par un des gros qui ne dispose pas d’un stack J2EE… Ou alors, redevenir une simple entité tehnologique à la Thoughtworks. Je ne crois pas qu’il y ait d’alternative, en tout cas pas dans le domaine du serveur d’application…
PS: en ce qui concerne la phrase « nous investissons chaque année plusieurs millions d’Euros dans le développement de logiciels libres » : L’open source ce n’est pas seulement du code disponible avec une license confortable. C’est aussi une gouvernance, et une communauté diversifiée. Je ne crois pas que cela soit le cas pour Spring.
@Cyrille
Je fais parti de l’expert groupe Java EE 6 (JSR 316 http://jcp.org/en/jsr/detail?id=316) et pourtant je ne saurai définir clairement le contenu du profile web (avec ou sans EJBs ? uniquement Servlet ou JSP ? JSF ou pas ?…). Le consensus au sein du groupe n’est pas clair. Par contre, nous sommes plutôt parti sur l’approche : un profil, une spécification. C’est à dire qu’il y a fort à parier que Java EE 6 ne viendra pas avec un profile web. En fait, Java EE 6 ne viendra avec aucun profile. Il faudra attendre la spécification « Profil Web » pour en connaitre son périmètre.
@Julien
)
Heureusement que tu n’as prévu de venir récupérer la version 2.5.5 sur ma machine
Quand je parlais de la version courante c’était en me plaçant dans le future, après application de la nouvelle politique. Prenons le cas de la version 3, ce qui serait acceptable et cohérent par rapport à l’argumentaire développer sur ton blog (limiter l’utilisation d’anciennes versions) c’est que les versions 3.0.x soient disponibles même en dehors du délai de 3 mois mais par contre que les versions 2.5.x ne le soient plus passé ce délai (3 mois après la sortie de la version 3.0).
Ce que le premier communiqué laisse penser c’est qu’une fois le délai de 3 mois passé, il n’y aurait plus de builds accessibles pour la communauté, et ce même si la sortie de la version suivante (3.1, 3.5 ou 4) devait intervenir plusieurs mois plus tard.
Merci de répondre clairement en disant lequel des deux scénarios est le bon.
D’autre part, si tu as des éléments sur le prix de la version payante, je pense que pas mal de monde serait intéressé.
La SpringSource Enterprise Maintenance Policy FAQ dont parlait Julien vient d’être publiée.
http://www.springsource.com/products/enterprise/maintenancepolicy/faq
Cyrille (Xebia)
D’après la SpringSource Enterprise Maintenance Policy FAQ, Spring Source ne changera pas la licence du code et continuera à committer les patchs « posts trois mois » dans le repository CVS public de code source de Spring. Cependant, ces patchs ne seront pas taggés.
Par conséquent, les utilisateurs non commerciaux pourront profiter des mises à jour en buildant des versions SNAPSHOT à date (e.g. spring-core-2.5-20080924-0742.jar ) ; le build Ant dure deux minutes.
Un détail technique d’importance : CVS, à la différence de subversion, n’offre pas de mécanisme de numéro de révision (cf Subversion in action : revisions). Par conséquent, il sera très difficile d’identifier sans ambiguïté la version de source utilisée pour un build. Les différences de fuseau horaire augmenteront encore la confusion. Est-ce une version 2.5-20080924-0742-GMT ou 2.5-20080924-0742-EST ?
Nous assisterons donc très probablement à la prolifération de versions qui seront de surcroît erronées alors que la traçabilité des versions est une préoccupation aujourd’hui très importante (notamment avec la généralisation de Maven).
Par ailleurs, Spring Source n’a pas répondu dans sa FAQ à la crainte aujourd’hui fréquente dans la blogosphère que les patchs soient publiés sur le repository public avec retard pour inciter les clients à souscrire à un contrat de support. Cependant, étant donné que la plupart des développeurs de Spring Source sont des contributeurs Open Source au passé prestigieux, nous pouvons douter que la société adopte une politique aussi en désaccord avec l’esprit Open Source. Une telle attitude causerait sûrement d’importantes controverses internes.
Enfin, il serait imaginable, pour prévenir la prolifération de versions incertaines, de voir émerger une entité qui publierait des versions « post trois mois » sans ambiguïté sur un repository compatible maven. Ce repository prendrait alors le relais sur http://repo1.maven.org/maven2/org/springframework/ . Cependant, il n’est pas à exclure que Spring Source ait les moyens juridiques comme par exemple un copyright sur le nom « spring framework » pour empêcher une telle initiative.
Un dernier point : les releases « post trois mois » que Spring Source fournira à ses clients utiliseront la licence commerciale de Spring Source (comme le permet l’Apache Software License). Par conséquent, il ne sera pas possible de diffuser ces patchs sans l’accord de Spring Source. Cette pratique est commune avec les licences Apache (e.g. IONA FUSE avec ActiveMQ, CXF et ServiceMix ou encore Websphere Community Edition avec Geronimo).
Cyrille (Xebia)
Si les récents communiqués officiels finissent par être clairs, je trouve dommage que vous ayiez initialement justifié cela par un manque de temps pour le packaging. Publier les dernières releases de la branche courante (ie 2.5 actuellement) aurait représenté le même effort de travail.
Il est regrettable que l’état-major de Spring Source ait été obligé de venir à la rescousse d’une note administrative laconique et compliquée à comprendre alors qu’une explication préalable aurait permis de dépassionner la discussion.
Je pense que la majorité des utilisateurs préféreraient que vous nous communiquiez quelques détails croustillants des killer features de Spring 3.0. D’ailleurs, pour les aspects Open Source et communautaire, il semble que le développement du premier milestone se termine … sans que le public n’y ait réellement accès (cf Matt Raible : How Open Source is Spring?). Pouvons-nous interpréter cela comme une évolution vers un modèle Public Source auquel nous a habitué Atlassian ?
Le deuxième scénarios de mon message précédent semble donc être le bon (la nouvelle politique s’appliquera à la version courante). Ce qui me choque alors ça le mépris à l’intelligence des membres de la communauté en justifiant cela par la nécessité de limiter les versions utilisées en faisant passer tout le monde aux versions les plus récentes. Sans compter des phrases du genre « ça ne change rien à la situation actuelle », car c’est clairement faux.
Que SpringSource cherche des sources de revenu pour continuer à faire avancer le projet est tout à fait acceptable, mais dans ce cas la bonne approche est de proposer une version commerciale qui apporte de nouvelles fonctionnalités. Là il s’agit de faire payer un service précédemment offert (la mise à disponibilité des builds). C’est un choix, mais il faut l’assumer pleinement et, notamment, il ne faut pas s’étonner des réactions de la communauté qui a largement participé à la renommée de Spring et qui a maintenant l’impression d’être contrainte de passer à la caisse (ou de bricoler ses propres builds).
Pour le futur ça me semble un choix tout à fait contre productif pour la qualité de Spring : les membres de la communauté sont les plus gros testeurs, s’ils n’ont pas accès au build 3.0.2, par exemple, qui va remonter les bugs ? (les seuls entreprises ayant acheté la maintenance….).
Quelques réactions dans le monde OSS anglo-saxon :
http://bill.burkecentral.com/2008/09/23/spring-source-the-drug-dealer-approach-to-oss/
http://www.1060.org/blogxter/entry?publicid=94D1E729BC0050419B903D16FE7C073D
Il est clair que la décision de SpingSource n’est pas bien vu…
[...] Nouvelle politique de maintenance de Spring : La très périlleuse route de la monétisation de l… [...]