Drupal has come a long way in the last fifteen years, with public sector agents acting as enthusiastic early adopters. From Howard Dean’s 2004 campaign, to the launch of the White House site in 2009, to the Department of Interior's Drupal-based platform going live this year - Drupal has become a powerful and popular tool in the public sector.
At Phase2 we’ve been involved with Drupal and government for a long time. We've worked with federal agencies as well as state and local governments, all of which have asked some variation of the same question: "Can we build it with Drupal?"
I decided to answer this question in a recent talk at Drupal GovCon, and I'll elaborate a bit more in this blog series. This post will focus on what happens BEFORE a project gets started (basically, settling on a platform, architecture, and development plan). In part 2 I'll help you decide if you should build with Drupal, and in part 3 I'll review how to get ready for development.
Yes! Of course you can build it with Drupal!
That's an easy answer.
Drupal has already proven its flexibility, security, and extensibility qualifying it for a wide array of projects:
- High-traffic, high-security, high-profile sites like the White House and We the People sites
- Multisite platforms at the state and local government level (most recently, the State of North Carolina)
- Templated site-building platforms for institutions like the House of Representatives
The Drupal Groups page on sites in government has more than 1800 sites listed. Although some of these are stand-alone sites, many are platforms managing multiple Drupal sites through a variety of methods. There are even government-specific distributions:
If these distributions do not fit an agency's needs, it can extend them or build its own platform from scratch. Drupal can use third-party libraries, use web services APIs to integrate with external datasources, and bridge the gap to external systems like Alfresco. You can even use Drupal with Sharepoint!
Don’t let perfect be the enemy of good
I’ve been working with Drupal for ten years, and first encountered it on a project for a government client. I had been working at a government association for a number of years building out their homebrew PHP CMS, but the CMS I had written had become increasingly hard to maintain, extend, document, and debug. After all, only one guy was maintaining it - me.
When I discovered Drupal, I was amazed to find an open source project that already did many of the things I previously had to build myself - user management, flexible content types, abstracted theming layers, tagging, access controlled content… Plus, there was this huge community supporting it. I didn’t need to build everything!
Drupal more than met the basic requirements of what I needed it to do for my project. I figured that I could just customize it as needed to fit the rest of the requirements.
What could go wrong?
Plenty, as it turned out. My project did not go well.
The problem wasn’t with Drupal. I had looked at the breadth of the functionality available in the contributed module library, at the robust developer community, and at the extensibility of the underlying framework, and I had assumed that I could make Drupal do what I wanted it to do.
I should have started with Drupal, working in conjunction with its core strengths and adjusting my requirements accordingly. If you are going to use Drupal, you need to understand what its strengths are, what its architecture demands, and the unique effects that it has on planning and running a project.
If you want to succeed with Drupal, you have to be willing to change. You have to be willing to adapt your internal processes, your relationship to your software, and the way you think about your mission. But you should be changing, anyway - organizations need to evolve to meet new challenges, and frankly one of the great strengths of Drupal is that it can evolve with you.
So yes, you can build it with Drupal. But... should you? Stay tuned for part 2.