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