"Drupal as a framework and/or CMS": My POV as a contributing business owner

As the community at large wrestles with Drupal's future as both a framework and a CMS, and its usefulness or focus on the various needs of developers, themers, designers, end-users, and others, Zivtech, as an 11-person Drupal team, deals with the same questions and debates internally. Drupal has many faces, and a successful Drupal shop requires expertise in the LAMP stack, version control, design, theming, Drupal API development, jQuery development, site building, module selection, marketing, project management, training, QA and on and on. Therefore even within a single shop there are many perspectives on what Drupal is and should be, and here's one of them.

I've always seen myself as a Drupal generalist, being experienced in development, theming, jQuery, and site building. I basically learned Drupal by freelancing in it and being forced to become an expert in everything all at once (I was scared into climbing straight up a few learning cliffs with hyenas at my heels threatening to rip me back down into the soul-crushing boredom of my previous career.). Being a generalist is a good place to be now as the leader of people who do all these different types of work and tends to make me a pragmatist rather than an extremist. While some in our office fall mainly into the "Drupal as a framework" camp and others in the "Drupal as a CMS" camp, I tend to place the split between our projects, rather than Drupal itself, seeing more complex projects as primarily "framework projects" and more standard site builds as mostly "CMS projects". There's always a good bit of bleed between the two project types, and some projects start as CMS projects ("get a quick prototype going") and morph into framework projects ("and now make it super awesome"). Personally, I like both kinds of projects, and enjoy the diversity of doing work all the way across the CMS/framework and front-end/back-end spectrums. A lot of my work tends to be where front- and back-ends meet, where I write modules that work with the theme, write sql schemas for my AJAX dazzles, use Firebug to get clues from Drupal's "markup bloat" just to grok the architecture, and write bash scripts to make subthemes. And ultimately, in a lot of ways, that's where Drupal itself is, right where two extremes meet and designers and developers come together like cats and dogs in the vet's waiting room.

We have a bit of an identity struggle in Drupal in terms of mixing up the Drupal community with the Drupal development community, which is the most established, and simultaneously sending the message (perhaps accidentally) that developers are at the top of some food chain of intelligence and importance. Even for myself, I feel that pull, and tend to identify more as a developer than as a themer, site architect, site builder, educator, contributed module encyclopedia, QA person, project manager or business owner, because 'core developer' certainly seems to grant the most respect of any of those titles. In the Drupal community, you even notice that the people who get the most respect in the non-developer sub-communities are actually usually developers themselves (I'm thinking for example of Young Hahn in the design community and Addison Berry in the documentation community). These kinds of perceived hierarchies in the value of different roles is probably inevitable within any profession, but it's a prejudice we should acknowledge and move towards overcoming personally and as a group, to make sure we're respecting all types of excellence in Drupal professionals and volunteer heroes, not just in Drupal developers.

In our office, we have Justin Randell, the LAMP genius, at the developer extreme, arguing for Drupal as a framework and always trying to free us from the "clicky-clicky" world of Drupal web-based site building. He's the go-to guy for creating a new API or setting up database replication, but not the first person you'll ask for contributed module recommendations. Then at the next table we have Aaron and Steve cranking out the CMS sites at lightning speed but sometimes struggling with the "deployment problem" which we're handling currently by having everyone write update functions for configuration changes that are being pushed to production sites. It's a strange world in which the ease of Drupal configuration becomes a burden in the realm of enterprise software deployment strategies. We have clients asking for a general handbook on administering a Drupal site and tell them such a thing can't exist because Drupal is a framework. And we have designers with no knowledge of Drupal giving us final site architectures that go against Drupal's natural CMS flow, who want to pay like it's a CMS but force us into building it more as a custom framework. It's a confusing situation for everyone involved.

But I don't believe the tug-of-war between the CMS and the framework will split us in half, because it's exactly this multidimensional nature of Drupal that makes it so rich and attracts most of us to it in the first place. I think we will develop ways to smooth the schizophrenic nature of Drupal without breaking either side. For example we can work to make all the Drupal settings into exportables so that, as in the Views model, the clickers and the version control people live side by side in (near) harmony. Instead of expecting designers to understand every tendency of Drupal the CMS and possibility of Drupal the framework, we can create and share Drupal-specific style worksheets and example guides for designers to encourage them to give us style guides that reflect many of the elements that are themed in Drupal sites, instead of having them create complete mockups that inappropriately include all the site architecture and ignore more general styling. We can do a better job of marketing the concept that Drupal is a hybrid of a framework and a CMS, so that newcomers know what they're getting into and aren't mistakenly given the impression that setting up a powerful Drupal site will be like opening a Facebook account.

Who is Drupal for? There are a lot of perspectives on that question. As a contributing developer and a business owner, I can share mine. It's a framework or a complex CMS requiring expert knowledge, which my team uses to do our work, and which we train other technical people to use. It's also the basis of the CMS and UX we deliver to our clients. It is a framework to build software products to sell as a business. Unfortunately, the truth is the people whose interests we are least aligned with are the power-users/site-builders-- the folks who use Drupal as a CMS and need everything to work easily out of the box in ways that fit beginner workflows. They tend to post support and feature requests to issue queues without being able to contribute much, which can make them seem tiresome to those of us with too much on our plates. But these are the people who build the base of Drupal, and who sometimes go on to become Drupal professionals (I started out as a site builder with just some beginning php chops), or become Drupal evangelists in their organizations, bringing large projects into being. Attracting and pleasing these people is important in the big picture, but, it's not a top priority for a business like ours. I do a fair amount of giving support and writing code for these power-users, but purely out of a feeling of responsibility, and I often just don't have time for it. If my priorities are typical for contributors in Drupal businesses, it seems that efforts like Acquia Gardens and Buzzr may become the places where the majority of the Drupal 'end-users' flock.

Personally, I'm all for smallcore- I'd like to see modules like poll, aggregator, forum and php go into contrib and for core to only have the modules that 90% of us use 90% of the time. I totally support the API improvements that enhance my developer experience. But I'm also for all the UI improvements that help my clients' experience because ultimately, they don't tell me they love that wily data import I broke my brain on all week, they just love the drag and drop they got out of the box. It's mainly a framework at heart to me, with CMS polish on the outside, and that's the perspective that drives what I'd like to work toward.