Forking the community, not the code

March 1, 2006

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.