Over the last several months -- especially as Drupal 4.7's beta period has dragged on -- more and more people in the community have weighed in on the platform's direction, the growing pains it is facing, and the best course for the future. I'm no different -- I'll put my two bits in here.

It's obvious that the last year have been big for Drupal. High-profile web sites rolling out Drupal based designs, coverage on tech sites like Slashdot and Digg, funding from Google, thousands of dollars in fund raising, mentions in The Economist, and dozens of thousands of sites now answering the 'are you running Drupal?' question positively. It has been a smashup success of a year and I feel grateful that I've been here in the community (though only visibly for the last six months or so) to witness it.

With that success, though, comes a lot of pressure. Until this point, Drupal has been (mostly) programmers and hobbyists, or 'true believers' who decided to base their web work consulting on the framework. Now, more and more newcomers are joining the fray. The post count on the Drupal.org discussion forums is climbing in a nice logarithmic curve, and every day there's a little more friction between hardcore devs working on building great software, and end-users who want a turnkey web app.

There's always been resistance to subdividing the Drupal community into 'groups.' Beyond 'people who contribute code and those who don't', everyone is lumped into the same crowd. I think, though, that the time has come to identify three key groups of Drupal users, and address them individually on Drupal.org.

First, there are software developers. Many want to build a site of their own, or have a programmerly itch to scratch and are hunting for a web framework they can use as a jumping-off point. These people want to know about APIs, the framework philosophy, and other under-the-hood stuff.

Second, there are site builders. They're usually experienced webmasters or consultants who need to build a custom content-driven site, and recognize the foolishness of 'rolling their own.' They're most interested in tying contrib modules together, putting together custom themes, and how well the whole mess scales once their client starts pounding on it. Experience levels can vary a lot in this group, but most are savvy folks who are drawn to Drupal's flexible module system and content organization tools.

Finally, there are task-focused users. These people want to set up an art potfolio, or a blog with software downloads, a web site for their church, or a site for their fledgling web comic. Sometimes, they're tech-savvy web geeks who want something cooler than Bloger for their personal home page. Other times, they're small business owners who want to sell pottery but don't know HTML from a ham sandwich. They don't really care about the details as long as it gets done, and gets done well.

These three groups of people are all important to the Drupal community. They ARE the Drupal community. But their needs, their experiences, and their frustrations are all very very different. Trying to fill all three sets of needs with a single solution will always be very, very problematic. Drupal is probably best suited for the first two groups right now -- its emphasis on Lego-style site construction ensures most sites will need customization, tweaks, and third party addons. CivicSpace, with its streamlined installer and bundle of pre-installed modules, is great for users in the third group who want to set up community oriented sites for nonprofit and political groups. The now-defunct Drupal4Bloggers is another great example, though it required hacks to Drupal's core that made it tricky to support.

Others have blogged about the idea of streamlining Drupal's core even more than it already is, and I'm in favor of it. Stripping out many of the current 'core' modules like Book, Forums, Blog, and so on would leave us with a pure 'developer core' that emphasises APIs and framework development. Helping site builders with information on combining modules and themes to create a 'recipe' for their site leverages Drupal's strengths. For users who want a turnkey solution for a site, packaged distro's of modules and themes could be bundled up to provide focused sets of features, customized interfaces to common admin tasks, and so on. There's nothing, for example, that would keep us from offering the 'extra' modules Drupal currently includes as a special 'Drupal Classic' dristro.

As we in the Drupal community move forward, I think that managing expectations for each group, pointing them to contextually helpful resources, and admitting when Drupal isn't yet ready for their needs, is extremely important.In my dream world, Drupal would have a splash screen of sorts, channeling them in the right direction before they get swamped in newbie questions, theming tutorials, or geeky arguments about optimizing tree sorting algorithms that really belong to another group entirely.

This doesn't mean "splitting" Drupal's community. Those three groups of users will have overlap, obviously, and there's no reason they can't all coexist on the same site using the same resources. It's more about how we think of Drupal, and how we approach it.

Over the last year or so Drupal has gone through some growing pains. As more new users have poked their heads into the Drupal-tent to check things out, the long-simmering conflict between 'Drupal as a very customizable CMS' and 'Drupal as a framework for web-CMS developers' has become more apparent.

Developers are frustrated by the addition of features to Drupal Core that only appeal to end-users, and 'bloat' the underlying engine. Site admins looking for a tool to run, say, a forum, are frustrated by the emphasis on APIs and hooks rather than actual solutions in Core.

Ber Kessels is one of the 'inner circle' of Drupal developers by virtue of his contributions to the system and the level of activity and involvement in the system's ongoing development. He's recently started blogging about his experiences tinkering with Ruby On Rails, and what Drupal could look like if it transformed into a similar developer-oriented framework. Obviously, the 'core' Drupal build would stop being useful for Joe Schmoe looking to set up a web site. Instead, he'd use task-specific Drupal distribution that rolls together Core, appropriate contrib modules, themes, and whatever glue is necessary to make them work nicely together.

If that approach were taken, what should be part of the Drupal Core? Here's my stab at a list.

block.module
filter.module
node.module
page.module
path.module
search.module
statistics.module
system.module
taxonomy.module
user.module

These modules are a rough approxomation of what Drupal Core has enabled when freshly installed. Modules that cater only to multi-user community sites (blog.module, tracker.module, forum.module, and so on), and modules that cater to bloggy conventions (comment.module ping.module, and archive.module) have also gone poof. Throttle.module? Better to put it in a collection of modules and tools for high-traffic sites. Aggregator module? It's cool, but core doesn't need it. Same with Blogapi, Book.module, and so on. Page.module stays because (I suppose) it would be nice to have SOME default node-type, and the standard 'page' concept is pretty universal. It might be tossed, though.

Themes? Bluemarine, with its CSS file stripped down to remove the reams and reams of cruft necessary to support all the older core modules. Other modules would be responsible for including their own CSS, rather than depending on core. For developers, it might make sense to bundle dba.module and devel.module with the core distribution. Those are already must-haves for anyone working on the development side of a Drupal site, though most application-specific distributions wouldn't include them.

What's the end result? A relatively vanilla-looking web site engine with a lot of APIs and not a lot of UI. In my next post, I'll toss around ideas on how the rest of the modules currently in core would find a home, and what third-party contrib modules would complement them in various application-specific Drupal Distributions.