Equinox Blog

ALA Techsource, a publishing arm of the American Library Association, just published Open Source Integrated Library Systems, a Library Technologies Report by noted librarian-technologist Marshall Breeding.

Overall this 32-page report is of value to the open source community, but get it while it’s hot from the oven. Most of the report focuses on present-day knob-and-dial functionality, which means that “the shelf-life of this LTR [is] likely to be measured in months,” as Roy Tennant noted in a recent issue of Current Cites. Also, Breeding’s report is limited to integrated library systems, which means it does not address the myriad open source library projects such as Jangle, SOPAC and Vufind (which collectively would make a good Techsource report on their own merit).

However, Open Source Integrated Library Systems does provide a snapshot of the state of the major open source integrated library systems in production (Evergreen, Koha, NewGenLib, and OPALS), while introducing and explaining some of the core concepts of OSS development.

Parts of Open Source Integrated Library Systems are more fruitful than others. Breeding is on shaky ground when he devotes two large paragraphs to the virtues of MySQL and then adds a curt coda about PostgreSQL, the well-respected, very powerful database environment used by Evergreen. But Breeding acknowledges the strengths of OpenSRF, a communications layer in Evergreen, and he does a commendable job of outlining the differences in licensing models between (and within) proprietary and open source software. This latter discussion alone will be helpful to many in our field, and extends the usefulness of this report.

In other sections,  Breeding lingers to think on the page, and this is often interesting.

I confess when I heard this report had been published — and it was unheard-of within the Evergreen community until shortly before its publication, when its review in Current Cites come over the transom — I had been bracing myself for Breeding’s oft-repeated suggestion that the total cost of ownership (TCO) for open source could meet or exceed proprietary products.

So it was a pleasant surprise to see Breeding more nuanced on TCO than he has been in the past (we are frequent flyers on similar speaking circuits).  Perhaps he has mellowed on this point due to his involvement in the “academic” open source ILS exploratory project, OLE, for which Vanderbilt, Breeding’s home library, is a member, and for which  Breeding participates directly as a member of the Connecting with Other Projects working group.

The OLE project has only recently risen from the fertile soil of LibraryLand. Like Extensible Catalog, a project out of the University of Rochester, OLE is in a ramp-up period of design and development. (Extensible Catalog plans to have a working product by mid-2009.)

While Evergreen stakeholders keep a watchful eye on the distribution of technology grant funding, it won’t fatally damage existing OSS projects to have yet another project on the table, and the many discussions among the projects — such as OAI-PMH development for Extensible Catalog, and collaborative discussions with OLE — can only help Evergreen’s future development.

Returning to OSS and TCO, the most pragmatic and most common argument for open source in libraries is the predicted lower total cost of ownership, and TCO tends to dominate the discussion in Breeding’s report, as well.

TCO can be a problematic argument. It teeters dangerously close to the rationale that OSS is “poor people’s software.” (Or as one speechifying vendor put it last year, OSS is only good for third-world countries — as if third-world countries were not deserving of good software.)

There are many other, equally pragmatic reasons to move toward open source that might have been valuable for this report to discuss at length, had space and/or printing costs permitted. (Remember when Butterfingers were a nickel, and LTRS were 60+ pages long?)  These reasons include the flexibility of easily-customizable software, the native interoperability of software whose code and indeed, development can be viewed by other software partners in the OSS and proprietary field, the security that comes with transparency — it is hard to snow customers that “Taos is on the way” when the code is out there for all to see — as well as more easily achieved customizations and rapid application development.

Given proper leadership and encouragement, open source projects can engage far more developers than any one company could ever hope to. That doesn’t preclude the value of a “seed company” such as Equinox, Media flex, Liblime, or in the broader world, companies such as Red Hat. It is just a mathematical truth that there is major FAIL written all over the model where perennially cash-poor libraries pay licensing fees to closed-code companies, who then try to scrape R&D out of the same small pot providing support, sales, salaries, and other corporate essentials. It’s just not a winnable war. We had it right the first time, when we were building our own code back in the 1970s and 1980s; we just didn’t have the file-sharing technologies to make it possible to collaborate. Some folks have said if the Internet had existed back then, libraries would have invented open source.

Compared to closed code, OSS is a far more flexible economic model. In OSS, development can be produced for money (also called a “bounty”), as a quid pro quo from interested institutions, or (less often, but it happens) individuals in the field. Every good line of code counts toward the effort–sometimes immeasurably. In this sense, OSS in libraries resembles the micro-economics that benefit (ahem) third-world countries: a margin of effort in librarianship counts more than out there in posher corporate environs.

Another, less tangible benefit of OSS lightly touched on in Breeding’s report is that it puts libraries back in the drivers’ seat. There are significant long-term strategic advantages (fiscal, professional, and pedagogical) for libraries to return to the place we were in for over a century, where we designed and built our service-delivery tools.

Tool design forces humans to think and to contemplate, and in our evolutionary history, helped lead us to larger craniums, civilization, and the ability to accessorize.  In librarianship, tool design, from the standard card size to Serial Keyword Index of the 1970s to the catalogs we designed through the 1970s and 1980s, compelled us to ponder and think about what we were doing.

This collective intellectual effort — the stuff, Andrew Abbott argues in The System of Professions, that makes us a profession in the first place — was temporarily lost in the period where without benefit of easy file-sharing or a body of thought related to the value of collaborative development, we handed our code over to companies who in many cases had every intention of partnering with us, but were stymied both by the intellectual-property models that drove software revenue back in the day, and by the growing syndrome of what Lori Ayre calls “ten years of learned helplessness” (it’s closer to three decades) that threatened to turn us into the shoe clerks of the information age.

(Shameless horn-tooting: this was roughly the topic of my five talks for VALA and CAVAL in November — how our creative endeavors and tool-building gave us a century of empowerment, and how the renaissance of open source development puts us back in the driver’s seat.)

In any event, perhaps it is out of scope for a short report to think so broadly, but these more abstract benefits of open source are nontrivial, and are quite obvious to those of us who have seen it both ways.

There are a few remaining quibbles. Breeding’s attempts to distinguish the acquisitions requirements of “small public libraries” overlook that many of these libraries are just as interested in EDI as the largest ARLs, and have complex acquisitions workflows in place to support their equally complex needs, often as nodes in a larger organism that is a shared consortial catalog.

In a couple of places the document contradicts itself. Breeding states that “large municipal libraries have not been moving toward open source products,” then notes quite accurately that King County Library System “has publicly announced its interest in moving toward an open source ILS.”

Then again, the largest municipal libraries, though they may be nimble in many respects, really cannot move on a dime, at least when it comes to the massive, complex legacy migration issues. In any event, as Breeding notes elsewhere, right now large municipal libraries aren’t “moving” anywhere — most right now are limping along with legacy systems while they try to keep boots on the ground and books on the shelves.

Once in a while, I blinked, as I did when Breeding commented in a discussion about the growth of open source, “The classic polemic casts Microsoft as a monopolistic domineering company against the open source companies that free the world from its stranglehold.”

That statement was awkwardly squeezed into an otherwise-reasonable discussion; perhaps it was there for the zing factor.   Regardless, if you look at the website for any library open source project from Archon to Zebra (and not overlooking our favorite vowel along the way, “E”vergreen), you will find precious little polemic but plenty of well-supported arguments for the value of open source to libraries — an argument Breeding largely accomplishes in his report.

Open Source Integrated Library Systems has some small errors suggesting a second edit, perhaps with some accompanying phone calls, might have been in order. On one page Georgia PINES, the mother ship for Evergreen, has 266 libraries, and a page later, more than 270. The latter is correct; 275, to be precise, though to use that number in press releases, where no doubt this fact was gleaned, would sound too Urkel-like.

But overall, Open Source Integrated Library Systems provides insight into the juggernaut of open source in libraries; it’s a quick ramp-up for library professionals trying to get up to speed on open source. Furthermore, this report and accomplishes something that for many in our profession, only a printed book can do: by virtue of its being published at all, and through Breeding’s stature in our field, this report, however slender, casts the imprimatur of sober respectability on a development model that has its historical precedent in well over one hundred and thirty years of innovation in our profession. If Breeding does not entirely close the loop to electrify that point, he can be forgiven. The Book can now be placed on the Shelf.

Bookmark to:

Recently, over on the eIFL website, Randy Metcalfe posted “The Square of Engagement,” a terrifically well-crafted and fully-baked discourse on the many facets of engagement with open source.

To over-simplify one of his main points, Randy is saying something that needs to be part of our open source advocacy for 2009: engagement takes many shapes.

People new to OSS assume (incorrectly) that to participate, to be part of the community, they must get hands-on with the code (from installing it to actually helping develop it). But there are many ways to participate — from simply using the software to assisting with documentation, engaging with developers about the future path of the software, providing usability reviews, funding “bounties” (work for hire), or simply chiming in when a question comes up on a list.

The upcoming, first-ever Evergreen Conference (May 20-22, Athens, Georgia — website and calls for programs to debut next week!) is its own form of engagement — of learning, sharing, networking!

The more active forms of open source engagement can seem alien to libraries accustomed to using software “off the shelf,” where software seemingly pops out of the great biscuit can in the sky. But as we who like to putter in the kitchen know, there’s no substitute for experience — and the people who use recipes are just as important as the people who write them.

Experience doesn’t just teach you more about baking biscuits — or creating software for our users; it makes you more committed to the process — and that process brings us closer to our communities and their needs.

Bookmark to:

(For a definition of FUD — Fear, Uncertainty, Doubt — and other open-source terms, see this open source glossary.)

So I’m sitting in my home office studying Docbook, a standard for technical documentation, when a Chrismahannukah Elf draws my attention to two PLA TechNotes on Open Source.

No disrespect to the professional association that commissioned this work, but these documents may well explain some of the “But I heard…” questions we in open source library development encounter.

Mind you, it’s worth addressing the pros and cons on any topic. When I wrote about open source for ASIST, I strove for middle ground. Yes, I do conclude that open source is a worthy path to follow, but I address its limitations and I also provide evidence for my conclusions.

These documents (which share some common language) start out well enough: open source software is free in many senses of the word — free to share, view, download, modify.  There are no licensing fees for Evergreen or any other open source software.

But in the “disadvantages” section, one document states that a library may need to “do a great deal more work than anticipated to adapt the software” and that “If local development is undertaken, new
releases may not be compatible with what has been done locally.”

First, I’ve watched large teams of library developers struggled to “adapt” proprietary software, or really, to develop around its inadequacies and hidden source code. For systems of any significant size and political complexity, “turnkey” is a fantasy. What would you rather “adapt”: code that is free to view, share, and download — and discuss and debug on public lists and chatrooms — or some vendor’s super-secret code you can’t entirely view and are often bound by contract not to discuss in the open?

Second, this article doesn’t really get its head around the concept that in open source development, development rarely stays “local” (even if it starts there). After decades of learned helplessness in our own field, the idea that software developers can work in an open “collaboratory” can seem outlandish to those of us who don’t know another model, but it works. Over 150 people contributed to the most recent version of WordPress; thousands contributed to the most recent version of Linux. Evergreen grows not just with the team at Equinox but with contributions from other states and countries.

The proprietary licensing model relies on a finite number of vendors working for a commercial company. That model works very poorly in LibraryLand, where we simply can’t afford the costs that would result in truly agile research and development.

Then one article says:

The decentralized development of open source software means that progress can be chaotic and there may be delays in addressing bugs and in completing planned enhancements. … Not only may there be lack of coordination within an open source development project, there may be little attention paid to integration with other applications.

Every major open source project I know of has a development process, a project development timeline, and well-orchestrated development.

But at this point my question became, where are the examples? The citations? The sources? The evidence?

One of the documents goes on to state, “No training comes with most open source products unless a commercial vendor is retained.” But that’s how most training is provided: somebody pays for it. For Evergreen, some organizations build their own internal training, while other organizations such as SOLINET offer fee-based online courses.

Then comes the statement, “There usually is limited technical support, especially for users of the software. However, a few open source products do have training and technical support available commercially for a fee…” followed later by the sweeping statement, “Only purchasers of proprietary products can expect financial and other contractual remedies for poor response times and loss of functionality.”

Again, more head-scratching. There are really only two models for software support: you do it yourself, or you pay someone for it. Every active open source library system has a corresponding support and development company. I work for one. These companies offer support levels, turnaround times, and anything else you’d expect from a “proprietary” vendor.

Then there is Evergreen; at which point I began to wonder when these documents, dated mid-2008, was delivered to its customer. The ILS document says, “as of early 2007 several public libraries in
Georgia were using the system…” Evergreen, which rolled out in production for 258 libraries in September, 2006, was in operation in over 270 libraries by early 2007, and by mid-2008 was in 275 PINES libraries and in several sites outside of Georgia, with contracts in place for additional library agencies.

I had to struggle to finish reading the documents after this statement:

Open source software may not offer the scalability and speed of proprietary software because the easy-to-use and general-purpose programming languages used are not very scalable and are slower than other languages.

Seriously? Compared to the legacy languages used in older products?

Georgia Public Library Service wrote Evergreen because not one single vendor was able to support the needs of PINES. For PINES to grow, GPLS had to write better software — and that is what it did, building in scalability from the bottom up by choosing the right database — PostgreSQL — and a consortial-strength database schema. The statements about Perl are not just wrong, they’re irrelevant.

There is more… much more. OPALS, a small but highly viable project, was overlooked entirely. Languages are described incorrectly. Mistakes were Made, and FUD was Spread. But honestly, I need to move on to other work tasks.

I do have a post parked away about Marshall Breeding’s ALA Techsource report on open source, but here’s my summary review: while not flawless, it’s a good basic introduction from a recognized authority.  Put Breeding’s report in the hands of your library administrators, and perhaps we won’t have so many “But I heard…” questions to deal with.

Bookmark to:

Laura McFarland joins Equinox Software at a fortuitous time, when Evergreen is in a very robust development stage and more and more libraries are coming on board. Laura spoke with Equinox about open source, good software, her work habits, and (we have pictures!) her family and pets.

What interests you about working for Equinox?

It’s a thoughtful product.  Good software that is thoughtful and well-planned is hard to come by. Evergreen developers have made something truly awe-inspiring, and that’s hard to do when it comes to software (I hate most of it and can find a thousand ways to make it better, usually ).

Then there are the people.  Everyone here has been simply fantastic.  I felt welcomed the moment I stepped through the door. My first day, when I sat down at my desk, I finally felt like I was where I was suppose to be.

What’s important about open source software?

What isn’t important about open source?  Seriously, open source software has always had a special place to me.  It’s amazing what can happen when you take people who care about something and give them free reign.

The naysayers will complain about lack of quality and maintainability, etc. - but when you take out the aspect of having a corporation decide how much code should be written, what the product should do, and “Hey, can you get that done in say…6 weeks?” and you put the power of the development back into the developers’ hands, you’re almost guaranteed a better product.

Where do you see open source development going in the next ten to fifteen years?

OSS development has gained a lot of momentum over the past decade already.  I can only imagine that the trend will continue, and begin trickling over into corporations (which it sort of has, already).

When you get stuck on a problem, how do you solve it?

I compartmentalize, mainly.  I begin by removing layer upon layer of known data to get down to where the true problem lies.  Once I figure that out, I can rebuild to correct or solve said problem.  I also must know why the problem happened in the first place in order to prevent it from happening in the future.

When it comes to code, I prefer the “head upon desk repeatedly” method, until I finally analyze and chew over the problem in my head enough that the true problem comes to me in a flash.  This usually happens right as I wake up in the morning, and I rush off to the laptop to try the solution.  This also happens with difficult math problems…my brain is an interesting creature, to be sure!

What do you keep on your desk?

Coffee. There is usually a cup of coffee on my desk.   I am also an office supply field; I love organization.  So, at the moment, there are a TON of notebooks on my desk, but as the weeks progress there will be more organizational things, and office supplies. I have notebooks for specific purposes and don’t write in them unless it’s for that purpose. Some may call that obsessive-compulsive, I call it…wait for it…ORGANIZATION!

I also have a lot of O’Reilly reference books.  I like books-duh!–and my kids are constantly asking me why I keep buying/acquiring new books when I have so many already.  I want my own personal library. That may be a sickness, but that’s ok. [Editor's note: you're in good company.] I also keep gum and trail mix on my desk…you never know when you’ll need clean teeth/breath and/or protein…I’m just sayin’.

What do you do to chill out? Or is that even possible with three boys, a full-time job, and a degree program?

I like to knit socks, scarves, fingerless gloves/mittens…I haven’t done a sweater yet, but I have one started.  I also go to Girls’ Fight Club every Sunday at a local park.  A group of women that I know all get together and train in Muay Thai.

I trained at a gym for a few months, but then moved from the area, so a friend of mine (from the gym) started Fight Club so that she and I could workout and we could teach others the joy of fighting.

Then there is photography, coding, and bike riding (although I don’t do as much bike riding as I’d like, but I try for once a month at least-a good 20+ mile ride is my idea of a good Sunday!).

And in all honesty: math.  I have a renewed respect for mathematics, and I actually enjoy math, on occasion-when it isn’t before a test and I’m cramming as many formulas into my brain as I can manage.   I guess I should admit my love of video games too while we’re at it…airing the dirty laundry, FTW!

Do you have any pets?

Linux

I do! I am an avid animal lover.  I have two cats, Alice and Tallulah and a Chihuahua, Linux.  We also have a snapping turtle, Horatio, who lives with my boys along with the black lab we adopted from the pound 11 years ago (her name is Sammie), she’s always protected the boys, and they adore her –the boys love animals more than anything, just like their mom

I keep asking for fish or a puppy for my office, but no one thinks I’m serious!

Bookmark to:

You probably think this post is going to be about Marshall Breeding’s new Library Technology Reports on open source, but I’m too busy making notes with my red pen to get that post done today (my review will probably be on the Evergreen blog).

Instead, this is about an article in Business Week that says open source is such a healthy model that the companies that support it will go out of business:

And therein lies the great paradox: Open-source code is generally great code, not requiring much support. So open-source companies that rely on support and service alone are not long for this world. The traditional open-source business model that relies solely on support and service revenue streams is failing to meet the expectations of investors [my emphasis].

A very wide smile stretched across my face when I read this. The key phrase to focus on is business model, because a successful business model for LibraryLand is a very different animal than business models for the typical reader of Business Week.

First of all, libraries can do more with a nickel in their pocket than most businesses can do with a wad of C-Notes stuffed in their Armani three-piecers. Face it: years of operating on nonprofit-sized budgets have made us so thrifty you can see the darned holes in our socks.

This is also a way of saying libraries operate on margins of subsistence unthinkable to most big corporations. The most well-staffed, well-funded library has to pick and choose what it will support in-house versus what makes sense to outsource — not just with IT and development, either, but with services such as book processing, accounting, and even reference services. Just because you can do it, doesn’t mean it makes sense that you should.

LibraryLand also doesn’t have a critical mass of developers for any major project (and too often, the resistance to software Not Invented Here results in splinter projects, further bifurcating our efforts). Would that it were otherwise, but I don’t see that changing any time soon. The other phrase I singled out in that quote — “much support” — presupposes a level of staffing that would be the stuff of fantasies for many libraries.

I remember reading a number of reminiscences about the fall of the dot-com era where toward the end, the company would cancel the lavish perks — the catered lunches, the special services. Yeah, I thought, I better cancel that private jet, ha ha ha, then I got up and changed the toilet paper in the library’s bathroom as the snow blew through the cracks around the doors of this old building through which, somehow, we supported a community’s library needs. We had automated, and that was great for us, but it happened on an economic scale that Business Week readers would find crazily unsupportable.

I’ve also been to the Googleplex in Mountain View (twice, in fact), and though I signed an NDA, I can aver that the rich are very different than you and I (mostly, as Hemingway observed, because they have more money).

The Googleplex was lovely, and lusciously appointed — yet also, with its chef-appointed cafeterias and manicured grounds, palpably removed from the hustle and flow of real life. I was glad to see how the swells live, and also glad to return to the homelier honesty of the real world. In my imagination I’d love to see libraries lavishly funded, but given our missions, it may not be an entirely bad thing that this will never come to pass.

So, with all due respect to the open musings of Stuart Cohen — who as CEO of the Collaborative Software Initiative, probably has much valuable wisdom to share with the businesses he consults with — my response to him is that a company establishing a business catering to librarians will build its operational model around the realities of LibraryLand or go out of business very quickly — and that operational model will keep open source support and development companies in the black for a good long time to come, if not forever.

Bookmark to:

Equinox Team, December 2007

Originally uploaded by Evergreen Open Source ILS

This was the 2007 holiday picture for Equinox, the support and development company for Evergreen, just six months after the original Evergreen development team founded the company.

Equinox has grown since then, acquiring more developers, a project manager, office manager, and a community librarian. The eleventh Equinox staff person, a developer, will join the team on December 8, 2008.

Evergreen has also grown since then — see the Evergreen Libraries wiki page for proof of that!

We’ll upload the 2008 photo in a week or two — our photo shoot is today. Corralling a growing company for a single photo shoot was an interesting exercise for Corinne, our tireless office manager.

The photo: from the left, clockwise: Jason Etheridge, developer; Bill Erickson, developer; Don McMorris, operations manager; Bob Molyneux, VP, business development; Mike Rylander, developer; Brad LaJeunesse, Equinox CEO. Picture by Dan Scott.

Bookmark to:

I just returned from a five-city”road show” hosted by CAVAL and VALA. I spoke about open source in libraries while Lizanne Payne of WRLC spoke about mass storage. In two weeks we visited libraries in Sydney, Brisbane, Perth, Adelaide, and Melbourne.

(I think Melbourne was my favorite, but that’s because I grew up in San Francisco, which looks and feels a lot like Melbourne — two cities with Victorian gold-rush roots.)

As always, I learned a lot from these visits. First I learned from all the preparations I did for my talk — piles and piles of books about library history, going back to the mid-1900s. I tried to tie together a full century of library innovations to the open source movement today. Then, as always, I learned from the visits themselves.

There were many good things to see throughout my trip (and some delish cream scones at our next-to-last library stop), but Brisbane City Library made my socks roll up and down. I encourage you to visit the entire Flickr set (just click on the picture above).

Some innovations at this library include:

* A highly-sophisticated self-check system where patrons can watch their books disappear into the automated-sortation area

* Tools and space for gaming and media that as Bibliotheka points out has resulted in a bump in library use among males aged 18 to 35

* Color-coded Dewey shelving (”Go upstairs and find the pink shelves…”)

* A lovely glass meeting room that floats celestially above the first floor

* Comfy, attractive furniture that can be angled around the terrific city views from library windows or pulled together into impromptu study circles

* A business center staffed by city experts

It’s not that I haven’t seen bits and pieces of all these innovations in various libraries — but this library has a sustained “wow factor” that keeps going and going. Should you happen to find yourself in Brisbane, do stop in.

Bookmark to:

Over on the Evergreen project blog you can find Volume 1, Number 1 of the Evergreen newsletter, a new monthly publication for all things Evergreen. This month’s issue updates you on the 1.4 release candidate, acquisitions, save the dates” for Evergreen events, the most recent libraries to “go Evergreen,” URLs for recent webinars, and more. (Except — d’oh — any mention of the Evergreen Conference next May, in Athens, Georgia. My dumb omission!)

You can blame John Fink and Dan Scott for suggesting this newsletter way last spring, even before I began working at Equinox. I held back for a little while before launching the newsletter so I could get to know the community better.

This turned out to be wise, because through the part of my job that can roughly be described as “external relations” I am learning that the seemingly monolithic open source “community” is really a series of communities with their own distinct needs, interests, goals, habits, and special contributions.

The Evergreen community includes some very dedicated developers, but it also includes people such as Robert Soullier of Mohawk College, who took the time to gussy up the recording of the most recent Evergreen webinar, and the librarians who on- and off-list, in webinars, and in small-group discussions, and in opening their libraries to Equinox, have offered many thoughtful and important ideas about the direction of Evergreen’s development and documentation, and training. In this picture you can see Jim Cooper of West Georgia Regional Library System, who recently opened his library and set aside plenteous time to help Equinox and PINES staff better understand his library’s observations about Evergreen.

Out in the field, I hear some refreshing twists on some of the hallowed assumptions about OSS development — or for that matter, development at large.

For example, in a variety of jobs in my past I’ve heard developers complain that nobody participates in testing software.

But in talking to librarians, it’s clear that call is often too fuzzy and open-ended. Narrow the request to specific features-for example, “ensure the new Frobbinator displays the Doomaflatchies in the staff client”-and at least a few willing victims will gladly step up to the plate. I’m hoping with the next release of 1.4 we can put out a laundry-list of things to test and ask people to commit to bits and pieces they have the most at stake in.

Because it does take a village — and that village has many interesting neighborhoods.

– Karen, Equinox Community Librarian

Bookmark to:

There’s a small element of defiance in that blog post title. The news “out there” in the wider world is a little rough, no doubt about it. But I am going to keep my eyes fixed on the good stuff happening around us — and it’s exciting to watch libraries joining the Evergreen community and watch Evergreen continue to grow and mature.

The National Weather Center Library will be the first (known) special library to “go Evergreen.” Evergreen scales all the way down to home libraries and all the way up to huge consortia such as Georgia PINES — and also fits in every type library.

Meanwhile, Grand Rapids Public Library went live with Evergreen on Monday, September 29. GRPL is the second Michigan library to go live with Evergreen. You can follow the Michigan Evergreen Project as five more libraries go live before 2009 (they’re even blogging).

Also, in addition to all the great new features in 1.4 — which is coming along briskly — Evergreen is going to get some very pretty foliage, just in time for the fall fashion lineup! Yes, there will be a very lovely, wonderful new design option for Evergreen’s catalog — not just more attractive, but more usable and a little bit more lightweight.

Plus we did a special Acquisitions webinar for Georgia PINES (the mother ship for Evergreen) and it went great. PINES is now doing what other Evergreen communities might consider: growing a committee to engage with us on acquisitions development. Expect more webinars on other topics, announced more widely.

Next, a small thing, but in case you hadn’t noticed, in the last month or so the Evergreen project site has spiffy new Frequently Asked Questions (in three acts, no less!) and a simpler-to-follow Roadmap, and also sports a new Open Source Glossary and updated Evergreen Feature Request Procedures.

Finally, we have found several terrific documentation writers — woohoo! (But if you were thinking “gee, you know, I’m still interested,” drop me a note at kgs at esi library dot com — we have some other documentation needs.)

Bookmark to:

We have an immediate need for writers who can produce well-written documentation for acquisitions services in library automation software. Librarians and other library workers who use, configure, or manage library acquisitions systems are the audience for this documentation. This is freelance work to begin in September, 2008 and be completed no later than December, 2008. Rates are competitive. Contact Karen Schneider, Equinox Community Librarian with at least two relevant writing samples and a brief description of your experience with writing documentation.

Bookmark to: