A proposal to Endeavor Voyager customers

If YPOW, like MPOW, is an Endeavor Voyager site, you’ve got some decisions ahead. Francisco Partners, naturally, would like you to migrate to Aleph, and I have no doubt that Ex Libris is, as I write this, busily working on a means to make that easy for Voyager libraries to do. But ILS migrations are painful, no matter how easy the backend process might be. There’s staff training, user training, managing new workflows, site integration; lots of things to deal with. Also, your functionality may not be a 1:1 relationship to what you currently have. How do you work around services you depended upon?

Since soon our contracts with Endeavor Information Systems will be next to worthless, I propose, Voyager customers, that we take ownership of our systems. For the price of a full Oracle (or SQL Server? — does Voyager support other RDBMSes?) license (many of us already have this), we can get write permissions to our DB and make our own interfaces. We wouldn’t need to worry about staff clients (for now), since we already have cataloging, circulation, acquisitions, etc. modules that work. When we’re ready for different functionality, however, we can create a new middleware (in fact, I’m planning to break ground on this in the next two weeks) to allow for web clients or, even better, piggyback on Evergreen’s staff clients and let somebody else do the hard work. If we had native clients in the new middleware, a library could use any database backend they wanted (just migrate the data from Oracle into something else). The key is write access to the database.

By taking ownership of our ILS, we can push developments we want, such as NCIP, a ‘Next Gen OPAC’, better link resolver integration, better metasearch integration, etc. without the pain of starting all over again (with potentially the same results, who is to say that whatever you choose as an ILS wouldn’t eventally get bought and killed off, as well?). Putting my money (or lack thereof) where my mouth is, I plan on migrating Fancy Pants to use such a backend (read only db access, for now, we still have a support contract, after all). I’m calling this project ‘Bon Voyage’. After reading Birkin’s post on CODE4LIB, I would like to make a similar service for Voyager that would basically take the place of the Z39.50 server and access to the database. Fancy Pants wouldn’t be integrated into Bon Voyage, it would just be another client (since it was always only meant as a stopgap, anyway).

What we’ll have is a framework for getting at the database backend (it’d be safe to say this will be a rails project) with APIs to access bib, item, patron, etc. information. Once the models are created, it will be relatively simple to transition to ‘write’ access when that becomes necessary. Making a replacement for WebVoyage would be fairly trivial once the architecture is in place. Web based staff clients would also be fairly simple. I think EG staff client integration wouldn’t be too hard since it would just be an issue of outputting our data to something the EG clients want (JSON, I believe) and translating the client’s reponse. That would need to be investigated more, however (I’m on paternity leave and not doing things like that right now 🙂

Would anybody find this useful?
It seems the money we spend on an ILS could be better spent elsewhere. I don’t think this would be a product we could distribute outside of the the current Voyager customer base (at least, not until it was completely native… maybe not even then- we’d have to work this out with Francisco Partners, I guess), but I think that that is big enough to be sustainable on its own.

10 comments
  1. A brave, and amusingly named, proposal.

    One that makes a great deal of sense, I hope it gains support.

  2. Ross,

    Wouldn’t E.L. consider the structure of the database as confidential IP?? Just wondering……

  3. Ross said:

    Joe, we already have access to the database schema. I wouldn’t expect us to be able to distribute Bon Voyage outside of existing Voyager customers. There would, in essence, be no installations from scratch (unless approval was given from E.L., of course).

    Having a pretty good knowledge of Voyager’s schema, there’s nothing terribly groundbreaking about it.

    Assuming that E.L. secrets aren’t exposed to the world, I don’t see much that E.L. could do. We paid for our ILS and when we don’t anymore support or upgrades, I’m pretty sure we can do whatever we want with it (besides distribute it).

  4. I don’t know if all Voy sites have similar contracts, but after rereading ours, there is no legal way we could use it after the contract was terminated. Well, at least our lawyers wouldn’t let us use it with the language that is in this contract!!! There is no mention of the database schema per se, so don’t know how much loophole we would have there?!

    It reads very much like an EULA where we only have license to use. We actually didn’t buy anything nor do we own anything. We must destroy, return, blah blah, etc. all software once the agreement is terminated.

  5. The idea that the structure of the database is proprietary
    is laughable – we all know what is in there, titles, and authors,
    and left anchored indexes that do not work very well.
    What Endeavor ought to do is to open source voyager; and focus their
    efforts on Aleph. Failing that they ought to NOW as they ought to have
    long ago is document the VACS protocol so we can develop alternate clients.

    just my yoctocents,
    Rick Silterra

  6. Ross said:

    Joe — we own our data. If we own our RDBMS as well, it seems we’ve got a little to work with. I mean, you may be totally right, but it seems a little fishy. What if Endeavor had gone belly up and nobody bought their assets? Anyway, all Ex Libris can do is say ‘no’. Then we’ll worry about contract law.

    Rick — it seems improbable that E.L. will open source Voyager (or Meridian or anything else they made) since I imagine something might potentially creep into Aleph. Regarding VACS: well, that’s another approach. Of course, Voyager’s middleware is so kludgy, I’m not sure that just building up anew from the database is a terribly idea.

  7. We were surprised to read this posting which suggests that Ex Libris or Francisco Partners wants Voyager customers to move to ALEPH. The reality is quite the opposite. Ex Libris has over a thousand happy Voyager customers, and we are actively supporting, enhancing and selling the system. We are not suggesting that now or in the future any Voyager customer migrate to ALEPH.

    Since the merging of Ex Libris and Endeavor two months ago, Ex Libris has more than doubled the development resources dedicated to Voyager. We will release Voyager 6.5 as planned in Q2 and are integrating Voyager with Primo and Verde. In addition, we are actively working on the development of Voyager 7.0, planned for release by the end of this year. Our product management team is already defining the requirements for future releases as well.

    Voyager is an integral part of the Ex Libris product suite, and our Voyager customers are extremely important to us. We will continue to support and enhance Voyager with the same level of dedication as the rest of our product suite.

    Nancy Dushkin
    Vice President of Marketing
    Ex Libris Group

  8. Andy Kohler said:

    Interesting and audacious, but I don’t see it as technically practical. This seems like a proposal to basically reverse-engineer the Voyager system; setting aside legal concerns, doing this safely is not simple. At UCLA we contracted for the VACS API documentation, and the interrelationships among functions can be very complex.

    I certainly like the idea of taking control of our own data… but figuring out all the details of how to write it safely into the Voyager schema seems the same order of magnitude as creating our own schema, free of any Ex Libris intellectual property issues.

    Nay-saying aside… I’m eager to see how this idea moves forward and definitely would consider participating.

  9. Ross said:

    Nancy, it would be nice to let the Voyager community know this, because I think the popular sentiment is that we’re on a dead end and we need to start thinking about alternate routes. There are a lot of rumblings and that helps feed the FUD. It seems like Ex Libris/Francisco Partners has to make a choice at some point, however, having two competing ILSes vying for the same space seems counter productive and unprofitable.

    Andy, I don’t disagree with your points. I had figured that Bon Voyage would use Voyager’s clients in the meantime. I am more concerned about working with the OPAC and patron empowerment issues (as well as NCIP type functionality – I would think this would be of value to UCLA, as well). But, really, your issues are why I figured all access would be readonly right now. Construct a framework to access the data and put in stubs for where future write access (or if Exdeavor supplied an API to work with…) would go. That way, if this thing has legs, we’re ready to run. And, if Voyager lives on forever and our support contracts remain intact, we’ve got a really useful, easy framework to build new services with our catalog data.

  10. Pingback: panlibus

Leave a Reply

Your email address will not be published. Required fields are marked *