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
The QA project as funded is complete and a report of activities and analysis can be found here: http://nox.esilibrary.com/~jason/qareport/qa.html
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
We are entering our 4th week of the QA project and here is what we’ve done since the last report:
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.
The project has been running for a little over a week and here are the results so far: (more…)