In presentations I usually point out that Drupal is three things:

1. A content management system: The forms you fill out, the buttons you click, and the content you work with. The stuff you interact with every day while you manage your site.
2. A content management framework: The low-level APIs that let you extend and modify Drupal to make it do everything from ratings to image galleries to your dishes.
3. A community: The thousands of documentation writers, developers, testers, support providers, designers, and evangelists from all over the world, working together to make Drupal a better platform every single day.

It's this third point I'd like to talk a little more about today, by providing some insights into the general Drupal community philosophies that guide our interactions with one another, and as a result, the growth and direction of the Drupal project as a whole.

The Drupal community has several core philosophies, some of which are documented, others of which you just kind of pick up from spending enough time watching various interactions on the forums, on issue queues, and on the mailing lists. Here's a brief guide, for the uninitiated.

Code quality is #1.

Particularly in Drupal core, but also in certain well-maintained contributed modules, every single line of code is subject to an excruciating level of peer review. Code must conform to coding standards, must be well-documented, and must be easy to follow. Did you forget the period at the end of that inline comment? It'll be slapped back down to "code needs work" faster than you can say "complete sentence."

While this sort of back-and-forth over seemingly meaningless details can frustrate both new and established contributors alike, this attention to detail is one of the things I love most about the Drupal community. The goal is to make code that was written by literally thousands of people look and act like it was written by one. This makes it easy to understand what's going on, no matter which dark corner of Drupal you're investigating. And if the key person who developed a particular subsystem of Drupal drops off the face of the planet (which does happen from time to time), we're all saved by the fact that their code didn't get into core until it was documented well enough for someone else to pick up the torch where they left off.

Keep core simple (but bring on the APIs).

Drupal's goal is to accomplish what the vast majority of sites will want (and expect) out of the box. While there are many ways one might want to handle user registration (let users register via e-mail, make them validate their e-mail address, assign a random string to their profile on registration to act as an ID code), core provides a few simple options that fulfill the needs of 90% of sites out there. If you need something more or different, you turn to add-on modules.

There's resistance to adding more knobs to twiddle and more buttons to press in Drupal core. The general consensus is that core is more than complicated enough, and should actually remove features, not add them. There's historical evidence for this: Archive module was removed in favour of Views. Moderation was removed in favour of contributed modules such as Modr8 and Revision Moderation. Drupal module was removed in favour of OpenID (ok, well that one was more of a swap than a removal). There are also people in the community who are pushing for modules such as Forum, Poll, and Blog to be removed, although there's contention around taking things this far.

Before that makes you run screaming over to PHP-Nuke, it's worth pointing out that Drupal covers its bases by providing a bunch of robust APIs that let both custom and contributed modules extend Drupal to achieve whatever crazy use cases people can envision. Add new form fields to your site's content. Add custom validation routines to the user registration form. Make a block that shows random bowling scores. Drupal lets you do it all through its hook system, aka the "content management framework" aspect of Drupal. And developers are hard at work all the time adding additional hooks so that Drupal can be extended in even more ways.

The drop is always moving.

Drupal core developers are encouraged to constantly innovate new and better ways of extending the platform each release, at the expense of backwards-compatibility. This approach means that Drupal carries little to no “baggage” with it from release to release, in the form of legacy code. The consequence, however, is that modules and themes that worked under a previous version of Drupal must be “ported” to work with the current version; Drupal 5.x modules will not work with Drupal 6.x, and vice-versa. However, an upgrade path is always available which will ensure that any “data” (database records, configuration settings, and so on) is brought forward from release to release when upgrading.

And not only is that drop always moving, it's moving fast! The Drupal community generally tries to get one new release of core out per year. Because only the current version of Drupal and one version previous are supported, that means most sites will end up having to upgrade every 18-24 months, unless they feel qualified to do their own security audits.

Action is gold.

Perusing the Drupal.org forums and issue queues, you’ll see there’s no shortage of people with opinions on what Drupal should be doing differently. Drupal, like many other open source communities, is a “meritocracy” do-ocracy. The folks who go beyond talk and start contributing to the project tend to get better support, have their opinions taken more seriously, rocket up the Drupal learning curve faster, and attract more Drupal clients.

It's worth pointing too out that "action" doesn't just mean code. There are a plethora of other ways to contribute, including reporting bugs, writing or fixing documentation, creating themes, submitting translations, testing and reviewing patches, creating mock-ups of how an interface can be improved, doing "issue queue housekeeping," and more. And the Drupal community in particular is one where any contribution is seen as extremely valuable -- this is not a geeks-only club.

Others?

Any other Drupal community philosophies you've picked up on out there that you'd care to share? :)

Comments on this post will automatically be closed three months from the original post date.