Build vs. Buy in Content Management Systems
November 25, 2003
The listserv cms-list has an interesting discussion lately on build vs. buy when it comes to content management systems. As one poster correctly noted today, build vs. buy is a simplistic way of stating the question. Most CMSs require extensive customization, and the work to make a CMS work for you needs to be thought of—at least— as a substantial extension to a given CMS technology.
I wrote a white paper about the build vs. buy question a couple of years ago, but I think it still holds up fairly well. It was written for a particular vendor (Enigma) to distribute, but most of it is neutral.
Posted by Bill Trippe at November 25, 2003 8:57 PM
Comments
Actually, I'm not convinced that there should be a strong need for customisation in many situations. Most organisations' requirements fall within one of the common "archetypes", such as "simple static website", "online documentation", "standard intranet" (etc, etc). For these common situations, it is possible to get something "off the shelf" to solve the problem, without resorting to extensive customisation.
For these cases, the challenge is to pick the *right* CMS that matches the needs of the organisation, as each CMS has a unique set of strengths and weaknesses.
Beyond that, there will always be situations that are unique or complex, and require customisation. No argument there...
Posted by James Robertson at November 28, 2003 7:41 PMPost a comment
Comments for this entry have been closed.
Too bad cms-list's archives aren't up-to-date, I can't really look at the discussion. I subscribed to that list for a while, but all the posts were about product evaluation, which is very boring to me as a developer (if I was in charge of purchasing, maybe, but even then it's pretty boring...)
My personal vision is that we'll have a toolset rich enough that the applications will practically fall out of the tools, i.e., you'll always build your CMS. But depending on the nature of the toolset, maybe that will look like a shrinkwrapped product depending on your perspective. Is the secretary who builds an Excel worksheet of contacts a DBA? Is the PHP coder a developer? What if it's just server-side includes? Is the HTML coder a developer? is the Dreamweaver user a developer? "Building" or "programming" or whatever -- it's all a continuum. Anything complex and powerful will require abstract thought, and there's simply no way to get around that.
The developer who makes a highly-flexible piece of software, and the developer that makes an easy-to-use library of code -- they are both moving to the same goal, but from different directions. In the end there's no nirvana, no perfect balance, but we certainly are moving forward toward that goal.
And of course when it's open source, you build it or you buy someone's time to build it for you, but without code as "property", it's all building. (Well, building and system administration, but that's a fuzzy line too)
Posted by Ian Bicking at November 25, 2003 10:32 PM