Les nominés/accusés sont -par ordre alphabétique- :

eXo / GateIn

eXo -qui propose associé à son portail une suite ambitieuse : WCM, GED, suite collaborative, Knowledge suite, etc.- s’associe avec JBoss pour sortir GateIn. Version 3.0.0 beta 4 en ce moment même. Un produit orienté middleware si l’on croit sur parole le touilleur. Les retours d’expériences sont cependant alarmants. eXo/GateIn doit vite stabiliser son cycle de développement, son code, sa plate-forme pour être à la hauteur de ses ambitions (et renforcer son équipe).

Jalios

Une société française, un code propre, des retours d’expériences corrects, une solution probablement en devenir. à surveiller. à tester. à challenger.

Jahia

Le succès de la version 4, les erreurs de la version 5 : Jahia a manifestement fait de gros effort pour refactorisé son code, son produit. Ses forces sont ses faiblesses : son positionnement d’éditeur (avec une licence finalement pas donnée pour accéder à toutes les fonctionnalités), l’intégration du CMS dans le portail. Il faudrait désormais valider la pertinence de la version 6 et rentre les interfaces plus souples (on intègre GWT mais les portlets restent désespérement statiques). Commence à être bousculé par Lutèce ou Jalios.

JetSpeed2

Un beau labo. Pour faire des expériences donc.

Liferay

Constance et qualité sont les deux forces indiscutables de Liferay. Ce portail qui s’appuie désormais sur une communauté et un succès énorme se limite -pour l’instant- à être un portail, mais il le fait très bien. Son succès entraine d’autres succès : adhérences nombreuses, extensions nombreuses, etc. De très bons retours d’expériences.

Lutèce

Un portail, un CMS, de bons retours d’expérience. Une solution assez neuve qui doit faire ses preuves mais qui semble s’imposer au sein des collectivités (CMS). A surveiller, à évaluer.

uPortal

Très orienté universités et instituts de recherche aux US. Peu de retours ici, chez les frenchy.

La conférence était organisée sur une alternance des “prez” 30mn sur un domaine, 30 mn sur l’autre durant 4h, saupoudrez de 30mn de pause.  Claude Aubry menait les affaires concernant Scrum, et David Larlet prenait en main les choses Python. Comme je vous le disais venant des deux mondes je me suis senti “dans le bain”, mais je m’interroge sur les personnes n’étant venu que pour un seul domaine. D’un côté cette alternance donnait du rythme mais d’un autre elle a peut-être empêché de creuser assez un sujet, ou d’interroger assez précisément un intervenant : pas assez de temps libre “off” avec les intervenants ! ,  une déception je n’ai pas eu le temps de parler rock’n roll avec Claude Aubry entre autres.

Pour résumer, c’était très agréable de replonger dans le bain django/python, et cela semble être comme le vélo : on n’oublie pas. Mais je reste encore dubitatif sur la percé du langage dans les entreprises ne serait-ce qu’en raison de la rareté des compétences locales.  Quand à Scrum rien de nouveau de mon côté, mais ce fut un plaisir de croiser et d’entendre cette présentation par Claude Aubry (il faut que je m’achète un chrono de cuisine pour mes timeboxes). J’ajoute : très beaux slides de David Larlet : simple et évocateur (des planches creative commons de flickr), une bonne idée que je vais reprendre (mais n’est-il pas developpeur web ? )

Enfin, première rencontre avec les gens de Particul.es. Sympa ! A ce sujet, ces deux conférences en une sont le prélude de formations/coaching autour de ces deux domaines (Python/Django & Scrum). Je vous encourage à aller sur le site pour en savoir plus (http://particul.es).

[ajout] Réflexion dans le bain cet après-midi : le vrai point commun entre Scrum & Python c’est le fait qu’ils sont tous les deux compacts. On s’approprie facilement et aisément les règles, librairies, de ces deux outils. inutile d’aller fouiller dans une documentation pour consulter le point x-44-b (comme Java par exemple qui se noie sous la documentation, ou CMMi…). L’outillage est là, présent, facile à appréhender, à l’esprit : c’est productif.

Ps : ci-joint un arbre des solutions PHP que je viens de réaliser, un dessin valant mieux qu’un long discours.

Si vous souhaitez m’éclairer sur une solution opensource, fiable, php, qui complète ce diagramme je suis preneur !

Basé sur PHP, a première vue le code parait surprenant, on ne voit pas immédiatement dans l’arborescence projet où se trouve quoi, et à quoi sert tel ou tel dossier. Tout ce qui se conçoit clairement se déploie clairement, et cette première impression reste mitigée. Je vous en dirais plus lorsque j’aurai vraiment essayé de toucher au code. Je suppose que cela est du au modèle de données : apparemment il a été prévu un modèle très malléable : j’introduis un nouveau type d’élément (une entité), je lui donne telle ou telle propriété avec telle ou telle valeur. Du coup demain si j’ai un élément de type nouveau, pas de problème, pas de modification de la structure des tables, ça roule. Bon, pour l’instant mon analyse est très superficielle donc sujette à caution. Je compte creuser et vous informer. Je ne sais pas si ce modèle n’a pas un impact sur les performances aussi, que je trouve un chouïa poussives (ils ont cependant prévu l’utilisation de memcached ou autre pour optimiser celles-ci). Idem pour le design, et le système de templates, je n’ai rien vu de concret jusqu’à présent. Enfin, un dernier petit point : l’installation se fait cahin-caha : il faut nécessairement activer le mod_rewrite de Apache. J’aurais préféré avoir le choix d’utiliser le rewrite ou non, cela pourrait faciliter le debug.

Bref il me faut creuser, car c’est malgré tout très prometteur (ah j’oubliais aussi de signaler  une API REST qui permet à l’accès à toutes les fonctions de l’outil, même si un warning indique qu’elle peut encore secouer un peu).

J’ai pu assez (très) rapidement monter une plate-forme, activer tout un tas de plugins à la facebook, twitter, pages, blog, albums photos, fichiers, etc. C’est du PHP/MySQL/Apache, donc cela reste simple (dans le bon sens du terme), efficace et productif. Aujourd’hui avec l’évolution des pratiques des internautes, et plus globalement des gens (voir des mobilonautes ou des iphonautes)  il parait évident que c’est le genre d’outil à déployer : communauté d’utilisateurs d’un logiciel, d’un produit, événementiel : par exemple un festival de musique, ou la convention des maraichers, ou l’université d’été du xxx (mettez le parti qui vous embauche)  : 3 mois avant la plate-forme est disponible, on chat, on blog avec les intervenants, avec les organisateurs, etc. durant l’événement c’est un vecteur en temps réel de l’actualité, a posteriori, c’est un outil de rétrospective (fichiers liés, blogs,images, etc.).

Bref, pas mal de projets assez excitants autour en perspective, j’espère du moins. Si vous souhaitez tester un peu la plate-forme vous pouvez aller chez Elgg.org ou me demander de vous créer un compte pour elgg.areyouagile.com (en me contactant pablo point pernot arboase gmail point com). C’est la plate-forme de test dont je vous parlais. Attention actuellement vu de l’extérieur elle paraît très creuse car nous avons ajouté un pluggin (walledgarden) qui interdit l’accès du public aux infos.

Non, désolé, mais cela ressemble fort à un post inutile (que les gens sensés s’arrêtent ici svp)*. Je ne cesse d’utiliser et de ne pas utiliser Eclipse. Je tergiverse devant l’éternelle question ultime du développeur dont la vie se résume à quelques bits : mais bon sang mais bien sûr quel éditeur (de code) vais-je donc utiliser ? Dans l’opensource (comme on dit “chez les restaurateur”) l’empreinte mémoire, c’est à dire la place prise en mémoire par un processus, c’est très important. On regarde de haut un outil gourmand. Et bon sang Eclipse, et Java plus généralement, sont de sacrés consommateurs de mémoire. D’où ma résistance (souvent enfoncée) à Eclipse (faut-il rappeler que je ne développe que très rarement en Java, mais surtout en PHP, voire en Python**). Cette “lourdeur mémoire” est à mon avis un des éléments fondateurs de ce désamour qui existe depuis longtemps entre l’Opensource et Java. Mais bon, Eclipse a tout pour séduire : références croisées d’un simple clique, découpage des objets (outline), lucène, tout un tas de plugins puissants et j’en passe, cerise sur le gâteau avec XDebug embarqué le tatonnement pas à pas dans le code est un délice. Mais je m’égare, ma machine râme, pédale, crachote, je fais un top (* commande unix/linux qui indique les processus en cours et leurs consommations CPU et mémoire), et je m’étouffe ! P***n java, p****n Eclipse. Ni une, ni deux, je bascule sur gedit (avec ctags). Là c’est léger, c’est rapide. Et puis j’erre dans le code, le teint pâle, le regard morne, où sont donc passés toutes ces fonctionnalités pratiques et efficaces, en un mot productives… Allez essayons Eclipse, l’éternel recommencement***.

MySQL

Où en est MySQL ? en plein paradoxe a priori. D’abord les choses qui fâchent : La société est rachetée voilà à peu près 1 an et demi par SUN. Manifestement elle reste KO debout. On ne connait ni la roadmap qu’envisage Sun, ni si ils vont garder le modèle économique de la base de données opensource la plus répandue au monde. En décidant un silence radio de 6 mois suivant le rachat Sun n’arrange rien. Et ça bouge, en interne, certaines grosses pointures quittent le navire. Pas mal de choses assez excitantes semblent oubliées ou dans une impasse : par exemple Google devait intervenir sur une partie du code de MySQL (des plugins de recherches et d’analyses syntaxiques probablement), disparu, oublié. Heureusement rassurent certains, Sun est une boite qui va comprendre MySQL, et ce n’est pas l’un des gros comme Oracle ou Microsoft ou IBM. A ce sujet -bien embarrassé d’avoir laissé filer InnoDB chez l’ennemi (racheté par Oracle il ya quelques années)- MySQL s’est lancé dans la réalisation d’un moteur transactionnel maison : Falcon. Démarrage poussif de ce dernier qui reste encore en Alpha et dont les progrès paraissent trop lents pour rassurer. On se demande même si il n’est pas gelé. Compétition en interne, on sent bien que les ingénieurs de Sun ont décidés de se la jouer “pro” contre les savants fous créatifs de la communauté (si je caricature). Ca remue je vous dis. Monty Widenius se lance dans Maria (un moteur de stockage myisam évolué), en sent bien qu’il est exclu, il ne tarde pas à quitter MySQL, et fonde récemment avec les excellentissimes Percona l’Open Database Alliance. Et patatras, voilà 6 mois, Oracle rachète Sun… Et c’est reparti pour un tour : pas de visibilité, pas de plan, l’inconnu.

Drizzle

Et pourtant beaucoup de bonnes choses : malgré un silence insistant de 6 mois les ingénieurs de chez Sun sortent soudain une version 5.4 de MySQL qui, si l’on en croit les benchmarks, pulvérisent les performances de ses prédécesseurs. On commence aussi à comprendre la position de Sun concernant le marché : ils offrent des solutions packagés/optimisés hardware/serveur de données. Et puis Oracle, ni Sun, n’osent bouger : le moteur Maria est déjà devenu un projet opensource à part, Percona offre des releases de MySQL patchées et propose aujourd’hui son propre moteur stockage et son propre outil de backup basés sur InnoDB. Drizzle (là aussi des anciens de MySQL) apparaît (comme très prometteur). Bref au moindre mouvement la communauté risque de faire un fork, si ce n’est déjà le cas.

Enfin autour de ma petite fenêtre je vois bien que les projets opensource n’ont jamais eu autant de succès, je vois bien que MySQL pénètre chez des clients qui ne juraient jusqu’à présent que par Oracle ou DB2.

Typo3 possède un langage de script propriétaire (le typoscript), qu’il soit bon ou mauvais peu importe, mais il est très long à prendre en main. Si donc une nouvelle équipe est amenée à intervenir sur un projet Typo3, la charge liée à sa montée en compétence est plus lourde que celle du PHP standard de eZPublish. Trouver un développeur est aussi moins simple que de trouver un développeur PHP. Problème de productivité donc. Le deuxième point est aussi lié à typoscript, on doit le modifier dans l’interface web du backoffice. Ceci interdit l’utilisation d’un gestionnaire de source classique type Git ou Subversion. C’est donc très dommageable, le script ne peut être modifié que par une seule personne à la fois. Problème de productivité encore.

Ces deux défauts ne sont pas anodins. Ils handicapent fortement le TCO (le fameux coût de revient global) d’une solution comme Typo3. eZPublish quand à lui n’utilise que des standards : PHP. De fait il est bien plus ouvert même si Typo3 est la solution 100% communautaire.