So I feel like I just won a wrestling match with the Horizon Information Portal (our OPAC), and wanted to gloat and share what I’ve done. The rules of the match were ‘XSLT’, because HIP has a point of intervention where you can change display using XSLT (not always very easily). My stuff isn’t entirely deployed yet, but I’ll show you on our test server.
So I know there are some Ruby-ites who have read this blog in the past, maybe you could give me some advice? Sorry this entry is so long, man I write too much.
I’m having trouble switching my brain from understanding good class hieararchy design in a statically typed language (like Java), to Ruby’s world of ‘duck typing’ which I’m still not entirely comfortable with.
Someone on horizon-l wrote: (Since it’s a closed list, I leave out names of other people, but then i’m also avoiding giving credit and ‘google juice’ where it’s due. Any suggestions as to appropriate etiquette? I’m too lazy to contact anyone I’m quoting in a blog entry each time, so don’t suggest that)
But I hope we don’t have to do an actual RFP. I hear that those are quite expensive for the vendor. See the comments from Carl Grant, President & COO, VTLS, Inc., on the Hectic Pace post “No Roaming”, at http://blogs.ala.org/pace.php?title=no_roaming&more=1&c=1&tb=1&pb=1
It would be very interesting if some vendors and libraries got together to devise a standard alternative to the RFP that would meet everyone’s needs. Cheaper/easier, while still giving libraries the information they need. Does anyone know if there’s been any work in that direction?
Are/were RFP’s (or rather the P’s in response to RFPs) originally intended as a legally binding document and basis to sue, as one of the quotes below [not included here] suggests? I agree that seems unrealistic and unnecessary. Isn’t that the job of the actual contract you sign, anyway? (Whether the contracts we have do that job, or even what it would look like to do that job well–another topic).
Another post I made to horizon-l. I am trying to be a rational (rather than propaganda-spewing) voice of pro-FLOSS. Feel free to let me know if you think I’ve mis-stepped in any direction.
Another member posted:
and it may be that your library administration would never consider open sourcing your ILS....
To which I replied:
It is important to remember that Evergreen and Koha both have vendors who will provide commercial support. Realizing that an ILS with an open source license can also come with a support contract, I can’t think of any good reason for administrators to rule out open source ILSs as a class. That’s the real meaning of how open source and commercial can be “both/and”. Evergreen and Koha are both commercial software AND licensed under an open source license. .
Is there anything I’m missing about a rational reason to dismiss open source as a class, to specifically reject software that’s licensed under an open source license, preferring software that is not?
Now, just because there may not be any reason to reject open source as a class, that doesn’t mean that any particular existing open source licensed ILS is right for you. The way you evaluate it is the same way you’ve always evaluated software, some particularly pertinent criteria in this case include:
1) Total cost of ownership, naturally. Your support contract for the open source licensed ILS being evaluated, plus hardware, plus if the software doens’t yet have all the features you need/want, the cost to pay a vendor (or hire staff) to add them. Compared to total cost of ownership of your other (proprietary) options.
2) As with any product, strength and staying power of the vendor. While both Koha and Evergreen have vendors providing commercial support, you want to ask yourself the question, how financially and otherwise organizationally healthy are they? How likely are they to stay around for the long term? As you would with any vendor. (And the market has of course seen that there’s no guarantee of continued viability of vendors of proprietary software either).
There will be negatives and positives with any particular solution you evaluate, which have to be balanced against one another and against the other options. For open source or proprietary. Open source by it’s very nature comes with some more _potential_ positives—if the currently existing vendor _does_ go under or decide to stop supporting the product: a) You can still keep using the software as long as you want without permission from anyone (that’s the nature of open source) b) Another vendor(s) can spring into existence to support and/or further develop the same product, without any permission from anyone, with full access to the source code (if not neccesarily the institutional expertise). Another unique possibility, if the open source ILS market continues to develop, is that there could
Many of these unique benefits to open source are just _potential_ in the ILS market at the moment, there are no guarantees—if you don’t want to consider these potential benefits yet, you don’t have to: You can evaluate open source ILS options head-to-head with proprietary options, without giving any weight to the potential unique benefits of open source. I think Koha and/or Evergreen are quite possible to still come out looking good in such a comparison.
But when you undertake the difficult calculus of evaluating what software is best for you among a collection of non-perfect options, I don’t see any reason to exclude open source licensed options from consideration altogether.
So, I’m afraid I’m joining the ruby cult. Or at least learning ruby.
I like a lot of things about it (so nice to work with a really object oriented language, where the community writes really object oriented code), and don’t like some things about it (still suspicious of ‘duck typing’, the community doens’t seem to write very good documentation).
But my question is: How are “mix-ins” any different than multiple inheritance? What am I missing? mix-ins as a feature seem to be exactly no more and no less than multiple inheritance. Is it just the convention for how to use them (just a few methods focused on a particular function) that makes them “mix-ins”? Like, mix-ins are mult inheritance used in a certain way? Is there something I’m missing?
I want an email client that offers a ‘reply to list’ function in addition to ‘reply to author’ and ‘reply to all’.
Even more importantly, I want it to put my message compose window in bright red or something whenever I’m replying to a list by default ‘reply’, which it should be able to detect.
Oh, while we’re at it, let me pick own my default-reply on a per-list basis.
Is that too much to ask? From how often I see people making this mistake (sometimes embarressingly), I’d guess this is one of the biggest email usability issues (right after spam prevention).
Email list servs don’t always use list-* headers that would make it easy for a client to do this but I can think of some heuristics that could succesfully identify list traffic much of the time. Like when the “To:” header matches the “Sender:” header, or when the “To:” header matches the “Reply-to:” header–most of the time that’ll be a mailing list, and most mailing list messages can probably be caught by rules like this.
Hadn’t seen this blogged yet anywhere I read, so I’ll cite it, even though I know some people are annoyed by just pointing to existing resources in your blog.
Has some good practical advice for attempting to integrate institutional repository and ‘e-print/pre-print’ content into your link resolver.
Shigeki Sugita et al.
Linking Service to Open Access Repositories
Volume 13 Number 3/4 ISSN 1082-9873
Or: There’s no such thing as a free lunch, but some meals are still better than others, even on a budget.
The horizon-l list has rather incredibly turned into “open source ILS for newbies” lately.
Someone posted [paraphrased, it’s a closed list] “I know open source isn’t free, despite what everyone says. We don’t have much in-house technical expertise, and we’re worried that the open source ILSs don’t have the feature we need from a mature ILS yet. What can we do?”
I have been thinking lately of a library subject guide system. A really great utopian library subject system. I imagined a system where librarians would list databases and other resources (chosen from Metalib and/or some other central repository of our stuff, when possible; URLs entered manually when not); also add other narrative text as desired. And organize the whole thing coherently somehow, without knowing any HTML.
And then we’re kind of at the kind of subject guides most of us have today (but perhaps easier to create), but then there’s all sorts of cool new features (I really hate saying ‘2.0’) we can imagine: Continue reading “Library Subject Guides (does this have something to do with Sakai?)”
New product apparently expected towards the end of 2008.
1) New product will be based on Unicorn. Will moving from Horizon to Unicorn be no easier than moving from Horizon to another vendor’s ILS…. will it be harder than moving to Evergreen?
2) Prior to the end of 2008, will we have a few more more succesful implementations of open source ILSs, in libraries comparable to our own, to give our own timid libraries enough confidence to make that move? Fall 2008 instead of Summer 2007, the previous (well, the latest previous) Corinthian release date—gives us more time.
The biggest winner of this announcement is Evergreen and Koha.
Oh, and all the rest of us too. Sometimes the only way to get off the sinking ship is to be pushed.