Evaluating Open Source CMS Solutions

1. Budget
   1. Hidden costs associated with all CMS choices must be evaluated. If ongoing system upgrades or licenses will involve additional expense these factors should be noted before deploying a particular CMS.
   2. Are specialized hosting situations required for either the chosen CMS due to client needs?
   3. Are there any supplemental costs associated with the deployment, such as SSL certificates?
2. Product Feature Set
   1. End product feature sets can be broadly defined as the feature set of the desired product. Will the product require blogs, member messaging, email to a friend features, RSS feeds, etc. CMS choices can be largely driven by the client feature requirements. Many CMS options offer various modules and core ingredients that may meet client needs out of the box. It is important to identify all desired features before evaluating any CMS. There may even be situation where the client needs are specific enough that a custom built CMS is warranted.
   2. Once all desired features have been identified each CMS can be evaluated based on its basic implementation, any additional modules, and the number and scope of custom modules can be weighed. This process is designed to determine which pre-built CMS will best fit the broadest scope of client needs with the least amount of customization. Once a best fit is established, it can be weighed against a custom built CMS.
3. Custom-Built vs. Existing CMS
   1. Pre-existing CMS solutions are advantaged in that the essential Quality Assurance (QA) has already been done. A pre-existing CMS is assumed to have a strong code base that will function without bugs or problems, saving developer time for customization. Most pre-existing CMS solutions provide add-on modules that can be used to meet many client needs. OS CMS solutions can also easily be modified to meet customer specifications.
   2. Custom-built CMS's require more time to implement because outside of core components they must be built from the ground up. While this introduces a much longer QA and debugging cycle, a custom-built CMS can be structured to meet client needs specifically. While a pre-existing CMS may require major modification and revision, a custom-built CMS can be created on the fly to meet client demands.

1. Support (in-house vs. contractor, initial vs. ongoing)
   1. Support should be a major consideration in choosing effective technologies. If the client already has in-house technical staff, their technical experience should be matched to the technology choice. If the client already employs in house technical staff that are knowledgeable in a certain technology, that should pre-dispose the technology choice to their area of expertise. If the client is looking to outside support, this should also be a consideration. In general it will be easier and cheaper to support OS solutions. OS functions on a principle of free community support which has created a large pool of inexpensive expertise. Closed source solutions will require more expensive support. CMS technology decisions should also be weighed against available support. Any CMS with an extensive user and support base will be more cost effective to maintain in the long run.
2. Existing platforms
   1. The client's existing hardware and software architecture should also be taken into consideration when exploring CMS solutions. Often time's clients will have existing hosting environments that may dictate CMS choices. If the client has any preexisting licenses to software or hardware these should not be ignored when evaluating CMS options.
3. Existing data
   1. Existing data that must be migrated into the CMS should also be evaluated. If existing data resides in a proprietary format then the cost of migration should be weighed against the use of similar proprietary format for the CMS.
   2. All existing and future data types must be noted. This includes any internal documents for publish or external sources (RSS, XML, etc.). The target CMS must be able to store, process, and manage these data types.
4. Data Availability.
   1. Some organizations are mandated to make their data available in a known format to internal applications, business partners, clients or customers. These needs must be identified before choosing appropriate CMS solutions. If archival formats are required, these should also be noted. Many clients require a uniform data format for archiving or future upgrades. These considerations must be taken into account when evaluating CMS data storage (specifically database back end support).
5. Content Process
   1. All content processing guidelines must be met by the target CMS. If content requires review, editing, or approval, each CMS must be evaluated in terms of its ability to meet these needs. Some CMS solutions support this workflow control better than others.
   2. Do one or more authors create the content? Are these authors centralized or distributed? These questions must be answered to determine which CMS will best support the client's content creation needs.
   3. Versioning and roll-back capabilities of each CMS must also be determined. If the client has extensive need for recall or versioning then the target CMS must be able to support this.
   4. Does the client have any URI requirements? Will content stay in static locations or will it move? If content location is variable the CMS must support URI to allow for dynamic linking of content.
6. Administration needs
   1. Ease-of-use must be evaluated. Does the Administration of the CMS require extensive training? How available are help and other documents? Is the interface intuitive? The overall usability of the administration must be evaluated from an end user perspective.
   2. Are there any geographic considerations with the administration? Does the administration require an installation of software or is it enabled with third party software? How available is the administration (for instance to road warrior users)?
   3. Admin resources standardization should be considered. Does the administration interface appear uniformly on all platforms (and/or browsers). Does the administration interface require any third party software (such as a web browser) or is it a stand-alone application?

1. New Data
   1. Does the CMS support new data types? If for an unforeseen reason the project must be expanded and new data types are added, the CMS must be able to conform to new data types with relative ease.
2. Scalability & Scope
   1. The scalability of each CMS must be evaluated to determine if it will meet the client needs. In addition, the intended scope of each CMS must be noted. A CMS designed to run a large corporate site may not be the best choice for a small business with a limited number of pages. Some CMS'es can scale easily to meet client needs, but others may require such heavy modification to meet client scale and scope as to make them inappropriate.
3. Templating
   1. Is the client site built off of any sort of universal template or will there be multiple content formats that must be supported? Some CMS's support custom content presentation better than others.
4. Reporting
   1. Does the intended CMS require reporting? If so the scope and scale of this reporting must be evaluated. Some clients will require only log file reporting, but others may need more detailed reporting statistics, including usage of specific functionality such as 'email to a friend' features.
5. Security
   1. Does the target CMS support client needs such as SSL or user/group controls? The degree to which the target CMS supports client security needs is a major consideration. Encryption and user controls should both be evaluated. If the client has complex user architecture then this must be noted as well.

1. Internationalization
   1. Does the intended audience or administration require multi-lingual support? If so this must be taken into consideration when selecting a CMS. The administration interface as well as the presentation must be evaluated and support any client language needs.
2. Standards
   1. The standards compliance of each CMS must be evaluated. CMS's which support extensible, standards compliant formats will be valuable over the long term since they will allow for easier maintenance and migration of material. Each CMS should be evaluated in terms of its support of well-known and accepted standards such as XML (including XHTML), Dublin Core, CSS, etc.
3. Accessibility
   1. Is the CMS Section 508 compliant? How well does the CMS present information for persons with disabilities? Each CMS must be carefully examined to determine if it meets or exceeds standard usability guidelines.
4. Membership and associated features
   1. Are there available member account features? What are the processes by which members sign-up? What features are available for member management (add/edit/delete)? Can any management be distributed among users and/or groups of administrators? Is member management scalable?