Questions with the ASP
model"> So with all this in mind, why consider an open-source CMS instead of one from a proprietary vendor such as Vignette? Gregor J. Rothfuss, the COO of Wyona, an international, open-source CMS consultancy, explained, "Many proprietary CMS vendors have had good experiences with the ASP (application service provider) model. Instead of selling their product into enterprises and the mid-market, they sell subscriptions to their CM services, which are powered by their CMS products."Thats fine as far as it goes, but "the ASP model has brought questions of data lock-in to the fore. Many customers started to demand standardized ways to import and export their data from the ASP to ensure that the service provider would not be in a position to hold their data hostage."Another inherent benefit of open-source CMSes is that they tend to have broad platform support. Since they tend to be written in high-level scripting languages or Java, most come ready to run on your server platform. Still, as Byrne pointed out, "Open-source tools do generally lag in their native integration with Microsoft products, including the Windows desktop and Office integration. Commercial vendors generally dont shy from integrating closely with, say, MS Word." That said, "They do compare well (in features) and are increasingly being seen as a serious alternative," observed Boye. In addition, "most buyers are realizing that the implementation is much more expensive than buying the actual system. With this in mind, together with the uncertainty around (the future of) many proprietary CMS vendors, many buyers are considering open-source CMS," said Boye. How much more expensive? RedDot CMS 6.1 starts at a cool $55,000. With similar implementation costs, open-source programs much-lower-to-free software prices can be very tempting for the Web manager on a budget. So, whats a business Web administrator to do when all he or she wants is an open-source CMS system to make an unmanageable Web site manageable? Well, while we can not even begin to claim that this is any kind of definitive guide, heres our overview of some of the better known CMSes. First, before tackling any of these you should be aware of two side issues, which may not have occurred to you. The first is that since many of these programs are works in progress, you should be ready to get your hands dirty with the source code. If the program doesnt have a feature you need today, be ready to put it in yourself. Youll find, as Byrne has said, "open-source CMS community has become fractured into various camps centered principally around different scripting languages (e.g. Perl, PHP, Python, Tcl)." Unfortunately, "their adherents tend to promote them with a quasi-religious fervor despite the fact that none of the languages holds a decisively compelling edge for developing content management systems." In short, when picking an open-source CMS, it would be a very good idea to have programmers on staff who can handle the language its written in. There is some potential good news from the viewpoint of users, rather than developers. There is now an effort under way by the OpenUsability Project to bring "common User Interface Guidelines for Content Management Systems to provide a reasonable level of consistency to specific areas of the UI and promote good interface design." While Byrne is "somewhat skeptical about the ability of different projects to align UI (user interface) efforts," still "the important thing is that now we have a forum to discuss it." If this effort is successful it will make it much easier for Web content providers to switch from one CMS to another without losing much time. The second issue is that most serious CMSs depend upon a DBMS (database management system) on the backend. With the wrong DBMS, you could run into serious system performance problems. For example, Jason Perlow, founder and director of technology for the eGullet Society for Culinary Arts & Letters, a popular gourmand site with over 3 million page views a month reported, "eGullet has pretty much maxed out on MySQL performance." Worse still, "eGullet now has to be rebooted on a weekly basis, because MySQL wont release memory correctly." For most sites, worrying about millions of hits a month isnt a problem. For those that do face those kind of issues, having a DBA (database administrator) on call would be a good idea. Or, better still, consider a CMS that has a higher end DBMS as its engine. For example, Zope and Plone, which are related open-source CMSes built on Python, use CAs (Computer Associates) open-source Ingres DBMS. You should also consider exactly what it is that you want from your CMS. Unfortunately, there is no common agreement on what constitutes a CMS. There is the JSR (Java Specification Request) 170 and the Content Repository for Java Technology API (application programming interface). Despite the title, JSR-170 is less about Java and more about freeing CMS from being locked in to a specific DBMS. It provides an open API, which will enable any CMS to access data from a JSR-170 compliant data repository. Next Page: DBMS concerns are critical.