Having spent a few weeks exploring CMSes during a recent project start in Atlanta, here’s my rambling answer to “please recommend a Ruby CMS”.
Content management is a hugely fragmented market. At one extreme you’ve got huge commercial CMS vendors like Vignette and at the other end hundreds of OSS projects, each scratching some particular itch. You can browse a listing at cmsreview.com to get a feel for the sheer number of options: http://www.cmsreview.com/CMSListing.html. During a three week period in Atlanta, Brandon Hastings Byars Esq. and I looked at all of the following (some very briefly):
- Radiant
- Mephisto
- Comatose
- Alfresco
- Magnolia
- Hippo
- Daisy
- Contribute
- Plone
- Bricolage
- CityDesk
- Joomla
- More and more and more and more
We even took an afternoon and outlined the stories and time needed to roll our own to meet the client’s needs.
Cooperatively with the tech and biz owners, we set out to divide the huge solution space using invariants. We built truth statements and used them as guideposts during our conversations and explorations. We repeated them all day long. We started with this one:
“We’re building tools which make experts more effective.”
That statement helped us guide the evaluations. Any CMS designed to bring authoring to the non-techie masses immediately got the axe.
Our client, as have others, initially requested a Ruby CMS. We explored that preference. As it turns out, they understand what it takes to own and operate a Ruby app and felt comfortable deploying another one. Other architectural options, like Plone on Zope (Python), needed some huge benefit to overcome the preference for Ruby. When pressed further, we discovered grand plans to build around this content management feature with other, more dynamic features in the future. When we probed around those plans, we found out they expected to build a custom Rails app around this content, eventually. Our second invariant ended up like this:
“Whatever manages the content will not deliver the content.”
That statement eliminated most CMS options, as they mostly want to manage and deliver the content ala Radiant or Magnolia. We explored an architecture centered around extracting content from a content repository (google java content repository) but we realized that solution just gutted the CMS products and the remainder provided little real value.
To further clarify, we learned along the way they didn’t want live editing (too risky) or to manage layouts and styles (skilled UI designers do that) and that a production-like preview is a MUST have. Oh, and deployment should be push button but release 1 doesn’t need any fancy scheduling.
They really wanted help managing their static content, not a content management system. What started out as a stated CMS problem really turned out to be a release management problem. We designed a solution to deal effectively and realistically with static content in their organization and received praise for ways in which we navigated the ambiguous terms and monstrous CMS solution space.
Having said all that, I think any client asking for CMS and asking for Ruby should at least explore the notion that Rails, with carefully selected additions, lends itself to rapidly changing content, frequent deployments and tight version-control integrations. Read this to provoke your thinking:
http://rubyredbricks.com/articles/2008/04/09/rails-as-cms
Content management is an overloaded term. You gotta ask what it means.