But the truly significant activity in LibraryLand technology hasn't been vendor-driven. It has been the maturation of what I call "enterprise open source": products such as Evergreen and Koha that are robust, well-implemented library automation packages with strong development communities and equally strong funded-support models.
Hear hear! Karen examines the value of open source, and finds that it's not so much in that it's a lower-cost alternative (although that can be a persuasive argument), and not so much that you have the ability to modify the code (although that can also be a persuasive argument), but that it depends on the strength of the community to continue to exist and improve. And that makes it a very good match for libraries, because we seem to do "community" better than most other industries.
So let me take a different tack than Karen, and assume that if you've read this far that you're interested in supporting open source for your library, but maybe you don't have a programmer on staff. How can you help?
Well, there are many ways other than programming to contribute to an open source community. Evergreen, for example, just posted a call on its development mailing list for help in defining and prioritizing the requirements for its acquisitions and serials modules. If you have experience with these areas, and have blue-sky ideas for how you could build a better system, this is a great opportunity to step into the conversation. There's a bit of a parallel here to proprietary systems, although with a proprietary system it's called a "request for enhancement" and most of those tend to get filed in the distant future. With Evergreen's invitation for discussion, you _know_ the developers are happy to listen to the ideas for making the best possible product. They don't have prior baggage holding them back, so they really can start from square one - and they have a huge incentive to do better than the existing options, because they want to convince you to pick Evergreen the next time you're thinking about your next ILS.
Or you can contribute your hard-won experience and knowledge to the documentation wiki. Evergreen and Koha both have wikis to which you can contribute. Interestingly, there is a parallel here to at least one proprietary vendor, which set up a wiki (behind a password-protected site) after many requests from their user group. It boggles _my_ mind, but some of these same customers have also argued that they (the customers) should pool their efforts and write a new set of manuals for the product for which they are paying support and licensing fees. I'm sure the Evergreen and Koha projects would really appreciate your assistance in writing a good set of manuals, and they won't charge you for the privilege, either.
You can also participate simply by joining in the conversations on the mailing lists or chat rooms (#OpenILS-Evergreen on Freenode for Evergreen, #koha on Freenode for Koha). You'll take some time to get familiar with the products, no doubt, but once you've climbed over the brick walls (with the help of the others on the mailing list), you will have the opportunity to pay it back a dozen times over as others face the same walls that you faced. I see this same principle on our proprietary vendor's mailing lists. The customers do a far better job of supporting each other than the vendor to whom they're paying support and licensing fees.
And it feels good, working together to build something that belongs to an entire community. For the little bits that I've been able to do, I get a huge sense of satisfaction. It's a nice little addiction.
Dan, re/doc for that proprietary vendor - re-writing the doc was, ahem, my idea. I hate to say it, but sometimes if you want something done you've got to do it yourself.
Re/fund accounting, acq and serials - I wouldn't separate these from each other or electronic resource management. Seems to me they all go together.
If there's interest in ERM, no reason not to see how much of SFU reSearcher suite can be productively incorporated into Evergreen. The Ruby-based Open URL/Link Resolver from Oregon comes to mind, too, though the name escapes me at the moment.
Okay, my point about serials & acq is grafting the accounting portion of Sakai on to Evergreen (the Woodchip project, isn't it, at the U. of Windsor) won't be easy. Aren't these two products, Sakai and Evergreen, very different architecturally (sic)? Have look at xTuple (http://www.xtuple.com). It uses PostgreSQL for a backend database and features an accounting package and a report writer. Maybe this would be a better fit than using a chunk of Sakai. Or not. Just a thought.
For ERM, yes, it absolutely makes sense to integrate with CUFTS (the SFU reSearcher project).
And you're thinking of LibraryFind (http://libraryfind.org/) for the Ruby on Rails-based metasearch application.
For the serials and acquisitions, actually, there's nothing going on with Sakai that I know about. It would make sense if academic institutions were looking to integrate with an OSS course management system, perhaps.
Evergreen's Woodchip proposal is based on OFBiz / opentaps (http://ofbiz.apache.org), which will happily use PostgreSQL. Although xTuple looks interesting, it appears to be covering similar ground -- and has the disadvantage of not being a top-tier Apache project
For a summary of the ground that's been covered so far in acquisitions and serials with Evergreen, the following wiki search does a reasonable job: http://open-ils.org/dokuwiki/doku.php?do=search&id=acq - although note that some ideas that have been expressed have been acknowledged to be dead ends; these are nowhere near design documents yet!