Archive for the ‘Thinking about Evergreen’ Category

What we talk about when we talk about the ILS Marketplace

Wednesday, June 17th, 2009

Yesterday I sat through a webinar on the integrated library system marketplace produced by Library Journal and Polaris Software. It wasn’t awful, but like a lot of missed opportunities in LibraryLand, it also wasn’t great.

The first half of the webinar was largely consumed by a discussion of one library’s migration to Polaris, a company which, as this handout makes clear, is not too receptive to open source at the moment — which is flattering, in a way, as well as an interesting bit of market intelligence.

Then there was a discussion of Colorado’s exploration of a statewide ILS, and finally, in this webinar that was about “[the] many factors to be considered with respect to both commercial and open source solutions,” the last speaker mentioned one OSS product his library had considered and then added, “We’re basically a Windows shop.”

This is not to harp on Polaris — a company that by most reports is not one of the vendors who (in the words of a vendor friend who shall remain nameless) “peed in the pool” for all the other proprietary-software vendors.

Nor is it to suggest that the speakers did anything else than what I would have done. Honestly, if a library magazine gave me the chance to invite an Equinox customer to open a broad talk about the ILS marketplace with a discussion of a single successful Evergreen implementation, I’d be on that like white on rice.

Also, the webinar did raise some good points. Migrations are hard. (They’re even harder when vendors refuse to let you extract your data, or charge you for it… a point overlooked by the speakers.) Jim Duncan from Colorado State Library also noted that systems should use open APIs,  be flexible, and be open to innovation; that they must be customizable and scalable; and be able to have strong features and handle a high service load. Plus vendors must use standards, and not just their own flavor of a standard.

(To me that sounds like Evergreen… and the principles of open source… but I digress.)

But there are some lingering questions here.

Is this how we want to have discussions about the most central toolsets for our library services: by anecdote and “How I picked my ILS good” testimonials?

Also, we all have a dog in some fight, somewhere — but where do we define the boundaries in the inevitable (and frequently valuable) partnerships that crop up in any profession?

In bits and pieces, the Polaris-Library Journal relationship seems harmless; nobody ever got kicked off a Gale shuttle bus at an ALA conference for buying ProQuest or Ebsco. But then, though there is an exchange taking place — a charter bus, some heightened awareness of a vendor — Gale employees don’t hop on the shuttle bus to tell us why we should buy their product.

Having just helped put on a user conference, I know that vendor relationships are invaluable. But should the boundaries be the same for the press as for the rest of us, or should they hold themselves to an even higher standard?

Posted in Evergreen, FUDbusters, Thinking about Evergreen | 1 Comment »

Consortial Library Systems

Monday, May 19th, 2008

A previous post dealt with the architecture of Evergreen and summarized its uniquely modern design. This design allows Evergreen to provide individual libraries with an ILS and also large resource sharing consortia. It can function, then, both as a traditional integrated library system (ILS) but also as what we will call a Consortial Library System (CLS). It can be argued that resource sharing consortia are the current state of the art and that in time—and wherever practical—systems will provide such consortial capabilities. Evergreen, then, is just the first such CLS and the next step in the evolution of automating an everything-everywhere national library system.

The term “consortium” is used in the library world to mean many types of things. Here we are referring to a “resource sharing” consortium. Even “resource sharing” however, is also used in several ways. We mean a consortium that is designed to share resources between administratively separate systems. Interlibrary loan can be seen as an early attempt to share resources between separate systems but this method was bound by its cumbersome nature. A CLS changes that because ILL becomes, basically, a type of circulation in a larger but still closed system. In order for these separate systems to share resources with a modern computer environment, there are necessary conditions.

For large systems, one needs a CLS and it is our belief that these systems, once their benefits are understood, will grow first to state networks, and then beyond.

What is a CLS?
A CLS is a software application, or set of related applications, that provides background computer resources for these resource sharing consortia. This type of consortium is one that unites libraries and their users, breaks down information silos, and provides enhanced access to the consortium’s resources for members of the consortium.

When the acquisitions and serials modules are added, Evergreen will also provide consortial ordering and serials control. These capabilities will increase the value of the discovery aspect of the CLS while adding features found in buying consortia.

What should a CLS do?
First, and most importantly, it provides an online union catalog for all items in the consortium. This catalog should be organized to provide users a means to discover the consortium’s resources. Therefore, the catalog should be deduped and items grouped by format, among other characteristics.

Second, the CLS provides a means for the resources to be shared. The PINES experience makes it clear that this aspect of the CLS is highly valued by a consortium’s users. And as a result, at a certain point, the system seems to have begun to generate its own pressure to grow.

Conditions for a CLS
Large consortia will require the ability to handle large databases. This has proven to be the easiest problem for ILSs to solve and although necessary, it is not sufficient for a CLS.

Deduping should be as automated as possible as should grouping of items returned on a search. Deduping still requires human editing, of course, but good programming practice can go a long way to suggesting like titles. Grouping of items by format or subject should be handled via database functions using the catalog records. That way, the results can be improved and updated with better search algorithms. Given the size of these consortium, as much of deduping and grouping like entries should be automated as possible through backend database functions. Consortia grouped by manual processes just don’t scale to union catalogs with millions of records. And a CLS must scale to larger than anything running now.

CLSs will require the ability to handle a large number of transactions. These transactions are circulations, cataloging changes with materials being added and withdrawn, searches, and so on. To handle these transactions, the database must be able to handle rapid, real-time updates. This capability has proven to be difficult to solve in the industry. There are a number of systems that can handle many transactions but the problem is that the other ILSs that handle many transactions can’t update their underlying databases fast enough. They pay the price of their old architecture.

Related matters
Migration into the CLS will necessarily involve migration from a variety of ILSs each with different data structures, configurations, and options. Migration, then, involves a number of tasks, not just bringing in the bibliographic data from the various libraries, deduping the records, and making them available for users. The backend database processing is key, as are the politics.

The political agreements, as Chris Jowaisis has pointed out, are a key to the success of PINES and Evergreen. For this reason, Equinox is developing FullfILLment ™ to do most CLS functions when the politics is not solved in a consortium.

Non-Standards
As a result of combining records from so many libraries, the variant cataloging practices of the various consortia’s member libraries becomes a serious a problem. These varying practices are, of course, old wine in a new digital bottle but their effect is to make the resulting union catalog harder to use and to result in inaccurate search returns. F, Fic, Fiction as shelving/cataloging are well-known but when a search result on a large consortium has these kinds of designations and also those were the same title may appear in more than one Dewey number, you have the makings of a problem that has far-ranging effects throughout the CLS. We have been giving this lack of standard practice thought and have some notions about how to work around it that we will report on in time.

Bob Molyneux
Mike Rylander

Posted in Thinking about Evergreen | 1 Comment »

Generations

Monday, April 21st, 2008

ILSs have evolved over time. What started as as a way to manage the printing of catalog cards (1950s and 1960s) eventually morphed into a system for tracking inventory, and then finally into a full-lifecycle management system for general library operations. None of this is news, of course.

What is news is that Evergreen is the first and only ILS to go into production that does not suffer from decisions made 20, 30 or even 40 years ago. Too often I see quotes from respected luminaries in the library world suggesting that Evergreen is simply duplicating what has been done for the last 30 years of ILS design. That means two things, actually:

  1. We’ve done a very good job of creating an interface to the Evergreen ILS that feels like what librarians are used to using. This means a shorter training cycle for front-line staff, greater ROI and lower TCO.
  2. We may have done too good of a job creating an interface that makes librarians comfortable with traditional ILSs feel comfortable with Evergreen, and haven’t explained well enough just how the core Evergreen is designed and shown just how easy it is to expand services in ways no one has yet considered in terms of an ILS

Looking Back

What we now call the ILS, a product purchased from and maintained by vendors, first emerged in the late 1970s and early 1980s. This is, for all intents and purposes, where history begins.

Over the last thirty years we’ve seen, more or less, three architectural generations of ILS arise from the original proto-ILS. Each generation learns from the lessons of those that came before, as well as from the wider world of software engineering. At each stage there are specific changes in architecture which provide obvious differentiating features that are wholly new so far as the ILS is concerned, but there are also concepts and constructs carried over from previous generations. In addition, there are non-architectural design components that are typical of each stage of evolution, and while the basic architecture of systems at each evolutionary stage may not be directly relevant, there is an identifiable correlation between the overall architecture and these higher-level design decisions.

The Client-Server Age

In the beginning (the late 1970s to mid 1980s) there was the monolithic client-server system, and it was good. Mostly it was good because there was nothing else, and something was needed. These systems were designed to run on the computers of the day; that is, large (for their time) central computers with dumb terminals, or later, thin clients on PCs, for data entry and output. They were (and are, it’s amazing how some of these systems persist) consolidated 2-tier systems that contained all of the logic in a single program on the server.

The back-end storage systems, and in many cases the display engine, were integrated directly into the main program, and required that this one program run on one server. The only way to scale such a system is to purchase a larger server. It is far from impossible to outgrow the largest servers on the market, even today, unless an institution is willing to dedicate a very large portion of their budget to such a system.

Another design constraint of theses systems, though not related to their client-server architecture but still endemic to the age, is that they were never meant to run the operations of more than one organizational entity. There is little or no consideration for location independence. If a staff member has a permission, they have that permission everywhere within the system. In other words, there is no concept of location-specific privilege separation.

Case in point: PINES is the state-wide consortium in Georgia at which Evergreen was initially developed. Although functionality was lacking in their existing solution, an equally concerning problem was the performance of the server during normal business hours. The 48 processor E10K they were running on was straining under the load of a state-wide consortium, and regular maintenance jobs that would not be a problem for smaller scale installations were requiring a mid-day restart of an essential, core service, and a nightly restart of all services. To upgrade out of the red zone would have meant investment in a 2 million dollar E20k, or larger. The PINES budget for one year is around 1.5 million dollars. Putting aside the cost and scaling factors in running such a system, there was no way for PINES to separate privileges based on which library or library system a staff member worked in. Among other things, this meant that PINES could not implement centralized Acquisitions.

The Web Application Age

Then in the late 1990s, scurrying around the feet of the lumbering, antiquated 1- and 2-tier client-server dinosaurs, there evolved the 3-tier web application. These systems are characterized by a nod towards database independence, the use of non-library standards for core functionality, and interface rendering handled by a generic third-party application such as a web browser. Such systems can be made to scale horizontally — that is, the full spectrum of functional areas can be scaled up — by adding more web servers in a dumb cluster, but because all of the web servers must run all the business logic for the ILS, as well as generate web pages for display, this scaling is not linear — one sees less usable per-server capacity added with each new server in the cluster. A related scaling problem is that there is no opportunity for balancing base-line resource utilization against the specific needs of the installation — in a low-circulation, high-search environment the server still has to load and run all of the heavy circulation logic with each instance of the search logic, sapping memory and CPU resources that could be used elsewhere.

These systems also carried over the lack of location-aware privilege separation from the earlier generations. While adding new services to such systems is somewhat simpler than in a client-server architecture, they are still basically a monolithic code-base built to run the operations of a single organization. They are also targeted at smaller library systems lacking the need for some of the more sophisticated business processes of larger institutions. As such, scaling is not a primary concern — and rightly so, with their small-system focus — and is not addressed directly but comes as a side-effect of the architecture, to the level that such scaling exists.

The SOA/Distributed/Dis-integrated Age

In the mid-2000s we see the rise of REST and SOA. New software systems in most industries are being modeled on distributed and modular architectures that allow the dis-integration of services and interfaces. ILSs designed and developed in this time period have the specific characteristic of incorporating concepts of SOA and distributed computing from the ground up. Each functional unit of the ILS is implemented as a service with a well-defined API, and these services can be replaced or augmented over time without the fear of disrupting the rest of the code-base. New services snap in like Legos and are trivial to implement in comparison to new services in previous generations, and service APIs stay consistent across time and even development and implementation methodology. Because ILSs built this way have intentional separation between all service layers (UI, business logic, storage) they can present many different workflow-optimized interfaces to the user, or to other services, while leveraging existing code.

Because of the focus on service dis-integration, resources can be applied precisely where they are most needed, and horizontal scaling is linear in the worst case. Scaling in this architecture is managed through the addition of simple, replaceable commodity hardware, making it extremely cost effective for initial capital outlay and providing the possibility of “just in time” cluster expansion using hardware that delivers the most bang for the buck at the time of need.

Greener pastures

Evergreen is the first production ILS, and only we are aware of as of this writing, to be designed with Service Oriented Architecture (SOA), Representational State Transfer (REST) and “n-tier” architectural concepts specifically in mind. Evergreen achieves this by building services and applications on the OpenSRF (Open Service Request Framework, and pronounced “open surf”) platform. OpenSRF handles all of the details of implementing a stateful, decentralized service architecture and the Evergreen code supplies the business logic and UI framework that matters to libraries.

To provide a specific example of the ease of extension that Evergreen and OpenSRF provide, the online bill pay functionality coming in the next major release was designed and developed by someone that had only passing familiarity with the underlying of Evergreen, or with the OpenSRF framework on which it is built. It was created in about 4 hours, and adds integrated, ILS-wide support for credit card and PayPal payment processing.

Another mistake I hear repeated all too often is the fallacy that Evergreen requires uniform policy definition across participating institutions. This could not be further from the truth — Evergreen supports the most flexible and location aware circulation and hold policies of any ILS available, and can even be extended with ad hoc exceptions to any policy definition via simple rules. This is, of course, unrelated to the architecture of Evergreen, but as it is the only example of a system based on such an architecture, this feature is also endemic to this pattern.

But wait, there’s more!

Another natural consequence of the SOA/dis-integrated architecture of Evergreen, facilitated by OpenSRF, is that most if not all of its code can be re-purposed largely without modification. We at Equinox Software are currently beginning development on FulfILLment, a large-scale, cross-ILS borrowing platform to facilitate the functionality of large ILL consortia, such as state or region-wide networks. This system will leverage much of the organization-aware business logic that Evergreen already provides to support cross-institution circulation in a completely ILS agnostic fashion.

The Future

While neither I nor anyone else can predict what the Next Big Thing will be in terms of application architecture, we can draw some clues from the current state of the art. Bleeding edge application development in 2008 seems to be moving towards refining the SOA model. Efforts such as SOA 2.0 and Service Component Architecture (SCA) point toward a near-term future where SOA and dis-integrated services become mainstream, and service-on-demand and mashups are the norm. If these trends are any predictor, Evergreen and OpenSRF are in for a long ride, especially as more features and functionality are incorporated over time.

Note: Updated 2008-04-22T10:00:00-04 to add some term clarification.

Posted in Evergreen, FulfILLment, Thinking about Evergreen | No Comments »

Mellon Award and Sir Tim Berners-Lee

Sunday, December 16th, 2007

As was reported on the Evergreen community blog and in a GPLS press release, Evergreen was recently recognized by the Mellon Foundation. Sir Tim Berners-Lee was the award presenter, and I got a moment to meet him and have a picture taken.

Brad and Sir Tim Berners-Lee

Posted in Announcements, Thinking about Evergreen | No Comments »

where’s the enhancement list?

Tuesday, October 23rd, 2007

This is what you may be used to with vendor-owned proprietary products:

1) A user group, in a private forum controlled by the vendor, periodically collects enhancement requests
2) Domain experts sift through the requests and put together a list for the membership to vote on
3) Members vote on the list and send the results to the vendor
4) The vendor decides which requests they want to implement, if any, with money gained from their annual fees, etc.

Equinox doesn’t work like that. Nor does Evergreen.

If an Evergreen-powered library needs a feature then they need the feature, and they can determine their needs in whatever manner works best for them. Internally, they may very well do something similar to the process above. But once they have determined their needs, then they have some options:

Option 1) Sweet talk the developers. Seriously. Open source development is a social phenomenon. With Evergreen, the developers aren’t hidden down in the bowels of some corporation, we’re right there in public view. We all volunteer our time to the community whether we’re directly paid to work on Evergreen or not.

Open source development communities are gift cultures that operate on merit, respect, and ego. If you pose a problem on the public mailing list, folks within the community are going to try to model a solution, if not actually implement one, just for the challenge of it and for any kudos they might get from their peers. We measure our worth in what we can give to others.

Tell us that another ILS does something better, and we’ll want to compete, and not only match the feature but do it better (and doing it better may mean integrating with another open source project that has already licked a specific problem domain, like how we’re using OFBiz for acquisitions).

Also, by participating thus in the community, you become a part of the solution. Your time and domain knowledge are valuable assets, and if you help us work through a problem in public, the problem gets exposed to a wider variety of eyeballs that can provide fresh perspectives and help rub off any rough edges on the software.

PROS: For some things, you can get changes made within hours, without jumping through hoops and going through a lot of red tape.

CONS: You have to be nice. :) You can’t really make demands in such a forum, and with volunteer development certain features might not get built on your timetable.

Option 2) Do it yourself. This need not be as daunting as it might sound. If you already have developers, perhaps among your IT staff, then they can grab a copy of the source code and/or a VMWARE image and start poking the code, asking questions on the public mailing lists, and learning Evergreen right away. It might take a few months to half a year to really start groking how all the pieces fit together, but the return on investment is high and there are no secret API’s or certifications with price tags attached. If you can’t afford a software developer, just providing what help you can (domain knowledge, etc.) to interested and like-minded community members, even if only a few hours a week, can work magic. The best way to find such community members is to ask on the mailing lists.

Now, on the subject of modifying source code, I want to take a moment to dispel a myth. Yes, the software is open source. That means you are allowed to copy it, make changes, and distribute those changes. But no one is obligated to actually add your changes to their copy of the software. Joe Random Developer can’t come along and trash Evergreen with sloppy code to the detriment of everyone else.

This is another reason why community participation is important. By working within the community, your changes get vetted by and hopefully adopted by the community. The community will help you make your changes work within the community, so as to not degrade the project.

The copy of Evergreen residing in a source repository at Open-ILS.org is what our community currently thinks of as the definitive canonical version of Evergreen, the home of Evergreen, but this is only by convention and social inertia. That repository is “governed” by a small group of core developers, currently the original developers who built Evergreen, plus one other, Dan Scott, the Systems Librarian for Laurentian University in Canada. There are other developers that submit “patches” to the community. Those patches get looked at and vetted by all interested developers. If things look good, the core developers apply the patches. If later testing finds a regression, those patches can be rolled back and re-worked. This is how quality control is maintained for the Open-ILS.org version of Evergreen. If a developer earns the trust and respect of the core group, they may be invited to join that group. This may sound elitist, but that’s okay, because open source culture makes this a meritocracy and not despotism. Developers are individuals, not companies; money doesn’t have a say in this. Also, if the governance of Evergreen ever begins to fail the community, the open source license used allows the community to fork the project. Basically, a new leadership can step forward, gain followers, and go off in their own direction with a copy of the software.

Now, to some folks a fork is a scary thing, and some open source traditions treat it as something to be avoided except under dire circumstances, because it can be a waste of resources and lead to duplication of effort. But as a threat, it’s actually useful, because it pushes folks to compromise and work out differences, and it tends to keep the leadership humble. A fork is bad when it divides a community and there are hard feelings. A fork can be useful if the divergent communities are still willing to collaborate and cross-pollinate, and when that happens, folks tend to not think of it as a fork at all. Even if effort is duplicated, one of the forks may actually prove to be superior, and will win mindshare on merit. For an example of a fork in the open source world, see the histories for X.org and XFree86. For more, look at the BSD’s.

This was a long tangent, but it does show how “Do it yourself” can actually work with open source software, if you do it within a community. Notice how it doesn’t work when you try it with a proprietary product. Because you’re not a part of a proprietary vendor’s internal development microcosm, you risk having your work rendered useless at every upgrade, unless you’re lucky enough for them to take your ideas, if not your implementations, and sell them back to you. An open API or database schema isn’t enough if you can’t join their development community as a peer, or if you can’t fork the software.

PROS: This is the ultimate way to control your own destiny. Software is information, and librarians are information architects. Open source is sharing, and so are libraries.

CONS: You may not be able to convince the powers that control your purse strings to let you do this, even if it might prove cheaper than going with a vendor.

Option 3) Go with a vendor. **cough**Equinox**cough** Or a consultant or developer already versed in Evergreen. What you’re paying for here is a developer’s time, expertise, and ability to get work done while staying in harmony with the community. You’re basically funding community development, but with concrete targets and deliverables that meet your needs, instead of paying some vague software tax or annual fee that grants you pseudo-voting rights on enhancement lists.

PROS: You’re still investing in software that can never be taken away from you, and this is a more traditional solution that might appeal to the powers that hold your purse strings.

CONS: We can’t think of any, but we might be biased here. :)
Wrapping this up…

From these options, I hope you’ve seen the real way progress gets made in open source. It’s through community. A mixed community of volunteers and paid workers, software developers, testers, documenters, users, domain experts, researchers, advocates, critics, fans, and other interested parties. Every little bit helps, and as the community grows, those bits add up faster and faster.

Thanks folks!

– Jason

Posted in Thinking about Evergreen | 2 Comments »

Thoughts on Evergreen’s Birthday

Thursday, September 6th, 2007

I started working at the Georgia Public Library Service on September 4th, 2001, a day seared into my memory. My title was “PINES System Administrator”, and on my first day at work, our proprietary ILS exploded, and we had to restore from backups. Yes, it was a memorable first day.

Note that at that point in time, I didn’t even know where the ILS server was even physically located, nor did I even have an account on the box. I was scheduled to go to training the following week to learn how the software worked and how to administer it. All I knew was this software, named after a mythical animal, wasn’t doing the job it was being asked to do, and there wasn’t a whole lot I could do about it except answer a couple hundred emails, apologizing for the service not being available.

At that point, I made it my mission to learn as much as I could about this ILS software that my job and livelihood depended on. It was a rough honeymoon period, and boy, did I have many opportunities, after problem after problem arose. I was also amazed at how much my employer was paying, and what they were getting in return, especially from technical support and the overall quality of the software.

I can rattle off enough stories to keep you occupied around a campfire until all of the marshmallows are gone. The time when a support person logged into our production system, without my knowledge, and restarted the system in the middle of the afternoon. Or about the time when a support person logged in and tried to backup data that was occupying 75% of the disk space onto that same partition and crashed the software. Or about the time when a support person deleted a ton of open bills. I can go on and on.

This was no way to live. Not only was the software itself failing us, the vendor’s support was as well. We could either sit around and point fingers, or we could do something about it. We decided to do something about it.

The idea of Evergreen was born, and as the saying goes, the rest is history. The idea that a public library can directly develop software to fill its needs was a bit of a radical idea… at least on the scale of building an ILS. I can’t tell you how many folks shook their heads in disbelief at the idea. There were many naysayers, spouting off wisdoms. To me, there were no dragons blocking our way. Sure, there were issues to overcome, but all were surmountable. This can be done, and here’s the path. Evergreen was also lucky to have management that would go to bat and support it.

While the primary goal of Evergreen was to create a system that worked, a secondary goal was to change the ILS marketplace permanently and for the better. When the software itself is no longer a proprietary ball and chain, and multiple companies can compete and offer basically the same service around the software, chances are that service is going to get better, faster, cheaper. Of course, we would love to have your business, and we will do everything we can to earn it.

So, here we are. Happy first birthday, Evergreen.

–Brad

Posted in Thinking about Evergreen | 2 Comments »

Library Visigoths Welcome Software Freedom

Monday, March 19th, 2007

Wow. I know Equinox should be excited over the sudden and increased interest in Evergreen, but it is sad when folks are forced to move further along that long road of product cancellations. I also feel for the developers and supporters of those abandoned products. Evergreen is our baby, and it would be bad enough if it couldn’t succeed on its own merit, but it would be absolutely horrible if someone were to just deny it the chance to grow.

Fortunately, Evergreen is free of such dictatorship. Any library, organization, vendor, or individual may plant a seed (or pine cone, as the case may be), and cultivate the software however they wish. You could even hire Equinox to be your gardener, and we could never take the tree from you once you have it. No one can. The software is licensed in such a way that no one distributing it can even ask you to contract away your freedoms to use and modify and share the software. You are empowered to make it work for you.

Equinox does not sell software. We sell our time and our expertise. Support isn’t a cost center for us that we’ll sacrifice for other interests; it’s our bottom line. And the software is already yours, if you want it. We’re a young company composed of librarians and software developers. We don’t have experience abusing our customers (and we don’t want to learn). What we do have is experience writing software that works. We know how to maintain it and we know how to support it.

Many of you have joined the project’s OPEN-ILS-GENERAL and OPEN-ILS-DEV mailing lists. We’re not the only gardeners, and I invite you to speak up and ask questions of a growing community. Evergreen may be what you’re looking for.

Sincerely,
Jason Etheridge
Vice President of Community Support and Advocacy

Posted in Thinking about Evergreen | No Comments »

It’s not just about books and software

Monday, February 5th, 2007

I’ve mentioned before that the library and open source communities should be natural allies, and indeed, there is crossover and movement between the two, especially with digital initiatives and low-level tools. To recap, both communities are all about sharing knowledge and enriching their members, and with both it’s not the products that are important, but the people and the processes. Libraries and the open source movement are both about service, and ultimately, giving gifts.

It’s worth noting that despite their conservative image, libraries have always been on the forefront of creating and using innovations and advancements in technology. Punch cards, networks, desktop PC’s, CDROM’s, each advancement has been embraced by libraries, and in a lot of cases the libraries were early adopters and pushed the use of such technology for their parent organizations. Open source development is itself often thought of as an advancement in the state of the art, and indeed, the pragmatic reasons for using open source are now more often heard than the idealogical reasons. And while in a lot of areas, open source software is playing catch-up with their proprietary counterparts, in other areas they are the market and technology leaders.

Another thing that the open source and library communities have in common is their love of open standards. The MARC standard for bibliographic, authority, and holding data (and associated cataloging rules and controlled vocabulary) was a revolution in the library world; it allowed for unprecedented resource sharing. Incidentally, it also mitigates a little the problem that libraries have now of vendor lock and the high cost of migrating their data to other systems. Z39.50, SRU/SRW, OpenURL, OAI-PMH, unAPI, NCIP… all of these foster the sort of sharing and collaboration that open source is all about. For a lot of open source software, the protocols and standards are more important than the code itself.

If early library automation had developed under the same conditions that the current open source movement evolved under (where the source code was shared, instead of falling into or being created by the hands of proprietary vendors), I believe libraries and open source today would be one and the same!

I know that is a bold statement, but the two communities are so close to each other, being gift cultures in the domain of knowledge and public service, that I’m surprised that there isn’t more overlap than there is today. Of course, there are a few obstacles, some minor and some major, that throw a monkey wrench into my vision of librarians and open source contributors singing kumbaya around a campfire.

Open source advocates don’t restrict themselves to software, and like librarians, they are keenly interested in such things as copyright, fair use, and freedom of speech. I think it’s fair to say that initiatives like the Creative Commons and Project Gutenberg spring from both open source and library advocates.

But libraries have to deal with big content publishers such as the movie industry, the music industry, and private database vendors. Some of the tactics used by these entities to protect their bottom line are antithetical not only to open source, but to the common good. They push such ideas as perpetual-copyright, denying the growth of the public domain (and even causing some works to be lost forever), and digital rights management (DRM), which also hinders the growth of the public domain, as well as the public’s ability to exercise their fair use rights.

It’s also unfortunate that as content producers themselves, librarians were and are subject to having their works appropriated and sold back to them. This happened with the early automation systems, and it happens today with bibliographic data and workarounds to modern automation systems. It also boggles my mind that the Dewey Decimal System I was taught in elementary school is actually proprietary, even at a ripe old age of 130.

Now, I don’t know if I’m attacking some sacred cows here. Proprietary vendors and non-profits like OCLC have certainly done some good, and are even beginning to adapt to this whole “open” thing. Maybe someday soon you’ll even have more vendors supporting NCIP, and not playing a blame game on why their software won’t interoperate.

There’s certainly nothing wrong with having commercial interest in the library world, but going open source and open standards really changes the game.

To illustrate this, let’s talk about Evergreen.

With software like Evergreen, if your vendor of choice goes out of business or merges with another, you’re not going to be out of luck. The software is free and libre, and any vendor can support it, even the ones that are traditionally proprietary.

With software like Evergreen, you could even grow your own expertise in-house, with no contractual road blocks or impediments. You could even pay someone who has the expertise to train and mentor your in-house experts. Or you could dive into the development community and learn that way.

In truth, open source communities supported themselves just fine long before commercial support companies started bridging the gap between traditional vendor support and the hacker Do-It-Yourself mindset.

With software like Evergreen, you can be more than just an “end-user”; you can be a peer.

With proprietary software, the more people that use it, the more likely you are to become a minority customer to a single vendor, and more likely that the customer with the most money will get the most attention. But with software like Evergreen, the more people that use it, the stronger the community surrounding it grows, and it’s the community (made up of individuals, organizations, and vendors) and their respect for one another that makes open source work.

With software like Evergreen, you won’t have features disabled at a flick of a switch, awaiting some magical payment in order to be turned on. You also won’t be nickle and dimed for such things as adding a branch to your consortia.

With software like Evergreen, you won’t have your data locked away requiring some special license to access a proprietary database, and you won’t have your standards “extended” in ways that hinder migration to another system.

With software like Evergreen, you won’t have your “community” sandboxed into a private forum, where members are contractually obligated to not criticize the software (or the company) publicly and forbidden to post performance benchmarks.

With software like Evergreen, you can do more than point fingers at a vendor for the software’s shortcomings or pretend that you can sue them and recoup your losses after a catastrophe.

With software like Evergreen, you are actually empowered to do something about problems.

And finally, with software like Evergreen, the important thing isn’t actually the software. It’s you.

–
Jason Etheridge
Vice President of Community Support and Advocacy

Posted in Thinking about Evergreen | 3 Comments »