CMS is it? ...

Recently, I accidentally stumbled upon a discussion of the term CMS , as well as Drupal and SharePoint in the context of this term. It all started with the fact that Bert Bourland said in his blog that in the next 3 years (entry dated December 22, 2006) CMS will mean “Community Management System”. Content ceases to be a key element of a successful site (both on the Internet and, with some delay, on the intranet).

It seems quite logical to me. Now it’s not enough to fill the site with useful, high-quality information. It is necessary to create a community around this information, thus increasing the involvement of site visitors in the content formation process. An ideal system built on the principle of "content + community" will have positive feedback. The more people get involved in the community, the more content they generate, the more visitors the site attracts, the more people get involved in the community ... the circle is closed. I deliberately leave beyond the scope of this entry, the quality of the content of the site, because they require a separate discussion.

The topic of a new look at deciphering the abbreviations CMS was developed in his blog by Drui Buite - the leader of the Drupal project. From his point of view , the CMS is the “Collaboration Management System”, i.e. collaboration management system. As an example, he cites SharePoint and its closest analogue with open source - the Alfresco system (the latter, however, it lacks exactly the “portal” functions). Dri also complains that, unlike these two systems, Drupal does not support integration with office software, such as MS Office and OpenOffice. The discussion continues in the comments to the post, but gradually rolls over to the banal holy war between fans of SharePoint and Drupal.

So what, in fact, is the difference between the content management system and the community management system or the collaboration management system (the latter, to some extent, is a special case of the second, most characteristic in a business environment)? In my opinion, the difference is in the direction of information flows. Traditional CMS'ki provide, in fact, one-way transmission of information - from the editor (it can be both the author and the "collector" of information) to the reader (site visitor). The editor, among other things, must have the skills to enter and change information in the used CMS. As web applications using DHTML evolve, the process of entering text into the system, even with complex markup, becomes much simpler, but, by its capabilities, still does not reach to full-fledged desktop office suites. What to say about tabular data and graphical diagrams, which are very often used in a business environment. Manual layout of pages is often too complicated for most users.
')
All this does not allow establishing a full-fledged reverse flow of information - from the reader to the site editor. As soon as we allow the reader (in this case, he is already a participant ) to make his own changes, to supplement and expand the content of the site using his usual means (and for most users it’s like an office package), we’ll get a collaboration system suitable for business needs. The casket, as you see, opens simply.

So, summing up:

1. The content management system should provide the flow of information from the editor to the reader . The collaboration system should provide a two-way flow of information - from the site to the participant, and from the participant - to the site. At the same time, the technical means by which the user enters information into the system must, on the one hand, have wide functionality, and on the other hand, be simple and / or familiar to the user.
2. In order to make a “SharePoint killer”, it is necessary first of all to implement a simple, bug-free, transparent integration of the system with this or that (and preferably both) office suite.

Crosspost from my blog