End of series of reactions about the blog post published by Dave Hall named "Drupal, we need to talk"... A Fierce competition.
Part 1: CMS Drupal losing pace?
Part 2: The end of the monolith
Part 3/3: A Fierce competition
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.
Ouch ! It is very hard to hear such criticism, but no, it is not ungrounded as we may think. In comparison with Joomla, everyone seems to find it quite unpleasant…
We can take a quick glance at most of the Drupal-specialized hosts. It is very easy for them to host its substitute, so this is not something that can get us worried.
For their part, Adobe and consorts are big markets. One must not be a psychic to know that they will long be haunted by open-source solutions, whether Drupal or not.
The bluedrop.fr team appreciates communities, but not THE community and its fetishes. Drupal will definitely step down one day, but we will not die for that. There are some pretty good ideas that will have to survive, whether via our favorite CMS or any other solution.
Several other factors could be harmful as well. I think of all the SaaS solutions ( let’s keep it real), that suggest providing a back-office on demand, coupled with a hosting solution for the static front-office of your choice.
- Contentful ;
- Prismic ;
- Firebase (Google) ;
- Netlify.
And the list goes on.
The first three provide a data warehouse to store data and to perform users’ management (rights, authentication, etc.), via an API that provides, in turn, the JSON module with your favorite JS framework.
CDN, Https, backups, have all been set up. There are no servers to manage, and less security breaches (until now)… No need to go over the integration with third-party services (e-mailing, e-commerce, search engines) that are only a click away.
We are far from the refinement of Views or CCK modules, and from the potential of Organic Groups among others. But for how long will Drupal sleep like a dormouse?
Prismic.io has already a system similar to our favorite content-type creation interface. The problem of referencing of the big empty pages dynamically filled with JS remains unsolved. I did not delve into the issue, but I know that there are alternative solutions (such as server side rendering) already provided by several software.
The last of the list (Netlify) falls within a different category, for it is a static site generator. With your Jekyll, your Hugo, etc. you will push the source code on the Git repo. Ideal for e-commerce, for instance. Not all customers will write a markdown article before launching a terminal. However, they have recently launched a REACTJS-based solution, which provides an online, open-source Edit feature (if you ever feel like deploying a second identical copy of the app).
Narrowed margins.
Aside from the free software activists’ considerations:
- Closed systems ;
- In fine data property and interoperability;
- Uberization of Agencies and Freelancers, which will act as an additional service to that of the silos;
- Sustainability of the services that will eventually reach the point of competing one against the other.
If we put ourselves in our customers’ shoes, we will realize that making up our mind is not so hard after all.
We have to pay monthly fees to have access to such services, but we shouldn’t forgo that most of them replace a classical hosting solution. It is then more a transfer than just an additional cost.
With less than 10 euros per month, these solutions cover the expenses of an average site.
For the same price, clients can have a dedicated virtual machine, but without intolerance, without backups, and will have to pay for every update. Small enterprises and freelancers perceive it as an additional solution.
In parallel, Javascript has become a Lingua Franca able to communicate with its APIs, regardless of the technologies used in Back-Office. It is the ideal front-end language, for better and for worse.
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.
This is beautiful. I totally agree.
Without going as far as to opt for small core, I’d rather choose something similar to Silverstripe, where CMS is a module of the more general Framework (they are not similar, which broadens the scope of available choices)
We can imagine that Drupal 9 is only a back-office with an agnostic API/REST and a CMS extension that allows to do things the old-fashioned way if needed, but with a clear distinction between the two, which will do us really good.
To tap into the full potential of CCK and Views to describe its API without using a single code line; would be the killer app.
If I’m not mistaken, Drupal 8 Services and REST modules still require a configuration before we could benefit from the rest.
Acquia’s WhaterwheelJS is prefiguring the JS library that will be accessible to everyone wishing to interact with Drupal.
The solution is within reach, but it deserves a comprehensive clarification and orientation to make a clear distinction between back-end(modules) and front-end contributions.
Finally, I would like to talk about Prismic.io, a free, self-hosted solution developed by Mozilla and integrated in Python. Given that I am not knowledgeable enough about this technology, I did not take the time to install it and test it, but it seems pretty cool. What’s left is to see if, for us, it is a source of commercial interest. Maybe to conduct the comprehensive management of small sites (development, refinement) with a frontend focus, all we need is 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.
Maybe Drupal should give up putting too much effort on the frontend and start focusing on its 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.
Everyone should adopt a UNIX approach. Moreover, it would be very interesting if we could push the recommendations relevant to the 12 factors apps forward.
Part 1: CMS Drupal losing pace?
