Backdrop proves the case for Top Shelf Modules

Less than a month after this, we saw last week the launch of a 60-day $50,000 fundraising campaign for Backdrop, the brain child of "founding forker" quicksketch, Drupal Evangelist at Lullabot (says his drupal.org profile) and D6/7 module developer extraordinaire (says I).

Though a lot has been said already about this D7 fork, we'd like to add an important point. It's one strangely not given any attention on the Backdrop introduction page (the HTML of which, perhaps fittingly, does not look anywhere near that of a standard Drupal site -- but was it made with Backdrop?).

At the time of writing none of the 7 goals listed on that page talk about Backdrop's contributed modules.

Is this to suggest that all's fine and existing D7 modules will continue to work without code changes? But how can that be? How can existing D7 modules work with Backdrop, when things like the "database abstraction layer" and "renderable arrays" are being ripped out of the Backdrop core? Indeed the fund-raising campaign page says this much: "Upgrading from Drupal 7 to Backdrop will be comparable to upgrading to D8".

With that being the case, we guess the expectation is that existing Drupal module maintainers will be keen to promptly port their modules to Backdrop? And happily maintain D6/7/8 and Backdrop versions (on different repositories), presumably for free?
Or to take one concrete example of one module that will need to be ported to Backdrop: Views. Remember how long it took for a stable D7 release of Views to come out after Drupal 7 was released?

Has the contrib aspect to Backdrop been thought through?

Do we have to remind ourselves and the community that any D7, D8 or Backdrop core by itself is NOT a website? That many Drupal or Backdrop websites will feature at least as many contrib modules as they do core modules? And that these need to be maintained?
That any core is nothing without a well-supported ring of contrib modules around it?

So to us, again, as with D8, there is a plan (of sorts) for an "improved" core, but not for an improved contrib space.
Or for the business that rely on contrib...
Or the maintainers that make contrib great… or if not rewarded in some form, not so great...

The contrib port, whether to D8 or to Backdrop, of thousands of D7 modules, won't happen by itself, not rapidly and not with great quality, without organised, coordinated initiatives and some cash.

That's why we support Top Shelf Modules. The TSM guys have realised that it's less about what core you choose, but more about what contrib you have available to you.
And that's exactly what they aim to improve.

A few days ago this was tweeted: (also quoted in Backdrop: Forking Drupal):
"#Backdrop needs to exist to *preserve* the #Drupal community and market."

We wish Backdrop the best of luck and add:
"#topshelfmodules needs to exist to *preserve* #Drupal… and #Backdrop."

File under: 

Combatting technical debt in Drupal 8

Read More »

Comments

Lots of improvements in Drupal 8 core (much like any version before) stem from experiences coming from contrib. For example, Views was brought in and the plugin system was devised based on experiences with prior contrib solutions. Several field modules, transliteration, localization update, etc. came in after contrib experimentation. New core APIs are also influenced by prior contribs. The new field API includes better support for multilingual fields and improves developer experience.

That said, its a new thing either way and contribs need to adapt. http://d8cx.org/ is a dedicated website to help porters and there are ongoing efforts such as https://drupal.org/node/2081777 and https://prague2013.drupal.org/bof/fix-drupal-8s-developer-experience-dx to improve Drupal 8 based on feedback from early porters. Contributed module maintainers are asked to port their modules at this time only if they can cope with ongoing changes and are welcome to provide feedback which is turned into improvements. There have been several improvements to make forms and pages easier to write for example.

I would be the first to admit that there are still a lot of things to do and these efforts may not be well marketed, but its definitely top of mind in the core community to make contrib's life as easy as feasible with Drupal 8's improvements in place.

I see https://drupal.org/node/2081777 was only just published. It's a great initiative. Thanks for mentioning it. Look forward to the DrupalCon Prague session too: https://prague2013.drupal.org/bof/fix-drupal-8s-developer-experience-dx Rik

Thanks guys! I'm really excited about the potential for contrib authors with Backdrop. One of the primary concerns around Backdrop is to end the painful upgrade cycles.

> "Upgrading from Drupal 7 to Backdrop will be comparable to upgrading to D8".

I think it's also important you include quoting the line directly before that one, which is "Porting Drupal 7 modules to Backdrop will be faster and easier than to D8." The part about "upgrading" was meant to mean for end-users, the process will be similar. As in, you can use update.php to move to Backdrop from Drupal 7, as if Backdrop were the next version of Drupal.

I did some math on line number differences between D7 and D8, the result of which is that (currently) between the roughly 30 modules in core that exist in D7 and D8, there's only a 25% overlap. Module authors will be seeing a similar level of changes required to restructure and rewrite their modules for Drupal 8. Backdrop aims to provide a much, much easier conversion for existing modules. Some areas like removing DBTNG though could require effort, but the overall move to Backdrop should be less painful than the move from D6 to D7, considering limiting API changes is a primary goal of the initial release.

(And removing DBTNG is currently being debated, it's not for certain: https://github.com/backdrop/backdrop-issues/issues/61)