Tomcat, un projet à la gouvernance partagée

Identifier le(les) acteur(s) clef(s) d’un projet Apache présente quelques subtilités.

En effet, la Fondation Apache exige des projets qu’elle héberge un partage de la gouvernance sur le principe de méritocracie. Ainsi, un projet qui ne serait animé que par une société contreviendrait à l’esprit de la Fondation.

C’est notamment la raison pour laquelle le projet CXF n’est toujours pas sorti de l’incubateur : la plupart des acteurs clefs du projet étaient employés par IONA.

Ce principe de gouvernance partagée complexifie l’identification des acteurs clefs d’un projet. Une démarche est de retrouver les employeurs des committers actifs [2]. Ces sociétés proposent souvent du support commercial sur les projets auxquels participent leurs employés.

Enfin, j’insisterai sur le rôle clef des sociétés qui fournissent du support sur les middlewares open source en me référant à récent billet Support for GlassFish – What’s in it for me? .

Covalent, acteur clef de Tomcat

quelques éléments pour voir en Covalent un acteur clef de Tomcat :

- Covalent est Silver Sponsor de la Fondation Apache (4 ème donateur après Google, Yahoo! et HP).

- Covalent est l’une des deux grandes sociétés de support de Tomcat avec SourceLabs. Covalent supporte plus de 400 organisations (notamment 50% des Fortune 500 et 20% des Global 2000).

- Covalent emploie plusieurs acteurs clefs du projet Tomcat (source Ohloh : Tomcat contributors), des committers jusqu’au PMC Members comme Jim Jagielski ou Filip Hanik.

Covalent, absent du marché français

Covalent n’a pour le moment que des bureaux aux Etats Unis et ne propose que du support en langue anglaise.

Je vous rejoins complètement sur la langue et l’éloignement qui sont des freins majeurs pour des clients.

… et je suis plein d’espoirs après le rachat de Covalent par Spring Source qui a des bureaux dans de nombreux pays [3] et qui prévoit de se développer encore plus

Cyrille (Xebia)

[1] Ce partage de gouvernance est différent de l’approche qu’ont choisi d’autres projets open source célèbres non moins célèbres comme Glassfish, JBoss, MySql, SpringFramework (cités par ordre alphabétique).
[2] Le portail ohloh et la liste des ASF Committers by Project Modules sont des bons points d’entrée pour mener cette analyse.
[3] USA, Canada, UK, The Netherlands, Germany et Australia pour le moment.

A tout seigneur, tout honneur [1]. MySQL, dans le domaine des SGBD, est largement plus utilisé en production que Tomcat .

> si les serveurs d’application vont gagner en modularité

Les profiles JavaEE et les modèles de composants (JSR 291 – OSGI, JSR 277 – Java Module System, HK2) [2] sont des voies prometteuses pour modulariser nos serveurs d’application mais
- J’espère que le très politique débat OSGI versus JSR 277 – Java Module System ne va pas ralentir le JCP
- Tomcat va peut être emprunter plus vite ce chemin avec le rachat par Spring Source de Covalent, l’acteur clef de Tomcat. Rod Jonhson, fort de la récente sortie de Spring Dynamic Modules for OSGI, évoque à demi-mot l’osgi-fication de Tomcat.

> et les spécifications justifier d’aller au delà de Servlet/JSP/Spring

Spring a toujours été un ardent promotteur des API JavaEE (excepté EJB mais ce n’est qu’une petite partie de Java EE). On peut même voir Spring comme le démocratiseur de JMS, JTA ou JCA ; des APIs que Tomcat, à la différence des serveurs Java EE, n’implémente pas [3].

Pouvez-vous nous éclairer sur des spécifications qui nous donneront envie d’utiliser un serveur JavaEE complet plutôt qu’un simple moteur de servlet comme Tomcat ? Vous nous en avez dit trop ou pas assez

[1] Jonathan Schwartz’s blog : … we’re putting a billion dollars behind the M in LAMP
[2] Resources : Enterprise OSGi, a Discussion with Eric Newcomer, Javapolis : JSR-277 Java Module System, The Hundred Kilobytes Kernel (HK2).
[3] On remarquera en plus que les implémentations open source d’API comme JTA manquent encore de maturité, JOTM a certes beaucoup de qualité mais ObjectWeb n’a pas la notoriété de la fondation Apache.

Cyrille (Xebia)

Même avec des rachats?

> Tomcat, la nouvelle menace des serveurs J2EE

Tomcat est #1 loin devant tous les autres et depuis longtemps. La question est de savoir si ça va durer ou si les serveurs d’application vont gagner en modularité et les specifications justifier d’aller au delà de Servlet/JSP/Spring. Je pense que oui (sans m’engager sur du volume ou une date bien entendu )

Pris par les exigences de concision de notre revue de presse, j’ai manqué de clarté. Quelques précisions :

JBoss est moins menaçant qu’en 2003/2005

A cette époque, certains croyaient que les grands éditeurs commerciaux de serveur J2EE seraient balayés par cette startup qui apportait une concurrence d’un nouveau genre. Cela n’a pas été le cas.

JBoss a certes de très belles parts de marché mais n’a pas ébranlé les positions des éditeurs commerciaux et il n’y a pas de raison que cet équilibre soit bouleversé dans un futur proche.

JBoss est progressivement devenu un acteur similaire aux éditeurs commerciaux. C’est maintenant un acteur très ‘classique’ (avec des commerciaux, du marketing, des contrats de support, etc) auxquels les éditeurs commerciaux sont habitués. Le côté menace d’un nouveau genre s’est estompé.

La banalisation des serveurs J2EE open source professionnels

Comme vous le disiez, les serveurs J2EE open source se sont banalisés (Geronimo, GlassFish, JBoss). Cependant, c’est de l’open source largement supporté par des éditeurs commerciaux qui proposent une offre de support.

On peut y voir une nouvelle équation économique de la commercialisation de logiciel : un éditeur porte un projet open source (souvent avec une gouvernance exclusive) et vend du support.

Tomcat, la nouvelle menace des serveurs J2EE

Les serveurs J2EE rencontrent aujourd’hui une nouvelle forme de concurrence avec l’essor moteur de servlet open source Apache Tomcat.

C’est une fois de plus une concurrence en rupture qui s’inscrit dans la lignée des ‘lightweight containers’ (Spring Framework, etc).

Face à ce concurrent, JBoss, l’ancien challenger, se retrouve aujourd’hui tout aussi historique que BEA, IBM ou SUN.

Les éditeurs de serveurs J2EE sont armés pour répondre à Tomcat et l’émulation se fera au bénéfice des clients

Cyrille (Xebia)

It’s true what you wrote. However, I’d like to add two things: (1) I didn’t mention how to choose a certain GC, as it matters not, because of (2) the JVM usually picks the right GC based on the amount of memory and the amount of processors your machine has.

It’s interesting to see how GC works, because then you’ll be confident that it works well and you won’t try to make « tricks » to outperform it – It’s almost impossible to outperform the GC. But that’s another post’s point.

Peut-être qu’ils sont beaucoup plus entrés dans les moeurs?

Here is a basic translation :

« Presentation of some garbage collection algorithms of Sun’s JVM

It is always interesting to know about the behavior of the JVM’s garbage collector. Once should still keep in mind that optimizing an application changing the garbage collector mechanism doesn’t make miracles : optimizing a business aplication usually go through optimizing the code itself. »

Thanks for your interesting blog post, it has been a pleasure to read it.

Cheers,

Cyrille (Xebia)