The Future of Drupal
The Future of Drupal
Over the past month there has been a lot of focus on Drupal, the community. More recently it seems people are back to thinking about the software. Dave Hall and David Hernandez both posted eye opening posts with thoughts and ideas of what needs doing and how we can more forward.
A one line summary of those posts would be "We should slim down core, make it more modular, and have many distros".
To a degree this makes sense, however it could cause divergence. Core is not great at all following the same pattern, but contrib is even worse. As part of the Workflow Initiative specifically there is a lot of work going on to try and get the Entity API aligned, get many more entity types revisionable and publishable, using common base classes, traits, and interfaces. If we maintained Node, Block Content, Taxonomy, Comment, etc all as separate projects then there's a chance less of this would happen. Also by doing this we are laying out foundations and setting examples to be followed.
One solution to this may be to follow Symfony (yet again), they have a monolithic project but then split this up into the various components, which are "read only" repos. It's be pretty awesome if we could do this with Drupal. From there we could make Drupal downloadable without many of the core modules. People with the right skills can create a composer.json file to pull in exactly what parts of Drupal are needed, others could use a form on d.o to select which parts are wanted, which downloads a compiled zip.
What would be more awesome is if we could abstract more of Drupal out of Drupal. Imagine if the Entity API was a PHP generic library. Imagine if you could create a Laravel or Symfony app with Nodes. This would be really tricky, especially since Dries announced the plans to make Drupal upgrades easy forever, but possible.
Currently most Drupal sites are still on 7, and here we're talking about what would be Drupal 9? Maybe we need to take step back and look at why sites aren't being upgraded. Dave mentions "A factor in this slow uptake is that from a developer's perspective, Drupal 8 is a new application. The upgrade path from Drupal 7 to 8 is another factor." Although another reason is also why would a company spend the tens of thousands upgrading to Drupal 8? It looks at works (from a users point of view) the same as Drupal 7. Drupal is a CMS, a Content Management System, and the management of content is more or less the same. Yes, with initiatives like Workflow and Media this is changing, but even then similar functionality can be achieved in Drupal 7 with contrib modules. Will Drupal 8 be the version to skip? go straight from 7 to 9?
As Drupal is now pretty firmly an enterprise platform we need to look at this from a marketing point of view. What is going to sell Drupal 9? Why are people going to upgrade? What do they really want? Is a slimmed down core and more modular application really the selling feature that's wanted?
Drupal is a CMS, quoting Dave again "do one thing and do it well". We need to focus on making the authoring experience awesome, and the workflows that go along with it awesome too. This should all be done in a consolidated way to make managing Node content, Block content, etc just as intuitive as each other. If during this process we can also make things more modular, and less Drupally, that'd be awesome!
timmillwood
Fri, 21/04/2017 - 17:22
Tags
Comment
Submitted by Daniel Wehner (not verified) on Sat, 22/04/2017 - 21:46
When we do these kind of refactoring we should define a goal, and not just do it for the sake of it.
One possible goal could be: I want to be able to use entity API + routing and that's it, aka. decoupled Drupal.
Another usecase could be: I want to be able to use the config system inside a Symfony application.
When we agreed on those goals, we can figure out what we want to do, but just doing things for the sake of it is a bit weird.
Submitted by Thom (not verified) on Sun, 23/04/2017 - 04:53
In reply to When we do these kind of… by Daniel Wehner (not verified)
The primary goal should be to make core development more agile which will hopefully allow for faster innovation.
At the moment core development is difficult and the barrier to entry too high.
This also directly relates to community tooling, I completely understand why the project would like to retain control but this concept was more relevant ~10yrs ago when there weren't any well defined standards. Not only is it a support and maintenance burden but it's difficult to introduce new developers and keep aligned with other well established industry standards.
From a developers point of view a good Drupal profile is nice but a good Github profile is more valuable as it contains information across many other OSS projects.
Microsoft have recently made the move -- https://blogs.msdn.microsoft.com/bharry/2017/03/31/shutting-down-codepl…
Why can't we go where the developers are?
"do one thing and do it well"
Submitted by Daniel Wehner (not verified) on Sat, 22/04/2017 - 21:47
One random thing we could do is:
* Provide composer.json files for core/lib/Drupal/Core/*
* Define dependencies to other bits of core/lib/Drupal/Core/*
Submitted by just-passin-thru (not verified) on Mon, 24/04/2017 - 15:27
What would be more awesome is if we could abstract more of Drupal out of Drupal"
uh, but then I'll just go use symfony or laravel directly and cut out the middle man altogether, lol.
Seriously though, if you do that, there is no reason to continue to use Drupal at all.
All these half-baked supposed 'get off island' incomplete integrations only result in inconsistent and worse, hidden, variations of drupalisms. The composer install debacle is but one example.
One the main points Dave Hall made was that Drupal seems to have peaked with D7 and is slowing down considerably with D8. Can you really still discount the shift from every day site builders to enterprise developers at this point?
As I write this I'm stumped that people still don't get what made Drupal so wildly successful for a time. It was PRECISELY because non professional developers could build such complex sites without having to delve into the black hole that is complex oo development. Including having to obtain and learn to use a professional IDE just to figure out what is going on.
yes, occasionally, site builders would have to use some 'old fashioned' procedural hook code to alter something, but in general, that's still accessible to site builders. Hecks, there's tons of copy and paste recipes out there for this or that. Some of those folks even advanced enough to create and maintain their own modules on drupal.org.
By setting the bar so high for entry, we lose this valuable population of enthusiastic users and potential future developers.
And they have NOT be replaced with the clamoring crowds of symfony and php devs or twig themers that were promised would come if we only catered to them.
So, the net results is less. Less devs. Less enthusiasm. Less site builders.
not really surprising. :-(
Add new comment