Equinox Blog

(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:

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:

The first five FUDBuster posts in this series focused on some of the biggest whoppers spread about open source software and Evergreen in particular… the Fear, Uncertainty, and Doubt used to undermine an effort. Starting next week I’m moving on to discussing features in Evergreen, beginning with Release 1.2.3 and then moving on to other topics, so this is the last FUDBuster — for now.

FUD: We would have to run Evergreen on a locally-installed server!

Response: If your library system is providing Evergreen, all you will ever need to install locally is the Evergreen staff client (available for Windows, Mac, and Linux). If you want to see how this works, download the staff client and point it at the demo server.

Equinox also provides hosting for Evergreen for libraries that need or prefer to use an externally-hosted server and very-high-level external support. Equinox currently supports two hosted libraries, Kent County Public Library in Maryland and Marshall Public Library in Missouri.

FUD: All libraries in an Evergreen system have to use the same policy!

Response: On the contrary, Evergreen’s permissions behavior can free your library from software-driven staff and user policies. Some libraries in Evergreen networks have elected to share similar policies in some areas. However, you will find that the policy structure in Evergreen is flexible and powerful enough to handle almost any workflow configuration you could think up.

There are two contradictory variations on this FUD: that all libraries in an Evergreen installation must share resources with one another, and that all libraries in an Evergreen installation can’t share resources with one another. Both are false. Evergreen is highly configurable; it will support a variety of needs, circumstances, and local policies.

FUD: Anyone on the same Evergreen system can edit a cataloging record!

Response: While it would be possible to configure Evergreen this way, in practice, we don’t know of any Evergreen system where “just anyone” can edit a cataloging record.

FUD: Evergreen is only for very large installations!

Response: If you remove the word “only,” this FUD is true. Evergreen was designed from the ground up to support the 270-plus libraries in the PINES network, so it can and does support large installations with millions of records, requirements for high indexing loads, deduping, high transactions, and so forth.

However, Evergreen scales down quite nicely. One Evergreen user installed Evergreen for his home library, and several known Evergreen installations (including Marshall and Kent), are if not tiny, certainly qualify as on the smaller side.

FUD: You can’t place holds on items in Evergreen!

Response: This FUD falls into the general category of “you can’t do X in Evergreen.” That list of FUD could go on forever. Of course you can place holds in Evergreen, unless your system has elected not to enable this functionality.

Last week, I placed a hold in PINES (after choosing a pickup location convenient to me), got a nice email notice in response (three cheers for email! I could have selected telephone notification, but prefer a notice I don’t have to write down in my illegible handwriting), and picked up my book two days later. Not that I ever doubted it… but like many Evergreen advocates, I dogfood whenever possible.

If you aren’t sure about a capability of Evergreen, turn to its community and ask — or even post a question or comment here — and you’ll get a fast response.

(Thanks to Flickr user ckelty for the great FUD image.)

Bookmark to:

Next week I’m going to close out the FUDBuster series — for now, anyway — with the FUDdiest FUD we’ve heard about Evergreen (you can’t place holds, anyone can edit a cataloging record, it’s only for very large installations, etc.). I want to move on to a new series based on Evergreen’s functionalities.

But today’s FUDBuster is a little different: not all FUD is FUD.

This isn’t going to turn into a weepy expiation of everything wrong with Evergreen or OSS. If you know of a perfect software program or design model, please do tell.

Evergreen has its strengths and its growing edges, just like anything else. This blog tends to focus on its strengths — some related to the nature of OSS, some due to its architecture, some due to the people involved in its development — and who can blame us? Creating and growing a product such as Evergreen is quite an achievement for all concerned — GPLS, PINES, the original developers, and everyone else who has since become involved.

I even like alphabetical order

But sometimes stereotypes do often hit uncomfortably close to home. (For example, I own many pairs of sensible shoes, and I also have cats. Livin’ the Library Life!) One stereotype that’s true more often than I’d like to admit is that OSS is poorly documented.

Last week I waged major battle with a piece of OSS (not library-related). The documentation was…and this is charitable…sparse and haphazard. I really wanted to work with this product for a variety of reasons — I could even buy commercial support for it at a very decent price — but the lack of documentation was one of several nails in this product’s coffin, at least for now.

Sometimes documentation is more important than other times. I confess I didn’t look at the Evergreen public catalog documentation until I decided to research all the capabilities of bookbags. I didn’t need to. I’ve been able to search, browse, find, and hold items without asking how to do this, and not, I believe, due to my magical librarian skills, but because the Evergreen catalog is easy to use.

But we do need more documentation for some of our services — reporting comes to mind — and moving forward, we know we also need to ensure we always incorporate documentation into the development process. Plus documentation should also help surface functions that might not be obvious; I intuited more about bookbags that was actually documented — such as the ability to subscribe by RSS — but not everyone might recognize that orange RSS icon. I’ll be writing about holds soon, to illuminate some of their hidden power.

In the end, documentation doesn’t write itself any more than laundry washes itself, and though it’s unsexy and a bit of a slog to produce (also not unlike laundry), it needs to be done.

Prepare Ye the Way

Fortunately, we’re able to address documentation this summer and fall through a grant from the Mellon Foundation that’s specifically targeted at documentation in Evergreen. We’re not putting documentation on our “round tuit” list to be gotten to eventually; we’re not waiting for it to grow on trees, or to float by our river on a lilypad. We’re getting ‘er done, we are, with real resources dedicated to this effort — and then, as is required by all good documentation, we’ll shampoo, rinse, and repeat indefinitely, and integrate documentation into the development process. It won’t happen any other way.

I will say that it’s easier to add documentation to good software than to add good software to documentation. But — not without some lessons-learned — we recognize the two go hand in hand!

– Karen, Equinox Community Librarian

Bookmark to:

Garage, basement, or bedroom, this FUD flows along the same path: open source software is written by some lone hobbyist in a torn Duran-Duran teeshirt, swilling Dr. Pepper into the wee hours while the weak light of a computer monitor reflects off his (it’s always a “he” in these scenarios) pallid forehead.

In other words, this FUD hints that OSS is amateurish, and any OSS program is one car wreck (or law school scholarship) away from losing its developer base — what I call GIAG (Guy in a Garage) software.

This FUD hits decision-makers right square in the neocortex with a visceral approach to what administrators fear most: making a highly visible, spectacularly bad decision. Who would want to explain to staff, the public, board members, and local government (or the library press, for that matter) that they had selected kiddy software for their most mission-critical applications?

As with most FUD, this one takes the truth and flips it jelly-side down. As library technologist Ed Corrado observed on his eponymous blog, “Someone must have a big basement to fit IBM or Sun Microsystems in it!” Many big companies (including legacy library software companies) rely on OSS to some degree, if they are not major OSS powerhouses such as Red Hat. If OSS development is happening in these companies, it’s going on in the same cubicles and offices as the rest of the development.

Enterprise-quality open source software — with its large developer communities, high security, and rapid application development, among other native characteristics — is so commercially viable that even Gartner, the squarest of business analysts, has given a cautious tip of the derby to OSS. A recent Gartner report observes that “The perspective of the open-source software model as an IT counter-culture movement is quickly becoming outdated as more markets increasingly incorporate open source into mainstream IT solutions.” Gartner also estimates that “At least 70% of commercial software packages will include some elements of open-source technology by 2012.”

Another strength of open source that this FUD tries to hide is that there is almost no limit to the number of skilled developers who can participate in its coding that large developer communities grow around good open source software. A recent version of Linux had over 3,500 developers contribute code.

I keep saying I’d like to see a developer in every library. That’s a vision, maybe one we will never achieve. But there is no challenge in library automation we couldn’t solve if we had a brain trust that size. One of the “happenings” for Evergreen is that for over a year we’ve had significant code participation from outside the original “core four.”

Meanwhile, out in LibraryLand, though we have very few developers –for an “information” profession, at least — we are seeing a flowering of creative effort. I wrote about some of the current crop of projects in an article just published in School Library Journal.

It ain’t just developers (in garages or elsewhere)!

Not that we all don’t have lots of affection for library software developers and the important work they do, but it stands repeating that any healthy OSS “community” is really a series of affinity groups much broader than its developers.

Contributions to OSS come in all shapes and sizes: users who contribute their domain knowledge to system design, documentation writers, trainers, educators, and so forth — or even just the “many eyes” that can observe and comment on the development process. Someone like Dan Scott of Laurentian, with his excellent knowledge of acquisitions processes, is indispensable to the work of lead Evergreen acquisitions developer Bill Erickson. (Sometimes the contribution is financial, and there’s nothing wrong with that, either.)

So what’s wrong with Dr. Pepper?

One tiny grain of truth in this FUD has to do with the nature of creativity. I think it was Roy Tennant who once observed that nothing was ever invented by a committee.

At the earliest stages of the creative process, there often is just one person with an idea. What happens next is partly a question of luck and timing (which is often a form of luck). But it is also a question of temperament and skill.

I’m no big fan of The Cathedral and the Bazaar — I find it windy and very much “insider baseball,” among other problems — but Eric Raymond does do a good job of talking up the human aspect of OSS development. He points out that all new software programs begin with a developer — but great OSS projects happen because the original developers had the human skills to build community around their ideas.

In any event, the next time you hear this FUD, think about what you really know about the software under discussion. Because I’m sitting three feet from a rosy-cheeked library software developer, in a nice ground-level office with a birdfeeder outside the window.

Bookmark to:

Most library workers in Evergreen libraries will never see a line of code, will never need to get down-and-dirty with the software, and will experience support as a phone call or email — the way it’s spozed to be. But that runs counter to this week’s Fear, Uncertainty and Doubt FUDBuster: the idea that to use open source software such as Evergreen, you need to maintain it yourself.

The easy answer to this FUD is that there are a number of commercial enterprises (like, you know, Equinox) dedicated to OSS. In LibraryLand alone, there are at least five companies (presumably all financially viable, since fish gotta swim, birds gotta fly, and we gotta eat) dedicated to open source software support, development, migration, hosting, and other services.

Outside of LibraryLand, some famous examples of commercial OSS companies include Red Hat (for Linux) and Acquia (for Drupal).

Of course, you don’t need to contract with commercial support companies to use open source software. If you can maintain Evergreen on your own, more power to you (and we hope you share your experience with others).

Then there is the coterie of LibraryLand consultants who provide OSS-related services on an as-needed basis — helping libraries write requirements, select products, etc. I bet you a low-fat-decaf-grande-vanilla-latte there will be more and not fewer of these folks as time goes on.

OSS can mean better support

Like most FUD, the whisper campaign that using open source software equals walking a tightrope without a net distracts you from a more obvious, and sadder, fact about the state of much proprietary library software, which is that many libraries spend vast buckets of time and labor trying to support it.

When a library organization gets beyond a certain size, it usually establishes support services for its member libraries or branches. These support services may help their users with a variety of issues, but coming from a number of organizations that had contracted for “turnkey” [sic] library software solutions,

I know that the bulk of support — and quite often, development efforts — is often directed toward issues related to library software.

It’s much more difficult to negotiate support issues with proprietary software. You’re flying blindfolded, relying on the company to identify problems in its software and resolve them for you. You’re also not sharing these issues in a broad community, the way open source development happens.
Some big organizations have as many as a half-dozen developers on hand dedicated to what are essentially workarounds for their “turnkey” software.

If you do have your own developers, and if the company deigns to allow you to peek at the code, you can’t reach out to a truly broad community and ask how to solve the problems. At best you can communicate with other organizations, all in accordance with confidential agreements. Enter the world of confidential agreements, NDAs, passcoded blogs and wikis… all designed to hide development issues related to software.

The companies tell us they have to hide their candy because this software is so special. I will agree… just all too often, not special in a good way.

Some of these companies now opening their doors a tiny bit act as if they are doing you a huge favor to let you see and modify the code you licensed for use in your library. Doesn’t that strike you as unlibrary-ish?

In any event, all of this secrecy and proprietary code leads to poor product support. If you want to see a library truly “going it alone,” visit some poor library stuck trying to figure their way through a problem with their library software when the product help-desk won’t or can’t support them. It will become obvious why this FUD keeps popping up.

Bookmark to:

If FUDBuster #1 is completely over-the-top, FUDBuster #2–open source software isn’t ready for prime time–is subtler and more pervasive. I’ve heard this phrase so often—”open source software isn’t ready for prime time”–and with so little justification, that it reminds me a little of those moments on the Daily Show when Jon Stewart presents clips from cable news shows in which newscasters are obviously parroting the same press release.

The ace card for Fear, Uncertainty, and Doubt is that it distracts us from facts and data and even from some obvious contradictions through the seduction of the emotional appeal. A whisper campaign can make someone start thinking, “Oh my goodness, if I select open source software, I’m going to look bad”–even though the FUD itself is nonsensical.

First of all, what does it mean for software to not be “ready for prime time?” If it means short on features and functionality, that’s a gross generalization about OSS that could be as true, or untrue, of any software. In fact, the great, long-lived OSS programs such as Apache and Linux are not only ready for prime time but run circles around their competition in terms of features, functionality, and strength.

FUD is intentionally diversionary, so it’s not surprising that this bit of FUD obscures some other facts. Evergreen was invented because no existing product could meet the needs of PINES, the sharing network of over 270 libraries provided by the Georgia Public Library Service. Most of the library automation software on the market at the time was hampered not by its lack of maturity but by its age. Products that were marginally innovative twenty years ago had become legacy software, as useful to the modern library as my old copy of WordStar would be to me today.

Legacy software is often burdened by legacy code, legacy languages, and even–as a librarian of a certain age, it pains me to say this, but I must–legacy developers. This is in its own slant way an OSS issue as well.

Newer library software such as Evergreen, Libraryfind, and Vufind often include features and capabilities older software isn’t capable of, and are written in languages and architectures that weren’t available when Katherine Hepburn was out-performing a computer in Desk Set.

Furthermore, in the commercial world, particularly in the world of library software development, where revenue margins can be vanishingly slender, there is less financial incentive or even ability to rewrite software from the ground up… and in fact, attempts to do so have become the Hindenburg disaster for some companies. Some of the more spectacular vendor-abandonment scenarios are at least partly due to a chronic lack of R&D (research and development) funding in a market that is both highly specific and chronically underfunded. We’re gorgeous, but we’re poor.

Meanwhile, after spending some time observing library software developers in the wild–how quaint their customs and native costumes!–one conclusion I make is that they are inherently flexible and adaptive, and their actions typically flow along paths to the best software and most appropriate architectures. Their stakes are too high to be otherwise. The better projects are able to marshal other developers to get on board and provide incentives to maintain their activity, and because it is open source development–where by definition, development happens in the open–there is no limit to the number of people who could theoretically participate in a project. Linux had over 3,500 developers participate in its latest version. We can do that in LibraryLand–we really can.

(This gets back to something else I will later discuss: why we need more developers in LibraryLand–my “boots on the ground” argument–and why we should liberate those library-based developers now chained to painfully dysfunctional legacy software so they can help build the systems of our future.)

Finally, the writer/journalist in me asks this of you. When someone says, “Open source software isn’t ready for prime time!” start poking–hard. Ask this person what he or she means by that. Is this in reference to a particular product? To a missing feature or functionality? To something someone said? Or is the not-ready-for-prime-timer even able to clarify what he or she means?

No software is perfect, and the best software is mutable and adaptive. Also, some software may not have the features you want now–though if you look closely, those features may be emerging. And some software is bad software. But “not ready for prime time” is that sort of FUDdy word-pudding we need to excise from our vocabulary if we are to be the judicious decisionmakers LibraryLand needs.

The open source software model serves our community well in many ways, not the least of which is that individually we may not be able to afford caviar, but if enough libraries bring developers to the potluck, all of us may dine quite well indeed. Beware the FUD that claims we cannot produce the software we need to run our libraries. There’s only one reason for that FUD: because increasingly, we know we can.

Bookmark to:

FUD stands for “Fear, Uncertainty, and Doubt.” Wikipedia defines FUD as “a strategic attempt to influence public perception by disseminating negative (and vague) information.” If you remember Donald Segretti, during the Watergate scandal, FUD was his core competency.

I’m launching this Monday FUDBuster series with my very favorite FUD about open source software.

A few months back, a friend direct-messaged me through Twitter. “So-and-so just spoke to our library and said open source is only good for third-world countries.” I could feel my friend’s eyes rolling.

This FUD is so wonderfully wrong on all accounts, but I enjoy it because in my two years in the Southeast, I’ve learned that there is some rivalry among Southern states. So my Floridian friends like this story because Equinox is based in that well-known “third-world country,” Georgia. I tell them when I head to Norcross I bring my passport and bottled water.

This also hits all the high marks of excellent FUD. It’s negative and vague, and not only that, it’s hilariously xenophobic. Can you imagine a marketing campaign based on the jingoistic notion that developing nations don’t deserve excellent software?

Parsing this FUD

What this FUD attempts to do is lump all open software together and present it as the software of last resort.

But first of all, not all open source software is created equal. OSS isn’t a panacea in itself, and each product needs to be evaluated with the same rigor we would evaluate any product.

Second, good open source software is often the software of first resort. The story of Evergreen is about a massive lending network that couldn’t find the software it wanted, and knew the old model — proprietary software built several removes from its users, with revenue based on licensing fees — was at least for their needs, fundamentally broken. No vendor or product, proprietary or OSS, could meet the needs of PINES, and some were quite clear they had no interest in trying.

So back to the library they went, and now the Evergreen community is building the software we want, scaled and tuned to our needs — regardless of the geopolitical status of the countries we live in. There are many more advantages to OSS — but that’s part of another series debuting this week.
(You can see this FUD really pushes my buttons! In 2006 I was privileged to speak to the special library association of South Africa, and among other things, I learned a lot on that trip about creative use of cellular telephony; a country that never really had POTS has found a million ways to use cell phones. Plus I’ve lived worldwide, and we’re all the same everywhere — we just accessorize differently.)

Meanwhile, I’m taking a side trip to Tifton’s library en route to the office, so I better run — I need to make sure my passport is handy and my shots are up to date!

– Karen, Equinox Community Librarian

Bookmark to: