Publié par

Il y a 11 années -

Temps de lecture 4 minutes

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 ?

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 :

Publié par

Publié par Cyrille Le Clerc

CTO de Xebia, Cyrille est aussi committer sur le projet Apache CXF. Après être récemment intervenu sur les sites web et les plateformes de web service à fort traffic d'opérateurs de télécommunication, Cyrille est actuellement responsable de la mise en place d'une grille de données inter-continentale pour une grande institution financière française. Après 7 ans chez IBM Global Services et 5 ans chez Xebia, Cyrille a une expérience variée allant du monde commercial aux écosystèmes Open Source dans des approches aussi bien très cadrées et contractuelles que légères et agiles. Cyrille est aussi blogger sur blog.xebia.fr et speaker dans des conférences (In Memory Data Grids & NoSQL, applications prêtes pour la production, etc).

Commentaire

21 réponses pour " Nouvelle politique de maintenance de Spring : La très périlleuse route de la monétisation de l’open source "

  1. Publié par , Il y a 11 années

    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 ?

  2. Publié par , Il y a 11 années

    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.

  3. Publié par , Il y a 11 années

    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.

  4. Publié par , Il y a 11 années

    @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)

  5. Publié par , Il y a 11 années

    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.

  6. Publié par , Il y a 11 années

    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é.

  7. Publié par , Il y a 11 années

    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.

  8. Publié par , Il y a 11 années

    @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)

  9. Publié par , Il y a 11 années

    @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)

  10. Publié par , Il y a 11 années

    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?

  11. Publié par , Il y a 11 années

    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.

  12. Publié par , Il y a 11 années

    @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.

  13. Publié par , Il y a 11 années

    @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é.

  14. Publié par , Il y a 11 années

    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)

  15. Publié par , Il y a 11 années

    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 ?

  16. Publié par , Il y a 11 années

    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….).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.