You could do something like what I did and run your own data backend and use whatever you need to/have to to display content.
Our website is just static HTML, CSS, and Javascript. Everything dynamic/data-powered is javascript that is pulling from a centralized API (written using grape: http://intridea.github.io/grape/). We can move the website to some cloud provider, into a central IT-managed system, or elsewhere and it won't break. I originally presented the concept at code4lib 2011 (slides: http://www.slideshare.net/MrDys/lets-get-small-a-microservices-approach-to-l ibrary-websites), but it's in production now. -Sean On 8/14/13 9:21 AM, "Joshua Welker" <wel...@ucmo.edu> wrote: > Does anyone have any suggestions as to where the library should or should > not compromise when it comes to using an institutional CMS rather than a > custom library one? We are going through this process right now. Our web > pages are currently all in static HTML and LibGuides. I am wanting to move > to Drupal, and campus IT wants us to move to their Adobe Contribute > platform. AFAIK, Contribute does not allow for any server-side scripting > and does not have any sort of plugin system, and I am very concerned that > Contribute would harm the library's ability to effectively integrate its > online resources into a single web portal (server-side caching, indexes, > scheduled tasks, etc). > > I know the answer to this question is "it depends," but I am hoping others > can share the fruits of their experience. > > Thoughts? > > Josh Welker > Information Technology Librarian > James C. Kirkpatrick Library > University of Central Missouri > Warrensburg, MO 64093 > JCKL 2260 > 660.543.8022 > > > -----Original Message----- > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > Jimmy Ghaphery > Sent: Tuesday, August 13, 2013 5:49 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] LibGuides: I don't get it > > I have followed this thread with great interest. In 2011 Erin White and I > researched many of the issues the group has been hitting on, demonstrating > the popularity of LibGuides in ARL libraries, the locus of control outside > of systems' departments, and the state of content policies.[1] > > Our most challenging statement in the article to the library tech > community (which was watered down a bit in the peer review process) was > "The popularity of LibGuides, at its heart a specialized content > management system, also calls into question the vitality and/or > adaptability of local content management system implementations in > libraries." > > One of the biggest challenges I see toward creating a non-commercial > alternative is that the library code community is so dispersed in the > various institutions that it makes it difficult to get away from the > download tar.gz model. Are our institutions ready to collaborate across > themselves such that there could be a shared SaaS model (of anything > really) that libraries could subscribe/contribute to? The barriers here > certainly aren't technological, but more along the lines of policy, > governance, etc. > > As for Research Guides in general, I see a very clear divide in the > public/tech communities not only on platform but more philosophical. From > the tech side once it is all boiled down, heck why do you even need a > third party system; catalog the databases with some type of local genres > and push out an api/xml feeds to various disciplines. From the public side > there is a long lineage of individually curated guides that goes to the > core of value of professionally knowing one's community and serving it. > > [1] https://ejournals.bc.edu/ojs/index.php/ital/article/view/1830 > > best, > > Jimmy > > > > On Tue, Aug 13, 2013 at 11:13 AM, Galen Charlton <g...@esilibrary.com> > wrote: > >> Hi, >> >> On Tue, Aug 13, 2013 at 6:53 AM, Wilhelmina Randtke <rand...@gmail.com >>> wrote: >> >>> There's not a lock-in issue with LibGuides, because it's used to >>> host pathfinders. Those are supposed to be periodically revisited. >>> One of >> the >>> big problems is that librarians will start a guide and never finish, >>> or make one then never maintain it. Periodically deleting >>> everything is a good thing for pathfinders and subject guides, and >>> people should do it anyway. No one's talking about tools for >>> digital archives, which have >> lock >>> in issues and are way more expensive. >>> >> >> Lock-in doesn't have to be absolute to be effective, it just has to >> has raise the bar sufficiently high to make users think twice about >> migrating away. >> >> This applies even if the data to be moved is transitory and constantly >> changing. For example, if a library has been diligently updating their >> pathfinders, but wants to switch platforms, if there were no way to >> export them to load into the successor system, the effort of redoing >> them or doing a lot of copy-and-pasting could be prohibitive. >> >> As a general statement -- and I know that this battle has been >> bitterly fought in the ILS space -- I believe that *all* library >> software services, whether based on F/LOSS software or proprietary >> software, should provide a way for the library to obtain a full dump >> of their data, in an accessible format, at no additional charge. >> >> I see that LibGuides advertises the ability to make local backups of >> individual pages and also provides (via a paid add-on module) an XML >> export function. I don't know if SpringShare will also provide free >> one-time exports on request, but I would hope they do. >> >> Of course, even if one has the data in hand, data migrations can still >> take a lot of time, effort, and expertise. >> >> Regards, >> >> Galen >> -- >> Galen Charlton >> Manager of Implementation >> Equinox Software, Inc. / The Open Source Experts >> email: g...@esilibrary.com >> direct: +1 770-709-5581 >> cell: +1 404-984-4366 >> skype: gmcharlt >> web: http://www.esilibrary.com/ >> Supporting Koha and Evergreen: http://koha-community.org & >> http://evergreen-ils.org >> > > > > -- > Jimmy Ghaphery > Head, Digital Technologies > VCU Libraries > 804-827-3551