Email vs. Content Management

Seth Gottlieb has a nice weblog about content management, open source and ploney things. (Another good one is Content Wrangler).
Here’s his post about Smart Folders and plone (don’t know how I missed this one). Smart Folders (previously called Topics) are something worth getting familiar with. Places to start: Using Topics in plone 2.1

Here’s Gottlieb’s wrapup of the March plone conference. Most interesting were his reports of Alan Runyan’s explanation of why he doesn’t use a plone product for bulletin boards:

Alan wants to get make Zope less of an island. The example that he uses is that CMFBoard (an add on bulletin board that can be added onto a Plone instance) is a dead project but there is no good reason to write another one in its place. The Zope platform is not optimized for the kind of thing that a bulletin board is designed to do. Bulletin boards are write-intensive whereas the ZODB is more efficient with reads. Instead, Alan recommends integrating with an external BB software built in something like PHP. He did this using Simple Machines Forums (SMF: http://www.simplemachines.org/) for the OXFAM site. All that they needed to do was make some modes to SMF to enable single sign-on.
Alan wants to create a repository in the Plone collective (which is used to store add-on products) for integrations with external systesm. These integrations could be patches that can be applied to external systems or adapters. Zope could be a very good platform to support this integration based architecture because of its strong support of XML-RPC. I really like this idea and I hope the dialog continues.

Since my CMS needs are relatively modest and I don’t have a lot of experience making customizations/ integrations, I dread the prospect of involving external products. Still, I can’t reject anything out of hand.

Here’s Seth’s take on the email vs. content management issue.

The key issue that I have against email is that it compounds the problem of exploding volumes of unmanaged content by creating unnecessary duplicates. If you email a document to 2 people, you now have 3 copies to manage and merge and diff. No one knows which one is the master copy. No one knows which one is the newest copy regardless if someone stupidly added “new” to the file name. Plus, everyone is personally responsible for their piece of the archive. That is too much responsibility. If I accidentally delete the best version (it may or not be the latest version) of a document, there is no way to get it back.

(This was a response to the Central Desktop blog on the popularity of email for office work:

Virtually everyone who has ever touched a computer understands email. Maybe it was daunting at first, but in the end, email is easy to understand. “It’s like sending a letter through the postal service, except its electronic.” People get it. The fact that so many grandparents and young children use email to stay in contact with their families and friends around the world is a testament to its ease-of-use. Likewise, after you “learn email” for the first time, all other ‘variations’ of it are essentially the same. The learning curve for switching email interfaces is virtually non-existent.

By comparison, most collaboration software solutions are difficult to understand. Many provide such a different user experience (wikis for example) that the learning curve becomes another hurdle of adoption.