Java est-il trop “serré” ?

Récemment, une énième discussion a enflammé les esprits sur les forums techniques. Vous savez bien, c’est une discussion qui démarre sur l’état de l’art et qui se termine en considérations sans fins sur les qualités comparées avec un “vieux langage” que-sur-des-cas-précis-il-ne-sera-jamais-dépassé…

C’est un fait que l’écosphère Java souffre actuellement d’une offre pléthorique (Struts/Stripes, Tapestry, JSF, Spring MVC, GWT, JavaFX… j’ai la tête qui tourne) et redondante (cf. débats actuels Java EE 6 vs. Spring 3.x ou la foule des portails, GED ou ESB apparus). Il est vrai aussi que :

  1. les débutants sont mal formés, notamment sur les paradigmes OOP, AOP et SOA
  2. les développeurs expérimentés s’épuisent à passer d’un framework à l’autre
  3. les architectes n’ont pas le temps d’évaluer les versions qui sortent en permanence

Sans parler des projets tellement évolutifs qu’ils embarquent plusieurs technologies Web Services en même temps ou pâtissent de toutes sortes de dettes techniques, faute de recevoir une maintenance planifiée…

Mais a contrario, en Java les standards évoluent tellement lentement qu’on leur préfère des solutions alternatives à forte obsolescence. On en est là. Avouez que c’est quand même dommage de faire preuve d’immaturité à cet âge ! De mon temps (hum) les bonnes idées étaient simplement reprises et transcendées au sein de la “meilleure” communauté créée.

Mais aujourd’hui il semblerait que notre industrie soit en guerre. jBoss vs Spring, Adobe vs Google, Hudson vs Jenkins… Faut-il pour autant prêcher la dictature comme remède à l’anarchie ? Nous ne voulons pas devenir .Net, si ? Bref, j’exagère (à peine).

Pourquoi le monde Java en est-il arrivé là ?

Selon moi, c’est à cause de son succès, justement. Le niveau d’activité de la communauté me semble tout à fait remarquable, notamment dans l’Open Source, mais pas que. Le revers de la médaille, c’est qu’un si grand nombre d’intervenants implique le ralentissement des prises de décision, favorisant ainsi l’adoption de solutions spécifiques ou inachevées.

Avant, c’était mieux (n’est-ce pas ?). Un serveur d’application Tomcat et quelques spin-off, un peu d’injection et de bonnes pratiques ORM et c’est parti pour le framework léger. Un IDE sympa, avec quelques plugins utiles. En plus, tout ça gratos ! Et l’enthousiasme du fait main se répandait dans les entreprises à la faveur des SCM. Ajoutez à cela les annotations, et l’on a pu croire un temps que nous serions productifs.

Bon… ça n’a pas vraiment suffit. N’est-ce pas ? Alors il y a eu Maven, l’intégration continue et même l’agilité. Et BOUM ; peut-être que ça marche trop bien, finalement : tout le monde s’est mis à parler/publier en même temps, la tête dans le guidon. Une vraie course à la nouvelle version.

Mais alors qu’est-ce qu’on va FAIRE (Mon Dieu) ?

Nous avons une responsabilité, en tant que communauté et en tant que professionnels. Cette responsabilité est de suivre un cap réfléchi pour assurer à nos utilisateurs et à nos clients une certaine forme de pérennité. Je ne parle pas de 10 ou 15 ans, bien sûr. En technologies de l’information et de la communication (comme on dit), c’est l’éternité ! Et c’est enfoncer une porte ouverte que de proposer un socle commun stable. Nous SAVONS ce qu’il nous faut. La question est COMMENT l’obtenir.

Et bien je pense personnellement que la République des Experts, c’est fini. Il nous faut une Démocratie Participative (notez les majuscules, je vous prie). Nous vivons actuellement une période transitoire qui pourrait très bien aboutir à un verrouillage par quelques grands acteurs (parmi Adobe, Google, jBoss ou d’autres), au détriment de la créativité et de la réactivité. Pour éviter cela, je pense que les développeurs devraient pouvoir influer sur les orientations du marché pas seulement par plébiscite, a posteriori, mais aussi en amont sur la base d’une information éclairante.

The Apache Software Foundation nous a montré la voie (par le truchement de l’incubation et d’un processus électif). Mais la méritocratie (qui a dit bureaucratie ?) n’est pas suffisante. Avez-vous compté le nombre de projets que la fondation héberge, récemment ? Là aussi, le débordement fait plus que nous guetter : il nous attend au tournant. Certaines idées méritent plus qu’un avis technique, il leur faut un coup de pouce (comme dans l’expression “Je poussoies”, bien sûr) afin de leur assurer l’effort requis. Et chacun, comme pour une primaire politique, devrait pouvoir donner sa voix sur la teneur des projets à privilégier.

Nous n’avons pas besoin d’une dizaine de bases NoSQL ; nous avons besoin d’une (aller, deux) solutions qui fonctionnent et garantissent une réponse à une problématique réelle (mais je garde pour moi mon opinion, concernant cet exemple précis). Les outils existent, je regarde vers GitHub (en tant que plateforme collaborative, peu importe que le support soit Git ou SVN, au fond). Nous savons fédérer la motivation ; mais il nous reste à exprimer l’intérêt plus tôt au cours du processus de développement afin d’éviter le gâchis actuel qui consiste à jeter nos forces dans des projets concurrents, parfois complètement équivalents, mais dont personne ne veut abandonner la paternité.

Un processus démocratique, ouvert, devrait permettre aux solutions d’avenir de recevoir suffisamment de moyens pour percer, prendre le temps de se stabiliser, et enfin s’imposer. Non pas sur une mode qui aurait duré, mais sur la qualité d’une réalisation ayant reçu toute l’attention nécessaire.

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

4 réflexions au sujet de « Java est-il trop “serré” ? »

  1. Je me suis penché sur le développement des logiciels libres. Et j’ai proposé une idée : FDD pour Fund-Driven Development, http://www.jroller.com/dmdevito/entry/revisiting_donation_funding_for_open

    Cela rejoint le contenu de votre billet. Comme vous dites: “Certaines idées méritent plus qu’un avis technique, il leur faut un coup de pouce afin de leur assurer l’effort requis” : perso, il me semble que le financement comme aide au développement d’un logiciel libre pourrait être un levier important, i.e. un des (rares) types de coups de pouce possibles, au delà d’un avis technique.

    Car “exprimer l’intérêt plus tôt au cours du processus de développement afin d’éviter le gâchis actuel”, c’est une chose, mais comment donner du poids à cette expression ? Sans poids, cette Démocratie Participative des développeurs s’évanouira rapidement… Dans l’approche que j’ai détaillée, le financement d’un projet open source par une assemblée de développeurs peut être mis à profit pour orienter la feuille de route dudit logiciel.

    1. Merci de cette excellente contribution.
      Pour ma part, j’ai voulu laisser ouverte la question du modus operandi dans l’article ; j’espère qu’ainsi d’autres bonnes idées pourront s’exprimer ici.

      Qui dit “free” dit (aussi) gratuit. Il ne serait pas souhaitable, par exemple, que les plus “riches” s’octroient les rênes d’un projet (ploutocratie) ; je suis plus branché “one man, one vote”. Mais je ne serais pas contre un ticket d’entrée minimum (mais extensible) dans la(les) communauté(s). Si chaque membre avait, disons, 20 points à répartir entre les features proposées pour exprimer la valeur qu’il leur accorde, et en plus le droit d’ajouter des idées au backlog, ça pourrait très bien fonctionner.
      On doit peut-être aussi imaginer de valoriser la participation des développeurs bénévoles.

      1. Oui, on peut imaginer différents modus operandi ~ imaginer différents réglages des paramètres présidant au fonctionnement du FDD (qui peut être vu comme du crowd-funding, mais pas seulement), histoire de ne pas se retrouver dans une situation néfaste à la vie de la communauté et du logiciel libre (a priori, on pourrait appeler une telle situation une situation de dead-lock pour réutiliser un vocable bien connu).

        La plate-forme Elveos permettait de faire du crowd-funding, mais elle a fermé ses portes. De manière plus générale, je pense que ce devrait être le rôle d’une communauté open source (Apache, Eclipse, OW2….) que d’offrir un tel service. Une communauté open source doit se vivre/définir comme un hub ou un facilitateur : on peut donc très bien imaginer qu’elle offre un service de FDD (~crowd-funding). Comme je pense qu’il faut éviter que le PMC (Project Management Committee) d’un projet open source ne se sente déposséder de la vie de son projet, le PMC, ou peut être plus simplement les committeurs, devraient être associés au plus tôt à une initiative FDD.

        PS : en tant que hub/facilitateur, je pense qu’une communauté open source devrait offrir aussi un réseau social pour ses développeurs. En d’autres termes, “Open source communities may benefit from leveraging distributed social networks” http://www.jroller.com/dmdevito/entry/open_source_communities_may_benefit

      2. Je viens de découvrir que PrimeFaces a adopté un modèle FDD (Funding-Driven Devleopment): http://www.primefaces.org/funding.html

        Cool !

        “PrimeFaces Feature Requests can be funded by the community collabaration. Below is the current list of all the feature requests that are available to be sponsored. When funding of a feature reaches the goal, it will be implemented by PrimeFaces Team in next major version of PrimeFaces. Payment is done over PayPal so please make sure to add the issue number to indicate which feature you are funding. Note that Prime Teknoloji do not provide invoices for donations lower than 50$.”

Laisser un commentaire

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


*