Updated: 4 Sep 2008

I. Is Drupal similar to other CMS?

1. Giving a feature-by-feature comparison of Drupal with other traditional content management systems (CMS) like PHPNuke, PostNuke or Plone is a tricky undertaking because of two reasons:

First, a comparative matrix of features does not accurately tell the tale.Saying that all of these CMS's have forum and blog modules is like saying that a Corolla is like a Ferrari, just because they both have four wheels, a windshield and an engine. We will later find out in this paper that Drupal's "secret ingredients" -- what sets it apart from the other CMS's is that its node-centered paradigm, which in turn enables it to have a powerful Taxonomy module (now also called Categories).

Second, Drupal’s major impact -- versatility or flexibility -- can only be fully appreciated by web developers. With Drupal, building an impressive website from scratch is trivial (especially with the release of version 6) and requires less programming than the other CMS's. More than this, if you use Drupal as the engine for your website, you will later discover that it is easier to add new features and even reshape your website from a simple brochure site to a web application.

It is important to note that the author has done various web development work: from making static web pages, to making dynamic websites using proprietary and open source engines. He is therefore comparing Drupal and traditional CMS from both the user perspective and the programmers perspective

 

II. Why a comparative matrix of CMS features will not work.

2. A Google search on CMS comparisons will usually lead to several web pages containing a matrix of features with check boxes. Like the other Plone and Joomla, Drupal allows blogging. All CMS's worth their mettle will also have the obligatory forum module. Most of the CMS's also let you "plug in" additional features and functionalities, and are theme-based -- meaning their visual design can be changed without major reprogramming needed. Finally, all of the CMS's mentioned are open source, using PHP, MySQL and Apache.

3. Therefore, using a comparative matrix is only helpful in counting the number of features but does not express the implicit power of Drupal over the others. (Some have suggested that comparing Drupal with traditional CMS from a CMS point of view is deceiving since Drupal is a framework and not just a CMS, while traditional CMS are just content management systems. This is a technical point that is valid but should be the subject of another paper.

III. Key Differences (User and Developer Side)

4. At first glance, the direct impact on users is not visible. However, when the users begin to use the system and start requesting things like:

(a) “We need to add new tags,”or

(b) “We need to be able to apply multiple tags in one article (multi-tagging)"

– then the main differences between Drupal and other CMS's become apparent. In other CMS's, the user requests mentioned above will require reprogramming. In Drupal these requests are easily implemented through the Taxonomy module (something which other CMS's do not have). In fact, such is the power of the Taxonomy module that users with no programming backgrounds can be trained to handle the two requirements above, since the task requires no programming at all.

5. The Taxonomy module is therefore the first key difference that distinguishes Drupal from traditional CMS's. In traditional systems, there is no way to multi-tag content. Adding new tags (or labels) or renaming the content labels will present a programming migraine for developers of old CMS's. In contrast, Drupal's Taxonomy module let's users generate new tags, rename old tags automatically.

6. There is a reason why the old CMS's are trapped in the multi-tagging problem, and this can be traced back to the history of web development. In the early days of web programming (it was still referred to as web authoring, back then), we had simple websites requiring simple ways of categorizing content. The resulting paradigm for sorting content at this stage could be referred to as the "pigeonhole system" -- imagine your content as letters in an envelope and the only way to sort them is to drop them into pigeonholes.

7. At that time, websites merely needed to have content sorted into pigeonholes labelled News,About Us, and Contact Us, for instance. Pigeonholing was the easiest and most primitive way of content architecture, during the days when web users were generally of the same demographic origin and behaved predictably. But since then, our usage of the web has become more sophisticated; more information has accumulated in our sites and we have recognized different audiences using separate styles to find and use web content.

8. Content architecture also evolved from mere pigeonholing to the more natural multi-tagging of content. To illustrate: Drupal allows a News item on the cervical cancer vaccine to be cross-tagged underScience or Health, or under both of them. Health conscious web surfers will think of looking for this news under Healthand not necessarily under Science or Medicine, for instance. Hence the importance and power of multi-tagging is in the fact that it allows content to be structured to anticipate the demands of different sets of readers.

9. The Taxonomy module, in other words, is a vital feature of content management that only Drupal currently possesses (not even MS Sharepoint can multi-tag at this stage). It represents a paradigm shift in the way content management systems are built. Drupal has the distinct advantage of being built after many CMS's. Thus the shortcomings of the old CMS's were addressed in the architecture of Drupal. However, a paradigm shift is not easy to embrace. And this is why in the early days of Drupal, many developers found it unwieldy to use.

10. Many developers struggled to understand the seemingly inverted approach of Drupal. That is, in old CMS's, we first had to define the categories or tags, then we put in the content inside those categories. In Drupal, that step is no longer needed. In fact, filling a Drupal website with content can be done in parallel with setting up the categories. Labelling content can happen after the articles have been uploaded. Moving around the labels can be done easily too with Drupal.

11. Note: paradigm shifts as Kuhn and Toffler have pointed out, are difficult because they cause resistance from traditional believers. Hence, programmers/developers who first encounter Drupal are often confused with the way Drupal handles content. This is because Drupal puts the content at the center of the CMS while traditional CMS put structure first and the content last. The way traditional CMS treated content and structure eventually became its limitation: if you first define the structure, then you are more or less locked within the confines of this structure. Drupal does the reverse by making content the starting point and then allowing users to define the categories and structure any way they want to. To understand this better, we can cite the YahooMail and GoogleMail analogy. The only way to categorize mail messages in YahooMail is to move them inside folders like Personal and Work. But what if a mail message has to be both under Personal and Work? GoogleMail does not use the folder metaphor but instead uses “labels”. In GoogleMail, mail messages can be multi-labelled.

IV. Paradigm Shift: From Content to Taxonomy

12. Organizations and companies today need the abiilty to easily and effectively filter the information and find the relevant ones. This can be done by creating a content management platform that facilitates the creation and revision of content architecture, something Drupal implements through its Taxonomy module. This paradigm change is subtle and it’s what most web programmers still fail to understand. Organizational requirements have since changed: from managing content, to making that content easy to find and retrieve. The situation brings forth a strong need for dynamic taxonomy management.

13. Moreover, as more organizations explore knowledge management and aim to become better learning organizations, it is now clear that the way we structure and categorize information is not static but fluid. One can imagine a library whose card catalog changes constantly because of the ever-changing needs of a household. Traditional CMS will therefore not be able to respond to the demand for fluid taxonomies; Drupal can. Drupal empowers the users themselves to easily define and change the categories and structures of their intranets and websites. Drupal’s taxonomy module also enables users to create relationships between categories or vocabulary terms without the need for reprogramming. For instance, defining the words “development” and “progress” as synonyms is trivial in Drupal and can be done by non-techie users. In traditional CMS, this task will require reprogramming. The paradigm shift is so difficult that even now, web developers who have made the shift to Drupal cannot clearly articulate why Drupal is better, even to their fellow developers (what more with non-techie users?!). Programmers also even suspect Drupal because it is relatively newer other CMS like PHPNuke or Plone.

14. At this point, programmers who use traditional CMS may say, “Why not just develop a taxonomy module for the traditional CMS?” Here the discussion brings into play another key difference between Drupal and traditional CMS: the design paradigm. Drupal was designed in the context of knowledge management and the awareness of the importance of dynamic taxonomy. To this author’s knowledge, no other CMS tool integrates a dynamic taxonomy module – not even Microsoft SharePoint, which is a fairly new product. Besides, building a taxonomy module for traditional CMS would most probably require major reprogramming of the core code, something that is tantamount to reinventing the wheel.

15. And there lies the third key factor that distinguishes Drupal: because it is developed in a new paradigm, it anticipates much of the emerging requirements of knowledge workers and organizations. Modifying a Drupal-based website or intranet will require less effort than if these sites were built on traditional CMS. Even in customization tasks that will require programmers to get their hands dirty with PHP, Drupal will prove to be easier to manage than with traditional CMS. Of course, this will sound like empty marketing promises to attract traditional web programmers to Drupal. But we can’t do anything about that – it’s the resistance to change which is at work there.

V. Summary and Conclusion

16. Trying to compare Drupal with traditional CMS on a point-by-point basis on existing product features will not generate useful wisdom. It is also difficult to do because users will hardly feel the difference and the major impact of Drupal will be appreciated more by web programmers. To make matters worst, programmers will most probably resist the new paradigm and stick to the familiar terrain of traditional CMS.

17. What would be more meaningful is to discover features beyond what is covered by these traditional-minded matrix comparisons. There are three key differences that distinguishes Drupal from traditional CMS: (a) the dynamic taxonomy management module that empowers non-technical users to define and change the structure of their websites, (b) the radical design paradigm that made possible the taxonomy module, and (c) the appropriateness of the design that makes Drupal an ideal engine as a tool for knowledge sharing and management.

-END-