[Evangelism] The State of Drupal

[Dylan Jay]

On 23/11/2009, at 4:59 AM, Steve McMahon wrote:

> While at the Non-Profit SW Dev Summit, I had the opportunity to  
> attend a couple of Drupal panels (new to Drupal, and what's new with  
> Drupal). Drupal had their A team at the summit (a couple of core  
> devs and several evangelists) to do the talks. I wanted to pass on a  
> few things on what I observed. Share as appropriate.
>
> 1) Drupal is also having the framework vs product debate. From what  
> I heard, the "framework" side is definitely winning. Many Drupal  
> integrators are actually demanding that some new, friendlier UI in  
> the Drupal 7 preview be rolled back because they feel it undermines  
> their flexibility as integrators. Drupal 7 continues to be a micro- 
> core product that is not really suitable for use out of the box. The  
> Drupal folks emphasize that no inexperienced person

some interesting thoughts by the founder/(leader?/dictator??) of  
Drupal on this on his blog.

http://buytaert.net/8-steps-for-drupal-8

I especially thought the following was relevant for Plone.

"Clearly the work on improving our APIs needs to continue, and  
creating better separation between the framework and the product will  
continue to be one of our goals during the Drupal 8 release cycle.
Over-engineering is a real threat though. When people fall in love  
with framework design, they tend to decouple everything, abstracting  
it up, down, and sideways. Before you know it, you end up with  
abstractions that make Drupal harder to develop for, and that could  
make Drupal a lot slower."

He also brings up the idea of having co-maintainers with two focuses:  
framework and product.  The idea that a CMS has two kinds of  
interfaces, developer (the framework) and user (the product) and both  
are equally important but will often be opposed... I think there's a  
lot of truth in that.
With regard to Plone I'm not sure what our equivalent of a maintainer  
is since our process is different but I'm assuming it would be the  
framework team. Can you have separation of concerns within a single  
committee?


> should think they can integrate Drupal by themselves (for more than  
> a blog), as they need to gain a lot of experience as to which  
> modules really work together.

>
> 3) Drupal is still very complex for end users. I don't think they  
> really differentiate between users

He has some interesting things to say on this.

"The single biggest barrier to the success of Drupal is its ease of  
use. This is repeatedly shown in studies, competitive comparisons and  
blog posts... ...To focus only on the power and flexibility of the  
framework mainly serves to keep the Drupal insiders happy, while the  
market and customer base passes them by to adopt tools that do not  
need their specialized skills because other products solve the  
market's needs out of the box."

Then he goes a lot into how there can only be one CMS left standing  
(very highlander) and how that can be Drupal etc etc. I can start to  
see where these drupal people get their zeal from now :)

Thankfully Plone's UI seems to be in great hands. The simplification  
of the framework side of plone has had some great noises made but IMHO  
we seem to have a great process for adding features and frameworks but  
it's unclear how that process works for simplifying the framework. Do  
we raise PLIPs to get rid of all CMFFormController use within the code  
for instance? Is it within the process to refactor code to remove old  
frameworks within a point release?
We have awesome demos of deco and its easy for all of us further down  
the chain to see where we are headed UI wise, but what would be the  
equivalent of a vision outlining a simplified framework for developing  
with plone?
Limi highlighting 25% less code in plone 4 is pretty cool. Wouldn't it  
be great to see 50% less concepts needed to learn plone in plone5?

>
> 4) Permissions and roles are still pretty much global, and workflow  
> is rudimentary. No ACLs. The organic groups module remedies some of  
> that, but there was skepticism about whether or not it could be  
> ported to 7.

This popped on a twitter search for #plone today.
http://drupal.org/project/secure_permissions
Looks like all the security talk about plone vs drupal must have got  
someone thinking :)


> 7) They are still, out-of-the-box, a great blogging platform, and if  
> you're using Drupal as a "news to the home page site" with a few  
> static pages, it's easy and fast to configure.

Dries talks about Distributions which isn't something we've done much  
with in Plone. Drupal seems to be advertising its out of the box  
intranet distribution on drupal.com and Plone doesn't have one and yet  
Plone is a better match.

The points Dries makes about distributions are also really interesting.

"There is a risk involved with distributions as well, which means that  
we need to approach them the right way. The risk is fragmentation, and  
it is why I feel it is important that distributions build on the  
usability patterns set by Drupal core. "

>
> 8) The party line on Acquia is that what's good for Acquia and Dries  
> is good for Drupal. I saw not a hint of discomfort with that.

I think this is one of the most important points. Maybe it won't last,  
and maybe the community will suffer long term by Acquia making lots of  
money? Maybe Drupal will end up being vendor opensource with all its  
downsides? Who knows.
In the medium term, as an Plone development company, I think Acquia  
gives Drupal an unfair advantage. Just the other day we had a very  
large organisation say they went with a proprietary solution because  
"we can't sue Plone" and decided this before we could even present to  
them or explain that opensource means you can purchase a plone  
solution from an integrator and then sue them if it goes wrong. We  
have liability insurance :)
Acquia gives Drupal the perception of size and credibility to those  
who don't know any better. We can dismiss these risk adverse decision  
makers of big organisations but I think those people matter. I agree  
with Dries when he says "We should all agree that at the end of the  
day, success should be measured by the number of people working with  
Drupal, not by the number of people working on Drupal". Plone kicks  
Drupal and a lot of proprietary CMS butt, feature for feature but  
Acquia makes Drupal easier to sell by giving the perception of  
security. Anything we can do to help sell plone is good for plone  
otherwise we risk being "irrelevant".