So, a few days ago Clay Johnson over at Sunlight Labs stirred up a bit of a hornet’s nest with his post entitled Content Management Systems just don’t work.
Much of the response has come from Drupal/Wordpress/[other CMS] developers, and channels a few common threads:
1. But what if you just want a blog?
2. But you get lots of stuff for “free” (forums, etc.)
3. But look at [awesome NKOTB CMS] – it solves every problem you mention!
Well, yeah. If all you actually want is a blog, then just use a blog – Clay himself points out that Sunlight uses WordPress (as does this blog). The argument is really directed at larger endeavors. If you really do just want a blog, or for that matter any specific feature that has a well-tested, well-maintained off-the-shelf implementation, then by all means just use that. But that’s not the point.
The point is that when deciding whether to: a) spend serious money in CMS customizations, or b) roll your own platform with the help of Django/Rails/[other framework], option (b) is a better choice in more situations than people think. Why? Because the decision to customize a CMS vs. building something “from scratch” is deceptive, since the “framework tax” of a CMS is more hidden than the obvious blank slate you get when working with a framework.
To use a slightly facile analogy, imagine you’re looking to build a house, and you have (because you’re really picky) very specific requirements. Let’s say that you find a house in a perfect location that’s almost what you’re looking for – you just need to add a third bedroom. In that case, adding on to the existing house might be considerably cheaper than building it from scratch.
But let’s imagine now that the house you found is actually nothing at all like the house you want, and you’ll have to raise the house on stilts, dig up the foundation, add a floor underneath, re-do all the plumbing and electricity and add an attic to fulfill your particular requirements. At that point, it’s highly likely that just building it from scratch will be cheaper than bending over backwards to reuse parts of the existing house – particularly if you can get many of the same components for free elsewhere (let’s say the neighbors are giving away perfect pre-fab kitchens that can be easily plugged in to any house).
Obviously the analogy has holes, and I’ve probably barred myself from the building industry for life, but the point stands – the cost of working within an existing product can be deceptive because the difficulties of working within its rules are less obvious than the missing parts on a blank slate.
It always looks like you’re getting all this stuff with an off-the-shelf CMS – “We won’t have to write any login code! Forums come pre-built! The widgets fidget all on their own! Hallelujah!” The trick is, though, that if you’re already having a conversation about the 10 different things you need to customize in your CMS to make it fit your workflow, there’s a good possibility that the stuff you’re getting for “free” will actually make it harder to do anything else. (And some of the pieces – like user management – are standard parts of most mainstream MVC-style frameworks as well).
Will the “anything else” be possible? Of course. Apparently there are at least two full-featured shopping cart WordPress plugins. Hell, you can implement a C compiler as a WordPress plugin. That doesn’t mean you should, and in fact implementing a C compiler as a WordPress plugin would be considerably more effort (and probably produce a messier result) than just writing the damn thing from scratch.
As with everything else, you have to assess the individual situation and make informed choices. If an off-the-shelf CMS (or other product) really fits your requirements perfectly, then of course go for it. But if you’re going to be making a substantive investment in technology, because nothing quite fits your needs and you’ve made the decision that doing X is a worthwhile effort, remember that even the “free” pieces of a CMS impose a higher “developer tax” when extending the system.