The story of Koha, the first open source library management system

No readers like this yet.
An open card catalog

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.


Joann is a librarian, mum, and foodie. She blogs at Library Matters.


I loved your description of the need for balanced relationships in several spheres, Joann, and how imbalance can result in problems. Thanks so much for HLT's gift of Koha to the community!

Thanks Dan. It was based on Greg Siefert's customer experience model. The full presentation is online if you are interested:

The power of free software. It warms me to see stories on the internet of New Zealanders embracing free software. Linux Lite is NZ's only free Desktop operating system. Would love to see Linux Lite in use at libraries and government departments around New Zealand.

Jerry Bezencon
Linux Lite Lead Developer

Thanks for this nice article. However, although it covers the Koha origins, I think don't covers all the Koha "story".
For example, could be useful describe the LibLime vs Community controversy, and their "divorce": there are two big Koha projects available (and independent): and

Hi Leandro,

There are not 2 big Koha. There is one that is developed by the community, and a fork, that is developed by LibLime.
If you look at the number of commits, people involved, activity, and users, I've no doubt that you'll choose to get your Koha.

About the history of this fork, I don't think it's needed to talk about it once again, except, maybe to prove that OpenSource is strong and can manage crisis like this one.
And writing about it would probably re-re-re-launch a flamewar and a strong and useless debate.

Paul, Koha developer since 2002, Koha release Manager for versions 2.0, 2.2, 3.8 and 3.10 (and french, and founder of

The article title "The Story of Koha..." drew me into reading. Instead of any discussion of how the application suite came to be, I found a lot of "philosophy." Where are descriptions of the architecture and design trade-offs? When and how does Koha meet needs that proprietary LMS did not? The article link to a "Koha Community" website was not obvious such that it took me several tries to find it.

I applaud the effort represented by the Koha project. Further, I hope that it encourages other projects.

Now the philosophy was well stated and applies with equal validity to both open-source and proprietary application development. In my 30+ years in software development, too often the project stake-holders avoided and neglected direct involvement with the end-users and, as expected, these projects were often still-born or failures in important ways.

Interesting story. We have cloud based <a href="">School Management System </a> Its does have Library system, you can check out if that interests you.

Dear Sir,
I'd to know how to install koha open source library software my computer. Tell me please direct download link. I will share public libraries in Myanmar. And then I will present this software for my LIS students our University of Yangon.

Information about Koha including how it can be downloaded can be found on the official Koha sute:

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.