The Future of Drupal maintenance support plans
Over the past month there has been a lot of focus on Drupal maintenance support plans, 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 maintenance support plans. From there we could make Drupal maintenance support plans 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 maintenance support plans 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 maintenance support plans out of Drupal maintenance support plans. 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 maintenance support plans upgrades easy forever, but possible.
Currently most Drupal maintenance support plans sites are still on 7, and here we’re talking about what would be Drupal maintenance support plans 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 maintenance support plans 8 is a new application. The upgrade path from Drupal maintenance support plans 7 to 8 is another factor.” Although another reason is also why would a company spend the tens of thousands upgrading to Drupal maintenance support plans 8? It looks at works (from a users point of view) the same as Drupal maintenance support plans 7. Drupal maintenance support plans 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 maintenance support plans 7 with contrib modules. Will Drupal maintenance support plans 8 be the version to skip? go straight from 7 to 9?
As Drupal maintenance support plans 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 maintenance support plans 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 maintenance support plans 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 Drupal maintenance support plansly, that’d be awesome!
timmillwood
Fri, 21/04/2020 – 17:22
Tags
drupal-planet
drupal 8
Source: New feed
