Proprietary vs. Open Source CMSs

If and when your organization needs a new website, in most cases the best approach is to build it upon a content management system (CMS), which is like a framework that allows the website owner to easily add and modify text and multimedia content by themselves, without having to rely upon any web developers or designers — who typically begin the process by identifying the needed capabilities of the site, configuring the CMS to make that possible, and crafting its visual design.

There are two general categories of CMSs from which you can choose: Open source or proprietary. Open source systems, as their name implies, consist of source code that is open to inspection by anyone, including the thousands of web developers who contribute to each CMS project, especially any group of them dedicated to finding and fixing security vulnerabilities in the code. Consequently, any such flaws in open source CMSs — such as WordPress and Drupal — are usually detected and repaired faster than those in commercial, homemade, or other proprietary systems. The security teams of open source projects typically comprise numerous skilled programmers who have diverse technical backgrounds and who take great pride in the quality of their work; after all, their names are clearly associated with the projects to which they are dedicated. This is quite unlike the unknown programmers who work at commercial firms and receive little publicity, especially when another security hole is discovered in the CMSs built and licensed by their employers.

In my experience as a web developer tasked countless times with replacing legacy websites built on proprietary platforms, clients who had allowed themselves to get locked into using such systems oftentimes find it much more difficult to transition away from any such platform, for several reasons: Each CMS has a unique way of storing page content, menu structure, content types, tags and tag assignments, etc. within its database. In turn, each one has a unique database design, making it prohibitively difficult to write code to try to automate the process of transitioning to an alternative platform (assuming such code has not already been produced by programmers who had faced the arduous process in the past). As a result, most such projects mean that your developers and content administrators will have to do most of that work by scratch.

Another downside to proprietary website systems is that the original developers who implemented the legacy system can even make it intentionally difficult to be replaced (perhaps thinking that this provides them with better job security). For instance, one of my former clients, a healthcare organization, hired me to replace a closed and heavily-licensed CMS, with something much more open and easily maintained. (For this particular project, I chose Drupal.) Not only was the legacy CMS poorly built and difficult to replace, but the original web firm had even gone to the trouble of encrypting on disk all of the client's PDF documents, and only decrypting them when displayed to users of the website. When the client asked the original developers (who knew they were being replaced) to decrypt the client's documents, they refused. As a result, the project manager was compelled to view every one of those PDF documents online and then save the decrypted document, for use within the new website.

Furthermore, adopting any of the proprietary CMSs involves paying licensing fees — regularly in many cases. In contrast, most open-source CMSs are free to use, even for commercial applications.

In addition, customization of a website built on a proprietary system is limited to the modification features built into the system by the vendor. The only exception is that some vendors are willing to customize their code to satisfy unusual client demands, but at considerable expense. Also, such custom code usually must be reintegrated for each subsequent version of the proprietary CMS. Last and certainly not least, any custom code typically receives far less scrutiny for security vulnerabilities than the code in the mainline version, since only one client would be involved in a resultant security breach.

There are numerous other disadvantages to choosing a closed or otherwise proprietary website system. But for the reasons noted above, if nothing else, you are almost always better off going with an open source CMS.

Copyright © 2023 Michael J. Ross. All rights reserved.
bad bots block