Doug Vann on what's holding back mainstream Drupal adoption

About the author

Jason Hibbets - Jason Hibbets is a senior community evangelist in Corporate Marketing at Red Hat where he is a community manager for Opensource.com. He has been with Red Hat since 2003 and is the author of The foundation for an open source city. Prior roles include senior marketing specialist, project manager, Red Hat Knowledgebase maintainer, and support engineer. Follow him on Twitter: @jhibbets

What's holding back mainstream Drupal adoption?

Word on the street is, Drupal is hiring. Well, Drupal shops to be exact. But the lack of experienced Drupal developers and themers is hurting the ecosystem.

Chances are, you've recently visited a website running Drupal. (This is one of them.) How many projects out there want to be using Drupal but don't have the in-house talent? Or they've contacted a Drupal shop and found out they're all booked up with other projects for the next for weeks and even months!

We decided to ask Doug Vann, a training consultant in the Drupal community about what's holding back mainstream Drupal adoption—as well as some other intriguing questions. Vann has been training individuals and organizations on how to harness the tremendous power of Drupal. He also attends various Drupal events regularly. Let's see what Vann has to say.

How did you get involved in Drupal?

I was working on a heavily Venture Capital funded social network site. The VC was paying a .NET shop to build a tremendous volume of custom functionality. It was brutal. Whenever we asked for something they didn't offer, they would slowly build it at a huge cost, then they would turn around and make this new functionality part of their service offerings. We were personally funding their R&D department and it was taking forever. I was actually a Joomla guy at the time and I was trying to get this project out of .NET and onto Joomla (Joomla1.5rc2 at the time). I actually won that battle and we began to solicit individuals and shops to put together an impressive team to build this out—fast. We had already wasted over a year and $1M on this project!

While I was posting ads on JoomLancer, Guru, and other sites, I attracted a lot of attention with my huge, flowing bulleted lists of ALL the functionality we wanted to build. We could afford it and we were going to build it! It was at this time that a shop called me up at the office and stated that they use Drupal. I somehow had the mistaken idea that Drupal was an old forgotten fork of Mambo before it became Joomla. Where did I get that idea? I have NO IDEA! LOL Anyway... This shop tells me that they have seen all my huge, flowing bulleted lists and that much of what I was asking for was available right out of the box in Drupal.

Long story short, 7 days later they showed us a quick prototype that they had whipped up in Drupal 5. OMG! Me and the team were blown away! Indeed, much of what we wanted was actually right out of the box in Drupal 5. We launched our site 70 days later and it didn't cost another $1M to do it!

What's holding back wide-spread Drupal adoption?

Brain Drain.

We really need more, talented players in the Drupal-sphere. Right now we have projects that are not starting because organizations are putting out RFPs but not getting back the qualified results they require. We have shops turning down work because there's not enough talent in-house and not enough of a talent pool to feed the shops. How many sites have wanted to be built in Drupal but were unable to find the talent and unwilling to wait? It happens WAY too often. The Drupal community is leaving money on the table and the part of the solution is to reach college students, fresh graduates, and people willing to move their C++, Java, or RoR, etc. skills to Drupal.

What role do you play in the Drupal community?

As I mentioned... qualified, skilled Drupalers are hard to find. This is where my training business via Synaptic Blue Inc. really scratches an itch. I provide a variety of fee-based and free public trainings at DrupalCons, DrupalCamps, LinuxFests, and anywhere else people want Drupal training. Here, people show up who desperately want to understand how Drupal works and how to make it work for them. Some just want to launch a site for fun or profit, others want to make a career out of this and they know they need the skills.

In addition to the public trainings, I am often asked to visit onsite with organizations to increase their internal knowledge base of Drupal. I've done this for NASA, The NY Attorney General's Office, Highlights Magazine for Children (Fun with a purpose!), the U.S. Federal Court, and quite a few major universities and colleges as well as other organizations.

What's the best part of the Drupal Community?

The "Community" is the best part of the community! LOL What do I mean by that... hmmmm... The people are the community. They gather in local groups, shops, or regions, but at the heart of it all, the community is comprised of individuals. These individuals put in tireless hours to make the core better, firming up contributed modules or documentation. Some speak eloquently at events, some write books, some organize events. It is this highly productive group of individuals that make Drupal the powerful, sought after solution that it is and forever will be!

You'll be attending a few upcoming events. Tell us where you'll be and what you'll be doing.

My next gig is DrupalCamp Atlanta. This is one I have never missed since I attended the first one in 2009. That was my fourth camp ever. Now DrupalCamp Atlanta 2012 will be my twenty-eigth! This camp is unique in that the organizer, David Terry, and his MediaCurrent crew put on one heck of a professional camp. Many camps feel like casual get-togethers and that's great, but I always come to Atlanta looking sharp and expecting to do business. In fact, this is the second year they are offering a Business Summit. The Drupal Business Summit was perfected in Atlanta last year. It brings a much needed business focus to the workings of Drupal, while also providing a day long event for the suits to attend. The value is amazing and evident by the fact that other camps are trying to emulate it.

After Atlanta is BADCamp or Bay Area DrupalCamp—early November in San Francisco at U.C. Berkeley. This will again be the largest one with upwards of 2000 people. After that DrupalCamp Ohio is in December. That will round me out with 30 camps in 48 months!

Tags

About the author

Jason Hibbets - Jason Hibbets is a senior community evangelist in Corporate Marketing at Red Hat where he is a community manager for Opensource.com. He has been with Red Hat since 2003 and is the author of The foundation for an open source city. Prior roles include senior marketing specialist, project manager, Red Hat Knowledgebase maintainer, and support engineer. Follow him on Twitter: @jhibbets

41 Comments

Thanks again for the interview!
Since we put this interview together some fascinating events have transpired. My involvement with the Drupal Branding & Marketing committee has extended my view on more than a few things.
As a committee we're working with the Drupal Association to make coordinated moves to attract more attention and clients to Drupal as well as more developers to Drupal. There's nothing to announce at this time, but we are very aware of the shortage of Drupal talent and we're exploring options to resolve it.
To stay on top of things please visit, join, and participate at http://groups.drupal.org/marketing-drupal . We really want to hear from a large swath of the community on these matters.
Another observation I have made is that the backlog of Drupal work is not across the board. The budget, size, and type of project determines whether the client will have an easy or difficult time finding a qualified solutions provider for their project.
It's a fascinating situation to be in where we want to grow the user base, the customer base, AND the developer base all at the same time. We're looking forward to the Community really getting involved. We see this already where DrupalCamps, Usergroups, and others are making moves to make their events an excellant 1st exposure to Drupal as not only a web solution, but a career.

This topic is only going to get MORE fascinating!
- Doug Vann [Drupal Trainer, Consultant, Developer, President of Synaptic Blue Inc.]
- http://dougvann.com

This is very exciting! Thanks for sharing. I think it's just part of the natural growing pains of an open source community. The best part is, the Drupal community i susing the open source way to approach and solve the problem. This, in itself, it awesome!
Jason

One of my worries is that "people willing to move their C++, Java, or RoR etc. skills to Drupal" may be a smaller demographic than you think.

My impression of things is that, to be a worthwhile Drupal hire, you need a fair bit of experience, but to get that experience without being in some kind of apprenticeship or code monkey position, you need to enjoy it to a certain extent. However, with Drupal being written in PHP, I don't see those demographics seeing it a desirable thing to move to.

People who enjoy C++ are probably the kind who want to focus on things that C++ does best like CPU-bound native applications. (Games, multimedia applications, anything simultaneously complex and low-level, etc.) I'm not sure how many of them would want to learn PHP AND Javascript to do web application development when they could learn just Javascript with Node.JS and do anything not I/O-bound in either C++ or client-side Javascript.

In my experience, Java is mostly learned in college/university courses, which means the migration path could be rocky for lack of students experienced in self-directed learning via online resources.

I can personally attest to how uncomfortable PHP is to people used to RoR and Python. I avoid it whenever hosting permits and stick to FatFree Framework (which requires PHP 5.3 anonymous functions) when I do use it, because it gives me a more functional Python/Javascript/etc.-style API.

I have nothing against Drupal, but I get the impression it's at a distinct disadvantage due to all the design and documentation baggage PHP carries.

Seriously? Using strings as function references in anything older than 5.3?

Being unable to get raw image data in GD because PHP wraps the API so snugly that you'd have to dereference a pointer to get it?

Building a template engine into the language syntax that still expects template designers to manually keep track of whether or not data has been escaped in this day and age?

Why are the object-oriented parts of the PHP documentation still so poorly indexed that you have to first look up the exact class and method names via Google, blog posts, and the stubborn conviction that they must exist? (eg. alternatives to opendir/readdir)

Thank you Stephan,
You raise some very valid points. I did mention my hope that developers of other technologies [C, Java etc] would move into the Drupal landscape. What I did not mention is that I also hope highschoolers and College students choose PHP and Drupal as a lucrative career.
As for your objections to PHP on many levels. You're not alone in your position. Despite any of its short-comings, PHP continues to move the WEB in exciting directions at blinding speeds. As both a solution to today's Web Applications demand AND as a money making vehicle for a shop or individual, PHP has stood the test of time and proven itself to be efective on many levels.
But as I said... Your criticisms are shared by many and every honest PHP dev has many pain points. PHP continues to improve and I'm excited at how Drupal will continue to leverage it in the future!

According to that latter post, this is Dries' intention: he wants Drupal to become more useful for non-programmers. That essentially means Drupal is estranging the very people that build it. This means there's a new sort of job position of "Druplist" emerging, which is someone who can click together a website, knows some (enough?) programming to get new functionality built, and possibly commission programmers to build new modules where that's required. However, 90% of all websites can be built mostly with prebuilt modules. They may require a little tweaking, but very few projects really require you to build a lot of module functionality from scratch.

The fact that Drupal's written in PHP and getting increasingly more complex means that there's a growing need for ever-more specialized programmers with a high degree of Drupal expertise. With Drupal 8, the move to Symfony just made it even more complex. This means that you're going to need more of exactly the kinds of people who are leaving (or never joining in the first place) because of their dislike of PHP. The kind of people Stephan talked about.

I don't think it is PHP persé; allthough it has a bad name. There are really neat projects done in PHP. Like CakePHP, building a clean OOP MVC framework on top of PHP, back in the days when PHP did not even have proper OOP features: a gigantic feat. Or like CodeIgniter and Laravel with a really smooth API and DSL.

The web-professionals that Build it are the ones that Use it. They are their main target-audience.
Because there certainly are a lot of PHP-professionals out there; thespite what hipster-developers in Ruby, Python and such make you believe. Sure, these clean, pretty PHP-frameworks, might not be as hip, or friendly as Django/Python or Rails/Ruby, but still a giant leap from Drupal.

I won't disagree that CakePHP is an elegant framework. I experimented with it myself at one point. However, I do have to disagree with you on PHP's role in things.

If I'm going to be using a framework heavy enough to be an order of magnitude slower than bare PHP unless a bytecode cache is used, I might as well use FastCGI with a language that has list comprehensions, function and class decorators, a cleaner standard library, a clean, concise syntax for functions with variable keyword arguments, and the ability to explicitly specify which code needs to run only for initialization and which code should be run for each request.

Whenever I use PHP with FatFree Framework, it's because FatFree will give me performance in the same ballpark as Django/Pylons/Pyramid+FastCGI/mod_wsgi on shared hosting that doesn't offer those technologies.

As for Ruby, I get the impression that I'm the polar opposite of a hipster because, despite how useful it could be to know, I just can't get over how much the design aesthetic offends my sensibilities. (I think I once called it the illegitimate offspring of Perl, BASIC, and Java while chatting with a friend.)

I think we are on the same side here. I switched from Drupal to Rails (As per the abovementioned link on my blog berk.es) for the exact reasons you mention: because there are languages and framworks that are such a better fit then PHP.

I think, especially when developers grow, they will leave PHP (and its tools) for such languages. And I think, indeed, that this is a threat to e.g Drupal: the "intelligence", those who invent and built good template systems, high-performing ORMS, clean APIs and such, are moving away.

For me the reason was: why try to make something as messy as Drupal pretty, in a sub-optimal language, when there already are alternatives that are ready-to-go, clean and written in a language much better suited for modern web-development.

We are on the same page here.

What I was also saying, is that PHP is far from dead, if that ever happens; and when there is a demand for PHP, there will be PHP-developers. But those developers, moving around within the PHP-world, will opt for cleaner, more modern frameworks then Drupal, Joomla or Wordpress.

Great interview/article, and as always, thanks to Doug for the work he's doing in the Drupal community!

Stephan brings up really critical points, and my experiences do line up with what he is saying wrt trying to entice solid C, Java, RoR, etc developers to jump over to PHP/Drupal development. One area of opportunity I do see developers evacuating their current platform is .NET. There's still considerable work out there for Microsoft developer professionals, but they seem more willing (and prepared) to make the change, based on my experience as the guy who does the hiring for my company.

One thing I really want to see more of in the upcoming year is stronger open source development courses being made available in the modern Universities, and possibly at the high school level as well. I am hoping that this is something the Drupal Association will be able to help evangelize the benefits of to department chairs/curricula designers in the months and years to come.

Hi,
Drupal needs help with marketing and so do small Drupal Development shops. I have 2-3 designers/developers I work with on a per project basis and we're not busy enough. Doug, can you help me to find good paying Drupal projejcts, $3000 and up?

I was surprised that this is a concern - I see Drupal popping up all over the place from big heavy-traffic websites to small shops. I guess the potential is bigger than the talent available!
To be fair, I have tried to do just a slightly advanced Drupal setup before and har a complete brain fail, so... not too easy to jump onto.

I've been interested in Drupal for quite sometime and the only reason I haven't really adopted is due to experience in php. I've programmed in Java and C++, C# and I've even used asp.net at one time. However it took a while for me to adopt a CMS. I've recently adopted WordPress and building plugins and sites for customers. However I haven't been able to play around with Drupal like I want and don't know a whole lot about it. My knowledge in WordPress is intermediate and growing. In all this article makes me want to pick up php and drupal development skills more. Thanks...

Heya... hit me up at my contact form at http://dougvann.com/contact and I'd be happy to spend a 1/2 hour or so screenshare with you showing you the power!
One thing the Drupal Community is really learning is that Drupal is best learned with a mentor.
;-)

A couple of people recently announced in blog posts that they left Drupal. It seems like the people writing them need to give themselves permission to move on. By no means do a couple of blog post imply a 'brain drain'. It is normal for people to come and go.

What is the case is that for every programmer that "leaves" Drupal, many more join the project. There is a very big opportunity for those joining Drupal.

Right on, Dries!
There IS a very big opportunity for those joining Drupal!
I personally don't know many ppl who have "left" Drupal. I know some who treat it like a hobby and they get hobby results from it. But those who work the fields are reaping the harvest with us and that is exciting to watch!
My biggest goal right now is doing what I can to help encourage more growth in the developer community. I use that term VERY broadly to mean that I want to see more designers, themers, project managers, site builders, coders, speakers at events, more events themselves, etc. I want to see more shops and more innovation and more distributions and more modules too.
I love the fact that Drupal's market share is ROCKING. I'm enjoying pulling more people in to a community with not only explosive adoption growth, but some of the best people in all of OpenSource! :-)

I didn't interpret the "brain drain" answer in that way. I can't speak for Doug, but I don't think the intention was to highlight some of the turnover in the community that you mention.

And for other folks reading this, yes, I agree, there is always turnover across open source (and other) communities. People's lives change, priorities change, interests change. This is normal, as you point out.

I read the comment as trying to say that there's more talent demand than there is talent. A good problem to have for the Drupal ecosystem (sort of). Other open source and even some commercial organizations can't even move some of their product right now. I felt that Doug was truly trying to say that if you've got some programming skills, there are opportunities in the Drupal ecosystem. If you need programming skills, consider the skills that can make you a Drupal expert!

"I was working on a heavily Venture Capital funded social network site. The VC was paying a .NET shop to build a tremendous volume of custom functionality. It was brutal."
I am sure this has been said, but it was not the .NET that was the problem, it sounds like a poor choice of a project manager and/or tech lead. Or...bad choice for the .NET dev vendor period. It was the people, not the tech. As for Drupal, it is nice, but as another poster mentioned...a solid C#, MVC3/TwitterBootstrap developer is not going to jump ship without a forced push.

Mickey,
You're so right. .NET was not the main issue. If this project would have been done in straight PHP and with the same volume of custom code it would have been just as equally difficult to make changes to the site.
My point was that "rolling your own" while it gives you some degree of freedom, also ties you down to your own sense of best practices. Without having the time tested best practices of Drupal, the NYSE projects were heading full steam ahead into a world where nearly every solution was custom and that was the BRUTAL part I was referring to.
There are those [not saying you are one] who laugh at the plug-n-play modular aspect of a high quality enterprise CMS like Drupal. Those that laugh are the same that seem NOT to understand why a project like NYSE moved over 50 sites off of .NET and they don't understand why the State of Georgia dumped Oracle, Java, and Vignette to adopt a solution built [of all things] on PHP. They assume some slick sales guy sold someone a bill of goods, when in reality Drupal [not the custom .NET solution NOR the Java, Oracle, Vignette solution] is empowering these large scale [may I call them ENTERPRISE?] users to truly be masters of their content and the pages that render them.
My message is clear. If any one is out there and considering a large scale project and you're thinking about putting a dozen .NET developers on the project, HOLD ON! Likewise if the licensing fees of Vignette look tolerable because the technology behind it sounds big and impressive and fast... HOLD ON! There's so much more to consider.

Caveat....
When Drupal is your hammer everything looks like a nail. I've seen a Drupal project fail that should not have been Drupal at all. Fortunately, I came in after the decision was made. I want to be clear that I don't think every single site on the web should be Drupal.
LOL

@Mickey: Are you sure about that? My job is mostly .NET, but with quite a bit of WordPress & GNU/Linux admin, plus as much Perl as I can squash in. I've spent several years working as a programmer, web programmer and DBA / DB developer jack-of-all-trades and this has only served to intensify my distrust of .NET.

In my view C# is an OK language for big application development, but it would never be a preference. The object model and the language are way too complex, but they don't need to be.

PHP and particularly Perl allow you to do some things quickly and easily and put harder things in reach. Perl in particular includes some really helpful powerful features with a terse syntax. C# can do pretty much everything but it's mcuh harder to program in than either of the aforesaid. It isn't really friendly for web development. It feels as though Hejlsberg took a deliberate decision to do as much as possible the long way round instead of creating a powerful syntax. It's flexible but heavy, like a massive metal chain.

I've got a lot of experience with creating SharePoint 2007 web parts as the primary vehicle for buildling web applications and portal functionality. It's a painful procedure. SharePoint is the flagship vehicle for .NET web app development and I can't wait to see the back of it (by getting a new job as a Perl dev hopefully). 2010 is meant to be better of course but you could improve a lot about 2007 and it would still be screamingly bad.

After years of using WordPress, Joomla! and Movable Type, I finally got round to installing Drupal recently and was blown away about how much similar-to-but-better-than-SharePoint functionality was provided. Such as for instance content types.

The differences? Drupal is slinky, resilient, well-documented, and basically works. It also looks a lot cooler. There are about 20,000 things wrong with SP2007, but my favourites are:

inability to code things in plain text, necessitating use of MS SharePoint Designer - a terrible and overcomplex product that broke my SP test build when I used it for its advertised main purpose (making a slight change to the master page template!)

table-based default design (hopefully this at least has been buckwheatsed in 2010)

some admin functionality (e.g. dragging and dropping web parts) is only available in Internet Explorer! But I still ditched IE8 (I was keeping it because our users are on it) because it just stopped loading the pages in the end. IE9 is still by far the poorest performance-wise for accessing SP. I use FF, GC and Opera.

I once tried looking up how to change the HTML page title element from the moronic default "Pages - Default" to something sensible. There were two very complex ways to do it, and I only had about an hour left in the working day, so I decided not to bother. The PAGE TITLE for Pete's sake. Try changing the title of any page or post in Drupal or WordPress. This takes seconds and is a joy to perform because both these web application frameworks are built by people who love and understand the web. MS fear and misunderstand it - at least that's what you'd think if you use SP07.

SharePoint is really heavy. You could probably run a Drupal install for a large organisation's intranet or for a major high traffic website on a couple of powerful enough virtual servers - especially if you had a separate database server. Compare that to our SharePoint 'farm' which runs on FOUR virtual serverswith a clustered dedicated database backend made up of two servers. (Admittedly only one is in use at any time). Plus this is all connected to a massive SAN.

This was the recommended spec - MS solutions always demand your top dollar, but deliver functionality that is better provided by free and open source software. Oh and that was a 'light' spec by the way - we were encouraged to go with a bigger SAN just in case.

Try coding up .NET web parts. Figuring out the difference between the two kinds of ASP.NET server controls is quite taxing, especially when even the official documentation at www.asp.net is bizarrely incomplete. Also there was no documentation on how to do stuff with ASP.NET in web parts as opposed to code-behind pages.

What other choices are there for .NET web app developers? DotNetNuke? I have heard that it is also diabolical - but it couldn't be any worse than SharePoint, and won't cost you £700 a server (= $1500 USD?) (plus another £5000 if you use it for a public website).

If you hear in IT industry mags that companies love SharePoint, you know why? It's because it's the first time many ordinary people get the chance to use a collaborative web content application. If only they saw Drupal first.

Drupal is a great product. WordPress is too but it is primarily aimed at being a blog (even though it can do full CMS) and does not include lockable areas out of the box.

All power to the Drupal community who are bringing a mature, quality FLOSS product to a deserving world.

@Bill Rose. Agree that SP2007 is a mess. SP2010 is a bit better. C# is fantastic, if that is what you do. Page titles, I must be missing something, not more than a text change. If you are building enterprise apps, C#, MVC with WCF is the way to go (unless you are a java shop). Nothing wrong with Drupal, but nothing there I can not do in MVC/C# and follow good, clean programming practices that any other .NET dev could walk in a pick up on day one.

Mickey said "...a solid C#, MVC3/TwitterBootstrap developer is not going to jump ship without a forced push."
I hear you and you're on to something here.
I'm not selling Drupal for Drupal's sake. If a solution isn't a good fit for Drupal then I won't bid on it. I am far more interested in seeing the client's needs satisfied. In this day and age, clients are getting quite savvy. They expect a LOT out of their websites. They watch videos on youtube where you can find Case-Studies of major government and private sector sites. They see how easy managing content is and managing users is and they wonder why their custom CMS doesn't have that. The answer is that they didn't ask for it when they asked the JAVA or .NET developer to build the site. Then they naturally wonder if they should have chosen Drupal instead of that custom JAVA or .NET solution.
In this sense the CLIENTs out there are asking for more control of their site. Many even want the ability to train someone internally to learn Drupal and make minor [or not so minor] changes to the site. In keeping with that line of thinking, many clients want to invest in books and events and consulting to REALLY educate their marketing and/or IT department about Drupal so that they can launch and manage their own micro-sites or other projects. [This is exactly where I spend a LOT of my time; training clients onsite to take better advantage of what Drupal offers them. I've done this for NASA, many Universities, BlueCross BlueShield, and many more.]

As more and more "solid C#, MVC3/TwitterBootstrap developers" realize that clients want THIS kind of solution, it is my hope that they will see the fruit on the trees and climb a ladder and start grabbing some!
At some point or another many of these coders are going to realize that 40+ hours a week in a code editor is only ONE way to build a client's website. Another is to be committed to quality CMS with a quality community behind it. And know that you don't have to pack up your editor and do everything with a mouse. Many Drupal sites contain volumes upon volumes of custom code all written within the Drupal API and framework.
If the .NET and C# and JAVA coders out there are really committed to state of the art, best in class solutions to the web needs of clients some of them [NOT all or most, but SOME] will realize that the perpetual innovation and expanding solutions-base of Drupal is an exciting and very lucrative career choice.
At the end of the day this is all about providing solutions. I believe Drupal has an edge that is unmistakable in its appeal to developers, designers, end users and potential clients.
Jaguar used the tag-line "The art of performance." In that vein I would say "Drupal, the Art of Web Based Solutions!" We have a LOT to offer any programmer who wants to deliver a whole new kind of solution to end users; a solution that more and more are asking for by name!
Doug Vann [Drupal Trainer, Consultant, Developer]http://dougvann.com

The answer is that they didn't ask
for it when they asked the JAVA or .NET developer to build the site. Then they naturally wonder if they should have chosen Drupal instead of that custom JAVA or .NET solution.

Correct. Up to the point where you piggyback Drupal into this story. Drupal is not, in no actual and workable, way able to solve this. Sure, maybe that cheesemonger around the corner, who can now create a new page and embed a google-map. Or the more tech-savvy user who can actually try new modules on their **simple and clean** Drupalsite.

But the rest is just theoretical. A ~10K site in Drupal is not that flexible that a webmaster can just tug in new modules. Not that and keeping a sane, maintainable environment. Drupal comes with tools like strongarm, features, drush and whatnot: in that it hardly differs from Rails, Django, Java, .net and whatnot. The one working on the site and application is an expert; probably a programmer. Using an RCS, commandline, writing code, deploying stuff over ssh; etceteras.

The main difference being that in my average larger Drupalproject the PM almost always has to say "sorry but no" to the client. Sorry, the module is not good; that solution won't perform; this new view you propose does not work without a refactoring of that part of the theme. And so on.
As such, Drupal offers little benefit over the tools you name.

Only in the low-budget-little-customisation, Drupal will outshine those tools. But I doubt anyone is proposing their client to write a Java-springs-based CMS for the cheesmonger around the corner to publish her menu.

You are right in that Drupal can offer some nice CMS solutions, and in ways better than others and definitely faster than roll your own. I also see what Bers is saying. Most enterprises ( medium to large companys) are looking for a CMS and a thinking, interactive dashboard, data-driven content, and very specific line of business applications. If the marketing department wants to stand up a internal/external site that is simply CMS, Drupal is usualy on the list somewhere. Along with SlamCMS, Orchard, etc... they provide some nice systems. When the client asks for an order management system, with custom, flexible pricing (real time), delivery management, warehouse management specific to their industry, code to run scanners and barcodes printers in the receiveing room, etc..you go to custom .NET, Java, etc...
Like you said, if the client is looking for a Drupal solution, I won't bid on it....yet. :)

What I said was, "I'm not selling Drupal for Drupal's sake. If a solution isn't a good fit for Drupal then I won't bid on it."
As for whatever a cheesemonger is I have no idea. This article and this thread is not intended to defend the fact that $10K sites and sites costing over $1M are enjoying the level of control that Drupal provides.
I don't know at what price level a client starts or stops being a cheesemonger.
Let me be clear.
ALL existing solutions and new ones coming around the bend have their place. I don't believe Drupal will or even could replace Vignette, raw code, Wordpress, Drupal or any language.
The facts don't lie. Drupal adoption in government and the private sector across all continents is a simple fact. We are gaining ground and we're not slowing down. Drupal8 will make this growth escalate. At the same time C# and .NET and JAVA and whatever will also continue to gain. I'm not talking world domination. This isn't a zero-sum game.
Drupal provides power. Clients want power. clients are willing to learn Drupal to ring even more power from their sites. This is true at the $10K level and the +$1M level.
For clients who don't want to use Drupal, there are MANY excellent choices from which to choose.
And to return to te intended topic... We're going to need more ppl who want to make serious money in order to get all this accomplished
;-).

Well said. Always a fan of coding, learning new code and always a fan of making more money.
All comes down to what you want your web application to do, how you want it done, what technologies are already in place... etc.

From my experience with building sites. It really depends on how big they want the site. For small very simple sites I'll just hard code them since they don't have a lot of functionality or they are all static. However for huge projects where content will always be changing I've stop complaining about CMS and started using them. As of right now, WordPress does the job since customers want blogs on their site and this makes it a lot easier. My interest in Drupal comes with finding the best solution for the website. An example is an Enterprise system which I believe Drupal can handle that. I wouldn't recommend WordPress for such a site.

As for businesses choosing languages like .net and Java for websites. I believe that businesses don't think what is the best solution but rather we have this now so why not use it. I've coded sites where I know what they have isn't the best solution. And I've tried suggesting other solutions and was not successful but I do hear how expensive it is just to change requirements in .NET and Java.

In the background of this discussion about the balance of Drupal talent versus opportunity, there is the issue of whether developers are not signing up fast enough or are fleeing the scene. Also in the background discussions (not on this post) is the question of whether an orientation towards a greater user focus is at odds with the interests of developers and thus causing them to leave.

All very interesting things to consider but I don’t think they are specific to Drupal. As a developer for over 20 years, a UX specialist for 16 years and a ‘Drupaller’ for 4 years, I see the ‘tension’ between developers and users as being the same in the Drupal community as everywhere else. It’s always been there and always will be there. This tension often boils down to a tug-of-war between what is seen as convenient for developers versus convenient for users. For the years that I have advocated for users, I have argued, begged, cajoled and convinced developers (and their managers) to do the right thing for users. It does take effort and commitment (and money) to go the extra distance to make functionality usable – that’s the nature of the business.

The good news is that I find most professional developers not only want to write clean, functional code but also do want to serve the interests of users. Sometimes they are not able to see how to achieve both these ends at the same time. That is why we need UI systems designers. I find this is also the case with Drupal.

I see the ‘tension’ between developers and
users as being the same in the Drupal community as everywhere else. It’s always been there and always will be there.

No. It has not, not everywhere.

The distinction, and specific Drupal-problem is that Drupal wants to solve UX-issues for my clients and my specific cases, applications and projects. Get of my lawn!

As a developer, I want a tool that allows me to build the exact proper UX for my specific case (and yes, there are plenty such tools). This way of developing is what helps developers most, without the "tug-war". Because when a system provides me with effective and efficient tools to make the best UX for my clients case, my project or my application I work with the "frontend-guys", I work alongside the UX-expert; and I can actually implement the suggestions my client gets back from a UX-review.

I don't think this holds Drupal back, though. But it is a factor that I have seen to frustrate my projects and clients a lot: the fact that the sites I, my team, or my (sub)contractors deliver are just plain awful in UX. It does not help when the delivery of a CMS has bad UX to Manage Content. It does not help when, in order to fix it, you have to hack your way trough so many gluecode modules, theme-overrides and whatnots; just to get a somewhat decent workflow, interface and experience.

It may partly be because my mindset prioritizes UX over almost everything else, but I see that as a huge issue.

Ill-fitting admin UX that's not worth the effort to customize to match a specific site's workflow and conceptual model is probably the #1 reason I've dismissed CMSes when evaluating their suitability for various projects.

Bèr you raise some very good points, thanks. I can certainly understand what you’re saying with regard to having the right tools and I certainly agree that Drupal is missing some key elements – in my opinion it’s missing an entire UX designer layer (which is not the same as the ability to theme one’s way out of a tight spot or build custom glue modules.)

I’m not going to dispute anything you’re saying but I do want to clarify my position a bit more. In my experience, the technological capabilities or limitations are only one of many potential causes of poor UX. Other factors I’ve encountered are poor product management, lack of UX talent, lack of funds, etc. But the overriding issue that concerns me is what I would regard as the culture of functionality-over-user-experience. This is what sets up the tension between developers and users and I have seen that in all the environments I’ve worked in. No, not everyone has this problem but it does arise. It’s a costly mistake that many software vendors make (I’ve done numerous UX bailouts in that regard).

So in that respect I look at Drupal’s ‘condition’ (the poor UX and lack of an adequate UX control system) as being a consequence of a historical bias towards functionality over User Experience. Here’s two examples: (A) FAPI is a convenient way for developers to build monolithic forms for getting user data to and from tables – but monolithic forms are not what I would recommend as a UX strategy in most cases. (B) The t() function is a convenient way for developers to help the UI be translatable – but it does nothing for reaching more subtle idiomatic usage contexts that are quite common.

These specific examples are, I assume, the Drupal development community’s best efforts, so far, to address some fundamental issues and they are essentially functional strategies. As a developer I have found them to be very useful. But as a UX designer these techniques, as they are, fall far short of what is needed to satisfy many UX requirements.

I think it’s great that there is more and more emphasis being placed on User Experience in the Drupal community. We do have a lot of challenges ahead. The good news is, as you said in your comment, there are ways to get back-end and front-end and UX designers to work productively to meet the needs of clients. I hope we can achieve this in the Drupal world.

In my experience, the technological capabilities or limitations are only one of many potential causes of poor UX. Other factors I’ve encountered are poor product management, lack of UX talent, lack of funds, etc.

My point was, that when everything is in place: proper management, talent, budget, etc. then technology can be a very limiting factor. A real-life case from a drupal5 site, long ago, for a large media-company (It was their first Drupalsite).

Two UX-experts designed the entire application. It was then tested in a UX-lab; eyetracking, stories, the whole shazam. A great graduation for one student (one of the UX-experts) guided by some professor in UX. They came up with even better designs, wireframes, mockups, proof of concepts. We then had this SEO-optimised as well and another graduate combined the two results and came up with something that, in theory was the best UX/SEO-optimised thing ever.

Enter Drupal. Enter me. We developed genormous amount of modules just to get even close to 80% of the advise in these reports. We hacked core. Added more modules. Themed nearly every thinkable theme()-function. The result was mediocre. It was passed trough another UX-lab-test. And the outcome was nearly the same as we knew it would be: all the things we could not implement, because Drupal thought different about them, got an advice "to be changed".

In the end, a year+ later, we rebuilt the entire site without UX-experts, SEO-experts and just went with what we called "the Way Drupal Does It". Saved lots of money, SEO, was so-so, UX was alright-ish and the site was a lot less struggle and fight to get out.

What I learned: that working this way: thinking up The Perfect Site, requires a tool that has no "ideas" about how it wants to do stuff. I,E. a proper, unbiased, framework.

This is what you call functionality-over-user-experience. I think we (developers) recognise this as being wrong. But we (developers) also have to remain realisitic and point out where the flexibility of the used tool ends. i.e. we often have to tell the UX-guys "sorry, but that is not easy/impossible" in Drupal.

You mention Drupal's FAPI. I raise you the lack of any proper State Machine in Drupal, a technical thing you need to build actual wizards, and flows-of-forms. It is not the "technical merits" of that FAPI that bring tension between a developer and a UXer, it is the lack of proper, realistic, architecture and functionality in that FAPI that make 80% of the Drupals forms you build, suck.

You mention t(), I raise you a proper, tree-based, context-aware *localisation* system. Simplest explained with an example: t("registration.messages.thank-you"); but in reality obviously a lot more advanced and detailed.

There really are good solutions for most of the UX-problems that you say cause tension, due to "technical limits"; they are just not there in Drupal (or Joomla!, or, yes, even Wordpress).

What I learned: that working this way: thinking up The Perfect Site, requires a tool that has no "ideas" about how it wants to do stuff. I,E. a proper, unbiased, framework.

There is always a trade-off when using prefabricated components - no matter if you are constructing an office building or a web application.

They (can) offer an advantage on the functionality/cost ratio that comes at the price of exact fit. The good: you dont have to build the core. The bad: you have little say in how the core works.

If you are willing to sacrifice the "perfect solution" (be it in terms of UX or tech) for speed and production cost and(!) the requirments are so that Drupal, with moderate tweaks, is suitable - it can be a great pick. If it does not work for your requirments, bending Drupal is probably a bad idea. It'll still end up not being the ideal solution and will have caused high cost and frustration in the process.

In that way, Drupal is maybe a closer friend to those making budgets than those crafting the code.

Well said.
If some one has the budget to build out the exact UX and UI they invision then they could spend that money on overriding whatever specific, Drupal native functionality needs overridden, OR they can pay to build it out from scratch on any language of their choice.
In the early days we saw Drupal adoption because it was "free." As time went on we saw Drupal adoption because Drupal was "powerful."
Those who have boldly stated the UX and UI issues of Drupal have also stated that no other CMS has solved that issue.
At the end of the day we are left with [what I see as] the clear conclusion that when an organization embarks down the Drupal road, they're going to benefit from the tremendous volume of code and functionality that some one else built AND the organization will have immense control over their content and the site functionality.
This sounds like a "WIN" to me. ;-)

I bought a Drupal 6 book and tried to get a site working to match clean simple ones that I had already created from Perl, C# or PHP. I ran into functions whose original purpose had apparently been redirected, so that the names didn't match well with their purpose anymore. I ran into structures that were apparently designed for one particular effect, but were not good for general purpose use, or involved a deep mess of re-interpreted code. Drupal is a mess that it doesn't need to be and shouldn't be for the general purposes to which it is put. And, because of the backward compatibility issue, it is essentially impossible to fix, and isn't getting any better with each release. As a programmer, I like things that are clean, logical and efficient. This makes Drupal unpleasant for me, and not something I would aspire to giving much of my energy. Unfortunately, because of its growth into complexity, which would be unnecessary if it was properly redesigned from the ground up, it takes a lot of energy to work with Drupal for anything that does not already fit into the available templates. The demise of Drupal would not make me sad. As a related side note, the rise of SharePoint (see other comments about it) makes me very sad. By the way, I like Yii, which I have decided to use for the near future.

Sorgfeit...
You "ran into functions..." What were you doing with functions? Which functions did you run into?
Were you trying to audit the code and alter it or were you trying to build a website the way the book recommended? I know of no book that tells you to pour through the core code and asess the naming conventions and trace their history.
If you're referring to a Drupal 6 module development book like the one authored by my friend Matt Butcher released in May of 2008, then again I can assure you that that book reveals no issues with legacy named functions. The names of our functions are not a complaint i hear from people.
I DO hear complaints about the predominance of PROCEDURAL code vs OO code. I do hear complaints that documentation is lacking or not up to date for newer versions.
I'll be the first to tell you that Drupal itself can turn off plenty of developers. We are continually doing housekeeping and making intentional efforts to make our own lives easier not to mention making it more attractive to potential new recruits.
But the experience you just described is a 1st for me.
The question in this interview was:
"What's holding back mainstream Drupal adoption?"
The answer is NOT legacy named functions, or "structures that were apparently designed for one particular effect, but were not good for general purpose use" , or problems that are impossible to fix because of backwards incompatibility.
We [as in Drupal] have our demons, but I have to believe that the lens you were looking through was very smudgy. I don't expect you to give it a 2nd shot. Just the same way that I'm never looking at EZ-Publish with XSLT ever again. I don't like it and I don't want to use it.
Drupal is doing extraordinarily well and I respect your right to not like it and do something else.
;-)

It was a year ago, I forgot the details. Maybe they weren't functions, but objects. In any case, they didn't all make sense to me and I could not make a page to match what I had already done in other ways. The available templates did not fit, so I tried to customize the page directly. I haven't totally given up, just decided to do other work for a while.

The 4+ years I have been a member of the community I have seen it having an amazing, and accelerating, growth. At the same time is has also become a much familiar name and player for the general public. Both the public and private sector is aware of its existence and are often placing Drupal at the top of their list of potentials when shopping around.

So, instead of "complaining" about the lack of talent, we need to look at it for what it is. A result of the increasing demand for Drupal and an opportunity for new talent to make a living out of it.

For me all this is very positive as it shows that Drupal will be around for years to come and thus is safe for everyone to bet their future on.

The real challenges the community has is how we handle the long term growth of Drupal and stop looking so much for short term fixes. Everyone knows the Drupal learning curve is very steep. The only way to fix that is to look long term and what is needed to be done to get there.

At DrupalCon in Munich I heard over and over Drupal 8 Core Initiative leads talking about how hard it is for them to get needed resources, funding just one part, to really make their initiative as ready as possible before feature/code freeze. Looking at how much money the Drupal ecosystem consists of, what they need is almost to be considered as coffee money.

So, how do we solve the problem of funding the much needed long term development of Drupal? If we find the answer to that, a lot will become much easier for all of us.

I spotted that problem, too, Thomas. I have this idea floating around in the back of my head that the Drupal Association could help here. What if there were a central place people and companies could donate to and Dries (with initiative leads or others) could spread that money around as needed? Then we might be able to get the important, but less "sexy" initiatives done faster and better. The amount of effort some of the current initiative leads have had to put in to get funding and resources has been painful to watch. They should be concentrating on making Drupal better, not project managing how to make it possible to make Drupal better, if you see what I mean ...

Doug... Thanks for the Drupal Intro training. I live what Drupal has to offer right out the box versus other CMS. I will be suggesting this for websites that will benefit from it's functionality. Thanks agina.

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat.

Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Shadowman logo are trademarks of Red Hat, Inc., registered in the United States and other countries.