Branches of Koha

An arborist recently came to look at the white oak tree in my back yard. The tree is about 80 years old and is the biggest in the neighborhood. According to the arborist, our tree was in excellent health because of its large number of leaders, or main branches. Even in the strongest wind, these leaders will bend and a few might even break, but the tree itself is very unlikely to topple. Some neighbors have a very tall, scary tulip tree with only one main branch. I fear it will come down one day very suddenly.

In my discussion of Koha and LibLime (part 1, part 2), I promised to write more about the so-called "forking" of the Koha development process. What happened was that about 10 months ago LibLime stopped participating in the the Koha open development community. According to Josh Ferraro, LibLime's CEO, this happened because LibLime developers were having trouble completing development projects that LibLime had committed to doing for customers. Together with his development partners, Ferraro judged that LibLime's developers were spending too much time providing support to non-customers and that the overhead of the community development process was slowing down development more than it was contributing to LibLime's development objectives.

This judgement is hotly contested by developers advocating a open community development process. (See, for example, this post by Chris Cormack, or Owen Leonard's post on the Koha List.) It's not hard to imagine that an open community might pose difficulties during focused development. Two coders may disagree about how a task is to be done, and depending on personality and skills involved,  such disputes might easily become major time-sinks. Implementing a feature important to US libraries might break a feature important to European libraries, for example, and making both features work at the same time might be a lot of work. On the other hand, a small community such as the one working on Koha can ill afford to fragment into factions and start working at cross purposes.

When one branch of code diverges too far from another, the branches can become incompatible, or forked. When this happens, effort applied to one branch may have to be duplicated for the other branch. Forking is a common occurrence in open source projects, and can be evidence of a project's health. Such a fork in the Linux kernel came to light just last week, as some drivers added to support Google's Android system were deleted from the project's main tree. The downside is that forks increase the maintenance burden. It's often worthwhile for developers to work hard to join their code to a main branch so that others can maintain the contributed code and keep it from breaking.

Open Source projects can be motivated in many ways. Some projects have their origin in proprietary software, when the developers decide their businesses would benefit from wider adoption or support. Or perhaps the emphasis of the developer's business has changed. Etherpad is a recent example- the company was acquired by Google, whose main interest was to improve Google Wave rather than to continue the Etherpad service.

Other Open Source projects arise as "calling cards". That's how IndexData started doing Open Source. Sebastian Hammer, IndexData's Founder and President, told me that when he started, he just wanted his software to be widely used. His business was primarily custom development, and companies who were using his software because it was free began using his company for development because the free software worked well.

Only a small percentage of open source software projects are supported by more then just a few developers, and even fewer survive without an acknowledged lead developer. Koha has been blessed with significant contributions from a number of developers (and it uses free open source components such as Apache, MySQL, Perl, PHP and IndexData's Zebra).

You can imagine that Koha contributors outside LibLime would be very upset at LibLime's withdrawal from community development. Their contributions to the project were made with an understanding of Koha as an inherently community-driven effort for the benefit of all Koha libraries, and LibLime's withdrawal from the community process implicitly minimizes the value of their ongoing contributions. In fact, several contributors within LibLime were upset at the changes, and are now working for competing companies.

The fact of competition among Koha project participants inevitably leads to conflicting incentives. While proprietary software creates incentives for vendors to compete for initial sales with a robust platform and advanced features at the expense of ongoing service, open source software creates incentives for companies to focus on service and custom development. A company that puts a lot of effort into the core software may gain no advantage from that work if it has competitors which instead focus on services. Competitive considerations may certainly have been an important factor in the manner of LibLime's withdrawal from the community process.

It's interesting to see the messaging that LibLime's competitors used to respond to LibLime's withdrawal from the community development process. These ranged from the sunny "Equinox Promise" to a pointed post from BibLibre and a worried post from ByWater. There is clearly a struggle among all these companies to resolve the tension between competition and the need for cooperation that underlies Open Source support businesses. (Note: Equinox supports a different library system, Evergreen, so it's not so directly competitive with LibLime. Update Feb. 11- Equinox announced its entry into the Koha support market.)

Another reason given by LibLime for the change in its development process was that they wanted development customers to be able to test and approve new functionality before it would be released to the world. In the words of a LibLime press release:

"A public software release of each version of LibLime Enterprise Koha will occur periodically, after the sponsoring library and LibLime's customers have had adequate time to ensure that the codebase is of sufficient quality and stability to be contributed back to the Koha Community."

One Koha developer described this rationale to me as "nonsensical" and pointed out that the code quality seemed to be good enough for LibLime production customers. A look through the Koha developer wiki gives the impression that an elaborate QA process has been built by the community; I don't know how well it is followed.

My perspective, as someone who has managed a development project of similar scope, is that testing and quality assurance require a fair amount of disciple and attention to process. Getting developers to comment their code, do proper testing, and keep documentation up to date (i.e. adhere to a documented QA process) is not always easy, even if you're signing their paychecks. So while I have little insight into whether LibLime's new internal development processes are in fact resulting in better or more timely code, I think that the explanation given is at least plausible.

Managing a software development project is really, really hard. A lot of people imagine that their success in managing one project is evidence of superior process or ability, when really they were just lucky to have the right people at the right time. So I'm really skeptical when someone says that "community development" is the best way to build software, or that "agile methodology" is the one true way. In the real world, development managers may have the skills to succeed in one style of development (or group of developers) and be lacking in the skills needed to succeed in another style.  Software development projects only work if they work. In the case of the two branches of Koha, only time will tell whether one branch will wither and die, or whether two branches will end up diverging, both healthy.

While the people in charge at LibLime and PTFS have been in no position to comment on what they will do before their transaction is complete, other Koha stakeholders that I talked to were "hopefully optimistic" that PTFS would ultimately decide to rejoin the community development process and help reunify the Koha code base. PTFS developers have been active with contributions during the period that LibLime has pursued separate development. At ALA Midwinter, PTFS' John Yokley emphasized that a decision as to the extent of PTFS participation in Koha community development had not yet been made. In the meantime, Koha stakeholders other than LibLime have launched a new website to be the "Temporary home of the Koha Community."

 (Update Feb.12 - the acquisition is not happening.) (Update Mar. 16 - the acquisition closed after all.)

You can look at my tree analogy in two ways. You could say that having multiple branches of the Koha code is good for the project, as it is for my oak tree. You could also say that concentrating development of Koha in one company is dangerous, and worry about it as I do about the tulip tree.

Or you could just be happy that spring is coming and buds are already appearing on the trees.

This is the third part of a series. Also see Part 1 and Part 2

Article any source

Who Owns Koha?

In New Zealand, Maori customs are taken seriously. For example, in 2002, the route of a new highway through a swamp had to be altered because it was believed that three taniwha - Karutahi, Waiwai, and Te Iaroa - lived there, and were being disturbed by the road, causing an unusual number of accidents. Taniwha are mythical beings that act as guardian spirits. Many taniwha arrived in New Zealand as guardians of specific ancestral canoes and then took on a protective role over the descendants of the canoe's crew.

Another Maori custom, one that has crossed over into general New Zealand culture, is that of "koha".  "Koha" is often translated as "gift", but according to Chris Cormack, one of the original developers of the Free Open-Source Software (FOSS) Library System with the same name, a more accurate translation would be a "gift with expectations".   Cormack got his B.A. degree in both mathematics and Maori Studies, so he should know. A koha is gift that is offered with an expectation that it will be reciprocated.

In the U.S., (and to a lesser extent, in Europe) it's our lawyers that we seem to take seriously. And so when we let people use software that we've developed, its not enough to offer it as a koha, we have to use a legal license to spell out the terms of the release. The license that has become popular because of the expectations of reciprocity built in to it is the Gnu Public License (GPL).

Software released under the GPL cannot be thought of as an unconditional gift by its developer. GPL software is not in the public domain, it is copyrighted. A copyright owner can exert control over the use of the copyrighted material; the GPL uses that power to require licensees to publish any modifications they make if they want to redistribute the modified work.  When the Horowhenua Library Trust was choosing a license to use for Koha (the library system software), they chose GPL (version 2) because they thought it would prevent Koha from being further developed as non-open software.

Included in the recently announced (but not yet completed) acquisition of LibLime by PTFS were Koha-related assets, including source code copyrights, trademarks and the koha.org website. It may be difficult for the casual observer to understand what value these assets have, especially in light of the GPL license attached to Koha. Could these assets be used to privatize Koha in some way? The short answer is "No", but it gets complicated.

Some FOSS companies use "dual licensing" as a business model. They release their code under GPL, but if another company wants to use the software in a way that would not be allowed under GPL, it has the option to pay for a commercial license. Dual-licensing can only be done by the original copyright owner. Index Data has used this model for years to the great benefit of libraries everywhere. MySQL AB is an example of a company which was extremely successful with this model; it was acquired by Sun Microsystems for about a billion dollars. (See this article for an overview of how GPL licensing fared in Oracle's subsequent acquisition of Sun.)

The GPL makes it very difficult, however, for anyone to change licensing terms after software has been released into the world. That's because of the way copyright law determines the copyright holder of derivative works. In general, if I take a piece of software that you have written, and modify it in such a way that involves creative effort on my part, then I own the copyright to the changes that I've made and the resulting work is a derivative work that both you and I have a copyright interest in. Even though you are the original copyright holder, you would need my permission to release the derivative work under any license other than the GPL.

Unlike Index Data's software, Koha has included significant contributions from many developers, including many who have never worked for LibLime or Katipo Communications (which sold its copyrights to Koha source code to LibLime in 2007). So although LibLime probably owned clear copyright to a majority of Koha at some point, Koha is still a collective work locked into GPL, version 2, and it is unlikely that LibLime or PTFS would be able to distribute Koha under terms other than GPL without doing a thorough rewrite of the software.

Trademarks are a different story. LibLime owns the US trademark for Koha; a European trademark is held by BibLibre. Trademarks are frequently used by open source projects to prevent splintering. The excellent primer on legal issues by the Software Freedom Law Center puts it this way:

FOSS applications develop reputations over time as users come to associate an application’s name with a particular standard of quality or set of features. Trademark law can help protect this relationship of trust and reliance that a project develops with its users; it allows the project to maintain a certain amount of control over the use of its brand.

Since GPL and other FOSS licenses allow anyone to modify and distribute software as long as the license conditions are met, they frequently spawn variants. The owner of a trademark can prevent these variants from using the trademarked name, and thus enforce unity in a project.

In the case of Koha, there are currently two parallel tracks of development being pursued, one inside LibLime, and the other by the community of developers outside LibLime. I will have to postpone a discussion of the issues surrounding  these development tracks to yet another article, but for now, let's just assume there will be two main versions of Koha, LibLime Koha and Community Koha. In the US, LibLime could theoretically prevent anyone from  using the name "Koha" without its authorization, and could strip Community Koha of the right to use "Koha" in its name. In fact, LibLime and BibLibre threatened to use this power a year ago to regulate PTFS's use of Koha trademarks in the marketing of its Koha support services. Liblime could even apply the Koha name to non-Open Source software. Similarly, BibLibre could regulate the use of the Koha name in Europe, preventing LibLime from marketing LibLime Koha there.

Based on discussions I've had with the leaders of almost every open-source library system company, I think it is unlikely that there will be any such "trademark war". Even if the development of Koha continues on separate but related tracks, the success of every Koha-based company is tied to the success Koha as a whole, and vice versa. It would be advantageous for every stakeholder if the two trademark owners develop some sort of "big tent" system of Koha trademark governance. Assuming PTFS's acquisition of LibLime is completed, such governance will need to be acceptable to both PTFS and BibLibre, and will need to accommodate differing styles of software development.

Until a general agreement on the use of Koha trademarks is reached, Koha stakeholders would be well advised to recognize that collective copyrights tie them into the same canoe and that they should avoid disturbing the taniwha that guards and protects them.

This article is the second part of a series. Part 1 is here. Part 3 is here

Article any source