18 Mai 2017

L'avenir de Drupal - Part 3 sur 3 - La concurrence est rude

Commentaires

Troisième partie des réflexions de @lcoullet sur l'avenir de Drupal : La concurrence est rude...
Mais elle n'exclut ni la créativité, ni le dynamisme !

Fin de série de réactions à la suite du post de Dave Hall intitulé "Drupal, we need to talk" (19/04/2017)... La concurrence est rude :)

Partie 3/3 : La concurrence est rude

I have heard so many excuses for why Drupal 8 adoption is so slow. After a year I think it is safe to say the community is in denial. Drupal 8 won't be as popular as D7.Why isn't this being talked about publicly? Is it because there is a commercial interest in perpetuating the myth ? Are the businesses built on offering Drupal services worried about scaring away customers ? Adobe, Sitecore and others would point to such blog posts to attack Drupal. Sure, admitting we have a problem could cause some short term pain. But if we don't have the conversation we will go the way of Joomla; an irrelevant product that continues its slow decline.

Traduction : J'ai entendu beaucoup d'excuses sur les raisons de la lente adoption de Drupal 8. Une année après (sa sortie), je pense que l'on peut s'autoriser à dire que la communauté est en plein déni. Drupal 8 ne sera pas aussi populaire que Drupal 7. Pourquoi personne n'en parle publiquement ? Est-ce parce qu'il y a des intérêts commerciaux en jeu pour perpétuer le mythe ? Est-ce que les sociétés qui vivent de la vente de services autour de Drupal ont peur d'effrayer leurs clients ? Adobe, Sitecore et les autres ne manqueraient pas de s'appuyer sur nos échanges pour attaquer Drupal. Oui, admettre le problème serait vraisemblablement une source d'ennuis à court terme. Mais si nous n'en discutons pas, nous finirons comme Joomla, un produit inadapté qui continue de décliner.

Aïe, aïe, aïe. C'est vrai que c'est difficile à entendre, mais ces critiques ne sont pas infondées. Et être comparés à Joomla, ça ne fait plaisir à personne…

Il n'y a qu'à voir la plupart des gros hébergeurs qui se sont spécialisés Drupal. Mais ils pourraient tout aussi bien héberger son remplaçant, ne nous faisons pas trop de soucis pour eux.

Quant à Adobe et consorts, ce sont de gros marchés. Sans être devin je pense que l'open-source n'en a pas fini de les tourmenter, Drupal ou un autre.

Chez bluedrop.fr nous aimons bien les communautés mais nous n'aimons pas trop LA communauté et ses fétiches du moment. Drupal tirera sans doute sa révérence un jour, on ne se laissera pas mourir pour autant. Néanmoins, il y a de bonnes idées et il faut qu'elles survivent au travers ou au-delà de notre CMS préféré.

Le danger pourrait aussi venir d'autres acteurs. Je pense avant tout à toutes sortes de solutions en SaaS (faut pas rêver hein), qui se proposent de fournir un back-office à la demande couplé à une solution d'hébergement pour un front-office statique de votre choix.

La liste est loin d'être exhaustive.

Les 3 premiers fournissent un entrepôt dans lequel stocker vos contenus ainsi qu'une gestion des utilisateurs (droits, authentification, etc.). Tout cela est accessible via une API qui fournira de jolis JSON à consommer avec votre framework JS favori.

CDN, Https, backups, tout cela est déjà en place. Pas de serveurs à administrer et potentiellement moins de failles de sécurité (enfin jusqu'ici)... Sans compter les intégrations avec des services tiers (e-mailing, e-commerce, moteurs de recherche) qui ne sont qu'à un click de leurs déploiements.

Certes on est loin des raffinements des modules Views, de CCK, des possibilités d'Organic Groups et autres. Mais est-ce que Drupal dormira sur ses 2 oreilles encore longtemps ?

Prismic.io offre déjà un système similaire à notre interface de création de types de contenus favoris. Il y a toujours le soucis du référencement avec ces pages qui ne sont plus que de grands espaces vides remplis dynamiquement par du JS. Là encore je ne me suis pas assez penché sur ce problème, mais je sais qu'il existe des solutions alternatives (server side rendering notamment) que la plupart de ces solutions proposent déjà.

Le dernier de la liste (Netlify) ne joue pas dans la même catégorie. Il s'agit d'un système de déploiement de sites statiques. Venez avec votre Jekyll, votre Hugo, etc. dont vous pousserez le code source sur leur dépôt Git. A chaque nouveau commit, Netlify se chargera de générer le contenu HTML et de l'héberger. Idéal pour un site vitrine par exemple. Certes ce n'est pas tous les clients qui iront écrire un article en markdown avant de faire lancer un terminal pour commiter. Sauf qu'ils ont sortis récemment une solution à base de REACTJS qui permet d'ajouter une fonction d'édition en ligne à tout cela et open-source par dessus le marché (si vous vous sentez de recréer un système de déploiement identique).

Les marges se réduisent

Toutes considérations qualifiées de libristes mises à part :

  • Systèmes fermés ;
  • Propriété in fine des données et inter-opérabilité ;
  • Ubérisation des agences et des freelances qui deviendront au final un service de plus / au service de ses silos ;
  • Pérennité de ses solutions qui se font entre elles une concurrence acharnée.

Si nous nous mettons brièvement à la place d'un de nos clients, le choix n'est pas si difficile à faire.

Certes il faut payer mensuellement pour pouvoir accéder à ces services. Mais ils se substituent pour la plupart à une solution classique d'hébergement. C'est donc plus un transfert qu'un cout supplémentaire en réalité.

Pour moins de 10 euros par mois, ces solutions couvrent les besoins d'un site moyen. Pour le même prix, ces clients pouvaient disposer d'une machine virtuelle dédiée, mais sans intolérance, sans backup avec la charge des mises à jours. Pour les petites agences et les freelances c'est également une solution de plus.

Parallèlement à cela, le Javascript est devenu une espèce de Lingua Franca à même de discuter avec ses APIs, quelle que soient les technologies utilisées en Back-Office. C'est le langage du front-end par excellence. Pour le meilleur et pour le pire.

Back to the roots

I don't think we will ever see Drupal become a collection of microservices, but I do think we need to become more modular. It is time for Drupal to pivot. I think we need to cut features and decouple the components. I think it is time for us to get back to our roots, but modernise at the same time.

Traduction : Je ne pense pas que nous verrons Drupal se transformer un jour en une collection de microservices, mais je pense que nous avons besoin qu'il devienne plus modulaire. Il est temps pour Drupal de changer de cap. Je pense que nous avons besoin de réduire certaines fonctionnalités et de découpler ses composants. Il est temps pour nous de retrouver nos racines tout en nous modernisant.

C'est beau. Je suis bien d'accord.

Sans aller jusqu'au small core j'aimerai quelque chose qui soit un peu dans la même approche de Silverstripe où la partie CMS est un module du Framework plus général (ce n'est pas la même chose, mais ils permettent de choisir).

On pourrait imaginer Drupal 9 qui ne soit qu'un back-office avec une API/REST agnostique en sortie et une extension CMS qui permette de faire à l'ancienne si on en a besoin mais avec une stricte séparation. Cela serait vraiment bien.

Pouvoir utiliser tout la puissance de CCK et Views pour décrire son API sans une ligne de code. Voilà la killer app.

Sauf erreur de ma part, les modules Services et REST de Drupal 8 nécessitent encore d'écrire une configuration avant de bénéficier du reste.

De même WhaterwheelJS d'Acquia préfigure cette bibliothèque JS que tout le monde pourrait utiliser pour interagir avec Drupal.

La solution n'est pas si loin que ça, mais ça mériterait une clarification et une orientation générale qui distingue bien les contributions back-end (modules) de ceux du front-end.

Enfin j'aimerais vous parler d'une solution libre de type Prismic.io développée par Mozilla et qui peut s'auto-héberger. C'est en Python et je ne suis pas assez calé sur cette techno pour avoir pu prendre le temps de l'installer et de la tester, mais ça a l'air bien cool. Reste à voir si cela représente un intérêt commercial pour nous. Peut-être une bonne chose pour les petits sites, une manière de les gérer globalement (évolutions, améliorations) et d'être libres sur le front. C'est Kinto.

Drupal has always been a content management system. It does not need to be a content delivery system. This goes beyond "Decoupled (Headless) Drupal". Drupal should become a "content hub" with pluggable workflows for creating and managing that content.

Traduction : Drupal a toujours été un un CMS. Il n'a pas besoin de devenir un système de diffusion de contenu. Cela va au delà d'un Drupal découplé (décapité). Drupal devrait devenir un hub pour le contenu, avec la possibilité de choisir plusieurs manières de créer et de gérer ce contenu.

Peut-être que Drupal devrait lâcher l'affaire sur le front et se concentrer sur son back-office ?

We should adopt the unix approach, do one thing and do it well. This approach would allow Drupal to be "just another service" that compliments the application.

Traduction : Nous devrions adopter une approche UNIX, faire une seule chose et la faire bien. Cette approche permettrait à Drupal d'être juste un autre service qui complèterait l'application.

Oui tout le monde devrait utiliser une approche UNIX. Nous aimerions également aller plus loin dans les recommandations de type 12 factors apps aussi.

@lcoullet

A suivre...