Drupal 4.7 and the Case for Open-Source Content Management

The question arrives with a skeptical eyebrow in most IT committee meetings: can we really trust free software with our website? It is a fair challenge. Drupal 4.7, released May 1 after a long development slog, is a good occasion to answer it properly.

What 4.7 actually ships

The headline is a rebuilt form system. That sounds like plumbing, and it is. But it is the plumbing that lets developers build admin screens consistently and securely, and Drupal lives or dies by its add-on modules. Free tagging arrives too, the labeling pattern that sites like Flickr made familiar. The installer and admin screens take real steps forward.

What the release signals matters more than any feature. Drupal’s community shipped a major improvement even though it broke compatibility, because the architecture needed it. Commercial vendors put off decisions like that for years because they complicate sales. Open-source projects can afford to be honest about their own problems. That honesty is worth something when you are picking a foundation.

The license fee was never the interesting number

Commercial web content management in 2006 runs from tens of thousands of dollars to several hundred thousand at the top tier, before anyone builds anything. Open source removes that line entirely. That is the part everyone notices, and the part that matters least. ‘Free like a puppy,’ goes the joke, and the joke is fair.

The comparison that decides real value is five-year total cost, and it has more rows than a license invoice.

• Implementation costs about the same either way. Someone experienced has to model your content, build your templates, and train your team.

• Customization favors open source. When the software does almost what you need, your developer changes it. With a closed product, you file a request and wait.

• Upgrades cost labor with open source, but there is no toll booth. Commercial upgrades often carry new licensing fees.

• Exit is the quiet one. Your Drupal site’s code and content are yours, portable to any host, fixable by any qualified shop. A proprietary platform’s exit costs are, in practice, a way of keeping you.

Security, support, and staying power

The trust objection usually lands on three worries, so let’s take them one at a time.

Security. The instinct says visible source code means visible holes. History says the opposite. Openness means a global community finds and fixes flaws that a vendor would schedule for next year. Drupal has a formal security team. What actually gets open-source sites hacked is skipping updates, and that is a management problem, not a licensing one.

Support. ‘Who do we call?’ has a better answer than the fear suggests. You call the same kind of firm you would hire to implement a commercial product. You also get forums, documentation, and a community that answers questions at 11 p.m. because someone in another time zone is awake. You lose the contractual throat to choke. You gain a market of service providers competing for your business, which is its own kind of accountability.

Staying power. Commercial vendors get bought, and their products get shut down. An open-source platform can lose steam too, but it cannot be discontinued out from under you by an acquirer’s product strategy. The code stays. Your options stay.

What a good implementation involves

A Drupal build worth paying for starts with content modeling. What kinds of things does your site contain? Programs, people, events, publications? How do they relate? That thinking comes before anyone touches a design, and Drupal is built for it. This is where it separates from tools that treat every page as a blob of text.

Then comes module selection. The add-on ecosystem is Drupal’s superpower and its junk drawer, and a practiced hand knows which hundred of the thousands are worth trusting. Then design, then setting up who can publish what.

Notice what is not on that list: writing an application from scratch. The savings come from assembling and configuring instead of custom-coding. When open-source projects go wrong, it is usually because someone custom-coded what should have been configured. The result is a one-off system wearing a Drupal costume, and it cannot be upgraded.

The rest of the field

Drupal is not the only credible answer. WordPress, technically blogging software with growing ambitions, is the better pick when the need is simple publishing run by a small team who will love its friendlier editing. Joomla has a big community but makes structured content harder. Our shorthand: WordPress for publishing simplicity, Drupal for structured complexity. Look hard at your actual content before choosing.

The honest catch

Here is the part the fans skip. Open source shifts cost from licensing to expertise, and the expertise is not optional. A badly built open-source site is every bit as expensive as a badly built commercial one. The platform being free does not make the project cheap. It makes the cost honest: you pay for skill, which is where the value was all along.

For nonprofits and mid-sized organizations priced out of the enterprise tier, Drupal has become the sensible default, as long as you budget for experienced help. Run the five-year comparison with all the rows filled in. We keep finding that the license fee, the number that dominates the meeting, is the smallest number on the sheet.