I’ve been working in the Drupal ecosystem for a while now, and I’ve noticed there’s a predictable life cycle of the Drupal developer. We all know the stages. Drupal developers start out hacking away at the theme layer. Then, they start writing their own modules. Still others start contributing those modules back to the community.

Eventually, those who survive the earlier stages grow to be good Drupal citizens, working as professionals and contributing back to the community in a meaningful, productive way. As critical as this stage is for the well-being of all developers, to achieve it requires self-awareness and discipline.

We were all beginners once

Beginners first approach Drupal like a closed box. It’s not something to be tweaked or hacked. Instead, they scour Drupal.org looking for modules they might need. They enable modules indiscriminately. The complexity of their projects increase exponentially as they install more and more modules, and they begin to complain about Drupal’s “learning curve.” Their attention may turn to aesthetics: “Hey, my site looks pretty ugly with all of these blocks and tabs on the page!” Or their attention turns to a limitation of one module or another: “I hate how limited Views is! Ugh, seriously, how hard is it to create a view of related nodes?”

At this point, the beginner starts to peel away the outer layer of the closed box. They search Drupal.org for example code, and begin making the beginner’s favorite dish: copy pasta. They start editing node.tpl.php and template.php. Their first theme may or may not be named zen_starterkit. They find a thread that says to throw some PHP in a Views argument, maybe a node_load(arg(1)) to get an array of terms. They’re well-intentioned but they lack the understanding of what it is they’re copying and what it is they’re overriding. They’re ignorant of the “Drupal way.”

Thing is, Drupal beginners are great people. We need more of them, especially if we’re to sustain our ecosystem. Yes, we need them to learn more, and learn more faster, but they won’t get to where we need them without our help. We must mentor our beginners as best we can, within Drupal.org issue queues and IRC chat rooms, and when they’re our co-workers and subordinates.

Don’t lie to yourself, either: we were all beginners once.

Intermediate developers are fearless

Assuming the beginner is given a chance to grow in a healthy environment, the natural progression is to become an intermediate Drupal developer.

At this stage, the developer approaches Drupal like a blank piece of paper. “A robust system of hooks!” they say with enthusiasm. “I shall use these to make modules for myself!” They’re a child playing with Legos for the first time. There is an overwhelming temptation to build anything and everything with these new building blocks — as they understand them. They’re fearless.

Unfortunately, this means they’re going to write a module when it’s not strictly necessary. They’re going to write a module that changes the page title for node pages. They’re going to write a module that adds some metatags to the <head />. They’re going to write a module that sends an email to a mailing list every time a node is saved or updated.

This is arguably the stage most dangerous to the rest of us. They could be at this stage here indefinitely, masquerading as professional developers. They could do a lot of damage when left unsupervised on a project. And we’re the ones that are inevitably tasked with reviewing their work and fixing it. (I shudder to think, what if we made the mistake of agreeing to a fixed fee before discovering their code soup?)

But there is hope, because there are some in this group who have raw enthusiasm for Drupal as a platform. They want to learn more, write more code, and build with Drupal more effectively. All they’re lacking is the holistic understanding of the community at large, how it all works together and how to leverage existing work to avoid reengineering the wheel1.

Advanced developers call it “dee dot oh”

The intermediate developer graduates to the next stage, advanced Drupal developer, when they recognize that Drupal isn’t a blank piece of paper, but a rich tapestry. While the thrill of writing a bespoke module remains, there is now also wisdom and the knowledge that there’s no sense in writing their own auto_nodetitle.

Advanced Drupal developers recognize that there’s a larger community of developers out there, so before starting with a blank .module file, they’re going to first check for pre-existing modules and APIs that they can leverage. They’re going to pay attention to best practices and security concerns — they know better than to output text without running it through check_plain(). They might even know to leverage things like the Cache API and the Batch API to be more effective and efficient. They’ve written Views handlers, Panels plugins, and Context reactions.

At first glance, you might mistake this developer as an expert. In a lot of ways, you’d be right. This developer went to Drupalcon, maybe even sat in on a core conversation, or attended a BoF or two. They call Drupal.org “dee dot oh.” They also participate in local community events, and they’re almost certainly employed as a full-time Drupal developer2. This type of developer knows the core API inside and out. They might boast that they’ve been working with Drupal since 4.7, and might claim that they’ve written modules for all major releases.

While all of these observations are correct, don’t put this kind of developer on a pedestal. They are far from perfect.

Let’s say they find a contrib module out in the wild that suits their needs. They enable it and find out that it’s buggy, or it doesn’t match their use case exactly. Or even more arbitrarily, it just doesn’t fit their expectations for how it “should be” implemented. Their next thought is, “oh well, I guess I’ll have to write my own!” They expect perfection — or at least likemindedness — from all contrib module authors, and when faced with the alternative, they choose to eschew the community and write their own solution.

The all-or-nothing position is dangerous for a Drupal developer because that implies that skepticism about the ability for existing modules to meet expectations is their default position. The developer works within a bubble even while participating in the community. Their position boils down to “I trust my implementation choices above all else.” They dismiss the intellectual capital invested by the maintainers as inconsequential.

From a practical standpoint, there’s a laundry list of reasons not to do this. They’re going to re-introduce bugs or security flaws that others have already encountered and fixed in the so-considered inferior solution. They’re going to leave out features that they might want down the road, not out of malice but because they simply didn’t think of them.

From a social standpoint, these developers will never have a chance to discover other developers are in fact likeminded. After all, it’s not unprecedented that a contrib module would have a complete rewrite in the -dev branch for the exact purpose of trying out a new design.

Working in a bubble is a terribly narrow-minded approach to open-source software development in general, but it is a cancer within the Drupal community because you can get away with it. There is no such thing as the “module police.” One developer can easily fork another developer’s module to add support for some feature they need on that one project, and nobody would ever know. Sure, maybe someday another developer will be asked to help out on that project and find the forked module, but even then there’s no guarantee that the changes will be merged back in to the community. It’s selfish, plain and simple — and completely unenforceable.

Good Drupal citizens police themselves

Self-policing is what allows the advanced developer to become a good Drupal citizen. They stop working in a bubble. They begin to contribute their efforts back to the community in such a way that acknowledges existing work rather than dismissing it.

They’re not afraid to submit a patch for a new feature on an existing module. They wait for their idea to be reviewed & tested by the community (RTBC), and they keep an open mind about their approach when it needs work. If the patch is rejected by the module maintainer, they find a constructive workaround.

When the good Drupal citizen writes a new module, it is to compliment existing APIs or fill legitimate gaps. They don’t make assumptions about use cases. They write unitasker modules that don’t make assumptions about the theme layer or menu structure. They recognize that some sites will be built with Context and others Panels, and yet others will use core blocks and node templates.

What they don’t do is work in a bubble. Anything they do is done with the assumption that it will be shared with the community in some way.

The community has a right to know what you’ve done and how you’ve done it. Whether it’s shared by submitting a patch, contributing to a 10-page comment thread in an issue queue, writing a blog post, or adding a new module on Drupal.org, good Drupal citizens contribute back. It’s open, it’s transparent. If you’re a PHP genius, the world deserves to know; if you’re barely competent, the world deserves to know that, too. If you won’t stand by your work, then we don’t want you in our community. Stop believing that you’re the only one who will want that feature you’re developing. Stop yourself from thinking that your implementation choices are without flaw.

We all benefit from participation

The Drupal community is lacking a formal peer review process. Participation does not require certification. There are no classes to take. You can start as a beginner and work your way through that intermediate stage of knowing just enough to get the job done, and you can stay employed and do a decent-enough job to never need to grow beyond that.

The measure of a good Drupal citizen, then, is self-policing. Before you fork that module for your own needs, consider how you can integrate your needs with the existing work and allow your Drupal developer peers to review it. Share your expertise with beginners. Encourage your intermediate co-workers to learn new APIs. Be the mentor that you never had because you started with Drupal back when it was just you and Dries.

Bottom line, recognize that we all benefit from your contribution, however big or small, and that you benefit from our collective expertise. No single developer knows more about Drupal than the community does, and yet, there wouldn’t be a community if people didn’t share their knowledge with others.

  1. I promised myself I wouldn’t use that phrase. Damn.

  2. … unless they’re (a) completely unaware of the demand for developers, or (b) completely un-hireable for some reason unrelated to their knowledge of Drupal. Good grief, they should at least be part-time contractors. There’s gold in them there hills!