Ò»±¾µÀÎÞÂë

Some CMS vendors provide only the CMS software, and that software requires hosting. Hosting may be external to the university (Amazon Web Services, Bluehost, etc.), or internal (a server you maintain in a campus server room, a computer under your desk or a virtual server on the Ò»±¾µÀÎÞÂë Campus Cloud service). Whichever service you choose, it’s important to remember that self-hosting requires some level of effort and oversight on your part. For example:

• Unmanaged Services: Local physical hosting, as well as relatively unmanaged services like Amazon Web Services, provide you with a server (either physical or virtual), but you must perform significant configuration of that server and you are responsible for whether or not the configuration is secure and stable. You should have significant experience with systems administration, and the resources, time and commitment to patch and maintain that server, and perform monitoring and backups on a daily basis.
• Managed Services: Managed external services like Bluehost, and managed internal services like Campus Cloud, require less configuration but no less responsibility. You will still need to configure the hosting, launch your site and troubleshoot any conflicts between your CMS and the hosting. This can be technically challenging, and the host typically accepts no responsibility for errors that can cause security vulnerabilities and downtime. While unmanaged services allow you to choose if and when to patch your machines, you will need to work with a managed service provider to schedule maintenance and understand its impact.
• Networking: If you maintain a university website, it should use a cmu.edu URL. Using an outside host can lead to unforeseen challenges when attempting to serve your new site at an official university URL.
• The 'server under the desk': Serving public university content from a web server that is not in a university machine room represents tremendous risk to Ò»±¾µÀÎÞÂë and should never be part of your standard operating procedure.

There are many CMS platforms available for free via open source license; some of the more popular include Wordpress, Drupal and Joomla. If you have web development experience, you may be comfortable spinning up new sites in one or more of these platforms, but should consider the implications of doing so on behalf of the university.

• Patching: Any CMS is only as secure as its last set of patches. Many open source CMS communities have dedicated security teams issuing patches on a regular basis as new threats emerge. However, if you do not apply the patches, your site is likely to be compromised. Likewise, patches must be applied as soon as possible after they are released, and must be tested thoroughly in a test environment to ensure they don’t negatively impact your site. Consider the significant time commitment required to apply, test and deploy urgent patches as soon as they are released when evaluating this option.
• Configuration: Many CMSs can be configured in different ways and have thousands of plugins available to extend their functionality. A very secure CMS can turn into a very insecure CMS if it is poorly configured, or extended with low quality code.
• Health of the Platform: Because open source projects are largely led by volunteers, they ebb and flow in terms of support and interest. It’s important to keep tabs on the user community, and be wary of major forks or a sudden drop in adoption that could signal the end of the product. As fewer people look after the health of a product, the risk associated with the CMS increases. 

Unlike open source projects, proprietary CMS systems (e.g., SiteCore, Adobe, Acquia, etc.) are maintained by a company, and either deployed on your own hosting, or served by the vendor’s cloud-based hosting. While these systems are typically patched and configured by the company, the cost of such systems is often quite high. Like open source communities, commercial systems are only as stable as their parent company. In some cases, it may not be easy to retrieve your data if the parent company goes under, is bought out or discontinues support for the product. Since these products are closed-source, you will be entirely dependent upon the will of the vendor to support their product on your hardware and OS configuration, and to provide additional functionality that your site may require. Lastly, when building your site, you may also be beholden to one or a few specialized vendors who are able to develop for the platform. 

Consumer cloud-based CMSs (Wix, Squarespace, etc.) are increasingly popular due to low cost and ease of use. They tend to be 'one size fits all,' and branding their premade templates to fit university guidelines and standards for compliance and accessibility may be difficult or impossible. Further, some of these sites can modify your content to insert their own branding and advertising. Networking these sites to a cmu.edu URL can be challenging, and all concerns regarding proprietary systems apply to these systems as well. Lastly, you should carefully consider the terms and conditions of such services, to ensure that you maintain appropriate ownership of the content you create. 

If you are a web developer, you may consider creating a CMS from scratch. However, someone other than yourself may eventually be charged with maintaining your site and its codebase; and unlike a large open source project, you will not benefit from other people providing security oversight for your project going forward. It's not sufficient to build a novel CMS of your own; you must take responsibility for the application for as long as it will be publicly available and representative of the university. Consider the effort involved now and in the future before following this path. 

Many vendors offer to build, host and maintain sites on various platforms, both commercial and open source. However, a vendor's knowledge, skills and commitment to quality can vary widely. Since any public university site represents the university, you must ask hard questions of any service provider regarding their security standards, code quality and commitment to uptime. Just because a vendor says they will "take care of it," you must ensure that you know exactly what "it" is and what "take care" means. Never wait until you have a hacked site to ask these key questions! The University Contracts office can also assist you in reviewing vendor agreements to avoid future problems.