Why Drupal?
Lately I've been asked in several different ways what essentially boils down to one question: "Why Drupal?" The subtext of the question is: "Why not some other system such as [insert your favorite CMS here]?" Allow me to explain…
Background
If you are familiar with the history of my site, you'll know that once upon a time it ran on Textpattern, a designer friendly content management system that sports a templating system akin to the syntax of XHTML. I was so enamored with TXP, as the cool kids call it, that I even pushed forth an effort to write a book about it. Several coauthors and I labored on what became Textpattern Solutions.
Again, depending on how long you've known me, you might also recall that last year I built a proof of concept module for the ExpressionEngine CMS to consume the Fellowship One API. I even took the time to make a brief screencast.
Like many designers, I was impressed with the EE 2.0 admin interface demo'd at the SXSW conference a few years ago. At the time, the core version of EE was free for nonprofits. It seemed like a good system to encourage for church use. We even chose EE to power our Fellowship Tech Developer site.
Ironically, after presenting my EE module talk at the Dynamic Church Conference in 2009, the first responses were basically "What about Drupal?" As it turns out, many of our church customers are big proponents of open source.
At the time, I knew next to nothing about Drupal, but this spurred my curiosity. I knew that it could power large sites, and that the Geeks & God podcast guys loved it, but I didn't really know much more than that. Coincidentally, 2009 was when interest began to pick up in the Drupal community around using 960.gs as a base for building themes. I was encouraged by Matt Farina to speak at the first ever Design 4 Drupal event in Boston, hosted by MIT. I ended up co-presenting with Todd Neinkerk of the Austin based agency Four Kitchens - video here.
It was there at the MIT Stata Center that I was immersed in the culture of Drupal for three days, and I began to see what all the fuss was about. The designers and developers I met were highly collaborative, eager to both teach and learn.
It should be noted that I have also attended a TYPO3 conference in Dallas, and found it to have a unique culture all its own. My friend Ron Hall is a huge fan of TYPO3, and helps to organize their North American conference. For whatever reason, TYPO3 is decidedly more popular in Europe, particularly in Germany.
Deep Dive
I have never been the type of person to purchase things on a whim. If anything, I tend to research products to a fault, spending weeks or months reading up on a particular topic. If memory serves, I have read four books on Drupal, three on EE and/or CodeIgniter, and two on TYPO3. Those books are…
Drupal
ExpressionEngine
TYPO3
Bonus: I also have on my bookshelf The Definitive Guide to Django.
Okay, maybe I am the type of person who purchases books on a whim!
Why Change?
Textpattern
So anyway, believe me when I say I like to have an informed opinion. The big question is: What made me leave Textpattern, after pouring in so many hours learning the system, and even more writing a book? I can say with all honesty, it was a "It's not you, it's me" situation. At some point, I realized that I had sort of tapped out the upper limits of what I knew how to build with Textpattern.
ExpressionEngine
So I began looking elsewhere. First I checked out EE, learning the ins and outs of how it handles layouts and modules. The way it works is not unlike how TXP does templates. I was intrigued by that possibility, coupled with things like their 1st party developed forum and member management modules.
But as we fleshed out the FT Developer site, I realized these modules (in 1.6.x) did not work like the rest of the system. Instead, it involved hacking away at heredoc strings. Elegance lost, if one was to build sites beyond what TXP could handle. Also, EE sent down headers to the browser before module code was output.
This meant we had a heck of a time getting OAuth to work. This is why no further development was done on our proof of concept EE module. That, and the change in EE 2.0's licensing that does not allow for nonprofit usage free of charge.
Again, none of this is a fault of the CMS. EE is fine for what it's meant to do.
TYPO3
Unlike TXP or EE, TYPO3 really shines as an application development platform and CMS hybrid. But it can be somewhat daunting just to get installed and configured correctly. Thankfully, there are efforts like the Web Empowered Church project helping to ease the learning curve, by providing users with guidance and starter templates. For me, what scared me off about TYPO3 was having to learn yet another pseudo syntax after having learned EE and TXP's respective tags.
I came across this article…
— TYPO3 Wizard: Copyright Notice with Current Year
I remembered thinking: That's a lot of steps. In PHP, it's just one line…
<?= date('Y') ?>It's ironic that I was initially drawn to Textpattern because of it's pseudo syntax, and because PHP seemed intimidating. Now I feel like an old man who can't be bothered to learn a faux language, preferring instead to write straight PHP.
At this point in my career, investing time to learn something that only works within the confines of a particular CMS could be likened to learning Klingon. Yes, technically it's a language. Yes, there are extremely zealous groups of people that are fluent in it. But outside of that "universe," all that knowledge is no longer applicable. It's tantamount to memorizing answers in Trivial Pursuit.
Learning PHP is like learning Spanish. Or English. Or some widely spoken language that will benefit you in more than just niche circles. PHP on the web is like white paint. It's everywhere. It might not be as pretty as Ruby or as puristic as Python, but as a developer it is worth having at least a working knowledge of PHP.
Even 37signals, creators of Rails, used PHP for their book Getting Real.
What about WP?
I see this old debate flare up from time to time. Some say…
"WordPress is not a CMS. It's just a blogging tool."
Others rebut…
"Blog posts are content. WP manages blog posts. Ergo, it's a CMS."
Well, call it whatever you want but WordPress is not for me. Yes I know that it's wildly popular. A quick comparison on Google Trends shows that the number of searches for WordPress easily outnumber those for Drupal related topics, by a staggering 10-to-3 ratio. So then, why not WordPress? Am I leaving money on the table by not listing WP theme development in my repertoire? Yes and no.
Commercial blog theme design is a saturated market for good reason. It's not terribly difficult. In fact, I'd venture to say if I were in that line of work, I'd find it downright monotonous. While there is no limit to the level of visual detail one can incorporate into a blog design, the functionality only goes so far.
Blogging goes like this: Write a post. Upload a photo. Maybe a video. Or do a podcast. Let people comment on any or all of these content entries. Rinse, repeat. As designers, we've have become quite adept at cranking out themes to accomodate these basic user behaviors. This is where WordPress excels.
In fact, WP is so tailored to blogging that I liken it to a yacht. It is streamlined for that particular task. It allows people with varying levels of technical savvy to get a site installed and online posthaste. Or, via WordPress.com you can skip the install process altogether and opt for a hosted blog. While a sharp focus on blogging ensures that the famed "5 minute install" will continue to be a selling point, it also means that WP at its core isn't meant for big sites.
Note: I mean "big" from an information architecture standpoint. I realize that with proper caching plugins and a good hosting setup WP can power sites with tons of traffic and an abundance of blog posts. While that's all well and good, I'm interested in building sites and/or web applications that have both breadth and depth.
Continuing with the WP as yacht analogy, I'd say Drupal is an aircraft carrier. A ship that big can carry fighters, bombers, supplies, or even refugees in a humanitarian relief effort. What I see far too often is people trying to strap things onto their yachts and then wondering why they run into difficulties. Custom fields do not make for an ideal CMS workflow. I learned this with Textpattern.
Scope
At it's core, Drupal is built for scalability. You can use it like I am on this site: humble blog, about section with sub-sections, portfolio, contact page, etc. It is also versatile enough to power sites like: Department of Commerce, Duke University, The Economist, Fast Company, UN Global Pulse, and The White House.
An extensive list of high profile Drupal sites is maintained by Dries Buytaert, creator of Drupal. While I'm on the topic: Dries is an extremely smart guy. He holds bachelor, master, and doctoral degrees in computer science. He cofounded Acquia, which focuses on providing enterprise level infrastructure and support for large Drupal sites. They are for Drupal what Red Hat is to Linux.
My reasoning for learning Drupal, when TXP was meeting the needs of my former site just fine, is that I want to constantly be pushing myself to learn more, and to increase the capacity of what I am able to build. I'm not one to seek out complexity just for kicks, like some Bloomberg pundit. I do enjoy taking something that otherwise might be complex, and breaking it down into digestible pieces.
Or, as the saying goes…
Q: How do you eat an elephant?
A: One bite at a time!
This is something Drupal allows me to do: Create hierarchical structures of content, helping to organize things so that users are able to find them presented logically. Though I know I'm not using it to its fullest on my simple site, I have peace of mind knowing that I've invested time in a system that can grow with a client's needs. I can say with impunity: "Yeah, Drupal can do that."
I think the ability to handle large scale websites is why you see Drupal agencies that employ anywhere from a handful to several dozen people, whereas people who build custom or commercial blog templates usually operate in smaller groups or as independent freelancers. The size of site dictates the manpower.
I keep an eye on these powerhouse Drupal agencies…
I am consistently impressed to see Development Seed building robust applications such as Managing News, MapBox, and Open Atrium atop Drupal. I also listen semi regularly to the Lullabot podcast hosted by founder Jeff Robbins, sometimes referred to as the "voice of Drupal" in the community. Lullabot was one of the first agencies to offer Drupal training, even before it was in vogue. They also have an extensive library of instructional videos covering a variety of Drupal topics.
So What?
What am I trying to convince you of? Nothing really. I just figured that since I am asked Why Drupal with increasing frequency, I should probably record my thoughts. If I've convinced you to try Drupal, great. If not, that's fine too.
I used to feel a burden for my designer friends when I'd see them spinning their wheels, making yet another blog theme, for yet another client that wanted his/her blog to be the coolest thing ever. I would wonder about such friends: "Why do they paint themselves into a corner, just using a blogging tool? Don't they know it won't scale well as a CMS?" As I've grown older, and arguably wiser, I've learned not to worry about such things. Some people want to build blogs, and can make a decent living doing so. More power to 'em.
Personally, I find myself yearning for more than re-skinning the same functionality. That's partly why I love working for a company that builds web applications. I want to solve complex problems with simple solutions. When I do build sites, I want a CMS that meshes with my philosophy. For me, that means Drupal.