Welcome Backdrop! and the road not taken

Back in 2008, when Drupal 6 was released and version 7 was only a faint glow on the horizon, the Drupal project stood at a crossroads with multiple possible futures. One of those futures was the one that's unfolded: the path to what's emerging in Drupal 8.

This is a story of pursuing maximum growth and enterprise clients. Its key players include Acquia, the multifaceted enterprise founded by Drupal lead Dries Buytaert, and other enterprise level Drupal-focused companies. In these circles, the inherent advantages of growth, professionalization, and market maturity seem self-evident. In this future, Drupal core development is increasingly carried out in association with or directly within corporations. If some users or contributors are left behind, the accepted wisdom says, that loss is easily compensated for by growth statistics and new market offerings. Contractor fees and investor profits keep rising along with demand. What's not to like? Progress isn't for everyone, is it? "I really think we can say we've built the best CMS for enterprise systems," the project lead can conclude with satisfaction.

But what if we'd taken a different path? What if profitability and expanding market share and wooing enterprise clients weren't the driving aims? What if, instead, we'd focused on stability, usability, and accessibliity for small and medium sized organizations--the ones that were the core of the Drupal community up to Drupal 6? What would Drupal look like today?

Thanks to Jen Lampton and Nate Haug, we may just get to find out. Their Backdrop fork of Drupal aims to chart the road not taken.

Personally, I haven't felt this excited about the Drupal community in a long time.

Not surprisingly, response to Backdrop has included the familiar claims that greet any radical departure: that its proponents are stuck in the past, afraid of progress, shortsighted, disruptive, and so on.

I'm hopeful we can soon move past these reactive responses and recognize Backdrop for what it is: a positive addition to the open source world. A sister open source project built on the same base but answering a distinct need. A fresh approach with shared roots.

I'm far from saying goodbye to Drupal. For now at least I plan to keep working and contributing in the Drupal space for some time to come. But I'm also planning to dig into Backdrop. Why not? No one knows yet where it's going. But if together we can take it somewhere, I could happily work in both Backdrop and Drupal. Hey, it's much more attractive than having to learn Joomla or Wordpress!

Backdrop reminds us in the most direct way possible that, whoever may claim the trademark or exert founder's rights, no one person or company "owns" Drupal. It's all of ours. And diversity is a strength. When we look at the Drupal principles (disclosure: I wrote the original version myself), doesn't the Backdrop project ring at least as true as Drupal 8 does?

Yes, Jen and Nate and the rest of us who pitch in will take the code in a different direction from where Drupal goes in the future. But is that so different from the ways that Drupal itself has diverged radically from its own past?

They say you can't go back. But in some cases, maybe you can.

Feed: 

Comments

Nicely done

Thanks for posting, Nedjo. I've adopted a "wait and see" attitude toward Backdrop; it hadn't really differentiated itself yet in my mind. Your post inspires me to look at it more closely to see what I might be missing -- and what direction it's likely to take. See you there!

Is enterprise a black and white thing?

Great post Nedjo! I disagree on several points though. I don't think enterprise friendliness can be painted as a black and white thing. Linux is very enterprise friendly (used mostly on servers) yet has great desktop and mobile OS distributions. Drupal continues to have the ambition to be a similarly all-encompassing solution for all web needs, like it ever was. Drupal 7 seen the introduction of overlay, a separate admin theme, better semantic markup, etc. Drupal 8 will include a WYSIWYG editor, better image handling, mobile tools, responsive themes (and may remove the overlay :), etc. I think these are useful improvements regardless of target market. A restaurant wants their website on mobile, and want to have an easy editing experience just as much as a big enterprise.

In terms of what became abstract or complex in Drupal, more things became entities, views got into core, the output pipeline became more abstract etc. These actually lead to easier to customise experiences. In Drupal 8 you can now customise the contact form with fields and have different types of contact forms with different sets of fields on them. You can modify the behaviour of the *admin* content listing page though an admin UI because it is just a view with exposed filters and bulk operations. You can change the setup of entity forms for different scenarios on the UI with form modes such as the user registration form and user edit form can be customised differently. It is true that abstractions are needed so you can apply the same fields to contact forms through files and taxonomy terms. Or that you can customise their forms the same way or even make admin views out of them.

In my closer neighbourhood in the multilingual initiative (which is an area I know you have deep experience with), we worked really hard to make things very simple to do in core (and in many cases even just possible). For example, we improved all translation user interfaces to be accessible and reworked the software translation interface (which mostly only smaller sites use) to be much easier and quicker to use. We made .po imports not time out regardless of the file size, we made language selection first step in the installer and do automated translation downloads so it has never been this easy to do a multilingual site in a matter of clicks. Ironically enough we have not even ventured into what enterprises really want: region/locale support (eg. for content targeting) and 3rd party translation services integration. We left those for contrib as before.

In summary I would caution to paint Drupal 8 as aiming at the enterprise as a single focus. As before, Drupal 8 continues to be aiming to be an all-around solution for different needs. It expands towards the enterprise just as much as it expands to support small sites with highly improved site building tools and flexibility out of the box. I do think we do a poor job highlighting these improvements (and celebrating these successes), and this definitely needs to be improved.

BTW we joined drupal.org on the same week, happy 10th anniversary!

And happy 10th anniversary to you!

And happy 10th anniversary to you Gábor!

Thanks for wading in here. It's an important conversation.

Drupal 8 is doing impressive things for sure, and as you say many of them could benefit small organizations.

But other directions are either neutral or - more to the point - present significant barriers to small organizations.

In the article I cited above, project lead Dries Buytaert said earlier this year:

I think when people think big websites, they usually think Drupal, and when they think small blogs or limited small websites in complexity then they think WordPress. At Acquia we never compete with WordPress. We don't see them ever. I'm sure the smaller Drupal shops run into them, but in the enterprise we never run into WordPress. I think with small sites I'm not willing to give up on them but I think we just need to say we're more about big sites and less about small sites, but then the small sites are still very useful to get people into the community.

I see a lot of signs that his priorities are strongly reflected in Drupal 8. To a degree, it's just another way of saying what I commented a couple of years ago: that as Drupal development is increasingly in line with the enterprise focus of many of its main contributors, other users and priorities may be left behind.

Some of the details I'm specifically concerned about: How well will an average Drupal 8 site run on typical shared hosting? What will the professionalization of Drupal talent mean for low end site development costs? for simple site updates when Drupal 6 is retired?

I don't think the enterprise vs. small site argument is valid

If you're concerned about is will D8 run on shared hosting then the answer is yes providing that your shared host supports PHP5.4.x. I've been running it on shared hosting on a Site5 account in various flavors of alpha and dev and it's snappy. No memory issues, pages load fast, etc...

If you're concerned about the development costs of contractors, I can't see the price changing. Drupal developers are in my experience in the upper price range already and I doubt the marketplace would support higher prices. Developing Enterprise websites will command a higher wage but that was the case with D6/D7 already because the work is different.

I think the Drupal 8 is more enterprisy argument has been misappropriated and was likely more of a statement that Drupal is Enterprise Ready and Wordpress isn't. Unfortunately it seems to be a slogan that's been adopted to make it sound like Drupal 8 is going to be difficult for non-brainiac computer scientists. In reality this couldn't be further from the truth. I've been tinkering with Drupal 8 for a little while using the alpha's and dev's for module development and running it through the paces for site building and here is my takeaway:

1) Site builders are the winners. D8 comes packed with everything you need to build a moderately sophisticated site, complex fields, wysiwyg, views, multilingual, quick-edit, etc... No need to spend any time adding and configuring modules ala D6 or D7. Everything is ready to go.

2) Theming with Twig is similar to PHPTemplate but we'll need some time to get up to speed. The markup looks a lot like Smarty. I don't think it's going to trip us up; it'll just be a bit of a learning curve.

3) Module builders will face the biggest learning curve. Module development in D8 is more rigid but IMHO, if you're developing in any technology, you're used to a shifting landscape anyway and it's one of the reasons you're drawn to that kind of work. The upsides are maintainability, memory management and security.

Andrew

 

Great to hear your experience

And I'll have to have a look at Site5. My experience is, at least for back end tasks, "snappy" is a rare description for shared hosting of Drupal 7, let alone 8.

It's more that the jury's out

It's not that Drupal 8 is out for smaller organizations. Rather - given the focus on enterprise requirements in Drupal 8 development - the jury's a bit out at this point. The Backdrop initiative provides a promising alternative. And the focus and discussion Backdrop has sparked could help spur improvements in Drupal 8.

But that's my point... It makes no difference.

It isn't that there are Enterprise Requirements, it's that the system will be open to Enterprise Development in ways that earlier versions were not..

For the small site developer it doesn't matter that Drupal 8's API will demand that module developers follow strict OOP and Pattern methods or that it provides better use of resources and is more secure. For site builders who are building small to medium sites, the job just becomes easier. All the go-to modules are already there; it's just a matter of installing and starting to build the site without having to install/configure 10 or 20 modules first.

I think the Alpha 4 is supposed to be released tomorrow (groups.drupal.org/node/342698). I suggest anyone who's nervous about the new version download it when it's out and give it a spin. It is the easiest Drupal yet for site builders.

You'll need to have PHP 5.4.x on your server. For site5 shared hosting that just means that you need to add a line in your .htaccess file (kb.site5.com/php/how-to-change-your-php-version/).