This was largely posted on the Georgia Library TechTalk list-serve. Based on off-list comments several people indicated they would love to comment but, feel they may face some form of retribution. Due to that concern I am posting an edited version where anonymous comments will be allowed. I sanitized my library, region, and boss's name from this version.
After getting several emails concerning the rumor that the we will be migrating to the free open source Koha Library System I felt it best to respond to the Georgia library community as a whole to address the rumor. As many of you are aware, we have submitted a letter of intent to leave the Regional Library System and form a single-county library system as of July 1, 2008. My boss has very succinctly covered the reasons why via the Directors Discussion List, and, in person, at the recent RPLAC meeting. While joining PINES is an option, we have legitimate concerns, that I will list in greater detail below. We feel it is in the best interest of our patrons to investigate other options. We have not made a final decision on whether to leave our current circulation system, switch to Koha, or to join PINES. We have decided to explore all options including evaluating whether Koha is suitable for our patron's needs. With that said up front, I'll go into the reasons why we are considering Koha.
Currently, the Regional Library System runs a Sirsi Unicorn circulation system. This system has been in place for 10 years and has served the needs of the library system extremely well. As with any software there have been problems, but day in and day out, it quickly checks the books in and out. We currently pay less than $9,000 in annual maintenance to continue running a Unicorn server. Unfortunately, in leaving the regional library we have to look at every expense. The Library will be facing a reduction in staff. The amount of money we currently pay for a circulation system could be a part-time staff member. Those of you who attended the recent training hosted on behalf of the Georgia Council of Public Libraries can attest that we have sufficient skilled staff to tackle a technology challenge. In fact, I'll say it because I believe it true, I have the best technology staff of any library of which I am aware. With that said I have little doubt in our ability to make a free alternative such as Koha perform.
Now I know you are saying to yourself "isn't PINES free?" Yes, that is true, but I have one very large problem with the library blindly joining PINES. Our current regional system has been in existence for 60 years where it has progressed from manual circulation system, to CLSI LIBS Plus, and, presently, Sirsi Unicorn. In those years, we have developed a large set of cumbersome policies and procedures in the spirit of getting along as a region. Yes, we revise policies frequently, but that doesn't change the fact that we do lots of hoop jumping to the inconvenience of our patrons to satisfy the individual branch's staff and boards of trustees. In looking at our current policies and comparing it to the service we want to provide our patrons, we see a wonderful opportunity to enhance service by writing procedure and policy to maximize our ability to provide outstanding service. This is our opportunity to radically simplify our procedures to meet that goal.
If we join PINES, we get a brand new set of policy and procedure that is the end result of compromise amongst 48 library systems. All libraries are not the same, and, in looking at PINES, you see that busy libraries and less busy libraries operate by the same rules. It's the "one size fits all" mentality that we question. Yes there is a mechanism for change involving list-serve discussions, subcommittees and a governing board of directors but where my library now has a seat at the table to directly be involved in making the compromise, we would no longer have that guaranteed opportunity to have our voice heard. Unless we had a permeant seat on each subcommittee and the governing board of directors to make sure we had input throughout the process, we would be a newly independent single-county library with little say in our destiny. In the current region, we can't turn on a dime, but we can turn on a hubcap because we have direct input in driving the library. If we join PINES, we loose that direct input and loose the ability to effect the direction our library is traveling.
The loss of independence is why we are considering running our own Koha system rather than simply joining PINES. It's going to be politically difficult to justify staying on our current system when PINES is free. Since Koha is free, that argument is moot. I'll switch to bullet form for the rest of my concerns, but, before they are listed, I need to state we are not anti-PINES. The ideal of a union listing of patrons and materials is what PINES is about. Allowing any Georgian to borrow any item in a Georgia Library is the ultimate goal. We simply don't believe that it's necessary for that goal to hand over our independence. Surely there has to be a way to allow the Not In PINES Yet (NIPY) libraries the benefits of PINES without compromising those libraries ability to serve their patrons. Right now, half of Georgia's library materials are unavailable to half of Georgia except via ILL. This is as true for a NIPY library as it is for a PINES library. Until libraries that value their independence are given the ability to access PINES directly from a NIPY library, this will remain true.
Other concerns about joining PINES
*Re-registration of our patrons. Having to re-register all 50,000 patrons does not seem very reasonable. While we understand wanting the "clean database", we don't see the benefit of not allowing a library to simply migrate their patrons and swap library cards for the new PINES card. One year you tell the county commission we have 50,000 patrons. The next year you tell them you have 15,000. That seems to shoot a great many statistical arguments in the foot as a library wrangles for local dollars. This also inconveniences the patron by forcing registration when simply confirming their information is much quicker for them and just as accurate.
*Deleting patrons after 3 years of inactivity. This exasperates the problem of re-registering patrons. Can't we simply block the patrons from checking out material until they confirm their contact information? This has the same effect as patron re-registration in arguing for extra funding.
*The manner Holds are processed. We think a hold immediately going out to the first available copy wherever the library is inefficient and frankly is an anti-patron philosophy. The stories we hear about patrons finding the item they placed on hold three days earlier on their local libraries shelf seem to occur with too much frequency. I know there is development work on a 24 hour wait to allow your holds to be serviced locally but it has been demonstrated that 24 hours is much too short a time frame to allow local items to service local patrons.
*The PINES delivery service. The horror stories that we have heard concerning the weeks it takes to move a book on toe fungus from Augusta, GA to a patron in La Fayette makes us wonder if we couldn't get the same book via ILL faster from Augusta, ME. Having to devote a staff member or multiple staff members to process the random delivery of a couple hundred holds is a real problem. With a reduction in force looming, where do I get my staff for holds processing?
*Receipt printing. The problem where patrons need to spend significant extra time after completing all circulation transactions just to get a receipt which prevents other patrons from library service is a real problem. One thing I like about our current system is the receipt is complete when the transaction is finished, so there is no need to buy a expensive printer to fix a software problem.
*Patron card requirements. Requiring patrons to always have a card to checkout items is, to me, inflexible. If you can verify a patron's identity and find them in the system, do I really want to tell them they can't checkout items because they forgot their card? This is a policy where you need to put yourself in the patrons shoes and ask if this how you want to be treated.
*System speed. The time spent waiting while the system thinks about processing a circulation transaction is ridiculous. The only fix we can effect is adding staff checkout stations or adding expensive self checkout stations. How can we do that when we may very well face a reduction in force? The slowness will prevent me from serving my patrons. I'm looking to increase service--not impede it.
*Help desk response. I hear it all the time from PINES libraries. Submit a ticket and we will fix it. Unfortunately, unless you scream about the problem, you will only receive a email stating the ticket is closed due to lack of communication after two weeks. Unfortunately, a satisfactory resolution to the problem isn't required to close a ticket.
*Apparent censorship of dissenting voices. I think most in PINES are aware of the most recent example where someone voicing actual concerns was told to be quiet by PINES staff. This is not the first time I've heard of PINES silencing a dissenting voice, just the first time someone had the courage to not take it lying down. It was said best in a meeting I attended last week. "PINES doesn't handle criticism well". Spirited debate should not be quashed in the profession. Let's see--I'm going to fight to keep Harry Potter on the shelf despite the controversy over Dumbledore, but I'll keep my mouth shut rather than discuss issues effecting my library with peers in other libraries? That is a counter intuitive argument that is undefendable.
We are not anti-PINES. We simply are stating a list of our concerns about joining PINES. Most of my concerns could be remedied by the local library not losing it's voice.
Subscribe to:
Post Comments (Atom)
51 comments:
Erik,
All excellent points! Would that the powers that be were attentive to the concerns of Evergreen users. It's a shame that they don't yet seem able to give improvements to the modules as high a priority as they appear to give to "sales and promotion".
Also in Georgia
I would like to add that I personally think it is one of the worst opac interfaces I have ever seen.
Erik the Tall-You should be called Erik the Brave! Thank you for opening up some open and honest discussion.
swilley...which opac are you referring to? koha or evergreen?
Erik, You raise some very interesting points. One thing which really concerns me is the delivery of PINES holds. It's terrible. The whole idea behind PINES was to make materials more available to our patrons. But if the materials aren't delivered in a timely fashion, what good is PINES? More later after I've had time to think about your post.
I would like to say that the idea that the database is "clean" is a joke. Do a patron search and put a common last name, like "Smith" in the first name box and do a search. If you could see more than 50 you would realize that thousands of records have been transposed. Do this with other common last names and see for yourself.
Just took a took a tour of Koha 3.0. Overall it's pretty cool. I'll know more after we kick the tires and run it around the block but I really think it will be sufficient for our needs. Amazing how the world has changed in a decade.
You are right clean is the ideal, but I will settle on "functionally tidy."
Hi Erik,
I'd like to split your issues into two categories, PINES issues and Evergreen issues. Being a software developer for Evergreen, I want to focus more on the Evergreen issues, but I may touch on both.
*snip*
>It's going to be politically difficult to justify staying on our current system when PINES is free. Since Koha is free, that argument is moot.
I think that's a bit disingenuous to compare PINES with Koha. Koha is software, and PINES is a membership organization that happens to host, support, and develop software. Are you saying that there are no costs involved with running open source software (whether it be Koha or Evergreen)? You should include the cost of your staff, hardware, etc. in such comparisons.
*snip*
>Right now, half of Georgia's library materials are unavailable to half of Georgia except via ILL.
What would you recommend here? You could help fund OpenNCIP, which could be used by both Koha and Evergreen, but even automated ILL is still ILL, and would be subject to political agreements. You can't fault PINES members for having agreed to policies that allow them to do intra-lending that is more efficient than typical ILL while allowing for a common patron experience. The software is as flexible as you could want it, but PINES is a different animal than a loose federation of libraries, and I for one think it's better for that. How many non-PINES libraries in Georgia have patrons asking why they're not in PINES?
>*Deleting patrons after 3 years of inactivity.
PINES merely marks the patrons inactive in lieu of actually deleting them. You may search for inactive patrons in Evergreen.
>*The manner Holds are processed.
This is how holds work currently in production in PINES: A patron places a hold on a title and chooses a pickup library. If the pickup library has an eligible item that can fulfill that hold, it is targeted and placed on their "Pull List". For 24 hours (this is a default, configurable per library, and I believe 3 days is now being considered), the pickup library is the only library that can fulfill that hold. If the pickup library can't fulfill the hold, the software broadens its search for an eligible item, and looks at the pickup system. Let's say a sibling branch to the pickup library has an eligible item and it is targeted and placed on their pull list. At this point, if the pickup lib had never had a targeted item (all of its eligible items were unavailable at the time of hold placement), then for 24 hours (again, configurable), the only two libraries that are able to fulfill that hold are the pickup library and the targeted sibling library. After a certain point, the software will take whatever item it can get, anywhere in the consortium, but for at least 24 hours, there are only two libraries that can fulfill a hold, the pickup library and the targeted library.
I believe this setup is very patron friendly.
>*Receipt printing.
Evergreen prints receipts the same way as Koha, all at once. Even better, with Evergreen you can auto-print and not have to click through (or even initiate) a print dialog. This is almost instantaneous on modern hardware. However, we are developing incremental printing for those who need it (where we print line-items as items are scanned). We're able to do this because of the technology stack Evergreen uses.
We are listening to our users!
>*System speed.
Have you tested Evergreen and Koha in your library? The main speed issue is with libraries that have saturated networks (mostly from patrons using YouTube, etc. in this new age of video on demand, but also from malware and zombie software that use bandwidth to their own ends, like for generating spam). Because Evergreen and Koha use HTTP and SSL with atomic requests and page updates, connections are constantly opened and closed, and suffer from any latency and bandwidth issues your network may have with each and every attempt at communicating with the server.
The easiest thing to do here will always be to fix the network.
However, we're not leaving it at that. One of the technologies that we're developing is OpenSRF-over-http, which will allow us to use streaming HTTP connections to serve data. This will minimize the number of connections that are opened in a given time period. Once we have OpenSRF-over-http being used in the staff client, it'll be a simple step to let the client also speak OpenSRF-over-XMPP (Jabber), so at that point, you'll be able to choose between two different protocols, one that looks like web traffic, and one that uses a single persistent connection. You'll be able to choose based on which one best fits your network environment.
We're also working to reduce the total amount of bandwidth used. Both Evergreen and Koha serve user interface data (buttons, menus, etc.) and library data (book titles, patron names, etc.) over the network (though Evergreen caches the interface data as much as possible and is very "AJAX"). I've been working on a version of the staff client that will just receive library data (the interfaces will exist in local code, but be remotely upgradeable). I also think it's important to have a completely web-based interface for circulation for those who want to use thin clients, so that'll be coming too.
I'm glad to see folks airing issues, even if I feel that Evergreen is being misrepresented. Open source means open development, and at least as far as the software goes, you can always contact me or the other developers directly. I'm just as anti-political as I've always been, and if you don't trust me to help resolve your issues (wow), then trust Dan Scott or Art Rhyno, both Canadian Evergreen developers who don't answer to Equinox or any government agencies in Georgia.
Thanks!
--
Jason Etheridge
| VP, Community Support and Advocacy
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: jason@esilibrary.com
| web: http://www.esilibrary.com
I was referring to evergreen unfortunately. I'm not familiar with Koha.
I think Evergreen is a smaller issue. The consortiium is actually the problem. However, I still disagree with Jason on two specific points:
"The software is as flexible as you could want it, but PINES is a different animal than a loose federation of libraries, and I for one think it's better for that."
I think a lot of people would disagree with that statement. Lots of libraries have asked, "Why can't we go back to the old way of doing things." PINES used to be more flexible, but over the past year they've tightened their hold.
In regards to holds:
"I believe this setup is very patron friendly."
How can I say this politely...NOT! Even 3 days will not rectify the problem. It's been proven that the courier service cannot beat the local patron returning the title within a two week period.
Hello Erik,
I'm still thinking about various things in your post.
One thing: You talk about you're possibly being better off getting the toe fungus book via ILL from Maine. I remember somewhere (ALA website?)that ILL costs in terms of staff time at both ends ran up to around $65 for each transaction. While PINES holds are certainly not "free", they are most likely cheaper than ILL. Still, something has to be done to address the problem of the tsunami of patron-placed holds. We are sinking under the weight of them.
Another thing: Why is a library card required for transactions? Why can't we just look the patron up? That's fine if you are dealing with a relatively small group of patrons rather than a huge database with over a million souls. It's too easy to make a mistake and attach items to someone else's card, especially if you are at a busy front desk. However, I can see letting people on to computers without a card, provided they present sufficient identification.
Erik the Awesome.
Your name is ringing a bell.
Is this the same Erik that was fired from GPLS? Former PINES administrator? Weren't you responsible for some servers that got hacked and subsequently taken away? Those were dark days in PINES as I remember them.
It's sad that we can't have discussion without personal attacks. This discussion has obviously struck a nerve with someone.
Are we now going to add argument "ad hominem" to the excuses and self-justifications being presented by Evergreen and Equinox?
Wouldn't time be better spent in identifying, addressing and correcting the problem areas with Evergreen? Open source is, after all, and should be, user-driven.
Anytime one questions what has not been questioned before one draws blood. A personal attack--what does that accomplish? It wouldn't matter if the blogger were simply a patron sponsoring this discussion--the point is to discuss possibilities. Sure, rail away but I bite my thumb at that. I want some meaty debate on the TOPIC, please.
*snip: holds in Evergreen*
>How can I say this politely...NOT!
There's not much I can do about a courier service (or anecdotal evidence), but I stand by what I said. The way holds currently work in Evergreen (the software) is a good strategy, and if you have any suggestions for a better algorithm, please share. Seriously!
We have some other notions ourselves, such as geo-spatial holds, and the ability to "weight" routes dynamically based on measured performance. I personally dream of a self-learning neural network taking charge, but I think I'm alone in that vision. This is the future, and no one currently does any of this that I'm aware of.
The previous automation system for PINES wouldn't even randomize holds, they went to the items most recently added to the system. We added a library to PINES and they got slammed with most of the holds for the whole consortium. The vendor said it wasn't feasible for the holds to be randomized. So we hacked together a kludge and did it ourselves, and life was better.
And now we have Evergreen, where we're in full control of the software. If something is broken, we don't have to hack together a kludge. We can change the software directly and do it right.
You just need to tell us how we can make it better.
-- Jason
"Those of you who attended the recent training hosted on behalf of the Georgia Council of Public Libraries can attest that we have sufficient skilled staff to tackle a technology challenge. In fact, I'll say it because I believe it true, I have the best technology staff of any library of which I am aware. With that said I have little doubt in our ability to make a free alternative such as Koha perform."
To me, that sounds like a assertion of expertise. If the author was in fact responsible for servers that were compromised, per the earlier comment, then it would be relevant and well within bounds because it calls into question the weight his comments have (at least the technically-leaning).
>Wouldn't time be better spent in identifying, addressing and correcting the problem areas with Evergreen?
I'd be happy if we start by identifying these "excuses and self-justifications" of "Evergreen and Equinox". :(
For someone who is against personal attacks, these are some mighty strong words you're using.
I don't think Evergreen (or any software or community) is perfect or all roses. I don't think the negativity on this blog is a ploy by competitors, though I do think some folks would like to see us fail.
I believe some people are having issues, and for whatever reason, can't get help, and are feeling frustrated.
I want to help! If the problem is software, we can fix it. If the problem is people, then we can at least identify it and work toward fixing it.
But in order to help, there has to be dialog, and there has to be civility, not a one-sided "I CAN'T HEAR YOU". And we have to give the issue an honest assessment, even if we might not like what we find (and I have to hold myself to this).
We also shouldn't conflate issues, because it just confuses things and generates ill will. This is why I want to keep a clear separation between PINES issues and Evergreen issues.
I honestly believe I have listened to Erik's Evergreen issues and related what we plan to do about them, and even in cases where it seems like we could say "Not our problem", we still plan to help out as much as we can.
But we need your help too! If, for example, you are convinced that your network is not at issue when it comes to Evergreen performance, then give reasons why you believe this!
If it is your network, but for some reason you can't improve it, let us know that too! Maybe Evergreen just needs to adapt and work on poor networks, and take advantage of good networks when able.
This is more than possible, it just requires honest communication.
Thanks folks,
-- Jason
Phasefx,
I appreciate the technical details and your taking time to respond. I hope that my technical concerns will be addressed. To be truthful, most of my issues are not technical. My library losing its voice amongst a few hundred libraries is my primary concern. Before my soon-to-be-single county library system makes a final decision, we must investigate all our options including the pros and cons of joining PINES.
"Is this the same Erik that was fired from GPLS? Former PINES administrator? Weren't you responsible for some servers that got hacked and subsequently taken away? Those were dark days in PINES as I remember them."
It's always good to be remembered, even incorrectly. I do feel a little clarification is in order. Yes, at one time, I was employed as the PINES system administrator. No, I was not responsible for the servers being hacked. I was only initially responsible for administering the Unicorn application.
In a span of 3 months, the state's technology staff had dwindled to just me. This left me responsible for administering the Unicorn server and a host of new duties. My new duties included administering a statewide data network for 300+ facilities, providing desktop support for the same number, administering a collection of mail and DNS servers, as well as assuming the full administrative responsibilities for the Unicorn Server. To say my job changed dramatically would be an understatement.
For about six months, I was the only technical support for the state of Georgia libraries. When assuming my added responsibilities, I discovered that those "hacked" servers had been "hacked" for several months before I took over. My only crime was in discovering the issue and reporting it. As for being fired from GPLS, that simply isn't true. I stayed with GPLS for an additional three years and made my own decision to leave.
'"Those of you who attended the recent training hosted on behalf of the Georgia Council of Public Libraries can attest that we have sufficient skilled staff to tackle a technology challenge. In fact, I'll say it because I believe it true, I have the best technology staff of any library of which I am aware. With that said I have little doubt in our ability to make a free alternative such as Koha perform."'
"To me, that sounds like a assertion of expertise."
Yes, I unapologetically believe I have an incredibly skilled technology team. Why should I not be proud of them? They are more than capable of running a Koha server. For the most part I do not work with technology on a daily basis. My job is running a library where technology is just one department. I'm usually busy buying books, staffing the library, and dealing with patrons to deal with anything other than my email. Give me a break I use a Mac so I don't have to play with technology.
>I appreciate the technical details and your taking time to respond.
Erik, no problem!
*snip*
>we must investigate all our options
If you investigate running your own instance of Evergreen outside of PINES, let me know if you run into any issues or need any help!
There's also an active community over on OPEN-ILS-DEV that is more than willing to help out, and I'm sure they would be interested in any of your findings.
Thanks!
-- Jason
I, for one, am happy to have a new outlet for discussions relating to Georgia Library PINES. I'm also glad to see input from "The Evergreen Experts." At first I didn't like the anonymity of this blog; however, I think ultimately it is good to give everyone a safe outlet to express their opinions...the good, the bad, & the ugly.
Erik, you've given up plenty to talk about. Where do I start? I've had my issues with some of the PINES policies being too restrictive. It can be pretty demoralizing for local staff. All we want to do is serve our patrons to the best of our ability. I think some policies are prohibiting us from doing that. It's extremely frustrating.
Evergreen...the functionality is great, but unfortunately we're one of the libraries that has had speed issues. I'm happy to report that the new QA person at GPLS has been doing some investigative work for us. I have to admit, I'm still somewhat skeptical that it's a network issue on our end. Why? Because these problems didn't crop up until we migrated to Evergreen. That said, I really hope we discover that it is an issue on our end! I would like nothing more to fix the problem once and for all!
I hope my comments don't get me into more trouble with folks in PINES-land. I spoke with a colleage yesterday that said it was a shame that people get the wrong idea about me through my posts. I'm really a nice person...really!
Yikes! Please excuse the spelling and grammatical errors in my post. I need to go to bed.
"The Indecent Librarian exists to provide a forum for those with non-conformist views an opportunity to comment on our profession."
Non-conformist...that's me! I hope you will be discussing a wide range of topics on your blog.
I think it's interesting that Evergreen started out as a vision of open-source software that PINES could customize to suit it's needs. PINES staff and Evergreen developers pitched this idea, got it approved, and then set off to "build" this new library software. Then good ole capitalism and greed set in. Open-Source seemed to be selected at first to save PINES tons of money in licensing fees, but now it appears that it was selected so that the developers could "take it with them" when they left and shop their services to other systems across the country. Software companies don't allow employees to take the software they developed with them, yet Equinox found a way around this with open-source. As soon as the software was finished, they formed Equinox to sell their "expertise" on the market. They got paid with PINES money to develop Evergreen, and couldn't wait to get out the door when it was done so they could start pitching it across the country. I think it's questionable that high-ranking PINES staff initially were involved with the private money making venture. So don't act like you are so interested in helping the users, when really you just want to improve the product that your company is trying to sell, and silence any critics that could lower the value of your company's products and services.
Even posting anonymously on this blog provides enough information for certain persons in authority to retaliate against staff members who post. Nevertheless, and at great risk:
My experiences with PINES staff and Evergreen have been peppered with problems. Primarily, the software was released without the usual comprehensive testing, and has been full of non-working or poorly designed elements.
Prior to the release of the early clients, the design team rejected offers to work closely enough with the actual users of the software to understand the nature of the work, or the minute details of what was really required. This has caused them to constantly react to a plethora of requests and help desk tickets to generate corrections to the software. It is a radical, new, and totally organic, evolutionary approach that, by continually bumping its way down blind alley-ways until it finds the path of least resistance, hopes by a trial and error method to self-correct like an evolving species mutates and evolves. It is nothing like the finalized release of a typical software vendor.
If this was an automobile they were selling, every one off the assembly line would end up being a returned lemon; and, with the method now being used by the design team, we end users--instead of being the proud owners of a shiny new car--all become merely the design team's crash test dummies!
The removal of the development team--first physically from the building housing other GPLS staff, and then conceptually by forming their own, for-profit company--has alienated them from the work-a-day library "grunts" on the front lines.
By using open-sourced software, the team has avoided paying any licensing fees, and has now gone on to develop a product that is so proprietary, that no one outside the team can install it on their own without the team's help.
This is exactly the way Sirsi got started when the design team for the Sirsi product developed the Sirsi software using academic resources at Georgia Tech. They, too, were at one time employees of the institution that created the software. The end result was that the for-profit Sirsi company can now do things like charge $400 per request for simple assistance and database maintenance issues. The development team is sure to follow this pattern.
Look at another example of the team's haphazardness. In a class that was being held on the reports module, when faced with a classful of students who could not understand the structure or functionality of the software, the design team admitted that they were unable to explain it to the class! To do so would have required a week of instruction in object-orientated database programming. Yet another disconnect between the design team and the end users.
More significantly, the design team clearly did not understand the nature of what would be required of the reports, and did not know how to relate it to the MARC and patron records and the transaction logs and circulation mappings in a way that could be intuitively understood or at least quickly grasped by the library staff. Their lack of understanding MARC records led to the creation of report templates that skew or miss data and provide false returns. Nor was there any instruction manual or background material with screen shots to explain the reports in depth.
This failure was the result of not connecting with the people who actually did the work prior to creating the product.
The lack of manuals has proven to be a very exasperating factor in the use of the software. Practices are left up to each user in a kind of exploratory manner of self-instruction or are left to the amorphous, often outdated resources in an online wiki.
There is no standardization of how things are to be done, so any number of procedures not circumsribed by PINES policy or the willy-nilly methods of performing specific tasks within the software end up being created by various libraries and staff members, while holes in the software have allowed some very strange anomalies to creep in.
The gist of all this is that the secure, dependable use of Evergreen, given its current highly unstable software, is years away, and even then only after tweaking and repairing all the errors and faults, solidifying manuals and procedures, fully testing and integrating the various modules (several of which have not even been created yet), and adding the input of hundreds of library staff members over time in order to make the software conform to what the larger community of users require, not what the tiny design team, with their very limited focus and understanding, thinks it should have.
One can only hope that after these horrific Dark Ages, there will be a tiny Elysium of Enlightenment.
There is one thing for dang sure, though : the © symbol that will end up at the end of the name Evergreen.
Yikes! My coworkers bitch profusely about the speed of the OPAC and hold fulfilments but this is the first time I've heard attacks on the EG dev team's integrity. I'm a bit removed form the fracas but I can testify that in my (limited) communication with the team members they've been responsive and friendly.
Frankly, at the risk of sticking my nose out to far, I think the negative comparison to Sirsi reveals a failure to grasp the wider concept of open-source software. If GPLS becomes unhappy with the current developers company they can toss them out and hire new programmers, who can in turn fork the project. Until I hear a coder declare that EG is written poorly or is too complex for outsiders to understand, I'm giving the benefit of the doubt to the creators. My experience lurking on the open-ils list has been that, if anything, the opposite is true of the code.
The one point I wholeheartedly agree with is that the software wasn't developed enough before being released. The Web 2.0 "perpetual beta" meme is one thing--the initial release of EG felt more like a pre-alpha experience on our end.
Jason, to address one of your comments--speed continues to be a serious issue on our end, and I have reason to believe it's not entirely because of our end of things. We recently added another T1 line, so we're at about 60% overall bandwidth usage on average. We also recently upgraded to brand new gigabit LAN wiring, so I don't think we're bottlenecking there.
To sum up my thoughts--there are legitimate complaints regarding PINES policy. The same might be said for EG itself, but to a much lesser degree, in my opinion. The feeling I get is that the dev team is understaffed--we saw rapid improvement for the first few months, but now the focus has shifted to the acquisitions model at the expense of circ and the OPAC. The client update is coming soon, so maybe I'm off in my perception. To circle back around to PINES: I always thought the furor over holds taking so long was a bit over the top (I'm fine with my holds taking weeks--how long does the average ILL take in comparison?) and, in any case, the fault of lousy courier service more than anything else.
-Mike
I remember somewhere (ALA website?)that ILL costs in terms of staff time at both ends ran up to around $65 for each transaction.
Your memory is in error. The ARL has conducted three nationwide ILL cost analysis studies (1992, 1996, 2002) of ARL libraries - full costs to include average cost per transaction, including staff salaries and wages, benefits, equipment depreciation, fees to paid to suppliers, etc.) All three studies sustained a median total cost (borrower and lender combined) in the vicinity of $27 (unadjusted for inflation).
I submit the usual caveats about comparing college/university libraries to public libraries. That said, there's quite a difference between $27 for everything on both sides combined and $65 just for staff for each side of the transaction.
>Jason, to address one of your comments--speed continues to be a serious issue on our end, and I have reason to believe it's not entirely because of our end of things.
Thanks Mike! If you would, email me and we can schedule a time to try some things. I'm particularly interested in the results of a traceroute to the PINES server and other sites, to see if any of the hops along the way are suffering from high latency, packet loss, or inconsistent ping times.
-- Jason
jason@esilibrary.com
From the very beginning, before a single line of code was written, PINES knew that a community would have to form around Evergreen for it to become self-sustaining and future-proof. A community of individuals, libraries, and yes, even hired workers. We chose open source for philosophical and pragmatic reasons. Philosophical because software, like speech, should be free and unencumbered. Pragmatic because the open source development model is effective and produces better software. You can handwave and say the software is crap, but as soon as you mention something specific, we will scrutinize it and fix it. It's that simple. And here's a little secret: we want any flaws to be exposed! Even if it comes from nay-sayers and critics. That's how open source works.
It doesn't matter if commercial interests are involved, because they all want the same thing. If I want to help users, does it matter whether I'm being paid to do so or not? What's wrong with enlightened self-interest? You think that PINES should not share Evergreen with those outside of PINES? Then maybe PINES can "give back" Linux, GNU, Apache, PostgreSQL, MySQL, Perl, Python, Ejabberd, Memcached, Mozilla, and all the other open source software that they "exploit". Maybe libraries should stop sharing books. Even proprietary vendors make use of open source software; I think there's only one major vendor that doesn't use Apache for their OPAC, for example. In marketing terms, Evergreen is a commodity. We can't control it or monopolize it, and yes, that was done on purpose. Software should be free and libre.
"Prior to the release of the early clients," the developers spent a whole year working with domain experts, conducting focus groups, developing frameworks, and getting feedback on prototypes, before we started in on the actual automation system. If you yourself felt "rejected" in this process, I am very sorry, but the truth of the matter is that we take all the help we can get, and always have. If you are a PINES member, are you subscribed to PINES-DEV? Have you ever responded to a call for help on that list from me? Or were you too busy? Are you subscribed to OPEN-ILS-DEV? Did you try to help anyone there? Did you respond to our calls for help on the open-ils.org blog?
All the tools are there for you to become involved. But it does take work. You have to actively participate, and not snipe from the sidelines. You have to become a part of the solution, and you have to share. Yes, it's organic, but that doesn't preclude structured development. We'll take all the QA, usability studies, case studies, domain expertise, etc. that you can give us. We'll also take any common sense advice you can offer.
As far as the server-side software being difficult to install goes, yes, it can be a challenge in changing and foreign environments (PINES only has one environment, afterall), and you're more likely to hear from folks having trouble than from folks having success (witness this blog), but folks are having success without help. You only need to visit OPEN-ILS-GENERAL to see that. Look for the thread titled "Are there any K-12 Schools Using the Evergreen system?" They're going live with Evergreen without assistance. But what's wrong with asking for help, anyway? I don't see anyone charging $400 per question in the Evergreen community. I don't see any trade secrets or non-disclosure agreements.
>"There is one thing for dang sure, though : the (c) symbol that will end up at the end of the name Evergreen."
Everyone who contributes code to the software owns the copyright to their code. But the software as a whole is "copyleft".
The only other "intellectual property" involved is the Evergreen trademark, owned and licensed by GPLS, and any possible patents, which the license won't let you exercise. And incidentally, if there is nothing new and innovative in Evergreen, then we really don't have to worry about patents from the decades-old library automation industry, do we?
This software is truly free and communal. It'll never belong solely to one individual, organization, or company. The cat is out of the bag, so to speak. You can't put it back in.
-- Jason
Jason, maybe you should go ahead and explain how Equinox became a company. The original position was there was no desire to form a company. Then one day Equinox is born. Nothing seems to change, everyone was still holding a day job with GPLS. One of the founders repeatedly claimed it was completely legal and had been cleared by BOR. Then one day all the founders, except the one defending the practice, quit GPLS. You really need to clear up that mystery.
Cost of ILL
Near as I can figure an ILL costs my library about $7 to lend and $5 to borrow. That seems reasonable to me. If it were $65 on each end who could afford the service without cost recovery from the patron?
"Another thing: Why is a library card required for transactions? Why can't we just look the patron up? That's fine if you are dealing with a relatively small group of patrons rather than a huge database with over a million souls. It's too easy to make a mistake and attach items to someone else's card, especially if you are at a busy front desk."
In my mind this is a training issue. I really have a hard time understanding the reasoning on this policy. If a patron wants to check-out a book without a card I look it up. It's that simple. If staff can be trained to search the catalog they can be trained to search the patron database. If the patron lost the card you take the same risk in issuing a replacement. If it's such a problem I do offer a suggestion. In the lookup couldn't an additional search term be used? Lastname and zip come to mind as a way to limit the search results.
Anonymous blogging.
I'm sorry some fear retribution for posting. This is a real problem for our profession. I've scratched my head and really don't have an answer. The Electronic Frontier Foundation does have some suggestions in the link below.
http://w2.eff.org/Privacy/Anonymity/blog-anonymously.php
Unfortunately whenever someone posts anonymously there is always a question of credability. I would like everyone who reads the blog to read all comments with an open mind. There may be a very good reason the comment is anonymous that shouldn't detract from the content.
I believe we have issues with both PINES and EG.
We have problems weekly with the system slowing down. Someone should take care of this problem before PINES adds any more libraries to the system.
The card catalog is a mess, also.
As for holds, we had difficulties with Velocity first and now STAT. It seems to me that the fault could be ours. When two companies get so bogged down under the weight of our massive intransits that they are unable to fill our needs in a timely manner then maybe it is because we are putting too many items in the courier system at one time. the only way to handle this problem is to limit the number of holds any one patron can have at any one time.
Sorry to say the Help Desk is of little help these days. We need to fix this problem right away.
When two companies get so bogged down under the weight of our massive intransits that they are unable to fill our needs in a timely manner then maybe it is because we are putting too many items in the courier system at one time.
I disagree. As big as our transit may be, it's not beyond the scope of what a courier could theoretically handle. Shoot, Amazon manages make, what, 10000 more deliveries than we do? It's not an apples to apples comparison of course but my point is it's not really an overwhelming service we're asking for, it's just that, as always, the contract goes to the lowest bidder. My guess is the competing bids were all higher because they better estimated the costs of delivering as many items as we requested.
the only way to handle this problem is to limit the number of holds any one patron can have at any one time.
Again, I disagree. I think the first thing we can do--after we get a courier that will live up to its contract, that is--is make it clearer to patrons what placing a hold entails on our end. Show them a confirmation that informs them that holds may come from across the state and as a result may take anywhere from 1 day to several weeks to fulfill. Better yet, allow patrons to choose whether they want their hold to come from outside the local system or not.
Beyond that, maybe it's worthwhile to make patrons directly share in the costs of transiting items. Charge 5 cents for local system holds and 10 cents for system wide ones (or 20/50 cents, or $5/$10--the amount itself is relatively unimportant). The number of holds would drastically go down, patrons couldn't help but realize there's a cost associated with getting books delivered, and we sure as hell would see less holds not picked up at all. Of course, the flip side of charging for the service is that patrons service expectations would go up.
>Jason, maybe you should go ahead and explain how Equinox became a company.
Sure, I can do that.
>The original position was there was no desire to form a company.
As far as I know (and I believe anyone working with the project will bear this out), there was never an "original position" in any direction from anyone. It just wasn't on the radar; we had enough on our minds already. We helped other folks in the interest of good will and promoting Evergreen as an open source alternative for libraries; yet, ultimately GPLS was not in the business of supporting people outside of Georgia, and interest was growing. Although we really wanted libraries outside Georgia to be able to operate Evergreen on their own, we also began to recognize that there were some libraries that needed a commercial context to feel comfortable with library automation. It all just seemed a natural progression. There was never an expectation that we _wouldn't_ form a company.
>One of the founders repeatedly claimed it was completely legal and had been cleared by BOR.
BOR, for those unfamiliar, stands for the Board of Regents for the University System of Georgia. They're the parent organization for the Georgia Public Library Service. BOR, in accordance to policy (there was no question of legality here), cleared us to form a company on the side, much like professors in Universities are allowed to do consulting on the side. The only stipulation in such an arrangement is that you can't double-dip into state money. So at the time, we were not targeting customers in the state of Georgia. We worked under this arrangement for several months, and then, to our surprise, BOR staff changed their minds (which policy says they can do). They asked us to decide whether we wanted to work for GPLS, or for Equinox, but not both. At this point, the four developers chose to work for Equinox, and the state contracted with us.
This actually turned out to be a positive move, for several reasons:
1) Georgia is a work "at-will" state, which meant, as GPLS employees, we could leave at any time. However, as Equinox, GPLS has a contractual hold on us. Sure, we're replaceable, but PINES already has a long list of enhancements they want implemented, so why waste time bringing new developers up to speed when we're already on the ground running and they already know our work ethic? At one time I was a contractor for GPLS. At another time I was an employee. Now I'm a contractor again. One of us was _always_ a contractor. As long as GPLS is getting what they pay for, what does it matter? The fact that we have the flexibility of hiring additional staff for needs that are outside the interest of PINES and GPLS is a good thing.
2) Georgia benefits when others adopt Evergreen or even become interested in Evergreen. However, Georgia isn't in the business of directly supporting people outside of Georgia, and many libraries simply can't afford to hire full-time support and development staff for any automation system. Those libraries absolutely require vendors or they would never adopt Evergreen.
How does Georgia benefit if others adopt Evergreen? In a nutshell, open source projects take advantage of economies of scale.
1) More libraries means more resources, and more sharing of development efforts. These resources could include developers, domain experts, technical writers, testers, and even funding.
2) More libraries means more incentive for other support companies to form around Evergreen. Equinox has an advantage now, but the software is open source, and at least one other open source vendor advertises services for Evergreen. It would be very smart for the existing ILS vendors to adopt Evergreen and leverage their brand power, but I doubt you'll see that happen because it would be a change in their business model. They make most of their money selling software licenses. We can only sell our time and expertise. But more people are gaining Evergreen expertise everyday. That knowledge and expertise is shared, not hoarded.
-- Jason
mike k said
"as always, the contract goes to the lowest bidder. My guess is the competing bids were all higher because they better estimated the costs of delivering as many items as we requested."
The lowest 'qualified' bidder. It's the responsibility of the bid writer to state the conditions that constitute qualified. Bids are first graded on qualification. Whatever the bid price the bidder must be qualified.
Maybe the third time will be the charm.
"Beyond that, maybe it's worthwhile to make patrons directly share in the costs of transiting items."
The State Aid Rules prevent cost recovery on a basic library service. Lending amongst PINES libraries should be considered a basic service. Charging for a hold would make a library ineligible for state aid.
Looking up a patron's account is much easier and more precise with Evergreen. There are multiple ways to narrow your seach for a common name...zip code, street name, city, to name a few. For the life of me, I cannot understand why this is such a problem for PINES libraries. It's basic customer service. We could even limit the number of lookups they were allowed by leaving an alert message on the account. This is one of the advantages Evergreen has over Sirsi. Why not use it?
I really like the look of MaineCat, a partnership of Maine's academic, public, & special libraries. You can view their statewide catalog at
http://mainecat.maine.edu
What's truly wonderful is their participating agreement. They have a few "general" policies, but for the most part libraries retain their autonomy. They even go so far as to let local libraries decide if they will allow "visiting" patrons, or walk-in patrons from other libraries. They also let patrons request their own ILLs.
I can honestly say that when I first got wind of Equinox, my first thought was, "We've been duped." Comparing what professors do on the side isn't the same thing, at least in my mind. What they are developing with state money is intellectual capital, not an actual product that can be carried out the door.
Jason,
Thanks for taking the time to shed some light on these issues. For each point you made, there is a valid counterpoint. All legality aside, there is a real perception issue here. Many feel that GPLS/PINES provided startup capitol for Equinox.
"Beyond that, maybe it's worthwhile to make patrons directly share in the costs of transiting items."
The State Aid Rules prevent cost recovery on a basic library service. Lending amongst PINES libraries should be considered a basic service. Charging for a hold would make a library ineligible for state aid.
Ah. i figured there was an ethical counterargument to be made in any case but I wasn't aware of that rule. Very well, passing on a portion of the costs is out. I still think it would be beneficial to let patrons know that there is a cost involved.
Also Erik, I think your last comment "Many feel that GPLS/PINES provided startup capitol for Equinox." states it more clearly and with less animosity than I've heard before. I don't agree though. Jason's account makes it clear that it was GPLS choise to move the Equinox staff to an external contractor role. I don't think you can fault them for offering the support service in the first place.
To offer a simpler analogy--I was hired to (among other things) provide computer help for our local patrons. I often bumped up against patrons wanting help with their home machines (or even phoning the library for tech support!). As a library employee my hands are rightfully tied here--it's not my job to provide support for non library computers as that's not one of the services we offer the community. But after a year of sending patrons in need of support to the Geek Squad I opened my own external computer service business. I don't solicit business on the job. Would you argue this unethical on my part? It's my knowledge and time that I'm selling.
The additional argument some have raised, most recently J Pickle's comment: "What they are developing with state money is intellectual capital, not an actual product that can be carried out the door." is, in my opinion, erroneous. It is another case of misunderstanding open-source software. GPLS got what they contracted for--the software exists and is in use. They could sever ties with Equinox at the end of their contract and EG wouldn't go away. Equinox is selling their knowledge and time, NOT the software package. As others have again and again pointed out, anyone can come in and offer support for EG, and at least one other company does so. At worst, you could say that the dev team constructed the code in such a way as to render it difficult for others to comprehend and therefore rewrite or support, so as to create a market for their services. Until a coder takes a look at the program and tells us this is the case, I think it would be unwise and unkind to level this or other unsupported charges.
mike k, You say you don't advertise while you are on library time. When someone needs help at home do you still refer them to Geek Squad or do you give them your card? As far as the GPLS/Equinox relationship...I agree that Equinox probably didn't do anything wrong. But the developers did get to develop a commodity (that they could keep/share) while being paid. Maybe there is nothing wrong with that. I just think it's good to look back and evaluate. Certainly there are lessons to be learned.
Mike K,
I do not think many would have a problem with your side business. I've known reference librarians to do extensive contracted genealogy research, using library resources, after work hours as a side concern. Computer work, which I have myself performed, is no different. As long as your trustees do not have a problem with this arrangement then it's probably not a problem. Others may perceive it differently, but it's not an uncommon arrangement.
This isn't an apples to apples comparison. I have little doubt BOR would allow an illegal action. Somewhere there is probably a rule or code section that specifically forbids BOR from breaking any law. Perception is another matter. I think if GPLS/PINES/BOR wanted to completely avoid a perception issue there was a very easy way to accomplish this. They could have put the project out for bid. If Equinox answered and was awarded the bid based on merit there would be little room for a perception issue.
OK, I can see your point there.
Hi Erik:
About the courier service, you said "The lowest 'qualified' bidder. It's the responsibility of the bid writer to state the conditions that constitute qualified. Bids are first graded on qualification. Whatever the bid price the bidder must be qualified."
Later, you complained about the process by which Equinox was awarded the support contract for Evergreen at PINES. "They could have put the project out for bid. If Equinox answered and was awarded the bid based on merit there would be little room for a perception issue."
I'm not from Georgia, but I assume the Board of Regents was smart enough to recognize that there would only be one company that would be qualified to bid on the contract at that point in time - the company that employs the original developers of the 150,000 lines of code that make up Evergreen. If any other company submitted a bid at that time (February 2007 or something like that?) they would have been laughed out of the room.
To date, there have been only a handful of other developers who have demonstrated that they're familiar enough with the code to contribute to the project. I'm one of them. I'm hoping that that changes over time, and I can vouch that the original Evergreen developers bend over backwards to support people interested in contributing to, using, or just trying out Evergreen -- even though that might mean that a year or two down the road some other company might be able to legitimately position themselves as capable of supporting and custom developing Evergreen.
So sure - in another year or so, a competitive bid process would make sense. But given the circumstances in February (I think?), it would have been a waste of everyone's time to go through that exercise for the purpose of leaving "little room for a perception issue". It sounds like all that was needed from the Board of Regents was just a clear explanation of events and why the choice was made.
A competitive bid would have prevented the perception issue. Competition, or the possibility of competition, produces many benefits beyond solving the perception issue.
Your points are not alien to me, and what you have said is logical. I simply think it best to avoid perception issues before they occur. I do have to chuckle at the irony of an open source developer arguing the merits of a sole source contract. I do see where you could have that condition, with any project based on expertise, but it does make me chuckle.
Post a Comment