When it comes to a Content Management System (CMS), what is better: to build your own system?...or to buy one of hundreds of available applications on the market? Cody Burke, analyst, posed this question as a part of this week's Basex TechWatch eNewsletter.
[If you want to be completely amazed, alarmed and possibly even overwhelmed, go to CMS Matrix to see how many Content Management System are available on the market today]
Years ago, as Mr. Burke points out, companies only had the two choices....build from scratch a system that perfectly fits your requirements and can be modified to changing needs, but can be expensive by using internal resources; or, spend to buy a system that has more than you need, is not custom, but can be implemented quickly and utilizes Content Management experts to shape the system to needs?
The answer usually came down to corporate philosophy...those with NIH (Not Invented Here) Syndrome building their own, and those short on internal resources, but strong in need, opting to find an existing commercial system.
While the argument is far deeper than these couple of positions posted here, it is not the purpose of the Basex news article, which set its focus on Open Source. In a relatively "old" (maybe mature is a better word) market such as Content Management there are now many offerings that can compete with commercial applications, but remain free of charge. As Burke points out:
There are multiple open source content management solutions available today that come with the benefit of zero cost and full access to source codes. Instead of building completely from scratch, setting up an open source CMS means downloading, integrating, and customizing the system initially, and ongoing work to support and maintain the system.
The article also mentions the fact that more and more companies are going into business as Open Source experts (Vendors), able to customize one (and in most cases more than one) CMS system to meet a company's requirements. More on this is a future post, but the point is that an organization can now find an Open Source solution (no-charge software with source code available) that competes with commercial software offerings, and hire a vendor that is expert in that system to customize it to meet requirements. Cody Burke reminds, though, that the price of admission may be 0.00, but you still must have the resources to either customize and support the system yourself, or find and pay a vendor to provide these services. From Burke:
By using open source tools, the cost is significantly lower than a commercial product, the customer possesses the source code, and the system can be fitted to exactly the needs of the user, getting rid of excessive bloatware and unused features. The negatives of open source, and building a CMS in general, are mitigated by the commercial level of support and pre-integration that negates the need to shift or hire staff to set up and maintain the system.
About 3 years ago, I was part of a team that made such a decision to go with an Open Source CM Solution and hire an outside Vendor to customize it to meet our requirements (and they were expert in more than 1 Open Source CMS system and a few other Open Source applications). It helped us solve an immediate problem, and In the end, we ended up hiring a full time employee to keep developing the system.
This leads to a final point that I feel is critical in any discussion about using a CMS.
For any 'first time' CMS implementation, I would strongly recommend going with an Open Source solution. The nearly 100 point Requirements Document that we created for our CMS did not adequately cover what our real use would be, once the system was implemented and accessed by Users (some things we ended up never using, while other minor requirements became major features, etc). By implementing an Open Source CMS, hiring a Vendor on a project-by-project basis, and then taking over development, our CMS was a dynamic tool that evolves as our needs do.
This is even a good path for those with NIH Syndrome, as going this route has helped us develop requirements for a system that we could build from scratch, but again, we can do it based on several years of experience using a CMS, instead of creating something from a set of requirements emanating out of a few brainstorming sessions.