I've been writing a lot about what I believe is important for the future of Drupal, but now it is your turn. After every major release of Drupal I do a "product management survey" to get your ideas and data on what to focus on for future releases of Drupal (8.x/9).

The last time we had such a survey was after the release of Drupal 7, six months into the development of Drupal 8. I presented the results at DrupalCon London in 2011. The results informed the Drupal community at large, but were also the basis for defining initiatives for Drupal 8. This time around, I'm hoping for similar impact, but also some higher-level strategic thinking about how Drupal should respond to various market trends.

Take the State of Drupal 2016 survey now

It shouldn't take more than 10-15 minutes to fill out the survey. We'd like to hear from everyone who cares about Drupal: content managers, site owners, site builders, module developers, front-end developers, people selling and marketing Drupal, etc. Whether you are a Drupal expert or just getting started with Drupal, every voice counts! Best of all, with Drupal 8's new 6-month release cycle, we can act on the results of this survey much sooner than in the past.

I will be presenting the results during my DrupalCon New Orleans keynote (the video recording of the keynote, the presentation slides and the survey results will be downloadable on my blog after). Please tell us what you think about Drupal; your feedback will shape future versions of Drupal.


SooperThemes D… (not verified):

With respect to the question of when I'm upgrading (my products) to Drupal 8: I'm waiting for some strong Drupal 8 showcases and a large enough user base. To port all the SooperThemes, supporting modules and distribution is a big investment and it's hard to justify the costs if people are still fine with Drupal 7. I think Drupal 8 really needs some case studies that demonstrate it's improved experience for developers.

Sébastien (not verified):

some major php frameworks are missing from the list of competitors (e.g. laravel, yii, etc.)

Kenny Carlile (not verified):

Great survey! As a developer and site builder, I think documentation is one of the weakest aspects of Drupal. There is a lot of documentation, but it's not organized well, it's difficult to find a path through (Google is often the best resource to find a topic rather than navigating through a logical path), and the format is not standardized. I'd like to see Drupal adopt an API format like the Java API for developers and I'd like to see a more direct and organized approach to overall documentation as I believe learning Drupal is the biggest hurdle to adopting Drupal.

Mark Hanna (not verified):

One thing that I'd like to see change, is how Drupal is perceived solely as a Content Management System. To a lot of people, this means its good at organizing and editing content, content being defined mainly as marketing material, OR traditional media such as blogs and magazine copy. In my experience, Drupal started as a CMS, but has evolved beyond that. In my mind, Drupal is a Management System. What can it manage? Processes, data, automation, interconnections between variety of disparate services. Either the definition of content should be expanded, or somehow lets throw off the "Drupal only does content" image. Maybe all data could technically be content, but the common sense of non-techy types is that content has a specific place, that is marketing and media. Is a product content? Sure ok. How about an order? Is a line item? How about research data used in statistical analysis of the habits of South American tree frogs? The Entity concept in particular has instrumental for Drupal to manage things "beyond content." The abstraction and codification of "thing-ness" is incredibly powerful. All content are things, but not all things are content. Managing content is where Drupal started, and the core principles and initiatives are driving towards better or more varied content display, but its so much more than that, and how to market these aspects of Drupal. One could compare WordPress to Drupal, but I think they are only somewhat similar. Drupal does and can be made to do so much more. One thing I'd like to see is a proper definition of content, and some way to market to potential clients that Drupal is and can do more. CMS++ . This all struck me strongly, last year at BADCamp. I went to the higher education summit, because I'm super into making Drupal a learning management platform. I was shocked when speaking to the attendees, many of whom where university administrators. They were hip on Drupal, but they talked about it only as a marketing platform. The idea that Drupal could be made to be a online learning platform seemed to have never crossed their mind. The learning industry is a great example of a "content++" paradigm. You need content management, but you also need other data and process management things, like a grade book, or interaction tracking and reaction capabilities. Drupal is perfectly suited to have such functionality and has it now contrib space. So as you strategize for the future, remember that content is only half of what Drupal is good at managing, and don't get tunnel vision down the rabbit hole of js frameworks. I think the Drupal community understands this, but how to project that to the public?

Aj Blosser (not verified):

The DX for D8 is pretty rough. I'm on my 6th D8 module now, and while I'm getting the hang of it, the barrier for entry has skyrocketed. If the company I work for wasn't already committed 100% to Drupal, I would have personally chose to switch to something else because of it.

The move to Symfony was supposed to be to bring new talent into the Drupal space, but after using it, I believe it's going to have the opposite effect.

Geoff Appleby (not verified):

Would you be willing to share the roughest areas for DX that affected you? Are there areas of background knowledge that you think would be helpful to provide Drupal specific content to bridge gaps for people?

Sebastian (not verified):

I could not agree more. My company (and myself) are 100% into Drupal, but Developer experience with D8 is frustrating, partially because of lack of clear and concise documentation with sample code, and also because I constantly hit the "deprecated" wall. (ie: any brand new D8 function that is already deprecated and should not be used, with no alternatives)

John Coonen (not verified):

In my many years of running CMS Expo and CMS Connection, I've fought the same demons of being "it's much more than a CMS!" There are many product offerings that labeled themselves "CMS" when in fact they were much more of a Content Management / Business Management Platform: Drupal, Sitecore, Magnolia, eZPublish, Hippo, Liferay, Adobe XM, Kentico, OpenText, and ALL other so-called "CMSs" are actually doing much more than CMS, and they have been for most of their lifecycles!

Well, being the host of CMS Expo and publisher of CMS Connection, I thought for years on a way to better define the "CMS" because semantics DO matter to me. I tried calling them "Web Experience" (WEM, CX, DX, pick a hashtag, the industry hasn't figured it out yet) and or "CX solutions, but come on, let's be honest -- it hasn't grabbed the end user/buyer's attention nearly as much as the analysts, thinking they were branding experts.

So until something new comes along, or the WEM/CXM/XM/DX label actually gets traction, I think I may have hit on something better for now. At least it's resonated with others. I began an effort to re-brand "CMS" sector itself, to be more inclusive of the entire Digital Experience journey. It's not the PERFECT name, but it's a start, toward a long-term nomenclature that better describes Drupal and other comparably equipped solutions. So what is it? Don't fall off your chair, Dries... It's "CMS 2.0."

"CMS 2.0" or "CMSS" is an acronym that covers the four pillars of the digital experience journey:

C - Content technology
M - Marketing technology
S - Sales technology
S - Support technology

This is the BEST solution I've seen out there so far, so I decided to re-position all my content on the CMS Connection to be ONLY about brands that have all FOUR of those pillars covered. I removed about 10 CMSs which were not focused strategically and tactically upon supporting ALL FOUR COMPONENTS of the DX Journey: Content, Marketing, Sales and Support. Notice Joomla, Umbraco, and many other "CMS 1.0s" are now off my list?

Please consider using the terminology "CMS 2.0" for a year or two, maybe it will stick, maybe it will not -- the community will be the final judge on this, but I came up with it for the same reason you did -- "CMS" is no longer applicable. It's just one of many disparate functions your platform offers!


John Coonen

David Lohmeyer (not verified):

Agree with AJ on the barrier to entry. I think it's higher now. While you'll see a lot more good code, Drupal will no longer be a land for hobbyists. While good in ways, it reinforces projects like Backdrop in a big way.

I also think comparing apples to WordPress is really important. Seeing some things that they have that we don't have (easily) is frustrating, and continues to be. Things like their admin UI, their drafts, content editing in general still being a lot easier out of the box. Their backend is terrible but their UX is 1000% superior to Drupal's by default. They also have powerful paid plugins like Woocommerce that can really trump Drupal's commerce options in a lot less setup time.

I answered that Drupal should appeal to front end developers. The main reason for continued WordPress use is the massive availability of beautiful themes. These themes exist because it's relatively easy to build themes for. Drupal is not easy to build themes for since it can do a lot more by default. So you see paid or generic themes trying to do everything, and they do everything very poorly and thus suffer visually.

Also, not having something like Panels in core is really bad. We're still waiting for a Panels UI if I recall in D8, and Panels and custom layouts are something Drupal is REALLY good at... when you have an interface to do it with. Blocks aren't good enough, they're not easy enough to work with on a per-node layout basis.

TLDR: we should examine competitors, beat them at what they do well, then continue improving on our strengths.

Jakub (not verified):

We can only be gratefull that panels are not a part of the core. I think this is the most overrated module ever. I can't understand why it's so heavily used even though there is frequently many better solutions out there in many use cases.

Leo (not verified):

It took me a long time to "see the light" regarding Panels. It's extremely powerful and is basically Ctools on steroids. One problem is that it's frequently sold on the ability to drag and drop content in a layout and that implies that it's a layout tool. Really it's a developer and site builder tool with a UI that will strike terror into most non-techies.

Used in the right way it's immensely powerful - but could do with some love in terms of it's UI and not for all situations imo.

David Lohmeyer (not verified):

While I agree that Panels in its former states might be "overrated" (interesting that this word is used in replied to two of my points in my initial comment), there is currently no answer to it in D8 for building layouts which Drupal should really excel at in a site builder and non-dev world to get wider adoption. Maybe with core attention something like Panels would actually have a good UI.

sherri (not verified):

When will you let us know who won the Drupalcon ticket?? :)

Johnny (not verified):

Because David talked about WordPress I wanted to give my personal view.

I have some WordPress sites to manage right now. I hate their UI. After working with it for over 6 months now, I still find nothing in it. I always have to go through different paths to find what I need. Just this week I ha d a long time WP developer that told me a feature would not exist in our WP Installation. I then found it 15 min later. But this is just my personal view.

Megan (not verified):

I agree. I think the Wordrpess UI is really overrated in a lot of ways. Especially when you have plugins and themes creating their own completely different UIs. And shortcodes. I've had to help a several clients out of shortcode messes.

That said, there are a few things they do really well that Drupal could learn from: revisioning/drafts and media management. It would be great if core had a better way to manage media uploads, scaling/thumbnails, insertion, enlargements, links etc.

David Lohmeyer (not verified):

While overrated, they're currently blowing Drupal away in terms of market partly because of that UI and heavy designer support. Their codebase is very bad but they have users because of the code flexibility and relatively consistent admin UI (imo). I'm sure you've worked on some WordPress before and can relate to inheriting spaghetti code plugins/themes, I know I have. It would be a great world if Drupal became the norm and we actually had pretty clean codebases in millions of sites instead of Wordpress.

Leo (not verified):

I do think that one of the biggest obstacles to Drupal adoption is the learning curve. Once you know how to use the big Drupal modules like Views, Rules, and the Field system, there is huge flexibility at your disposal. But there's very little in the way of guidance of how these systems can be used for new site builders. While there is some documentation on Drupal.org, it's not very well organised; in the past I've tended to find myself doing copious amounts of Googling and picking up bits and pieces from various different sources - but it's fragmented and I think many people would just give up.

The developer documentation is pretty good - the API is well documented and there's plenty of techie documentation around module hooks.

But for site builders and end users, it's tricky. I feel that Drupal could benefit hugely from having equivalent documentation aimed at these two groups and showing how to best accomplish common site building tasks.

There are books available but the info really needs to be online and free to access.

Ken Robinson (not verified):

I learned Drupal in about 2008, starting with D6.02. I jumped into module development and learned from a great mentor. I've grown with Drupal and loved doing module development in D7. Now with D8, I have to re-learn EVERYTHING. I liked D7 because OO PHP wasn't forced on anybody, now it is. What would have been preferable, IMHO, would have been a transitional release which to support both D7 & D8 style modules. The core developers really needed to step back and look at the entire community to see how the D8 changes affected regular developers.

I have attended local Drupal camps and seminars about D8 module development, but the learning curve is still extremely steep.

eFeS (not verified):

I totally agree with AJ and Leo. My biggest challenge to learn new Drupal features at major version upgrades. I'm not a full time Drupal developer, but contributed to Drupal and made sites solely with Drupal for more than 5 years. It's very hard to learn, documentation pieces are scattered all over the web. And yes, there are situations, when Google is better then api.drupal.org. And new versions make the process harder to manage...

But I think, customizational capabilities worth the effort to learn. But for newcomers the whole learning process could be easily prove to be diappointing and very frustrating.

albertczyk (not verified):

I mostly agree with Ken R. IMO, D8 is kind of a moonshot, and the cost of migrating existing sites in previous versions is too high and it doesn't provide any measurable benefits. I've been maintaining Drupal sites since D5, and migrations to D6 and D7 were absolutely painless. Even more, migration to D7 provided a strong incentive because there were in fact *more* modules and of better quality than for D6. Plus, migrating themes and custom modules was relatively easy. But an upgrade of a fairly complex running site to D8 would represent a ginormous effort. I simply cannot make the case for it to any customer.
I also don't quite understand some moves as switching to symfony. The built-in http engine was OK. Maybe expanding API calls could come in handy, but little more.

Doug Gough (not verified):

Just want to quickly offer the alternative point of view on the developer experience. Yes, it's harder if you don't have a grasp of OOP, but if you take some time to learn the basics of OOP then I find that D8 kind of unfolds before you in a very consistent, learnable and friendly way. The consistency is the huge win for me in moving from D7 to D8.

Leo (not verified):

Ironically, I had just got my head around OOP when I started using Drupal 6, and was initially nonplussed by the hook system. I'm looking forward to getting back to OOP with Drupal 8.

Joshua Stewardson (not verified):

I posted the survey to our Slack #drupal channel and got an immediate and good response from one of our awesome sys admins:

> The fact that there are no operations roles available for #1 says a lot.

John_B (not verified):

I would not get in Drupal had I not started in D6. Barrier to entry too high. Luckily I know enough to cope now, and Drupal has been good to me.

My central point made in the survey is that it is tempting to move away from the concept of the web based on structured and linked pages of data, which is where it shines, towards appification, because that is fun to develop and can bring in big bucks. This is dangerous, because it is moving into a world where client-side logic can interact directly with database and static content, where in many complex use cases, Drupal (however good it may be as a decoupled backend) will not be the scalable or economical choice. Drupal is the ultimate page builder which can thrive long terms in those parts of the web which have not lost sight of the value of a page of structured hypertext or SGML with a durable URI.

Grant Klassen (not verified):

I started using computer tech 32 years ago with the introduction of the first accessible GUI. It's 2016, the move to more programming frameworks, command line tools and complexity (Symphony, Twig, SASS, Drush) appears very regressive to me. My job is the in-house Drupal developer for a small non-profit organization. Creating a custom theme (based on Zen) in D6 was manageable. With D8, it's now looking like I'll have to hire a 'themer', unless I can customize an existing theme that's close enough to what we need.

Siva (not verified):

Why you are using the external survey tools and not Drupal for the survey?