With the evolution of the web standards, features, the number of Open Source CMS packages available and their package cost advantages, there has been growing enthusiasm in the industry about the use of Open Source CMS packages. With this growing demand for Open Source CMS, there is an increasing demand for service providers such as Oshyn, who follow systematic comparative approach, evaluating their client requirements, the CMS feature set fit and the complexities in development using Open Source CMS, and guide their clients in making a knowledgable decision. To understand whether using an Open Source CMS is safe or not, we should first understand the advantages and disadvantages of using Open Source and then we can make a decision on when it is safe and when it might be risky.

Advantages that make these systems an attractive option are:

• Initial package cost is zero, as it is free.
• Full availability of source code, to modify to suit custom requirements.
• Availability of several latest features as add-on modules.
• There is often a developer community providing a talent pool, it being Open Source.
• Good fit when the modules fulfill the requirements without any modifications or extensions.
• It would be robust and secure, over the long run as more community is involved in using it, removing any critical bugs and flaws in the packages.

 Disadvantages of these systems that make their adoption difficult are:

• Lack of accountability and support for issues with the system: As it is developed by people around the globe on voluntary basis with no monetary incentive, there would be issues with providing support for any issues that one encounters with the system. However, nowadays, there are vendors which provide for hosting and support for some major modules of the CMS, ex: Acquia hosting for Drupal.
• Lack of standardized QA methodology for the add-on modules which would make it difficult to identify quality and reliable modules for usage, as well as to support issues with the modules.
• The future direction of the CMS: what are the areas of development the CMS community is looking into for future. Assume you need social media features, but the CMS community is more dedicated in the development of some other areas of the CMS.
• Lack of training on the CMS: There is no formal training provided for Open Source packages as there are with commercial CMS.
• Deviation from vanilla version/Extensions to the CMS would make it expensive in the long run. Though the initial package cost is zero, the cost of development and maintenance would be less as long as the modules and the package meet the requirements. When any custom development or extensions to the package are required, then it will make it expensive for development and maintenance in the long run.
• Ease of Future Upgrades to CMS package – The upgrade process becomes complex when any custom modifications/extensions to the CMS are made to meet business requirements, thereby obstructing any future upgrades of the package, and locking the business into their package version.
• Level of activity of the developer community – The level of activity of the developer community will indicate the progress and direction of the Open Source CMS, and it is highly unreliable factor due to lack of a committed team to progress on the CMS feature set.
• Availability of well documented APIs to interact with the CMS: Since they are built voluntarily by individual developers, there might be poor documentation about the APIs available, thereby making it difficult to integrate other systems to the CMS.
• Talent pool available for developing sites in the CMS might be limited based on the level of activity in developer community, which would impact the cost for development, maintenance of sites.
• Features provided: As long as the feature requirements are met by the available modules, the cost of implementation and ongoing maintenance are low. We can have some custom modules built, but should make sure that this does not constitute a significant percentage of the implementation and out of the box modules fit and serve the business requirements.
• Security of the package: As source code is exposed to community, there can be initial security vulnerabilities initially and hence maturity of the package will be of prime importance, as maturity of the package has a direct correlation with the robustness of the package.

 Criteria for Evaluation and Inter-Criteria Relationships:

• Initial cost of the package – zero, low, medium, high
• Maturity of the package – low, medium, high or low, medium, enterprise
• Implementation team’s knowledge of the product – low, medium, high
• Availability of hosting and support for issues with CMS – zero, low, medium, high
• Availability of source code – Yes, No 
• Level of activity and availability of strong developer community – low, medium, high
• Availability of add-on modules – low, medium, high
• Reliability of add-on modules – low, medium, high
• Availability of good API documentation for CMS – low, medium, high
• Extensibility of the CMS – easy, medium, complex
• Ease of Future upgrades to the package – easy, medium, complex
• Training support on the CMS – low, medium, high
• Security/robustness of the package – low, medium, high
• Features provided – low, medium, high
• Ongoing maintenance cost – low, medium, high
• Ease  of use for Editors – low, medium, high
• Type of business – Non-Profit, Commercial (low, medium, high)

Maturity of an Open Source CMS is reflected by stronger developer community and activity, availability of add-on modules, reliability of modules, availability of hosting and support options for CMS, security of the package, and feature set provided by the package. There is a direct correlation between these options and maturity of the package, which will provide confidence in adopting that package.

In the below diagram we can see how some of these factors are related and affect the total cost of ownership of the implementation and ongoing maintenance.

Risk Evalution

Considering that we are just taking into account the ‘risk’ associated with Open Source CMS, we may assume that we have a high expertise team implementing the system to eliminate that risk due to their expertise.  With that assumption, the core remaining items that bring risk are as follows:

• Choosing the right Open Source CMS that fits the requirements – This is an important part of choosing any CMS, but more so with Open Source CMS, or else we will have greater cost of ownership as shown in orange path in the before mentioned diagram.
• The Open Source CMS should have strong developer community with a lot of activity – or else this will make it obsolete and stale and in time will lead to less developer community engagement to provide solutions.
• The available modules should be sufficient to fulfill the requirements of the project minimizing custom development — or else we will end up again on the orange path for custom development in the above diagram. The more custom development, the more the cost of ownership overall.
• Development should be easy in the CMS to accommodate faster learning and development curve

We at Oshyn follow the process of SEAD diagram as shown below


The above process helps eliminate the risk involved in choosing the right Open Source CMS that best fits the requirements and involves minimal custom development, with stronger developer community, with sufficient documentation ensuring ease of development. These principles if applied appropriately will bring the best results, ensuring smooth and successful completion and provide for ease of maintenance, as we have done in many of our projects involving Open Source CMS such as Drupal (http://www.oshyn.com/solutions/drupal-development.html) in the PHP realm and Jahia (http://www.oshyn.com/solutions/jahia-web-content-management-integration.html) in the Java realm. The Open Source CMS arena has grown tremendously in the past decade and provides for great savings with calculated risk, if the CMS is chosen with the objectives as mentioned before, it a risk worth taking.