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.
Acquisitions
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.
Divisions
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.
Conglomeration
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.
Reparations
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.
Lessons
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.
5 Comments