Lessons from Koha in open source project ownership

Register or Login to like
Register or Login to like
Brand and community balancing on a see-saw


While compiling OSS Watch's list of Open Source Options for Education, I discovered Koha, an open source Integrated Library System (ILS). I discovered, with some confusion, that there seemed to be several ILS systems called Koha. Investigation into the reason for this uncovered a story which provides valuable lessons for open source project ownership, including branding, trademarks, and conflict resolution.

Koha started its life in New Zealand (reflected in the name, which is a Māori word meaning reciprocal gift, or a gift with expectations). It was originally commissioned by the Horowhenua Library Trust (HLT), written by Katipo Communications Ltd, and released under the GPL. Crucially, Katipo held the copyright on the Koha code.

As one of the few open source options in a market dominated by proprietary systems, a community of libraries, companies, and developers grew around Koha. As its market became international, it came to the attention of Joshua Ferraro, who worked for a public library in the USA.


Ferraro left his job at the library to found LibLime, a company providing Koha development and support. LibLime was soon providing Koha to a number of libraries in the USA, and as its customer base grew, so did the company. LibLime bought Skemotah, a consulting firm with copyright over a lot of Koha's early documentation, and Katipo's Koha division.

With the purchase of these companies, LibLime became owner of a large proportion of the IP and related assets of the Koha project. Katipo also hosted the project's website, mailing list, bugzilla, and owned the koha.org domain name. Control of these now transferred to LibLime. LibLime also registered the trademark of Koha in the US.

At the time, LibLime was deeply engaged with the Koha community. Ferraro served as release manager, overseeing the flagship 3.0 release. However, soon after this LibLime's fortunes changed.


Another company who provided ILS systems in the USA, Progressive Technology Federal Systems, decided to change its portfolio to a fully open source offering. This included Koha, and another open source ILS called Evergreen. Ferraro viewed PTFS as a competitor and set to paint them as the bad guys in the community, in spite of their positive record of engagement. LibLime's influence over the community meant that many members from outside LibLime fell into rank against PTFS, creating bad blood between both parties.

Galen Charlton, a LibLime employee, was appointed as release manager for the 3.2 Koha release cycle. At the time, Koha had no fixed schedule for releases, and they were made only when the release manager deemed them to be ready.

During this release cycle, LibLime as a company drew back from the community, instead focusing its development efforts on a product called LibLime Enterprise Koha. This product was developed strictly to client specifications, behind closed doors. Despite Ferraro's arguments to the contrary, the community viewed this as a fork, and met the announcement with indignation. Several LibLime employees left the company. Galen Charlton moved to Equinox, who provided support for Evergreen. Another, Nicole Engard, was employed by LibLime as an Open Source Evangelist, and as the company's open source activity ceased, she moved to ByWater Solutions, another Koha provider.


At this point, things took a complex turn. Ferraro and the other founders of LibLime decided that it was time to move on and turn their attentions to other areas. They approached PTFS and offered to sell LibLime to them.

During this time, members of the community lost editing access to koha.org and set up koha-community.org as a community-owned home of the Koha project. After some uncertainty, the sale was agreed. PTFS now owned LibLime's collective assets, including the amassed Koha IP and the koha.org website.

Despite PTFS's record of engaging in the community, after the LibLime purchase was completed they too pulled back from the community project. As Galen Charlton now worked for Equinox, the time he could commit to the 3.2 release of Koha was limited. PTFS was unhappy with the speed of releases and forked the project internally, creating a product called LibLime Koha, with its home at koha.org.

Unfortunately, this only served to the detriment of relations with the Koha community. Koha.org was previously the home of the community Koha project, and now promoted a project which, while open source, was developed by a single company.

A further blow to the relationship was struck when it became apparent that just before the sale of LibLime, the company had filed a trademark application for the mark KOHA in New Zealand. As PTFS now owned all of LibLime's assets, the application was transferred to them. There was a fleeting chance at reconciliation as the Koha community put forward an agenda for a meeting with PTFS.

The CEO of PTFS attempted to schedule a conference call with members of the HLT Koha Subcommittee. While the committee was initially receptive to the idea, governance discussions typically took place on mailing lists and IRC channels, so they decided they would only be willing to have such discussions in one of these formats. Requests for discussions to take place in this way were unfortunately declined. PTFS recieved some flak from members of the community and responded with a press release indicating that the community wasn't serious about having discussions. The HLT Koha Subcommittee published a report from their point of view.

The application for the New Zealand trademark has been provisionally granted by IPONZ. Individuals from the community opposed the grant, which now awaits a final ruling.


We stand today with three brands using the name Koha.

  • Koha is developed by a diverse international community.
  • LibLime Koha is developed by PTFS to the demands of its clients.
  • LibLime Academic Koha is developed by PTFS for a consortium of institutions.

Other companies on the Koha community use the name Koha, where their product is drawn from the community's codebase and may have local customisations.

I discussed the potential for community engagement in LibLime Koha with Patrick Jones, Director of Commerce-based Library Solutions and Services at PTFS. As far as they are concerned, all and sundry are welcome to take, use, and contribute to the LibLime Koha code base, which is still released under the GPL and is available on GitHub. They have recorded over a thousand downloads of the open source code on top of the deployments they manage for clients, and there are several forks by GitHub users. However, any changes made by these parties have yet to be contributed back to the LibLime codebase.

The LibLime Academic Koha project follows a different model. Parties must make a financial commitment to become part of the consortium governing the development, at which point they also get access to the product. The code is necessarily GPL, but not distributed outside the consortium. This is similar to the community source model employed by the Sakai project in its early stages. 

One could argue it's not inherently bad for a project to fork, but there would be benefits if all versions of Koha drew from the same codebase. While it's certainly a healthy sign when an open source project is diversified and customised to individual requirements, this would ensure that the whole community benefited from the shared development effort. Where a party decides not to contribute their changes back for whatever reason, a shared codebase at least provides a known baseline for developers and for customers.

However, with codebases that have diverged as with Koha and LibLime Koha, there would need to be a considerable amount of effort to integrate the changes from each into a single codebase, and agreement over which codebase this should be. While PTFS and companies in the Koha community all have employees paid to work on the code, they all have to meet demands of their customers, so there would need to be a clear business case for dedicating the time to make this happen.

There would need to be compromises on both sides to heal the rift. The issue that the community has drawn most attention to in recent years is PTFS's pursual of the New Zealand trademark. This is viewed, particularly by HLT but also by other members of the international community, as an attack on the Koha project's identity. Withdrawing the application would go a long way to healing the current rift. PTFS's view is that since their acquisition of LibLime gives them copyright ownership over much of the Koha code, documentation, logos, and ownership of several Koha-releated websites, the community should acknowledge their position and right to use the Koha name.


There are some key lessons that can be learned from this story, both for open source projects and for companies engaging with existing projects.

The first is an issue of assets. Once a project is established, you may want to consider transferring ownership of assets to a non-profit foundation. There are a number of software foundations which exist for this purpose. Having your assets held in this way ensures that the buying and selling of companies doesn't lead to transfer of your project's IP.

You should work with the assumption (and indeed the intention) that commercial organisations will be interested in providing services around your product. Attracting companies to your product is a key path to sustainability, as it provides financial support for ongoing development.

It's perfectly sensible that these companies will want to do things like registering trademarks that pertain to their brand offering. To avoid confusion, it's wise to ensure the brand you wish to promote the project under is protected as widely as possible (e,g. by registering a trademark), and ensure there are clear guidelines governing its usage.

For a company to support your project, it will need to be able to provide a guaranteed service to customers. A predictable release cycle will help make this possible, as it allows a company to plan its services around a known schedule of releases.

If you do engage with an existing project, it always pays to approach the situation humbly. An established project will have a governance structure which the community have trust in. Work within the established structures, and once you've contributed to the project, you may be in a position to gain influence and use it to further your interests.

Ongoing conflict isn't good for any parties concerned. Never turn down an opportunity to discuss an issue and seek a resolution. If two parties can't agree on terms by themselves, it may help to seek mediation from a third party who can broker a compromise.

When emotions around an issue run high, it can be hard to stand back and take an objective view of a situation. Where there are past disagreements, personal apologies for comments published in anger may be a good place to start.

OSS Watch maintains a series of briefings and articles about project governance, sustainability and community engagement. If would like information and training on applying these to your project, please get in touch.

I'd like to thank Patrick Jones and Nicole Engard for taking the time to tell me the story of Koha. If you'd like to find out more, there is a reading list of news articles and blog posts about the project.

Mark Johnson is Development Manager for OSS Watch, the open source software advisory service. He contributes to the Moodle VLE though code contributions and plugins, as well as the Ubuntu community through the weekly Ubuntu Podcast.


I believe the article implies there is some compelling need to heal the "rift". I rather doubt the Koha community feels that way. This issue is settled wrt Koha development (except for the continuing effort by PTFS to register the New Zealand trademark); PTFS is off in their corner working on their quasi-open products, and the community is continuing to develop the open, free Koha.

I'm not sure I agree that PTFS has the "record of engagement" or true open source spirit stated in the article. They have certainly alienated the community, and now we've moved on. It's history, time for cookies.

I do concur that this experience shows the need to think early in the product development lifecycle about trademarks, branding and "ownership". It's indeed unfortunate that Koha "identifiers" weren't entrusted to a responsible, independent organization before problems arose. Given that PTFS owns the Koha trademark in the US, I fear anyone, support companies or even end users like libraries, using the Koha name are subject to litigation by PTFS.

It's interesting you note the copyright of the code as an issue, since it was released under the GPLv2+ it really isn't. Even if most of the code were copyright PTFS (git blame tells me its closer to 24% now) it couldn't be relicensed without the rest of the copyright holders agreement. Also that would not change the fact that it has been released under GPLv2+ and can't be unreleased. In this case the copyrights are a moot point. I am sure you understand this point but felt it needing clarifying for the readers, there is no danger to the Koha codebase.

about the meeting between the community and the CEO of PTFS:
CEOs are often good in talking to an audience. community geeks that live half their live online prefer emails and IRC. obviously, each party would dominate the other in their preferred media. as this is likely to come up as an issue whenever an open-source community meets business, it would be interesting to find a god solution to this problem. to find a way of communication to which both parties can agree.

i personally have no idea for a solution.

I think that the default mode should be open, not a private conversation, open in a logged medium, just like the rest of the development process.

If you didn't follow Koha closely, you wouldn't know of these shenanigans around the Koha name, trademarks etc.

It could be that the start of most things is when the initial development is unplanned and comes from just the fact that there is demand for product, which means a lot of the 'infrastructure' issues go unresolved for a while.

I wish Koha well, as its our leading open source recommendation when implementing A1 Academia.

Waithaka Ngigi

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.