In the meantime rel_3_0 is rapidly progressing towards a 3.0 release. San Ouest Provence library near Marseille have done a ton of work towards 3.0 and its looking pretty nifty. The thing I enjoy most about working on Koha is that almost all the features have come from requests from Libraries/Librarians, and have been specced by them. And in cases like San OP, and CCFLS, and Near East University (and others im bound to be forgetting), coded by them also. In essence Koha evolves in the way that librarians want to evolve, rather than in a way that vendors think is saleable.

I agree totally with needing to convince the people who are in charge of the money that OSS is a viable option. And im constantly suprised that the Library environment is as slow to accept OSS as it is. I think this is where Joshua was coming from when he was talking about Liblime. It was started as a way to shift some thinking, to make those who make the decisions see that it is viable. And for a lot of people, something isnt viable unless there is commercial support for it.

–TR

I’m not really familiar with Sirsi and Aleph, but last time I checked, Sirsi does provide RSS support and a pseudo-open api so you could likely roll your own OpenSearch support. We are an Innovative library and yes to RSS and the various metadata formats — it all depends on what modules you purchase from the vendor. III uses a very al cart model which I guess made sense at one time — but I find fairly annoying today since it means that any new development becomes a new product to purchase. In most cases, the costs are not steep — but you get a feeling that you are being nickled and dimed to death — which just seems silly when you consider what one pays per year for “service” and “support”. Field weighting — to a degree, relevancy — its gotten much better this year and is probably better than any other proprietary system I’ve currently seen (though still could improve a lot). Search of fixed fields — yes. You can even scope the catalog by items in the fixed fields — though in many cases, only a few of these bytes are would be useful for most folks.

>>Do the Sirsi and Aleph systems offer SMS
Again, not familiar with Sirsi and Aleph, but if you purchase it, III does offer such functionality.

As far as Koha, I’m currently running a copy of both Evergreen and Koha of our catalog as a way to evaluate the products. I’ve been working with our consortia and wanted to look specifically at the current OSS offerings to see exactly how feasible the current offerings are within a consortial environment. Unfortunately, this would be a catalog for just the consortia and would require our vendor making concessions to make the data more accessible for indexing outside their consortia software — which isn’t likely. So I’ve gotten pretty familiar with both over the past month or so.

>>2. I’ve yet to find someone who actually

Well, you’ve met one. As someone that’s written several servers and clients for the GIS community years ago — I can honestly say that I loath the protocol. I actually first worked with it as part of the FGDC nine years ago, when Z39.50 was (and probably still is) implemented to provide a national federated search for the geocommunity. I find the protocol expensive and dodgy when doing very broad queries or very complex queries and is generally implemented using only at the most basic level making it only nominally useful when querying most Z39.50 servers. In created our own search tools, I’ve found that working with SRU, OpenSearch and SOAP services much more fruitful. The problem, as you mention, is that Z39.50 is still the mostly widely used protocol — though this is changing as our content providers provide XML gateways for current federated search tools. In the past few months, we’ve had a number of our largest content provides submit documentation regarding webservices API that allow us to query as if on their system so I’m hopeful that we’ll be able to retire Z39.50 in the next 5 years or so.

While our vendor, III, does provide the ability to provide most of these services, what it doesn’t provide is an open API that can be developed to. This I think is I think the biggest benefit that OSS software offers. It might save you some money — though I’ve found that it really just redistributes where the funds are spent (Dspace for example allowed us to not purchase a vendor solution, but required the purchase of hardware support as well as a programmer’s time to manage the software initially. I think over each year, the cost is probably a push), but what it does do is give you control over your information. What I’d like to see OSS community push more is the openness aspect and I’d like the conversation move out of the developer’s community. To a large extent, everything that folks have posted about OSS is preaching to the choir. I’d hazard to guess that most folks that read this blog are developer oriented. The development community has agreed that these are good tools, that their development is a good thing. Now we need to convence our directors and administration. This is where the conversations need to occur and the proprietary vendor community is much more adapt at speaking to this group than the current development community.

I’ve known folks whose careers have suffered over the past two years for submitting alternatives to vendor products, so I’m not convenced that the library environment is open enough to support wide scale OSS adoption just yet. I’m not questioning the desire by those that develop the software — but the organization desire to allow it and support it. I work at an organization that has allowed me to work on a number of OSS projects — many simply outside of the library given my research interests — but I don’t think that my environment is typical today.

–TR

Do the Sirsi and Aleph systems offer SMS messaging for their patrons for overdue books, fines, etc.? Can you sort by ‘popularity’? How about limiting to ‘currently available items’? I wonder if you’ve even taken the time to actually look at the Koha ZOOM OPAC.

2. I’ve yet to find someone who actually understands Z39.50 and didn’t think it was an important standard for building search engines; standards-based search engines are key to interoperability, and as far as targets go, in the library world, Z39.50 is king at the moment.

3. I agree, the OPAC advanced search continues to be problematic, but keep in mind that Koha’s advanced search options you see on the NPL and other Koha ZOOM systems were speced out by librarians. The underlying tool certainly isn’t restricted to offering so much search granularity. If you would rather offer a simple ‘amazon style’ advanced search, that’s certainly possible.

I consider myself well informed and on the cutting edge of technology. I implemented Koha with the help of a great tech guy and am now giving presentations at our state library conference and school technology conference.

My desire to get more people involved with Koha, in particular, but OSS in general, is the thought that we can spread the costs out for building a system that meets the needs of our particular libraries.

I am fortunate in the fact that I have a supervisor that understands we haven’t given up the upkeep costs for our old system, just moved where the funds will be spent on the programming.

Having the catalog up and running is my first step, my next one is to learn to program in Linux so that I can add my own changes. I am thrilled with Koha and what it opens up for people to do. Long before I learned of Koha, I felt that we should be able to have a program like this in the librarian community. Librarians by their nature like to share, so I feel that Open Source is a great place to be.

I’ve actually seen these (I’d seen the anouncements some time ago on Code4lib) and was glad to see them. Your right — they do catch the public interface up with systems like Sirsi and Alepha (which have provided these types of interfaces for a while) and have passed systems like III in the short term (which OSU currently uses). The thought of the catalog as basically a Z39.50 front end does make me shudder a bit though — that’s one protocol that I’d personally like to see deleted from our collective vocabulary . I also like the SRU/SRW support (something vendors seem to have ignored completely) — but lets get back to my main point — even with these improvements, I still don’t see any ILS system that has what I would consider a current generation opac or outside what I would consider to be the status quo in terms of Opac design, which I think is still the problem. The advance search is a perfect example. It provides great searching granularity — but this isn’t want our patrons as asking for. They are asking for use to make searching easier and to make it inclusive. Transparency in the opac…kindof. And as I say — I have a feeling that if this problem isn’t remedied — libraries (or the organizations that fund libraries) will find it much easier to simply oursource this part of the process to something like OpenWorldCat, which I know is happening, at a couple of large research institutions in the states. So this direction may not be that bad — though I’d need to be convinced.

I think what gives me hope with Evergreen is that there is a very unorthodox aspect to it — something that has a very research oriented, yet practical feel to the current development. I think it complements the Koha development very nicely, which I’ve found to be much more practical and easier to set up and support for smaller organizations with limited support budgets.

But, with all that said, I still think that the time is ripe for libraries to re-invest in their own futures (be they with the current available systems or something new like XC) — I just hope it happens before time passes us by.

–TR

–TR

http://search.athenscounty.lib.oh.us

http://library.neu.edu.tr/

There are two production examples of the latest Koha OPAC. At the back end, it uses a high performance textual database engine (Zebra) that has native support for Z39.50/SRW/SRU, OpenSearch RSS feeds of any search, relevance ranking, field weighting, and stemmed queries. It includes faceted results and supports multiple query syntaxes such as CCL and CQL. The MARC support for searching is more comprehensive than any I’ve encountered (take a look at the advanced search at the Nelsonville site for instance). It’s got native federated search capability (which you can see at the NEU site) because it’s entirely standards-based … in fact, the OPAC is basically an enhanced Z39.50 client. Zebra also scales to tens of millions of records, and is in use in some very large bibliographic databases like the Danish National Library with something like 25 million records.

But anyway, your point is well taken. The research community hasn’t taken note of the OSS library systems. I’m thrilled that you see Evergreen as a potential for changing that within your community.

I don’t want to give the impression that Koha doesn’t serve a purpose for a niche group, but yes, I work at a medium sized academic library in the US and am thinking primarily of this group and larger. For this group, your aquisition, circulation, serials checkin and OPAC modules are steps behind what currently can be purchased within the proprietary community as well as a lack of an ERM module which becomes more important all the time. For small libraries, libraries that cannot afford a proprietary product, its a fine system. For larger academics, its got some warts. It’s also been around for a while. As you note, 7 years. I’ve seen it grow quite a bit in that time, but its never captured the interest of the research community here in the states.

Evergreen is changing that. I see Evergreen as being a year, maybe two (looking at their development path) from being viable for large consortia or research institutions, and primarily because they’ve been able to capture some buzz within the research community. There are currently a lot of libraries that are downloading the code and giving it a spin to see how it currently evaluates against their current systems. If this project was to fill in some missing pieces or garner a large development partner willing to bring it up in parallel to their current system, I could see someone going this route.