On Jan 4, 2010, at 10:54 AM, Alejandro Garza Gonzalez wrote: > I second John Fereira's comment re: putting this information into a CMS =) > For instance it'd be awesome to browse by language...
For the past week or so I have been trying to evaluate content management systems (CMS). Boy, there are bunches of them out there! Lot's of choice. The market is so much more mature in this area compared to librayr-specific open source applications. (Ironically, MyLibrary is/was sort of like a CMS in that it was intended to create certain types of Web pages based on the content of a database. No HTML knowledge required.) But the real question I want to ask is, "To what degree do existing CMS applications force a sort of vendor lock-in?" The vast majority of the applications I've looked, briefly, are PHP/MySQL combinations. This means some relational database is created, complete with application-specific tables, records, and fields. The PHP code then does I/O against the database to create and maintain website content. Cool. Suppose I invested my time and energy into one of these systems? For a long time it does what it is expected to do. Suppose then it breaks, becomes no longer supported, or a newer/cooler application comes along. How am I expected to get my content out of the first CMS and into second application? At least in Library Land we have MARC records (ick) to allow for some sort of migration path. I'm a bit hesitant when it comes to CMS application. Should I rely on the community at this point to come up with a solution? Yea, I can read the underlying database, create a cross-walk, do some magic, port from one system to anther, and hope to retain the better part of my functionality, but some things always get lost in translation. To what degree should website administrators be concerned with such things? Back-end content creators might simply see the easy-of-use of creating content. Geeky people, like me, might see a severe problem for the future. Y'alls input would be greatly appreciated. -- Eric Lease Morgan
