A small public library serving a population of 30,000 in New Zealand developed and released the world’s first open source library management system in 2000. Horowhenua Library Trust named the system Koha, which is a New Zealand Māori custom meaning gift or contribution.

This is a story of why we developed Koha and how it has changed the way we, and millions of others, work.

A new library management system

In 1999, with a 12 year-old system running on a 386 server, Horowhenua Library Trust (HLT) needed to replace our library management system (LMS). We followed the usual Request For Proposal (RFP) process, and after reading a staggering amount of papers, found we were not satisfied with any of the options. There were systems available that would over-deliver at a cost we couldn’t afford, systems which we could afford but didn’t meet our needs, and all of the systems had much more expensive communications solutions than we had been using. Plus, none of them used a web browser interface.

We engaged Katipo Communications to develop a web-based LMS for us, and they suggested it be released under the GNU General Public License (GPL) as a way to ensure the project had longevity (they didn’t necessarily want to spend the rest of their days supporting a proprietary system) and this would encourage other people to use it—improving and enhancing it along the way. The GPL would also ensure that subsequent modifications and additions by other organisations were open source as well, benefitting all users.

While "shareware" and "freeware" have been available since the earliest days of computing, open source software had developed in the years leading up to 2000 on a different scale entirely. It was no longer confined to the realm of "hobby" programmes. Open source projects were starting to produce software that matched or exceeded the quality of commercial products at the time, and Linux was starting to challenge Windows in very large-scale projects.

Librarians and FOSS

Librarians and free and open source software have lots in common. They both:

believe that information should be freely accessible to everyone

benefit from the generosity of others

are about communities

However, working with free and open source is a very different way of working for librarians who are traditionally more comfortable in a co-dependent relationship with vendors. A significant mind-shift is required in order to maximise value from open source.

It is NOT about accepting what you are given but articulating what you want. Librarians need to develop new skills in order to interact or participate fully in the community that is the heart of open source projects.

Open source community

Open source projects only survive if a community builds up around the product to ensure its continual improvement. Koha is stronger than ever now because it is supported by an active community of developers, librarians and vendors—who actually talk to each other!

Each partner has a role to play in a successful open source community:

Librarians and the patrons or end users whose interests they represent are the ultimate judges as to whether or not a product or service is desirable, and they define a product or vendor’s success.

Developers who create the code and tools.

Vendors filter ideas and bring only the viable, potentially profitable, and sustainable options to market.

My keynote address at KohaCon09 in Thane, India explored this community of partnerships and how crucial it is that the interactions between each is balanced.

Vendors and libraries

When the relationship is in perfect balance the relationship thrives; vendors get excellent input and feedback on feature development, exhaustive usability testing for design and function, and truckloads of free promotion. However, if the desire to have a congenial working relationship dominates over sound business decisions, development stops being financially viable and economic sustainability is lost. On the flip side, if short-sighted business decisions override the needs and wants of the library, including the open source philosophy, we get into trouble as well.

Developers and libraries

When it works well, we get speedy development of solutions that do the job. A reality check informs technical development; developers don’t just develop something because it sounds cool but because it’s a ‘good’ solution to an existing problem or will add value. When it gets out of harmony, we risk getting bad features developed at the initiative of either the library or the developers. Libraries may request really useful features but developers may not want to incorporate them, or too many bells and whistles could get developed, sacrificing function over gizmos.

Vendors and developers

Many businesses fall into the trap of focusing most of their energy in the business side (cost savings, process improvements, efficiencies, quality control) instead of taking the time to focus on the people and relationships. When pure business goals start driving development we get bad stuff happening due to corporate greed, but when we get the balance right we get high quality, innovative, viable, rapid, and sustainable development.

Take a holistic view

While each of the relationships between the partners are important the holistic view is even more important. It is really important that librarians are actively involved and don’t just leave development to the developers and vendors. We need to keep in mind the end user who we serve. For example, if you ask: "Do these new bells and whistles help the people accomplish something or do they just get in the way?" it helps you avoid the "just because you can" syndrome.

Linus Torvalds in an interview by Steven Vaughan-Nichols for a Hewlett-Packard publication had this to say about software development:

The other thing ... that people seem to get wrong is to think that the code they write is what matters ... No, even if you wrote 100% of the code, and even if you are the best programmer in the world and will never need any help with the project at all, the thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it."

Moving to open source was philosophically a good fit for Horowhenua Library Trust. It has also been a good financial and practical decision. But most importantly it helps us to put the end user, our patrons and the people we serve, at the heart of decisions we make as an organisation.