[Suggestion] Constats sur les concurrents de Joomla!

[garstud]

Ce fil a été ouvert afin d'éviter les débats "hors contexte" concernant nos concurrents qui pourrait parasiter les autres posts du forum.
Il se veut informatif sur ce qui se passe chez nos chers voisins (Pas de dénigrements , merci).

Règle d'utilisation de ce fil:
merci de rester objectif, informatif (plutot que vindicatif), courtois et de respecter les règles du forum.
Tout post ne correspondant pas a la charte du forum ou ne représentant que du dénigrement sera supprimé !

[garstud]

Re : Constats sur les concurrents de Joomla!

J'ouvre ce fil avec la reprise d'une citation de ygirod qui nous révèle l'existence d'un article retracant les déboires de Drupal avec sa version 7.

Je suis plutôt d'accord, dans l'ensemble, avec Stylefr. Sauf pour se tourner vers Drupal... ;-)

Je ne connais pas assez les différentes versions de Drupal pour dire si c'est objectif, ... mais a 1ere vue, le bloggueur a l'air de maitriser le domaine

[senghor]

Re : Constats sur les concurrents de Joomla!

Il est intéressant que ce qui se passe pour Drupal, ne se réalise pas pour Joomla.
Avec la multiplication des versions pour Joomla, les utilisateurs auront besoin de bien réfléchir avant de faire quelque chose.

J'ai entendu ce matin qu'un responsable IT de l'université de Lucerne, aller basculer tout leurs sites de Joomla vers Wordpress et disait que Joomla se dirigeait vers une Dead End.

Ce n'est qu'un témoignage et pas mon point de vue.

[zepelin57]

Re : Constats sur les concurrents de Joomla!

Pour reprendre le post de ygirod il est bon aussi de lire cet article du même site sur Joomla 1.7.
Je côtoie beaucoup la communauté allemande et je dois dire que beaucoup de pros ont l'intention de tourner la page Joomla. Une petite enquête/sondage avait été mise en place, avant d'être retiré tant cela virait au cauchemar.

Nous travaillons avec 2 systèmes: EZ-Publish, Joomla. Mais depuis peu nous essayons d'autres solutions comme Contao, le léger Website Baker et le prometteur Kryn.

Alors tourner la page Joomla ? J'en parle avec mon équipe bien sûr, mais cela n'est pas encore d'actualité. Nul doute que le premier semestre 2012 sera un tournant, comme l'avait été en son temps la séparation avec PhpNuke pour le remplacer par Miro/Mambot.

La fin de Drupal ? Je n'y crois pas, pas plus que celle de Joomla, par contre ces 2 poids-lourds vont laisser des plumes au profit d'autres CMS.

[kursus]

Re : Constats sur les concurrents de Joomla!

Pour moi la nouvelle gestion des versions est un erreur. Qui va avoir envie de monter un site professionnel avec Joomla en sachant qu'au bout de un an et demi - au mieux - il faudra passer par une douloureuse update, que l'expérience a montrée coûteuse en temps et en ressources ?

Sur un site effectivement ce n'est pas trop grave, mais pour 10, 20 ou 50 on peut commencer à se poser des questions.

La pérennité est un point majeur. Qui a envie de perdre une journée de travail à updater, adapter, chercher des remplaçants aux extensions cassées ? Ne pas séparer les updates de sécurité et de fonctionnalités est un grave défaut. Pourtant il est possible de concilier les deux, Debian le montre depuis des années.

C'est - à mon humble avis - un manque de considération d'une partie utilisateurs. Et le pire est qu'il n'y a pas de compensations dans le nouveau système. Les nouvelles fonctionnalités sont certes toujours bonnes à prendre mais ne justifient pas cette perte.

Et surtout je me demande pourquoi la core team ne se focalise pas plus sur les extensions (qui représentent le plus gros point fort de Joomla) pour apporter de nouvelles fonctionnalités, , au lieu de casser les API - et les extensions - à chaque nouvelle version.
Le fait même de prévoir à l'avance de les casser n'a aucun sens. J'y vois comme une forme d'autisme de la part de la core team, et un deni des avantages du CMS au profit d'un mimétisme de la course à la version que l'on retrouve un peu partout dans le monde du libre (lancée par Chrome).

Sur la mailing-list Mozilla on parle carrément de faire disparaître le numéro de version, en prenant pour exemple Facebook qui lui "n'a pas de numéro de version". Je vous laisse juger de la pertinence de cette décision, qui risque de se généraliser à l'avenir.

Clairement pour les utilisateurs occasionnels ça ne va rien changer, par contre Joomla risque de perdre l'appui de nombreux professionels, dont les besoins semblent avoir été écartés lors de la réflexion sur le nouveau système de version.

[cavo789]

Re : Constats sur les concurrents de Joomla!

Sur la mailing-list Mozilla on parle carrément de faire disparaître le numéro de version, en prenant pour exemple Facebook qui lui "n'a pas de numéro de version". Je vous laisse juger de la pertinence de cette décision, qui risque de se généraliser à l'avenir.

Je ne suis pas sûr que la comparaison soit possible : facebook n'existe qu'à un seul endroit; sur le site de facebook. Il n'y a pas lieu pour un utilisateur de se dire "ai-je téléchargé la dernière version?". Dans la situation où tu as une version d'un programme en local, la question du numéro de version prend toute son importance.

[jisse03]

Re : Constats sur les concurrents de Joomla!

Pour moi la nouvelle gestion des versions est un erreur. Qui va avoir envie de monter un site professionnel avec Joomla en sachant qu'au bout de un an et demi - au mieux - il faudra passer par une douloureuse update, que l'expérience a montrée coûteuse en temps et en ressources ?

On a connu ce même genre de discussion et remarques lors du passage du noyau de Linux de la série 1 vers la série 2.0, avec ces mêmes craintes et même un vrai flot de discussions rageuses sur les newsgroups.
Le passage d'un genre de numérotation assez laxiste vers une méthodologie industrielle (et surtout la notion LTS/STS) implique une réorganisation du code qui peut troubler au départ.

La pérennité est un point majeur. Qui a envie de perdre une journée de travail à updater, adapter, chercher des remplaçants aux extensions cassées ?

Pour moi également, la pérennité est un élément majeur. Dans le cadre Joomla!, les extensions bien écrites (Community Builder par exemple) survivent à tout (pour CB de mambo à J!1.0, 1.5, 1.6, 1.7) sans vrai problème.
La problématique se pose le plus souvent pour des extensions écrites sans un respect intégral des API, ça peut fonctionner dans un contexte, mais devenir vraiment problématique à la moindre évolution du noyau.

Nous travaillons avec 2 systèmes: EZ-Publish, Joomla. Mais depuis peu nous essayons d'autres solutions comme Contao, le léger Website Baker et le prometteur Kryn

EZ-Publish également a connu une vraie mutation entre sa version 3 et la 4, avec peut-être même plus de changements qu'entre Joomla! 1.5 et 1.7. Mais dans son cas, la problématique était plus simple, vu la quasi inexistence d'extensions tierces parties.
Les solutions émergentes genre Contao ou Kryn ont certes un avenir, mais seul le futur le dira.

Il me semble que la plus grand eforce de Joomla!, son incroyable collection d'extensions tierces, est également ce qui fait sa faiblesse. Les extensions tierces doivent être maintenues à niveau, évoluer avec la base même d eJoomla!, ce qui n'est pas toujours le cas, pour moultes raisons, dont certaines discutées dans ce sujet http://forum.joomla.fr/showthread.ph...e-d-extinction

Et surtout je me demande pourquoi la core team ne se focalise pas plus sur les extensions (qui représentent le plus gros point fort de Joomla) pour apporter de nouvelles fonctionnalités, , au lieu de casser les API - et les extensions - à chaque nouvelle version.

La core team a pour rôle de développer le noyau de Joomla! et de fournir une API consistante, cohérente et évolutive aux développeurs tiers, ce qui est réalisé via Joomla! Platform.
A mon sens, en tant que développeur, entre 1.5 et 1.7, les API n'ont pas été "cassées" (90% restent identiques), mais ont évolué, et dans le bon sens. Par contre, devenant bien plus contraignantes qu'auparavant, il est vrai que les extensions quelque peu laxistes sur le respect des API se trouvent face à des problèmes, parfois graves, lors de leur portage.

Concernant la disparition du numéro de version, autant pour un site genre Facebook, ça ne pose pas de problème, puisque tu ne dois pas télécharger ou installer le code de facebook sur ton PC ou ton serveur pour l'utiliser. Par contre, pour une application, le numéro de version permet de savoir ce qui est supporté ou pas, quels en sont les bugs, vers quelle version il faut mettre à jour, etc.

Nul doute que le premier semestre 2012 sera un tournant, comme l'avait été en son temps la séparation avec PhpNuke pour le remplacer par Miro/Mambot.

On retrouve bien là la bonne vieille filiation, le code originel de Miro/Mambot étant un fork de PhpNuke (tout comme PostNuke et Nukem entre autres) pour refactorer le code spaghetti et le rendre un peu plus conforme aux besoins et évolution des normes de développement (et également plus stable sous PHP 3 à l'époque).

[ced1870]

Re : Constats sur les concurrents de Joomla!

salut à tous
je suis cette discussion avec intérêt, je dois dire que moi aussi je me pose des questions et je rumine, je rage parfois à cause de l'évolution changeante qui demande beaucoup de suivi et de travail. Quant à dire si c'est un bon choix, seul l'avenir le dira....

[kursus]

Re : Constats sur les concurrents de Joomla!

Disclaimer: j'essaye d'exprimer mon humble point de vue, parfois avec ferveur, ce n'est absolument pas pas une critique ferme à l'encontre de joomla, à qui je dois beaucoup. Et désolé pour le pâté !

On a connu ce même genre de discussion et remarques lors du passage du noyau de Linux de la série 1 vers la série 2.0, avec ces mêmes craintes et même un vrai flot de discussions rageuses sur les newsgroups.
Le passage d'un genre de numérotation assez laxiste vers une méthodologie industrielle (et surtout la notion LTS/STS) implique une réorganisation du code qui peut troubler au départ.

Je ne suis pas contre le fait qu'un logiciel doive évoluer, et je suis d'accord avec toi sur le fait que les extensions bien codées nécessitent peu de modifications pour suivre la cadence, et que ça ne fait pas de mal de faire un grand ménage dans la jungle des extensions.

Néanmoins la comparaison est peu adaptée : lors du passage à linux 2, Internet était très loin d'être répandu en France et updater son système via le net était inenvisageable. Le nombre de commits est infiniment plus grand pour un noyau que pour un cms.

La question qui reste en suspend pour moi est "pourquoi ne pas continuer les updates de sécurité pour 1.5 ?"
Pas indéfiniment bien sûr mais enfin un peu de marge n'aurait fait de mal à personne. On a le choix à l'heure actuelle entre un site en 1.5 qui sera dépassé et vulnérable avant même sa création, ou un site en 1.7 qui contient encore quelques jolis bugs et qui prive joomla de nombre de ses extensions (le principal attrait du CMS), et même si le temps va arranger les choses, je me demande si il était bien utile de mettre les utilisateurs dans une telle situation.

Ce n'est pas comme si publier un correctif de sécurité tous les mois ou deux demandait des ressources énormes.

En ce qui concerne la "méthodologie industrielle", c'est dommage de voir qu'un projet libre s'impose cette contrainte. C'est justement l'un des énormes avantages du libre que de pouvoir ne pas s'imposer de deadline.
Un objectif de date d'accord, mais une deadline c'est le monde à l'envers! Que se passe-t-il si un projet est en retard d'un mois ? Dans un boîte, on sort quand même le produit buggé puis on publie un correctif, car on n'a pas le choix (logistique, marketing, partenariats commerciaux, etc. qui ne peuvent pas accepter de report) . Dans un projet libre ça n'a aucun sens, pourquoi ne pas attendre plus longtemps sachant que rien ne le justifie ? (cf la différence de qualité entre debian qui sort quand elle est prête et ubuntu qui sort coûte que coûte)

La décision du projet Joomla semble avoir été prise à la va-vite. Deux ans pour la version 1.5, puis quelques semaines pour la 1.6, puis sortie d'un planning de versions qui change encore la donne, etc. Je ne dénigre pas, c'est très bien de prendre des décisions pour l'avenir, mais je m'interroge légitimement.

Je maintiens que la course stupide à la version lancée par Chrome a fait des émules sur la petite planète du web. Chez mozilla, après avoir copié sans réfléchir et provoqué le mécontentement des utilisateurs, la question de la disparition du numéro de version (ou plus exactement sa relégation dans le placard des fichiers de conf) a été soulevée (voir commentaire #27 pour la comparaison avec facebook, avec laquelle je ne suis bien sûr pas d'accord) et va être appliquée.

On n'aura plus dans la boîte d'aide "Firefox 6.0" mais "Firefox a été mis à jour il y a deux heures".
En gros une version est déclarée obsolète simplement parce qu'on a décidé qu'elle l'était (gmail commence à sabrer les anciennes versions de firefox, et on ne peut pas leur en vouloir tellement ça devient compliqué de gérer 36 versions pour eux) et non pas parce qu'elle l'est en termes de fonctionnalités ou de sécurité.

C'est un peu le même raisonnement que je retrouve dans la nouvelle politique joomla. "Faîtes une mise à jour parce qu'on a décidé que votre version devait être remplacée, peut importe si ça pète vos extensions, et si vous ne le faites pas attention à la catastrophe".
C'est pour moi un vrai manque de considération, voire une légère prise d'otage.

Et ce n'est pas comme si la pléthore de nouveauté justifiait cette migration : entre J1.5 et 1.7, je ne vois que les catégories emboîtables et les ACL. Les catégories sont un excellent apport, par contre pour moi rien ne justifiait l'ajout des ACL dans le core, à la rigueur elles auraient pu être proposées en extension, car la majorité des utilisateurs ne l'utiliseront certainement pas au maximum, voire ne l'utiliseront pas du tout.
Quitte à rajouter une fonction lourde qui justifie un changement de version (et d'API), ça aurait été bien plus pertinent d'implémenter un CCK.

C'est là-dessus que je tique : le rôle de la core team ne serait-il pas de préparer le core pour que l'ajout d'une fonctionnalité comme les ACL soit facilité en extension, plutôt que de tout remuer pour l'intégrer en natif ?
C'est comme un déni de la plus grande force de ce CMS, les extensions.

Bref pour finir parce que je crois que plus personne ne me lis, je pense justement qu'une approche moderne d'un CMS serait de diminuer au maximum les changements de versions, voire viser à les supprimer, plutôt que de les accélérer.

Et encore une fois, je suis dans l'incapacité d'upgrader tous les sites en 1.5 dont je suis responsable, car clairement ça me prendrait un mois à temps plein, sans compter les galères imprévues. Certes les développeurs ne m'avaient rien promis, mais comme d'autres, la situation me donne envie de faire un tour du marché pour voir si certains ont une approche moins rigide.

[ced1870]

Re : Constats sur les concurrents de Joomla!

La décision du projet Joomla semble avoir été prise à la va-vite. Deux ans pour la version 1.5, puis quelques semaines pour la 1.6, puis sortie d'un planning de versions qui change encore la donne, etc. Je ne dénigre pas, c'est très bien de prendre des décisions pour l'avenir, mais je m'interroge légitimement.

pareil, c'est bien de se donner des objectifs, mais je trouve aussi que cette déferlante de versions est troublante pour tout le monde. Je ne dis pas que c'est mal, ni que c'est bien

Bref pour finir parce que je crois que plus personne ne me lis

si moi!

[jisse03]

Re : Constats sur les concurrents de Joomla!

Bref pour finir parce que je crois que plus personne ne me lis

Mais si, on te lit jusqu'au bout, d'autant plus que le rédactionnel est clair et bien rédigé

Ce n'est pas comme si publier un correctif de sécurité tous les mois ou deux demandait des ressources énormes.

Il me semble bien avoir entendu des indiscrétions sur une prochaine 1.5.24...

En ce qui concerne la "méthodologie industrielle", c'est dommage de voir qu'un projet libre s'impose cette contrainte. C'est justement l'un des énormes avantages du libre que de pouvoir ne pas s'imposer de deadline.

Le terme "méthodologie industrielle" n'impose pas de deadline contrairement à une idée reçue, mais une vraie méthodologie de développement, en se donnant, si possible, une date de stabilisation d'un produit. Joomla! n'est pas le seul produit sous licence GPL à se fixer ce type d'objectif, et pour une excellente raison, l'impact hors du milieu geek du CMS, qui est de plus en plus souvent adopté soit en solution intranet, soit comme portail ou site vitrine par des professionnels.

D'où l'introduction de cette distinction entre le LTS (les versions à support long) et STS (cutting edge).

Les produits concurrents de Joomla! sont face aux mêmes impératifs. Ce qui diffère avec Joomla! est l'extrême richesse des extensions tierces, sur lesquelles la core team n'a que peu de pouvoir (sauf à imaginer un système de certification qui se révèlerait certainement très lourd à gérer).

Et ce n'est pas comme si la pléthore de nouveauté justifiait cette migration : entre J1.5 et 1.7, je ne vois que les catégories emboîtables et les ACL. Les catégories sont un excellent apport, par contre pour moi rien ne justifiait l'ajout des ACL dans le core, à la rigueur elles auraient pu être proposées en extension, car la majorité des utilisateurs ne l'utiliseront certainement pas au maximum, voire ne l'utiliseront pas du tout.

Il y a une nouveauté énorme, bien que non visible de prime abord, le découplage entre le framework (maintenant Joomla! Platform) et le CMS, qui perdent l'imbrication énorme qui interdisait quasiment l'utilisation du framework Joomla! 1.5 pour autre chose qu'un CMS.

Concernant les catégories, la catégorisation récursive n'est vraiment pas un luxe, la rigidité sur ce point de Joomla! 1.5 étant connue
Par contre, sur les ACL, je ne peux être d'accord avec toi. Tous les CMS modernes permettent une granularité des accès que seul un système ACL évolué autorise. Et tout framework digne de ce nom intègre également une granularité fine des ACL. La gestion des accès Joomla! 1.5 était une ébauche, et ceux qui ont du galérer avec des hacks pour affiner les accès doivent remercier la core team

Quitte à rajouter une fonction lourde qui justifie un changement de version (et d'API), ça aurait été bien plus pertinent d'implémenter un CCK.

Un CCK est une extension typique d'un CMS et pas une gestion de base d'un Framework. Et puisqu'il s'agit effectivement d'extension lourde, et que diverses philosophies CCK co-existent, sur quels critères objectifs en choisirait-on l'une plutôt qu'une autre ?
Le CCK est bien un élément relavant des extensions qu'il ne faut justement pas caser en tant que core component d'un CMS, sauf si on veut imposer une vision plutôt qu'une autre.

On le voit par exemple avec EZ Publish, l'un des CMS concurrents, dont le genre de CCK natif (une véritable usine à gaz) est utilisé parce qu'il n'y a pas d'alternative, sauf à alourdir encore le mammouth.

la situation me donne envie de faire un tour du marché pour voir si certains ont une approche moins rigide.

Pour pratiquer au jour le jour une collection de CMS et autres applications pour satisfaire mes clients, tout produit arrive à un moment où l'autre de son existence à devoir réaliser un changement majeur dans son code, ses API ou même sa structuration de données.
Il me semble que Joomla!, avec le découplage du framework et du CMS a réalisé la pas de géant permettant d'atteindre la maturité et garantissant ensuite des évolutions plus fluides que les sauts quantiques qu'on a connu jusqu'ici.

Mais une fois de plus, c'est l'avis d'un développeur. Et comme tout développeur, reste la question des extensions codées sans respect des standards, ce qui sera toujours le problème majeur d'un système générant une galaxie entière de produits divers destinés à de multiples usages. Cette richesse fonctionnelle est également la chausse trappe.

[daneel]

Re : Constats sur les concurrents de Joomla!

oui je rejoins sur plusieurs points jisse03 qui illustre très bien cet évolution...

A kursus, on a le choix de le faire les mises à jour ou non... Je connais bien certains qui étaient encore en Joomla 1.0.15 en début d'année 2011

Dans le cas de Wordpress, on desactive les notifications pour faire au cas par cas... Actuellement une mise à jour tous les mois (c'est bien et cela tourne parfois au désastre)

http://www.seomix.fr/wordpress/utilisation/mettre-a-jour-cms/

Pour Drupal, je parle pas des difficultés pour le passage entre 6 et 7 car toutes les modules ne sont pas disponibles mais il y a plus d'activité pour la dernière version (ce qui revient à l'identique entre Joomla 1.5 et 1.7 actuellement)

Version | Modules | Thèmes | Stats d'utilisation*
7.x | 2009 | 179 | 84145
6.x | 5892 | 597 | 330503

Pour les autres, il y a toujours des problèmes entre les versions tellement le nombre de fonctionnalités obligent à revoir le développement des extensions majeures… Je suis bien un pro joomla mais je regarde bien les autres cms et les problématiques sont souvent les mêmes...

Pour les ACL, je dirai que c'était un mal nécessaire. un reproche continuel sur la 1.5 (à chaque fois j'ai entendu le même refrain... mais oui on est limité à quelques niveaux… c'est un gros défaut). C'était pratiquement obligé car une extension aurait amené à devoir installer une nouvelle version à mise à jour de joomla et des plugins pour chaque composant installé… (le cas de GMACCESS est un exemple sur la 1.5 car Greg devait suivre en parallèle chaque mise à jour pour que son composant reste compatible).

Aujourd'hui je sais bien que cela peut représenter un travail sur la migration de 1.5 à 1.7… Que l'on se rassure, on a encore quelques mois avant la fin de la 1.5 (et il y aura une ou deux mises à jour) donc la migration peut se faire en douceur. Je suis en traine de rédiger un tutoriel complet sur le sujet en espérant qu'il vous donnera la conviction que l'évolution va vers le bon sens.

Ce que l'on peut entendre des utilisateurs de la 1.7, c'est... je ne reviendrai plus sur la 1.5 !

[jisse03]

Re : Constats sur les concurrents de Joomla!

Dans le cas de Wordpress, on desactive les notifications pour faire au cas par cas... Actuellement une mise à jour tous les mois (c'est bien et cela tourne parfois au désastre)

http://www.seomix.fr/wordpress/utilisation/mettre-a-jour-cms/

J'ai connu aussi avec certaines extensions WordPress. L'automatisation qui tourne à l'erreur 500 n'est pas si rare que ça

[paimages]

Re : Constats sur les concurrents de Joomla!

Bonjour à tous,
Il y a certaine extension "incontournable" qui ne tourne que sur J1.5. Je pense entre autre à Joomfish.
Du coup, on se retrouve devant le dilemme avec un nouveau projet:
- je construit mon nouveau site sur un système en fin de vie 1.5....
- j'attends, j'attends et j'attends encore que les extensions suivent
C'est vraiment une situation pénible et difficile à expliquer à un client.

Changer de CMS..... Comment changer de CMS pour une petite webagency (3-4 personnes) ou pire pour un indépendant quand on a plusieurs dizaines de sites à maintenir ? Acquérir le même niveau de connaissance sur une autre technologie tout en maintenant un parc important de site est une véritable gageure.

Je reste attentif au marché, mais je me sens tout a fait captif de Joomla! à cause de l'historique de mon entreprise.

Bonne journée
PA

PS: une version beta et un nouveau site web pour JMonitoring va voir le jour sous peu.

[albourg]

Re : Constats sur les concurrents de Joomla!

Le minimum minimorum est de prévoir une compatibilité ascendante!
J'ai un site en joomla 1.5.24! avec un template (gratuit) fourni par la société où j'héberge mon site (cloudaccess.net, lien donné par joomla.org).
Ils n'upgradent pas leurs templates.

=> Si je veux passer au 1.7 je dois réécrire un template, ou en trouver un équivalent, ou revoir le look&feel du site.
J'ai d'autres sites à écrire: c'est une raison suffisante pour choisir un autre cms (drupal ou wordpress, j'hésite encore). Les auteurs de cms doivent comprendre que les utilisateurs n'en ont rien à faire de passer leur temps à faire des maintenances sur un site qui tourne, uniquement parce que la version a changé. Et selon moi, la meilleure solution est que la nouvelle version reprenne l'ancien site et fasse la conversion tout seul comme un grand!

Impossible? Non, Word, Excel, Access ont tiré leur leadership de là (entre autres): la nouvelle version reprend tout ce que l'ancienne fait de manière transparante pour l'utilisateur. Si les auteurs de cms veulent que leur cms soit dans les leaders du marché (qu'il soit libre ou payant), ca doit selon moi commencer par là!