Coffee|Code : Dan Scott

Sometimes forking a project is necessary to reassert community control over a project that has become overly dominated by a single corporate rules: see OpenIndiana and LibreOffice for recent examples. And in the world of distributed version control systems, forking is viewed positively; it's a form of evolution, where experimental branches that lead to new features or a stabler system or better performance get grafted back onto the accepted authoritative branch.

Yet a negative connotation can also be associated with forking a project, particularly if the word is whispered behind closed doors as an accusation of the behaviour of one or more parties in the community. Particularly in a small community, where development resources for a project built on the principles of software freedom from the ground up are relatively scarce, the spectre of a development effort based on that project that is not publicly visible can be troubling and opens the door to the accusation: FORK! Organizations that have staked their customers' satisfaction, and their own reputation, on free software that they expected to see flourish as others joined in the development effort, fret and worry that they'll be left behind with just the base for another organization's project and no easy way to reconcile the two.

In the Evergreen community, we're fortunate that we're small enough that we should be able to avoid these concerns. The Evergreen "trunk" code repository has been hopping; just take a peek at the revision log to see the rather torrid pace of development. Some major features are taking shape, such as acquisitions with EDI support, first-class serials management, outbound telephony, and more - evident in the Evergreen 2.0 alpha 3 release that the development team put together today. This is not a minor release!

And yet, and yet... during the exciting KCLS migration live-blog, Lori Ayre felt it necessary to write:

The answer is that much of it is already in trunk, and if it isn't there now, it will be very soon. None of this work is being held back. There is no KCLS fork. This is all Evergreen and anyone who knows how to download from trunk will be able to get at this code in very short order.

Well, I know that everyone involved with the KCLS enhancements are good people, and that that it is certainly their intention to make any of the enhancements available, and there is no intention to fork Evergreen. I know! Ironically enough, however, due to the prior actions of proprietary companies such as Relais' "announce that we will open source our ILL product in 2008; freeze the market; announce in 2010 that maybe we'll have something by the end of 2010" strategy, the broader library community has become more skeptical and susceptible to disinformation and FUD. I can't imagine who would want to sow discontent among the community of a rapidly maturing ILS project, other than perhaps proprietary competitors who have forgotten how to compete on the merits of their product rather than negative marketing. (Just a guess, mind you!)

Still: until the code for any remaining enhancements is available under an open source license, the possibility that those whispering, Saruman-like voices could be right remains an actual possibility. My suggested remedy for the easiest way to dispel those concerns, now and in the future for any project (Evergreen or otherwise), is to simply develop in the open:

• Create a public repository - SVN (Evergreen contributions), or Bazaar (Evergreen LaunchPad), or git (Gitorious), or what have you. Put a README in the top directory of the repository specifying that the contents are licensed under the "GPL v2 or later" or GPL-compatible license.
• Announce the repository on the Evergreen development mailing list. If you tuck your repository in an obscure location and don't tell anybody about it, it might technically be open, but that's not really the spirit of openness. You're also depriving your effort of possible collaborators, and possibly duplicating effort if somebody else is working on the same feature.
• Watch the rumours disappear and the fame, glory, and accolades roll in. (Oh, and don't forget to invite us to integrate the fruit of your labour into the core of Evergreen!)

Sure, there might be some material that you don't want to share: trademarked institutional logos or the like. But the bulk of what we collectively create should be able to be openly shared, not just when things are perfectly baked, but all the way through the process. Release early, release often, and keep the spooky whisperers at bay.

On October 13th, a very special event is happening: the Access Hackfest. A tradition since Access 2002, the Hackfest brings together library practitioners of all kinds to tackle challenges and problems from the mundane to the sublime to the ridiculous. If you can imagine a spectrum with three axes, you might be just the person to pose those challenges to the Hackfest participants!

What we're saying here, folks, is that we need suggestions for Hackfest projects. There are no limitations to these challenges: oh sure, you're bringing together complete strangers and asking them to accomplish in eight hours or less what the rest of the library ecosphere is incapable of or uninterested in solving during the rest of the year - but that's what makes the Hackfest MAGICAL. Example results of previous Access Hackfests are available from the Access 2004 web site, and Dan Chudnov's podcast that captures the spirit of the Hackfest from Access 2006 in Ottawa is available from Library Geeks.

We plan to keep the Hackfest suggestions secret until the moment of their unveiling on the morning of October 13th - can you feel the anticipation mounting? - so please submit your challenges in one clearly written paragraph or less (okay, the abstract should be one paragraph or less, but you can go into great lengths if you want to expound for those who get interested by the teaser) via the Hackfest submission form, or if you prefer, via email.

Update 2010-09-28: Fixed link

The home page for Information Technology and Libraries states:

Information Technology and Libraries ( ITAL) (ISSN 0730-9295) is a refereed journal published quarterly by the Library and Information Technology Association (LITA), a division of the American Library Association.

The September 2010 issue of ITAL contained an article by Sharon Q. Yang and Melissa A. Hofmann called "The Next Generation Library Catalog: A Comparative Study of the OPACs of Koha, Evergreen, and Voyager". As an Evergreen developer, I wonder just how much refereeing happened before this article was published. Certainly I am biased, but there are a number of problems with the study from my perspective:

1. The article stated "The latest releases at the time of the study was Koha 3.0, Evergreen 2.0, WebVoyage 7.1." Grammatical problems with that sentence aside, the first alpha release of Evergreen 2.0 was created on August 23, 2010. For an article published in September 2010, I find it highly unlikely that the authors were able to find any running instances of this version of Evergreen on which to base their information. Which leads to a problem with the methodology:
2. The stated methodology in the article was

   The OPACs used in this study included three examples from each system. They may have been product demos and live catalogs randomly chosen from the user list on the product websites. ... In case of discrepancies between product descriptions and reality, we gave precedence to reality over claims. In other words, even if the product documentation lists and describes a feature, this study does not include it if the feature is not in action either in the demo or live catalogs.

   This sounds like a thorough, pragmatic approach. But the product versions associated with each of the chosen examples are not listed. So while the article mentions the latest releases of each product, the actual reported experience might be based on an outdated version of the product. In the case of Evergreen, one of the chosen examples is two major versions behind the actual current stable release of 1.6.1.2, and another of the chosen examples is one major version behind the current stable release. In addition, one of the desired features of modern OPACs is customizability: not just the ability to turn features on and off, but also the ability to change the user experience significantly as a small matter of programming. Depending on which example OPACs were chosen for each system, the features the authors were looking for might not have been turned on or exposed.
3. On the "Single Point of Entry for All Library Information" feature, the authors state:

   While WebVoyage and Evergreen only display journal-holdings information in their OPACs, Koha links journal titles from its catalog to ProQuest’s Serials Solutions, thus leading users to full- text journals in the electronic databases.

   As far as I can tell, however, this is not a special integration feature of Koha; it appears to just be the use of an 856 with a URL that points to a link resolver for a lookup of a given ISSN. While it is a reasonable cataloguing practice, any other library system should be capable of that; Evergreen certainly is. However, check out this link for an example of how one can make an OPAC work harder by bringing resolver results right into the OPAC display. I built an Evergreen service, called open-ils.resolver, for caching resolver requests for ISSNs and used that service as the basis of a developer tutorial for writing Evergreen services. The idea isn't new; Jonathan Rochkind wrote about doing this back in 2007. But having a caching server-side implementation freely available for your library system is relatively novel. We've been using it since the summer of 2009. If you use Evergreen, then you can add this feature to your system too; it is written up in the developer workshop and is licensed under the GPL v2 or later, but if there's interest I can add it to Evergreen's core.
4. On "Enriched Content", the authors found that Evergreen offered only cover art. Of course, enriched content depends heavily on the content supplier and the chosen item. Since launching in 2006, Evergreen has provided enriched content such as cover art, abstracts, author notes, reviews, and tables of contents from Syndetic (requiring a Syndetic subscription, of course). In addition, Evergreen has offered Google Books integration in the form of partial & full previews (if available) inline in the detail page since Evergreen 1.6.0.0, thanks to the initial efforts of Alexander O'Neill at the University of Prince Edward Island. And as of Evergreen 2.0, the default content provider for cover art and tables of content will be OpenLibrary. Here's an example from our catalogue that brings in enriched content including cover art and a book review from Syndetic and a Google Preview.
5. On "RSS Feeds", the authors make the bold statement: "Koha provides RSS feeds, while Evergreen and WebVoyage do not". In the case of Evergreen, that's a laughable statement, because significant parts of the OPAC are built on RSS feeds. For example, in any Evergreen system, click on the "Basic catalogue" link and you'll find that it is nothing more than an RSS feed with a simple search form. If you are using Internet Explorer or Firefox on an Evergreen site, you might notice the search source selector widget is highlighted; that's because Evergreen is an OpenSearch provider, so you can easily add an Evergreen site to your browser as a search source. The OpenSearch results, of course, are built on RSS/Atom just like the examples in the OpenSearch description document. The default format that a user's custom bookbags are exposed in is also an RSS feed. I suppose the authors didn't find an RSS feed icon lighting up in the search results in the dynamic Evergreen OPAC and made the assumption that no RSS feeds were provided. To address this gap, I have added the one line of JavaScript to the default OPAC skin that adds the Atom feed link necessary to make the RSS feed icon light up. Not that many humans actually use RSS feeds directly - but it will help make it easier to find for future feature comparison articles.
6. On "Relevancy", while Evergreen does not currently use circulation data or "popularity" to affect relevancy rankings, I would happily argue that the out-of-the-box relevancy ranking algorithm is good enough to keep relevancy as the default sort option, while the relevancy algorithm of our previous ILS was simply terrible. Combine that with your ability to customize the relevancy algorithm, and I think an argument could be made that, while "Relevancy has not worked well in OPACs", it works well in this one.

As the article mentioned the latest release of Evergreen was 2.0, let me show you a screenshot of the default OPAC in Evergreen 2.0 as of the upcoming alpha2 release. Notice a few things:

• Those facets on the left are much closer to what the world has come to expect from a faceting interface. You get a narrowing effect on your current search results, rather than firing off a brand new search. There are pros and cons to this, but oh well.
• Notice that the RSS feed icon is lit up in the URL bar. Yes, Virginia, Evergreen has RSS feeds for search results, amongst many other things.
• The inline advanced search interface shows that Evergreen 2.0 offers an OR option, and clearly labels the relationships between the search terms.
• The OpenSearch source has been added to the list of Firefox search sources in the top right box, just by clicking on the icon and selecting "Add Evergreen catalogue"

Evergreen 2.0 inline advanced search interface showing AND and OR options