Rolling your own CMS just doesn't make sense

I think the problem with developer's relationship with Content Management Systems lies in a couple of areas. I feel that developers have a huge amount of emotional capital stored in their prior self taught knowledge base. As a result they choose to "take their football and play elsewhere", the football being their vision for the CMS rather than learn the plays and work with the team to get the job done. The idea that one could have (or should allow) a government contract with a "roll your own" architecture is pretty naive. From what I've seen starting with Vignette, Cold Fusion, Plone and Drupal and even I dare say Sharepoint, is that most developers don't take the time to know the Content Management Framework and won't forgive the choices made by those that went before them. So they opt out and build as they say in France, "Craptastique" proprietary systems and so they can play football by themselves until mommy and daddy cancel the contract or they have a heart attack because they can't keep enough footballs in the air (Customers with 2^n proprietary systems built by the developer)to keep a revenue stream flowing. Learn to play with others. Accept their faults and build on experience. Development is a process and shared experience.

Great article.

What we also see with clients that move over to our CMS from custom rolls or OS systems is that no one in the executive suites planned for end user support or even code maintenance. Their custom system turns into handcuffs to the original developer and have you ever had a programmer supporting an end user?

SaaS CMS from a solid experienced vendor is a great choice for SME's who don't want all the headaches.

It all comes down to the right approach for your organization. For some, it will be creating your own, for others SaaS and others commercial or open source. Each company has to make educated decisions based on its own needs and requirements. There is no right or wrong answer, but with so many existing systems, some very flexible, it seems that building your own system from scratch would not be the most cost-effective (especially as needs change over time).

Nice, Ron. I agree completely and pointed to this editorial from our corporate blog. Blog[dot]reallysi[dot]com

What the original poster may have meant to say is that, like virtually every software system, a CMS is built on a set of assumptions and can be measured only against them. In a article a few years back, I opined that CM is not something you buy or develop, but is instead something you do. Because everyone with content to manage is likley to face at least a partially unique set of challenges, a CMS is likely to work in any particular site only if its foundation assumptions describe the site's unique requirements. Unfortunately, the software industry has floated the idea that "content management" is a definitive term that means pretty much the same thing everywhere (unless modified by "web", "digital assets", etc.) It's easier to sell a product that way, but it doesn't help the site that needs to commit the time and effort to define CM for its unique requirements so it can choose a CMS that comes closest to them. All too often, the prospect CMS buyer just assumes that he needs CM, vendors all sell CM so he just picks one that demos well and voila! As so many have learned, it doesn't work that way.

Componding the problem is the fact that most CMSs are built on relational DBMS models that work less and less effectively as content to be managed becomes more and more dynamic. In a richly structured XML environment, the RDBMS limitations become very onerous and the software becomes more and more complex and cumberesome trying to keep up with the content.

In any case, CMSs work, but they only do what they do (some better than others) and if you need something other than that, many won't work 'for you.'

Regards,

Barry

Barry,
That's a pretty pessimistic view of content management and one I really can't agree with. While I do agree every company has a unique set of needs, there are enough common elements that the packages being marketed today will solve a good portion of the problems they face. The CMS I use to produce this newsletter for instance isn't necessarily perfect for me, but it's close enough for me to get my job done every week, and it works well enough for my editor to review and publish the newsletter to the web and to our email subscribers.

There is such a thing as the 80/20 rule and I think you'll find most CMS vendors take care of the 80 percent fairly well. Sure there will be pieces that aggravate you, but for the most part you are going to get a system that manages your content fairly effectively.

As for the underlying relational database, even that is changing and there are more systems based on XML (which presents its own set of challenges by the way)

There is no perfect solution, even rolling your own, as I pointed out may not be the best bet for every user who gets in front of the system, or the end result may not give you what you thought when you sketched it out on paper.

I appreciate you taking the time to comment.

Ron

Ron;

Agree with most of your detail points, but can't agree with the overall conclusion. You are correct that I have, over the years, become a little pessimistic about the outcome of CMS acquisitions without the level of diligence I described. I would agree that the 80/20 rule might apply to many CMS challenges, but in my travels the 20% you need and don't get (or don't need but pay for anyway) with a poorly chosen product can be crippling. Having found myself involved as a consultant in a couple dozen CMS projects, I have come to feel strongly that accepting the term "content management" as definitive of a generally accepted set of functions simply hasn't held up. I must caveat that statement with the acknowledgement that there are some CM requirements that fall within a pretty restricted function set and these, of course, are less at risk. However, as the demands for increasing elegance in information products grows, they will be fewer and fewer.

I hope that we can agree on the following:
1. CM is not a monolithic term or function set.
2. If you are going to acquire one, know what you need... in some detail, before you sign.
3. Don't fall prey to the salesman's assertion that his product does what you want without checking that out.
4. Don't roll your own unless you have lots of technical talent with nothing much to do.

Regards,

Barry

Barry,
We are in complete agreement with those four points and I defer to your vast experience on this matter. I don't think there are any absolutes here. You find what works best for you whatever direction you choose

Ron

Thanks Ron;

Hardly vast, but as the Chinese say "interesting times." Thanks for opening a subject far too few people think about before they start writing checks.

Regards,

I think a lot of the problem stems from the swiss-army knife approach. Wanting one system which does everything. Generally speaking I've found that using the right tool for the job is always far more efficient, so rather than buying in one CMS which tries to do all aspects of web publishing it is easier to use a number of dedicated tools and put the coding effort into making the public face of it all look integrated.

(see http://shadowfax.org.uk/wiki/The_Power_of_Simple)

Your comments "You're not in the CMS business and you probably shouldn't be" may be extended to include web development in general. To many design and advertising agencies are placed in charge of CMS projects. They simple dont have the correct skill set. Great post.

Thanks for commenting and glad you enjoyed the post.