Evergreen 2009: Not Just Code

This is the fourth in our series of posts leading up to Evergreen’s Tenth birthday.  

I first became aware of Evergreen in 2007 when I saw a posting on a library technology listserv.  As an open source advocate and a librarian, I began following its progress. Skip forward to a cold morning in January 2009 and I was letting IT managers and library directors from around the state of South Carolina into a meeting room.  I was the IT manager at the Florence County Library and two months previously we, as a library, had decided to move to Evergreen.  We had written a long term technology plan and a critical part was our Integrated Library System.  Aside from Georgia, we saw Evergreen being adopted in Michigan and Indiana.  I knew that in time Evergreen would match and surpass our other options.

We also knew that an open source community was going to require changing our perspective of what our relationship to the ILS looked like.  The old proprietary vendor had legal control over aspects of the community and there were limits to what we could share among ourselves as customers.  Libraries had to strike special deals with strict non-disclosure agreements to gain access to source code and the insight to how the ILS worked behind the user interface.

To say that this was going to be different would be an understatement.  The source code was not only not confidential but openly published.  People developed reports and freely published them on community wikis while articles appeared in journals and on personal blogs.  The lack of a corporate gatekeeper was both invigorating and a little overwhelming.  Bringing in a vendor to run an ILS as a service made sense to us but could we convince others to join us?

We asked if other libraries would be interested in an Evergreen consortium.  The answer was yes.  There were a lot of concerns but the experts we called in, Equinox Software, seemed the perfect choice.  No one knew Evergreen as a team as well as they did and they had worked with small libraries and big consortiums.  Partnering with Equinox allowed us to start the migration process quickly despite very little in-house knowledge of Evergreen across our libraries.  And without a proprietary gatekeeper, other libraries in the consortium could dig into the deeper technologies to the degree they were comfortable doing so.  My library was definitely one of the others that wanted more.

We knew that user community was important.  Even with its limitations the user group of our previous ILS had been valuable.  2009 was the year I went to the inaugural Evergreen Conference.  2009 was the year I became active on the listservs, mostly watching but answering questions where I could.  2009 was the year I first volunteered to help out with community activities.  2009 was the year I first gave feedback on new features and bugs.  2009 was the year I, as a user, became a part of the community and saw an impact from it.  And, frankly, it was kind of easy.  I had an advantage being both a librarian and having a technical background but as I met others as new to the community as I was I saw them doing the same thing.  Where they became involved varies based on their interests and skills but everyone who wanted to found a place.  I even recognized a few from the user groups of my old ILS.  Before these people had been names and faces I vaguely recognized from meetings at ALA and listservs.  They had been users of the same thing I used.  Now, in the Evergreen community they were fellows and peers.

The open development process meant that I got a chance to provide feedback on features being developed that we weren’t paying for.  I had participated in feedback about features for proprietary ILSes.  It always felt like throwing pennies in a wishing well and crossing my fingers.  I didn’t work at libraries large enough to drive the process of development so we had to hope that the really big customers wanted the same things we did.  Here, the process wasn’t just open in name but discussion about requirements and needs was being done in public forums.  Input was not just allowed but encouraged.  It was clearly a matter of pride for the developers to know that their work was as widely useful as possible.  I could follow the process and choose to participate if it was a feature I was interested in.  And behind each of these things was a person, someone I got to know on a listserv or a conference.  

In December of 2009 our third wave of libraries went live.  Things had calmed down from the hectic early days of migrations.  It had been almost a year now since that early meeting when we went from “we want to” to “we are doing this.”  I remember having time to spend looking at bugs because we had the Christmas slowdown common to public libraries when a developer at another consortium sent me an email.  I commented on a bug that wasn’t a high community priority but it, well, bugged me.  I had helped this developer with testing some patches both to help him out and to give myself more patching experience.  He carved out time and fixed that bug for me.  The truth is that any human endeavor involves an economy of personalities.  But in the software world of meritocracy, open source projects are often more about code than people.  They are often tightly focused projects that do specific things.  An ILS isn’t tightly focused.  It touches on a vast swath of a library’s operations.  It took me a while to realize what now seems obvious in hindsight, but Evergreen isn’t tightly focused and it’s not about code.  Code is critical to the project as it is the means to an end but Evergreen is about people.  I learned a lot in 2009 but things have changed.  I’ve changed jobs and code has changed but the fact that Evergreen is about people hasn’t changed.

–Rogan Hamby, Project and Data Analyst