The Open Source Experts
full-service open source library services provider

Evergreen 2006

I have trouble pinpointing the exact moment when Evergreen was conceived, even though I was one of the principal agents.  Let me start by covering a few acronyms: PINES is the name of a statewide inter-lending library consortium project in Georgia, one of the largest of its kind.  GPLS is short for the Georgia Public Library Service, a state agency that administers PINES and many other library projects.  In 2002, I was hired by GPLS for PINES as a contractor to develop an add-on reporting system to address the limitations of their then library automation system.  With the success of that project, I was hired on as a full-time employee in 2003 to maintain and further develop that system, as well as create other needed software solutions to prop up their existing system.  It was during that time that we lobbied for and eventually received the go-ahead to develop Evergreen, and in 2004 we hired Mike Rylander and Bill Erickson to help develop the software.  In 2006, PINES went live on Evergreen and the rest is history.

But there’s a part of the story that doesn’t get told often enough, and that’s the influence of the free/libre and open-source software movements, with the likes of Richard M. Stallman, who wrote the GNU General Public License and started the Free Software Foundation, Eric S. Raymond, who wrote the Cathedral and the Bazaar, Larry Wall, the creator of the Perl programming language, and Linus Torvalds, the creator of the Linux kernel and more recently, the Git version control system.  I was (and am) a huge open source and free software advocate; I cut my teeth on Linux during college and followed the battles between open source and proprietary software very closely.  There were huge forces arrayed against us; Microsoft was abusing their monopoly power preventing OEM’s from installing Linux while calling open source a cancer, the SCO lawsuit was happening in 2003, and most governments and governmental agencies were very skeptical of open source software, GPLS included.  It’s funny how some of those same battles were later mirrored in our efforts.

There are some very philosophical reasons why open source software meshes well with libraries (software developers even collect code into “libraries”), and while we did use those as arguments in our appeal for Evergreen, it was really the pragmatic aspects that made it all possible.

1) The building blocks in the software world were a lot bigger than they used to be (and this trend continues to be true), and increasingly open source themselves.  We didn’t have to constantly reinvent the wheel, and could use software like GCC, Linux, Apache, PostgreSQL, Ejabberd, Mozilla, CVS (and then Subversion, Bazaar, and Git), MARC::Record, Simple2ZOOM, etc.  We could be informed by and share code with other open source efforts like Koha.

2) Each of these open source applications had (and continues to have) development communities and ecosystems that we could participate in (including the wider open source community as a whole).  We could (and do) leverage volunteers and domain experts who just want to help out.  Or pay people if we needed to (we did that too, for example, with some enhancements to PostgreSQL).

And all of this not starting from scratch actually allowed us to start from scratch, with more modern design paradigms.  🙂  For example, we made real use (not mere buzzword compliance) of relational databases and a service-oriented architecture.

Most importantly, we were already using these things prior to Evergreen in our daily work, and demonstrated what just a single developer could do with modern open source tools and software.  Now, with almost a dozen active committers and many more contributors of domain expertise, documentation, testing, etc.–in other words, a community of our own–we’re pretty much unstoppable.  Happy Birthday Evergreen!

— Jason Etheridge, Community and Migration Manager


Quality Assurance, part 3

The QA project as funded is complete and a report of activities and analysis can be found here:

This work would not have been possible without the generosity of our funding partners: Georgia Public Library Service, BC Libraries Cooperative, South Carolina Library Evergreen Network, Bibliomation, and Central/Western Massachusetts Automated Resource Sharing.

There has already been interest in the development community for increasing our use of pgTAP for testing the database, and I’m hoping we can build on Equinox’s work for using integration tests with Evergreen as well.

However, as the report points out, QA is not a finite destination or a project to bring to completion, but rather it’s a journey — a process — that must be continuously embraced and championed.  Every new feature, every bug fix, every single change to the code requires a QA response and that requires constant resources.

We’ve found that it’s much easier to devote resources (both staff and money) to projects that provide a clear and definite deliverable such as a new feature. QA is a project that only seems to be recognized when something goes horribly wrong — and it doesn’t take much to tip over that house of cards, as we have seen in our recent past.

Equinox is soliciting ideas from the community about how best to tackle this problem. Equinox is willing to step into a (to be defined) role of QA champion, but we cannot do it without monetary support.

Some have suggested that we simply tack on a “QA tax” to our support fees, but the fact is many of the largest Evergreen users do not have a support contract with Equinox. It also makes our support costs higher than competitors, so it does not make good business sense.

Equinox will support whatever direction the community decides to take on this issue — however, a direction must be decided and action needs to be taken or we will certainly find ourselves in a bad situation again.

Quality Assurance, part 2

Quality Assurance, part 2

We are entering our 4th week of the QA project and here is what we’ve done since the last report:

  • We’ve created the unit test for the Dewey sort bug in Koha,, and for the same bug in Evergreen, we created a pgTAP test against the database as part of, along with many other examples of pgTAP unit tests. These changes merge in with previous pgTAP work done by Galen Charlton.
  • We ported some of Kevin Beswick’s work in OpenSRF for unit tests in C to Evergreen, and created some example C unit tests specific to Evergreen:
  • We’ve also been reviewing GNU AutoTools, Buildbot, and Bill Erickson’s Evergreen Installer Scripts for Debian Squeeze and Wheezy, with an eye toward testing running systems, as opposed to build-time checks. The pgTAP tests, for example, require an actual database with the Evergreen schema to be useful, and we’ll need to use Evergreen’s stock test datasets for API and performance testing.
  • We’ve sent out a survey for wide dissemination to Evergreen users, staff and patrons alike, to gauge which functional areas of Evergreen appear to be most important to Evergreen users: We’ll send out a separate survey in the coming weeks to gauge which functional areas of Evergreen appear to the be most painful or cumbersome to Evergreen end users. These are being done separately so that the data can be gathered as objectively as possible, and when we combine them later we can plot the functional areas on the two axes, pain versus importance. We might then, for example, deem the functional areas that are furthest from some relative origin on the plot in the quadrant of most importance and most pain as the ones that should get the most attention. This is useful information in general, but for the purpose of the QA project, we may tackle one or two of these highlighted functional areas as a case study in how to use QA in conjunction with fixing the problems.
  • We’ve identified existing developer documentation to serve as best examples for core languages/domains within Evergreen: These examples need to be worked into some sort of primer/styleguide for EG development and/or debated/reviewed by other developers.
  • Finally, I’ve been microblogging some of this at

Next steps:

  • Iron out the automatic installation of Evergreen for the purpose of testing, and actually fire off tests that depend on this such as the pgTAP examples.
  • Construct more tests in this vein, for API testing, etc.
  • Send out the second survey for EG pain points.

Quality Assurance

Earlier this year, Equinox’s president, Brad LaJeunesse, put out a call to the wider Evergreen community for literal and figurative buy-in to a project for improving the QA processes and tools used with Evergreen development:

Several members of the Evergreen community pitched in and this Equinox-managed project is now funded.  The deliverables are outlined below.

  • Identify and assess the efficacy of existing resources and processes.
  • Deploy examples of unit tests for each language and domain within Evergreen.
  • Deploy examples of API tests for Evergreen’s internal and published APIs.
  • Document, with narrative, an example usability test and analysis, and the resolutions to problems discovered.
  • Identify or create best examples of developer documentation for each language and domain within Evergreen.
  • Demonstrate through initial implementation how continuous integration can provide regression testing.
  • Analyses of available UI testing automation tools, and, if possible, design of a UI Testing framework.

The project has been running for a little over a week and here are the results so far: (more…)

At Equinox, unlike other administrative roles I’ve had, I get to work directly with libraries to help them solve their problems.

Vice President