A panel of speakers presented on different aspects of the Evergreen ILS during today’s session. Speakers were:
The Sitka Perspective
- 54 libraries in BC
- consortia model
- think about the end user first
- multi-faceted selection criteria
- check with your colleagues about your ideas
- every ILS is a work in progress
- got equinox to teach them to fish
- now they teach others to fish
Why Open Source? The Community
- community is a powerful thing and driven by the community
- vibrant, growing community
- who do you want to be involved with?
- plus you can have control
- centralized policy and way to push out to staff computers
- localize view for search results
- easy to access data and pull data for reports and visuals
- mobile OPAC using an open web services API to add My Account functions (still in development)
Sneak Peak to Evergreen 2.2
- increased flexibility for MARC match set editor
- authority control sets, ability to customize control set
- Evergreen 2013 in Vancouver!
Matt Carlson, ILS Administrator, from King County Library System and Grace Dunbar, COO, from Equinox talked about implementing Evergreen ILS at King County.
Why a New System?
- many reasons, wanted to have more control over tool that everyone was interacting with
- a lot of development
- buy in is hugely important: demos with all branches, took Evergreen on a road show
- might provide new features
Are you ready for [the OSS]?
- and Is [the OSS] ready for you?
- is there a test server with a stable release
- do a gap analysis – software dependent? or workflow dependent?
- are gaps major or minor?
- major gaps = large development projects e.g. missing acquisitions module
- minor gaps = if missing, be creative e.g. receipt not printing exactly the same way
- Have the resources i.e. developers in-house? If not, you may have to outsource (how Equinox got involved)
- what do you really need?
- requirements: don’t have staff sit down and say what they want, use
- use cases – no edge cases, focus on what people do
- focus on outcomes, not processes
- be specific
Finding your development partner(s)
- engage the community via irc, mailing lists, conference
- evergreen conference is in Vancouver in 2013
- look locally (other OS projects, students, GSoC participants, etc.)
- write an RFI or RFP: if want OSS, rethink how RFI/RFP is written because companies don’t own software, provide service
- request a quote from a vendor
- may need consultant to help
Be specific in:
- hours estimates
- ownership of work
- interaction with community: make sure that contributions/development work will be accepted, local customizations can be the death of a system
- scope creep: important to assess input, but cannot just keep adding things
- be realistic about time for testing, clarifications and feedback
- best practices
- update your project plan
- build a team of subject matter experts
- provide real examples, use cases and mockups whenever possible
- never too soon to start thinking about your go live timeline and identify dependencies
- multiple clients/projects competing for time
- communication: keeping communication restricted to need to talk to people, while making sure community is kept in , while making sure the feedback can get back up in a meaningful way
- use cases and mockups: drawings can solve a lot of problems
- best practices
- 1-to-1 project managers: one from client side, one from vendor side
- clear, shared objectives (client/vendor/community)
- set priorities: something will get changed or not implemented, so set top 5 things
- create a test manual and use it
- engage staff and patrons in creative solutions
- will need a test server for testing and training
- have an exit strategy
Stay on Target
- still stick to priorities
- functionality is key, outcomes work?
- can always make tweaks later
- must have plan B, no plan survives initial contact!
- managers aren’t necessarily trainers: critical to find the right trainer
- set aside mandatory time: absolutely needed! Something that people will be interacting every day
- structured feedback is critical, so that feedback is meaningful
- have a plan for on-going training: new staff, staff that couldn’t attend, changes that come along that need refresher
- implement in phases, whenever possible
- have a fall back position: rollback to previous version, hot spare, offline mode, handwritten checkouts, smoke signals – communicate fall back plan to staff (aware of procedure, etc.), make sure patrons know you’re doing something new
- change is hard: celebrate
- Don’t… freak out
- Do… have fun, this thing you’re doing is really cool!
- Do… have a life outside this project
What’s Working and Not Working Now
- things have gone very well
- implemented many changes, several upgrades
- minimal downtime, had some bumps
- still some features still not there yet
Chris Cormack from Catalyst IT is one of the founders of Koha, an open source ILS, and one of the lead developers. He gave a talk on Koha today, but focused more on the free software, caring, sharing, and community.
- freed to run the program, for any purpose
- freedom to study how the program works, and change it to make it do what you wish (access to the source code is a precondition to this)
- freedom to redistribute copies so you can help your neighbour
- freedom to distribute copies of your modified versions to others
Why Free Software?
- end goal is freedom
- open source puts the emphasis on the development model
- free software puts the emphasis on freedom
- free software allows to weed, expand collection, and share
- pile of code and documentation
- more importantly, Koha is a community
- widespread, fairly sized community with159 committers from every continent except Antartica
- 35% women, partly because librarianship dominated by women, partly because of how it developed
- 11+ years of development and an average 3.7 commits/day
- New Zealand libraries had a suboptimum ILS, and was not legally allowed to fix it
- wrote RPS and got responses, but none worked for their requirements
- some requirements were unique to New Zeland e.g. had to work on phone lines because of electric fences
- decided to develop their own
If you would like to know more, there is a code4lib article on its forming.
What to do when things go wrong
Chris Cormack also gets extra thumbs up for encouraging library students to report bugs as part of their assignment by giving us chocolate! I will have to post our Koha vs. Evergreen Circulation Module Evaluation later.
I don’t normally post news items, but I was really excited to hear about the new version of evergreen (here’s the list of new features). I have been taking a library automation course, so I have been learning more about ILS, particularly OpenSource (OS) ones. I didn’t know how many OS systems were available, so I was interested in reading and hearing more. I was a bit disappointed when I heard there was no OS ILS suitable for large libraries, but even if the new version of Evergreen doesn’t quite meet those needs, I’m happy to hear that it’s moving in that direction.