February 2nd, 2010 Brian Herzog
Not having a cell phone, I can be a bit behind when it comes mobile apps - but this is still cool even to tech-no's like me.
My former co-worker Chris pointed out the iPhone app RedLaser, that turns the iPhone's camera into a barcode scanner. The app was designed to do instant price checks while you're in a store, to see if you could buy something cheaper online.
He also found that the database it scans can be customized - which means it could be modded to search a library catalog (among other things).
So a patron with an iPhone (or an Android) could be shopping in a bookstore, see a book they'd like to read, and instantly scan it to see if it's available at their local library. Great stuff.
But wait, there's more...
Another colleague, Scott Kehoe of NMRLS, posted about making customized versions that can search the MVLC (my library consortium), MassCat and the NOBLE consortium catalog. His post shows how he did it, links to Delicious for the customized databases, and explains how you can customize it yourself.
I think this is a great thing to promote to patrons, but they need to be careful about walking around bookstores scanning barcodes. I've heard many stores will throw people out if they appear to be doing "research" (recording a store's prices or looking for country of origin). Also, about this app, one bookstore owner was quoted as saying:
If I see any lecherous internet bottomfeeders using my store as a display case for a discount website, I will politely ask them to leave.
As the world of mobile devices becomes more compatible with the world of ebooks, the next step will be to create customs searches of places like Overdrive and Project Gutenberg, so that patrons can not just locate but also download the desired book immediately. I tend to think instant gratification is not a good thing, but in this day and age, it is certainly easy to support.
For a few more library-related apps, check out Aaron's post on Walking Paper.
Tags: android, app, apps, catalog, cell, devices, iphone, libraries, Library, lookup, mobile, phone, phones, public, redlaser, search
December 3rd, 2009 Brian Herzog
Since I first heard about it, I've been yapping on about the Mass Libraries Open Source Project, trying to publicize and chronicle its progress. It became official a couple weeks ago, when the membership of the three consortia involved (MVLC, NOBLE and C/WMARS) each voted to go with the Evergreen ILS.
Now that the software has been chosen, the next step is to define the features we want. See, with open source, you can shape the software like clay to mold to your situation, rather than being handed someone else's idea of what you need.
In order to figure out what we need, the December issue of the MVLC Connections newsletter [pdf] asks staff to create an list of ideal features (questions below). Obviously, one source of ideas is likes and dislikes of our current ILS (SirsiDynix's Horizon), but they're also encouraging staff to pull great ideas from other industries and websites - at this point, the sky is the limit.
I think we should also ask the larger library world - what do you think are important ILS features? If the questions below were handed to you, how would you answer? A quick internet search found some information on what an ILS/OPAC should really do. But if you have any ideas, please leave a comment below.
- List the three most annoying “features” of Horizon in regards to Your Specialty and describe how they could be made less annoying.
- What process or activity in Your Specialty is the most time consuming or frustrating and describe what it is that causes the problem. Is there something that the system could do to help?
- Are there any procedures or policies in Your Specialty which seem cumbersome or awkward because they are based on what the system can do and not what is logical or needed?
- As you are using the Internet copy the url or print out those sites which are exceptionally user-friendly or really cool. Also, are there any times when tie-ins with communication tools such as Twitter, email, or a blog could be useful to Your Specialty activities?
- You are the librarian on the Starship Enterprise. Everyone knows that Your Specialty can not be fully taken over by the ship’s computer...it is much too complex for that. However, as long as you walk the computer through the process, the computer can do a lot of the nit-picky stuff for you. Outline some of the most tedious or complex procedures that you currently do and show where you need to "ask" the computer to do something and what it is that it should do.
I'm also giving this a try on the new Unshelved Answers website. It's similar to other question-and-answer websites, but is a forum specifically for librarians. I didn't find any related questions, so I asked one, but was informed it might get deleted because "we prefer questions that can be answered, not just discussed."
This will be a long process, but at some point I'll try to make sure all the various features and pulled together in a single list. Yay for having input.
Tags: catalog, design, features, functions, ils, libraries, Library, opac, open source, oss, public, software, unshelved answers
October 29th, 2009 Brian Herzog
I attended the 10/29/09 information session for the Massachusetts Open Source Project. My notes are below, and I hope they make sense - there were about six speakers, and all their presentations slightly overlapped, so I tried to distill things into a coherent single overview. The presentations started with the basics of open source software, then got into the specifics of the MA project.
Massachusetts Open Source Project
Information Session - 10/29/09
The Open Source Task Force consists of three MA networks (and MBLC) looking to cooperatively move to an open source library system. The key personnel of this task for so far are:
- NOBLE: Ron Gagnon, Elizabeth Thomsen,
Mark Martha Driscoll
- C/W MARS: Joan
- MVLC: Jason Stephenson, Tracy Swaim, Larry Rungren
- MBLC: Paul Kissman
Why even look at an Open Source Library System (OSLS)?
Open source software is free. However, like "free kittens," there's still the ongoing maintenance costs (which is true whether you paid for the kittens or got them free). Free = freedom to:
- download - you want it, you got it
- view - (seeing the source code is huge) everyone can see exactly what's happening, and nothing is hidden
- share - have as many copies as you need (no registrations or license fees)
- modify - the code can be edited (but do you know what you're doing?)
- you also get more freedom in support options - you can support it yourself, or contract out with numerous companies, or rely on the user community for help. This is great because you're not locked into one provider
Open source has a participatory culture - people want to develop and share their improvements to make the system better, not to make money (people can charge for support services, not the software). The online community of the internet makes this possible, and so does "versioning software" (keeps track of what version you have, what's new, and whether or not you need to upgrade).
Open source communities are generally self-defined - you make yourself a member by showing up, participating, and contributing:
- software development
- bug fixes
- testing (looking for bugs)
- documentation and training materials (tech and style/design skills needed)
- spreading the word
- discussion of the software, both official and unofficial (no artificial proprietary limits on what you can say where)
This is messy, yes?
- tight controls protect the core code (you can edit your own version, but changes to the general software get reviewed and approved to be included in the next release)
- Release managers review and decide what changes will go into each new release of the core code
- Committers are developers with the ability to add (commit) new code to the core
- these positions must be earned by contributing and participating
Fear of Forking - forks are separate, increasingly incompatible versions of the software
- although it's possible to customize your own software, as soon as you change it, you're unique and the community is less helpful (because their core software is different than yours)
- there is pressure to work within the community - there are guidelines for discussing and submitting changes
- but when one group funds development, everyone benefits from that investment
Who uses OS?
- everyone (at least indirectly) - Amazon, Google, US Navy, Gov. of Canada, Ticketmaster, Firefox, ebay, Open Office
- many companies and organizations run a combination of proprietary and OS, and contribute back to the OS community
Vision for the MA Open Source Project
Wouldn't it be great if all networks in MA were on the same ILS? This would allow
- collaborative staff training, patron ease of use, financial cost sharing
- leveraging state and local resources during this time of statewide budget problems. Instead of sending money out of state (to vendors), keep it in-state by providing jobs for support and development
We are all frustrated with traditional vendors. Despite this, well over $500,000 goes out of state each year for systems that do not meet our needs. Open source software has proven itself as a successful business model (see above partial list of open source software, and the companies that rely on it). Also, open source library systems have proven themselves to be stable and practical (namely, Koha and Evergreen).
What are the advantages of adopting open source software now?
- we can engage end users in design and testing
- we will have control over development and can establish our own priorities
- collaborative development and support will reduce overall costs
- the openness of open source means we can adopt a transparent development process
- the openness also avoids locking us in to one vendor (multiple support companies out there)
- we're not "buying blind" - staff can kick the tires and evaluate all aspects of each system before we choose (all three networks have downloaded Evergreen and Koha and played and tested - don't need to take salesmen at their word on how the system works)
Creating the system we want
The task force reviewed existing ILS' and determined that no proprietary system meets our needs - they are all very expensive, very slow in development, falling behind patron expectations, and there are concerns about corporate stability (Horizon got cancelled, Sirsi is being sued).
Libraries in Georgia created Evergreen 4 years ago, because all vendors fell short after a comprehensive review. Instead of developing a new system for Massachusetts, we adopted Georgia's system and invited all 9 MA networks to participate. C/W MARS, MVLC and NOBLE opted in.
These networks were awarded a $412,000 LSTA grant from MBLC to Investigate, Select, Develop and Implement an open source library system to replace the current systems.
- review current state of each network
- brought in both LibLime (Koha) and Equinox (Evergreen) for demos
- did lots of independent research and local testing (since a traditional RFP wouldn't suffice)
- talked to actual users of both systems
Selection - Decision Criteria
- Multiness: ("have it your way") ability to support multiple sets of circulation parameters and network transfer rules
- Scalability: how well can the system handle the load of many large libraries and networks
- Extendibility: ability to play nice with other software libraries rely on (self-check machines, time limit and print management software, museum pass software, etc). Also, how well can the system be customized to meet our needs?
- Current customer base: are the current users like Massachusetts networks? Evergreen came out ahead in this criteria - Koha user seemed to use one set of rules for all systems
Based on these criteria, the Task Force recommended Evergreen as better suited as a consortia system
A lot of data came from Marshall Breeding's librarytechnology.org - some stats:
- Koha: developed in 1999 in NZ for small libraries with limited telecom capacity
- Evergreen: developed in 2006 in GA for 252 libraries
- Evergreen customers are more like us (MVLC has fewest bibliographic records of the three systems, but more than the biggest Koha customer)
- Of Liblime customers, 28 have migrated away from LibLime, but 21 still use Koha and 7 moved to Evergreen
- 0 libraries have migrated away from Evergreen
- Both systems run on Linux, Apache (my)SQL, Perl
- Both have mature circulation and cataloging
- Both have immature serials and acquisitions
- flexible hierarchy, allows for different levels of library structure (library, branch, system, network, consortia)
- Rule and parameters are associated with hierarchy (can apply to different levels)
- Cluster-friendly architecture - allows for load-balancing throughout entire network
- Separate loan rules for each branch
- Most other settings are single system-wide (funds, notice templates, calendar [days open/closed], borrower mandatory fields, ceiling due date)
- Hierarchy structure coming in v3.2 - but a lot of this is in the form of "yes, it will be able to do that" but no one has seen it yet
Evergreen is the winner for us
- Unanimously selected by three networks
- Can provide scalability and meet the complexity required by our networks
- released under the GPL - designed to spread beyond Georgia
- designed from the ground up to support and scale to a state-wide library consortium
- Customer list most resembles our networks
- The developers asked the right questions: "is the data driving the procedure or is the procedure driving the data?"
- Developers worked with front-line library staff to develop all aspects of software
Where do we go from here?
MassLNC (MA library network cooperative) created by administrators of the 3 networks to drive this project - http://masslinc.cwmars.org
In the First Year:
- Hold information sessions on open source and this project
- Get network approval of Task Force recommendation by Boards of each network
- Hire a Project Coordinator (job listing)
- will take the load of network staff
- will work closely with networks to guide the project moving forward so that systems are as similar as possible
- will review development options
- be point of contact between networks and vendors
- Track development of ILS software
- library systems on/moving to Evergreen:
- Using Koha:
- Draw up development requirements via user involvement
- establish functional requirements, which will be compared to what the system can do
- there will be an online database of potential features - OpenRFP, but not quite ready
- committees within networks will evaluate current Evergreen modules and suggest improvements or modifications
- survey patrons to get their input, to rank what is important to them (placing holds on all items at a time, or social tagging, etc.)
- Develop helpdesk and intranet support infrastructure and procedures
- Develop database migration tools and procedures
- Beginning of development - can hire support vendor (Equinox [spin off from PINES], Alpha-G in Utah (lots of former Sirsi staff), local developers, train/hire network staff, work with other Evergreen users on joint projects)
- Continue development
- Staff training
- Data migration of first network (likely MVLC) - spring/summer of 2011
- Migrate other two networks afterwards
- Get more MA networks involved
- Creation of statewide support organization
We will be the "owner" of our system, not a "renter." We won't have a landlord to rely on, we'll make our own decisions on our schedule, depending on resources - but with more control comes more responsibility. Think of open source as buying a fixer-upper - sound underneath, and we can customize the surface.
- Cost savings will be in
- not having vendor contracts
- running system over internet, instead of dedicated telecommunication systems
- OS won't solve every problem we have
- We'll still have policy issues, but we will have more control over implementing our resolutions
Questions and Answers
How do we develop modules if we can't change the core code?
-We'll play by the rules of module submissions, and we don't currently have plans for radical changes. And we plan on working with other major customers
Based on research, what are the function that are ready to go, and which need more development?
-Basic modules are in a pretty good place. Acquisitions and serials are in development. The two areas of most concern are workflow issue with the circ client (we'd prefer it as a browser) and the "curb appeal" of the opac - King County is also focusing on these two modules. Also, we need to make sure it works with 3rd party software and Virtual Catalog
Evergreen works across the internet - are we susceptible to downtime and attacks?
-We have more problems now with dedicated circuits than internet connection. As for attacks, Evergreen won't make anything different - firewalls will still protect us like we do now, using SSL encryption between servers
From individual libraries point of view, does PC requirements change?
-As long as it runs a web browser, you won't need upgrades
Updated info on how King County migration went?
-They're still in the thought process. They got a $1M grant, but haven't really started development. They're just a little ahead of us.
Have any Evergreen libraries migrated from Horizon or III?
-Yes, and this information is readily available (unlike with proprietary vendors). No migration is flawless, but the system that gives the most problem has been from Koha. Lots of Alpha G employees are former Sirsi employees, so they are familiar with our systems. Evergreen also has a development roadmap, to show where they plan to be in the coming years and beyond.
On the timeline, Spring/Summer 2011 is the first network - when are the next? And how does this affect the network fee structure?
-Depends on how well the first migration goes.
-Initially, it won't affect fee structure at all - they should stay the same until things stabilize, and then will likely decrease when the support system has been established. In the short run, maintenance dollars will go towards development, and then shifted back to support.
Will it require additional tech support within individual libraries?
-Probably not, in fact perhaps less
Will these presentations be online, with links to what Evergreen looks like?
-It will be available on the MVLC wiki, everything will be on the MassLNC website. An Evergreen demo is also available on their website.
Since Georgia did this, has there been research into what other states have done as far as statewide proprietary systems?
-The shortcomings of proprietary systems are pretty much the same across all vendors, and the biggest shortcoming is in "multiness" - the number of sets of rules you can use. The only system that could have met this criteria was Horizon 8, which was cancelled and now Sirsi is being sued because their resulting product is technologically inferior to the Horizon 8 specs.
Can you talk more about the development of the Acquisitions module?
-It is one of the modules in the later stages of developments, and has a lot of activity. We can mirror the good features of other systems, like Overdrive's automatic purchasing when hold/copy ratio reaches a certain level. We and King County plan on doing a lot of work on this.
What are the downsides of OS, and is anyone considering leaving Evergreen and why and how easy is it to transition away from Evergreen?
-It is a relatively new system, so it's not fully mature in all areas. It's a different involvement model, and change is always tough, especially when it required a complete rethink. It will require more involvement from us. An anti-downside is that we won't have to bend our policies to fit the system anymore (as much). Two people are thinking of moving from Evergreen to Koha because they are single libraries and Evergreen is more complicated than they need, but since it's all open source and standard formats, migrating shouldn't be a problem.
Is each network voting in November and is that all we need for a green light?
When you spoke to other libraries, how did they negotiate what developments they wanted and got - how did they set priorities for development?
-Evergreen has a document for the process for an enhancement, that gives guidelines for how much work is involved, how long certain changes take, etc.
Why didn't the other six networks want to join in now?
-Minuteman is taking on major RFID project and so it's not the right time to switch vendors. Others are happy with their current systems than the three of us are. One network has a homegrown system and is skeptical of OS. Many didn't want to be the first to do it, so are waiting to see how it goes for us - especially in the areas of staff reconfigurations and cost savings. Other networks don't have the same economic pressures, so can sustain their system for a few more years, because their systems are little newer than the OS3's networks. One network just launched a new opac to address curb appeal.
Do you get the impression that we'll have a lot of influence since we're three networks working together?
-we'll be better off working together because we'll have more funding, but it's also why we're trying to work with Bibliomation, King County, and whoever else we can. We're also trying to talk up developments now, so they might be ready by the time we come online.
What does the new cluster of networks look like?
-roughly half public libraries in the state
Question for attendees: What do people want to see?
-better opac (less embarrassing)
-happy that the focus in on the patron
-staff-time saving features (but staff can be trained to do workarounds)
-getting the whole state together for better resource sharing and interlibrary loan
-a system that doesn't slow down during peak times
UPDATE 11/5/09: There's a great summary of the project so far in the Nov09 issue of the MVLC Connections newsletter [pdf] - it includes more stats that I wasn't able to get while I was typing during the session.
Tags: catalog, evergreen, ils, integrated, Koha, libraries, Library, maosp, masslnc, opac, open source, os, oss, public, software, system
August 4th, 2009 Brian Herzog
I've mentioned this in passing, but here's some insider information on the prospect of Massachusetts libraries adopting an open source state-wide catalog.
The update comes courtesy of my consortium's monthly newsletter, the August 2009 MVLC Connections [pdf]*. It's a good article, reviewing current OSS ILS options, how they differ from traditional library catalogs, and what it will take to get one in place.
However, one paragraph set off some alarm bells:
Once the platform has been selected, the second phase of the project – assessing user requirements and system development needs - will begin. This is the point in the project where library staff will begin to be heavily involved.
Here's what bothers me: shouldn't "assessing user requirements and system development needs" be necessary to select a platform in the first place? I'm just worried that the plan is for a lot of major decisions to be made before there is any input from front-line librarians. It's kind of like your mechanic deciding with the dealer which make and model of car you have to buy, then asking for your input on the color and whether or not you want power windows.
But don't get me wrong: this is great news, especially for MVLC libraries (the ILS we're using is woefully dated and inadequate). However, with this project as big as it is, changes won't happen until 2011 at the earliest - which means the time patrons and staff have to continue to put up with not-good-enough software is being measured in years instead of months.
So if I'm sounding like Veruca Salt**, it's because I have to apologize to patrons on a daily basis for such a difficult catalog interface. I know there are much better systems out there, and I can hardly wait. I don't care how, I want it now.
Read more about the pros and cons of OSS (via iLibrarian)
*Dear Irony: You have to download the newsletter from my server, because the original, containing this article about the future of libraries, is locked up on a password-protected "wiki," which no one is allowed to edit.
**I just noticed that the wall in the background of the photo is the same as my website background - huh.
Tags: c/w mars, catalog, catalogs, evergreen, hip, ils, Koha, libraries, Library, mvlc, noble, opacs, opan, open source, os, oss, public, search, software
January 29th, 2008 Brian Herzog
Last week, the Greater Manchester Integrated Library Cooperative System (GMILCS to its friends) became the first large library system to integrate Chili Fresh into its online catalog.
I talked about Chili Fresh last September, when I was helping with some initial testing and design. Unfortunately, my consortium was not in a position to pursue the product at the time, so I'm glad the progressive and flexible GMILCS was able to step in for final testing and be a beta site.
Chili Fresh is neat because it doesn't require sweeping changes to a library catalog to bring about improvements. It is a plug-in that allows patrons to add comments and reviews of books right into the library's catalog, for other patrons to read. We need more tools like this.
A link to the ratings and reviews is shown on both the search results page and the item details page, and the reviews are displayed in a popup window. Although all the data is stored on Chili Fresh servers, the way it is displayed can be customized to match the look of the catalog.
This concept not only provides a valuable readers advisory service, but also gets patrons engaged in the catalog - and, by extension, the library.
I don't want to sound like I'm selling this product - I'm not. But I am selling the idea. ILSs are huge, cumbersome and complex, and often wholly lacking in necessary features. Small plug-ins like this (and LibraryThing for Libraries) add tremendous utility to the tools we provide our patrons, at relatively little cost and involvement from libraries.
A screenshot of the Chili Fresh admin screen is shown here - click to see a larger view, and for a description of what it allows you to do. More screenshots are on flickr.
Please leave a comment if you know of other tools like this - I'd like to make a list of catalog plug-in tools, because until ILSs catch up with patron needs, libraries need a way to provide these features.
catalog, chili fresh, chilifresh, gmilcs, ils, libraries, library, opac, plug-in, public, reviews
Tags: catalog, chili fresh, chilifresh, gmilcs, ils, libraries, Library, opac, plug-in, public, reviews